SEO
What Are Core Web Vitals? A Complete Guide to Website Performance
Core Web Vitals are three measurements Google uses to describe how a web page feels to a real person: how soon the main content appears, how quickly the page reacts to a tap or click, and whether the layout jumps while they try to use it. The current set is Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS). They are not a design contest and they are not a single “SEO score.” They are a shared vocabulary for loading, responsiveness, and visual stability.
This guide answers what Core Web Vitals are, what a good score looks like, how Google measures them, and how to improve them without chasing a lab screenshot. The practical repair order — images, scripts, fonts, hosting — lives in website performance optimization. Speed is one part of technical SEO, not a substitute for a page that actually answers the search.
Scriplit is not affiliated with Google. Good Core Web Vitals do not guarantee a ranking. Thresholds below follow Google’s current public documentation on web.dev and Search Central. Metrics can change; confirm the live docs when you make a decision.
What Core Web Vitals are
Google’s Web Vitals program tries to name a short list of user-centered performance metrics so site owners are not comparing twenty different timers. Core Web Vitals are the subset that apply to every page, can be measured on real visits, and appear in Google’s common tools. Each one stands for a different part of the visit:
- Largest Contentful Paint (LCP) — loading. When does the largest piece of visible content finish rendering?
- Interaction to Next Paint (INP) — responsiveness. After a click, tap, or keypress, how long until the next frame paints?
- Cumulative Layout Shift (CLS) — visual stability. How much do visible elements unexpectedly move?
Those three are the current, stable set. First Input Delay (FID) used to be the interactivity Core Web Vital. On 12 March 2024, INP replaced FID because FID only looked at the delay before the first event handler, and only for the first interaction. INP watches clicks, taps, and keypresses across the visit and includes the time until the next paint. If an older article still treats FID as current, treat that article as outdated.
Google evaluates each metric at the 75th percentile of real page loads, separately for mobile and desktop. A “good” label means at least three out of four visits meet the good threshold — not that your laptop on office Wi‑Fi had a green Lighthouse run. A page is considered to pass Core Web Vitals only when all three metrics meet their good targets at that percentile.
Why Core Web Vitals matter
They matter first because people notice them. A hero image that arrives four seconds late, a menu that ignores the first tap, or a “Buy” button that slides under a finger are conversion problems before they are ranking problems. Slow or unstable pages lose attention on a phone; that is enough reason to fix the money templates even if search never moved.
They also matter for search. Google’s ranking systems use Core Web Vitals as part of understanding page experience. That is not the same as “pass these three numbers and you outrank everyone.” Relevance still wins. A slow page that is the only honest answer to a query can still appear. When several pages could satisfy the same search, a usable, stable page is more aligned with what those systems try to reward. HTTPS, a usable mobile layout, and avoiding interstitials that hide the content sit in the same page-experience conversation. None of that replaces matching the query, which is the job in what SEO is.
Largest Contentful Paint (LCP)
LCP is the time from when the user starts navigating to the page until the largest image, text block, or video in the viewport has rendered. It is meant to answer “when did the main thing show up?” Older timers such as load or First Contentful Paint (FCP) do not answer that. FCP only marks the first paint of any content — a header or a spinner can satisfy FCP while the real offer is still blank.
Typical LCP elements are a hero photograph, a product image, a video poster, a CSS background image loaded with url(), or a large heading. Cookie banners and full-viewport decoration can steal the measurement if they are bigger than the content. Google’s LCP documentation lists the element types that count and the heuristics that ignore empty placeholders and invisible nodes. Details: Largest Contentful Paint on web.dev.
A good LCP is 2.5 seconds or less at the 75th percentile. Between 2.5 and 4.0 seconds needs improvement. Above 4.0 seconds is poor.
What usually makes LCP slow
- A huge hero image, or an image the browser only discovers late (buried in CSS or injected by JavaScript).
- Lazy-loading the LCP image. Lazy-load below-the-fold assets; the first large image should be in the HTML with width and height (or
aspect-ratio). - Slow Time to First Byte: the HTML itself is late because of the server, redirects, or a cold cache.
- Render-blocking CSS or fonts that hold the largest text from painting.
- A slider or client-rendered banner that is not in the first HTML payload.
How to improve LCP
Find the LCP element in PageSpeed Insights or Chrome DevTools, then make that one resource arrive earlier. Compress and size images to the largest they will display. Use responsive srcset and a modern format such as WebP or AVIF where your audience’s browsers allow. Preload only that LCP image if it is truly the bottleneck — preload is a queue jumper, not a habit. Cache public HTML when you can. Defer chat, tags, and A/B scripts that are not needed to paint. If the page waits on a database or a remote API before it sends HTML, no amount of JPEG compression will save LCP. The ordered punch list is in the performance guide.
Interaction to Next Paint (INP)
INP measures how long the page takes to respond to clicks, taps, and keyboard presses throughout the visit — not only the first tap after load. For each interaction, the clock runs from the input until the browser can paint the next frame. The page’s INP is essentially the worst typical interaction after outliers are handled; Google then looks at the 75th percentile of those page values. Scrolling and hovering do not count. A page with no clicks, taps, or keypresses may have no INP value at all. Official definition: Interaction to Next Paint on web.dev.
A good INP is 200 milliseconds or less. From just above 200 ms through 500 ms needs improvement. Above 500 ms is poor.
Responsiveness is what tells a person the tap worked: the menu starts to open, the button shows a pressed state, the accordion begins to expand. INP does not wait for a slow network call to finish. It asks whether the next paint is blocked. Heavy JavaScript on the main thread is the usual reason it is. Event handlers that do too much work, large bundles on a brochure page, and third-party tags that compete for the same thread all stretch the gap between the tap and the next frame.
What usually makes INP poor
- Long tasks on the main thread while the visitor is trying to use a menu, filter, or form.
- Tag managers, live chat, heatmaps, and review widgets on every URL.
- A client-side framework downloading the whole app to render a mostly static page.
- Input handlers that reflow the whole document or run expensive queries on every keystroke.
How to improve INP
Do less work before the next paint. Split JavaScript so the home page does not download checkout code. Yield to the browser in long handlers. Debounce search-as-you-type. Load a library on the click that needs it, not on every page. Name every third-party script and delete the ones that support no decision. Lighthouse cannot fully simulate INP because it does not tap through your real flow; use Total Blocking Time in the lab as a hint, then reproduce the slow control on a mid-range phone. Field data and a performance trace beat guessing.
Cumulative Layout Shift (CLS)
CLS measures unexpected movement of visible content. If a heading, button, or paragraph changes its starting position between frames without the user asking for it, that movement scores. New elements that appear without pushing anything else, and shifts that happen soon after a click (within about 500 milliseconds of that input), are treated differently — those are often expected. CLS is not “anything that animates.” It is surprise.
The score is not a running total of every shift for the entire month. Shifts are grouped into short bursts called session windows. The CLS value for a visit is the worst of those bursts. A good CLS is 0.1 or less. Between 0.1 and 0.25 needs improvement. Above 0.25 is poor. Official definition: Cumulative Layout Shift on web.dev.
What usually makes CLS high
- Images or embeds without reserved space (no width/height or aspect-ratio).
- Ads, cookie bars, or announcement bars injected above existing content after first paint.
- Web fonts that swap in with different metrics and reflow the text.
- Late client-side content: “you may also like” rails, related posts, or review widgets that expand the layout.
- Chat launchers that push the document instead of sitting in a fixed corner.
How to improve CLS
Reserve space before the asset arrives. Put width and height on images and iframes, or set aspect-ratio in CSS. Keep banners in a reserved region or overlay them without shoving the LCP down. Prefer font fallbacks with similar metrics, or font-display choices that do not cause a late jump. Animate with transform rather than by changing top, left, width, or height. If a click is supposed to open a panel, paint a placeholder immediately so the later content does not rearrange the page under the finger.
Core Web Vitals score ranges
Use this table as the current field-data target. All three rows are judged at the 75th percentile, mobile and desktop separately. A page that is good on two metrics and poor on one does not pass overall.
| Metric | What it measures | Good | Needs improvement | Poor |
|---|---|---|---|---|
| LCP | When the largest visible content renders | 2.5 s or less | Over 2.5 s through 4.0 s | Over 4.0 s |
| INP | Delay from click, tap, or key to the next paint | 200 ms or less | Over 200 ms through 500 ms | Over 500 ms |
| CLS | Unexpected layout movement | 0.1 or less | Over 0.1 through 0.25 | Over 0.25 |
These thresholds come from Google’s published research on how people experience delay and movement, summarized in how the thresholds were defined. They are not Scriplit house rules.
How Google measures Core Web Vitals
There are two kinds of numbers, and they answer different questions. Mixing them up is how teams “fix” a site in Lighthouse and still fail in Search Console.
Field data (real users)
Field data comes from real Chrome visits that meet Google’s eligibility rules. The public dataset is the Chrome User Experience Report (CrUX). CrUX aggregates roughly the last 28 days, reports the 75th percentile, and is the dataset Google Search uses when it talks about Core Web Vitals for page experience. Not every URL has enough traffic to appear. Low-traffic pages often have origin-level data only, or no field row at all. CrUX is Chrome-centric; it is not a census of Safari, Firefox, or every bot.
Your own real-user monitoring can go deeper: which control was slow, which template, which country. CrUX tells you whether there is a problem. It rarely names the line of code.
Lab data (a test machine)
Lab data is a simulated load: a defined device, a defined network, no real customer tapping around. It is excellent for reproducing a fat image or a blocking stylesheet before you ship. It is a poor substitute for field INP, because INP depends on what people actually click. Lighthouse will often show Total Blocking Time as the interactivity stand-in for that reason.
The tools you will actually open
- PageSpeed Insights — paste a URL. When CrUX has enough samples, you see field LCP, INP, and CLS for the URL and the origin, plus a Lighthouse lab run for diagnostics.
- Google Search Console — the Core Web Vitals (Experience) report groups URLs that share a problem. It is a debug queue, not a branding score you optimize to 100. Console still does not tell you whether anyone enquired.
- Lighthouse — in Chrome DevTools or via PageSpeed Insights. Lab only. Use it to name opportunities (unused CSS, an unsized image), then confirm the field report later.
- Chrome DevTools — Performance and the live Web Vitals overlay help you see the LCP element and layout shifts on a page you control.
- CrUX — the same field source behind Insights and Console, also queryable via Google’s CrUX tools if you need origin history.
A green lab score and a red field score usually means the lab was kinder than your audience: faster CPU, warmer cache, fewer tags after consent, or a URL that is not the one customers land on. Believe the field row when it exists. Use the lab to hunt.
How to improve Core Web Vitals
Work the templates that sell — home, a service or product page, contact or checkout — before you compress images on a rarely read article. Change one class of problem at a time so you know what helped. Then wait for the 28-day field window to roll; a deploy on Tuesday will not rewrite CrUX on Wednesday.
| Work | Helps | What to do first |
|---|---|---|
| Image weight and responsive images | LCP, sometimes CLS | Correct dimensions, modern formats, srcset; do not lazy-load the LCP image |
| Preload and fetch priority | LCP | Preload only the actual LCP resource |
| Render-blocking CSS | LCP, FCP | Keep the first stylesheet small; defer the rest |
| JavaScript and third-party tags | INP, LCP | Remove unnamed scripts; split bundles; load chat after idle or a gesture |
| Fonts | LCP, CLS | Subset, fallback metrics, avoid a late metric swap |
| Server response, caching, CDN | TTFB, then LCP | Cache public HTML; put the origin near users; kill extra redirects |
| Reserved space | CLS | Width/height or aspect-ratio on images, embeds, and ad slots |
Images are the most common LCP. Serve the file at the size it will display. A 3× retina asset as the only source on a 360-pixel phone is wasted decode time. Prefer a real <img> in the HTML for anything that might be LCP; background images in CSS are harder to prioritize. Scriplit’s browser image converter can emit WebP or JPEG from a still you already have — it does not crawl your site, and it is not a substitute for a proper responsive set on the live template.
A content delivery network and HTTP caching help when the bottleneck is distance or repeat views. They do not fix a 4 MB PNG or a chat widget that blocks the main thread. Hosting and cache headers are infrastructure. The LCP element is still your job.
Other website performance metrics
Several timers show up next to Core Web Vitals. They are useful diagnostics. They are not the three Core Web Vitals.
| Metric | Role | Typical good target |
|---|---|---|
| First Contentful Paint (FCP) | When any content first paints. Helps explain a slow LCP if even the first paint is late. | 1.8 s or less (75th percentile) |
| Time to First Byte (TTFB) | Until the first byte of the document response. Redirects, DNS, TLS, and the server all sit inside it. | 0.8 s or less as a rough guide |
| Total Blocking Time (TBT) | Lab sum of long main-thread tasks after FCP. A proxy when you cannot measure INP in the lab. | Use Lighthouse’s rating; it is not a field Core Web Vital |
| Speed Index | Lab estimate of how quickly the viewport fills in. Diagnostic, not a Core Web Vital. | A lab hint only |
If TTFB is poor, start with the server, redirects, and cache — not with a new image format. If FCP is poor but TTFB is fine, look at render-blocking CSS and fonts. If LCP is poor but FCP is fine, the largest element is the problem (often an image). If INP is poor and TBT is high, the main thread is busy. That mapping keeps you from “optimizing everything” at once.
Core Web Vitals and SEO
Google recommends good Core Web Vitals for Search and for users. The same documentation is explicit: a perfect report does not put you at the top of the results, and page experience is more than these three metrics. There is no single “page experience signal” you can tune. Core ranking systems still try to show the most relevant result, including when the page is slower than you would like. When many pages could help, experience can contribute. That is the accurate relationship — not “Core Web Vitals are the ranking algorithm.”
Treat the Search Console report as one column in a website SEO audit: fetch and index first, query match second, then whether the money templates are usable on a phone. A site that fails LCP on the home page and also fails to answer the query has two jobs. Do not spend a month shaving 80 milliseconds off a page that should not exist.
How to test your website’s Core Web Vitals
- Open PageSpeed Insights and paste the live URL you care about — usually home, a service or product page, and contact or checkout. Use the public host, not staging.
- Read the mobile field section first when it exists. Desktop is a second pass. Google Search is mobile-first; a green desktop lab run is not the report that matters most.
- Note LCP, INP, and CLS at the 75th percentile. If a metric is missing, the URL may not have enough CrUX samples; use origin data and your own lab checks.
- Open the lab diagnostics. Identify the LCP element, unused JavaScript, render-blocking CSS, and unsized images. Those rows are a punch list, not a grade.
- In Search Console, open the Core Web Vitals report and see whether the same issue is grouped across a template. Fix the template, not one lucky URL.
- Reproduce the worst page on a mid-range phone or with CPU/network throttling. Click the menu, the filters, and the form. Lab INP will not appear unless you interact.
- Change one class of issue (images, or tags, or font swap). Redeploy. Retest in the lab the same day. Recheck field data after enough real visits have aged through the 28-day window.
- Confirm the faster page still converts. A layout that paints quickly and hides the phone number in a drawer optimized the wrong thing. Pair this work with website conversion optimization.
Common Core Web Vitals problems
| What you see | Likely cause | First fix |
|---|---|---|
| LCP is a huge photo or a late hero | Oversized file, lazy-loaded LCP, or image only in CSS | Real img in HTML, sized, compressed; preload that one file if needed |
| LCP is poor but images look fine | Slow TTFB, extra redirects, or HTML waiting on a backend | Cache the public page; shorten the redirect chain; profile the server |
| INP spikes on the mobile menu | Main thread busy with tags or a large bundle | Defer third parties; split JavaScript; test the menu on a mid-range phone |
| No INP in the report | Not enough interactions in CrUX, or people only scrolled | Use origin data, RUM, or a lab flow that actually clicks |
| CLS jumps when fonts or ads load | Fallback metrics differ, or slots have no height | Reserve space; match fallback fonts; do not inject a bar above the header after paint |
| Lab is green, Search Console is red | Field devices and tags differ from the lab | Trust field data; reproduce on a slower phone with the live tag container |
| You shipped a fix and CrUX did not move | 28-day mix still includes the old visits | Wait for the window to roll; confirm you changed the URL people actually open |
If you want a human to read the money templates and change the front end or the host, that is ordinary web development and SEO work at Scriplit — not a guaranteed PageSpeed number. Send the live URL and which template takes the enquiry through the web development contact form or the SEO contact form, and say whether you can change hosting or only the theme.
Frequently asked questions
What are Core Web Vitals?
They are Google’s current field metrics for loading, responsiveness, and visual stability: Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS). A page passes when all three are “good” at the 75th percentile of real visits, on mobile and on desktop.
What is a good LCP score?
2.5 seconds or less at the 75th percentile. Over 4.0 seconds is poor. Measure real users when you can, not only a developer laptop.
What is a good INP score?
200 milliseconds or less at the 75th percentile. Over 500 milliseconds is poor. INP replaced First Input Delay in March 2024 and covers more than the first tap.
What is a good CLS score?
0.1 or less at the 75th percentile. Over 0.25 is poor. Expected movement right after a click does not count the same way as a surprise jump.
Do Core Web Vitals affect SEO?
They are used by Google’s ranking systems as part of page experience. They do not outrank relevance, and a green report is not a ranking guarantee. Useful content on a usable page is still the job.
How do I check Core Web Vitals?
Paste the live URL into PageSpeed Insights and read the field section when it exists. Then open Search Console’s Core Web Vitals report for grouped URLs. Use Lighthouse to name lab issues.
Why is my LCP score poor?
Usually a late or oversized LCP image, HTML that is slow to start (TTFB), or render-blocking CSS and fonts. Find the LCP element first, then fix that resource and the server time behind it.
Why is my CLS score high?
Something visible moved after paint: an unsized image, a late ad or cookie bar, a font swap, or a widget that expands. Reserve space and stop injecting bars above content that already rendered.
Does JavaScript affect Core Web Vitals?
Yes. Heavy JavaScript delays INP and can delay LCP if the largest content is client-rendered. Third-party tags are JavaScript too. Removing unused script often helps more than micro-optimizing your own bundle.
Do images affect LCP?
Often they are the LCP element. Oversized files, lazy-loaded heroes, and images hidden in CSS are the usual failures. Compress, size correctly, and keep the LCP image in the first HTML.
How often does Google update Core Web Vitals data?
CrUX field data is a rolling window of about 28 days and updates on a best-effort daily schedule. Search Console’s report lags that window. A fix you shipped today will not fully replace the old visits until those days age out.
Is First Input Delay still a Core Web Vital?
No. Interaction to Next Paint replaced FID on 12 March 2024. Use INP in current reports. Older FID charts are history, not the live target.