Page Speed and SEO: What Actually Moves Rankings

Page speed as Google measures it is not a single number. It is a bundle of Core Web Vitals metrics (LCP, INP, CLS) plus a set of secondary signals (First Contentful Paint, Time to Interactive, Total Blocking Time) that feed into the Page Experience signal cluster. The composite influences ranking modestly on its own and dramatically as a behavioral proxy - fast pages retain visitors, and retention is the signal that really moves rankings.

The measurement source is field data from Chrome users (via the Chrome User Experience Report), not lab data from Lighthouse. This distinction matters. A lab-fast page that is field-slow (due to a slow CDN in a specific geography, for example) is a field-slow page from Google's ranking perspective.

The threshold for the good/needs-improvement/poor buckets is 75th percentile. If 75 percent or more of your real Chrome users experience a metric in the 'good' zone, the page is good. If not, it is not. Optimizing for the median is not enough - the tail matters.

Across our audit database, images account for 60 to 80 percent of average page weight. They are also the most compressible content type - modern formats (AVIF, WebP) achieve 30 to 50 percent size reductions over JPEG at equivalent visual quality. Adopting AVIF/WebP as the default format is usually the single highest-impact speed change any site can make.

Responsive images (srcset) serve smaller versions to smaller devices. A mobile user does not need a 2400px hero image; serving one wastes their bandwidth and blocks their LCP. Every image tag should have srcset and sizes attributes matching the layout's actual rendering widths.

Lazy loading (loading='lazy') defers below-the-fold images until the user scrolls near them. It is now a native browser attribute - no library needed. The exception is the largest above-the-fold image (usually the hero), which should be preloaded and never lazy-loaded because it determines LCP.

The average site loads 15 to 30 third-party scripts: analytics, tag managers, chat widgets, A/B testing tools, session replay, ad scripts, social embeds, and more. Each script runs on the main thread by default, blocking interactions. Cumulative blocking time from third parties often exceeds all first-party JavaScript combined.

Audit third parties quarterly. For each script, ask: does this drive a decision worth its speed cost? Chat widgets that generate two support tickets a month for a $50k performance cost are not worth it. Session replay tools that record 100 percent of sessions for a marketing decision that could be made from a 5 percent sample are not worth it.

For scripts you cannot remove, move them off the main thread. Partytown wraps most third-party scripts in a Web Worker where they run without blocking user interaction. Not every script is compatible, but the ones that are usually cut INP by 30 to 60 percent with no other changes.

Every optimization on top of a slow server hits a ceiling. If TTFB is 800 milliseconds, LCP cannot be under 2.5 seconds no matter how optimized the HTML and images are. Fixing server response time is the prerequisite for the rest of the optimization stack to matter.

The three levers for server response time: cache at the edge, locate the origin near your users, and pre-render where possible. Cloudflare, Fastly, and Vercel Edge cache static or near-static content at hundreds of PoPs worldwide, cutting TTFB from hundreds of milliseconds to tens. Static site generation removes the origin from the equation entirely.

For dynamic content that cannot be cached, database query optimization is the usual bottleneck. Any query taking longer than 100 milliseconds should have an index added or be denormalized into a cached read model. Slow databases masquerade as slow servers, and the fix is at the query level, not the server level.

Every synchronous stylesheet in the head blocks paint until it downloads and parses. Every synchronous script in the head blocks parsing until it downloads and executes. The default for every render-blocking resource should be to inline the critical portion and defer the rest.

Inline critical CSS for above-the-fold content directly in the head as a style tag. Defer the full stylesheet with a media='print' onload='this.media=all' trick, which downloads it non-blockingly and applies it once loaded. This pattern cuts LCP by hundreds of milliseconds on typical sites.

For JavaScript, use type='module' for modern browsers (which supports native ES modules and improves parsing efficiency) and add defer or async to every non-critical script. defer preserves execution order and waits for HTML parsing to complete; async fires as soon as the script downloads regardless of order. Pick defer unless the script must run before HTML fully parses.

Web fonts routinely add hundreds of milliseconds to LCP if loaded incorrectly. The default browser behavior (block text rendering until the font loads, or 'FOIT') is the worst option. Use font-display: swap (show fallback immediately, swap to web font when loaded) or font-display: optional (never swap after initial paint) to eliminate the block.

Preload critical fonts with a link rel='preload' tag in the head. This starts the font download in parallel with the HTML parse rather than waiting for CSS to reference it. For the hero font, preloading typically saves 200 to 400 milliseconds of LCP.

Subset fonts to include only the characters you actually use. A full-glyph font can be 200KB or more; a subset targeting Latin characters and punctuation is often 30KB. For sites in a single script, subsetting is a free 60 to 80 percent font weight reduction.

Lighthouse gives you a score. Chasing that score is a trap. A 100/100 Lighthouse score on a page that field-tests at 5-second LCP is not a fast page - it is a page that passes a simulated test but fails real users. Focus on field data (CrUX, RUM) and treat Lighthouse as a diagnostic hint, not a target.

Common Lighthouse-vs-field discrepancies: Lighthouse simulates a mid-tier mobile device on 4G; real users may be on lower-end devices or 3G in some markets. Lighthouse tests from a fixed location; real users are worldwide. Lighthouse tests with no third-party scripts blocked; real users experience the full script cost.

The workflow: use Lighthouse for identifying specific optimizations (this JavaScript file is unused, this image is uncompressed) and CrUX/RUM for confirming those optimizations actually moved the field metrics. Any optimization that improves Lighthouse but does not improve CrUX is not helping real users.