--- title: "What zero JavaScript did to Core Web Vitals | Elivate SEO" description: "Elivate SEO ships no client-side JavaScript on content pages. Here are the Lighthouse numbers, and the two fixes that had nothing to do with JavaScript." url: "https://elivateseo.com/insights/zero-javascript-core-web-vitals" published: "2026-09-03T00:00:00.000Z" --- SEO # What zero JavaScript did to Core Web Vitals Elivate SEO ships no client-side JavaScript on content pages. Here are the Lighthouse numbers, and the two fixes that had nothing to do with JavaScript. Ridam Agrawal founder, elivateseo **Published:** 3 September 2026 **Read:** 4 min In short ## Does removing JavaScript actually improve Core Web Vitals? Removing client-side JavaScript took elivateseo.com to 100 on performance, accessibility, best practices and SEO, on mobile and desktop, with a Total Blocking Time of 0 ms. The zero JavaScript is what removed blocking time. Fonts, image dimensions and cache headers produced the rest, and none of those three involve JavaScript at all. 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. | | Mobile | Desktop | | --- | --- | --- | | Performance | 100 | 100 | | Accessibility | 100 | 100 | | Best practices | 100 | 100 | | SEO | 100 | 100 | | First Contentful Paint | 0.9 s | 0.2 s | | Largest Contentful Paint | 1.4 s | 0.3 s | | Total Blocking Time | 0 ms | 0 ms | | Cumulative Layout Shift | 0 | 0 | | Speed Index | 2.2 s | 0.7 s | 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. An Elivate SEO content page ships no framework runtime, no hydration and no component tree being rebuilt in the browser. Two scripts do load: a cookieless analytics beacon of about 3KB, and Google Analytics, which is 173KB and is fetched only after the `load` event so that it never competes with first paint. Nothing contends for the main thread while the page is painting, 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](https://elivateseo.com/services/seo) 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](https://elivateseo.com/services/geo). 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 `` added from here carries explicit width and height for exactly that reason. ## Questions **Does a perfect Lighthouse score improve rankings?** A perfect Lighthouse score is not a ranking factor on its own. Core Web Vitals are one small, real signal inside Google page experience, and Google ranks on field data from real visitors rather than on the lab score Lighthouse produces. **Is a zero-JavaScript site realistic for a business site?** Zero client-side JavaScript is realistic for content pages — marketing pages, articles, service pages — which is most of a business site. Product interfaces, dashboards and anything with real interaction need JavaScript, and pretending otherwise is how a fast site becomes an unusable one. **What is Total Blocking Time measuring?** Total Blocking Time measures how long the browser main thread was busy enough to ignore a tap or a click while the page was loading. Total Blocking Time is driven almost entirely by JavaScript parsing and execution, which is why removing scripts moves it further than anything else. ## Sources - [Lighthouse performance scoring](https://developer.chrome.com/docs/lighthouse/performance/performance-scoring) - [Web Vitals](https://web.dev/articles/vitals) ## Ridam Agrawal Founder of Elivate SEO. Full-stack engineer who built the SEO and GEO platform this work runs on — keyword and rank tracking, site audits, and citation tracking across AI assistants. [More about the work →](https://elivateseo.com/about) ## Is your brand being cited? On a free 30-minute strategy call we look at where you stand in search and in AI answers, and what would change it. [Book a strategy call →](https://elivateseo.com/contact) keep reading ## Related reading SEO ### [B2B SaaS SEO, measured on 69 sites](https://elivateseo.com/insights/b2b-saas-seo) We checked 69 SaaS sites against the advice Google shows for "b2b saas seo". Most blog in a subfolder and build rival pages; 27 serve Markdown to AI agents. SEO ### [D2C SEO, measured on 43 brands](https://elivateseo.com/insights/d2c-seo) We checked 43 D2C brands against Google's own docs. The platform writes the product markup; stores skip shipping and returns, and FAQ rich results are gone. Service ### [How we approach SEO](https://elivateseo.com/services/seo) Technical SEO, on-page work and content strategy — implemented rather than recommended.