Core Web Vitals are field metrics for loading, interaction responsiveness and visual stability. They turn parts of user experience into a shared measurement system, but a green report is not a substitute for relevant content, accessible journeys, crawlability or business outcomes.
CrUX and first-party real-user monitoring show what eligible visitors experienced. DevTools and repeatable lab tests reveal the element, interaction, resource or task behind it. Lighthouse 100 is not the objective.
Know the three current metrics and thresholds
Evaluate the 75th percentile of page visits, separately for mobile and desktop. Lower is better for all three metrics. LCP and INP are time values; CLS is a unitless visual-stability score.
INP replaced First Input Delay (FID) as a Core Web Vital on March 12, 2024. FID is no longer a current Core Web Vital, and Chrome performance tools ended support later that year. Total Blocking Time in Lighthouse is a useful lab diagnostic, not a substitute for field INP.
| Metric | Good | Needs improvement | Poor | Experience measured |
|---|---|---|---|---|
| LCP | ≤ 2.5 seconds | > 2.5 to 4 seconds | > 4 seconds | When the likely main content becomes visible |
| INP | ≤ 200 milliseconds | > 200 to 500 ms | > 500 ms | Responsiveness across qualifying interactions |
| CLS | ≤ 0.1 | > 0.1 to 0.25 | > 0.25 | Unexpected visual movement during the visit |
Understand how the assessment passes or fails
A page or origin passes the Core Web Vitals assessment when the 75th-percentile values for LCP, INP and CLS are all “good”. In PageSpeed Insights, an aggregation with insufficient INP data can pass when LCP and CLS are good; if LCP or CLS lacks sufficient data, it cannot be assessed.
Search Console assigns a URL group the status of its worst-performing Core Web Vital. “No data” is not a pass or failure—it means the CrUX sample does not support that assessment.
| Situation | Assessment | Interpretation |
|---|---|---|
| All three metrics good | Pass | At least 75% of measured visits meet every threshold |
| One metric needs improvement | Does not pass | Fix that user-experience dimension |
| One metric poor | Poor group/status | Prioritize representative affected journeys |
| INP insufficient; LCP and CLS good | May pass in PSI | Too few qualifying interactions for INP assessment |
| LCP or CLS insufficient | Cannot assess | Use RUM and lab evidence; do not call it a pass |
| No CrUX data | Unknown | Often insufficient eligible traffic, not proof of speed |
Place Core Web Vitals inside page experience and Search
Google says its ranking systems use Core Web Vitals, but there is no single page-experience signal. Relevance remains primary, and a perfect report does not guarantee top rankings. HTTPS, mobile presentation, intrusive interstitials, distracting ads and clear separation of main content still affect the experience users receive.
Use Core Web Vitals to improve important journeys and reduce friction—not to make every decorative feature disappear. Measure whether the change also protects accessibility, task completion and conversion quality.
| Claim | Accurate position |
|---|---|
| “CWV guarantees rankings” | False; it is one set of signals among many |
| “CWV does not matter because content ranks” | False; poor experience can reduce user value and may contribute to Search outcomes |
| “Only green URLs are usable” | False; thresholds are shared targets, not a complete UX diagnosis |
| “Page experience is one score” | False; Google describes multiple aspects and page-specific plus some site-wide assessment |
Use each evidence layer for the question it can answer
| Evidence | Best question | Typical source | Main limitation |
|---|---|---|---|
| CrUX field data | What did eligible Chrome users experience? | PSI, Search Console, CrUX API/History/BigQuery | Aggregated sample; limited segmentation and eligibility |
| First-party RUM | Which route, element, interaction, user context and release regressed? | web-vitals library or RUM platform | Needs governance, sampling, privacy and analysis |
| Lab load test | What blocks this reproducible navigation? | Lighthouse and PSI lab section | One simulated load; weak for post-load behavior |
| Interactive trace | Which task, handler, layout or paint delayed a flow? | Chrome DevTools Performance panel | Manual test conditions may differ from users |
| Delivery evidence | Did server, CDN or asset behavior change? | Server-Timing, CDN and application logs | Does not measure the complete visual experience |
| Business analytics | Did faster journeys improve useful outcomes? | Analytics and conversion records | Correlation needs release and cohort controls |
Know what CrUX includes—and what it does not
CrUX aggregates real experiences from eligible Chrome users on supported desktop platforms and Android Chrome. It excludes Chrome on iOS, Android WebView, other Chromium browsers and users who do not meet its settings criteria. Pages and origins also need to be publicly discoverable and sufficiently popular.
CrUX is therefore representative evidence, not a census of every visitor. Query parameters and fragments are stripped in page-level CrUX aggregation, and SPA soft navigations have platform-measurement limits. Supplement low-traffic, segmented or application-specific questions with first-party RUM.
| CrUX property | Operational consequence |
|---|---|
| 28-day rolling aggregation | A release mixes with up to 27 earlier days and changes gradually |
| Updated daily in API/PSI | New data does not mean a fresh independent 28-day test |
| URL and origin levels | Origin fallback can hide a slow or fast individual template |
| Eligible Chrome sample | Do not generalize blindly to every browser or audience |
| Popularity threshold | New and low-traffic pages may show no field data |
| Privacy filtering and fuzzing | Use distributions and trends, not traffic-volume inference |
Read PageSpeed Insights and Search Console correctly
PageSpeed Insights combines a 28-day CrUX view with a new Lighthouse lab run. Confirm whether the field section says “This URL” or “Origin”; those scopes can tell different stories. Search Console groups URLs believed to provide similar experience and is intended for group-level diagnosis, not finding an exact score for every URL.
The Search Console group status reflects the worst metric. Open representative examples, compare PageSpeed URL versus origin data, and verify the actual Template before applying one fix everywhere.
- Separate Mobile and Desktop.
- Record collection dates, URL/origin scope and group name.
- Do not compare Search Console group data directly with one Lighthouse run.
- Confirm whether the tested page had enough URL-level CrUX data.
- Check all three metric distributions, not only the overall label.
- Save the affected Template, release version and representative URL.
- Use CrUX History or RUM for trends rather than screenshots.
- Treat “No data” as unknown.
Define the affected unit before touching code
A report URL is often only an example of a shared Header, Hero, Article Template, Product Gallery, Form or Consent Layer. Reproduce more than one URL and segment by Template, Device, Navigation Type and important user state.
Fixing one image on one URL is low leverage when a CMS rule generates the same failure across hundreds of pages. The reverse is also true: do not rewrite a global component because one personalized page is an outlier.
| Pattern | Likely unit | First comparison |
|---|---|---|
| Same metric across one Template | Template markup or shared asset rule | Three representative URLs |
| Issue across most pages | Header, font, consent, analytics or CDN | Home, article, service and form |
| Only slow repeat visits | Cache, service worker or client state | Cold versus warm navigation |
| Only post-login flow | Application route/state | Anonymous versus authenticated RUM |
| Only one geography | CDN, origin distance or third party | Region and network cohort |
| Only new release | Changed bundle, component or backend | Version and deployment annotation |
Diagnose LCP through its four subparts
LCP measures when the largest eligible content element in the initial viewport is painted. The candidate can differ by viewport, content and user, so capture the real element rather than assuming every page uses the Hero Image.
Every LCP can be separated into Time to First Byte, resource load delay, resource load duration and element render delay. Improve the largest evidenced subpart; compressing an image may not help when late discovery or client rendering is the real delay.
| LCP subpart | Evidence | Common cause | Focused response |
|---|---|---|---|
| TTFB | Document response begins late | Origin work, redirects, cache miss, network distance | Cache HTML, reduce backend work, remove redirect, use suitable CDN |
| Resource load delay | LCP request starts long after TTFB | CSS background, JS injection, lazy load, parser blockage | Discover in initial HTML, remove lazy load, use priority/preload only when justified |
| Resource load duration | Request itself takes too long | Oversized image/font or slow asset host | Responsive dimensions, compression, modern format, cache and delivery |
| Element render delay | Resource arrived but element paints late | Render-blocking CSS, font, hydration, animation or hidden state | Reduce blocking work and render main content earlier |
Apply LCP changes without creating new problems
For an image LCP, expose a crawlable src/srcset in initial HTML, request the right dimensions and avoid lazy loading. A deliberate fetchpriority="high" or preload can help a genuinely critical late-discovered resource, but preloading many files competes for bandwidth.
For text LCP, inspect font and CSS delivery. A faster TTFB also gives every discovered resource an earlier start. Use the Image SEO guide for responsive image and intrinsic-size decisions.
- Record the LCP element and four subparts.
- Test cold and warm cache conditions.
- Keep the primary resource in the initial document when possible.
- Do not lazy-load the LCP image.
- Serve dimensions appropriate to rendered size and DPR.
- Preload only an identified critical resource.
- Verify text remains visible during font loading.
- Check Mobile viewport, not Desktop only.
- Retest redirects, CDN cache and third-party Hero content.
Diagnose INP across the whole visit
INP observes qualifying Click, Tap and Keyboard interactions across a page visit and reports a high-latency interaction, normally the longest while allowing an outlier for pages with many interactions. A page with no qualifying interaction has no INP value.
Interaction latency has three parts: input delay before callbacks run, processing duration of event callbacks, and presentation delay until the next frame. Diagnose the slow part and target; a fast first click cannot prove the whole experience is responsive.
| INP part | What delays it | Evidence | Typical response |
|---|---|---|---|
| Input delay | Existing long task, script evaluation, timers or overlapping work | Interaction trace and load state | Reduce startup JavaScript, split/yield work, control recurring tasks |
| Processing duration | Heavy event callback or synchronous calculation | Event timing and call stack | Do less in handler, move/defer noncritical work |
| Presentation delay | Large DOM update, style/layout/paint or framework render | Rendering work after callback | Update smaller regions, reduce DOM/layout cost and animation work |
| Iframe interaction | Widget has its own main thread but shares constrained device resources | Frame target and provider trace where possible | Delay, replace, isolate or renegotiate third-party behavior |
Test the interactions users actually perform
Lighthouse load audits cannot discover every slow Menu, Search, Filter, Checkout, Form Validation or Chat interaction. Use field attribution to identify slow targets and interaction types, then reproduce them on constrained hardware with the DevTools Performance panel.
Break long tasks and yield after the urgent UI update so the browser can paint; defer Analytics, Save, Spellcheck or other secondary work. Avoid rendering huge DOM regions after a small action. Rendering choices are also covered in the JavaScript SEO guide.
- Open and close navigation, Mega Menu and Dialog.
- Type in Search and apply filters.
- Expand FAQ or Accordion items.
- Validate and submit lead or checkout forms.
- Accept and reject consent choices.
- Open WhatsApp, Chat or embedded tools.
- Test an interaction during page startup.
- Use low- or mid-tier Mobile conditions.
- Record target, type, load state and three INP subparts.
Diagnose CLS throughout the page lifetime
CLS is a unitless score based on how much visible content moves and how far. It uses the worst session window of layout shifts, with a one-second gap and a five-second cap—not simply everything before the load event.
Some movement within 500 milliseconds of a qualifying input can be considered expected. Scroll and hover are not qualifying inputs, so shifts caused while scrolling or hovering can still count. CrUX can include user-visible iframe shifts that page JavaScript RUM cannot always observe.
| CLS source | Why it shifts | Evidence |
|---|---|---|
| Image/video without dimensions | Browser learns size after content is laid out | Layout Shift track and element attributes |
| Ad/embed/widget | Late creative uses unknown or different height | Field target, slot lifecycle and provider timing |
| Injected banner/content | New block appears above existing content | Post-load and scroll flow |
| Web font | Fallback and final font use different metrics | Font waterfall and text shift |
| Animation/transition | Layout properties change geometry | DevTools rendering/animation trace |
| Back/forward or long-lived page | Later lifecycle state is missed by load-only testing | RUM, pageshow and full journey |
Reserve space and control late content to improve CLS
Give images and videos intrinsic width/height or a correct aspect-ratio. Reserve realistic space for ads and embeds, and decide whether empty slots collapse before—not after—the surrounding content settles.
Use a metric-compatible fallback font or font-display strategy, and animate with transform and opacity where appropriate. Consent or promotion UI can overlay without pushing content, but must remain accessible and must not hide the main task.
- Load each Template at Mobile and Desktop widths.
- Scroll through lazy images, ads and embeds.
- Open menus, accordions, filters and validation errors.
- Trigger consent, promotion, chat and localization UI.
- Test web fonts under cold cache and slow network.
- Use Back/Forward navigation.
- Check hover and responsive breakpoint changes.
- Capture the shifted element and the element that caused it.
Treat third-party code as a product decision
Tag managers, ads, consent platforms, chat, heatmaps, A/B tools, social embeds and video players can affect all three metrics. A third party may delay an LCP request, occupy the main thread during an interaction or resize an unreserved container.
Inventory owner, purpose, load rule, data destination and performance cost. Load after consent or intent when appropriate, reserve UI space and remove duplicate tags. If the business keeps a costly feature, document the tradeoff instead of hiding it with a score-only workaround.
| Decision | Question |
|---|---|
| Keep | Does it support a measured user or business outcome? |
| Delay | Can it load after consent, idle time, viewport proximity or explicit intent? |
| Restrict | Can it run only on Templates that need it? |
| Replace | Is a lighter provider or static preview sufficient? |
| Remove | Is it unused, duplicated, expired or ownerless? |
| Monitor | Can version, load failure and CWV attribution be observed? |
Fix the platform rule, not only the generated page
In WordPress and page builders, common causes include oversized source images, multiple optimization plugins, uncached HTML, global animation, font variants, slider Heroes, plugin JavaScript, duplicated analytics and DOM-heavy Components. Start with the responsible Template, Theme or Plugin setting and confirm output; do not stack more plugins before finding the cause.
On custom sites, treat Route data, image Component defaults, code splitting, hydration boundaries, CSS delivery and CDN caching as shared rules. Preserve useful functionality and test updates, forms, analytics, accessibility and SEO output after performance changes.
| Symptom | Platform-level place to inspect |
|---|---|
| Same large Hero on every page | Media pipeline and responsive image Component |
| Slow uncached first response | Page cache, origin, database and CDN policy |
| Poor INP after consent | Tag manager, CMP callbacks and vendor scripts |
| CLS on every Card | Shared image dimensions and skeleton Component |
| Fast staging, slow production | Ads, analytics, CDN, personalization and consent |
| Improvement only with plugin disabled | Plugin function and alternatives—not a permanent blind disable |
Use first-party RUM when aggregates cannot explain the issue
The web-vitals library can collect LCP, INP and CLS using definitions aligned closely with Google tooling and its attribution build can record useful debug targets and subparts. Capture route/Template, metric ID, value, rating, navigation type, release version and a privacy-safe target or component label.
Send at appropriate lifecycle points and avoid unreliable unload/beforeunload dependence. Sampling, consent, retention and data minimization must follow the site’s privacy obligations. RUM and CrUX may differ because of population, iframe visibility, browser APIs, SPA attribution and aggregation.
| RUM field | Why it matters | Privacy/control |
|---|---|---|
| Template/route group | Find shared failures | Prefer normalized path; strip personal parameters |
| Release version | Separate cached and new code | Use non-personal build ID |
| Metric value/rating/id | Aggregate and deduplicate correctly | Avoid session identity unless justified |
| Attribution target | Find LCP/INP/CLS component | Use safe component label, not user text |
| Navigation/device context | Explain cold, bfcache and constrained journeys | Keep only necessary coarse dimensions |
| Business event link | Measure task outcome | Use governed analytics and consent |
Prioritize performance as a business and accessibility decision
Start with Poor before Needs Improvement, Mobile before Desktop when that is where the audience and failures are, high-value journeys before low-value archives, and shared Template causes before isolated URLs. Also account for users on slower devices, assistive technology and networks that averages can hide.
A performance budget is a release guardrail, not a promise that a byte count equals experience. Set limits tied to proven causes—for example maximum Hero bytes, third-party execution, route JavaScript or layout shifts—and retain UX, accessibility and conversion gates.
| Priority signal | Higher priority when |
|---|---|
| Status/severity | Poor, recurrent and visible to many visits |
| Template reach | One cause affects many indexable or transactional URLs |
| Journey value | Lead, signup, purchase, reading or support task |
| Audience risk | Mobile, constrained devices or key region is disproportionately affected |
| Change confidence | Trace points to a controllable root cause |
| Regression risk | Fix can be staged, measured and safely rolled back |
Run a repeatable field-to-fix workflow
Store evidence, owner, risk and retest outcome in the SEO audit workflow. Performance should become a governed release discipline rather than an occasional plugin cleanup.
- Select metric, device, date range and affected group.
- Confirm URL versus origin CrUX scope and sample limits.
- Map examples to real Templates and journeys.
- Use RUM attribution or representative field evidence where available.
- Reproduce the route and interaction under matched lab conditions.
- Identify element, target, shift and metric subparts.
- Trace the server, network, asset, CSS, JavaScript or third-party cause.
- Choose the smallest coherent change and define success/guardrails.
- Implement on staging with a release version.
- Regression-test content, accessibility, analytics and conversion actions.
- Deploy gradually when risk warrants it.
- Monitor immediate lab/RUM signals, then wait for the CrUX window before closing.
Use release QA that protects more than a green score
| Gate | Pass condition | Evidence |
|---|---|---|
| Content | Main answer, media and CTA still useful | Visual/content review |
| Accessibility | Keyboard, focus, labels, motion and contrast remain usable | Manual + automated checks |
| SEO delivery | Status, Canonical, metadata, links, image and schema remain correct | Build/crawl samples |
| Analytics | Consent, pageviews and conversions are not duplicated or lost | Debug and production events |
| Performance | Target subpart improves without another Vital regressing | Matched lab trace + RUM canary |
| Resilience | Slow API, third party, cache miss and error states remain usable | Failure-path tests |
| Rollback | Previous version and configuration can be restored | Release record and owner |
Measure the change without overclaiming causality
Annotate the release and compare the same Device, Template, Navigation Type and business cohort. Immediate lab or RUM movement can confirm the mechanism; CrUX and Search Console move gradually because their 28-day window still contains pre-release visits.
Connect performance to the SEO measurement workflow: track CWV distribution, affected URLs, impressions, engagement and qualified conversions. A simultaneous design, content, campaign or ranking change prevents a simple “speed caused revenue” claim.
| Time horizon | Evidence | Decision |
|---|---|---|
| Before release | Baseline distribution, trace and business metric | Define target and rollback threshold |
| Minutes/hours | Synthetic checks, errors and canary RUM | Catch breakage or clear regressions |
| Days | Versioned RUM by Template/device | Confirm root-cause improvement in users |
| Up to/after 28 days | CrUX, PSI and Search Console trend | Verify eligible aggregate response |
| Ongoing | Performance budget and release monitoring | Prevent recurrence |
Common Core Web Vitals myths
- “A Lighthouse score of 100 means every user has a fast experience.”
- “PageSpeed Insights field and lab numbers should match.”
- “No CrUX data means the page is fast.”
- “Search Console reports a precise score for every URL.”
- “One optimized example fixes the whole URL group.”
- “Compressing the Hero always fixes LCP.”
- “Total Blocking Time is the same as INP.”
- “CLS ends when the page finishes loading.”
- “Any shift after a click is excluded.”
- “A performance plugin can identify every root cause.”
- “Removing JavaScript automatically improves the business journey.”
- “Passing CWV guarantees higher rankings or conversions.”
Frequently asked questions
What are the Core Web Vitals in 2026?
Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift remain the three current Core Web Vitals for loading, responsiveness and visual stability.
Are Core Web Vitals a Google ranking factor?
Google says its ranking systems use Core Web Vitals, but there is no single page-experience signal and strong scores do not guarantee top rankings.
Why does PageSpeed Insights show two sets of numbers?
The field section uses aggregated CrUX experiences from the previous 28 days; the lab section is a new Lighthouse simulation used for diagnosis.
Why does Search Console differ from PageSpeed Insights?
Search Console uses groups of similar URLs and the worst metric for group status. PSI generally shows one URL when enough data exists, otherwise origin data.
How long does a Core Web Vitals fix take to appear?
Lab and first-party RUM can move immediately. CrUX is a rolling 28-day aggregate, so old and new experiences mix until the window turns over.
Does every page need CrUX data?
No. New or low-traffic pages may not meet CrUX eligibility. Use representative Templates, RUM and lab checks without pretending “No data” is a pass.
Is LCP always the Hero Image?
No. It can be an image or text element and can differ by viewport and user state. Capture the actual candidate and its subparts.
Why can INP be poor when the page loads quickly?
INP measures interactions throughout the visit. Startup tasks, menus, forms, filters, large DOM updates and third-party widgets can be slow after the page looks loaded.
Why is field CLS worse than Lighthouse CLS?
Real visitors scroll, open UI, see ads, fonts, embeds and long-lived states that a load-only lab test may not exercise. CrUX can also observe some iframe shifts unavailable to page RUM.
Should we remove a useful feature to pass?
Only after weighing user and business value. First reduce, delay, isolate or replace the actual cost, then measure both performance and task outcomes.
Official references
- Google Search Central: Core Web Vitals and Search results
- Google Search Central: page experience in Search
- Google Search Console Help: Core Web Vitals report
- Google PageSpeed Insights: field and lab data
- web.dev: how Core Web Vitals thresholds are defined
- web.dev: Web Vitals measurement and tools
- web.dev: getting started with Web Vitals measurement
- web.dev: why lab and field data differ
- web.dev: debug performance in the field
- web.dev: optimize Largest Contentful Paint
- web.dev: optimize Time to First Byte
- web.dev: optimize Interaction to Next Paint
- web.dev: INP replaced FID as a Core Web Vital
- web.dev: diagnose slow interactions in the lab
- web.dev: find slow interactions in field data
- web.dev: optimize Cumulative Layout Shift
- web.dev: field measurement best practices
- Chrome DevTools: Performance panel reference
- Chrome UX Report: methodology and eligibility
- Chrome UX Report: tools, cadence and granularity
Share the affected template, PageSpeed result and recent releases. Jack can separate server, image, CSS, JavaScript and third-party causes, then define a measurable verification plan.
How Google Ranking Evolved: From PageRank to Modern Search SystemsSeptember 2, 2026
Google AI Content and SEO: What Is Allowed, What Is Spam, and How to Publish SafelySeptember 2, 2026
Google Florida Update (2003): What We Know, What Remains TheorySeptember 2, 2026