Page speed and Core Web Vitals, explained for a product site
Speed in search is three numbers measured on real phones, not the score on a dashboard. These guides say what each number is, where it comes from, and what slows it: fonts, images, scripts, the server, the layout. One cause per guide, one fix per cause.
By Théophile Louvart, founder of Porteur · Updated 14 September 2026 · Markdown
The three numbers that count
Google ranks on three Core Web Vitals, each with a threshold for good. Largest Contentful Paint is when the biggest thing in the viewport has painted: good up to 2.5 seconds, poor above 4. Cumulative Layout Shift is how much the page moved while loading: good up to 0.1, poor above 0.25. Interaction to Next Paint is the slowest response to a tap or click over the visit: good up to 200 milliseconds, poor above 500. INP replaced First Input Delay in March 2024.
The assessment that counts for Search is the field data: the 75th percentile of real Chrome users' page loads over 28 days, per URL when there is enough traffic, otherwise per origin. It lives in the Chrome User Experience Report, and Search Console shows it in the Core Web Vitals report, grouped by similar URLs. A site with too few visits shows no field data at all, and is then judged by nothing.
Everything else is lab data: one simulated load by Lighthouse on a mid-range phone over a throttled connection, in PageSpeed Insights, DevTools or a tool like the one here. The lab is where you find the cause; the field is what Google reads. The Lighthouse score from 0 to 100 is not a ranking factor and varies between runs.
How much speed matters for ranking
Core Web Vitals have been a ranking signal since the 2021 mobile and 2022 desktop rollouts, applied to field data at the good thresholds. Google has said the signal is smaller than relevance and content: a slow page that answers the query beats a fast one that does not. What speed does reliably is decide ties, keep the click once it lands, and let a crawler fetch more of the site in the same time.
Mobile-first indexing has been complete since 2023, so the mobile figures are the ones that count: the smartphone crawler reads the page, and the mobile field data is what the Search Console report shows first. A page fast on a laptop and slow on a phone is slow.
What slows a page, and where the fix lives
LCP waits on the server (time to first byte), on render-blocking stylesheets and scripts, on fonts, and on the hero image: an image that is lazy-loaded, discovered late or served without priority is the commonest cause on a product site. The fix lives in the head of the page and in the image tag.
CLS comes from media without width and height, banners injected above the content, fonts that swap to a face with different metrics, and content inserted late. The fix is reserved space: dimensions on every image and iframe, a slot for the notice, matched fallback metrics for the font.
INP comes from JavaScript on the main thread: hydration of a large framework, heavy handlers, a large DOM, third-party scripts. Lighthouse cannot measure it, so Total Blocking Time stands in for it in the lab. The fix is less script, script that yields, and third parties loaded on interaction or not at all.
| Symptom | Usual cause on a product site | The guide |
|---|---|---|
| LCP over 2.5 s | Slow first byte, a render-blocking stylesheet, a lazy or late hero image, a web font before the text | Time to first byte, render-blocking resources, image optimisation, web fonts |
| CLS over 0.1 | Images without dimensions, an injected banner, a font swap | How to fix cumulative layout shift, web fonts |
| INP or TBT high | Hydration, third-party scripts, long tasks | Interaction to Next Paint, Total Blocking Time, third-party scripts |
| Good on desktop, poor on mobile | CPU-bound JavaScript, images sized for desktop | Mobile page speed |
The order to read the guides
- First: Core Web Vitals for a product site, then how to read PageSpeed Insights, then whether speed affects SEO. Those three say what is measured and what it is worth.
- Then the number that is red for you: Largest Contentful Paint, cumulative layout shift, Interaction to Next Paint, or the lab proxies (First Contentful Paint, Total Blocking Time, the Lighthouse score).
- Then the cause: time to first byte, render-blocking resources, web fonts, image optimisation, lazy loading, third-party scripts.
- Last: mobile page speed, and the Search Console Core Web Vitals report to see whether the field data moved 28 days after the fix.
How to measure your own site
Open PageSpeed Insights on the home page, the pricing page and one long page: the top section is the field data with a pass or fail, the bottom is the lab run with its opportunities. If the field section is empty, the site has too few Chrome visits yet and the lab is all you have. The Core Web Vitals checker here runs the same Lighthouse on a simulated phone and judges each figure against the thresholds in words; the server response checker times the first byte and reads the headers that decide how a page starts.
Then Search Console's Core Web Vitals report, once the site has traffic: URLs grouped into Poor, Needs improvement and Good, mobile first. Fix the template behind a Poor group, wait 28 days, validate.
Where the free check fits
The free check measures the home page on a simulated phone and says what would save the most time. The report measures one page of each kind that sells (pricing, a comparison, an article, the docs, a landing page), names the cause on each, and writes the change as a brief with the file it touches, so an agent can make it in the repository. Speed is a chapter of the report, not the whole of it: a fast page nobody searches for is still a page nobody finds.
The guides, in the order to read them
19 guides on the theme, each on one question, each ending in your own figures.
- Core Web Vitals for a product site: the three numbersGuide
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.
- How to read PageSpeed Insights: field data first, then the scoreGuide
Start with field data, not the score. Learn what Google uses, why scores vary, and how to turn a PageSpeed Insights run into a clear order of fixes.
- Does page speed affect SEO? What Google has said and what the data doesGuide
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.
- Largest Contentful Paint: what slows it and what fixes itGuide
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 fix cumulative layout shift, cause by causeGuide
See how CLS is measured, find the shifting elements, fix each common cause, and check field data after 28 days to confirm it worked.
- How to improve Interaction to Next PaintGuide
Cut slow interactions to under 200 ms. See where INP hurts, why Lighthouse misses it, and the fixes that make your page feel instant.
- First Contentful Paint: what it measures and what moves itGuide
What First Contentful Paint measures, the good and poor thresholds, why it affects Lighthouse not rankings, and how to make it faster on your site.
- Total Blocking Time: the lab number that stands in for INPGuide
What Total Blocking Time measures in Lighthouse, why it weighs 30 percent, how it relates to INP, and the fixes that cut it fast.
- Reading a Lighthouse score on a phoneGuide
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.
- Time to first byte: the delay every other metric inheritsGuide
TTFB sets the pace for every other speed metric. See what it includes, how to test it in field and lab, the causes on product sites, and the fixes.
- Render-blocking resources: what blocks the first paint and how to unblock itGuide
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.
- Web fonts and page speed: load one face, and load it firstGuide
Ship crisp type without slowing first paint or shifting layout. Choose one fast path, preload the face above the fold, and stop the swap from moving text.
- Image optimisation for page speed: the hero image and everything below itGuide
Fix the hero image first for LCP, then lazy-load the rest. Choose AVIF or WebP, set srcset and sizes, and add width and height to stop shift.
- Lazy loading images: what to lazy-load and what never toGuide
Lazy loading images saves bandwidth. Here is what to lazy-load, what never to, how to handle iframes and backgrounds, and how it affects LCP and SEO.
- Third-party scripts: the page speed you gave awayGuide
See what each third-party script costs and what to do: remove, load on interaction, defer, self-host, facade video and maps, and preconnect smartly.
- Mobile page speed: the version of your site that Google readsGuide
Run a mobile page speed test the way Google reads your site. See field vs lab, why phones are slower, the key fixes, and how to verify on a real device.
- Caching: what to cache, for how long, and what it does for crawlingGuide
Hashed assets cached for a year, HTML cached briefly and revalidated, stale-while-revalidate at the edge, and the caching mistakes that cost crawls.
- How to speed up a website: the order that paysGuide
Six changes, ranked by what they usually return for the effort: the hero image, blocking resources, fonts, third parties, the server, the bundle.
- HTTP/2 and HTTP/3: what they change for a site’s speedGuide
What each protocol fixes, where it is switched on, how to check which one your site serves, and how much it is worth beside your other speed work.
The free tools
Each checks one thing on one page or one site, without an account, and says what it found in words.
- Core Web Vitals checkerFree tool
Paste a URL for one Lighthouse run on a simulated phone: LCP, CLS, TBT and FCP against Google's thresholds, the biggest savings, the failing audits.
- Server response checkerFree tool
Paste a URL and time the server's answer: time to first byte, HTTP/2 or HTTP/3, brotli or gzip, Cache-Control, HSTS, the headers that decide when a page starts.
- On-page SEO checkerFree tool
Paste a URL and get the page read as a crawler reads it: title, description, canonical, indexability, headings, alt text, links, share tags, what to fix first.
The words
What each term means for a small site, and what to do about it.
- Core Web VitalsGlossary
Core Web Vitals are Google’s three field speed and responsiveness metrics. See their thresholds, lab versus field, how to read them, and what to fix.
- Largest Contentful Paint (LCP)Glossary
Largest Contentful Paint is when the biggest element appears. Aim under 2.5 s. See how to measure it, usual causes on small sites, and quick fixes.
- Cumulative Layout Shift (CLS)Glossary
Cumulative Layout Shift is how much a page moves while loading. Keep CLS at or below 0.1. Here is how to measure, find causes, and fix them.
- Interaction to Next Paint (INP)Glossary
INP is the delay from tap to next paint, good up to 200 ms; learn how to measure it, read field versus lab data, and fix script delays.
- Mobile-first indexingGlossary
Mobile-first indexing means Google uses your mobile page to crawl, index and rank. Here is what it hides on desktop-only pages and how to fix it.
- RenderingGlossary
Rendering is how Google executes your JavaScript and CSS after crawling HTML, which can delay indexing. Here is what to check and how to fix it.
- JavaScript SEOGlossary
What JavaScript SEO means, how Googlebot renders, what breaks, how to fix links and content, and how to choose SSR or SSG so pages index fast.
Questions
No. Google ranks on the field data of the three Core Web Vitals at the good thresholds. The Lighthouse score is a lab figure that varies between runs; it is useful to find the cause of a slow page, not as a target.
The field data comes from opted-in Chrome users over 28 days, and a page with too few visits has none; the tool falls back to the origin, and a small site may have none for that either. Until there is traffic, the lab run is all you have, and it is enough to fix the causes.
The one that gets the most search impressions and fails a threshold in the field data, usually the home page or a guide. Fix the template, not the page: a change to the layout or the head fixes every page that shares it.
The field data is a 28-day window, so a fix takes up to a month to move a URL group from Poor to Good, and the report's Validate fix follows the same window.
Check my site, free
Paste your URL and the check measures your home page on a simulated phone, names what slows it, and shows three findings whole in about thirty seconds.
- Free check, no card
- Read-only, your own accounts
- Readable by your agent