DEV Community: WP Speed Audits

How to Improve INP in WordPress (2026 Guide)

WP Speed Audits — Fri, 16 Oct 2026 01:07:29 +0000

Originally published on WP Speed Audits.

How to Improve INP in WordPress (2026 Guide)

Your PageSpeed score looks decent, your images are optimized, caching is on — but Google Search Console still flags poor INP on mobile. Sound familiar?

INP (Interaction to Next Paint) became an official Core Web Vital in March 2024, replacing First Input Delay. It measures something caching alone cannot fix: how quickly your site responds when a visitor actually interacts with it — taps a menu, clicks a button, types in a search box.

This guide walks you through measuring INP properly, finding exactly what is slowing down interactions on your WordPress site, and fixing it in order of impact. No fluff, no invented numbers — just the practical method.

What INP Actually Measures (in 60 Seconds)

Every time a visitor interacts with your page — a click, a tap, a keypress — the browser has to run JavaScript, recalculate styles and layout, and paint the next frame. INP measures the delay between the interaction and that next painted frame.

Google's thresholds are straightforward:

Good: under 200 milliseconds
Needs improvement: 200–500 milliseconds
Poor: over 500 milliseconds

Here is the part that trips people up: Google does not average your interactions. It looks at nearly the worst ones (technically the 98th percentile). That means a single slow interaction — one heavy dropdown menu, one laggy add-to-cart button — can tank your whole page's INP score, even if everything else feels instant.

Why does INP matter? Because it is a ranking-relevant Core Web Vital, and because it measures what visitors actually feel. A site can load fast and still feel broken if every tap takes half a second to respond.

Step 1: Measure INP Properly

Before fixing anything, get a trustworthy measurement. INP is trickier to measure than load metrics because it needs real interactions — a lab test that just loads the page may report "no data."

Use these in order:

Google Search Console → Core Web Vitals report. This shows your real-world INP status across your site, based on actual Chrome visitors. If it says "poor," believe it — this is the data Google uses.
PageSpeed Insights → field data section. Look at the "Discover what your real users are experiencing" block. It shows INP from the Chrome User Experience Report (CrUX). Note that field data lags by about 28 days — fixes take time to show up here.
Chrome DevTools → Performance panel. Open your page, start a recording, click around (menu, buttons, forms), then stop. Look for long tasks — the yellow/red blocks on the main thread. Click one to see exactly which script caused it. This is how you find culprits, not just scores.
The web-vitals JavaScript library (for developers). If you want ongoing real-user monitoring, this tiny library can log INP to your analytics. Optional, but powerful.

What not to rely on: a single lab score, or your own fast desktop. INP problems live overwhelmingly on mid-range mobile phones, where the same JavaScript takes several times longer to run.

Step 2: Find What Is Slowing Down Interactions

Record a DevTools Performance trace while interacting with the page, then look at the Bottom-Up or Call Tree view sorted by total time. The scripts at the top are your suspects.

On WordPress sites, the usual culprits are remarkably consistent:

Page builder JavaScript. Elementor, Divi and similar builders load large JS bundles on every page — even pages barely using their widgets. Frontend animation and motion effects are especially expensive.
Sliders, carousels and popups. Each one adds its own script, and they often initialize on page load whether visible or not.
Chat widgets and third-party embeds. Live chat, review widgets, social feeds — these are some of the heaviest scripts on the modern web, and they compete for the main thread exactly when the visitor tries to interact.
Cookie consent banners with heavy JavaScript that blocks or delays everything behind them.
Theme scripts that were written years ago and never slimmed down — jQuery-era menu and slider code is a classic.
Too many plugins each adding a small frontend script. Individually harmless; collectively a traffic jam on the main thread.
A bloated DOM. Page builders nest elements deeply (div inside div inside div). Every interaction forces the browser to recalculate more of the page. As a rough guide, pages with several thousand DOM nodes start paying a real interactivity tax.

Note what is not on this list: your images, your caching plugin's page cache, your CDN. Those affect loading metrics (LCP), not interaction responsiveness. If someone tells you "just install a caching plugin" for INP, they are solving the wrong problem.

Step 3: Fix INP in Order of Impact

Fix 1: Cut JavaScript weight (biggest win for most sites)

Every kilobyte of JavaScript is main-thread work on your visitor's phone. Audit ruthlessly:

Deactivate plugins you do not need, especially ones adding frontend scripts (old sliders, unused social sharing, "nice to have" widgets).
Unload scripts per page. Tools like Perfmatters or Asset CleanUp let you disable specific scripts on pages that do not need them — e.g., the contact-form script loading on every blog post, or slider code on pages with no slider. This is one of the highest-ROI changes you can make.
Replace heavy widgets with lighter alternatives: a native HTML/CSS accordion instead of a JavaScript one, a static testimonial grid instead of a carousel.

Fix 2: Defer or delay non-critical JavaScript — carefully

Deferring JavaScript (load after the page renders) and delaying it (load only on first user interaction) can dramatically cut main-thread work during load. Most optimization plugins — WP Rocket, FlyingPress, LiteSpeed Cache, Perfmatters — offer these toggles.

The critical warning: delaying everything can make your site feel less responsive, not more. If your navigation menu, search box or add-to-cart button depends on a delayed script, visitors will tap and nothing will happen until the script loads — which is exactly the kind of poor interaction INP punishes.

The safe method:

Enable delay/defer for JavaScript in general.
Immediately exclude interactive scripts: menu/navigation, search, cart and checkout, cookie consent accept buttons, form validation.
Test as a logged-out visitor on a real phone: tap the menu, open search, add to cart. If anything hesitates, its script needs excluding.

Fix 3: Tame third-party scripts

Third parties are the worst INP offenders because you cannot optimize their code — you can only control when it loads:

Delay chat widgets until user interaction (most chat tools and optimization plugins support this). Nobody needs live chat in the first 3 seconds.
Facade-embed videos and social feeds. Load a lightweight placeholder image and only load the real embed when clicked. A YouTube embed can cost megabytes of JavaScript; a facade costs almost nothing.
Self-host where possible. Analytics and font files served from your own domain (or CDN) avoid extra DNS lookups and connections.
Audit with DevTools' coverage or a third-party tracker to find scripts you forgot about — old marketing pixels are notorious.

Fix 4: Put your DOM on a diet

Open DevTools, run document.getElementsByTagName('*').length in the console. If the number is in the thousands on a simple page, your builder is generating bloat:

Prefer container-based layouts over nested sections and columns.
Limit widgets per page — every widget is markup plus usually JavaScript.
Remove hidden-but-loaded elements (sliders with 10 slides where 1 shows, mega menus with hundreds of links on mobile).

Fix 5: Help the main thread

Some of this is developer territory, but worth knowing:

Keep animations to transform and opacity only — these do not trigger layout recalculations.
Avoid code that forces synchronous layout (reading layout properties in loops) — this is called layout thrashing and it murders INP.
Break up unavoidable heavy work with setTimeout or requestIdleCallback so the browser can paint between chunks.

If you are not a developer, Fixes 1–4 will still solve the large majority of WordPress INP problems. Hire a developer only for what remains.

Fix 6: Strengthen the server side (supporting role)

Faster Time to First Byte does not directly fix INP, but a snappy server means the browser starts its work sooner and dynamic interactions (search, filters, cart updates) complete faster:

Run PHP 8.x with OPcache enabled — older PHP versions are measurably slower at executing WordPress.
Enable an object cache (Redis or Memcached) so repeated database queries do not repeat work. This shines for logged-in users and dynamic pages, which page caching cannot help. Our Redis setup guide walks through it.
Choose hosting with enough PHP workers — too few workers and interactions queue up under traffic.

Step 4: Verify the Fix (Without Fooling Yourself)

Immediate check: re-record a DevTools Performance trace and confirm the long tasks are gone and interactions feel instant on a mid-range phone (use DevTools device emulation with CPU throttling for honesty).
Real-user check: if you installed RUM (the web-vitals library), watch INP trend down over days.
Official check: wait for Search Console and PageSpeed field data to update — remember the ~28-day CrUX window. Do not panic if week one still shows "poor."

And do not chase a perfect lab number at the expense of real functionality. An INP of 180ms on a site where everything works beats 120ms on a site with a broken menu.

What Will NOT Fix INP

Save yourself some time — these are common dead ends:

Page caching alone. Page cache speeds up HTML delivery (great for LCP and TTFB), but INP happens after the page loads, in the JavaScript layer. Caching does not make your menu respond faster.
Image optimization. Crucial for LCP, nearly irrelevant for INP.
Installing another optimization plugin without removing the heavy scripts. Plugins do not cancel each other out — the bloat stays.
A CDN. Wonderful for delivery speed worldwide; does not slim your JavaScript.

Frequently Asked Questions

What is a good INP score for WordPress?

Under 200 milliseconds is "good" by Google's thresholds, 200–500ms "needs improvement," and over 500ms "poor." Aim for under 200ms on mobile — that is where most WordPress INP failures happen, because phones have slower processors running the same JavaScript as desktops.

Why is my INP poor on mobile but fine on desktop?

Mobile CPUs are much slower than desktop ones, so identical JavaScript takes several times longer to execute on a phone. This is the single most common INP pattern on WordPress: a page builder and a few third-party scripts that feel fine on your laptop create long tasks on a mid-range Android device. Fix it by cutting JavaScript weight, not by testing only on desktop.

Does delaying JavaScript improve or hurt INP?

It can do either — which is why this setting needs testing. Delaying non-critical scripts frees the main thread and usually improves INP. But if you delay scripts that power interactive elements (menus, search, cart), tapping those elements does nothing until the script loads, which hurts INP. Always exclude interactive scripts from delaying and test every tap as a logged-out visitor.

How long until Search Console shows my INP improvement?

Google's field data (CrUX) aggregates roughly 28 days of real visits, so Search Console and PageSpeed Insights field data lag behind your fix by about a month. Use DevTools traces and real-user monitoring for immediate feedback, and be patient with the official reports.

Do I need a developer to fix INP?

Usually not. The fixes that solve most WordPress INP problems — removing heavy plugins, unloading unused scripts per page, delaying third-party widgets, simplifying builder layouts — are all settings in optimization plugins, no code required. Bring in a developer only if DevTools points at custom theme or plugin code with genuine long-task problems.

The Bottom Line

INP is the Core Web Vital that caching cannot fix, because it lives in your JavaScript, not your HTML delivery. The winning formula is simple: measure with real data, find the heavy scripts with DevTools, cut what you do not need, delay what is not critical, and protect interactivity while you do it.

Work through the fixes in order, verify on a real phone, and give field data its month to catch up. Your visitors — and Google — will feel the difference with every tap.

WP Rocket vs FlyingPress (2026): Which Caching Plugin Is Right for Your Site?

WP Speed Audits — Fri, 16 Oct 2026 01:07:07 +0000

Originally published on WP Speed Audits.

WP Rocket vs FlyingPress (2026): Which Caching Plugin Is Right for Your Site?

If you've decided to pay for a WordPress caching plugin, your shortlist probably has two names on it: WP Rocket and FlyingPress. WP Rocket has been the default recommendation for years. FlyingPress is the newer challenger that performance enthusiasts keep raving about.

So which one should you actually buy? This guide compares them honestly — features, approach, pricing, ease of use and compatibility — without the hype and without invented benchmark numbers. By the end, you'll know exactly which one fits your site.

Quick note on method: this comparison is based on what each plugin does, how it is built, and who it is built for. Speed test numbers vary wildly with hosting, theme and content, so treat any "Plugin X is 43% faster" claim you see online with healthy skepticism — including ours, which is why we are not making one.

The Quick Verdict

Short on time? Here is the summary:

Pick WP Rocket if you want the battle-tested, beginner-friendly option with the largest knowledge base, the widest compatibility history, and support that has seen every weird theme conflict imaginable.
Pick FlyingPress if you like a modern, lightweight approach, you are comfortable tweaking settings, and you want aggressive optimization techniques (like smart JavaScript delaying) done well out of the box.
Pick neither (yet) if your site runs on LiteSpeed hosting — the free LiteSpeed Cache plugin is purpose-built for that server and is often the fastest option there. If that is you, read our cache types guide first before spending a dollar.

What Each Plugin Actually Does

WP Rocket: The Established All-Rounder

WP Rocket (by WP Media, around since 2013) is the plugin most WordPress tutorials recommend, and for good reason. It takes the "do everything, safely" approach:

Page caching with automatic cache preloading, so visitors rarely hit an uncached page
Browser caching and GZIP compression rules
File optimization: minify and combine CSS/JS files, defer JavaScript, delay JavaScript execution until user interaction, and remove unused CSS
Media optimization: lazy loading for images, iframes and videos
Database optimization: cleanup of revisions, transients and spam
Extras: Google Fonts optimization, CDN integration, Cloudflare add-on, DNS prefetching, heartbeat API control

It works on any web server — Apache, Nginx or LiteSpeed — which is a big part of its popularity. The settings dashboard is famously beginner-friendly: most sites get 80% of the benefit just by activating it with the defaults.

FlyingPress: The Lightweight Challenger

FlyingPress (by Gijo Varghese, first released around 2020) took a different path. Instead of adding every feature imaginable, it focuses on doing the highest-impact optimizations really well, with a lean codebase:

Page caching with preloading
CSS/JS optimization: minification, remove unused CSS, and delay JavaScript execution
Font optimization: self-host Google Fonts, preload critical fonts
Lazy loading for images, iframes and background images, plus lazy rendering of below-the-fold elements
Database cleanup and bloat remover (disables unused WordPress features like emojis and embeds)
CDN integration and link preloading

Its philosophy is "optimize smarter, not more." The plugin is popular with performance-focused site owners who like fine-grained control and are happy to test settings rather than click one magic button.

Feature-by-Feature Comparison

Feature	WP Rocket	FlyingPress
Page caching	Yes, with preloading	Yes, with preloading
Browser caching	Yes	Yes
Minify CSS/JS	Yes	Yes
Delay JavaScript execution	Yes	Yes (a signature strength)
Remove unused CSS	Yes	Yes
Lazy load images/iframes	Yes	Yes
Font optimization	Yes (host locally, preload)	Yes (self-host, preload — very polished)
Database optimization	Yes	Yes
CDN integration	Yes + Cloudflare add-on	Yes
Works on any server	Yes (Apache, Nginx, LiteSpeed)	Yes (Apache, Nginx, LiteSpeed)
Free version	No	No

On paper, the feature lists look similar — and that is exactly the point. The difference between these two plugins is not what they do, it is how they do it and who they are built for.

The Real Differences (Beyond the Marketing)

1. Philosophy: comprehensive vs. focused

WP Rocket tries to cover every optimization angle in one dashboard. That is comforting — one plugin, one support channel — but it also means a bigger settings surface to understand.

FlyingPress deliberately keeps the feature set tight and leans on modern techniques. Fans say this makes it feel faster to configure once you know what you are doing; critics say it assumes more knowledge upfront.

2. Ease of use

WP Rocket wins for pure beginners. Its setup wizard and documentation are the most polished in the business, and because millions of sites run it, almost any conflict you hit has already been solved in a forum thread somewhere.

FlyingPress is not difficult, but it expects you to understand concepts like "delay JavaScript" and "unused CSS" before you toggle them. If terms like that already make sense to you, you will feel at home.

3. Compatibility track record

This is WP Rocket's quiet superpower. A decade of real-world use means it plays nicely with page builders (Elementor, Divi, Beaver Builder), WooCommerce, membership plugins and multilingual setups — and when it does not, support has seen it before.

FlyingPress is younger, so its compatibility history is shorter. Most users report it works fine with major builders, but you should budget time for testing — especially if your site has complex interactive elements.

4. The JavaScript delay question

Both plugins can delay JavaScript until user interaction, which is one of the biggest single wins for mobile PageSpeed scores. But it is also the setting most likely to break things: navigation menus, sliders, add-to-cart buttons and cookie banners can all stop working if the wrong script gets delayed.

FlyingPress's implementation of this is widely praised for being smart about exclusions. WP Rocket's is solid too and very well documented. Either way, the rule is the same: after enabling delay-JS, test your site as a logged-out visitor and click everything — menu, search, forms, cart. This advice applies no matter which plugin you choose.

Pricing: What to Expect

Both plugins are premium with annual licenses, priced by the number of websites you want to use them on. The entry tier covers a single site, with higher tiers for freelancers and agencies managing multiple sites.

As a general guide, expect the single-site license of each to sit in the same ballpark (historically around the $60/year mark), with multi-site tiers scaling up from there. Pricing changes, so check the current pricing pages before you buy — and factor in renewal pricing, not just the first-year deal.

Neither plugin offers a free version. If budget is zero, the free LiteSpeed Cache plugin (on LiteSpeed hosting) or a careful free stack can get you surprisingly far.

An Honest Word About Performance Claims

Here is something most comparison articles will not tell you: on a well-built site, both plugins can get you to green Core Web Vitals. The plugin is rarely the deciding factor. What actually moves the needle, in rough order:

Hosting quality (especially Time to First Byte)
Theme and page builder weight
Images (sizing, formats, lazy loading)
Third-party scripts (chat widgets, trackers, embeds)
Then the caching plugin's fine-tuning

Switching from one good caching plugin to another typically changes scores by a small margin — it does not rescue a slow host or a 4 MB homepage. Buy the plugin whose workflow you prefer, then spend your real effort on the list above. Our 20-step WordPress performance checklist walks through all of it.

Who Should Pick Which?

Choose WP Rocket if you:

Are new to performance optimization and want the safest defaults
Run an agency and need one reliable plugin across many client sites
Use complex setups (WooCommerce, memberships, multilingual) and value a decade of compatibility history
Want the biggest documentation and community to fall back on

Choose FlyingPress if you:

Already understand caching concepts and enjoy fine-tuning
Want a lean, modern toolset without feature bloat
Like the idea of aggressive-but-smart JavaScript delaying done well
Are building fresh, lightweight sites (block themes, GeneratePress, Kadence) where it shines

Choose LiteSpeed Cache (free) instead if you:

Host on a LiteSpeed server (check with your host — many shared hosts use LiteSpeed)
Want server-level caching without paying anything

How to Decide in 10 Minutes

Check your hosting: LiteSpeed server? Start with free LiteSpeed Cache.
Honest skill check: beginner? WP Rocket. Comfortable tinkerer? FlyingPress.
Check your theme/builder: heavy page builder + WooCommerce? WP Rocket's compatibility history is reassuring.
Budget: both cost roughly the same at the single-site tier — decide on workflow, not price.
Whichever you pick: enable, configure conservatively, test every interactive element, then measure with PageSpeed Insights.

Frequently Asked Questions

Is FlyingPress better than WP Rocket?

"Better" depends on what you value. FlyingPress is newer, leaner, and loved by performance enthusiasts for its smart JavaScript handling. WP Rocket is more established, more beginner-friendly, and has a far longer compatibility track record. Both are excellent — pick based on your experience level and workflow, not on marketing claims.

Can I use WP Rocket and FlyingPress together?

No — never run two page-caching plugins at the same time. They will conflict with each other and can break your site or produce bizarre caching behavior. Pick one.

Does FlyingPress work with Elementor and Divi?

Generally yes, but page builders plus aggressive JavaScript delaying need careful testing. Enable the plugin's optimizations one group at a time, and after each change, test your menus, sliders, popups and (for shops) the cart as a logged-out visitor. Exclude any script that breaks interactivity from delaying.

Is WP Rocket still worth it in 2026?

Yes, if you value stability, support quality and broad compatibility — especially for client or business sites where downtime costs money. If you are on a tight budget or a LiteSpeed host, free alternatives can cover most of the same ground.

Do I still need a caching plugin if I use Cloudflare APO?

Cloudflare APO caches your HTML at the edge, which handles a big part of what a caching plugin does — but a plugin still adds value through file optimization (minify, delay JS, remove unused CSS), database cleanup and media handling. Many fast sites run both.

The Bottom Line

There is no wrong answer here — both WP Rocket and FlyingPress are genuinely good plugins. WP Rocket is the safe, proven, beginner-friendly choice. FlyingPress is the modern, lean favorite of tinkerers. And if you are on LiteSpeed hosting, try the free option first.

Whichever you choose, remember: the plugin is the finishing touch, not the foundation. Nail your hosting, theme and images first — then let your caching plugin of choice squeeze out the last drops of speed.