Google's "page experience" signals have been a topic of confusion and speculation since they were announced in 2020. Some signals are confirmed. Some are strongly implied. Some people cite as ranking factors are based on misreading a Google blog post or a correlation study that doesn't prove causation.
Here's a clear breakdown of what's actually confirmed and what the evidence shows.
The Confirmed Page Experience Signals
Google has explicitly named these as ranking signals. Not implied, not hinted at — officially confirmed:
Core Web Vitals
Since the Page Experience update rolled out in 2021, Core Web Vitals are a ranking signal measured via field data (real Chrome users). The three metrics:
- LCP (Largest Contentful Paint): Good = under 2.5 seconds. Measures when the main content loads visually.
- CLS (Cumulative Layout Shift): Good = under 0.1. Measures visual stability during loading.
- INP (Interaction to Next Paint): Good = under 200ms. Replaced FID in March 2024. Measures how responsive the page is to all user interactions, not just the first.
INP replacing FID was significant. FID only measured the first interaction. INP measures every interaction throughout the page lifetime, which means React-heavy apps that felt fast initially but lagged during continued use now fail where they used to pass. Most sites that were passing CWV before 2024 need to recheck their INP scores.
HTTPS
Confirmed as a lightweight ranking signal since 2014. Not having HTTPS in 2025 is essentially a technical error — every major hosting platform provides free SSL via Let's Encrypt. Chrome shows "Not Secure" warnings for HTTP pages, and that user trust signal compounds the ranking signal.
Mobile-Friendliness
Google moved to mobile-first indexing for all sites in 2023. Google crawls and indexes the mobile version of your site. If your mobile experience is broken or missing content, that's what Google sees. Mobile-friendliness is less of a "signal" and more of a baseline requirement at this point.
No Intrusive Interstitials
Google confirmed in 2017 that intrusive interstitials are a negative ranking signal — specifically, pop-ups that block the main content immediately on mobile. Full-screen ads that appear before you see the page content, overlays that are difficult to dismiss, and interstitials that cover more than about 30% of viewport on mobile all qualify. Cookie consent banners and age verification overlays are explicitly exempted.
What Google Has Said About Engagement Signals
This is where the debate lives. Do bounce rate, time on page, and dwell time affect rankings?
The honest answer: Google has not confirmed these as direct ranking signals. John Mueller and other Googlers have explicitly said they don't use Google Analytics data for rankings. The leaked Google API documents from 2024 mentioned "navBoost" (a system for adjusting rankings based on click data), which is plausible and consistent with what a lot of practitioners have observed, but wasn't officially confirmed as a final ranking factor.
My view: Google almost certainly uses some form of click and engagement signals for quality assessment at the system level, but it's not as simple as "high bounce rate = lower rankings." A page about a bus schedule that users visit, get the time, and leave in 5 seconds has a high bounce rate and short session duration. That's a successful interaction, not a quality failure.
Fix LCP First
If I had to give one practical recommendation from all this, it's that LCP is where most sites fail and where the most ranking impact lives.
The data on CWV performance is consistently discouraging: in 2024, roughly 60% of mobile sites still fail LCP. It's the hardest of the three metrics to pass because it's affected by server response time, render-blocking resources, and image loading all at once.
The most common LCP failures and how to fix them:
The LCP element is a large unoptimized image. Convert it to WebP or AVIF. Add fetchpriority="high" to the img tag. Add a <link rel="preload"> tag in the head pointing to the image.
TTFB is too high (over 600ms). LCP can't be fast if the server is slow to respond. A CDN, server-side caching, or switching to static generation (where applicable) addresses this. A server responding in 1.5 seconds makes a 2.5s LCP target nearly impossible.
Render-blocking JavaScript or CSS delays when the browser can paint. Defer non-critical JS. Inline critical CSS. Remove or async-load third-party scripts that aren't needed before paint.
JavaScript Loading and CLS
CLS failures are nearly always caused by content being injected after the initial render: images loading without reserved space, ad slots expanding, fonts causing text reflow, or third-party widgets inserting content after load.
The fix for images: always set explicit width and height attributes. The browser reserves the space before the image loads, preventing the shift.
For ad slots: set a min-height on the container equal to the ad's expected height. The slot stays empty until the ad loads rather than shifting everything down.
For web fonts: use font-display: optional if preserving layout stability is more important than showing your custom font immediately. Or font-display: swap with a fallback font that has similar metrics to reduce the reflow extent.
INP: The New Hard Problem
INP replaced FID in March 2024 and a lot of teams were caught off guard. FID only measured the first interaction — typically, how fast the page responded to the first click or tap. INP measures every interaction throughout the entire page session and reports the worst one (after removing statistical outliers).
React applications are disproportionately affected. Heavy re-renders, large component trees, and synchronous state updates that block the main thread all show up as INP failures that never appeared in FID scores.
The practical fix for most React sites: use React.startTransition for non-urgent state updates, reduce the component tree depth for frequently-updated components, and audit third-party scripts that register their own event listeners (these compete for main thread time on every interaction).
For non-React sites, the INP checklist is simpler: identify and break up any JavaScript tasks over 50ms, move heavy computations to web workers, and reduce the size and scope of event handlers.
The Realistic Priority Order
If you're working through page experience improvements for the first time:
Start with TTFB. If your server is slow, nothing else matters much. Then LCP — it's where the most sites fail and where the ranking signal is clearest. Then CLS — usually fixable with specific, targeted changes rather than architectural rework. INP last — it's real, it's confirmed, but it typically requires deeper JavaScript changes than the other three.
HTTPS and mobile-friendliness should already be done. If they're not, fix them today before anything else.
FAQ
Does Google use bounce rate as a ranking factor?
Not directly confirmed, and Google doesn't have access to your Google Analytics data for ranking purposes. But Google does have its own click data from Chrome and Search, and likely uses it in ways that correlate with what we'd call engagement. Focus on making pages actually useful rather than trying to game engagement metrics.
My Lighthouse score is 95 but my Core Web Vitals are still failing in Search Console. Why?
Lighthouse uses lab data (simulated). Google Search Console shows field data (real users). Third-party scripts that only load in real browser sessions (chat widgets, A/B testing tools, analytics) can cause field CWV failures that never appear in Lighthouse. The field data is what Google uses for rankings.
If I pass all Core Web Vitals, will I rank better?
Passing CWV removes a small negative signal. It doesn't create a positive ranking boost beyond that. Content quality, backlinks, and search intent matching are still dominant factors. Think of CWV as a floor, not a ceiling.