How to read PageSpeed Insights: field data first, then the score

Judge a URL by the field data at the top of PageSpeed Insights. That section is from real Chrome users over 28 days and decides your Core Web Vitals pass.

The Lighthouse score is a lab run. It is useful for diagnosis, not as a KPI. Scores change between runs. Search does not read them.

• Top: Discover what your real users are experiencing. This is field data from the Chrome User Experience Report. It shows LCP, CLS and INP over 28 days at the 75th percentile. It can be per URL or per origin.
• Bottom: Diagnose performance issues. This is a Lighthouse lab run on a simulated mid-range phone over throttled 4G. It includes the 0 to 100 Performance score and audits.

The two can disagree. Field data wins. Use the audits to plan fixes that move the field metrics for your users, especially on mobile.

1. 1

   Open a report

   Go to pagespeed.web.dev. Paste a full URL like https://yourproduct.com/pricing. Choose Mobile first.

2. 2

   Read the Core Web Vitals assessment

   Pass or Fail is what matters for Search. Note which metric fails and by how much.

3. 3

   Scan the field distributions

   Open LCP, INP and CLS. Note the 75th percentile values. Mobile data is the priority as of 2026.

4. 4

   Use the audits for causes

   Scroll to Opportunities and Diagnostics. Match them to the failing metric. Ignore audits that would not move the field numbers.

Lighthouse runs once on a simulated device and network. Small changes in timing, server load or third-party responses shift the score. That is normal.

Field data aggregates real visits over 28 days. It smooths noise. That is what powers the Core Web Vitals assessment and the reports in Search Console.

Do not chase 100. Aim for a Core Web Vitals pass on your key templates on mobile. Ship changes that keep LCP at or below 2.5 s, CLS at or below 0.1, and INP at or below 200 ms.

LCP is often the hero image or a large headline. Fix server time, image priority and image optimisation. Do not lazy-load the hero. Consider fetchpriority=high on it.

CLS comes from missing width and height, late banners and font swaps. Reserve space for media and UI. Use overlays for notices. Match fallback and web font metrics to avoid jumps.

INP flags slow taps and clicks. Break long tasks. Keep handlers small. Render the visual change first, then do the heavy work. Use web workers where you can.

• Hero image delivery: no loading=lazy, add fetchpriority=high, responsive srcset and sizes, AVIF or WebP, and a CDN. Preload a CSS background hero.
• Server time: reduce TTFB with HTML caching or pre-rendering, HTTP/2 or HTTP/3, and a CDN. Avoid redirect chains.
• Render-blocking resources: inline critical CSS for the above-the-fold view. Load the rest with media=print and onload. Defer scripts or use type=module. Remove @import.
• Web fonts: use font-display swap or optional. Preload the one face used above the fold with crossorigin. Self-host WOFF2. Subset. Consider a system font stack.
• Third-party scripts: remove unused chat, A/B or widgets. Load embeds behind a click with a facade. Defer until after load. Preconnect to a small set of early origins.
• Long tasks and hydration: split work with scheduler.yield or setTimeout. Defer non-visual code. Avoid synchronous layout reads after writes. Keep the DOM smaller.

Example: your /pricing page fails LCP on mobile at 3.6 s. You remove loading=lazy on the hero, add fetchpriority=high and a preload for a CSS background. You cut TTFB with a cache. The field LCP drops under 2.5 s over the next 28 days.

Small pages often lack enough visits for URL-level field data. PageSpeed Insights falls back to origin-level data. If even that is missing, it shows only lab data.

• If you see origin data, fix shared issues first. Templates and global assets move the origin.
• If you see no field data, use Lighthouse audits to make sensible changes. Then watch Search Console’s Core Web Vitals report for the origin as traffic grows.
• Mobile-first indexing is complete. Prioritise the Mobile tab and your mobile field data.

1. 1

   Identify the failing metric

   Start with the field assessment on Mobile. Note LCP, INP or CLS and the 75th percentile value.

2. 2

   Find the page’s bottleneck

   Map each failing metric to two or three likely causes in the audits. Keep the causes that match your page’s structure.

3. 3

   Estimate impact versus effort

   Pick items that would move the field metric on many templates. Example: font preload beats a tiny JS micro-optimisation.

4. 4

   Batch by template

   Fix shared layout and assets across /, /pricing, /blog and /guides/*. One release, many pages improved.

5. 5

   Ship and measure

   Release. Then wait for the 28-day window to reflect the change. Track the Core Web Vitals report in Search Console.

A clean backlog fits on one page. Ten items or fewer. Each item states the target metric, the change, the scope and the owner. Example: Reduce CLS under 0.1 on / and /pricing by adding explicit width and height to all images and reserving space for the cookie banner.

• Opportunities estimate savings in seconds for the lab run. Use them to spot causes, not as goals.
• Diagnostics list facts. Prioritise render-blocking resources, large payloads, long main-thread tasks and third-party impact.
• The Performance score weights Total Blocking Time 30%, LCP 25%, CLS 25%, First Contentful Paint 10% and Speed Index 10%. TBT is a lab proxy for INP.
• Some audits will not apply to your stack. It is fine to ignore an audit that would not move your field LCP, CLS or INP.

Example: Lighthouse flags Reduce the impact of third-party code. You remove an unused survey widget and delay your video embed behind a click. Your field INP improves and the lab TBT drops.

Googlebot uses the smartphone crawler. Search Console shows mobile Core Web Vitals first. Fix mobile first. It is usually the slower path anyway.

Desktop matters for users too. Check both tabs. Ship wins that help both, like TTFB, image delivery, font loads and third-party control.

• First Contentful Paint: good up to 1.8 s, poor above 3 s. Often limited by render-blocking CSS and TTFB.
• Time to First Byte: good up to 0.8 s, poor above 1.8 s. Improve with caching, a CDN and fewer redirects.
• Total Blocking Time: good up to 200 ms in lab. Cut long main-thread tasks and heavy scripts. This often aligns with INP gains.

Use these as supporting goals. They help explain why your LCP or INP is slow and suggest the fix. Do not treat them as ranking signals on their own.