Page experience: what Google says is used in ranking, and what is not

“Page speed is a ranking factor” sits in many technical SEO guides, usually next to HTTPS and mobile friendliness, as if all three worked the same way. Google’s documentation separates them more carefully, and the difference decides where effort should go.

This article sets out what Google says about page experience, Core Web Vitals, mobile-first indexing and HTTPS, and how to read the measurements. Where we give our own reading, we say so.

There is no single page experience signal

Google’s page experience documentation says its core ranking systems look to reward content that provides a good page experience, and that site owners should not focus on only one or two aspects. It offers a self-assessment: pages with good Core Web Vitals, served securely, displayed well on mobile, free of excessive ads and intrusive interstitials, and designed so the main content is easy to tell apart.

It lists resources for measuring the rest, including Chrome Lighthouse for improvements such as mobile usability, and Chrome’s own check of whether a site’s connection is secure. Its FAQ is direct. There is no single signal. Core Web Vitals are used by its ranking systems, and beyond them, other page experience aspects do not directly help a site rank higher, although they can make it more satisfying to use, which is aligned with what its systems seek to reward.

The three Core Web Vitals and their targets

Google’s Core Web Vitals documentation names three metrics. Largest Contentful Paint measures loading, with a target of within 2.5 seconds of the page starting to load. Interaction to Next Paint measures responsiveness, with a target of less than 200 milliseconds. Cumulative Layout Shift measures visual stability, with a target of less than 0.1.

The web.dev guidance adds how to judge them: measure the 75th percentile of page loads, segmented across mobile and desktop, and treat a page as passing only if it meets the targets for all three. It also notes that the set evolves: a stable metric can be retired and replaced, as happened when INP replaced the earlier First Input Delay measure in 2024. Google highly recommends good Core Web Vitals for success with Search, but also says good scores do not guarantee a top position, and that chasing a perfect score purely for SEO may not be the best use of time.

Lab data and field data

The PageSpeed Insights documentation separates two kinds of data. Lab data comes from a controlled test, is useful for debugging, but may not capture real-world bottlenecks. Field data comes from real users, drawn from the Chrome User Experience Report over the previous 28 days. PageSpeed Insights sorts results into Good, Needs Improvement and Poor. A page may lack enough field data, for instance because it is recently published, in which case PageSpeed Insights falls back to the whole site, and sometimes shows none. Our reading: use field data to judge whether there is a problem and lab data to find its cause.

Reading the Search Console report

The Core Web Vitals report is built on field data. It groups similar URLs and sets each group’s status by its worst-performing metric, so one poor measure makes the group poor. Only indexed URLs appear, and it is a sample, not a complete list. Its chart counts each URL once, for its slowest issue, while its table counts every issue, so the two totals can differ. A group without enough data for both LCP and CLS is left out. A new property may show no data for a few days while the underlying dataset catches up. Data from all visitors is combined, so a large audience on slow connections can pull results down.

Mobile: what Google indexes

Google’s mobile-first indexing guidance says it uses the mobile version of a site’s content, crawled with its smartphone agent, for indexing and ranking. A mobile version is not required to be included, but is very strongly recommended, and responsive design is the pattern Google recommends. For separate mobile versions it advises the same robots meta tags, the same primary content and headings, and not loading primary content only on interaction, because Google will not load content that needs swiping, clicking or typing. If a mobile page carries less content than the desktop one, Google says to expect some traffic loss under mobile-first indexing, and suggests moving content into accordions or tabs rather than removing it.

Secure pages, interstitials and ads

Google’s HTTPS report help says it strongly recommends HTTPS to protect users’ security and privacy, and that when a page has both HTTP and HTTPS versions, it prefers to index the HTTPS one. The report, available for Domain and HTTPS URL-prefix properties, shows how many indexed URLs are HTTP and how many HTTPS, and flags errors such as an HTTP page declaring itself canonical when an HTTPS version exists, and warns that many HTTPS errors can prompt Google to stop crawling HTTPS pages. Ads and interstitials appear in the self-assessment. Under the FAQ above, they are not described as direct ranking levers.

Where to spend the effort

Our reading of the documentation: start with field data for the templates that matter, fix any Core Web Vitals that fail at the 75th percentile, and treat HTTPS, mobile parity and unobtrusive layouts as hygiene that makes a site better to use. Google also says its self-assessment questions do not cover every aspect of page experience, so the list is a starting point, not a checklist to complete. Beyond the targets, performance work competes with everything else, and Google itself says content and the wider experience matter.

Where this fits at Cultured Digital: performance as one input

Our rendering guide treats performance as one input among many. On builds, our websites page states that performance is budgeted, not hoped for, alongside semantic HTML and content in the HTML. See also our piece on image SEO, where image weight and lazy-loading meet performance.