Fast WordPress pages, built before anyone asks
Staatic builds your WordPress pages once, when you publish. On Staatic Cloud, visitors get the finished file from a nearby CloudFront location, with no PHP or database to wait for.
Staatic’s slowest request beat WordPress’s fastest
We asked for four pages of staatic.com 51 times each, from our WordPress (no page cache) and from Staatic. Staatic’s slowest answer took 178 ms. WordPress never answered in under 206 ms.
- WordPress, no page cache
- Staatic
- Median
/
/pricing/
/security/
/documentation/setup/
Staatic cuts the server wait. On a phone, your theme sets the rest.
We loaded our homepage on a simulated mid-range phone. Same page, about 223 KB in 22 requests either way. The part Staatic changes is the server wait: in our first-byte test the homepage took 47 ms from Staatic and 249 ms from WordPress.
In this run the largest element appeared 0.3 seconds sooner from Staatic: after 2.53 seconds, against 2.83 from WordPress. The gap is smaller than at the first byte because images and fonts weigh the same either way.
Lighthouse 12.8.2, default mobile throttling, 29 October 2026. Test your own pages: your theme sets these numbers.
A good page cache is fast too. The difference is the miss.
For a popular page already cached at the edge, a well-run host is fast, as Cloudflare’s tests show, and so is Staatic. The difference is every request the cache doesn’t hold. A cached WordPress builds that page with PHP. Staatic fetches the finished file from storage: not always faster, but no WordPress code runs.
A popular page, already cached
Staatic
Served without PHP: File from a CloudFront location
Other setups
- WordPress, no page cache
- PHP runs, or the page fails: Built by PHP every time
- With a page cache on the server
- Works, with a catch: Cached copy from your one server
- Host with an edge cache
- Served without PHP: Cached copy from an edge location
A post from two years ago
Staatic
Served without PHP: File from CloudFront or storage. No PHP.
Other setups
Right after you publish or purge
Staatic
Served without PHP: Finished before going live. A first request comes from storage, not PHP.
Other setups
- WordPress, no page cache
- PHP runs, or the page fails: Built by PHP
- With a page cache on the server
- PHP runs, or the page fails: “Slower for a period of time” until pages are cached again. WP Engine
- Host with an edge cache
- PHP runs, or the page fails: Every page fetched from your server again as it is requested
Bots and odd URLs, many at once
Staatic
Served without PHP: Misses reach storage, not WordPress
Other setups
- WordPress, no page cache
- PHP runs, or the page fails: All reach PHP and the database
- With a page cache on the server
- PHP runs, or the page fails: Misses reach PHP
- Host with an edge cache
- PHP runs, or the page fails: Misses reach PHP
WordPress or its database is down
Staatic
Served without PHP: Every published page
Other setups
- WordPress, no page cache
- PHP runs, or the page fails: Site down
- With a page cache on the server
- PHP runs, or the page fails: Site down once the cache runs out
- Host with an edge cache
- Works, with a catch: Cached pages until they expire. Always Online steps in only when the server can’t be reached.
Logged in, cart or checkout
Staatic
PHP runs, or the page fails: Runs elsewhere, such as a shop on a subdomain or Snipcart. See what works on static
Other setups
- WordPress, no page cache
- PHP runs, or the page fails: Built by PHP
- With a page cache on the server
- PHP runs, or the page fails: Skips the cache
- Host with an edge cache
- PHP runs, or the page fails: Skips the cache
From each host’s documentation, not our measurements. Defaults vary by plan.
Fast on an ordinary day. Still up on a bad one.
Visitors get the files you published, not pages from WordPress, so those pages keep loading whatever happens to WordPress afterwards.
On a WordPress site without a separate cache, these two lines are the same line. A scheduled publication that runs while WordPress is broken publishes the broken state.
The public site also keeps serving while you change the PHP version, restore a backup or import a site, and while WordPress is paused after 15 idle minutes without the always-on add-on. Visitors get the version you last published until you publish again. Only a path you forward to WordPress with origin rules depends on it.
Not a backup copy of popular pages
Cache features sold as “always online” serve only what they kept, and only when your server can’t be reached. Cloudflare’s Always Online doesn’t step in when WordPress answers with an error. On Staatic the published files are the site, a two-year-old post included.
What the public site does depend on
Amazon Web Services (CloudFront and S3), your domain’s DNS, and Staatic’s form and search services if you use them. A forwarded path depends on where it goes. Your WordPress, its plugins and its database are not on the list.
Check it from where you are
Response headers say where a page came from. Here are both answers for our homepage, explained.
HTTP/2 200x-powered-by: PHPPHP ran to build this answer.cf-cache-status: DYNAMICNot cached by Cloudflare: WordPress built it for this request.server: cloudflare
HTTP/2 200server: staaticA finished file. No PHP ran.x-cache: Hit from cloudfrontCloudFront already had the page and sent it straight away.x-amz-cf-pop: AMS58-P6The CloudFront location that answered: Amsterdam.
Shortened to the lines that matter, PHP version left out.
In your browser
Open your browser’s developer tools, choose Network and reload. Timing shows how long the server took before it answered.
/
WordPress, no page cache
status 200
document
waiting for the first byte: 249 ms
/
Published by Staatic
status 200
document
waiting for the first byte: 47 ms
Run it yourself
Paste these into a terminal: the first shows the headers, the second times one request. Your CloudFront location and times will differ from ours.
$ curl -sI --compressed \ https://staatic.com/ HTTP/2 200 server: staatic x-cache: Hit from cloudfront x-amz-cf-pop: AMS58-P6 (other headers left out) $ curl -so /dev/null --compressed \ -w '%{time_starttransfer}\n' \ https://staatic.com/ 0.046959 # one run; the median of 51 was 0.047
What Staatic doesn’t change
- A heavy theme
- Large images, fonts and scripts take as long to load from a static file as from WordPress. Staatic removes the wait for the page, not the weight of it.
- Changes go live when you publish
- Saving in WordPress doesn’t change the public site; publishing does. Quick and scheduled publications (Staatic Premium and Staatic Cloud) keep the delay short.
Staatic Cloud serves your site from 250+ locations (400+ on Enterprise). Our measurements were answered by one of them, in Amsterdam; yours will use the nearest. Self-hosting the plugin? Then speed depends on where you publish.
Publish once.
Every page is ready.
Try Staatic Cloud on your own site for 14 days and run the same commands against it. The same finished pages also leave attackers next to nothing to attack.
- No payment details needed
- The trial ends automatically
- You keep editing in WordPress
How we measured
Show how we measured Hide how we measured
Our own measurements were made on 29 October 2026 from a location in Amsterdam, between 21:37 and 21:45 CET: curl for the first byte, then Lighthouse 12.8.2, 5 runs per form factor. We woke WordPress first and threw away one warm-up request per page on each side. Then came 51 rounds: each asked for every page once from WordPress and once from Staatic, in a shuffled order, each request on a fresh connection, so both sides met the same moments of the network. Every figure is the median of all 51 requests; no round was picked. Every Staatic request was a CloudFront cache hit. Availability statements follow the Staatic Cloud documentation.
WordPress: Answers carried cf-cache-status: DYNAMIC, and the homepage came back at two different sizes: 61,427 and 61,905 bytes. Each request ran PHP and the database again. Staatic: Answers carried x-cache: Hit from cloudfront and the same 55,920 bytes every time, over HTTP/2.
Lab tests with a simulated phone; Google ranks on real-visitor data. Largest contentful paint per mobile run: 2.42 to 2.67 s for Staatic, 2.63 to 3.15 s for WordPress. Mobile scores were 79, 93, 93, 94, 95 for Staatic and 67, 76, 78, 88, 93 for WordPress. On desktop both are fast: Staatic scored 100 with the largest element at 0.59 seconds, WordPress 99 at 0.84.