FlyingPress Review: Why We Switched to RunCloud and WP Super Cache

We stopped using FlyingPress because it created too much ongoing work on the WordPress sites we managed. The biggest concern was scheduled Auto-Refresh Cache being disabled by default, leaving us to deal with nonce issues that a sensible refresh schedule could help prevent.

We generally moved back to RunCloud’s built-in caching or WP Super Cache. We wanted a simpler setup that kept sites fast and working reliably.

Auto-Refresh should be on by default

A page can load quickly and look fine while an expired security token stops a form working.

WordPress uses security tokens called nonces to help check requests. With standard settings, they remain valid for between 12 and 24 hours. When a form or interactive feature includes a nonce in cached HTML, that token can expire while the page keeps serving it.

A contact page might work straight after clearing the cache, then fail the following day. Nobody needs to edit the page for this to happen. Clearing the cache only when content changes does not solve it.

For a business website, that can mean a lost enquiry. An uptime check may still report that the site is online, so the failure can go unnoticed.

Having similar trouble? See our guide to fixing WordPress nonce errors caused by caching.

FlyingPress has an Auto-Refresh feature that clears and rebuilds cached pages at set intervals, but its documentation confirms it is switched off by default. We consider that a major reliability issue with the starting setup.

Yes, we can turn it on, exclude affected pages or create our own schedule. Those fixes do not make the default sensible. WP Rocket explicitly says its 10-hour default cache lifespan is chosen to avoid nonce problems. That is the kind of everyday WordPress behaviour we expect a paid caching plugin to account for.

In our view, leaving scheduled refresh off underestimates how business websites are used. Even a rarely updated brochure site can have enquiry forms, booking tools and other time-sensitive features.

Cache expiry compared

These are expiry or purge defaults once page caching is active, not identical scheduled refresh features. WP Super Cache’s 30 minutes is a recommendation. Breeze’s 24 hours and LiteSpeed’s 7 days can outlast nonces in cached HTML, so shorten the interval, exclude affected pages or use supported nonce handling. LiteSpeed supports ESI nonce fragments where configured.

Other reasons we moved away

Too many optimisations enabled. Our starting configurations needed more adjustment than we wanted. Changes to CSS and JavaScript can affect layouts and interactive features. We prefer to enable page caching first, then test further optimisations one at a time.

The cost did not add up. The licence was only part of the expense. Finding broken features, adjusting exclusions and checking sites again takes time. FlyingPress did not save us enough work to justify the total cost.

Support fell short. We raised issues but did not feel our concerns were properly acknowledged. We needed clear explanations and workable fixes. The support experience did not give us enough confidence to continue.

Updates did not solve our issues. FlyingPress has an active changelog, so the problem was not a complete lack of updates. During our use, the changes did not improve the parts that caused us difficulty enough to change our experience.

Limited WP-CLI support. FlyingPress documents commands for preloading, purging and licence activation. However, the command set did not cover enough of what we wanted to automate across the sites we maintain.

Our FlyingPress alternatives

For sites hosted on RunCloud, we generally returned to its built-in caching. For other sites, WP Super Cache is our usual alternative. The choice depends on the hosting and the website’s needs.

WP Super Cache is a free plugin that generates static HTML pages. It gives us page caching without a large bundle of CSS and JavaScript optimisations. We can handle that performance work separately and test each change.

Neither option removes the need to configure cache expiry, exclusions and purging. What we want is a straightforward setup with predictable behaviour and less ongoing troubleshooting.

FlyingPress may suit other teams. For us, reliability, sensible defaults and manageable costs mattered more. A fast website should still work when a customer returns tomorrow.