At a glance
Lighthouse measures four dimensions of a website — Performance, Accessibility, Best Practices, and SEO. But only the Core Web Vitals feed directly into Google's ranking. Performance optimization is a measurable SEO lever, not just a UX discipline. Most sites fail at architectural decisions, not at detail optimization. Calvarius brings its mandate sites methodically into the 90-plus range across all four dimensions — the Calvarius site itself currently sits at 99/100/100/100, with First Contentful Paint at 0.7 seconds, Largest Contentful Paint at 0.7 seconds, Total Blocking Time at 70 milliseconds, and Cumulative Layout Shift at 0.
What Lighthouse measures — and what it doesn't
Lighthouse is an open-source tool from Google that evaluates a website across four dimensions. Each dimension receives a score between 0 and 100, presented in the familiar donut chart in green, orange, or red.
Performance measures loading speed and rendering time. This is where metrics like First Contentful Paint, Largest Contentful Paint, Total Blocking Time, Cumulative Layout Shift, and Speed Index combine into a weighted total. Performance is the only one of the four dimensions where Lighthouse runs synthetic tests — the values are determined in the browser under simulated conditions, not measured from real users.
Accessibility checks conformance with the Web Content Accessibility Guidelines, or WCAG. This includes sufficient color contrasts, semantically correct HTML structure, alternative texts for images, keyboard operability of all interactive elements, sufficient touch target sizes. Lighthouse can automatically detect about 30 to 35 percent of accessibility issues — the rest requires manual audits.
Best Practices checks technical hygiene: HTTPS, secure library versions, correct image dimensioning, no browser console errors, no deprecated APIs. This dimension is usually the easiest — those who develop modernly often reach 100 here without explicit optimization effort.
SEO checks technical findability: meta tags, structured data, crawlability, mobile suitability, correct HTTP status codes. Important to understand — the SEO dimension measures technical preconditions, not content quality or backlink profiles. A Lighthouse SEO score of 100 guarantees no good Google position. It only guarantees that no technical obstacles block ranking.
This is the central limitation of Lighthouse scores as a marketing metric: they are synthetic, not derived from actual user behavior. They measure potential, not reality. Reality is measured by Google itself, with the Core Web Vitals.
Core Web Vitals — the metrics that actually matter
While Lighthouse evaluates four dimensions, Google uses only three specific metrics for ranking — the Core Web Vitals. They are not measured in the Lighthouse browser but derived from real user data via the Chrome User Experience Report database, or CrUX. That is the decisive difference: Lighthouse shows what is theoretically possible. CrUX shows what users actually experience.
Three metrics make up the Core Web Vitals.
Largest Contentful Paint (LCP) measures loading time. Specifically: how long does it take until the largest visible element above-the-fold is rendered? This can be a hero image, a headline, or a background element. Google rates LCP under 2.5 seconds as good, 2.5 to 4 seconds as in need of improvement, over 4 seconds as poor. According to the Web Almanac 2025, only 62 percent of mobile pages worldwide achieve a good LCP value — making LCP the hardest of the three Core Web Vitals.
Interaction to Next Paint (INP) measures responsiveness. How long does it take between a user interaction — click, tap, keyboard input — and the next visual response of the page? INP replaced First Input Delay (FID) as a Core Web Vital in March 2024. The switch was substantially stricter: FID only measured the first interaction of a session, INP measures essentially all interactions. Google rates INP under 200 milliseconds as good. Worldwide, 77 percent of mobile pages achieve this — among the 1,000 most-visited websites, however, only 53 percent. High-traffic sites with complex JavaScript logic often have INP problems that remained invisible under the old FID metric.
Cumulative Layout Shift (CLS) measures visual stability. Does content jump around during loading because images, ads, or fonts insert themselves retroactively? CLS under 0.1 is considered good. CLS is the easiest of the three metrics to solve, because it largely traces back to structural specifications: images need width and height attributes, ad slots need reserved heights, fonts need font-display strategies.
These three metrics have been part of Google's "Page Experience" ranking signal since 2021. They do not replace content relevance and they do not replace backlink authority — but they are an independent ranking signal that tips the scales when sites are otherwise comparable. Google itself phrases it this way: "If you have similar content to a competitor, performance can make the difference in ranking."
Why most sites fail — three architectural anti-patterns
Anyone who runs a Lighthouse audit on an average marketing site regularly sees scores between 40 and 70 in the Performance dimension. The temptation is great to react directly to the Lighthouse recommendations — compress images, minify JavaScript, activate browser caching. This detail optimization falls short in most cases, because the actual problems lie further upstream: in the architecture, in the fundamental build decisions of the site.
Three architectural anti-patterns dominate in practice.
First, missing server-side rendering with JavaScript frameworks. A modern React or Vue site that renders exclusively client-side initially sends an almost empty HTML shell and then loads the JavaScript bundle. Only after the download, parse, and execute of the JavaScript file does the actual rendering begin. This shifts LCP and FCP by seconds — on mobile with slow connections often to 5 to 8 seconds. Server-side rendering or static site generation solve this fundamentally: the HTML content is already in the first response, the JavaScript bundle subsequently hydrates the page for interactivity.
Second, monolithic JavaScript bundles without code splitting. When every page loads the entire application JavaScript — including code for blog articles, contact form logic, analytics pipelines, third-party integrations — the homepage is artificially slowed down. Current Calvarius experience from our own optimization iteration: a seemingly harmless import in the site-wide navigation component pulled the entire blog pipeline with markdown parser, YAML library, and all pre-rendered articles as static strings into the main bundle. The result: 1.1 megabytes of JavaScript on every page, even when the user never opens a blog article. Clean code-splitting architecture reduces this to 400 kilobytes or less — three quarters of the volume is loaded lazily, when actually needed.
Third, unoptimized image pipelines. Images are statistically the most common performance lever — and at the same time the most frequently overlooked. A typical marketing site loads 1 to 2 megabytes of image data on first homepage visit, because logos, hero images, and section illustrations are delivered without modern formats, without responsive srcSet, without lazy loading. From the Calvarius optimization: 18 logo images in the marquee slider component delivered over one megabyte of image data, at a display size of 200 by 72 pixels and original resolutions of 1000 by 500 — a fivefold oversizing. WebP conversion plus srcSet plus lazy loading reduces this to 80 to 120 kilobytes. Factor ten less, optically indistinguishable.
These three anti-patterns are cumulative. They do not act individually but reinforce each other. A site with client-side rendering plus monolithic bundle plus unoptimized images produces LCP values of 5 to 10 seconds and Performance scores between 30 and 50. Detail optimization cannot repair this. Architecture correction can.
Performance as SEO discipline — Google's Core Web Vitals in ranking
The direct correlation between Core Web Vitals and Google ranking has been part of the official ranking factors since 2021 through the Page Experience Update. What has changed since then: Google measures more strictly, evaluates more consistently, and the weighting in the algorithm has grown.
Current study data show the economic effect. A Vodafone study from 2024 documented: an LCP improvement of 31 percent led to a 15 percent better lead-to-visit rate and 8 percent higher sales figures. A Deloitte-Google study from 2020 showed: an improvement in mobile loading time of just 0.1 seconds increased conversion rates in retail by 8.4 percent and the average order value by 9.2 percent.
The data on abandonment probability are equally clear. A Pingdom analysis from 2025 showed: 53 percent of mobile users in the US abandon their visit when a page takes longer than 3 seconds to respond. Akamai data documents: an increase in loading time from 2 to 3 seconds reduces conversion rates by 7 percent. On mobile sites that load in 1 second, revenue per user is 2.5 times higher than on sites that take 5 seconds.
This data shows a mechanism that goes far beyond pure Google ranking. Performance affects ranking directly, because Google uses Core Web Vitals as a signal — and indirectly, because faster sites produce lower bounce rates and higher engagement values, which in turn act as behavioral ranking signals. Those who optimize performance do not optimize a detail. They optimize the foundation of their entire organic visibility.
Accessibility is not a compliance topic. It's reach.
Since 28 June 2025, the European Accessibility Act (EAA) has been fully in force across the European Union. It obliges companies to design their digital products and services accessibly. In Germany, the EAA is implemented as the Barrierefreiheitsstärkungsgesetz (BFSG); other EU member states have analogous national implementations. The legal requirements orient themselves to WCAG 2.1 at Level A and AA, with urgent recommendation of the stricter WCAG 2.2.
The compliance obligation is real. Violations risk fines, cease-and-desist orders, consumer lawsuits. Certain micro-enterprises with fewer than 10 employees and under 2 million euros in annual revenue are exempt from parts of the obligation — but the online shop obligation applies to practically all B2C companies.
More important than compliance is the economic argument. About 15 to 20 percent of the population in industrialized countries has impairments that, without accessibility, make the use of digital offerings difficult or impossible — from permanent impairments like vision impairment or motor limitations to situational impairments like operating a smartphone with one hand. Those who forgo accessibility forgo up to one-fifth of their potential reach.
Plus: accessible sites are demonstrably better indexable. Correct semantic HTML structure, meaningful alt texts, clear heading hierarchies — these are exactly the structures Google uses to understand content. Accessibility is not a cost center next to SEO. It is part of SEO architecture.
Calvarius brings its mandate sites methodically into WCAG 2.2 AA conformance — not as a retrofitted layer, but as an integral part of build decisions. Touch target sizes from 48 pixels, color contrasts above 4.5:1, semantic heading structure, full keyboard navigation, ARIA attributes only where HTML semantics is insufficient. This discipline is part of every Calvarius mandate, not optional add-on.
Methodical discipline in optimization — lessons from our own practice
The Calvarius site itself was the scene of a methodical optimization iteration over several weeks. The score began at 77, fell intermittently to 68, rose to 89, fluctuated between 76 and 89 across multiple audits, and finally reached a stable 99. This volatility is methodically instructive, because it shows where typical performance optimization fails.
Four discipline points proved decisive — points that have since been standard in every Calvarius mandate practice.
First, incremental approach instead of multi-measure stacking. The score decline from 77 to 68 occurred when six optimization measures were implemented simultaneously — font optimization, CSS reorganization, slider refactor, vendor chunk splitting, image srcSet preparation, tree-shaking audit. When the score fell, it was impossible to attribute which of the six measures had caused the regression. The consequence: blind rollback of all measures, then incremental re-implementation. One measure, one audit, then next measure. This discipline slows the individual iteration but substantially accelerates the overall result.
Second, cross-check diagnosis before intervention. In one diagnostic round, it was claimed that the slider CSS component was completely missing from the code. In fact, it existed at a different location than searched — the original search command had not correctly captured the class names. Had the optimization reacted blindly to the supposedly missing CSS and written new classes, 140-pixel-high logo cards would have been exchanged for 56-pixel bare images — a fundamental design change without performance justification. The methodical lesson: cross-check every diagnostic claim with file inspection before code interventions follow.
Third, architectural proof beats score value. After bundle optimization with dynamic imports, an intermediate audit showed a score decline from 89 to 77 — with simultaneously verified bundle reduction. The symptom profile — simultaneous increase in FCP and LCP at smaller JavaScript volume — was architecturally impossible as a consequence of the measure. The diagnosis: cold edge cache hit after deployment, a Cloudflare-typical artifact. Multi-run median over 3 to 5 audits showed the stable value at 89, not at 77. Lighthouse variance can span 15 or more points with cold CDN caches — individual values are methodically not robust enough for optimization decisions.
Fourth, image payload is the most common performance lever. The largest single improvement in the entire iteration sequence did not come from JavaScript optimization or rendering architecture — but from the WebP conversion of the 18 logo images in the marquee slider. 1,057 kilobytes of JPG payload became 80 to 120 kilobytes of WebP payload, the score jumped from 68 to 89. In statistical evaluations across many audits, it becomes clear: image optimization is the largest performance lever in 60 to 70 percent of cases — before JS bundle size, CSS optimization, or font loading. Those who optimize performance must first check the image pipeline.
Economic significance — what 99 versus 75 means for conversion and ranking
The difference between a Lighthouse score of 99 and one of 75 is not academic. It is economically measurable — in conversion rates, in organic visibility, in bounce rates.
Three economic effects are quantifiable.
Direct conversion effect. The Amazon study from 2006 — confirmed since then over several decades multiple times by Walmart, Mobify, Trainline, Zalando — shows: 100 milliseconds faster loading time increases revenue by 1 percent. A site that reduces its LCP from 2.5 seconds to 1.5 seconds can expect 8 to 10 percent higher conversion rates. For a mid-sized online shop with 2 million euros annual revenue, that corresponds to 160,000 to 200,000 euros additional annual revenue, solely through performance optimization.
Indirect SEO effect through behavioral signals. Sites with better Core Web Vitals have lower bounce rates — bounce probability increases by 32 percent when loading time grows from 1 to 3 seconds, and by 90 percent between 1 and 5 seconds. Lower bounce rates and higher dwell times are behavioral signals that Google factors into ranking. That is a self-reinforcing mechanism: fast site, better user signals, better ranking, more traffic, more conversions.
Direct ranking effect through Core Web Vitals. For competitive search queries where multiple providers have similarly relevant content, Page Experience decides the order in search results. A site with green Core Web Vitals (LCP under 2.5s, INP under 200ms, CLS under 0.1) has structurally better ranking chances than a site with yellow values — with otherwise identical content quality. That is not a 1:1 effect but a co-weighting in the algorithm that can tip decisions when close.
These three effects accumulate. A performance optimization from score 75 to score 99 is not a "nice to have" — it is a substantial lever on revenue, visibility, and long-term competitive position.
What is different about Calvarius mandates
Performance optimization is treated in most agency practices as a downstream step: build site, launch, then optimize. This sequence is methodically the core of the problem. Architectural performance decisions — server-side rendering, code splitting strategy, asset pipeline, image pipeline, font loading — must stand at the beginning of a project, not at the end.
Calvarius works methodically differently. Three disciplines are standard in every mandate, not add-on.
Performance-by-design. Already in the architecture phase, build decisions are made under performance aspects. Which framework? Which hosting stack? Which CDN strategy? Which image pipeline? These decisions are barely correctable later — and they decide the performance potential of the entire site. Calvarius chooses stacks like TanStack Start with full SSR, Cloudflare as edge layer, vite-imagetools for the image pipeline, variable fonts with correct fallback metrics. These decisions are made before the first pixel, not after the launch.
Methodical audit discipline. Lighthouse audits are not run as a score game, but as methodical diagnosis. Multi-run median instead of individual values. Incremental optimization with audit between each measure. Architectural proof for unclear findings. This discipline prevents the very common anti-pattern in practice that sites show 95 in one audit run but in practice produce substantially weaker values through CDN volatility, edge cache effects, and real user devices.
Accessibility as architecture question. Touch targets, color contrasts, semantic HTML structure, keyboard operability — these are not retrofitted corrections, but design system decisions. The Calvarius site sets touch targets by default to 48 pixels, uses a central ContactLink component for phone and email links with correct padding, ensures semantic heading structure in every pillar article. WCAG 2.2 AA is standard, not goal.
The economic consequence: Calvarius mandate sites reach typical Lighthouse values between 90 and 99 in all four dimensions — not through retroactive audit optimization effort, but through build decisions at the beginning. This excludes lengthy and expensive re-optimization phases.
Practice checklist — seven points every site owner should check
Anyone who runs a Lighthouse audit of their own site and sees an orange or red-dominated donut chart can gain a first methodical overview with the following seven check points.
First, server-side rendering active? View Source on the homepage. If the HTML body is practically empty and contains only a <div id="root">, the site is running client-side — that is the largest performance lever. SSR or static generation are the structural answer.
Second, image pipeline optimized? Network tab in the browser, filter on image requests. Calculate total transfer size of all images on initial load. If that lies above 500 kilobytes, image optimization is the likely largest lever. WebP conversion, srcSet for responsive delivery, lazy loading for below-the-fold images.
Third, JavaScript bundle size acceptable? In the Network tab, find the largest JS bundle. For static marketing sites, 80 to 150 kilobytes gzip should serve as guideline. Over 300 kilobytes gzip is oversized. Diagnosis via npx vite-bundle-visualizer or similar tools — what is in the bundle?
Fourth, fonts properly embedded? Google Fonts via fonts.googleapis.com produce render-blocking requests. Self-hosted variable fonts with preload and correct fallback font metrics are methodically cleaner and faster. Plus: include separate italic font cuts instead of rendering synthetic italic via CSS slant.
Fifth, cache headers set? Self-hosted assets — fonts, images, JS bundles — should receive Cache-Control: public, max-age=31536000, immutable headers. Lighthouse report "Use efficient cache lifetimes" shows where cache headers are missing. Cloudflare headers file or server middleware solve this in under an hour.
Sixth, check touch targets? On mobile, test all interactive elements. Lighthouse accessibility shows under "Touch target areas" specifically where targets are too small. 48 by 48 pixels is the Lighthouse recommendation, 24 by 24 pixels the WCAG 2.5.8 minimum.
Seventh, run multi-run audit. Individual Lighthouse values are not robust — variance between audits can span 15 or more points. Three to five audits via pagespeed.web.dev with 60 seconds pause each. Take median, not individual value. If variance over 7 points: edge cache problem, separate diagnosis needed.
Want to check your own site?
Calvarius offers a free Lighthouse live check that runs directly through the Google PageSpeed Insights API. You enter a URL, the tool runs an audit and shows you the four Lighthouse scores plus Core Web Vitals plus three concrete improvement levers in our methodical assessment — the same values you saw at the beginning of this article for calvarius.com itself, but for your site.
This article is part of the Calvarius pillar series on SEO and web performance. Related articles: Lovable, TanStack Start, and the SEO question · FAQ schema after Google's May 2026 abolition.