Breeze Cache Plugin 2.6.4 Tested Under Real WordPress Traffic

Every WordPress site eventually has a moment when more visitors arrive than it was built to handle. Usually, this happens during a sales event (like the up-coming Black Friday and Cyber Monday) when the server suddenly has to answer dozens of requests at once.

What happens next depends entirely on what is running under the hood. We wanted to see exactly what that moment looks like with Breeze 2.6.4, Cloudways’ free WordPress caching plugin, and what it looks like without it. So instead of guessing, we tested it directly. This Breeze cache plugin benchmark walks through the real WordPress load testing results and explains what each one means for your own website.

The Result, Up Front

Without a caching plugin, our test website took 15 to 20 seconds to respond on average under a realistic traffic rush, and the server could handle only about 2 requests per second. With Breeze 2.6.4 active, the same website on the same server handled between 9 and 48 times more WordPress requests per second, depending on the testing tool, and brought average response times down to under 2 seconds. Not a single request failed across 36 test runs.

What we measured	Without Breeze	With Breeze
Requests handled per second	About 2	18 to 92
Average page response under load	15 to 20 seconds	0.35 to 1.74 seconds
Slowest response under load	22 to 30 seconds	2.7 to 6.4 seconds
Failed requests across all runs	0	0

Three independent testing tools reached the same conclusion. Oha requests only the page’s HTML, while k6 and JMeter load the full page with its assets, so each one stresses the site differently. Even so, all three showed the same pattern. Breeze raised throughput by 9.2x to 47.9x and cut average response time by 89% to 98%, with no failed requests in any tool.

How We Tested This

For this WordPress cache plugin performance test, we took a live WordPress website and simulated 32 visitors loading the homepage at the same moment, continuously, for a full minute. That is a reasonable stand-in for a real traffic spike, large enough to show whether a website holds up or starts to buckle.

To make sure we were not reporting a fluke, we used three independently built testing tools, Oha, k6 and JMeter, and ran each one three times against every setup. That gives nine runs per condition without Varnish and nine more with it, 36 runs in total across both conditions. Multiple runs let us spot noise and rely only on results that held up.

The comparison is simple. We tested the same website with no caching plugin, then again with Breeze 2.6.4 active.

Scenario	Breeze	Varnish	Runs per tool
Baseline	Off	Off	3
Breeze only	On	Off	3
Varnish only	Off	On	3
Varnish with Breeze	On	On	3

Cloudways servers can run Varnish, a server-level cache, in the background. We tested with and without it so you can see what Breeze adds by itself and what it adds on top of Varnish.

Oha requests only the HTML document of the page, so its response sizes are around 50 KiB. k6 and JMeter load the full page with its assets, which is why their response sizes are 330 to 370 KiB and their requests per second are lower. The three tools measure related but different things.

What “WordPress Requests Per Second” Means, and What We Found

When a testing tool reports requests per second, it is measuring how many separate visitors the server can serve within one second without falling behind. This is the number that decides whether your website survives a traffic spike and continues to perform as the server needs to process an increasing number of user requests.

Without Breeze, our test website could serve only about 2 requests per second in every tool. At that rate, a handful of visitors arriving together is enough to make everyone else wait in a queue. With Breeze switched on, the same server handled between 18 and 92 requests per second.

Testing tool	Without Breeze	With Breeze	Gain
Oha	1.93 / sec	92.23 / sec	47.9x
k6	1.69 / sec	17.91 / sec	10.6x
JMeter	1.97 / sec	18.10 / sec	9.2x

The same gap shows up in the total number of requests each setup served during the 60-second runs.

Testing tool	Served without Breeze	Served with Breeze
Oha	84	5,503
k6	121	1,109
JMeter	134	1,113

The k6 and JMeter results with Breeze settle at about 18 requests per second. Multiply that by the 330 to 350 KiB these tools download per page and you get roughly 6 MB per second. Oha requests only the small HTML document, and shows the larger 48x gain.

This is important for most WordPress websites because they usually do not get visitors at a steady pace. They get spikes, where visitors arrive in a bunch with variable gaps in between spikes. Requests per second tells you whether your website can absorb these spikes or whether it buckles the moment a handful of people show up together.

What “Average Response Time” Means, and What We Found

This one is more intuitive because it is really page load time. It measures how long a visitor waits, staring at a blank or half-loaded page, before the website’s server finishes responding to their request.

Without Breeze, the average response during our tests stretched to between 15 and 20 seconds. With Breeze active, the same test produced average responses between about a third of a second and under 2 seconds, depending on the tool.

Testing tool	Without Breeze	With Breeze	Faster by
Oha	19.82 sec	0.35 sec	98%
k6	17.97 sec	1.74 sec	90%
JMeter	15.33 sec	1.73 sec	89%

Most websites feel fast most of the year because you know and have budgeted for the average number of visitors arriving one or two at a time. The real test is what happens when several visitors arrive together. A page that takes close to 20 seconds under pressure is a page most visitors will never see, because they leave first.

What “Slowest Response” Means, and What We Found

An average hides the worst experiences. A few very slow requests can sit behind a healthy-looking number, so we also tracked the slowest single response in each run. In real world terms, this would be the visitor staring at a partially loaded page while the server struggles to send all the assets to the browser.

Without Breeze, the slowest visitor waited between 22 and 30 seconds on average. With Breeze, the worst case dropped to between 2.7 and 6.4 seconds.

Testing tool	Without Breeze	With Breeze	Lower by
Oha	30.35 sec	2.67 sec	91%
k6	27.70 sec	6.39 sec	77%
JMeter	22.26 sec	5.22 sec	77%

When traffic spikes, the people who arrive last often have the worst experience, and they may be the ones about to check out or sign up. Keeping the slowest response in the low seconds means the whole crowd gets a usable page, including the people at the back of the queue.

What “Zero Failures” Means

Across all 36 test runs, we tracked how many requests came back as errors or timeouts instead of a successful page load. With Breeze running, that number was zero. Not one visitor saw an error page or a stalled request, even at the peak of each test.

For ecommerce and high-traffic websites, this is an important metric because visitors may tolerate a slow website but never a slow website. In addition, a website that throws errors under load turns them away at the moment interest is highest. It is important to note that the speed gains we measured did not come at the cost of dropped requests.

A good result is only useful if it repeats. In k6 and JMeter, Breeze’s throughput stayed within about 4% from one run to the next (for example 17.48 to 18.21 requests per second in k6). In Oha, throughput ranged from 81 to 98 requests per second across the three runs, a wider spread but still far above the roughly 2 requests per second of the uncached site. Without Breeze, Oha’s average response time swung between 17 and 23 seconds from run to run, so the uncached website was also the less predictable one.

Why Breeze Caching Speeds Up WordPress Under Heavy Traffic

Every time someone loads a WordPress page without caching, the server rebuilds that page from scratch. It pulls content from the database, runs the theme’s code and assembles everything into the page the browser displays. That is fine when a few people visit across a day. It falls apart quickly when thirty people arrive in the same minute, because the server repeats the same expensive work over and over while new visitors keep piling up behind it.

Caching removes that repetition. The first time a page is built, Breeze saves a finished, ready-to-serve copy. Every visitor after that receives the saved copy instead of making the server start from zero. This mechanism is the reason why the gap under real load is so large and why caching is the most direct way to improve WordPress speed under traffic.

Breeze Reduces HTML Document Size by About 17%

Breeze also optimizes the files it serves. In Oha, which downloads only the page’s HTML document, the document averaged 42.2 KiB with Breeze versus 50.6 KiB without, about 17% smaller. This figure covers the HTML document only. The k6 and JMeter tools load the full page with images and scripts, and in those tests total page size stayed within about 1% of the baseline, so we make no claim about overall page weight.

Breeze on Top of Varnish Adds Up to 16% More Throughput

Varnish is a server-level cache that Cloudways can run in front of your WordPress site. It works at the server level, well below your website layer. Now, since the Cloudways Breeze plugin works inside WordPress, we repeated the full test with Varnish switched on to see whether Breeze still adds value on top of it.

Testing tool	Varnish only	Varnish with Breeze	Change
Oha	117.96 / sec	136.50 / sec	+16%
k6	17.62 / sec	18.11 / sec	+3%
JMeter	18.16 / sec	17.97 / sec	About equal

Oha gives the clearest read on server capacity, and there Breeze added a further 16% on top of Varnish, along with a slightly faster average response (0.24 seconds versus 0.27). In k6 and JMeter, the two setups tie at around 18 requests per second. This shows Breeze adds no overhead when it runs alongside Varnish.

If your Cloudways server already runs Varnish, Breeze is not redundant. It handles WordPress-level optimization that a server cache does not, and in our test it added capacity without costing extra in terms of server resources.

GTmetrix Results

Load tests show what a crowd experiences. 

GTmetrix shows what a single visitor experiences when one page loads in a real browser. We ran our test site using Chrome 154 and Lighthouse 12.6.1 on October 28, 2026.

With Breeze active, the website scored 96% for Performance and 97% for Structure. This translates to a GTmetrix overall score of A. Every Core Web Vital landed well inside the range Google considers good.

Metric	With Breeze	Google’s “good” range
Performance score	96%	90% and above
Structure score	97%	90% and above
Largest Contentful Paint	1.1 sec	2.5 sec or less
Total Blocking Time	0 ms	200 ms or less
Cumulative Layout Shift	0	0.1 or less

Performance and Structure are GTmetrix’s two headline scores. Performance reflects how quickly the page loads and becomes usable. Structure reflects how well the page is built to load fast, such as how its files are delivered and sized.

Largest Contentful Paint, 1.1 seconds, measures how long the biggest visible element, usually a hero image or main headline, takes to appear. It is the number closest to what a visitor would describe as “how fast did this feel.”

Total Blocking Time, 0 milliseconds, measures whether the page freezes while it finishes loading, the kind of delay you notice when you tap something and nothing happens. Zero means the page stayed responsive throughout.

Cumulative Layout Shift, 0, measures whether elements jump around as the page loads, like a button that moves just as you reach for it. Zero means nothing moved unexpectedly.

Largest Contentful Paint and Cumulative Layout Shift are two of Google’s Core Web Vitals, which Google uses as signals when ranking pages in search. A website that scores well here is faster for visitors and better positioned in search results.

How Breeze features map to each GTmetrix metric

Page caching shortens the time the server takes to send the page, which is where Time to First Byte improves. File optimization, such as minification and deferred loading of scripts, reduces paint and blocking time. Lazy loading of images helps the main content appear sooner.

 

PageSpeed Insights, a Second Opinion

We also ran the website through Google’s PageSpeed Insights, captured on October 28, 2026. On the desktop test, it agrees closely with GTmetrix.

Device	Score	Largest Contentful Paint	Total Blocking Time	Cumulative Layout Shift
Desktop	97 / 100	1.0 sec	0 ms	0
Mobile	64 / 100	7.0 sec	40 ms	0

The mobile result deserves context. PageSpeed’s mobile test emulates a mid-range phone on a throttled slow 4G connection, which is a deliberately harsh scenario. How quickly the main content appears under those conditions depends heavily on factors such as image weight and theme code, which a caching plugin does not control. Breeze’s role is getting the page from the server to the visitor quickly, and blocking time and layout shift both held up on mobile. Optimizing images and trimming heavy theme assets would add to what Breeze does.

What This Means for Your Website

What happens right now if 20 or 30 people land on the same page within the same minute? 

For a large share of WordPress websites, the honest answer is that response times climb sharply and some visitors start seeing delays.

That is the scenario this Breeze WordPress caching plugin benchmark tested. Under heavy load, Breeze took our test website from response times of 15 to 20 seconds down to under 2 seconds, and from about 2 requests per second to as many as 92, without dropping a single request. Under ordinary conditions, the same website scored in Google’s good range on the independent tools the industry uses to judge speed.

In practical terms, that means more room on the hosting plan you already pay for, pages that stay usable during a promotion or a viral moment, and a stronger base for the Core Web Vitals that influence search visibility.

Breeze is free and built into Cloudways hosting, so there is nothing extra to buy. To learn how to configure it for your own website, see the Breeze documentation.

Test Notes and Limitations

These results come from one website, one server configuration and one page, the homepage. Your results will vary with your theme, your plugins, your hosting plan and your traffic patterns. The k6 and JMeter results were likely capped by the bandwidth of the machine generating the load, so their gains are probably conservative. GTmetrix and PageSpeed scores also vary slightly between runs and test locations, which is why we list the conditions we used. We encourage you to run the same tools on your own website and compare.

FAQ

Do I need to install Breeze myself, or is it already on my site?

If you host on Cloudways, Breeze typically comes pre-installed and activated with default settings on new Optimized WordPress applications. You can also install it from the official WordPress plugin repository under Plugins > Add New Plugin in your WordPress admin.

Is Breeze really free?

Yes. Breeze is completely free, with no premium tier, and is included at no extra cost with Cloudways hosting.

Does Breeze work with WooCommerce and other plugins?

Yes. Breeze is built to work with WooCommerce and WordPress Multisite, and it is tested for compatibility with popular plugins from the WordPress.org repository.

My Cloudways server already runs Varnish. Do I still need Breeze?

Varnish caches pages at the server level whichever plugin is active. Breeze adds WordPress-level optimizations on top, such as minification and browser caching. In our Oha test, Breeze added a further 16% in requests per second on top of Varnish.

Why do the numbers differ between testing tools?

Each tool measures the same site in a different way. Oha requests only the HTML document, while k6 and JMeter load the full page with its assets. That makes Oha’s requests lighter and its results higher. What matters is that all three tools show the same direction and a large gap with Breeze enabled.

Why is Oha’s gain so much larger than k6 and JMeter?

Oha’s small requests let the server run closer to its true capacity. The k6 and JMeter results appear to have been limited by the bandwidth of the load generator, so their gains are likely a floor.

Will Breeze slow down my WordPress admin or editing experience?

No. Caching applies to how pages are served to visitors, so editing and publishing in the dashboard are unaffected.

Appendix, Per-Run Results

These tables show every run behind the averages in the report. Times are in seconds and response sizes are in KiB per request. Every run recorded zero failures. R1, R2 and R3 are the first, second and third runs.

Oha without Varnish

Metric	Without R1	Without R2	Without R3	With Breeze R1	With Breeze R2	With Breeze R3
Total requests (60s)	87	68	96	5,857	4,838	5,813
Avg response time	19.03	23.14	17.29	0.33	0.40	0.33
Fastest response	2.71	15.86	13.80	0.22	0.22	0.22
Slowest response	31.19	37.29	22.56	1.83	4.57	1.60
Requests per second	1.98	1.67	2.13	98.13	81.16	97.39
Response size	50.60	50.61	50.61	42.17	42.17	42.17

Oha with Varnish

Metric	Varnish R1	Varnish R2	Varnish R3	Varnish + Breeze R1	Varnish + Breeze R2	Varnish + Breeze R3
Total requests (60s)	6,884	7,132	7,122	7,736	8,366	8,374
Avg response time	0.28	0.27	0.27	0.25	0.23	0.23
Fastest response	0.19	0.19	0.19	0.19	0.19	0.19
Slowest response	2.94	1.78	2.37	3.72	1.29	1.07
Requests per second	115.26	119.39	119.23	129.46	139.96	140.08
Response size	50.61	50.61	50.61	42.61	42.61	42.61

k6 without Varnish

Metric	Without R1	Without R2	Without R3	With Breeze R1	With Breeze R2	With Breeze R3
Total requests (60s)	139	119	105	1,080	1,131	1,116
Avg response time	15.23	18.08	20.60	1.78	1.71	1.73
Fastest response	3.62	2.39	2.55	0.53	0.22	0.22
Slowest response	22.90	25.44	34.77	6.88	4.66	7.64
Requests per second	1.97	1.65	1.45	17.48	18.21	18.05
Response size	346.13	344.03	341.33	347.02	347.67	346.84

k6 with Varnish

Metric	Varnish R1	Varnish R2	Varnish R3	Varnish + Breeze R1	Varnish + Breeze R2	Varnish + Breeze R3
Total requests (60s)	1,082	1,129	1,092	1,122	1,132	1,123
Avg response time	1.78	1.70	1.76	1.71	1.71	1.73
Fastest response	0.37	0.40	0.23	0.42	0.21	0.42
Slowest response	9.64	4.13	9.17	4.62	3.94	4.15
Requests per second	16.95	18.28	17.63	18.21	18.19	17.94
Response size	347.42	347.44	347.90	347.84	347.54	347.42

JMeter without Varnish

Metric	Without R1	Without R2	Without R3	With Breeze R1	With Breeze R2	With Breeze R3
Total requests (60s)	135	137	131	1,088	1,124	1,128
Avg response time	15.50	15.07	15.42	1.77	1.71	1.71
Fastest response	3.62	4.09	3.41	0.22	0.23	0.23
Slowest response	23.21	21.91	21.67	6.01	5.26	4.39
Requests per second	1.94	2.01	1.97	17.70	18.33	18.28
Response size	326.70	326.70	326.69	330.30	330.30	330.30

JMeter with Varnish

Metric	Varnish R1	Varnish R2	Varnish R3	Varnish + Breeze R1	Varnish + Breeze R2	Varnish + Breeze R3
Total requests (60s)	1,129	1,106	1,128	1,065	1,133	1,127
Avg response time	1.71	1.74	1.71	1.81	1.71	1.71
Fastest response	0.20	0.20	0.20	0.21	0.20	0.20
Slowest response	4.68	4.97	5.38	7.27	5.01	9.64
Requests per second	18.32	17.87	18.29	17.22	18.40	18.30
Response size	330.68	330.68	330.68	330.68	330.68	330.68