From 90 to 100: The Engineering Behind Perfect Lighthouse Scores

Google Ads uses Quality Score to determine your ad placement and cost per click. Quality Score is built from three components: expected click-through rate, ad relevance, and landing page experience. Research indicates landing page experience accounts for approximately 39% of the Quality Score calculation.

Landing page experience is evaluated based on several factors: how useful and relevant your content is, ease of navigation, page load speed, and mobile-friendliness. Google considers a slow load time as "regional average plus three seconds." For mobile specifically, Google scores landing page speed on a 1-10 scale.

The mathematics of Google Ads means that Quality Score has an outsized effect on what you actually pay. Your actual CPC is calculated as: (Ad Rank of the advertiser below you ÷ Your Quality Score) + $0.01. This means a higher Quality Score directly reduces your costs.

Industry benchmarks show the impact at different Quality Score levels compared to the baseline of 5:

Real-world case studies have documented 20–25% reductions in cost per click after improving landing page performance. One fitness brand improved their Quality Score from 6 to 9 and saw CPC drop from $3.50 to $2.45 — a 30% reduction. A utility company improved Quality Score from 6.5 to 8.9 over six years, resulting in estimated savings of $1.5 million on CPC alone.

For businesses spending thousands on ads monthly, this translates to significant savings or significantly more reach for the same budget.

Google measures how users interact with your site after clicking a search result. High bounce rates and short time-on-site signal that users didn't find what they were looking for — or that the experience frustrated them.

The data on bounce rates is clear. Google's research shows that as page load time increases from 1 to 3 seconds, the probability of bounce increases by 32%. From 1 to 5 seconds, bounce probability increases by 90%. From 1 to 10 seconds, it increases by 123%.

BBC found that for every additional second a page takes to load, 10% of users leave. Akamai research shows a 2-second delay increases bounce rates by 103%.

Fast, stable pages keep users engaged longer. Desenio achieved a 37% lower bounce rate, 48% longer sessions, and 34% better conversions after optimizing Core Web Vitals in 2024. Rakuten 24 saw a 53% increase in revenue per visitor after similar improvements. Pingdom's data shows sites loading in 1 second have a 7% bounce rate, while 5-second sites have 38%.

These engagement signals — bounce rate, time on site, pages per session — influence how Google perceives your content quality, which affects rankings over time.

Research consistently shows that page speed affects conversions. The "Milliseconds Make Millions" study by Google and Deloitte, analysing 30 million user sessions across 37 brand sites, found that a 0.1 second (100ms) improvement in load time resulted in:

• Retail: 8.4% increase in conversions and 9.2% increase in average order value
• Travel: 10.1% increase in conversions
• Luxury: 8.6% more page views per session

Portent's analysis of 27,000 landing pages found conversion rates drop 4.42% with each additional second of load time between 0-5 seconds. E-commerce sites loading in 1 second achieve a 3.05% conversion rate; at 5 seconds, that drops to 1.08%. B2B sites loading in 1 second convert 3x higher than 5-second sites, and 5x higher than 10-second sites.

The famous Google/SOASTA research found that 53% of mobile site visitors leave a page that takes longer than 3 seconds to load.

On mobile — where most users browse — the impact is even larger because mobile CPUs are 4–6x slower than desktop. Lighthouse applies 4x CPU throttling by default for mobile simulation. Research by Alex Russell shows budget Android phones can be more than 4.25x slower than leading iPhones, with the gap widening each year.

A site that feels instant builds trust. A site that hesitates loses visitors before they even see your content.

Here's the reality: most of your competitors aren't optimising for this.

When the typical Norwegian website scores 60–70, and excellent sites reach 90, pushing to 100 creates a measurable gap. Your pages load faster, rank better, cost less to advertise, and convert more visitors.

This isn't about chasing perfect scores. It's about recognising that most businesses leave this opportunity untouched.

The Performance score measures how quickly your page loads and becomes interactive. Lighthouse 10+ calculates this using five weighted metrics:

Largest Contentful Paint (LCP) measures when the largest content element becomes visible. Good: ≤2.5 seconds. Poor: >4 seconds.

Interaction to Next Paint (INP) replaced First Input Delay in March 2024 as a Core Web Vital. It measures responsiveness to user interactions. Good: ≤200ms. Poor: >500ms. In lab testing, Lighthouse uses Total Blocking Time (TBT) as a proxy since INP requires real user interactions.

Cumulative Layout Shift (CLS) measures visual stability — how much content shifts unexpectedly during loading. Good: ≤0.1. Poor: >0.25.

First Contentful Paint (FCP) measures when the first content appears. Good: ≤1.8 seconds. Poor: >3 seconds.

A score of 90 puts you in approximately the top 8% of websites. A score of 100 puts you in the top tier of web performance.

Accessibility checks whether your site works for everyone — including users with screen readers, keyboard navigation, or visual impairments.

Lighthouse uses the axe-core library for automated accessibility testing. However, automated tools can only detect approximately 30-40% of WCAG issues. A score of 100 does not mean full accessibility — it means you've passed the automated checks. Manual testing with actual screen readers and keyboard navigation remains essential.

Key areas tested include image alt text, colour contrast ratios, form labels, ARIA attributes, heading structure, focus indicators, and tap target sizes.

Best Practices catches security issues, deprecated APIs, and general technical hygiene that affects long-term maintainability. This includes HTTPS usage, absence of console errors, proper image aspect ratios, and valid source maps.

SEO verifies that search engines can properly crawl, index, and understand your content. Lighthouse checks for meta descriptions, valid robots.txt, proper viewport configuration, legible font sizes, and descriptive link text.

Note that a Lighthouse SEO score of 100 doesn't guarantee good rankings — it confirms the technical foundations are in place for search engines to do their job.

Images are often the largest resources on a page. On the median page, images account for more transferred bytes than any other resource type. The key is providing multiple sizes and letting the browser choose the most appropriate one.

Only load JavaScript when it's needed. Components that aren't visible on initial page load should be lazy-loaded. This is particularly important because JavaScript has a double cost: download time and execution time.

On mobile devices, JavaScript execution is where the real performance tax hits. A budget Android phone might take 4-6 times longer to parse and execute the same JavaScript as a high-end device. HTTP Archive data shows mobile pages at the 75th percentile have nearly 3 seconds of blocking time; at the 90th percentile, nearly 6 seconds.

With SSR, the initial HTML arrives fully rendered. Users see content immediately instead of watching a blank screen while JavaScript loads. This directly improves both First Contentful Paint and Largest Contentful Paint.

The trade-off is server processing time and hydration complexity. The server must render the page before sending it, and the client must "hydrate" the HTML with JavaScript to make it interactive. Done well, this provides the best of both worlds: fast initial content with full interactivity. Done poorly, it can cause layout shifts during hydration or delay interactivity.

Above-the-fold styles embedded directly in the HTML eliminate render-blocking CSS requests. The browser can paint the initial view without waiting for external stylesheets to download.

This requires identifying which styles are needed for the first view and inlining only those. The rest of the CSS loads asynchronously. Tools like Critical or Critters automate this extraction, but the principle is simple: don't make users wait for CSS they don't immediately need.

Custom fonts can cause invisible text (FOIT) or layout shifts (FOUT) if not handled carefully. The recommended approach:

1. Preload critical fonts — Tell the browser to fetch them early
2. Use font-display: swap — Show fallback text immediately, swap when the font loads
3. Use WOFF2 format — Modern compression, wide browser support
4. Subset fonts — Include only the characters you actually use

A well-optimised font strategy prevents both invisible text and jarring shifts when fonts load.

preconnect establishes early connections to domains you'll need, eliminating DNS lookup, TCP handshake, and TLS negotiation from the critical path. Use it for CDNs, font providers, and API endpoints.

preload fetches specific resources you know you'll need soon. Use it sparingly for critical resources that might otherwise be discovered late — fonts referenced only in CSS, for example.

Lighthouse tests approximately 30-40% of WCAG success criteria using automated checks. Passing these is necessary but not sufficient for true accessibility.

WCAG AA requires specific contrast ratios:

• Normal text (smaller than 18pt or 14pt bold): 4.5:1 minimum
• Large text (18pt/24px or larger, or 14pt/18.5px bold): 3:1 minimum
• UI components and graphics: 3:1 minimum

These are threshold values — 4.49:1 does not meet the 4.5:1 requirement. No rounding. The ratios compensate for contrast sensitivity loss equivalent to 20/40 vision, typical at approximately age 80.

This affects readability for everyone: mobile screens in sunlight, cheap monitors with poor colour reproduction, and tired eyes at the end of a long day.

Every interactive element needs a visible focus indicator. Tab order should follow logical reading order. This is non-negotiable for keyboard users.

WCAG 2.2 adds specific requirements: focused elements cannot be completely obscured by other content (2.4.11 Focus Not Obscured), and interactive targets must be at least 24×24 CSS pixels (2.5.8 Target Size Minimum).

Proper heading hierarchy using <h1> through <h6> provides document structure. Landmark regions (<header>, <nav>, <main>, <footer>) let screen reader users jump to sections. Descriptive link text explains where links go — "Read the full report" rather than "click here."

Respecting prefers-reduced-motion for users who experience motion sickness or vestibular disorders. Animations should be subtle anyway, but for these users, they should be reduced or eliminated entirely.

Heading hierarchy — Use one <h1> as the main page headline, with logical <h2>/<h3> structure. Google's John Mueller has confirmed that multiple H1 tags don't negatively affect SEO, but a clear hierarchy helps both users and search engines understand content structure.

Metadata — Unique titles (50-60 characters to avoid truncation) and descriptions (150-160 characters for desktop, front-load key information for mobile). Meta descriptions aren't a ranking factor, but they affect click-through rates. Google rewrites them approximately 63% of the time if they don't match the search query well.

Canonical URLs — Self-referencing canonicals on all indexable pages. Use absolute URLs. Common mistakes include pointing canonicals to 404 pages, content mismatch between pages, and multiple canonical tags (which causes all to be ignored).

Mobile-first indexing — As of July 2024, all sites are crawled exclusively with Googlebot Smartphone. Content that isn't accessible to mobile devices isn't indexed. Mobile and desktop must have identical content, meta tags, structured data, and headings.

Structured data — JSON-LD format for rich results. Active types include Article, Product, Event, Organisation, and Local Business. Note that FAQ structured data is now only shown for authoritative government and health websites (since August 2023).

Clean robots.txt and up-to-date sitemap — The sitemap should only include canonical URLs. Remember that robots.txt blocks crawling, not indexing — if you want to prevent a page from appearing in search, use noindex, not robots.txt.

All resources over HTTPS — Mixed content warnings affect both security perception and actual security.

No deprecated APIs or console errors — Browser APIs get deprecated. Code that relies on them eventually breaks.

Images at natural aspect ratios — Stretched or squished images fail this audit.

Valid source maps — Enables debugging production issues without exposing unminified code.

Sites with clean technical foundations age better. Browser updates don't break functionality. Security scanners don't flag issues. Technical debt accumulates slowly instead of quickly.

Rocket Loader defers all JavaScript until after the page renders by rewriting your HTML. For server-side rendered applications, this breaks hydration timing and causes visible layout shifts. React and Next.js applications report consistent issues with Rocket Loader: broken functionality, images failing to load, and hydration errors. If you're using SSR, disable Rocket Loader entirely.

Auto Minify was deprecated in August 2024. It was redundant if your build pipeline already minifies (it should), and it could break source maps and Subresource Integrity hashes. Cloudflare recommends minifying at build time instead.

Mirage is being deprecated in September 2025. It lazy-loads images via JavaScript injection. Native loading="lazy" does the same thing without adding script overhead or complexity. Cloudflare explicitly recommends transitioning to native lazy loading.

Brotli compression delivers 15–25% smaller files compared to gzip for text resources like HTML, CSS, and JavaScript. Brotli has a built-in dictionary of common web terms that gives it an advantage on typical web content. It's slightly slower to compress but at least as fast to decompress.

HTTP/3 provides faster connection establishment, especially on mobile networks. HTTP/3 uses QUIC, which combines the TCP handshake and TLS negotiation into a single step and supports 0-RTT connection resumption. Real-world benchmarks show 12% faster time-to-first-byte on average, with more dramatic improvements on lossy mobile connections — up to 55% faster under 15% packet loss conditions.

Early Hints (HTTP 103) lets browsers start loading resources before the server finishes generating the response. While your server is doing database queries and rendering templates, the CDN sends hints about CSS, fonts, and other resources the browser will need. Benchmarks show 15-30% improvements in LCP. Shopify reported 500ms faster LCP at the 50th percentile in production.

Aggressive caching for versioned static assets (files with hashes in their names), with cache bypass for dynamic content. Static assets with versioned filenames can be cached indefinitely — when the file changes, the filename changes.

The best CDN configuration is invisible. It accelerates delivery without modifying your optimised code.