Page Speed: Diagnose LCP, TTFB, Render-Blocking & CWV

Page speed is now both a ranking factor and a conversion factor — Google uses Core Web Vitals as a tiebreaker between otherwise equal pages, and every 100ms of additional latency costs measurable conversions. The Page Speed Analyzer runs Lighthouse and CrUX field data against any URL, surfaces the specific bottlenecks, and gives you a remediation order. This guide covers every metric the analyzer reports, what each means, and how to fix the failures in priority order.

Lab data vs field data

Page speed comes from two distinct data sources, and they tell you different things:

Lab data (Lighthouse)Single-run synthetic test from a controlled lab environment. Reproducible, diagnostic, but doesn\'t reflect real user experience.

Field data (CrUX)28-day rolling average of real Chrome user visits. Reflects actual user experience. What Google uses for ranking.

You optimise against lab data; you\'re judged on field data. Lab improvements take 28 days to fully reflect in field metrics, so don\'t panic if field data lags lab improvements by several weeks.

💡 Field data is only reported for sites with sufficient Chrome user volume — typically 1000+ monthly visits to a URL. Smaller sites get only lab data and must extrapolate.

The Core Web Vitals trio

Largest Contentful Paint (LCP)

Time from navigation start until the largest above-the-fold element is rendered. Google\'s benchmark: good < 2.5s, needs improvement 2.5-4.0s, poor > 4.0s. LCP is usually the hardest CWV to fix because it touches everything — hosting, TTFB, render-blocking resources, image sizes, the actual LCP element\'s priority.

Interaction to Next Paint (INP)

Replaced FID in March 2024. Measures the latency of all user interactions during a visit (clicks, taps, key presses), reporting the 75th-percentile experience. Good < 200ms, poor > 500ms. Driven mainly by JavaScript main-thread blocking — long tasks during interaction handling.

Cumulative Layout Shift (CLS)

Measures unexpected layout shifts during page load and interaction. Good < 0.1, poor > 0.25. Driven by images without dimensions, fonts loading late, ads injecting, dynamic content insertion above already-rendered content. See the CLS Guide for the full debugging workflow.

Supporting metrics

Metric	Good	What it measures
TTFB	< 800ms	Time to first byte from the server
FCP	< 1.8s	First content paint (anything visible)
SI	< 3.4s	Speed Index — visual completeness over time
TBT	< 200ms	Total Blocking Time — sum of long tasks
TTI	< 3.8s	Time to Interactive

The optimisation order

Fix in this order — each step makes the next one easier to measure:

Step 1: Server response time (TTFB)

If TTFB > 800ms, nothing else you do will reach Good CWV. Causes: slow hosting tier, missing CDN, no caching layer, expensive database queries on the homepage, server-side rendering bottleneck. Fix order:

Enable a CDN (Cloudflare, Bunny, Fastly) — typically halves TTFB for global traffic
Add page-level caching — static HTML cache for cacheable routes
Database query review — slow queries on critical paths get indexed or cached
Upgrade hosting tier if you\'re on shared hosting
Move to edge rendering for SSR-heavy sites (Vercel, Cloudflare Workers)

Step 2: Render-blocking resources

CSS and synchronous JS in the <head> block the browser from rendering the page. Audit Lighthouse\'s "Eliminate render-blocking resources" — typical wins:

<!-- Bad: blocks render -->
<link rel="stylesheet" href="/styles/app.css">
<script src="/js/app.js"></script>

<!-- Good: critical CSS inline, rest deferred -->
<style>/* critical above-the-fold CSS inline */</style>
<link rel="preload" href="/styles/app.css" as="style"
      onload="this.onload=null;this.rel='stylesheet'">
<script src="/js/app.js" defer></script>

Step 3: Image weight

Images often account for 60-80% of page weight. Best practices:

Modern formats — AVIF first, WebP fallback, JPEG/PNG last
Responsive images with srcset + sizes
Explicit width/height attributes (also fixes CLS)
Native lazy-loading for below-the-fold: loading="lazy"
LCP image should NOT be lazy-loaded; preload it with <link rel="preload">

Step 4: JavaScript weight

JavaScript bytes downloaded, parsed, compiled and executed all happen on the main thread, all delay interactivity. Audit and reduce:

Code-split routes — load only the JS for the current page
Dynamic imports for off-screen interactivity (chat widget, video player)
Remove unused libraries — check Coverage tab in DevTools
Tree-shake bundlers properly (webpack, esbuild, Vite)
Defer third-party scripts (analytics, ads, support widgets)

Step 5: Third-party scripts

Analytics, A/B testing, chat widgets, ad networks, social embeds — each adds bytes, blocks main thread, and competes for resources. Lighthouse "Third-party usage" tab shows the cost in milliseconds. Decisions:

Audit annually — which scripts justify their performance cost?
Lazy-load chat widgets — most users don\'t open them in the first 30s
Use fetchpriority="low" on non-critical third-parties
Self-host critical analytics where possible
Container tag management (GTM) helps centralise but ALSO adds latency

The 28-day field data lag

Field data is a 28-day rolling average. A change you deploy today shows up gradually over the next 28 days as it dilutes the historical data. Don\'t conclude your changes failed after 7 days; wait the full window. Conversely, a regression deployed today won\'t show its full impact for 28 days.

Mobile vs desktop

Google ranks via mobile-first index — mobile CWV scores matter more than desktop. Lighthouse mobile simulation throttles CPU 4x and network to Slow 4G, which is intentionally pessimistic. Optimise for mobile first; desktop usually follows.

When CWV doesn\'t drive ranking change

CWV is one ranking signal among hundreds. Sites with poor content quality won\'t rank well even with perfect CWV. Sites with excellent content can rank well despite imperfect CWV. Treat CWV as a tiebreaker: get to Good (green) and focus the rest of your effort on content, links and E-E-A-T.

Frequently Asked Questions

What's the realistic timeline to fix poor LCP?

2-12 weeks depending on root cause. CDN + caching wins are deployable in a day and improve TTFB immediately, with field data catching up over 28 days. Render-blocking resource cleanup is a 1-2 week dev effort. Heavy image optimisation pipelines take 2-4 weeks. Fundamental architecture changes (moving off slow SSR, switching frameworks) are 1-6 months. Quick wins exist; structural problems need real investment.

Should I optimise for Lighthouse score or field data?

Both matter, but field data is what ranks you. Lighthouse is diagnostic — it tells you what to fix. Field data is the report card — it tells you whether the fixes worked at user-experience scale. Don\'t chase a Lighthouse score of 100 if your field data is already in the Good range; the marginal returns drop sharply above 90.

Does HTTP/2 / HTTP/3 actually help speed?

Yes, especially HTTP/3 over poor mobile networks. HTTP/2 multiplexes connections so multiple requests don\'t serialise. HTTP/3 uses QUIC which recovers from packet loss faster than TCP. Both are essentially free if your CDN supports them — verify with curl -I --http3 yoursite.com or browser DevTools Network tab.

My TTFB is fine but LCP is bad — what now?

LCP element prioritisation is your next investigation. Use Lighthouse\'s LCP element report — if the LCP element is an image, ensure it has fetchpriority=\"high\" and is preloaded. If it\'s text, ensure web fonts aren\'t blocking it (use font-display:swap or self-host with preload). If the LCP element is below other render-blocking resources in HTML, restructure to prioritise it.

⚡ Analyse your page speed

Run Lighthouse + CrUX field data on any URL. Get prioritised fixes for LCP, INP, CLS and supporting metrics.

Run Page Speed Analyzer →