# FlyingPress vs WP Rocket in 2026: One of Them Serves the First Visitor an Unoptimized Page

> FlyingPress serves an uncached page raw and unoptimized by its own documentation. WP Rocket defers five named features. Both priced within $1 at one site.

- Published: 2026-09-24
- Updated: 2026-10-04
- Author: xSpeed Cache Team
- Tags: FlyingPress, WP Rocket, Comparison, Caching, Performance, platform:wordpress, fix:unused-css
- Canonical: https://xspeedcache.com/blog/flyingpress-vs-wp-rocket/

---

Updated September 2026

WP Rocket Single costs $59.95 a year and FlyingPress Starter costs $59, both read from [each](https://flyingpress.com/pricing/) [vendor's](https://wp-rocket.me/pricing/) own pricing page on 24 September 2026, with WP Rocket's figure unchanged since 23 September 2026. At three sites the two ladders sit $10.95 apart. The comparison people expect from a pair priced this closely is a speed test. The more useful comparison is which of your pages each plugin optimizes at all, because both vendors answer that question in their own documentation, and the two answers are not the same shape. Every price, tier and code marker below was verified on the day of writing.

## Quick Summary: Which of the Two Suits the Site You Actually Run

| Your situation | Pick | Why |
|:---|:---|:---|
| One site, and you want to try before paying | FlyingPress | 14-day free trial with full access. WP Rocket's own FAQ says it offers no trial, only a 14-day refund |
| Three sites | Either, on price | $109 against $119.95 a year for the same three activations |
| Between four and twenty-five sites | FlyingPress | $229 a year for 25. WP Rocket's ladder steps from 3 sites straight to 50 |
| Fifty or more sites | WP Rocket | $299.95 for 50, and it sells 100 and 500 tiers above that |
| Traffic arrives on pages nobody preloaded | WP Rocket | Minification, defer and lazy load still apply on a cache miss |
| You want page HTML cached at Cloudflare's edge on a free Cloudflare plan | FlyingPress | Its Cloudflare integration does full-page HTML caching and syncs exclusions both ways |
| You need to change a documented default without adding a plugin | FlyingPress | Its help centre ships no downloadable plugins at all |
| You want to pay once rather than every year | Neither | Both are annual subscriptions |

![Cover graphic: FlyingPress vs WP Rocket, with the FlyingPress documentation line that an uncached page is served raw and unoptimized](https://xspeedcache.com/images/blog/cover-flyingpress-vs-wp-rocket.webp)

## Two Price Ladders That Touch at One Site and Split at Twenty-Five

Both products are premium-only. Neither appears in the wordpress.org plugin directory, which a direct Plugin API query confirms for the slugs `flyingpress`, `flying-press`, `wp-rocket` and `wprocket`, all four returning `Plugin not found` on 24 September 2026. That has one consequence worth stating before any table: **no install count exists for either product**, so nobody, including this article, can tell you how many sites run them.

| Sites covered | FlyingPress | WP Rocket |
|:---|:---|:---|
| 1 | Starter, $59/yr | Single, $59.95/yr |
| 3 | Pro, $109/yr | Plus, $119.95/yr |
| 25 | Business, $229/yr | Not sold |
| 50 | Not sold | Multi, $299.95/yr |
| 100 and 500 | Not sold | Multi, higher tiers |
| Unlimited | Unlimited, $279/yr | Not sold |
| Trial | 14 days, full access | None |
| Refund | None, the trial replaces it | 14 days |
| Staging sites count against the licence | No | Not stated on the pricing page |

Read the shape rather than the numbers. At one and three sites these are the same product at the same price, and picking on cost alone is a rounding error. The gap opens in the middle of the range, and it opens in FlyingPress's favour: a person with a dozen client sites pays $229 or $299.95 depending on which vendor they picked, for licences that cover 25 and 50 sites respectively. We wrote about that specific gap in [WP Rocket's own ladder](https://xspeedcache.com/blog/wp-rocket-pricing/) two days ago, and nothing about it has changed since.

One recurring cost belongs in the same paragraph as the licence, because it is easy to read past. FlyingCDN, the optional Cloudflare Enterprise network FlyingPress sells alongside the plugin, is [billed at $10 per domain per month](https://docs.flyingpress.com/en/articles/11403515-flyingcdn-billing-and-pricing) including 100GB of bandwidth, with each further 100GB at $5, and its own documentation counts cached and uncached traffic alike towards that meter. On a single site that is $120 a year on top of $59. It is genuinely optional, and the plugin's free Cloudflare integration covers page caching at the edge without it, but a budget built on the licence price alone will be wrong by more than the licence.

## Where Each Plugin's Optimization Actually Runs

This is the part that decides which product behaves better on your traffic, and both vendors document it plainly enough that nobody needs to guess.

FlyingPress treats optimization as a build step. Its ["When and Where FlyingPress Caches Pages"](https://docs.flyingpress.com/en/articles/11406425-when-and-where-flyingpress-caches-pages) article describes a preload queue: a URL enters the queue, the page is generated, and the optimized HTML is written to disk as `index.html.gz` under `wp-content/cache/flying-press/`. Used CSS comes from what the vendor calls a cloud-based optimizer, which extracts the CSS the page actually needs and inlines it. Lazy rendering works the same way, and [the documentation](https://docs.flyingpress.com/en/articles/11406903-lazy-render-elements) is explicit that the detection happens off the site: "Our cloud optimizer automatically detects elements that are suitable for lazy rendering," followed by "No manual setup is required—FlyingPress handles everything during caching."

WP Rocket splits the same work in two, and publishes the split as a list. Its ["Asynchronous optimizations"](https://docs.wp-rocket.me/article/1688-asynchronous-optimizations) article names exactly five things that are not applied immediately: Remove Unused CSS, and the four Priority Elements features, which are Optimize critical images, Automatic Lazy Rendering, Preload fonts and Preconnect to external domains. Everything else in the plugin, minification, combining, deferred JavaScript, delayed JavaScript and image lazy loading, is applied while the page is being generated.

![Diagram comparing where FlyingPress and WP Rocket run their optimization, and what each one does on a cache miss](https://xspeedcache.com/images/blog/flyingpress-wp-rocket-where-optimization-runs.webp)

Both designs therefore have an asynchronous tail. The difference is what sits outside it.

- **FlyingPress:** the whole optimization set is on the far side of cache generation. A page that has not been through the queue has not been optimized.
- **WP Rocket:** five named features are on the far side of a cloud scan. The rest apply the moment the page is built.

That distinction stops being academic the second a reader lands on a page the queue has not reached.

## The First Visitor Is the One Who Pays

FlyingPress's [caching documentation](https://docs.flyingpress.com/en/articles/11406425-when-and-where-flyingpress-caches-pages) states the consequence in a single sentence, and it is the most decision-relevant line either vendor publishes:

> "If a page isn't already cached, the raw (uncached and unoptimized) version is served once. That URL is then added to the queue with high priority for caching."

Read literally, that means an uncached page arrives with no minification, no deferred scripts, no used-CSS extraction and no lazy rendering. The second visitor gets all of it. The first gets the theme as the theme ships.

The same behaviour appears in a second place, which is what makes it a design choice rather than an edge case. FlyingPress can cache pages for logged-in users by role, storing a separate file per role, and [its documentation](https://docs.flyingpress.com/en/articles/11406461-cache-for-logged-in-users-by-role) notes of those files: "These versions are cached without frontend optimizations (minification, lazy load, etc.)." Membership sites, WooCommerce customer accounts and any logged-in area therefore run on cached but unoptimized HTML by design.

Two consequences follow, and they are the ones to check against your own traffic:

- A page nobody has requested since the last purge is a page nobody has optimized yet.
- A signed-in reader on a role-cached page is served a file that was never optimized at all.

WP Rocket's answer to the same problem is preloading rather than a different architecture. Its [Preload documentation](https://docs.wp-rocket.me/article/8-preload-cache) says the feature "is enabled by default on plugin installation" so that "there's no need to wait until a real visitor accesses the pages before starting to serve cache files, therefore, your pages are fast from the first visit." FlyingPress preloads too. The difference is the penalty when preloading has not happened yet, and there are ordinary reasons it has not: a large archive, a freshly purged cache, a URL with a query string, a page published an hour ago, a site that purges on every product update.

Neither behaviour is a defect. A build-step design buys something real, which the next section is about. But if a meaningful share of your traffic lands on long-tail URLs that nobody preloaded, the two products are doing measurably different things for those readers, and no benchmark of a warmed home page will show it.

## What Each One Does That the Other Cannot

Two things survive this comparison as genuine asymmetries, and they run in opposite directions.

**FlyingPress pushes the HTML itself to Cloudflare, free.** Its [Cloudflare integration](https://docs.flyingpress.com/en/articles/11977701-flyingpress-cloudflare-integration-full-page-caching-setup-guide) caches full HTML pages at the edge, states that it "Works with all Cloudflare plans, including the free plan," and keeps the two configurations in step automatically: pages excluded in the plugin are excluded at Cloudflare, ignored query strings are ignored at Cloudflare, bypass cookies bypass at Cloudflare, and enabling separate mobile cache enables Cache by Device Type. Cloudflare caches 56 file extensions by default and HTML is not among them, which is the problem that integration exists to solve, and one we covered in detail when writing about [connecting a page cache to Cloudflare](https://xspeedcache.com/blog/cloudflare-wordpress-cache-setup/). WP Rocket's own pricing page offers something narrower under the same heading: RocketCDN speeds up "3 key pages" for free "across 10 edge locations", which is a different proposition from putting the whole site's HTML on a network you already pay nothing for.

**WP Rocket gives you far more places to intervene.** That is the other side of the helper-plugin count below, and it is a real advantage for anyone who has ever had one stubborn script break a layout. FlyingPress's controls are deliberately coarser. Its lazy-render exclusions match a substring of the element, and the documentation states that "Regex and wildcards are not supported." Its used-CSS safelist accepts CSS selectors only, and says in as many words that file names will not work. Its minifier has, by its own description, "no built-in exclude list."

### The One Thing Both of Them Leave Open

There is a third difference that is not an advantage for either side, and it matters for anyone running a store. FlyingPress serves cached pages to shoppers who have items in their basket, and [tells you to add](https://docs.flyingpress.com/en/articles/11405614-woocommerce-e-commerce-compatibility) the `woocommerce_items_in_cart` cookie to Bypass Cache for Cookies if your theme does not update the cart count over AJAX, warning that doing so "will reduce your cache hit ratio." We read twelve plugins from source yesterday, neither of these two among them, and found the field splits cleanly on it, in [which caching plugins stop a shopper writing your public cache](https://xspeedcache.com/blog/woocommerce-caching-plugins/). WP Rocket documents the same failure and distributes its fix as a separate download called Prevent Cache Generation for Active Carts. Both vendors know about it. Neither closes it by default.

## The Receipt Test: Four Strings That Prove an Optimization Landed

Settings screens tell you what is switched on. They do not tell you what reached the page a reader is looking at, and with two products that both defer work to a cloud scan, those are different questions. So here is the test, built entirely from markers each vendor documents itself.

Open the page logged out, view source, and search for the strings below.

| Search the page source for | Emitted by | What a hit proves |
|:---|:---|:---|
| `<style id="flying-press-css">` | FlyingPress | Used CSS was generated for this URL and inlined |
| `data-wpr-lazyrender="1"` | WP Rocket | Below-fold elements were detected and marked |
| `rocket-lazyrender-inline-css` | WP Rocket | The `content-visibility` rule reached the page |
| `data-rocket-location-hash` | WP Rocket | Scanning has started and has not finished yet |

That last row is the one worth knowing about. WP Rocket's [Automatic Lazy Rendering documentation](https://docs.wp-rocket.me/article/1835-automatic-lazy-rendering) describes a two-pass process: an identifier is added to elements and a script is injected, the script reports which elements sit below the fold, and "the next time the page is cached, the markup of below the fold elements will be modified." A page carrying `data-rocket-location-hash` is mid-flight. A page carrying `data-wpr-lazyrender="1"` is done. Confusing the two produces a bug report that resolves itself overnight.

Run it on two URLs, not one: the home page, which every preloader reaches first, and a URL from deep in the archive that nobody has requested today. The gap between those two answers is the whole subject of this article, and it takes about ninety seconds to measure on your own site.

![Table of documented source markers for proving which optimizations reached a given page](https://xspeedcache.com/images/blog/optimization-receipt-test-markers.webp)

**State the limits, because this test has three.** Absence is weaker evidence than presence: a vendor can rename a marker in any release, so a miss means look again rather than conclude. A logged-in session, a bypass cookie or a device-specific cache will each change the answer, so test logged out and on the device class you care about. And a marker proves an optimization was applied, never that it helped. For the second question you need a measurement rather than a grep, which is where a scan that reports server response, compression and render-blocking together earns its place. Our own plugin publishes an `X-XSpeed-Cache` response header for the same purpose, and a header has one practical advantage over a body marker: it survives on responses where the body has been rewritten downstream.

## We Counted Every Helper Plugin in WP Rocket's Documentation

When a documented default does not suit your site, how does each vendor hand you the change? We counted, on 24 September 2026, from each vendor's own documentation index rather than from a feature grid.

| Measure | WP Rocket | FlyingPress |
|:---|:---:|:---:|
| Documentation sections counted | 13 feature categories | 8 collections |
| Articles fetched | 107 | 93 |
| Articles offering a downloadable plugin | 49 | 0 |
| Distinct helper plugins named | 54 | 0 |
| Articles saying a manual code edit is required first | 10 | 0 |
| Articles offering a filter snippet instead | 27 | 14 |

Forty-nine of 107 articles in WP Rocket's feature categories, a little under half, end by handing the reader a zip file to download, unzip, sometimes edit in a text editor, re-zip, upload and activate. The names are ordinary maintenance: Disable Page Caching For Logged-In Users, Ignore Query Strings, Exclude Scripts from Defer JS, Set tablets as mobile, Remove ETag. Ten of them carry the notice "Manual code edit required before use!" before they will do anything.

![Census comparing how many WP Rocket and FlyingPress documentation articles hand the reader a separate plugin](https://xspeedcache.com/images/blog/wp-rocket-helper-plugin-census.webp)

FlyingPress's help centre offers none. Fourteen of its 93 articles give a one-line filter to paste instead, and the rest route you to a settings box.

**How this was counted, and what it does not show.** Every article linked from WP Rocket's thirteen feature category pages and FlyingPress's eight documentation collections was fetched under a browser user agent and searched for a `.zip` link and for the vendor's own naming convention. One WP Rocket article listed on a category page did not fetch and is excluded, which is why the denominator is 107 rather than 108. Three caveats travel with the result. The two help centres are organised differently, so an article count is not a feature count. A helper plugin is a distribution choice rather than a defect, and a vendor that publishes 54 of them is documenting 54 supported behaviours, which is more than most vendors document at all. And the count says nothing about how often anyone needs one.

What it does show is the shape of the maintenance each product asks for. A site on WP Rocket with four unusual requirements is plausibly a site with four extra plugins in its plugin list, each pinned to a documentation page, each surviving updates on its own. A site on FlyingPress with four unusual requirements is more likely a site where one of the four could not be expressed at all.

## Running Either of Them Across Twenty-Five Client Sites

Fleet work changes which of these facts matters. A single site owner meets a cache miss occasionally. An agency meets it on every deploy, on every client, and the twenty-five-site question is where the two ladders diverge most: $229 a year against a product that does not sell that tier.

We build xSpeed Cache, so treat what follows as the disclosure it is, and check the numbers against the same sources as everything above. xSpeed Cache reports 6,000+ active installs, version 1.3.5, rated 5.0 from 13 ratings, last updated on 22 September 2026, all from a direct wordpress.org Plugin API query on 24 September 2026. Against two products with roughly a decade of track record each, that is a short one. The honest Cons entry is shorter still: Critical CSS and Remove Unused CSS are Pro features in our plugin, and those two are exactly what both of the products above lead with, so a free xSpeed install is not a free FlyingPress or a free WP Rocket.

Three things are genuinely different rather than differently worded, and all three are fleet-shaped:

- **A free tier exists at all.** FlyingPress sells a 14-day trial and WP Rocket sells neither a trial nor a free version, so evaluating either across twenty-five client sites means paying first or working inside two weeks.
- **A lifetime licence.** 25 sites for $249 once against $229 or $299.95 every year. Our [80-capability comparison](https://xspeedcache.com/comparison/) records which tier each feature ships in for all three products, which is the column most comparison tables omit.
- **An MCP server in the free tier**, so the fleet can be read and changed by an agent rather than by twenty-five dashboard logins, which is the part of this job that scales worst by hand.

Whichever plugin you land on, verify the result from outside the server rather than from its own settings page. Run the free xSpeed Scan on any site you are judging: [xspeedcache.com/scan/](https://xspeedcache.com/scan/).

If you are moving between any two of these, the settings do not travel by themselves. Our notes on [importing from another cache plugin](https://xspeedcache.com/docs/migration/) cover what an importer can read and what it cannot, and [object cache configuration](https://xspeedcache.com/docs/object-cache/) covers the layer all three of these products leave to Redis or Memcached. FlyingPress added its own Redis object cache with an `object-cache.php` drop-in, which is worth knowing before you install a second drop-in on top of it.

## Common Mistakes Buyers Make With This Comparison

- **Benchmarking a warmed home page.** It is the one URL both preloaders reach first, so it is the one URL where the two products are most alike. Test a warmed page and a cold one, and report both numbers.
- **Reading the entry price as the cost.** At one site the difference is 95 cents a year. The real variables are the site count you land on, whether you add FlyingCDN at $120 a year per domain, and the hours spent on exclusions.
- **Running either one alongside another optimization plugin.** FlyingPress automatically disables conflicting optimizations in Breeze, EWWW Image Optimizer, Perfmatters, ShortPixel Adaptive Images and SiteGround Optimizer, and says outright: "For best results, use FlyingPress as your only optimization plugin." We reached the same conclusion from the other direction when measuring [what an asset-only optimizer adds to a cache plugin](https://xspeedcache.com/blog/perfmatters-vs-caching-plugin/).
- **Assuming lazy rendering is a FlyingPress exclusive.** Both products now ship it, both implement it with `content-visibility: auto`, and both apply it asynchronously. It was a differentiator. It is a checkbox.
- **Trusting the settings screen.** Every optimization discussed here can be enabled in the dashboard and absent from the page in front of a reader. The receipt test above exists for that reason.

## Frequently Asked Questions

### Is FlyingPress faster than WP Rocket?

On a cached, preloaded page the two are close enough that ordinary test-to-test variance will swamp the difference, which is why this article ranks them on architecture instead. On an uncached page they are not close: FlyingPress serves the raw page by its own documentation, and WP Rocket still applies minification, deferral and lazy loading. Test both states.

### I only have one site. Does any of this change my decision?

Mostly it comes down to the trial. FlyingPress gives you 14 days of full access before charging, WP Rocket gives you a refund window after charging, and at $59 against $59.95 nothing else about the money is decisive.

### My pages look unstyled for a second after I clear the cache. Which plugin is doing that?

Either, and for different reasons. On FlyingPress the page may simply not be through the queue yet, so no used CSS has been inlined. On WP Rocket, Remove Unused CSS is asynchronous and the page may be waiting for its cloud scan. Search the source for `<style id="flying-press-css">` or for `data-rocket-location-hash` to tell which.

### Do I need FlyingCDN to get the Cloudflare page caching?

No. FlyingPress's own integration guide says its Cloudflare full-page HTML caching "Works with all Cloudflare plans, including the free plan." FlyingCDN is a separate paid product at $10 per domain per month that adds image optimization, Argo routing and the Enterprise network on top.

### Can I run both plugins at once while I migrate?

Do not. FlyingPress's compatibility documentation lists the optimization plugins it automatically disables and recommends running it alone. Two page caches writing the same drop-in file is one of the most common ways a WordPress site starts serving stale or broken HTML.

### How many sites run each of these plugins?

Nobody outside the two companies knows. Neither product is distributed through wordpress.org, so there is no active-install figure for either, and any article quoting one is estimating. Treat install counts as available for directory plugins and unavailable for these two.

### Should I worry that my logged-in members get unoptimized pages on FlyingPress?

Worry is strong, but know about it. Role-based logged-in caching stores a file per role, and FlyingPress documents that those files are cached without minification or lazy load. If most of your traffic is signed in, that is a much bigger consideration than anything on the pricing page.

### Does WP Rocket's Remove Unused CSS need my firewall opened?

Yes, in effect. The feature is generated by WP Rocket's own service, which [visits your pages](https://docs.wp-rocket.me/article/1529-remove-unused-css) with two documented user agents carrying `WP-Rocket-SaaS/1.0`, and the documentation asks you to allow-list those agents or its published IP ranges. Sites behind strict firewalls or Cloudflare Bot Fight Mode see the feature quietly fail.

### We run twenty client sites. Which licence is cheaper?

FlyingPress Business covers 25 sites for $229 a year. WP Rocket has no tier between 3 sites and 50, so twenty sites means the $299.95 Multi licence. That gap is the single largest price difference in this comparison.

### My cart count stopped updating after I turned caching on. What broke?

The page is cached and your theme is reading the cart from the HTML rather than over AJAX. FlyingPress's fix is to add `woocommerce_items_in_cart` to Bypass Cache for Cookies, at the cost of a lower hit ratio, and its documentation suggests fixing the theme instead. The same issue appears on [WooCommerce stores](https://xspeedcache.com/use-cases/woocommerce/) running any page cache.

### Is there a free option that does most of this?

For page caching, yes, and several are genuinely good, which we measured when reading twelve of them from source in [which free caching plugins actually cache](https://xspeedcache.com/blog/free-wordpress-caching-plugins/). For used-CSS extraction and automatic lazy rendering, the free field thins out quickly, and that is the work both paid products here are really selling. Our own xSpeed Cache free tier sits in the same place as the rest of the free field on that one point: it caches, minifies, defers and lazy loads for nothing, and leaves used-CSS removal to Pro.

## Conclusion: FlyingPress or WP Rocket?

These two are not separated by speed. They are separated by a design decision each vendor documents: FlyingPress makes optimization a property of the cached file, and WP Rocket makes most of it a property of the page and the rest a property of a later scan. Everything downstream, the behaviour on a miss, the treatment of logged-in caches, the number of helper plugins, follows from that one choice.

| If you want... | Choose | The reason in one line |
|:---|:---|:---|
| A trial before you pay | FlyingPress | 14 days, full access, no card charged until it ends |
| Every visitor to get minified, deferred assets | WP Rocket | Those apply at page generation, not after a cloud scan |
| 4 to 25 sites on one licence | FlyingPress | $229/yr for 25, a tier WP Rocket does not sell |
| 50 sites or more | WP Rocket | $299.95/yr for 50, with tiers above it |
| Free page-HTML caching at Cloudflare's edge | FlyingPress | Works on Cloudflare's free plan and syncs exclusions |
| The most exclusion controls available | WP Rocket | 54 documented helper plugins and a large filter surface |
| To pay once instead of annually | xSpeed Cache | The only lifetime licence of the three, $79 to $399 |
| To try a paid engine at no cost first | xSpeed Cache | A free tier rather than a trial window |

**What to do this week:**

1. Open your slowest long-tail URL logged out, view source, and search it for the four markers above. That tells you whether your current plugin is optimizing the pages people actually land on.
2. Count your sites, then read the licence ladder again. The 4-to-25 band is where the money is.
3. If you are adding a CDN, price the bandwidth meter, not the plugin.
4. Scan the result from outside the server, so the verdict is not the settings screen's opinion of itself: [xspeedcache.com/scan/](https://xspeedcache.com/scan/).
5. If you want a lifetime licence and a free tier to evaluate on, our [pricing page](https://xspeedcache.com/pricing/) lists both, from $29 a year or $79 once, with a 14-day money-back guarantee. **If you want the trial and the twenty-five-site licence, FlyingPress is the better buy of the three, and we would rather say so than pretend otherwise.**

If you run one of these and have measured something that contradicts anything above, we would genuinely like the counterexample. Every claim here comes from a vendor document or a live query, and all of them are dated so they can be checked again next month.