01Largest Contentful Paint: how long until the main thing shows up
LCP is the render time of the largest image, text block or video visible on screen, counted from the moment the visitor starts loading the page (web.dev). On most small business sites that is the big photo or the headline at the top. A good LCP is 2.5 seconds or less, and anything over 4.0 seconds is poor. Two details from web.dev matter on a small site. An image that has not finished loading does not count as rendered, and neither does text hidden while a web font loads. So a very large photo, or a slow font, pushes the number up. That is our reading of the definition, not a measurement of your site. If the photo at the top is far bigger than the screen needs, start there.
- Good: 2.5 seconds or less. Poor: over 4.0 seconds
- Counts the largest image, text block or video in view
- Timed from when the visitor starts loading the page
- Usually the top photo or the headline on a small business site (our reading)
02Interaction to Next Paint: does the page react when you tap
INP reports how long the page takes to respond to clicks, taps and key presses across the whole visit, up to the moment the next frame is painted. Hovering and scrolling do not count. Unlike First Input Delay, which only measured the first interaction, INP looks at all of them (web.dev). A good INP is 200 milliseconds or less, and over 500 milliseconds is poor. On a small business site, think of the menu button, the form submit, the chat bubble: whatever a visitor taps and then waits on. What delays the response depends on the scripts your pages run, and we would rather not guess which. A test on your own pages tells you more than any rule of thumb.
- Good: 200 milliseconds or less. Poor: over 500 milliseconds
- Counts clicks, taps and key presses, not hovering or scrolling
- Covers every interaction in the visit, not only the first
- Test your own menu, form and chat bubble
03Cumulative Layout Shift: does the page jump while you read
CLS scores unexpected layout shifts: it is the largest burst of them over a page's life (web.dev). You know the feeling: you go to tap a button and the page slides down under your thumb. web.dev lists the usual causes: images or videos without set dimensions, fonts that render larger or smaller than their fallback, third-party ads or widgets that resize themselves, and content added above what is already on screen. A good CLS is 0.1 or less, and over 0.25 is poor. Shifts within 500 milliseconds of a tap or key press are excluded, because a menu that opens when you ask for it is expected. A banner or widget that loads late and pushes the text down is a small-site version of the problem (our example).
- Good: 0.1 or less. Poor: over 0.25
- Images and videos need set dimensions
- Late-loading fonts, ads and widgets can move the text
- Shifts within 500 milliseconds of a tap or key press are excluded
04How Google reads them, and how much they weigh
Google assesses these on real visits, not on one test run in your office. In PageSpeed Insights, field data comes from the Chrome User Experience Report over the previous 28 days, and a page passes the Core Web Vitals assessment when the 75th percentile of all three metrics is good, and when there is too little INP data it is assessed on LCP and CLS. Mobile and desktop are assessed separately. A small site may simply lack enough visits: Google's documentation says a page with too little data falls back to site-level data, and a page cannot be assessed when LCP or CLS data is missing. On ranking, Google's page experience guidance says Core Web Vitals are used by its ranking systems and recommends good scores. It also says Search always seeks the most relevant content even when page experience is sub-par, and that there is no single page experience signal. We promise no position.
- Field data: real visits over the previous 28 days (PageSpeed Insights)
- Pass: the 75th percentile is good on all three (on LCP and CLS alone when INP data is too thin), mobile and desktop assessed separately
- Too little traffic: a page may have no assessment at all
- Google: relevant content first, and no single page experience signal
05Check your own site
Open the Core Web Vitals report in Search Console, which Google's documentation points site owners to, and PageSpeed Insights for a single page. Read the field data first, because it reflects real visitors. The lab data PageSpeed Insights also shows is a simulation, useful for debugging, and Google notes it may not capture real-world bottlenecks. Look at the weakest of the three numbers, not an average: a page passes when all three are good, and when there is too little INP data it is assessed on LCP and CLS (PageSpeed Insights documentation). Then open the page on your own phone, on mobile data, and tap through it. If the numbers and your thumb disagree, repeat the test before you believe either.
- Search Console: the Core Web Vitals report, for your whole site
- PageSpeed Insights: field data first, lab data for debugging
- The weakest of the three metrics decides the pass
- Open the page on your own phone, on mobile data
06Where PROOF48 is the wrong choice
PROOF48's SEO page lists Core Web Vitals in the technical audit it starts with, and offers that audit free: send the URL and the first reply says what is broken. We do not publish a Core Web Vitals score for any of our builds, and no case study records one, so we cannot tell you that a PROOF48 site passes. We are the wrong choice in four situations. You run a hosted builder where you cannot change the code: we fix what we can and document what we cannot. Your site gets too few visits for Google to assess, so the report may be empty. Your real problem is that nobody finds the pages for lack of content, which Core Web Vitals will not fix, and SEO takes months. Or you need customers this week, where ads move faster, as our SEO page says. When the platform is the cause, a rebuild is the fix: a 48-hour website costs 500 to 2,500 EUR, paid after the preview.
- The SEO page offers a free technical audit: send your URL
- No Core Web Vitals score is published for any PROOF48 build
- Locked hosted builder: we fix what we can and document what we cannot
- Need customers this week: ads move faster than SEO
A rebuild with redirects, and no speed figure
The SCP Shine & Style salon site was rebuilt in 2026 and every old WordPress address was redirected, so nothing already indexed broke. The case study lists what shipped, from a page per service to video clips declared in the sitemap, and records no Core Web Vitals result before or after. We hold no speed measurement for it that we can publish, so we draw no speed conclusion from it. Our SEO page describes the order we work in: a technical audit first, content on top of it second.
See the build: SCP Shine & StyleQuestions, answered
Do Core Web Vitals decide where I rank on Google?
No. Google says its ranking systems use them and recommends good scores, but also that Search always seeks the most relevant content, even if page experience is sub-par, and that there is no single signal. Nobody can promise you a position, and PROOF48 does not.
What is a good score for each one?
Per web.dev: LCP 2.5 seconds or less, INP 200 milliseconds or less, CLS 0.1 or less, at the 75th percentile of page loads, with mobile and desktop reported separately.
Why does PageSpeed Insights show no real-user data for my site?
Field data needs enough real visits. Google says a page with too little data falls back to site-level data, and a page cannot be assessed when LCP or CLS data is missing. The lab data it shows instead is a simulation.
Is First Input Delay still one of the three?
web.dev lists LCP, INP and CLS as the three Core Web Vitals. First Input Delay measured only the first interaction on a page, while INP covers interactions across the whole visit.
Will PROOF48 get my site to pass?
We cannot promise a pass, and we publish no Core Web Vitals score for any build. The SEO page starts with a technical audit that covers them, and the audit is free. Send your URL and the first reply says what it found.
Where PROOF48 fits
Core Web Vitals are three timings: how fast the main content appears (2.5 seconds or less), how fast the page reacts (200 milliseconds or less) and how little it jumps (0.1 or less), judged on real visits. Check them in Search Console and PageSpeed Insights, fix the weakest one first, and do not expect a ranking from them alone. PROOF48 starts SEO with a free technical audit, and a 48-hour website costs 500 to 2,500 EUR, paid after the preview.
Cosmin Tiu · Founder, PROOF48
Cosmin has worked in online marketing and software development since 2018, and has built with AI every day since January 2023. He still writes code from scratch daily, in Python, React, Rust and C#. PROOF48 ships business websites in 48 hours and invoices afterwards, so every opinion on this blog was paid for in real builds, not in theory.