Fix WordPress INP Issues in PageSpeed Insights – Complete 2025 Guide

Right, let's get one thing straight from the start. If you're still seeing that infuriating orange "Needs improvement" warning for INP in PageSpeed Insights, you're definitely not alone. After helping dozens of UK businesses optimize their WordPress sites this year, I've learned that INP isn't just another metric to ignore — it's become the make-or-break factor for user experience in 2025.

Here's what happened last Tuesday: Sarah from a Manchester-based design agency rang me in a proper state. Her client's WordPress site had brilliant content, looked absolutely stunning, but Google was basically telling them their user experience was rubbish because of INP scores hovering around 400ms. Three months of lost leads later, she was desperate for answers.

That conversation got me thinking — there's a massive gap between the technical documentation and what actually works in the real world. So I've put together this comprehensive playbook based on what's genuinely moving the needle in 2025, not just what should work in theory.

Table of Contents

• Quick Wins Checklist: Start Here
• What INP Actually Measures
• WordPress 6.8's Game-Changer: Speculative Loading
• Browser Compatibility & Support
• Version Compatibility & Requirements
• The Stuff That Actually Moves INP Scores
• Mobile-Specific INP Challenges
• Hosting Impact on INP Performance
• What WordPress 6.9 Brings to the Table
• Performance Monitoring & Measurement
• When Things Go Wrong (Troubleshooting)
• The Bottom Line
• Frequently Asked Questions

Quick Wins Checklist: Start Here

Before we dive into the technical deep-end, here's your action list. Tick these off and you'll likely see immediate improvements:

✓ Check current INP score in PageSpeed Insights (focus on field data, not lab data)
✓ Audit top 3 heaviest plugins using Query Monitor or P3 Performance Profiler
✓ Enable WordPress 6.8 speculative loading (it's on by default, but verify it's working)
✓ Set fetchpriority="high" on your main hero image only
✓ Test site speed on mobile (where INP problems are most visible)
✓ Remove unused plugins you've been meaning to delete for months

If you knock out this list in the next hour, you'll have a solid foundation. The rest of this guide will help you fine-tune from there.

What INP Actually Measures (And Why Google Cares So Much)

Interaction to Next Paint — let's just call it INP because life's too short — is Google's way of measuring how quickly your site responds when someone actually tries to use it. Not how fast it loads, but how fast it reacts to clicks, taps, and typing.

Think of it this way: you know that annoying moment when you click a button and absolutely nothing happens for what feels like forever? That delay is exactly what INP measures. Google's basically saying, "If your site takes more than 200 milliseconds to respond to user interactions, you're failing your visitors."

Here's the brutal reality from the latest industry data: only 43.44% of WordPress sites are passing Core Web Vitals assessment, making WordPress lag significantly behind other platforms. Compare that to Squarespace's impressive 95.85% of sites showing good INP responsiveness, and you can see we've got some serious work to do.

"An INP below or at 200 milliseconds means a page has good responsiveness."

— Google's Web.dev Guide

But here's what gets me excited — nearly 600,000 websites went from passed to failed Core Web Vitals when INP officially replaced FID in March 2024. This wasn't a punishment; it was a wake-up call. The sites that are now thriving are the ones that took INP seriously and optimized accordingly.

INP Optimization Timeline Expectations

WordPress 6.8's Game-Changer: Speculative Loading

When WordPress 6.8 dropped in April 2025, it quietly included something that's genuinely changed how we think about site speed. Felix Arntz from Google's Chrome team, who helped develop the feature, describes it perfectly:

"Sites that enabled speculative loading improved their Largest Contentful Paint passing rate by ~1.9% at the median."

— Felix Arntz, WordPress Core Performance Team

Your site now predicts which page someone's about to visit and starts loading it in the background. So when they finally click, boom — the page is already there waiting. It's like having a really good barista who starts making your usual order the moment they see you walking up to the counter.

I tested this on a client's property blog last month. Before speculative loading, navigation between property listings took about 1.2 seconds on mobile. After enabling it properly? Down to 0.3 seconds. The client's bounce rate dropped by 15% almost immediately.

Browser Compatibility & Support

Current Support:

• Chrome 121+ (full support) — covers ~65% of UK traffic
• Edge 121+ (full support) — covers ~10% of UK traffic
• Opera 107+ (full support) — covers ~2% of UK traffic
• Safari (experimental support expected late 2025)
• Firefox (in development, likely 2026)

What This Means: For users on unsupported browsers, there are zero negative effects — they simply don't get the speed boost. The feature is designed as a progressive enhancement, meaning it gracefully fails in older browsers without breaking anything.

Setting Up Speculative Loading Properly

⚠️ Critical Warning: Always exclude state-changing URLs like cart pages, logout links, and form submissions. I once enabled prerender on an e-commerce site without proper exclusions and customers accidentally triggered checkout processes just by hovering over links. That was an expensive lesson.

WordPress 6.8 enables speculative loading by default, but in its most conservative mode. For most sites, you can safely make it more aggressive:

<?php
// Add this to your theme's functions.php or create a small plugin
add_filter('wp_speculation_rules_configuration', function ($config) {
    return [
        'mode' => 'prerender',        // More aggressive than default 'prefetch'
        'eagerness' => 'moderate',    // Start preloading at 200ms hover
    ];
});

// Exclude risky URLs - this bit is absolutely crucial
add_filter('wp_speculation_rules_href_exclude_paths', function ($paths) {
    $paths[] = '/cart/*';
    $paths[] = '/checkout/*';
    $paths[] = '/wp-admin/*';
    $paths[] = '/logout*';
    $paths[] = '/wp-login.php*';
    return $paths;
});

<?php
// Add this to your theme's functions.php or create a small plugin
add_filter('wp_speculation_rules_configuration', function ($config) {
    return [
        'mode' => 'prerender',        // More aggressive than default 'prefetch'
        'eagerness' => 'moderate',    // Start preloading at 200ms hover
    ];
});

// Exclude risky URLs - this bit is absolutely crucial
add_filter('wp_speculation_rules_href_exclude_paths', function ($paths) {
    $paths[] = '/cart/*';
    $paths[] = '/checkout/*';
    $paths[] = '/wp-admin/*';
    $paths[] = '/logout*';
    $paths[] = '/wp-login.php*';
    return $paths;
});

Why this code works: The Speculation Rules API has three modes:

• Prefetch (default): Downloads HTML only
• Prerender (what we're using): Downloads and fully renders the page
• Conservative/Moderate/Aggressive eagerness controls when preloading starts

The static $done = false in our earlier fetchpriority example prevents multiple high-priority declarations, which would defeat the purpose.

Version Compatibility & Requirements

WordPress Requirements:

• WordPress 6.8+ for built-in speculative loading
• WordPress 6.3+ for fetchpriority image support
• WordPress 5.5+ for default image lazy loading

PHP Compatibility: Based on the latest WordPress hosting team recommendations, WordPress 6.8 supports PHP 8.1 (Security Support), 8.2 (Active Support), 8.3 (Active Support), and 8.4 (Candidate Support).

Our Platform Specs: At 365i, we run PHP 8.3 by default on our WordPress Hosting platform, which provides optimal performance for these new features. If you're still on PHP 8.1 or earlier, now's a great time to upgrade.

The Stuff That Actually Moves INP Scores

After testing on dozens of sites over the past few months, here's what genuinely makes a difference:

Ruthless JavaScript Audit

Tools I Actually Use:

• Query Monitor (WordPress plugin) — brilliant for identifying slow database queries and heavy plugins
• P3 Performance Profiler — tells you exactly which plugins are slowing things down
• Chrome DevTools Performance Tab — essential for spotting long tasks over 50ms
• WebPageTest — real-world testing with different connection speeds

I know, everyone says this. But seriously — most WordPress sites are drowning in unused JavaScript. I audited one site last week that was loading 340KB of JavaScript just for a contact form that could've been done with 3KB. Absolute madness.

My JavaScript Triage Process:

1. Record interactions in Chrome DevTools while clicking around your site
2. Look for red blocks in the "Long tasks" section — anything over 50ms needs investigating
3. Check the call stack to see which plugins/themes are causing delays
4. Test with plugins deactivated one by one to isolate culprits

Edge HTML Caching Changes Everything

Here's something most people miss: if your HTML is being generated fresh from PHP every single time, you're fighting a losing battle. I've seen 400ms TTFB times drop to 20ms just by caching HTML at the edge properly.

Real-World Performance Impact:

• Before edge caching: Average UK TTFB of 200-400ms
• After edge caching: Average UK TTFB of 15-50ms
• INP improvement: Typically 100-250ms better responsiveness

On our platform with the included CDN, we cache HTML globally by default, but I've seen too many sites on other hosts where this isn't even configured. It's like trying to win a race with your handbrake on.

fetchpriority Is Your Secret Weapon

WordPress has supported fetchpriority on images since 6.3, but hardly anyone uses it properly. Set fetchpriority="high" on your LCP image — that's the biggest image above the fold — and watch your loading times improve.

But don't go mad with it. I've seen people set high priority on everything, which defeats the entire point. It's like shouting — if everything is urgent, nothing is urgent.

Here's the code I use to automatically set fetchpriority on just the first content image:

// Add this to your theme's functions.php
add_filter('wp_get_attachment_image_attributes', function($attr, $attachment, $size){
    static $done = false;
    if (!$done && is_singular() && !empty($attr['class']) && strpos($attr['class'], 'wp-image') !== false) {
        $attr['fetchpriority'] = 'high';
        $done = true;
    }
    return $attr;
}, 10, 3);

// Add this to your theme's functions.php
add_filter('wp_get_attachment_image_attributes', function($attr, $attachment, $size){
    static $done = false;
    if (!$done && is_singular() && !empty($attr['class']) && strpos($attr['class'], 'wp-image') !== false) {
        $attr['fetchpriority'] = 'high';
        $done = true;
    }
    return $attr;
}, 10, 3);

This snippet only affects the first image on posts and pages, which is usually your hero image or main content photo. The static $done variable ensures it only fires once per page load, keeping things clean.

Why fetchpriority Works: The browser has limited bandwidth and CPU resources. By explicitly marking your most important image as high priority, you're telling the browser: "Load this first, everything else can wait." It's particularly effective when combined with our edge caching, as the image loads from a nearby server location.

If you want to dive deeper into how fetchpriority works, the Fetch Priority API guide on web.dev is brilliant, and MDN's documentation covers the technical details thoroughly.

The Plugin Problem

Every WordPress site seems to accumulate plugins like a teenager's bedroom accumulates dirty clothes. That social sharing plugin you installed two years ago? Still running JavaScript on every page load. That SEO plugin that does the same thing as three other plugins? Still there, slowing everything down.

Plugin Performance Audit Checklist:

• Social sharing widgets (often load external scripts)
• Chat plugins (notorious for blocking main thread)
• Heavy sliders or carousels
• Multiple SEO plugins doing the same job
• Page builders with bloated JavaScript
• Analytics plugins loading multiple tracking codes

I did a brutal plugin audit on my own site last month — disabled everything and added back only what I genuinely needed. Page load time improved by 40%. Sometimes the best optimization is deletion.

Mobile-Specific INP Challenges

Here's something that might surprise you: mobile INP scores are significantly worse than desktop, with WordPress's mobile CWV passing rate being 3.64% lower when measured by INP instead of the old FID metric.

Why Mobile Is Harder:

• Limited processing power compared to desktop
• Slower network connections (even on 4G/5G)
• Touch interactions are more complex than clicks
• Smaller screen means more scrolling and interaction

Mobile-Specific Optimizations:

1. Lazy load everything below the fold — WordPress does this by default since 5.4, but you can extend it to other elements
2. Reduce JavaScript on mobile using wp_is_mobile() conditional loading
3. Optimize touch targets — make sure buttons are large enough and properly spaced
4. Test on real devices — Chrome DevTools mobile simulation doesn't show the full picture

Hosting Impact on INP Performance

Your hosting choice makes or breaks INP optimization. Here's why:

Server Response Time Impact:

• Shared hosting: Often 200-500ms TTFB, makes INP optimization nearly impossible
• Managed WordPress hosting: Usually 50-150ms TTFB, decent foundation for optimization
• Premium hosting with edge caching: 15-50ms TTFB, optimal for INP performance

What Makes the Difference:

• Server-level caching (Redis, Memcached)
• HTTP/2 and HTTP/3 support for faster resource loading
• Global CDN with HTML caching (not just assets)
• Optimized server stack (latest PHP, MySQL optimization)
• Resource allocation (CPU, RAM sufficient for traffic spikes)

At 365i, our WordPress Hosting platform is specifically optimized for these metrics. We use autoscaling infrastructure that handles traffic spikes without performance degradation — crucial for maintaining consistent INP scores during busy periods.

What WordPress 6.9 Brings to the Table

WordPress 6.9 lands on 2nd December 2025, and there's some genuinely exciting performance work in the pipeline. The bit I'm most excited about? Native support for fetchpriority on scripts, not just images.

Confirmed 6.9 Performance Features:

• Script fetchpriority support — mark critical JavaScript as high priority
• Enhanced back/forward cache compatibility — faster browser navigation
• Improved block loading strategies — better resource prioritization
• Additional speculation rules enhancements — more granular control

What This Means for INP: Critical JavaScript that your site depends on can now be prioritized properly. Think custom web fonts, essential plugins, or framework code that everything else depends on. Instead of competing with less important scripts, they'll load first.

Preparing Your Site for 6.9:

1. Audit your critical JavaScript — identify what absolutely must load first
2. Clean up your asset loading — remove unused scripts before the upgrade
3. Test back/forward cache compatibility — ensure your site works properly with browser caching
4. Review speculation rules — prepare to take advantage of enhanced controls

Performance Monitoring & Ongoing Measurement

Real-World Testing Methodology: Here's exactly how I test INP improvements:

1. Baseline Testing (Week 0):
   • PageSpeed Insights (mobile + desktop) — 3 tests each, average the scores
   • Chrome DevTools Performance tab — record 30-second interaction session
   • WebPageTest from London location — 3G and 4G connection tests
   • Document specific INP scores and identify worst-performing interactions
2. Implementation Phase (Week 1-2):
   • Make one change at a time (never batch changes)
   • Test each change in staging environment first
   • Use Chrome DevTools to verify no new issues introduced
3. Measurement Phase (Week 3-4):
   • Wait for field data to accumulate (Google needs 28 days of real user data)
   • Monitor Search Console Core Web Vitals report
   • Track analytics metrics (bounce rate, engagement time)

Tools and Monitoring Setup:

• Google Analytics 4 — set up Web Vitals custom events
• Search Console — monitor Core Web Vitals report weekly
• Real User Monitoring — if budget allows, tools like SpeedCurve or Calibre
• Uptime monitoring — ensure optimizations don't cause stability issues

Cost vs Benefit Analysis

ROI Considerations: Based on client data, a 100ms INP improvement typically correlates with:

• 2-5% increase in engagement time
• 1-3% reduction in bounce rate
• 0.5-2% improvement in conversion rate (for e-commerce)

Accessibility Connection

Here's something most people don't realize: INP improvements often benefit accessibility users even more than typical visitors. Screen reader users, keyboard navigators, and people with motor disabilities rely heavily on consistent, predictable interactions.

How INP Helps Accessibility:

• Keyboard navigation becomes more predictable with consistent response times
• Screen readers can announce changes more reliably when interactions are fast
• Motor disabilities benefit from interfaces that respond immediately to input attempts
• Cognitive disabilities find faster interfaces less frustrating and easier to use

Accessibility-First INP Optimizations:

1. Focus management — ensure focus moves quickly after interactions
2. Skip links — make them load instantly with high fetchpriority
3. Form feedback — immediate validation responses improve usability
4. Navigation consistency — speculative loading makes menus more predictable

Competitive Analysis Example

How to Benchmark Against Competitors: I use this process with every client:

1. Identify 5 direct competitors in your industry/location
2. Test their key pages (homepage, service pages, blog posts) using PageSpeed Insights
3. Document their INP scores and identify the best performer
4. Analyze their technical setup using tools like BuiltWith and Wappalyzer
5. Set target scores — aim to be 10-20% better than the best competitor

Example Competitive Analysis (Manchester Web Design Agencies):

This gives you concrete targets and helps identify what's working in your market.

Quick Wins You Can Implement Today

1. Theme Performance Check Some themes are absolute performance disasters. I audited one last week that was loading 15 Google Fonts variants for a single page. Fifteen! Most sites need two, maximum three font weights.

2. Image Optimization Reality Check WordPress handles image optimization pretty well now, but most people still upload massive files. That 4MB photo from your phone? WordPress creates smaller versions, but plugins and themes don't always use them properly.

Use this quick audit: Check your homepage's largest image in DevTools. If it's over 500KB, you've got work to do.

3. Database Cleanup When did you last clean your database? Revisions, spam comments, expired transients — they all add up. I use <a href="https://wordpress.org/plugins/wp-optimize/" rel="nofollow">WP-Optimize</a> regularly, but there are plenty of good options.

4. CDN Configuration If you're not using a CDN in 2025, you're basically running a website with one leg. Our global CDN at 365i is included with all hosting plans, but whatever you use, make sure HTML is cached at the edge, not just images.

The Real-World Testing Process

Here's my step-by-step process for improving INP scores, based on what actually works:

Week 1: Baseline Everything Get your current scores from multiple tools. PageSpeed Insights, GTmetrix, WebPageTest, and if possible, your own analytics. Don't just test the homepage — test your most trafficked pages.

Use these specific testing conditions:

• Location: London (for UK-focused sites)
• Connection: 3G Fast (represents real mobile usage)
• Device: Moto G4 (mid-range mobile device)
• Time: Multiple times throughout the day

Week 2: JavaScript Audit Use Chrome DevTools to identify long tasks. Record a typical user journey on your site, then analyze the Performance tab for anything over 50ms. These are your INP killers.

Specific things to look for:

• Third-party chat widgets loading 200KB+ of JavaScript
• Social media widgets making dozens of API calls
• Analytics scripts running heavy calculations
• Outdated jQuery libraries doing DOM manipulation

Week 3: Enable Optimizations Turn on speculative loading (carefully). Set fetchpriority on your LCP image. Enable HTML caching if it's not already on. But do them one at a time — never batch optimizations.

Week 4: Measure Again Give it time for field data to accumulate. Real improvements take a few days to show up in Google's metrics because they need enough real user data.

When Things Go Wrong (Advanced Troubleshooting)

Speculative Loading Issues:

Problem: Analytics showing inflated page views Solution: Check if your analytics tool supports prerendering. Most modern tools (GA4, Plausible) handle this correctly, but older implementations might need updates.

Problem: E-commerce cart behaving strangely
Solution: Ensure you've excluded all cart, checkout, and account URLs from speculation rules. The filter should catch /cart/*, /checkout/*, /account/*, and any custom e-commerce paths.

Problem: Form submissions duplicating Solution: Add no-prerender class to forms or exclude form action URLs from speculation rules.

fetchpriority Not Helping:

Problem: LCP times unchanged after adding fetchpriority Solution: Verify you've identified the correct LCP element using DevTools. Sometimes it's not the image you think it is — could be a text block or video.

Problem: Multiple images marked as high priority Solution: Check that your code only applies fetchpriority to one image. Multiple high-priority resources defeat the purpose.

INP Still Orange Despite Everything:

Time to get serious about JavaScript. Use these advanced techniques:

1. Bundle Analysis: Use webpack-bundle-analyzer or similar to see exactly what's in your JavaScript files
2. Code Splitting: Break large JavaScript bundles into smaller chunks
3. Dynamic Imports: Load non-critical JavaScript only when needed
4. Web Workers: Move heavy calculations off the main thread

Real Example: I had a client whose contact form was loading a 180KB JavaScript library just to validate email addresses. Replaced it with 10 lines of vanilla JavaScript. INP improved by 200ms instantly.

The Bottom Line

Look, I get it — INP optimization can feel overwhelming. After months of testing, I can tell you this: most INP problems aren't technical mysteries. They're architectural decisions made months or years ago that are finally coming home to roost.

The biggest insight? Most INP problems stem from treating WordPress like a generic CMS instead of the specialized platform it is. WordPress has specific performance characteristics, and the platforms that embrace this (like ours) consistently outperform those that don't.

WordPress currently lags behind other platforms with only 43.44% of sites passing Core Web Vitals, but that's not because WordPress is inherently slow. It's because most WordPress sites aren't optimized properly for the metrics that matter in 2025.

The sites that are crushing INP scores share common characteristics:

• They run on hosting optimized for WordPress performance
• They use minimal, well-coded themes
• They're ruthless about plugin choices
• They implement modern performance features like speculative loading
• They have proper edge caching configured

If you're serious about performance and want a platform that handles the technical heavy lifting — edge caching, global CDN, optimized WordPress stack — our WordPress Hosting might be worth a look. We've spent years optimizing for exactly these metrics, and our client results speak for themselves.

But regardless of where you host, the principles in this guide will help. Start with the quick wins, be patient with the results, and remember — in the world of INP optimization, consistency beats perfection every time.

Frequently Asked Questions