Swift Performance AI vs WP Rocket: what happens when a real visitor arrives

Run a caching plugin comparison and you will usually get a table of PageSpeed scores. We ran one too, and the honest headline is that the scores were close. Swift Performance AI and WP Rocket both cached the page, both cut it down, and on the numbers a benchmark reports there was not much to separate them.

So we changed the question. Instead of asking what a testing tool sees, we asked what happens the moment a person arrives and moves the mouse. That is where the two plugins turned out to be doing genuinely different things — and it is the difference that shows up in your field data, not your screenshots.

We make Swift Performance, which is exactly why the method is written out in full below. Every number here is reproducible on your own page in an afternoon.

The page we built to break them

A light page makes every plugin look good, so we built the kind of page agencies actually ship:

• A full-bleed hero with a 2400 px background photograph
• Four Google Fonts — Playfair Display, Inter, Bebas Neue and Lora, multiple weights, enqueued the normal WordPress way
• Font Awesome 6 as an icon font, loaded from a CDN for six feature icons
• A YouTube embed
• 17 images totalling 2.9 MB, twelve of them in a gallery below the fold
• WooCommerce running in the background, with its cart and account blocks in the header, as on any real shop

Unoptimised it pulls 7.7 MB across 71 requests. That is a normal marketing page after two years of a marketing team.

One detail that matters more than it sounds: the fonts are enqueued through wp_enqueue_style, not dropped into the page as raw <link> tags. Neither plugin will touch a stylesheet you hand-code into post content, so a test built that way measures nothing at all.

How we measured

Each plugin was measured in two conditions, at the same wall-clock point after navigation starts, so the columns are directly comparable:

• Idle — nobody touches the page. This is what PageSpeed Insights and every automated test measures.
• Real visitor — the pointer starts drifting 250 ms after navigation begins, the way a person whose hand is already on the mouse behaves. Anything a plugin postponed “until interaction” comes due here.

We deliberately do not click or tap. A click freezes Largest Contentful Paint by specification and marks nearby layout shifts as expected, which would hide the exact effect we are trying to see.

• Site: WordPress 7.0.2, PHP 8.3.33, Apache, WooCommerce 11.0
• Plugins: Swift Performance AI 1.0.4 and WP Rocket 3.23.1.1, never active at the same time
• Browser: Chromium 151 at 1440 × 900, fresh context per run, 4× CPU throttling to approximate a mid-range device
• Per configuration: cache cleared, cache fully warmed, three runs, median reported. No run was manually discarded.
• WP Rocket: minify CSS and JS, defer JS, delay JS, LazyLoad for images and iframes, image dimensions, host fonts locally, preload, preload links
• Swift: every optimisation level at maximum, nothing else touched

The lab result: closer than we expected

Read that as a scorecard and WP Rocket looks excellent. Same payload, a third of the requests, a quarter of the JavaScript, a marginally faster first paint. Swift wins Largest Contentful Paint by about 100 ms and time to first byte by a hair. If we published only this table, the honest summary would be “very close, pick either” — and the scoring tool agrees.

What PageSpeed Insights says

We ran the same page through PageSpeed Insights with each plugin active, because that is the number most people will actually check. The verdict there is a draw:

100 against 98. Two points apart, both comfortably in the green, and if this article stopped here it would be a shrug. WP Rocket even wins First Contentful Paint outright, 0.3 s to 0.6 s. Swift takes Largest Contentful Paint, 0.6 s to 1.0 s, and layout shift, 0 to 0.073.

That is the honest state of play in a lab. Now the part a lab cannot see.

Then somebody moved the mouse

A large part of WP Rocket’s lab advantage came from postponement rather than elimination. The 87 KB of JavaScript in six requests holds only while nobody touches the page; one pointer movement and it becomes 241 KB in seventeen requests, arriving all at once, on the main thread, at the precise moment your visitor started interacting with the page. That is where the 63 ms long task comes from — and long tasks are what Interaction to Next Paint measures.

Swift’s figure moves from 247 KB to 255 KB. Nothing was being hidden from the test, so there was nothing to hand over.

One precision point, because it matters: our pointer movement is not itself an Interaction to Next Paint event. INP measures discrete interactions — clicks, taps, key presses. We use pointer movement here purely to trigger the scripts WP Rocket had held back, and to measure the work that becomes due the moment a visitor becomes active. That work then has to execute before or around the real interactions that follow.

It matters because the numbers Google uses are field data from real Chrome users, not lab runs — and real users arrive, move, and then click. A configuration that only looks light in the absence of a human is describing the report rather than the site.

Both defer something. What you defer is the whole argument

Here is the fair version, because Swift defers things too. After interaction both pages land at almost exactly the same weight: 1,366 KB against 1,365 KB. Identical.

The difference is the composition. Swift’s extra 149 KB is fonts — it painted with critical fonts and brought in the rest afterwards. WP Rocket’s extra 155 KB is JavaScript. A font arriving late costs bandwidth and swaps some glyphs. JavaScript arriving late costs parse and execution time on the main thread, which is the one resource the visitor is competing for while they try to click something.

Deferring is a legitimate technique — delaying JavaScript genuinely reduces initial main-thread work, and WP Rocket documents it as an LCP optimisation. The trade-off is that work removed from the initial load does not necessarily disappear. If it is triggered by the visitor’s first interaction, the cost can move from loading performance into interaction performance.

The part where we did not configure anything

Halfway through testing we wiped Swift’s cache completely. It came back serving a partially optimised page: WebP conversion working, but the responsive image sets and the automatic LCP preload missing.

The reason is that Swift schedules its deeper work by what is actually being visited. On a demo site with no visitors, there is nothing to prioritise. So we sent it one wave of genuine traffic and watched:

No settings were changed between those two columns. Nothing was queued by hand, no page was marked as important, no priority was assigned. The plugin worked out which page mattered because people went to it, and optimised that one first.

This is the practical difference in day-to-day use. WP Rocket’s settings are not hard, but they are decisions: which scripts to delay, which to exclude, whether to turn on Remove Unused CSS, what to safelist when a slider breaks. There is a large documentation library because there are a large number of choices, and every one of them is a chance to leave performance on the table without ever knowing it. Swift’s equivalent configuration was three sliders at maximum and no documentation open.

Images: an optimiser, not just a lazy loader

Swift converted 16 of the 17 images to WebP and generated responsive sizes, so the browser downloads an image scaled for the viewport rather than a 2400 px original squeezed down by CSS. The whole gallery costs 92 KB.

WP Rocket optimises how images are delivered — lazy loading, critical image detection, dimensions — and does it competently. What it does not do is compress or convert the original files, so a deferred 2.5 MB is still 2.5 MB, and it lands the moment somebody scrolls. Compression is a separate subscription to Imagify, from the same vendor. Budget for it, or use a plugin where it is included.

Both plugins spotted the hero as the LCP element without being told: WP Rocket applied fetchpriority="high" to it, and Swift did that and issued a <link rel="preload"> for it. Swift emitted 23 preload hints in total against WP Rocket’s one — that is not a score where more is automatically better, but Swift’s set covered the resources it had identified as critical to the initial render, and WP Rocket’s single hint was a stylesheet.

Fonts, video and the rest of the gap

Our page asks for four families and a complete icon set. Swift builds critical fonts: with CSS optimisation at maximum it works out which glyphs are needed above the fold and serves only those to paint the page. It shipped 294 KB of font data to first render against WP Rocket’s 442 KB. For an icon font this is the whole game, because a page using six Font Awesome glyphs has no business downloading several thousand.

WP Rocket’s Host fonts locally is a real feature and it does help; some comparisons wrongly claim it is missing. But self-hosting a font file does not make it smaller.

The video went the same way. Before any interaction the page made zero YouTube requests under Swift and one under WP Rocket, because Swift’s iframe optimiser swaps the embed for a lightweight placeholder and loads the player only when it is wanted — for any iframe, not only the formats it recognises.

Three more things Swift includes that WP Rocket does not, which did not fit our single-page test but change the shape of a real site:

• Fragment caching — cache a page that contains per-user pieces, instead of giving up on caching it. For logged-in areas and shops this is the difference between a cached site and an uncached one.
• On-site navigation — subsequent pages are fetched and swapped in rather than loaded from scratch, so the second click feels instant.
• Cloudflare integration — proxy caching becomes a checkbox rather than a page-rules project.

The cloud that does the thinking

Both plugins send work to their vendor’s cloud. What they send is the difference.

WP Rocket runs automated background analysis too — Remove Unused CSS, plus its Priority Elements work: critical image detection, font preloading and preconnect hints. Beyond those automatic features, though, JavaScript delay exclusions and CSS safelisting are still yours to configure whenever a compatibility problem shows up.

Swift’s API is doing considerably more. The optimisation daemon submits each page for a full optimize pass, and images go through their own conversion endpoints. That one pass is where the decisions in this article come from: which scripts can safely be deprioritised and which must run, which glyphs belong in the critical font for that specific page, which responsive sizes each image actually needs, which element is the LCP candidate worth preloading, and the critical CSS for that URL.

That is why the configuration is three sliders. The analysis that WP Rocket asks you to encode as exclusion rules is the thing Swift’s API is for. And it is why the deeper optimisations only appeared after we sent real traffic — the daemon submits the pages people are actually visiting, in that order.

The measured output of that single pass, on our page: inline CSS down from 59 KB to 10 KB, font data in the render path down from 442 KB to 294 KB, 15 responsive image candidates against 2, and 23 preload hints against 1.

Where WP Rocket is genuinely strong

• First paint and request count. It reached First Contentful Paint marginally sooner in the lab and served the page in 25 requests against 65. On a slow connection, fewer round trips is a real advantage.
• RocketCDN. A tuned CDN you enable with one click, on one subscription, with no separate account. We have no direct equivalent.
• Compatibility. The best record in the category. If you run something unusual, that track record is worth money.
• It is easy to start. Activate it and the page is cached. Nothing about our result changes that.

Price

The two entry tiers are within a dollar of each other. Where they part company is what the price covers: image optimisation is included with Swift and is a separate Imagify subscription with WP Rocket, and if you run more than a handful of sites, Swift Performance AI is part of the Must-Have Pack — every plugin we make, unlimited sites, one subscription.

Frequently asked questions

Is Swift Performance AI a good WP Rocket alternative?

On a page heavy enough to need a performance plugin, yes. The lab scores are close, but Swift includes image optimisation, critical fonts, automatic LCP preloading, fragment caching and an iframe optimiser without extra subscriptions, and it does not buy its score by postponing JavaScript until the visitor arrives.

Does Delay JavaScript Execution actually hurt my visitors?

It shifts cost rather than removing it. In our test it held back 154 KB of JavaScript across eleven requests until the first interaction, then delivered all of it at once with a 63 ms main-thread task attached. Your lab score improves; your visitor’s first interaction is what pays for it.

Which is faster, Swift Performance AI or WP Rocket?

In a lab test with nobody touching the page, they are nearly identical: PageSpeed Insights scored 100 for Swift Performance AI and 98 for WP Rocket on the same heavy page. The gap opens once a visitor becomes active. At that point WP Rocket delivered 241 KB of JavaScript against 87 KB while idle, and Swift’s figure moved only from 247 KB to 255 KB.

Does WP Rocket delay JavaScript until user interaction?

Yes. Delay JavaScript Execution holds scripts back until the visitor interacts with the page, which reduces initial main-thread work and improves lab scores. In our measurement it held back roughly 154 KB across eleven requests; that work then arrived together once the pointer moved, with a 63 ms main-thread task attached.

Can I run both plugins together?

No. They both write cache rules and rewrite the same assets. Ours refused to co-exist during testing, which is correct behaviour.

Will these numbers hold on my site?

The milliseconds will not — they belong to our server on the day. The ratios should, because they come from what each plugin does rather than how fast the host was. Run the two conditions described above on your own heaviest page and see.

Reproduce this test

Nothing here needs to be taken on trust. Build a page with a large hero image, several webfonts, an icon font, a video embed and a gallery nobody compressed. Then, for each plugin in turn:

1. Activate one plugin only, clear its cache, and warm it fully before measuring anything.
2. Confirm from the served HTML that its optimisations are live — delayed-script markers, lazy-loading attributes, WebP references, inline CSS size. A settings screen is not evidence.
3. Load the page in a fresh browser context with 4× CPU throttling and touch nothing. Record payload, requests, script bytes, FCP, LCP, CLS and long tasks.
4. Repeat, but start moving the pointer 250 ms after navigation begins, at a human pace of roughly one movement every 500 ms. Do not click — a click freezes LCP by specification. Read the same metrics at the same point after navigation start.
5. Compare the two columns for each plugin. The gap between them is the work the lab never sees.

If your synthetic visitor moves the pointer far faster than a person would, you will force the browser into frames it would otherwise skip and measure your own instrumentation instead of the plugin. Pace it like a human.

The verdict

If you only ever look at a benchmark, these two plugins are close, and WP Rocket has a genuine case: fewer requests, a hair faster to first paint, RocketCDN in the box, and the best compatibility record in the category. Those are not consolation prizes.

But a benchmark is not a visitor. When somebody actually arrived on our page, WP Rocket handed over 154 KB of JavaScript it had been holding back, in eleven extra requests, with a main-thread task attached — and ended up at exactly the same page weight as Swift Performance AI, which had simply done the work up front. One of those two profiles is what your field data will be built from.

Add the things Swift did without being asked — WebP conversion, responsive image sets, critical fonts, automatic LCP preloading, an iframe placeholder, and choosing which page to optimise first based on where people actually went — and the case is not really about a hundred milliseconds. It is that one plugin asks you to make the decisions and the other makes them, and the one making them was not the one that needed a human to look good.

Both come with a money-back period. Put your own heaviest page in front of each, measure it in both conditions, pace your synthetic visitor like a person, and let the numbers decide.

Tested 15–16 August 2026: WordPress 7.0.2, PHP 8.3.33, WooCommerce 11.0, Swift Performance AI 1.0.4 and WP Rocket 3.23.1.1, alternating rounds, cache cleared and fully warmed before each set, three runs per configuration, median reported, 4× CPU throttling. Both plugins’ optimisations were verified live in the served HTML before each round was accepted. Prices checked on both vendors’ pricing pages on the same dates.