Mobile page speed: the version of your site that Google reads

Google uses mobile-first indexing. As of 2023 the smartphone crawler is the one that reads your pages. The mobile experience is the one that ranks.

Search Console and PageSpeed Insights show field data from real Chrome users. The mobile slice is the one that matters first for search. Desktop comes after.

Your laptop hides problems a mid-range phone shows. The CPU is slower. The network is spiky. Scripts take longer. Images made for desktop choke the radio.

PageSpeed Insights has two parts. The top is field data from the Chrome User Experience Report over 28 days. The bottom is a lab run from Lighthouse.

A small URL may show origin-level data or none. That is normal when traffic is low. Test a busier template too, like "/blog" or "/pricing".

Lighthouse emulates a mid-range phone on throttled 4G. It limits CPU and network to expose mobile bottlenecks. One run is noisy, so expect variance.

Its performance score, version 10 and later, weighs Total Blocking Time 30 percent, LCP 25, CLS 25, First Contentful Paint 10 and Speed Index 10. Scores vary between runs and are not a ranking factor.

A page that feels instant on a laptop can fail on a phone. Reasons: heavy JavaScript, too many third parties, an oversized hero image, web fonts that block text, or server time on first byte. Fix those for mobile, the score follows.

The three Core Web Vitals as of 2026 decide your pass or fail. Aim to meet them at the 75th percentile of field data on mobile.

• Largest Contentful Paint: good up to 2.5 s, poor above 4 s. Usually your hero image or a headline.
• Cumulative Layout Shift: good up to 0.1, poor above 0.25. Measures visible jumps.
• Interaction to Next Paint: good up to 200 ms, poor above 500 ms. Measures your slowest interaction in a visit.

In PageSpeed Insights, check the Mobile tab. The field section says Pass or Fail on the Core Web Vitals assessment. That line is what matters for search visibility, not the lab score below it.

Find the LCP element in Lighthouse. It names the node. On mobile it is often an oversized hero image discovered too late or lazy-loaded by mistake.

1. 1

   Remove lazy loading from the hero

   Do not use loading=lazy on the LCP image. It delays first paint. Add fetchpriority=high on it so the browser starts the fetch early.

2. 2

   Preload CSS backgrounds used for the hero

   If the hero is a CSS background, add a <link rel="preload" as="image"> for it. Keep the URL in the HTML so discovery is not delayed.

3. 3

   Make images responsive and small

   Use srcset and sizes. Serve AVIF or WebP when supported. Crop desktop art for narrow viewports so phones do not fetch oversized files.

4. 4

   Cut TTFB

   Cache or pre-render HTML. Serve from a CDN near users. Use HTTP/2 or HTTP/3 and keep-alive. Avoid redirect chains and add 103 Early Hints if you can.

5. 5

   Inline the critical CSS

   Inline only what is needed for the first viewport. Load the rest with media=print and swap onload. Remove unused CSS so the byte cost is low.

A fixed page like "/" will paint the product screenshot within the good LCP range on a phone, with the request for the hero image in the first flight and no lazy flag on it.

CLS stacks up in session windows. Elements that appear late or resize cause jumps. On small screens one bar can push everything down by a lot of pixels.

• Give width and height or aspect-ratio to every img, video, iframe and ad slot.
• Reserve space for dynamic slots with min-height, including announcement bars and consent banners.
• Use overlays for notices instead of injecting a banner above the content.
• Match font metrics on the fallback: size-adjust and ascent-override avoid jumps when the web font swaps.
• Animate with transform and opacity, not layout properties like height or top.
• Do not insert new content above the fold after load. Append below or in an overlay.

If "/pricing" shifts when the promo bar appears, measure its height and reserve it with CSS from the first paint. Your CLS will drop below 0.1 on mobile when the bar no longer moves content.

INP replaced FID in March 2024. It measures the slowest tap, click or key press over the visit. Phones struggle when the main thread is busy or handlers are heavy.

• Break long tasks. Use scheduler.yield or setTimeout to yield back to the browser.
• Render the visual change first, then do the heavy work. Show the menu instantly, fetch after.
• Ship fewer and smaller scripts. Remove dead code. Load non-essentials after load.
• Move expensive work off the main thread with web workers.
• Reduce DOM size and avoid sync layout reads after writes.
• Tame hydration of large frameworks. Split routes, island-ise components or delay hydration until interaction.
• Keep third-party handlers light. Consent, chat and A/B tools can block taps if they run on every click.

On "/checkout", make the Pay button change state immediately on tap, then process. If the handoff is under 200 ms on a phone, you will pass INP comfortably even under load.

Stylesheets block rendering. Synchronous scripts block parsing. Third-party code often blocks both. On mobile the cost is multiplied by CPU and radio limits.

• Inline critical CSS for the first viewport. Load the rest non-blocking with media=print and onload.
• Defer or async scripts. type=module defers by default. Remove @import and unused CSS.
• Fonts: set font-display swap or optional. Preload the one face used above the fold with rel=preload as=font and crossorigin. Self-host WOFF2. Subset with unicode-range. A variable font can replace several files. Or use a system stack to ship nothing.
• Keep the tag manager container small. Remove tags nobody uses. Load embeds on interaction with a facade. Defer analytics and chat until after load. Preconnect only to origins you truly need early.

A fixed "/guides/getting-started" will render above the fold CSS inline, load the docs bundle with defer, and replace the YouTube iframe with a click-to-load placeholder. The page will keep interactivity snappy on a phone data plan.

Lab runs are a compass, not a verdict. Verify on a physical phone on a busy network. Your thumbs and eyes catch what a bot misses.

1. 1

   Run PageSpeed Insights for the URL

   Open pagespeed.web.dev, paste the URL, pick Mobile. Read the field section. If the Core Web Vitals assessment fails, collect the metrics and start from the slowest.

2. 2

   Profile with Lighthouse

   Scroll to Diagnose performance issues. Expand the audits. Note the LCP element, the render-blocking list, and third-party summary. Run it more than once to see variance.

3. 3

   Test on a phone you own

   Use Chrome on Android or Safari on iOS. Toggle a slow connection via your network or a hotspot. Time first paint and first interaction by feel and a stopwatch.

4. 4

   Use Chrome DevTools for mobile-like runs

   Open DevTools, set Network to Slow 4G and enable a CPU slowdown. Record a Performance trace. Look for long tasks, layout thrash and the LCP event.

5. 5

   Track field data in Search Console

   Open the Core Web Vitals report. Focus on mobile groups. Fix templates that affect many URLs first. Re-test after deploy and watch the next 28 days settle.

Write down a target per template. For "/", LCP under 2.5 s, CLS under 0.1 and INP under 200 ms on mobile. Ship in small steps and recheck the field data after each release window.

Phones have weaker CPUs. JavaScript that feels quick on a laptop can take far longer on a mid-range device. That blocks taps and delays paint.

Networks are slower and spikier. A large hero image loads late on 4G. A web font from a third-party host waits on DNS and TLS before bytes arrive.

Layouts are tighter. A sticky header appearing late can shift the entire viewport. Desktop may hide the move. Mobile will show it clearly in CLS.