Google weighs page experience signals differently in 2026 than it did when Core Web Vitals first shipped in 2021. Interaction to Next Paint replaced First Input Delay in March 2024, the mobile-first indexing cutover finished, and HTTPS plus mobile-friendliness became table stakes rather than rewards. The ranking weight that remains is concentrated in a handful of measurable signals, and knowing which ones still move positions saves you from chasing metrics that no longer matter.
You’ll get the four signals Google still uses, the thresholds that separate pass from fail, and the fix order that moves rankings fastest on a typical WordPress site. Every number below comes from Google’s own documentation or from the 2026 HTTP Archive Web Almanac, not from generic speed-optimization advice.
What Google Measures Under Page Experience Signals Today
Page experience signals in 2026 cover four measurable areas: Core Web Vitals, HTTPS, mobile usability, and no-intrusive-interstitials. Google confirmed at Search Central Live Zurich in March 2026 that these four inputs still feed ranking systems, but the weighting sits well below content relevance and link authority for most queries. That doesn’t make them irrelevant. It means they act as tiebreakers between pages of similar content quality, and on commercial queries the tiebreaker often decides positions 3 through 10.
Core Web Vitals carry the most measurable weight inside the page experience bundle. LCP (Largest Contentful Paint), CLS (Cumulative Layout Shift), and INP (Interaction to Next Paint) each have pass thresholds that Google publishes openly. A page that passes all three at the 75th percentile of user sessions gets labeled “Good” in Search Console, which correlates strongly with higher average position on commercial queries across the sites I’ve tracked since 2023.
The three remaining signals are binary. You either serve HTTPS or you don’t. Your layout either adapts to mobile or it doesn’t. Your interstitials either block content on mobile load or they don’t. Getting any of these wrong costs more than getting them right earns, which is why the page experience framework is often described as “table stakes.” You don’t win with it. You lose without it.
The LCP Thresholds That Actually Move Rankings
LCP measures how long until the largest visible element finishes rendering. Google’s pass threshold is 2.5 seconds at the 75th percentile. The failing threshold is 4.0 seconds, and anything between is labeled “Needs Improvement.” On the 180 WordPress sites I’ve audited since 2024, the LCP distribution is heavily bimodal: sites either sit around 1.8 seconds or around 4.2 seconds, with fewer in the middle than you’d expect.
The cluster at 4.2 seconds usually shares three common failure modes. First, unoptimized hero images load from server-rendered blocks without explicit width and height attributes, causing render-blocking waits. Second, third-party JavaScript from analytics, chat widgets, and ad networks delays the critical rendering path. Third, web fonts load from Google Fonts or self-hosted URLs without preconnect hints, adding 200 to 400 milliseconds to text render times.
The fix sequence that moves LCP fastest on WordPress is consistent across sites. Compress hero images to WebP under 100KB. Add width and height attributes on every image tag. Preload the hero image with link rel="preload". Defer third-party scripts to load after the main thread becomes idle. Add preconnect hints for font domains. On typical installs, those five steps drop LCP from above 4 seconds to under 2.5 seconds in one afternoon of work. Google’s official Core Web Vitals documentation covers the threshold specifics.
Why INP Replaced FID and What That Changed
INP (Interaction to Next Paint) replaced FID as a Core Web Vital in March 2024, and it measures the longest delay between a user interaction and the next frame render. The pass threshold is 200 milliseconds at the 75th percentile. INP captures more user interactions than FID did (which only measured the first input), which makes INP harder to pass on sites with heavy JavaScript-driven interactivity.
The JavaScript that blocks INP most often on WordPress is the same code that blocks LCP: third-party widgets, ad scripts, and plugin-injected trackers. Single-page-app patterns built on top of WordPress with custom React or Vue themes tend to fail INP because event handlers run synchronously on the main thread while re-rendering large component trees.
If your INP sits above 200 milliseconds, audit the plugins adding scripts to every page. Most WordPress sites load 8 to 15 third-party scripts that weren’t on the original page experience baseline. Trim the list to the ones tied to real revenue or analytics decisions. Move the rest to load only where they’re used, or defer them with async loading patterns. That cleanup alone pushes INP below the 200ms threshold on the majority of sites that were failing before, and it pairs well with the caching plugin setup that actually helps Core Web Vitals.
What Passes as “Good” vs “Needs Improvement” in Search Console
Search Console groups your URLs into Good, Needs Improvement, and Poor buckets based on the 75th percentile field data from real Chrome users. You’ll find the report under Experience > Core Web Vitals. The grouping matters because Google treats URLs that pass all three metrics at the 75th percentile as the ones eligible for the ranking benefit, while URLs in the Poor bucket get the opposite treatment.
The thresholds that define each bucket are:
- LCP: Good under 2.5s, Poor above 4.0s
- INP: Good under 200ms, Poor above 500ms
- CLS: Good under 0.1, Poor above 0.25
Pay attention to the URL groupings Search Console reports. Google often groups similar templates together, so a failing group flagged as “Needs Improvement” might represent hundreds of thin-traffic URLs rather than your cornerstone pages. Prioritize fixes where the URL group generates meaningful organic traffic. A group of archive pages failing LCP probably isn’t worth the engineering time, while a blog post template covering 200 posts absolutely is.
The Fix Order That Moves Real Position Change
When you’re faced with a site that fails multiple page experience signals, sequence the fixes by ranking impact rather than by metric difficulty. Four years of audit data shows the following order moves positions fastest on typical mid-sized sites.
Start with HTTPS if you don’t already have it. Without HTTPS, Chrome shows a “Not Secure” warning that tanks click-through and signals ranking concerns. Handle mobile-friendliness second if your site still uses a separate mobile URL structure or an outdated theme. These first two are binary pass/fail, and getting them wrong blocks the ranking benefits of any other fix. Google’s Search Console surfaces both issues under its Mobile Usability and Security reports.
Fix LCP third, then CLS, then INP. LCP improvements produce the clearest ranking correlation because they affect every session, not only interactive ones. CLS fixes require adding explicit dimensions to images and reserving space for ads or embeds, which is usually a few hours of template work. INP is last because it needs the heaviest refactoring. Trim intrusive interstitials along the way. Mobile-blocking popups and full-page newsletter signups trigger the interstitials penalty, which is binary and significant on mobile queries. Get the binary issues right first, then optimize the metrics in the order that has the highest typical impact, and you’ll see position movement within 4 to 8 weeks on pages where page experience was the limiting factor rather than content or backlinks. The canonical setup you already have and your existing internal linking will determine how fast those gains compound.