Most ranking signals are opaque — Google confirms they exist but rarely details how they work. Page experience signals are the exception. Google published all five explicitly, specified the thresholds, built a dedicated report for them in Search Console, and even announced the rollout timeline in advance. Passing these signals is one of the few places in SEO where you know exactly what's required.
The caveat: page experience signals act as a tiebreaker, not a primary ranking factor. A page with exceptional content and poor page experience will outrank a technically perfect but thin competitor. These signals matter most when content quality is roughly equal across competing pages — which in competitive SERPs, it often is.
Key Takeaways
- Page experience signals affect rankings as a tiebreaker — strong content still outranks technically perfect but thin pages; these signals matter most in competitive SERPs
- Core Web Vitals (LCP, CLS, INP) are the most complex of the five — they require ongoing monitoring because page changes can cause regressions
- HTTPS is the most binary signal — a site without an SSL certificate fails automatically; there's no partial credit
- Intrusive interstitials means pop-ups that cover the main content immediately after landing from search — legitimate modals (age verification, cookie consent) have explicit exceptions
- All five signals are reportable via Google Search Console — the Page Experience report shows a pass/fail summary for your site
Signal 1 — Core Web Vitals
The most complex page experience signal. Three metrics, each with pass/fail thresholds:
| Metric | Good | Needs improvement | Poor |
|---|---|---|---|
| LCP (Largest Contentful Paint) | < 2.5s | 2.5s–4s | > 4s |
| CLS (Cumulative Layout Shift) | < 0.1 | 0.1–0.25 | > 0.25 |
| INP (Interaction to Next Paint) | < 200ms | 200ms–500ms | > 500ms |
Google reports CWV as "Good," "Needs Improvement," or "Poor" in GSC. A URL must be "Good" on all three metrics to pass the CWV signal.
CWV scores come from real user data via the Chrome User Experience Report (CrUX). Lab measurements from tools like Lighthouse are useful for diagnosing regressions but don't directly affect ranking — field data does. A page with excellent Lighthouse scores but slow real-user LCP (due to geography, slow networks, or heavy JS hydration) will still fail the signal.
Of the three metrics, LCP is the most actionable. Common causes of slow LCP: unoptimised hero images with no explicit dimensions, render-blocking scripts delaying the first paint, slow TTFB pushing the entire waterfall later. The Page Speed Inspector identifies render-blocking resources and reports the LCP candidate image URL so you know exactly which element to optimise.
INP replaced FID (First Input Delay) in March 2024. FID only measured the delay before the browser could start processing an interaction; INP measures the full round-trip from interaction to visible response. Sites that passed FID may fail INP — particularly those with heavy main-thread JavaScript.
Signal 2 — HTTPS
Every page must be served over HTTPS (not HTTP). Four requirements must all be met:
- Valid SSL/TLS certificate installed
- Certificate covers the exact domain (including www and non-www variants as needed)
- Not expired
- No mixed content (HTTPS page loading HTTP subresources)
Check: visit your site and confirm the browser shows a padlock icon in the address bar. In the Page Speed Inspector, TTFB is measured over HTTPS — if the TLS handshake fails or shows an error, the HTTPS signal is failing.
HTTPS is the easiest signal to pass (it's binary, and most hosting providers handle it automatically) and the most permanently damaging if failed. No HTTP page qualifies for page experience ranking consideration. Mixed content — where the HTML is served over HTTPS but embedded images, scripts, or stylesheets use HTTP — is a subtler failure mode that won't show a browser warning on all browsers but still degrades the signal.
Signal 3 — Mobile-friendliness
Pages must render correctly on mobile devices. Google assesses this using its mobile crawler agent (Googlebot Smartphone). The four requirements:
<meta name="viewport" content="width=device-width, initial-scale=1">present in<head>- Content not wider than the screen (no horizontal scrolling on a 375px viewport)
- Text large enough to read without zooming (16px or larger recommended for body text)
- Touch targets — buttons, links, form inputs — at least 44×44px with adequate spacing between them
Check: GSC → Experience → Mobile Usability. Any URLs listed there are failing this signal. The report specifies the exact failure reason (viewport not set, content wider than screen, text too small, clickable elements too close together).
The missing viewport meta tag is the most common single cause of mobile usability failures — particularly on older sites or pages generated by legacy CMSes. A page with no viewport tag renders at desktop width on mobile, fails Google's mobile assessment, and is ineligible for the mobile-friendly ranking boost.
Signal 4 — No intrusive interstitials
Pop-ups and overlays that cover the main content immediately after a user arrives from search are penalised. Google specifically targets three patterns:
- Pop-ups that cover the main content immediately after landing from a search result
- Standalone interstitials the user must dismiss before accessing the page content
- Layouts where the above-the-fold area resembles an interstitial — the actual content is hidden below a large overlay
Exceptions — patterns Google explicitly does not penalise:
- Age verification modals (legal requirement for regulated content)
- Cookie consent notices
- Login dialogs on private or paywalled content
- App download banners that use a reasonable amount of screen space (not full-screen)
The practical rule: don't show a full-screen pop-up covering your content in the first seconds after a user lands from Google search. A timed pop-up (appearing after 30 seconds on-page) or a scroll-triggered overlay doesn't trigger this signal — Google's assessment happens at landing, not during the session. Exit-intent pop-ups are similarly safe because they fire when the user is already leaving.
There is no dedicated GSC report for this signal — Google has not automated detection of intrusive interstitials the way it has for mobile usability. Enforcement happens via manual and algorithmic review. The check is manual: load your pages from a simulated mobile viewport, note what appears in the first 3 seconds, and verify it doesn't block the main content.
Signal 5 — Safe browsing
Pages must not contain malware, deceptive content (phishing), or other security issues that Google's Safe Browsing system flags. This signal is rare for legitimate sites but is an absolute blocker — a site on the Safe Browsing list receives a browser warning before users even reach the page, and ranking is suspended.
The most common path to failing this signal: a site gets hacked and malicious code is injected. The site owner often doesn't know. Safe Browsing detection may happen days or weeks after the compromise.
Check: GSC → Security & Manual Actions → Security Issues. Any issues listed there indicate your site is flagged in Safe Browsing. Google also sends alerts via email if your GSC account is associated with the property.
If flagged: clean the malware or hacked content completely, verify the fix, then submit a reconsideration request in GSC. Google re-crawls and re-evaluates within a few days of a clean reconsideration request.
Checking all five signals
GSC → Experience → Page Experience provides the unified view. The report shows:
- Percentage of Good URLs (passing all Core Web Vitals)
- HTTPS usage across your site
- Mobile usability failures (count and reason breakdown)
Individual signals have their own dedicated reports for deeper investigation:
- Core Web Vitals: Experience → Core Web Vitals (separate tabs for mobile and desktop)
- HTTPS: Experience → HTTPS
- Mobile usability: Experience → Mobile Usability
- Safe Browsing: Security & Manual Actions → Security Issues
- Intrusive interstitials: No dedicated GSC report — requires manual review
CWV data in GSC is aggregated from the Chrome User Experience Report and updates weekly. Improvements you make today won't appear in GSC for 7–10 days. Use the Page Speed Inspector for immediate, per-request diagnostic data while you're working on fixes — then return to GSC to confirm the field data trend is moving in the right direction.
Common failure patterns and how to fix them
LCP above 2.5s. Most often caused by a slow TTFB (server not responding fast enough), a hero image that isn't preloaded or is served in an unoptimised format, or render-blocking scripts delaying the first contentful paint. Fix: check TTFB with the Page Speed Inspector, serve hero images as WebP/AVIF with explicit dimensions, add <link rel="preload"> for the LCP image.
CLS above 0.1. Usually caused by images without explicit width and height attributes (browser doesn't know how much space to reserve), web fonts causing FOUT that shifts text, or dynamically injected content above existing content. Fix: always set dimensions on images, use font-display: swap with a size-adjusted fallback font, avoid inserting content above existing elements after load.
INP above 200ms. Heavy JavaScript on the main thread. Long tasks block the browser from responding to input. Fix: break long tasks with scheduler.yield(), move non-critical JavaScript to Web Workers, reduce third-party script load on initial page render.
Mobile usability failures. Missing viewport meta tag or fixed-width layouts. Fix: add the viewport tag, audit your CSS for fixed pixel widths wider than 375px, and verify touch targets with DevTools device emulation.
Diagnose Your Core Web Vitals Performance
Free, no signup. The Page Speed Inspector measures TTFB, LCP candidate, render-blocking resources, and compression — the server-side signals that determine whether your pages pass Core Web Vitals.
Try the Page Speed Inspector Free →Affiliate disclosure: Some links on this page may be affiliate links. We only mention tools we've personally used and have an honest opinion about. Affiliate revenue helps keep ByteWaveNetwork's tools free and maintained. We are not paid by any of the tools compared in this article for favorable coverage.