Lighthouse perfection, out of the box

August 23, 2026 · @holsee · design · performance · seo · agents

Scores like this are usually the end of a story: an audit, a backlog of fixes, a week of chasing tenths. On a Cherry site they are the starting state - and not for one blessed default, but for every one of the thirty official themes, from the CSS-only ones to the WebGL ones. This post walks through each of the five lights and shows where in the framework the work actually lives, because none of it lives in your site or your theme.

Performance: ship nothing, then ship it well

The fastest request is the one the page never makes. A Cherry build is plain HTML and one stylesheet; there is no client framework, no hydration bundle, no analytics snippet, and no third-party request of any kind. Themes that want motion mount it as small, deferred islands - a canvas here, a search index there - so the reading path never waits on script.

What does load is engineered around the paint:

• Fonts land before first paint. Every face a theme ships is a self-hosted, latin-subset woff2, preloaded from the framework-owned head. Each family carries a metric-matched local fallback - size-adjust, ascent, descent and line-gap measured against the real face - so even when a slow connection delivers the font late, the swap moves nothing. That is where the layout-shift score comes from: the page simply has no reason to reflow.
• Decoration never blocks layout. Theme atmospherics paint to position: fixed canvases behind the page or arrive inside the existing box. First paint is the finished layout.
• Builds are deterministic. Same tree in, same bytes out. There is no runtime doing work per request that the build could have done once.

Accessibility: the templates are the audit

The score is a consequence of the theme contract, not a checklist run after the fact. Official templates use semantic landmarks (header, main, nav, article), label their controls (the theme toggle and copy buttons are aria-labelled icon buttons), keep focus visible, and honour prefers-reduced-motion in every animated theme - reduced motion means one still frame, not a slightly slower animation. Colour flows through the token system in both renditions, so contrast is a property of the palette, and every one of the thirty themes ships a light and a dark rendition that hold it.

Best practices: boring on purpose

No console errors, no deprecated APIs, no mixed content, no third-party origins to leak to. Everything a page references lives on your own domain, from fonts to search. Images carry real width and height attributes. JS-off is a designed state, not an accident: every island has an honest static fallback, and print gets its own consideration. The audit has nothing to find because the surface area is small and self-contained.

SEO: the head your theme cannot forget

The classic SEO failure is not a missing technique, it is a missing tag. Cherry makes that structural: the SEO head is framework-owned HTML that every theme renders as a single assign, or fails the contract check. So every page - on every theme, with zero config - carries its canonical URL, description, Open Graph and Twitter cards, feed links (Atom and JSON Feed), favicons, and JSON-LD where it applies (a Person on the portfolio, BlogPosting on posts). robots.txt and sitemap.xml are build outputs. Root-relative links respect base_path, so project-pages deployments do not bleed 404s into the index.

And the part audits cannot see: cherry check refuses a build with a broken internal link, and the deploy workflow runs the same check before it builds. A link that would rot your crawl budget never reaches production. The full story is in LLMs and SEO.

Agentic browsing: the third audience

The newest column on that scorecard measures what the other four ignore: can a machine that is not a crawler actually use the site? Cherry passes all three checks because the machine surface is a build output, not an afterthought:

1. A table of contents for language models. Every build emits /llms.txt, the curated map of what the site contains and where.
2. A plain mirror of every page. Beside each index.html sits an index.md - the page as the author wrote it, not as the theme rendered it. An agent curls it and gets clean markdown, no DOM parsing, no readability heuristics.
3. Structured data for everything that has structure. JSON Feed for the blog, a cv.json JSON Resume on sites with a profile, and the search index as plain JSON.

The same philosophy runs through the CLI: every verb takes --json and returns one envelope shape with honest exit codes, so the agent editing your site works the same interface as the agent reading it. That half is documented in the machine surface.

Out of the box means out of the box

Here is the part that matters if you are choosing a tool rather than admiring a scorecard. Nothing above is a plugin, a recipe, or a config flag. It is what cherry new hands you:

• the SEO head, feeds, sitemap and robots - emitted for every site;
• font preloading and metric-matched fallbacks - part of every official theme, enforced by the same conformance tests;
• the machine surface - llms.txt, markdown mirrors, JSON everywhere - emitted for every build;
• the link gate - cherry check in your terminal and in the deploy workflow cherry gen.action writes for you.

Swap any of the thirty themes and the scores do not move, because the score-bearing parts never belonged to the theme. That is the design: the framework owns what must never regress, the theme owns the personality, and you own the content. Lighthouse just confirms the division of labour.