Skip to content
Log inTest my visibilityStart free trial
Log in
Language English
Start free trial Test my visibility

Display the page’s main content quickly on mobile

Technical Updated Oct 4, 2026

Description

This criterion measures the page’s speed under the conditions of an average phone: iPand loads it once, cold, on a simulated Pixel 7, with the slowed network and CPU of Lighthouse’s mobile profile. It records when the largest visible element is displayed (LCP) and how long scripts block the page (TBT); the server response time (TTFB) is measured when the page is fetched directly.

This is a lab measurement, not the speed your real visitors experience (Chrome UX Report).

Why it matters for AI engines

Google recommends providing a good page experience to appear in its AI features, and display speed is part of it. A slow server also holds back crawling: when response times get longer, Google crawls fewer pages of your site.

  • LCP marks the moment the main content becomes visible: web.dev rates it good at 2.5 s or less.
  • TTFB is not a Core Web Vital, but web.dev advises staying at 0.8 s or less: the rest of the load waits for the server’s response.
  • Every JavaScript task longer than 50 ms blocks the page; TBT adds up these blocks and points to a page that responds poorly to visitors’ actions.

How to fix it

  1. 1 Speed up the main element LCP must not exceed 2.5 s; it is the measurement that weighs most in the criterion. Find the main element, often the image at the top of the page or the first heading. Serve it at the right size and in a light format, do not lazy-load it (loading=lazy) and preload it if the browser discovers it late.
  2. 2 Make the server respond faster The server must send the first bytes of the page in 0.8 s or less. Cache pages on the server or on a CDN, avoid redirects before the page and lighten the work done on each visit, such as database queries or CMS plugins.
  3. 3 Defer non-essential scripts TBT must not exceed 200 ms. Load scripts with defer or async, remove third-party scripts you no longer need (widgets, duplicate tracking tools) and split long processing. The part of each task beyond 50 ms adds to TBT.
  4. 4 Keep a margin below the thresholds Test the page with Lighthouse or PageSpeed Insights in mobile mode, under conditions comparable to iPand’s. A value within ±10% of a threshold keeps the verdict of the previous analysis, so that the status does not flip from one day to the next: aim well below.

Key takeaway

iPand judges the page as an average phone would see it: main content in 2.5 s, server in 0.8 s, script blocking of 200 ms at most. Keep a margin below these thresholds for a stable verdict.

Further reading