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

Read the field data first. That is what Google uses for ranking. Then use the Lighthouse score and audits to find what to fix. This guide is for founders who ship their own site.

Updated 2026-09-14 · Source: https://porteur.ai/guides/how-to-read-pagespeed-insights

## Field data beats 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.

> Never optimise for the Lighthouse score alone. Search uses field data from real users.

## The two halves of PageSpeed Insights

- 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. **Open a report** Go to pagespeed.web.dev. Paste a full URL like https://yourproduct.com/pricing. Choose Mobile first.
2. **Read the Core Web Vitals assessment** Pass or Fail is what matters for Search. Note which metric fails and by how much.
3. **Scan the field distributions** Open LCP, INP and CLS. Note the 75th percentile values. Mobile data is the priority as of 2026.
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.

## Why scores change and why it does not matter

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.

## How to read the Core Web Vitals

| Metric | What it measures | Good | Poor | Notes |
| --- | --- | --- | --- | --- |
| Largest Contentful Paint (LCP) | Time to paint the largest above-the-fold element | ≤ 2.5 s | > 4 s | Delayed by TTFB and slow hero images |
| Cumulative Layout Shift (CLS) | Unexpected visual movement | ≤ 0.1 | > 0.25 | Measured in session windows without user-triggered shifts |
| Interaction to Next Paint (INP) | Worst interaction latency in a visit | ≤ 200 ms | > 500 ms | Replaced FID. Includes input, processing and presentation |

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.

## Opportunities that pay on a product site

- 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.

## When a URL shows no field data

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.

## From a report to an ordered list of changes

1. **Identify the failing metric** Start with the field assessment on Mobile. Note LCP, INP or CLS and the 75th percentile value.
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. **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. **Batch by template** Fix shared layout and assets across /, /pricing, /blog and /guides/*. One release, many pages improved.
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.

## Read the audits without chasing ghosts

- 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.

## Mobile versus desktop, and what Google uses

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.

## Speed thresholds beyond the three vitals

- 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.

## Questions

### What is PageSpeed Insights?

A free Google report for one URL. The top shows field data from real Chrome users over 28 days. The bottom is a Lighthouse lab run with a 0 to 100 score and audits.

### How do I access PageSpeed Insights?

Go to pagespeed.web.dev and paste a full URL. Read the Mobile tab first. Save the link to the report for later comparison after you ship changes.

### Is PageSpeed Insights free?

Yes. Both the field section and the Lighthouse run are free. The data comes from the Chrome User Experience Report for field and from a simulated lab run for diagnostics.

### Is PageSpeed Insights reliable?

The field section is reliable for Core Web Vitals. It uses the 75th percentile over 28 days. The lab score varies between runs. Use lab audits to find causes, not as a KPI.

### Why does my score change every run?

Because Lighthouse is a single simulated load. Network and server noise, and third-party timing, move the number. Your field data changes slower and is what Search uses.

### Why is INP failing when my score looks fine?

The score blends metrics and can hide an INP problem. Field INP failing means real users tap or click and wait. Cut long tasks, shrink handlers and defer work after the visual change.

## Read next

- [Core Web Vitals for a product site: the three numbers](https://porteur.ai/guides/core-web-vitals): The product founder’s guide to LCP, CLS and INP: what Google measures, why phones decide the pass, common causes, and how to test and fix.
- [Reading a Lighthouse score on a phone](https://porteur.ai/guides/lighthouse-score): Use the mobile Lighthouse run to judge speed and UX. See what each score means, how lab and field data differ, and what to fix first.
- [Largest Contentful Paint: what slows it and what fixes it](https://porteur.ai/guides/largest-contentful-paint): See what usually counts as LCP, what makes it slow, how to fix it in order, and how to read it in Lighthouse and field data.
- [How to improve Interaction to Next Paint](https://porteur.ai/guides/how-to-improve-interaction-to-next-paint): Cut slow interactions to under 200 ms. See where INP hurts, why Lighthouse misses it, and the fixes that make your page feel instant.
- [How to fix cumulative layout shift, cause by cause](https://porteur.ai/guides/how-to-fix-cumulative-layout-shift): See how CLS is measured, find the shifting elements, fix each common cause, and check field data after 28 days to confirm it worked.
- [Render-blocking resources: what blocks the first paint and how to unblock it](https://porteur.ai/guides/render-blocking-resources): Stop CSS and synchronous scripts from blocking first paint. Read the Lighthouse audit and fix in order: defer, inline critical CSS, split CSS, and handle fonts.
- [Does page speed affect SEO? What Google has said and what the data does](https://porteur.ai/guides/does-page-speed-affect-seo): Yes, speed affects SEO, but only at Core Web Vitals’ Good thresholds. Here is what Google measures, what the data shows, and what to fix first.

Get a free read of your site’s speed and rivals in about thirty seconds: paste a URL and Porteur will show three findings you can ship next. Free check: https://porteur.ai/