Core Web Vitals

Core Web Vitals are three measurements Google uses to judge the real experience of loading and using a web page: how fast the main content appears (LCP), how quickly the page responds to a tap (INP), and how steady the layout stays while it loads (CLS). They form part of the page experience signals in Google Search.

• LCP: Largest Contentful Paint, the time until the biggest image or text block is visible.
• INP: Interaction to Next Paint, the delay between a tap or click and the page's visible response.
• CLS: Cumulative Layout Shift, a score for how much content jumps around unexpectedly.
• Data: Scores come from real Chrome users visiting the site, not only from lab tests.
• Target: At least 75 percent of visits should have a "good" experience for each metric.

This lesson follows one example: an online store in Delhi selling phone cases, chargers and earphones. Most shoppers arrive on mid-range Android phones over mobile data, and pay with UPI at checkout. The owner noticed that many shoppers added items to the cart but left before paying.

Key Characteristics of Core Web Vitals

• User-centred: Each metric describes something a shopper actually feels: waiting, freezing or a jumping page.
• Field-based: Google assesses real visits collected from Chrome users, which is why a site with few visitors may show no data at all.
• Threshold-driven: Each metric has a "good" and a "poor" line, measured at the 75th percentile of visits.
• Grouped: Search Console groups similar URLs together, so one fix to a template can improve hundreds of pages.
• Evolving: Google changes the set over time; INP replaced First Input Delay as the responsiveness metric.

How Core Web Vitals Work

1. Visits are measured: When people browse the store in Chrome, the browser records how long loading, responding and shifting took, if they allow usage statistics to be shared.
2. Data is gathered: Google collects those measurements over a rolling window of about 28 days in the Chrome UX Report.
3. The 75th percentile is taken: For each metric, Google looks at the value that 75 percent of visits beat, so a few slow visits do not decide the score.
4. Thresholds are applied: LCP is good at 2.5 seconds or less, INP at 200 milliseconds or less, and CLS at 0.1 or less. Poor starts above 4 seconds, 500 milliseconds and 0.25.
5. Reports show the result: The Core Web Vitals report in Google Search Console and PageSpeed Insights show each URL group as good, needs improvement or poor.

Common Causes and Fixes

Example: Core Web Vitals for a Delhi Phone Accessories Store

• Finding: Search Console marked the mobile product pages as poor for LCP and CLS, and PageSpeed Insights showed the same problems in its field data.
• LCP cause: Every product page opened with an uncompressed photo several megabytes in size.
• CLS cause: A "Festive offer" banner loaded late and pushed the "Pay with UPI" button down, so shoppers sometimes tapped the wrong thing.
• INP cause: Three chat and review apps loaded on every page, and tapping "Add to cart" froze for a moment.
• Fixes: The team resized and compressed photos, reserved fixed space for the banner, removed two unused apps, and loaded the chat widget only after the page settled.
• Follow-up: Field data updates slowly, so the owner used Search Console's "Validate fix" option and checked again after four weeks, instead of trusting a single lab test.

Benefits of Good Core Web Vitals

• Conversions: A page that loads quickly and stays still is easier to buy from, especially at a UPI checkout on mobile data.
• Rankings: Page experience can help when competing pages are otherwise similar in relevance and quality.
• Trust: A page that does not jump or freeze feels safer when a shopper is about to pay.
• Focus: Clear thresholds give developers a specific target instead of a vague "make it faster".

Limitations

• Small signal: Great scores do not make up for weak or irrelevant content, and speed is only one part of technical SEO.
• Slow feedback: Field data covers several weeks, so improvements take time to appear in reports.
• Missing data: Sites and pages with little traffic may have no field data to judge.
• Lab confusion: PageSpeed lab scores vary between runs and devices, and chasing a perfect lab score wastes effort.

How AI Changes Core Web Vitals Work

What AI Automates Now

AI assistants can read a PageSpeed Insights report and explain in plain language which element is the LCP, which script blocks interaction, and which banner causes layout shift. They can also suggest code changes, such as adding image dimensions or deferring a script. AI coding tools can apply small fixes to a theme, which the Claude Code for marketers lesson covers.

What Still Needs a Human

Deciding which apps, pop-ups and trackers the business truly needs is a trade-off between features and speed. A person must also test the checkout on real, mid-range phones over mobile data, because a fix that looks good in a lab can still break the UPI payment flow.

Risk to Watch

AI-suggested code changes can remove a script the checkout depends on, or break tracking set up for conversion rate optimization. Always apply changes on a staging copy first and test a real payment before publishing.

Do It with AI

Use this prompt to turn a PageSpeed Insights report into a fix plan. It works in ChatGPT, Claude or Gemini.

1. Run PageSpeed Insights on a product page, a category page and the checkout.
2. Paste each report into the prompt along with the list of apps and scripts.
3. Apply the fixes on a staging copy and test a real UPI payment on a mid-range phone.
4. Publish, then check the Core Web Vitals report in Search Console after a few weeks.

Check Before You Use It

• Facts: Confirm the thresholds and each diagnosis against Google's own web.dev documentation and the actual report.
• Brand fit: Do not remove features customers rely on, such as size charts or delivery estimates, just to gain speed.
• Compliance: Keep the consent banner and privacy controls working when scripts are delayed or removed, as described in Consent Mode.