Core Web Vitals, speed and mobile experience

Video lecture

Core Web Vitals, speed and mobile experience

13 chapters · about 8 min · full transcript

Coming soon

Chapter 1 of 13

Core Web Vitals and mobile

LCP, INP, CLS
Field vs lab data
Causes and fixes
Prioritising work

The narrated lecture is in production

Every chapter is scripted and ready. Browse the chapters and read the full transcript now — the video will appear here when it’s published.

Chapters

Transcript of the narration, chapter by chapter.

0:00 Core Web Vitals and mobile

Picture a shopper in Lahore on a mid range phone, on a patchy mobile connection, tapping your product page from search. The hero image takes four seconds to appear. The add to basket button jumps as an ad loads. They tap, and nothing happens for half a second. They leave. In this lecture you'll learn the three Core Web Vitals, how they're measured on real users, the common causes and fixes, and how to prioritise speed work across a site.

0:35 Why it matters

Why does page experience matter? Fast, stable, mobile friendly pages keep visitors engaged and convert better. Google uses page experience signals, including Core Web Vitals, as part of its ranking systems, though great content that best matches intent still matters most. Think of speed as a tie breaker for rankings, and a major factor for conversions and revenue.

1:00 The three Core Web Vitals

Here are the three metrics. LCP, Largest Contentful Paint, measures loading: how quickly the main content appears. Good is two and a half seconds or less. INP, Interaction to Next Paint, measures responsiveness: how quickly the page responds to taps and clicks. Good is two hundred milliseconds or less. It replaced First Input Delay in March twenty twenty-four. And CLS, Cumulative Layout Shift, measures visual stability. Good is point one or less. Google assesses them at the seventy fifth percentile of real visits, separately for mobile and desktop.

1:38 Field vs lab

Here's the key idea: field data versus lab data. Think of a car's fuel economy. The number in the brochure comes from a test track. The number you actually get depends on your roads and your driving. Lab data, from Lighthouse or the lab section of PageSpeed Insights, is the test track: great for debugging. Field data, from real Chrome users, shown in Search Console and PageSpeed Insights, is the real road. Field data is what counts for assessment. And test on mid range phones and slower networks, not just the office Wi-Fi.

2:18 Causes → fixes

Common causes and fixes. Slow LCP: huge hero images, so compress them, use modern formats, size them correctly and don't lazy load the hero. Also slow servers, so use caching and a CDN, and render blocking CSS and JavaScript. Poor INP: heavy JavaScript and long tasks, and too many third party widgets like chat, heatmaps and pixels, so audit and remove what you don't use. High CLS: images without dimensions, ads and banners pushing content down, and late loading fonts. Reserve space.

2:54 Mobile-first indexing

Mobile first indexing matters too. Google primarily uses the mobile version of a page for indexing and ranking. So make sure the same main content, headings, structured data and internal links exist on mobile as on desktop. Text must be readable without zooming, tap targets shouldn't be crammed together, and pop ups shouldn't cover the main content. And don't forget HTTPS everywhere and accessible design, like good contrast and labelled form fields.

3:25 Example 1 (simple, illustrative)

Worked example one, simple. A UK restaurant's mobile LCP is poor because a four megabyte hero photo loads first and a plugin lazy loads it. Compressing it to a modern format, sizing it for mobile and marking it high priority brings LCP into the good range in lab tests. Removing two unused tracking scripts improves INP. Setting image dimensions fixes a menu that jumped as photos loaded. Three small changes, one much better page.

3:57 Example 2 (illustrative)

Worked example two, realistic and illustrative. A Dubai fashion retailer has hundreds of pages failing Core Web Vitals. Where should developers start? The content lead ranks templates by organic clicks from Search Console, multiplied by the share of URLs failing in the Core Web Vitals report. The product template, with most revenue and most failing URLs, goes first. The blog template second. The about page, slow but rarely visited, goes last. One template fix improves thousands of URLs at once.

4:32 CrUX API hands-on

Here's a hands on tool. The Chrome UX Report API returns the same real user field data that powers PageSpeed Insights. The Python script in the lesson posts a URL and form factor, and prints the seventy fifth percentile values for LCP, INP and CLS. If a page doesn't have enough traffic, the API says so, and you can query the whole origin instead or use lab tests. Keep the API key in an environment variable, restricted to that API.

5:07 Third-party script audit

Let's pause on third party scripts, because they're the quiet killer of INP. A typical marketing site might load a chat widget, a heatmap tool, three advertising pixels, a cookie banner, a review widget and a social feed. Each one runs JavaScript on the main thread. Ask for each: who uses its data, and when did we last look at it? Remove what nobody uses, load the rest after the page is interactive or on user action, and use a tag manager with discipline. Marketing teams often own these scripts, so marketing can often fix INP.

5:49 Watch me do it: prioritise speed work

Watch me do it. I'll find where to start speed work for a Dubai fashion retailer. First, I open Search Console's Core Web Vitals report for mobile. It groups failing URLs: a product template with LCP issues, and a category template with CLS issues. Next, I take one example URL from each group and run it through the CrUX API script from the lesson. The product page's seventy fifth percentile LCP is well over the good threshold. The category page's layout shift is also over. Then I run PageSpeed Insights on the same product URL to see the lab details. The hero image is a large file, it's lazy loaded, and there are six third party scripts loading before the page is interactive. Now I prioritise. I export clicks by page from Search Console, map pages to templates, and multiply template clicks by the share of URLs failing. Product template first, category second. Then I write the brief for developers. Product: don't lazy load the hero image, serve it in a modern format at mobile size, and defer non essential scripts. Category: reserve space for the promo banner and set image dimensions. Finally, I note the date, because field data updates on a rolling window, and I'll recheck in four weeks.

7:21 Process + mistakes

A simple improvement process. Check Search Console's Core Web Vitals report to find groups of URLs with issues. Test representative URLs in PageSpeed Insights. Prioritise fixes by impact, templates first. Implement with developers and test on staging. Then wait for field data to update, because it's a rolling window of real visits, before re checking. Common mistakes: optimising only for a desktop lab score, lazy loading the hero image, piling on third party scripts, and hiding content on mobile.

7:55 Recap

Recap. Core Web Vitals are LCP, INP and CLS, measured on real users at the seventy fifth percentile. Field data counts, lab data debugs. Fix LCP with images and servers, INP by reducing JavaScript, and CLS by reserving space. Mobile pages need the same content. And prioritise templates by traffic and failure rate. Try this now. Run PageSpeed Insights on the mobile version of your three most important pages and write down the top two fixes for each.

Why page experience matters

Fast, stable, mobile-friendly pages keep visitors engaged and convert better. Google uses page experience signals, including Core Web Vitals, as part of its ranking systems, though great content that best matches intent still matters most. Think of speed as a tie-breaker for rankings and a major factor for conversions.

The three Core Web Vitals

Metric	Measures	"Good" threshold
LCP – Largest Contentful Paint	Loading: how quickly the main content (often a hero image or heading) appears	2.5 seconds or less
INP – Interaction to Next Paint	Responsiveness: how quickly the page responds to taps, clicks and key presses	200 milliseconds or less
CLS – Cumulative Layout Shift	Visual stability: how much content unexpectedly moves while loading	0.1 or less

INP replaced First Input Delay (FID) as a Core Web Vital in March 2024. Google assesses these at the 75th percentile of real user visits, separately for mobile and desktop.

Field data vs lab data

Field data comes from real users (for example the Chrome User Experience Report, shown in Search Console's Core Web Vitals report and PageSpeed Insights). This is what counts for assessment.
Lab data comes from simulated tests (Lighthouse, PageSpeed Insights lab section). Useful for debugging but not identical to real-world experience.

Many visitors in Pakistan, parts of the Gulf and elsewhere browse on mid-range phones and variable mobile networks. Test with throttled mobile settings, not only on a fast office connection.

Common causes and fixes

Slow LCP

Large, uncompressed hero images → compress, use WebP/AVIF, correct dimensions, and prioritise the hero image (do not lazy-load it).
Slow server response → better hosting, caching, a CDN.
Render-blocking CSS and JavaScript → defer non-critical scripts, inline critical CSS.

Poor INP

Heavy JavaScript and long tasks on the main thread → remove unused scripts, split code, defer third-party tags.
Too many third-party widgets (chat, heatmaps, multiple pixels) → audit and remove what you do not use; load others after interaction where possible.

High CLS

Images and videos without width and height → always set dimensions or aspect-ratio.
Ads, banners or cookie notices that push content down → reserve space.
Web fonts swapping late → use font-display strategies and preload key fonts.

Mobile-first indexing

Google primarily uses the mobile version of a page for indexing and ranking. Ensure:

The same main content, headings, structured data and internal links exist on mobile as on desktop.
Text is readable without zooming and tap targets are not too close together.
Pop-ups do not cover the main content on mobile (intrusive interstitials harm experience).

Other page experience basics

HTTPS across the site.
No deceptive or intrusive interstitials.
Accessible design: sufficient colour contrast, labelled form fields and logical heading order also help usability.

A speed improvement process

Check Search Console's Core Web Vitals report to find groups of URLs with issues.
Test representative URLs in PageSpeed Insights.
Prioritise fixes by impact (templates used by many pages first).
Implement changes with developers or plugins; test on staging.
Wait for field data to update (it is based on a rolling window of real visits) and re-check.

Worked example (illustrative)

A UK restaurant site's mobile LCP is poor because a 4 MB hero photo loads first and is lazy-loaded by a plugin. Compressing it to a modern format, sizing it for mobile and marking it as high priority brings LCP into the "good" range in lab tests. Removing two unused tracking scripts improves INP. Setting image dimensions fixes a menu that jumped as photos loaded (CLS).

Hands-on: pull real-user Core Web Vitals with the CrUX API

The Chrome UX Report (CrUX) API returns the same real-user field data that powers PageSpeed Insights, for URLs or whole origins with enough traffic. Create an API key in Google Cloud (restrict it to the CrUX API) and keep it in an environment variable:

import os
import requests

API = "https://chromeuxreport.googleapis.com/v1/records:queryRecord"
key = os.environ["CRUX_API_KEY"]

def p75(url: str, form_factor: str = "PHONE") -> dict:
    r = requests.post(f"{API}?key={key}", json={"url": url, "formFactor": form_factor}, timeout=20)
    if r.status_code == 404:
        return {"url": url, "note": "not enough real-user data"}
    r.raise_for_status()
    m = r.json()["record"]["metrics"]
    get = lambda name: m.get(name, {}).get("percentiles", {}).get("p75")
    return {"url": url,
            "LCP_ms": get("largest_contentful_paint"),
            "INP_ms": get("interaction_to_next_paint"),
            "CLS": get("cumulative_layout_shift")}

for u in ["https://www.example.com/", "https://www.example.com/menu/"]:
    print(p75(u))

Compare the p75 values with the thresholds above (LCP ≤ 2,500 ms, INP ≤ 200 ms, CLS ≤ 0.1). Pages without enough traffic return no URL-level data — use the origin ({"origin": "https://www.example.com"}) or lab tests instead.

Prioritising speed work as a content strategist

You rarely fix Core Web Vitals yourself, but you decide where developer time goes. Rank templates by organic clicks (Search Console) × share of URLs failing (Core Web Vitals report). A failing product template with 10,000 URLs and most of your revenue beats a slow "about us" page every time. For deeper performance engineering, see Technical SEO Mastery (technical-seo-mastery).

Common mistakes

Optimising only for a desktop lab score.
Lazy-loading the hero image.
Piling on third-party scripts.
Hiding content on mobile that exists on desktop.

Core Web Vitals are LCP (≤ 2.5 s), INP (≤ 200 ms) and CLS (≤ 0.1), measured on real users at the 75th percentile.
Field data counts for assessment; lab data is for debugging. Test on mid-range phones and slower networks.
Fix LCP with image and server optimisation, INP by reducing JavaScript and CLS by reserving space for elements.
Google uses mobile-first indexing, so mobile pages need the same key content and a usable layout.

Run PageSpeed Insights on the mobile version of three important pages. Record LCP, INP and CLS field data (if available) and list the top two fixes for each page.

Enrol for free to save your progress

Reading is always free. Enrol to keep your place, take the final assessment and earn a verifiable certificate.

Core Web Vitals, speed and mobile experience