DEV Community: WP Speed Audits

Bunny CDN vs Cloudflare for WordPress (2026): Which Is Right for You?

WP Speed Audits — Wed, 21 Oct 2026 03:13:05 +0000

When WordPress site owners outgrow "no CDN," the shortlist almost always comes down to two names: Cloudflare and Bunny CDN (now just "Bunny"). They are very different products that happen to overlap on one job: delivering your site's files fast, everywhere.

This guide compares them honestly for WordPress use: what each one actually does, how they differ on Time to First Byte, how hard each is to set up, what they really cost at different traffic levels, and the big architectural question: Cloudflare APO versus Bunny's full-page caching.

The short answer: Cloudflare is the easier, more forgiving choice, especially on its free tier. Its huge network plus APO make it the default pick for most WordPress sites. Bunny is the performance-per-dollar specialist: cheaper at scale for pure content delivery, with a more hands-on setup. Many fast sites actually use both.

What Each Service Actually Is

Cloudflare: The All-in-One Platform

Cloudflare is not just a CDN. It is a full edge platform that happens to include CDN functionality:

Reverse-proxy CDN on one of the largest edge networks in the world (300+ cities)
Automatic performance features: Brotli compression, HTTP/3, early hints, image resizing (paid tiers)
Security built in: WAF, DDoS protection, bot management, free SSL
DNS: many people use Cloudflare for DNS alone
APO (Automatic Platform Optimization): a WordPress-specific add-on that caches your HTML at the edge

The free tier is famously generous: unlimited bandwidth CDN, free SSL, and basic DDoS protection at zero cost. That is why Cloudflare is the default recommendation for most small WordPress sites.

Bunny: The Performance-Per-Dollar CDN

Bunny is a focused content-delivery network built for speed and transparent pricing:

Pull zones for your static assets (images, CSS, JS) served from 120+ edge locations
Bunny Edge Storage and origin shield options
Perma-Cache: long-term edge caching for truly static files
Full-page caching options that can cache your HTML at the edge, similar in spirit to APO
Image optimization (Bunny Optimizer) as an add-on: WebP/AVIF conversion, resizing on the fly

Bunny's pitch is simple: no-nonsense CDN performance with usage-based pricing and no feature-gating games. You pay for what you use, and everything is available on every plan.

The TTFB Question

Time to First Byte, how fast the server responds, is where CDN choice matters most for WordPress, because WordPress pages are dynamic by default.

With a standard setup (CDN caching static assets only): neither CDN improves TTFB for uncached HTML, because the HTML still comes from your origin server. Both speed up everything around the HTML — images, CSS, JS — which is most of your page weight. For TTFB itself, your hosting quality matters more than which of these two you pick.

With full-page/HTML caching enabled: this is where it gets interesting. Cloudflare APO caches your WordPress HTML at Cloudflare's edge, so repeat visitors get TTFB from a nearby edge server instead of your origin. Bunny's full-page caching does the same thing on Bunny's network. In both cases, TTFB for cached pages drops dramatically compared to origin — the difference between the two networks is usually smaller than the difference between cached and uncached.

The honest take: for most WordPress sites, "CDN A vs CDN B for TTFB" is the wrong question. The right question is "am I caching HTML at the edge or not?" Edge HTML caching beats any origin-vs-origin comparison by an order of magnitude.

Setup Difficulty

Aspect	Cloudflare	Bunny
Basic setup	Change nameservers to Cloudflare; the dashboard walks you through it	Create a pull zone, point your CDN URL (or use their DNS), install a plugin to rewrite URLs
WordPress integration	Official Cloudflare plugin + APO plugin; many hosts offer one-click setup	BunnyCDN WordPress plugin handles URL rewriting and cache purging
Full-page HTML caching	APO: install plugin, toggle on — genuinely easy	Requires more manual configuration of caching rules
DNS	Built in (often the reason people start)	Not a DNS provider — you keep your existing DNS
Learning curve	Gentle; sensible defaults	Moderate; more knobs, more control

Cloudflare wins on ease, no contest. Changing nameservers sounds scary but the onboarding flow is polished, and APO is close to a one-click win for WordPress. Bunny's setup is not hard (the WordPress plugin does the heavy lifting), but you will make more decisions yourself: pull zone regions, cache rules, optimizer settings.

One practical note: because Cloudflare is a reverse proxy (all traffic flows through it), some hosts and plugins need small adjustments (restoring visitor IPs, flexible-vs-full SSL settings). Bunny as a pure pull CDN for assets avoids most of that. It only handles the URLs you point at it.

Real-World Costs

This is where the two diverge sharply. Not in "which is cheaper" but in how you pay:

Cloudflare's model: generous free tier, features cost money. The free plan covers CDN, SSL, and DDoS protection with no bandwidth charges. Genuinely enough for most small-to-medium WordPress sites. You pay when you want more: APO is a small monthly add-on per domain, and higher tiers (Pro, Business) unlock the WAF rules, image optimization, and prioritized support. Costs are predictable and flat.

Bunny's model: usage-based, everything included. There is no free tier in the Cloudflare sense. You pay per GB delivered (plus small add-on fees for things like the optimizer). The per-GB rate is low and gets lower with volume, and every feature is available regardless of spend. For a small site, the monthly bill is often pocket change; for high-traffic sites serving lots of media, it scales linearly with traffic.

How to think about it:

Small site, mostly text: Cloudflare free tier costs nothing and covers you. Bunny would also cost very little, but free is free.
Medium site with real traffic: compare Bunny's per-GB cost against Cloudflare's paid tiers. Bunny often wins on pure delivery cost; Cloudflare wins if you also want its security and platform features.
Media-heavy site (video, large images, downloads): bandwidth dominates, and Bunny's usage pricing is usually the economical choice. This is Bunny's home turf.
Unpredictable/viral traffic: Cloudflare's flat pricing means a traffic spike does not spike your bill. Bunny's metered pricing means it does (though at low per-GB rates).

APO vs Bunny Full-Page Cache

Both services can cache your WordPress HTML at the edge. The differences are in philosophy:

Cloudflare APO is WordPress-specific and opinionated. It knows WordPress: it handles logged-in users, the admin bar, WooCommerce cart behavior, and cache purging through its official plugin. You toggle it on and it mostly does the right thing. The tradeoff is control. It works the way Cloudflare designed it.

Bunny's full-page caching is more of a toolkit. You configure the caching rules, and you get finer control over what gets cached and for how long. The tradeoff is responsibility: misconfigured edge caching can serve logged-in content to the wrong visitor, so you need to understand what you are doing (especially with WooCommerce or membership sites).

Can you use both? Yes, and many fast sites do. A common stack: Cloudflare in front (DNS, security, APO for HTML) with Bunny handling media delivery, or Bunny for everything with Cloudflare kept for DNS and firewall. They are not mutually exclusive; they solve overlapping but distinct problems.

Who Should Pick Which?

Choose Cloudflare if you:

Want the simplest setup with the most forgiving defaults
Are on the free tier budget (most small sites)
Want security (WAF, DDoS protection) bundled with performance
Like one-click WordPress-specific features like APO
Have unpredictable traffic and want flat pricing

Choose Bunny if you:

Serve lots of media and bandwidth cost is your main concern
Want transparent usage-based pricing with no feature gates
Prefer fine-grained control over caching behavior
Already have DNS and security handled elsewhere
Run a high-traffic site where per-GB economics favor Bunny

Consider both if you:

Want Cloudflare's security and DNS with Bunny's media delivery economics
Are optimizing a serious site and willing to manage two services

Frequently Asked Questions

Is Bunny CDN faster than Cloudflare?

For pure static-asset delivery, both are excellent and the difference depends more on your visitors' location relative to each network's edge points than on the brand. Real-world tests vary by region and time. Either one properly configured will be dramatically faster than no CDN — that is the comparison that matters.

Can I use Bunny CDN with Cloudflare at the same time?

Yes. A common setup keeps Cloudflare as the DNS provider and security layer (proxying your domain) while Bunny serves media files from a CDN subdomain or cookieless domain. Configure carefully so the two caches do not fight over the same URLs.

Does Cloudflare's free plan slow down my site?

No — the free plan delivers the same edge network performance as paid plans for basic CDN and SSL. Paid tiers add features (WAF rules, image optimization, more page rules), not raw speed. A free Cloudflare setup is faster than no CDN in essentially every case.

Do I still need a caching plugin if I use APO or Bunny full-page cache?

Yes, usually. Edge HTML caching handles page delivery, but a caching plugin still contributes file optimization (minify, delay JS, remove unused CSS), database cleanup, and media handling. Many fast sites run both.

Which is better for WooCommerce?

Both need care with dynamic content (cart, checkout, account pages must never be cached at the edge). Cloudflare APO has WooCommerce-aware behavior built in through its plugin, which makes it the lower-effort choice. Bunny can do it with proper exclusion rules, but you configure them yourself.

The Bottom Line

Cloudflare is the default recommendation for a reason: free tier, huge network, dead-simple WordPress integration with APO, and security bundled in. Start here unless you have a specific reason not to.

Bunny is the specialist's choice: superb price-to-performance for content delivery, transparent usage pricing, and more control for those who want it. If bandwidth bills are your pain point, Bunny deserves a serious look.

And whichever you choose, the CDN is one layer of the stack. Hosting quality, image optimization, and browser caching still do most of the heavy lifting.

Originally published at https://wpspeedaudits.site/bunny-cdn-vs-cloudflare-wordpress/

How to Speed Up Elementor (10 Fixes That Actually Work)

WP Speed Audits — Wed, 21 Oct 2026 03:12:21 +0000

Elementor powers millions of WordPress sites, and it has a reputation for being heavy. That reputation is partly deserved: a default Elementor page ships more CSS, more JavaScript, and more DOM elements than a hand-built or block-theme equivalent.

But here is what the "Elementor is slow" discourse usually misses: most Elementor slowness comes from how it is used, not from Elementor itself. Old section-based layouts, unused widgets loading assets site-wide, icon fonts nobody asked for, and a dozen Elementor addon plugins. These are choices, and they can be unchosen.

These ten fixes are ordered by impact. Start at the top.

The short answer: convert old sections to flexbox containers, enable Elementor's performance experiments, disable unused widgets and icon libraries, control per-page assets, cut Elementor addon plugins, and put the result on decent hosting with caching. Each step is small; together they transform Elementor page weight.

1. Convert Sections to Containers (Biggest Single Win)

Old Elementor layouts use sections to columns to widgets, which generates deeply nested divs, a notorious source of DOM bloat. Elementor's modern Container layout (flexbox-based) produces dramatically leaner markup.

In Elementor to Settings to Features, make sure Flexbox Container is active.
For existing pages, Elementor offers a "Convert to Container" tool in the editor (right-click a section). Convert your highest-traffic templates first: homepage, landing pages.
Build all new pages with containers from the start.

This one change often cuts DOM size substantially on old Elementor sites, which helps every metric: LCP, CLS, and Total Blocking Time.

2. Enable the Performance Experiments

Elementor ships performance improvements behind the Experiments panel (Elementor to Settings to Features). These are the ones to activate:

Optimized DOM Output: removes wrapper divs Elementor historically added around widgets. Less DOM, faster rendering.
Improved Asset Loading: loads widget CSS/JS only when the widget is actually used on the page, instead of site-wide.
Optimized Control Loading: shrinks the editor's own footprint (helps your editing experience too).
Inline Font Icons: replaces the Font Awesome font file with inline SVGs for only the icons you use (see fix #4).

Experiments marked "Stable" are safe for production. Ones still labeled experimental: test on staging first, especially with addon plugins.

3. Disable Widgets You Never Use

Every active Elementor widget can contribute assets. If you never use the Flip Box, Countdown, or Testimonial Carousel, they should not be loading code.

Go to Elementor to Settings to Features and look for widget management, or use the editor's Widget Panel organization to disable unused widgets.
Be honest in the audit: most sites use 10-15 widgets regularly and carry 40+.

4. Kill the Icon Font Bloat

Elementor historically loaded the full Font Awesome library (hundreds of kilobytes) on every page, even if you used three icons. The fix:

Enable the Inline Font Icons experiment (fix #2). This swaps the font file for inline SVGs of only the icons in use.
Alternatively, in Elementor to Settings to Advanced, look for the Font Awesome loading option and set it to only load what is needed.
Audit custom icon usage: if your theme or addons pull their own icon fonts, that is a second copy of the same problem.

Icon fonts are render-blocking; removing an unused one is a free speed win.

5. Control Assets Per Page

Elementor lets you manage which scripts and styles load where:

Elementor to Settings to Advanced to CSS Print Method: "External File" is generally better for caching than inline embedding.
Review per-page asset loading: with Improved Asset Loading active, Elementor handles much of this automatically. But addon plugins often do not. Audit which plugins inject assets on pages that do not need them.
A plugin like Perfmatters or Asset CleanUp can disable specific scripts/styles on specific pages. For example, stop the contact-form scripts loading on every blog post.

6. Fix Google Fonts Loading

Elementor sites commonly load Google Fonts in the heaviest way possible: multiple families, multiple weights, render-blocking.

In Elementor to Settings to Advanced, set Google Fonts Load to "Swap" (uses display=swap so text renders immediately with a fallback font).
Reduce families and weights ruthlessly. Each weight is a separate file: two families x four weights = eight font files.
Better yet: host fonts locally. Download the woff2 files, serve them from your own domain (no third-party connection), and preload the one or two weights used above the fold. Caching plugins can automate the local-hosting part.

7. Audit Your Elementor Addon Plugins

This is the dirty secret of slow Elementor sites: it is rarely Elementor core. It is the six addon plugins (Ultimate Addons, Essential Addons, HappyAddons, Premium Addons, and friends), each loading its own CSS/JS framework site-wide.

List every Elementor addon you have installed. For each, ask: do I use its widgets on more than a couple of pages?
Remove the ones you barely use. For the keepers, check whether they offer per-widget asset control and enable it.
Two addons with overlapping widget sets is pure waste. Consolidate.

8. Optimize Images the Elementor Way

Elementor makes it easy to drop in a 4000px image and display it at 600px. The browser still downloads the full file.

Set appropriate image sizes in each widget (Elementor lets you pick the registered size per image; use it).
Enable lazy loading for below-the-fold images (WordPress core does this by default; verify your builder is not fighting it).
Serve modern formats: WebP/AVIF versions of your images, which your caching plugin or CDN can generate.
Never lazy-load the hero/LCP image. That single mistake tanks LCP on countless Elementor homepages.

9. Cache Aggressively (and Correctly)

Elementor pages are still WordPress pages. They benefit from the full caching stack:

A caching plugin with page cache, minification, and delayed JavaScript (test thoroughly; delay-JS plus Elementor animations needs care).
Browser caching for static assets so repeat visits fly.
A CDN so Elementor's asset files serve from edge locations near your visitors. And test whether your CDN is actually serving cached content after setup.
Regenerate Elementor's CSS cache after changes: Elementor to Tools to Regenerate CSS & Data.

One Elementor-specific gotcha: after enabling minification or JS delaying, clear Elementor's own files cache too (same Tools screen), or you will debug ghosts.

10. Be Honest About Hosting

Elementor is a page builder. It does more work per request than a static block theme. On bottom-tier shared hosting with slow disks and few PHP workers, no amount of asset tuning overcomes a 2-second Time to First Byte.

If your TTFB is consistently slow (check in DevTools or PageSpeed Insights), the host is the bottleneck, not Elementor.
Elementor's own hosting is tuned for it, but any quality host with server-level caching, current PHP, and enough workers will do.
Pair decent hosting with the nine fixes above and Elementor stops being "the slow builder." It becomes just a builder.

Frequently Asked Questions

Is Elementor really slower than Gutenberg?

Out of the box, yes — a default Elementor page typically ships more markup, CSS, and JS than an equivalent block-theme page. But a well-optimized Elementor site (containers, experiments on, addons trimmed) can score green Core Web Vitals. The gap is real but closable.

Will these fixes break my design?

Fixes 1-8 change markup and asset loading, not visual design — but aggressive changes (DOM optimization, JS delaying) can affect animations, popups, and sticky elements. Always test as a logged-out visitor after each change, and keep a backup before converting old sections to containers.

Do I need a separate optimization plugin with Elementor?

Elementor is adding performance features, but it is not a caching plugin. You still want one for page caching, file optimization, database cleanup, and media handling. Just configure its aggressive features (especially delayed JavaScript) carefully alongside Elementor's animations.

Which Elementor experiment is most important?

Improved Asset Loading and Optimized DOM Output deliver the most consistent wins across sites. Enable those two first, verify nothing breaks, then move on to the rest.

Should I rebuild my site without Elementor for speed?

Only if you have measured and proven Elementor is the bottleneck after applying these fixes. Rebuilding is expensive; most Elementor sites have far more to gain from the ten fixes above — especially containers, addon audits, and hosting — than from a platform migration.

The Bottom Line

Elementor is not slow; neglected Elementor is slow. Convert sections to containers, switch on the performance experiments, trim widgets and icon fonts, audit your addon plugins, and cache properly. Work through the list in order, test as you go. Your Elementor site can be fast. It just needs the same discipline any performance work needs.

Originally published at https://wpspeedaudits.site/how-to-speed-up-elementor/

How to Fix LCP Issues in WordPress: The 4-Stage Checklist

WP Speed Audits — Wed, 21 Oct 2026 03:11:40 +0000

Largest Contentful Paint is the Core Web Vital that fails most often on WordPress sites, and it is the one visitors feel most directly. LCP measures when the main content of the page becomes visible: the hero image, the headline block, the product photo. When it is slow, your site feels slow, whatever the other metrics say.

Google's threshold: under 2.5 seconds is good, over 4 seconds is poor. If PageSpeed Insights is flagging your LCP, do not start toggling random optimization settings. Follow this four-stage checklist in order. Each stage builds on the last, and skipping ahead is why most LCP fixes fail.

The short answer: 1) Identify exactly which element is your LCP. 2) Make the browser discover and download it first (preload, eager-load, fetchpriority). 3) Make the file itself smaller (right size, WebP/AVIF). 4) Remove whatever is blocking it from rendering (slow server response, render-blocking CSS/JS). Measure after each stage.

Stage 1: Identify the LCP Element (Do Not Skip This)

Most failed LCP fixes fail here: people optimize the wrong thing. Before changing anything:

Run PageSpeed Insights on the affected page.
In the results, find the "Largest Contentful Paint element" in Diagnostics. PSI names the exact element (an image URL, a heading, a div).
Note two things: what the element is (image? text block? background?) and when it renders (the LCP timing breakdown shows how much time went to server response vs. resource loading vs. render delay).

Common WordPress LCP elements and what they tell you:

Hero image: the image pipeline needs work (Stages 2-3).
Headline text block: the text is waiting on something — usually render-blocking CSS or web fonts (Stage 4).
Background image on a div: backgrounds cannot be prioritized like <img> tags; consider converting to a real image or preloading (Stage 2).
Slider/carousel first slide: sliders are LCP killers; the first slide's image needs eager loading and the slider script must not block it.

Write down your LCP element. Every step below targets it specifically.

Stage 2: Preload It and Load It Eagerly

The browser cannot render what it has not discovered. A huge share of WordPress LCP problems is simply late discovery: the LCP image is buried in markup, injected by JavaScript, or just lazy-loaded — the classic case.

If the LCP element is an image:

It must have fetchpriority="high" and loading="eager" (never lazy). WordPress 6.3+ adds fetchpriority automatically to the likely LCP image, but page builders and custom themes often bypass this.
If your optimization plugin lazy-loads it anyway, exclude it (by CSS class, filename, or URL) in your plugin's lazy-load exclusion settings.
Verify in DevTools: the Network tab's Priority column should show High for this image.

If the LCP element is hard to discover (background image, JS-injected):

Add a preload hint to your <head>:

<link rel="preload" as="image" href="/wp-content/uploads/hero.avif" fetchpriority="high">

Only preload the actual LCP resource. Preloading five things is the same as prioritizing nothing.

If the LCP element is text: the "resource" blocking it is usually CSS or fonts (Stage 4). But also check: is the text inside content that a script reveals (animations, fade-ins)? Disable entrance animations on above-the-fold content. They delay LCP by definition.

Stage 3: Make the File Smaller (Size and Format)

Once the browser discovers the LCP resource early, the next question is how fast it downloads. For images:

Serve the right size. A 2400px-wide hero displayed at 800px wastes most of its bytes. Use responsive images (srcset; WordPress generates these automatically for content images) and pick the correct registered size in your builder.
Use modern formats. WebP is typically 25-35% smaller than JPEG at similar quality; AVIF goes further still. Your caching plugin's image optimizer or your CDN's image service can generate these automatically — serve AVIF/WebP with JPEG fallback.
Compress sensibly. Quality 80-85 for JPEG/WebP is visually identical to 100 for photographic content at a fraction of the size. Do not chase extreme compression on the LCP image itself. Artifacts on the hero are the most visible on the page.
For text LCP: the "file" is your CSS and fonts. Subset fonts to the character sets you use, limit weights (each weight is a file), use font-display: swap, and consider hosting fonts locally instead of pulling from Google on every visit.

A note on honesty: image optimization has real but bounded returns. If your LCP is 6 seconds because of a 3-second server response, no image format will save you. Which brings us to Stage 4.

Stage 4: Kill Whatever Is Blocking It

LCP has four sub-parts, and WordPress sites commonly bleed time in two: Time to First Byte (server too slow) and render delay (something blocking the browser from painting).

Fix slow TTFB:

TTFB is hosting + uncached dynamic work. Enable page caching so repeat visits skip PHP entirely.
Set up Redis object caching to cut database time on the requests that must run PHP.
Check for slow plugins with Query Monitor; one bad plugin can add seconds to every uncached response.

Fix render-blocking resources:

CSS: the browser will not paint until stylesheets load. Inline critical CSS (the styles for above-the-fold content) and defer the rest. Caching plugins generate critical CSS automatically — test it, because bad critical CSS breaks layouts visibly.
JavaScript: scripts in the <head> without defer or async block rendering. Defer non-critical JS; delay third-party scripts (chat widgets, trackers) until user interaction. But test everything. Delaying the wrong script breaks menus and sliders.
Third-party embeds: that social feed, review widget, or video embed above the fold is render-blocking by nature. Move embeds below the fold, facade them (click-to-load), or remove them.

The order matters within Stage 4 too: fix TTFB first. Shaving render-blocking resources on a page with a 3-second server response is polishing a slow foundation.

Measure After Each Stage

Do not apply all four stages and then test once. After each stage:

Purge all caches (plugin, CDN, browser).
Run PageSpeed Insights 2-3 times and take the median — single runs vary.
Check the LCP element and timing breakdown again. Did the element change? Did the bottleneck move from "resource load" to "server response"?

If LCP improved but is still over 2.5s, the breakdown tells you which stage to revisit. LCP optimization is iterative, not one-shot.

Frequently Asked Questions

What is a good LCP score for WordPress?

Under 2.5 seconds on mobile (which is what Google grades) is "good." Between 2.5 and 4 seconds "needs improvement"; over 4 seconds is "poor." Aim for good on your key templates — homepage, top landing pages, top posts — rather than every archive page.

Why is my LCP different on every test?

LCP varies with server load, cache state (warm vs. cold), network conditions, and even the test location. Always compare medians of multiple runs with the same cache state. A single bad run after purging caches is expected — the first visitor rebuilds the cache.

Can a caching plugin fix LCP by itself?

Partially. Page caching fixes the TTFB portion, and file optimization features help with render-blocking resources. But no plugin can identify your LCP element, choose the right image size, or decide your slider is the problem. The checklist above is the thinking the plugin cannot do for you.

My LCP element is a slider. What should I do?

Sliders are among the worst LCP offenders: heavy scripts, multiple large images, animations. The honest fixes, in order of effectiveness: replace the slider with a single static hero image (best); if you must keep it, eager-load only the first slide's image, lazy-load the rest, and make sure the slider script does not block rendering.

Does lazy loading hurt LCP?

Lazy loading below-the-fold images helps performance. Lazy loading the LCP image hurts it badly — the browser deliberately delays the most important element. This is the single most common WordPress LCP mistake, and it takes minutes to fix once identified.

The Bottom Line

LCP issues feel mysterious until you work the checklist: identify the element, prioritize its discovery, shrink the file, unblock its rendering. In that order, measuring as you go. Most WordPress LCP failures trace to one of a handful of causes: a lazy-loaded hero, a slow server response, or render-blocking bloat. All of them are fixable without exotic tooling.

Originally published at https://wpspeedaudits.site/how-to-fix-lcp-issue-wordpress/

Perfmatters vs Asset CleanUp: Script Manager Showdown

WP Speed Audits — Mon, 19 Oct 2026 05:20:56 +0000

Originally published on WP Speed Audits.

Perfmatters vs Asset CleanUp: Script Manager Showdown

Here is a performance truth most site owners miss: your caching plugin can be perfect and your site can still be slow — because of everything loading that should not be there. Contact Form 7's scripts on pages with no form. Slider scripts on pages with no slider. Emoji scripts, embed scripts, a dozen plugin stylesheets on every single page.

Script managers fix exactly this: they let you unload CSS and JavaScript on pages where they are not needed. The two best-known are Perfmatters and Asset CleanUp. This guide compares them honestly — what each unloads, how the interfaces differ, pricing, and which pairs best with your caching plugin.

Quick note on method: this comparison is about workflow and control, not lab benchmarks. Unloading the right assets can cut significant weight from a page — but "which scripts to unload" depends entirely on your plugins, so expect to spend time auditing your own site.

The Quick Verdict

Short on time? Here is the summary:

Pick Perfmatters if you want the polished, actively-developed premium tool with the best interface, plus extras like delay-JS, remove-unused-CSS and lazy loading in one package.
Pick Asset CleanUp if you want a capable free version to start with, you like its "test mode" safety net, and you prefer one-time pricing over a subscription.
Pick neither yet if you have not audited what is actually loading — install Query Monitor or check DevTools' coverage tab first, so you know what you are trying to unload.

What Each Plugin Actually Does

Perfmatters: The Premium All-in-One Optimizer

Perfmatters (by Brian Jackson and the ForGravity team) started as a script manager and grew into a full optimization suite:

Script Manager: disable scripts and styles per page, per post type, or sitewide — with logged-in/logged-out granularity
Delay JavaScript execution until user interaction, and remove unused CSS
Lazy loading for images, iframes and videos; delay/placeholder options
Tweaks: disable emojis, embeds, dashicons for logged-out users, heartbeat control, limit post revisions, DNS prefetch/preconnect
Database optimization and CDN rewrite for asset URLs
Code snippets and script attributes (async/defer) management

Its philosophy: one lightweight plugin that handles all the "small but numerous" optimizations caching plugins leave behind.

Asset CleanUp: The Unloading Specialist

Asset CleanUp (by Gabriel Livan) stays focused on its core job — unloading assets — and does it with unusual depth:

Unload CSS/JS per page, per post type, via URL patterns (regex), or sitewide with exceptions
"Test Mode": preview unloading rules as an admin without affecting visitors — the safety net that made it famous
Minify and combine CSS/JS files, async/defer handling
Google Fonts optimization (combine, preload, display=swap)
Unload on conditions: by device type, for logged-in users, on specific taxonomies
Free version covers core unloading; Pro adds deeper rules, critical CSS, and more

Its philosophy: be the best possible tool for one job — deciding exactly what loads, where.

Feature-by-Feature Comparison

Feature	Perfmatters	Asset CleanUp
Per-page script/style unloading	Yes	Yes
Unload by post type / taxonomy	Yes	Yes
Regex/URL-pattern rules	Basic	Yes (a strength)
Test mode (admin-only preview)	No	Yes
Delay JavaScript	Yes	Limited
Remove unused CSS	Yes	No (Pro has critical CSS)
Lazy loading	Yes	Basic
Disable emojis/embeds/bloat	Yes (extensive)	Partial
Database optimization	Yes	No
Minify/combine files	No (relies on cache plugin)	Yes
Google Fonts optimization	Yes	Yes
Free version	No	Yes
Pricing model	Annual subscription	One-time Pro payment (historically)

The overlap is the script manager itself; the difference is everything around it. Perfmatters bundles delay-JS and unused-CSS removal (normally cache-plugin territory), while Asset CleanUp bundles minify/combine (also normally cache-plugin territory). Know what your cache plugin already covers before doubling up.

The Real Differences (Beyond the Marketing)

1. Interface and learning curve

Perfmatters' Script Manager is widely considered the nicer interface: it lists every script and style loading on the current page, shows dependencies, and lets you toggle per-page, per-post-type or everywhere with a few clicks. Asset CleanUp's interface is more powerful in raw rule terms (regex patterns, conditional logic) but takes longer to learn. If you will touch these settings weekly, Perfmatters' polish matters. If you will set rules once and forget them, Asset CleanUp's depth wins.

2. Test mode: Asset CleanUp's killer feature

Unloading the wrong script breaks things — a missing cart script, a dead menu, a form that silently stops submitting. Asset CleanUp's test mode lets you apply unloading rules visible only to logged-in admins, so you can click through the whole site safely before visitors ever see the change. Perfmatters has no equivalent; you test by toggling and checking as a logged-out visitor (which works, but test mode is more forgiving).

3. Overlap with your cache plugin

This is where people waste money or create conflicts:

Perfmatters + WP Rocket/FlyingPress: Perfmatters' delay-JS and remove-unused-CSS overlap with both cache plugins' versions of the same features. Pick ONE plugin to own each feature — running two delay-JS implementations is asking for breakage.
Asset CleanUp + cache plugin: Asset CleanUp's minify/combine overlaps with cache plugins too. The cleanest setup is usually: cache plugin handles page caching + minify, while Asset CleanUp handles only unloading (disable its minify module to avoid double-processing).
Rule of thumb: let each plugin do what it does best, and switch off the overlapping modules.

4. Pricing philosophy

Perfmatters is an annual subscription — you pay every year for updates and support. Asset CleanUp has a genuinely useful free version, and its Pro has historically been a one-time payment. If you dislike subscriptions or want to try before you buy, Asset CleanUp's path is friendlier. If you value continuous active development and premium support, Perfmatters' subscription funds exactly that.

5. What "unloading" can and cannot do

Both plugins only help with assets that should not load at all on a given page. They cannot fix a genuinely heavy script that a page needs (a chat widget, a page-builder's core files). For those, the fixes are: delay it, defer it, replace it with something lighter, or remove the feature. Unloading is about the easy wins — the contact-form scripts on 95% of pages that have no form.

How to Audit Before You Buy Either

Install Query Monitor (free) and load a few key pages — it shows which scripts and styles each page pulls in.
In Chrome DevTools, open Coverage (Ctrl+Shift+P → "Show Coverage"), reload, and see how much of each file actually executes. Red bars everywhere = unloading candidates.
List the obvious wins: form plugins on non-form pages, slider assets without sliders, social-share scripts, emoji/embed scripts.
Only then choose your tool — you will configure it in an afternoon instead of guessing for a week.

Frequently Asked Questions

Can I use Perfmatters and Asset CleanUp together?

Technically yes, but do not — two script managers will fight over the same assets and create confusing breakage. Pick one. (One script manager plus one caching plugin is the normal, correct stack.)

Will unloading scripts break my site?

It can, if you unload something a page actually needs. That is why Asset CleanUp has test mode, and why the universal rule applies: change one thing, test as a logged-out visitor, click everything — menus, forms, cart, search — before moving on.

Do I still need a caching plugin if I use Perfmatters?

Yes. Perfmatters is not a page-caching plugin — it optimizes what loads, but it does not cache full HTML pages. The standard stack is: caching plugin (page cache) + Perfmatters or Asset CleanUp (asset control) + image optimizer.

Which is better for beginners?

Perfmatters has the gentler learning curve and better documentation. Asset CleanUp's free version is the better zero-risk starting point, and its test mode forgives mistakes. Either is fine if you follow the "small batches + test" rule.

Does unloading assets help Core Web Vitals?

Yes — fewer, smaller files mean less render-blocking work and faster interactivity (INP), and less JavaScript parsing helps on mobile especially. But it complements, not replaces, caching, image optimization and good hosting.

The Bottom Line

Perfmatters is the premium all-rounder: the nicest script manager plus delay-JS, unused-CSS removal and a dozen small optimizations in one subscription. Asset CleanUp is the specialist with the better free tier, the beloved test mode, and one-time pricing. Either one, configured carefully, removes the dead weight your caching plugin cannot touch — just never run both at once, and always let one plugin own each overlapping feature.

WP Rocket vs W3 Total Cache (2026): Still Worth Paying?

WP Speed Audits — Mon, 19 Oct 2026 05:19:53 +0000

Originally published on WP Speed Audits.

WP Rocket vs W3 Total Cache (2026): Still Worth Paying?

This is the classic WordPress performance debate: the premium plugin everyone recommends versus the free plugin that can do almost everything — if you can figure out how. WP Rocket costs money every year. W3 Total Cache (W3TC) is free and, on paper, more powerful.

So is WP Rocket still worth paying for in 2026? Or should you invest the time to master W3 Total Cache and keep your money? This guide compares them honestly — ease of use, feature depth, Redis/object-cache support, and who each one is really for.

Quick note on method: this comparison is about workflow and fit, not lab benchmarks. Both plugins can produce fast sites; the difference is how much of your time they demand and how much control they hand you.

The Quick Verdict

Short on time? Here is the summary:

Pick WP Rocket if you want results fast with minimal fuss — the best defaults, the best documentation, and support that answers when something breaks. Your time is worth more than the license fee.
Pick W3 Total Cache if you are technical, you want deep control (including free Redis/Memcached object caching), and you enjoy tuning. It is the most capable free caching plugin ever built — and the most demanding.
Pick the free stack (below) if your budget is zero but you still want object caching and solid page caching without paying.

What Each Plugin Actually Does

WP Rocket: Pay for Simplicity

WP Rocket (by WP Media, since 2013) is built around one idea: caching should just work. Activate it, and most of the important stuff is already on:

Page caching with automatic preloading
Browser caching and GZIP rules
File optimization: minify/combine CSS and JS, defer and delay JavaScript, remove unused CSS
Media: lazy loading for images, iframes, videos
Database cleanup, Google Fonts optimization, CDN integration, Cloudflare add-on, heartbeat control

What it deliberately does not do: object caching. WP Rocket has no Redis or Memcached integration — for that you would add a separate plugin. Its philosophy is page-cache-first, and for most brochure sites and blogs, that is the right 80%.

W3 Total Cache: The Free Power Tool

W3 Total Cache (by Frederick Townes, around since the early WordPress days) is the opposite philosophy: expose everything, assume the user knows what it means:

Page caching (disk, opcode, or Memcached/Redis-backed)
Object caching with Redis or Memcached support built in — the big one WP Rocket lacks
Database caching, fragment caching, and opcode caching options
Browser caching, CDN integration with extensive provider support
Minify for CSS/JS (powerful but historically the trickiest section to configure safely)

W3TC's settings pages are famously dense — dozens of sections, each with a dozen toggles. In the right hands it is a precision instrument. In the wrong hands it is a fast way to break a site's layout at 2 AM.

Feature-by-Feature Comparison

Feature	WP Rocket	W3 Total Cache
Price	Premium, annual license	Free
Page caching	Yes, with preloading	Yes (multiple storage engines)
Object cache (Redis/Memcached)	No	Yes — built in
Database caching	Cleanup only	Yes, dedicated module
Fragment caching	No	Yes
Minify CSS/JS	Yes (safe defaults)	Yes (powerful, fiddly)
Delay JavaScript	Yes	Limited
Remove unused CSS	Yes	No
Lazy loading	Yes	Yes
CDN integration	Yes + Cloudflare add-on	Yes (very broad provider support)
Beginner friendliness	Excellent	Poor — expert-oriented
Support	Dedicated tickets	Community/docs

The table tells the real story: W3TC does more (object cache, fragment cache, database cache), while WP Rocket does less but makes it nearly foolproof.

The Real Differences (Beyond the Marketing)

1. Object caching: W3TC's killer feature

This is the single biggest functional gap. If your site is dynamic — WooCommerce, memberships, forums, anything with logged-in users — page caching alone does not help much, because every visitor sees different content. Object caching (via Redis or Memcached) speeds up the database layer for everyone, logged in or not.

W3TC includes Redis/Memcached object caching for free. With WP Rocket you would add a separate plugin (like Redis Object Cache) alongside it. Our Redis setup guide walks through the standalone approach — it pairs fine with WP Rocket, but it is a second plugin to manage.

2. Ease of use vs. control

WP Rocket's setup wizard gets most sites 80% optimized in minutes. W3TC's general settings page alone can take an hour to work through carefully — and the minify section has broken more layouts than any other settings screen in WordPress history. The rule with W3TC: enable one module at a time, test as a logged-out visitor, and keep notes on what you changed.

3. Compatibility and "mystery breakage"

WP Rocket's decade of real-world use means most conflicts are documented and support has seen them before. W3TC's power cuts both ways: its database-caching and fragment-caching modules can conflict with plugins that expect fresh data (e-commerce, membership, anything with real-time counts). If you enable W3TC's database cache on a WooCommerce store and the cart starts acting haunted, that module is suspect number one.

4. What "free" actually costs

W3TC costs $0 and potentially several hours of careful configuration and testing — plus ongoing attention, because its many modules interact with plugin updates in ways that occasionally need re-tuning. WP Rocket costs an annual fee and roughly 30 minutes. For a personal blog, the hours are a fine trade. For client work or a business site, the fee is usually cheaper than your time.

The Free-Stack Alternative

If the answer "it depends" is not helpful, here is a concrete free setup that covers most of what WP Rocket does:

Page caching: a solid free caching plugin (or LiteSpeed Cache if your host runs LiteSpeed — it is free and excellent there)
Object caching: W3TC just for its object-cache module, or the standalone Redis Object Cache plugin
File optimization: Autoptimize (free) for minify/defer, used carefully
Images: ShortPixel or Imagify free tier, or a similar optimizer
CDN: Cloudflare free tier

This stack takes longer to assemble and tune than installing WP Rocket, but it costs nothing and teaches you how each layer works. Many performance-minded site owners end up here eventually.

Who Should Pick Which?

Choose WP Rocket if you:

Want the fastest path from "slow site" to "fast site"
Are new to performance work or manage client sites where reliability matters
Value dedicated support over forum archaeology
Do not need object caching, or are happy adding a separate Redis plugin

Choose W3 Total Cache if you:

Are comfortable with technical settings and methodical testing
Need free, integrated Redis/Memcached object caching
Run a dynamic site (WooCommerce, membership, community) where the database layer is the bottleneck
Enjoy having every dial exposed

Build the free stack if you:

Have more time than budget
Want to learn how each caching layer actually works
Are on LiteSpeed hosting (start with free LiteSpeed Cache before anything else)

How to Decide in 10 Minutes

Budget zero? Free stack or W3TC — no shame in it.
Dynamic site with logged-in users? You need object caching: W3TC has it built in; WP Rocket needs a companion plugin.
Client or business site? WP Rocket — the support alone justifies it when downtime costs money.
Love tinkering? W3TC will make you happy. Hate tinkering? It will make you miserable.
Whichever you pick: configure one module at a time, test logged-out, and measure with PageSpeed Insights before and after.

Frequently Asked Questions

Is W3 Total Cache still maintained in 2026?

Yes — it remains one of the most-installed caching plugins in the WordPress directory and continues to receive updates. Its core architecture is mature, which is both a strength (stable, battle-tested) and the source of its complexity.

Can I use W3 Total Cache just for object caching?

Yes, and many people do exactly that: enable only the Object Cache module (pointed at Redis or Memcached) and use a different plugin for page caching. W3TC's modules are independent — you are not forced to enable everything.

Does WP Rocket work with Redis?

Not directly — WP Rocket has no object-cache module. The standard approach is WP Rocket for page caching plus the free Redis Object Cache plugin for the object layer. They coexist fine because they handle different layers (page cache vs object cache explained).

Which is better for WooCommerce?

WooCommerce sites benefit most from object caching (dynamic carts, accounts, product queries), which favors W3TC's built-in Redis support or WP Rocket + a Redis plugin. Either way, never cache cart/checkout/account pages as full pages — both plugins exclude them by default, and you should verify that.

Is WP Rocket worth it if I am technical?

Honestly? Less so. If you genuinely enjoy configuration and can debug conflicts yourself, W3TC or the free stack gives you equal or greater capability for $0. WP Rocket's price buys convenience and support — valuable, but optional for experts.

The Bottom Line

WP Rocket is worth paying for if your time is valuable, you want the smoothest setup in the business, and you run standard sites where page caching does the heavy lifting. W3 Total Cache is the right call if you are technical, need free object caching, and want maximum control. And if your budget is zero, the free stack gets you remarkably far — it just bills you in hours instead of dollars.

LiteSpeed Cache vs WP Rocket (2026): Which Caching Plugin Wins?

WP Speed Audits — Mon, 19 Oct 2026 05:18:53 +0000

Originally published on WP Speed Audits.

LiteSpeed Cache vs WP Rocket (2026): Which Caching Plugin Wins?

Here is a comparison with an unusual twist: one of these plugins is free, and on the right server, it is also the faster one. LiteSpeed Cache vs WP Rocket is not just a feature shootout — the answer depends heavily on one question: what web server does your hosting use?

This guide compares them honestly — features, pricing, server requirements, ease of use and real-world fit — without invented benchmark numbers. By the end, you will know which one belongs on your site.

The one-sentence version: on LiteSpeed servers, LiteSpeed Cache (free) is almost always the right pick. On any other server, WP Rocket is the premium all-rounder to beat.

The Short Answer

Pick LiteSpeed Cache if your host runs LiteSpeed Web Server (many shared hosts do — ask yours). It is free, and its server-level page caching beats any PHP-level plugin on the same hardware.
Pick WP Rocket if your host runs Apache or Nginx. LiteSpeed Cache still works there, but without the LiteSpeed server it loses its superpower — and WP Rocket's polish, compatibility history and support win out.
Pick neither yet if you have not checked your server type. This single fact decides the whole comparison, and it takes 30 seconds to find out (see below).

How to Check Your Server Type (30 Seconds)

Before reading further, find out what you are running. Any of these works:

Ask your host. Open a support chat and ask: "Do my sites run on LiteSpeed Web Server?" They will answer in one sentence.
Check an HTTP response header. Open your site, open DevTools (F12) → Network tab → reload → click the main document → look at the server response header. LiteSpeed means LiteSpeed; nginx or Apache means what it says.
Check your hosting plan page. Hosts that use LiteSpeed usually advertise it — it is a selling point.

Now the comparison will actually make sense.

What Each Plugin Does

LiteSpeed Cache: The Free Server-Level Specialist

LiteSpeed Cache (by LiteSpeed Technologies) is free and does something no PHP plugin can: it caches pages at the web server level, before WordPress/PHP even wakes up. On a LiteSpeed server, that means:

Server-level page caching — the fastest kind of full-page cache available to WordPress
Object cache + browser cache management from one dashboard
Image optimization via QUIC.cloud (free tier with generous quotas): WebP conversion, lazy loading
CSS/JS optimization: minify, combine, defer, delay JavaScript, remove unused CSS, critical CSS generation
Database cleaner, heartbeat control, crawler for cache warming
QUIC.cloud CDN integration (with free tier)

The catch: roughly half of this magic only happens on LiteSpeed servers. On Apache/Nginx, LiteSpeed Cache becomes a capable but ordinary PHP-level caching plugin — still good, still free, but no longer special.

WP Rocket: The Premium All-Rounder

WP Rocket (by WP Media, around since 2013) is the most recommended premium caching plugin in WordPress, and it works identically on every server — LiteSpeed, Apache or Nginx:

Page caching with automatic preloading
Browser caching, GZIP compression rules
File optimization: minify/combine CSS/JS, defer and delay JavaScript, remove unused CSS
Media: lazy loading for images, iframes, videos
Database optimization, Google Fonts optimization, CDN integration, Cloudflare add-on, heartbeat control

Its strength is consistency and polish: the same excellent dashboard, documentation and support no matter where you host.

Feature-by-Feature Comparison

Feature	LiteSpeed Cache	WP Rocket
Page caching	Yes — server-level on LiteSpeed	Yes — PHP-level, with preloading
Price	Free (+ optional paid QUIC.cloud tiers)	Premium, annual license
Works on any server	Yes, but best on LiteSpeed	Yes — identical everywhere
Minify/combine CSS/JS	Yes	Yes
Delay JavaScript	Yes	Yes
Remove unused CSS	Yes	Yes
Critical CSS	Yes (via QUIC.cloud)	Yes
Image optimization	Yes (QUIC.cloud, free tier)	Lazy loading only (no compression)
Object cache	Yes (Memcached/Redis support)	No (page cache focused)
CDN integration	Yes + QUIC.cloud CDN	Yes + Cloudflare add-on
Beginner friendliness	Good, but many settings	Excellent — famous setup wizard
Support	Forum/community (free plugin)	Dedicated ticket support

The Real Deciding Factors

1. Your server (decides ~70% of this)

This is the whole game. Server-level caching skips PHP entirely for cached pages — no PHP plugin, however good, can match that on identical hardware. If you are on LiteSpeed, LiteSpeed Cache is not just cheaper — it is architecturally faster.

On Apache or Nginx, the tables turn: LiteSpeed Cache drops to PHP-level caching like everyone else, and WP Rocket's decade of refinement, better defaults and support become the differentiators.

2. Price vs. polish

LiteSpeed Cache is free — remarkably full-featured for free. WP Rocket costs an annual fee. What the fee buys: the most beginner-friendly setup in the category, superb documentation, and support engineers who have seen every bizarre theme conflict since 2013. For agencies and client sites, that support alone often justifies the price.

3. Image optimization

WP Rocket deliberately does not compress images — it expects you to handle that separately. LiteSpeed Cache bundles QUIC.cloud image optimization (WebP conversion, compression) with a free quota that covers most small-to-medium sites. If you want one plugin to do everything, LiteSpeed Cache covers more ground.

4. Object caching

LiteSpeed Cache can manage your object cache (Redis/Memcached) connection; WP Rocket does not touch object caching at all. If you run a dynamic site, membership site or WooCommerce store where object caching matters, LiteSpeed Cache + Redis is a potent free combination. Our Redis setup guide walks through it.

5. Compatibility track record

WP Rocket's quiet superpower: a decade of real-world use across every host, theme and page builder imaginable. LiteSpeed Cache is mature too, but its most aggressive features (critical CSS, JS delaying) need the same careful testing as any optimization plugin — especially with page builders. Whatever you choose: after enabling optimizations, test your site as a logged-out visitor and click everything.

Can You Use Both Together?

No — never run two page-caching plugins simultaneously. They will conflict and can break your site in confusing ways. Pick one. (You can use LiteSpeed Cache for page caching plus a specialized plugin like Perfmatters for script management — that is a common advanced stack — but one page cache only.)

What About Cloudflare APO?

Cloudflare APO caches your HTML at Cloudflare's edge, which overlaps heavily with what both plugins do. Many fast sites run APO plus one caching plugin: APO handles edge HTML delivery, the plugin handles file optimization, database cleanup and media. Our CDN testing guide shows how to verify your CDN is actually serving cached content.

Who Should Pick Which?

Choose LiteSpeed Cache if you:

Host on a LiteSpeed server (check first — this is the deciding factor)
Want the most features for free, including image optimization
Run a dynamic/WooCommerce site and want integrated object cache management
Are comfortable with a bigger settings dashboard

Choose WP Rocket if you:

Host on Apache or Nginx
Are new to performance optimization and want the safest, most polished setup
Run client sites and value dedicated support with a decade of edge cases behind it
Prefer one well-documented workflow over a sprawling free dashboard

Reconsider your hosting if you:

Are on slow shared Apache hosting and wondering why no plugin helps. The plugin is the finishing touch — hosting quality (especially Time to First Byte) matters more than any caching plugin choice. Our 20-step performance checklist starts there for a reason.

The Bottom Line

On LiteSpeed servers: LiteSpeed Cache wins — and it is free. Server-level caching is an architectural advantage no PHP plugin can overcome.

On Apache/Nginx: WP Rocket wins on polish, compatibility history and support — worth the annual fee if you value a smooth, well-supported setup.

Either way, check your server type first, configure conservatively, test everything as a logged-out visitor, and remember: the plugin squeezes out the last drops of speed — hosting, theme weight and images decide the first 90%.

Frequently Asked Questions

Is LiteSpeed Cache really better than WP Rocket?

On LiteSpeed servers, yes — server-level page caching is fundamentally faster than PHP-level caching, and LiteSpeed Cache is free. On Apache or Nginx servers, WP Rocket is generally the better pick for its polish, defaults and support.

Is LiteSpeed Cache completely free?

The plugin is free with no feature-locked premium version. Some cloud features (image optimization, critical CSS generation, QUIC.cloud CDN) run through QUIC.cloud, which has a generous free tier and paid tiers for high-traffic sites.

Can I switch from WP Rocket to LiteSpeed Cache later?

Yes. Deactivate and delete WP Rocket first (never run both), then install LiteSpeed Cache and configure it. Clear all caches after switching and re-test your key pages. Your content is untouched — only the caching layer changes.

Does LiteSpeed Cache work on Nginx?

Yes, it installs and works on Nginx and Apache, but without a LiteSpeed server you lose server-level caching — its biggest advantage. It is still a solid free caching plugin there, just not a special one.

Which is easier for beginners?

WP Rocket, clearly. Its setup wizard and documentation are the best in the business — most sites get the majority of the benefit with near-default settings. LiteSpeed Cache is powerful but its dashboard has far more toggles, which can overwhelm newcomers.

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.