What zero JavaScript did to Core Web Vitals

Elivate SEO rebuilt this site on Astro with output: 'static', which ships no client-side JavaScript unless a component asks for it. Nothing on a content page asks. The first Lighthouse run against production, on 2 September 2026, is the number every later change gets compared against.

What the numbers were

Lighthouse 12, headless Chrome, run against the live site rather than localhost.

These are lab numbers. CrUX needs real traffic before it reports field data, and elivateseo.com had none on the day of the run. Google ranks on field data, so a perfect lab score is a starting position rather than a result.

Why Total Blocking Time was zero

Total Blocking Time measures how long the browser main thread was too busy to respond to a tap. On a typical marketing page that time is spent parsing and executing JavaScript, so the number is mostly a measure of how much script arrived.

The only JavaScript on an Elivate SEO content page is the analytics beacon, which is about 1KB and cookieless. There is no framework runtime, no hydration, no component tree being rebuilt in the browser. Nothing competes for the main thread, so Total Blocking Time is 0 ms on mobile and desktop, and it is 0 ms for a structural reason rather than because the page was optimised into that shape.

This is the part of the result that genuinely comes from shipping no JavaScript. It is also the part that is hardest to hold on to: one analytics tag, one chat widget and one A/B testing script are enough to put the number back.

The two fixes that had nothing to do with JavaScript

The first run scored 95 on accessibility, not 100, and the cause was the oversized wordmark in the footer. Rendered as live text it sat at 1.19:1 against its background — decoration doing an impression of content. Marking it aria-hidden was not a fix: that hides it from a screen reader while a sighted low-vision visitor still has to look at it. Redrawing it as an SVG was the honest fix, because ornament is what it always was.

The second was caching. Production was serving everything with max-age=0, must-revalidate, so a returning visitor revalidated the stylesheets and 108KB of fonts on every single page view. The adapter’s caching rule had been written after the handle: filesystem marker in the routing config, which meant it never fired at all. A build script now writes the rule ahead of that marker.

Neither problem was caused by JavaScript and neither would have been fixed by removing more of it. Both were found by running the audit rather than by reasoning about the stack — which is the argument for running the audit in the first place.

Where zero JavaScript stops being the right call

Zero JavaScript is a good default for content: marketing pages, articles, service pages, documentation. It is a bad default for anything with genuine interaction, and Elivate SEO does not pretend otherwise — the admin panel behind this same site uses JavaScript, because a lead pipeline that cannot update without a page reload is a worse product.

The rule that survives is narrower and more useful than “no JavaScript”: ship none on pages whose job is to be read, and spend the budget where interaction actually earns it.

What these numbers do not tell you

A 100 on performance says the page loads fast in a lab. It says nothing about whether anyone finds the page, whether the content answers the question that brought them, or whether an AI assistant will cite it — which is a separate problem with separate work behind it.

Elivate SEO publishes this number because it is the honest starting point, not because it is an achievement. The interesting version of this article is the one written in six months, when there is field data from real visitors, images on article pages, and something to compare against. Cumulative Layout Shift is at 0 today partly because there are no images above the fold yet. That is the first thing expected to regress, and every <img> added from here carries explicit width and height for exactly that reason.