Swift Performance AI Benchmarks vs the Competition

Caching plugins are critical for enhancing the speed and performance of a WordPress website. They work by storing a static version of your site and presenting this to your users, which significantly reduces server lag. This ultimately leads to faster load times, providing an enhanced user experience. Today, we are focusing on the new player in town: Swift Performance AI, also known as Swift Performance 3. For those familiar with Swift’s previous caching plugin, Swift Performance 2, I recommend Swift’s Blog Post that explains the differences between these two plugins.

We aim to answer these critical questions: How fast is Swift Performance AI? Is Swift Performance AI better than Swift Performance 2? How does Swift Performance AI compare with WP Rocket?

To provide accurate answers, I’ve run an in-depth series of benchmarks and deployed each plugin to an identical version of a real WordPress website.

Testing methodology

I created multiple identical copies of my website, each deployed onto its private server. All instances used their databases, housed all of their content, used no CDNs like Cloudflare, and operated on the same versions of PHP, Nginx, Ubuntu Server, WordPress, etc. The only difference was the caching plugin installed. I used Google’s PageSpeed Insights tool and GT Metrix for benchmarking. To ensure the caches were functioning, I manually loaded each website and used the networking tab on my browser before beginning the tests.

Here are the detailed environment specifications and versions of each caching plugin used:

Environment details & versions

ComponentVersion
Operating systemUbuntu 22.04.2 LTS (GNU/Linux 5.15.0-71-generic x86_64)
CPU cores6
RAM12gb
Stoage256gb SSD
Web servernginx/1.18.0
PHP version8.2.6
PHP memory limit256M
Database hostAWS
Database typemysqli
Database server version8.0.31
Database client versionmysqlnd 8.2.6
WordPress Version6.2.2
Redis version2.4.1
Swift Performance 22.3.6.12
Swift Performance AI0.4.14
WP Rocket3.13.3
A table of the version of all components used during testing

The theme on the website at the time of testing was Divi 4.21.0. Under the Divi settings, the following performance options were enabled for all instances (Divi > Theme Options > Performance):

  • Dynamic Module Framework: Enable this to allow the Divi Framework to only load the modules that are used on the page, and process the logic for the features in use.
  • Dynamic CSS: Dynamic CSS greatly reduces CSS file size by dynamically generating only the assets necessary for the features and modules you use. This eliminates all file bloat and greatly improves load times.
  • Dynamic Icons: The Divi icon font is broken up into various subsets. These subsets are loaded only when needed based on the modules and features used on each page. If you need access to the entire icon font on all pages (for example, if you are using our icon font in your child theme), then you can disable this option and load the entire icon font library on all pages.
  • Dynamic JavaScript Libraries: Only load external JavaScript libraries when they are needed by specific Divi modules on the page. This removes unused JavaScript from the main scripts bundle and improves load times.

Some final notes to be aware of with regards to my website: This isn’t a typical everyday website as I have done some optimisations that non-developers may not do to their websites. So please be aware of the following:

  • All of my images are sized appropriately, uploaded as ‘.webp’ and compressed via tinypng.com before being uploaded to my site.
  • All fonts in use are hosted on my website directly, eliminating the need for Google fonts (or any other 3rd party provider) to be loaded.
  • Google reCaptcha v3 is enabled via the Contact Form 7 plugin, which often has a large impact on load times. I normally disable this for all pages except my contact page, but I enabled it for these tests on all instances to help make the tests feel more “real”.

Cache plugin settings

  • Swift Performance 2 (unoptimised): After installing the plugin and activating it with my licence key, I allowed it to build the cache. No further configurations were made.
  • Swift Performance 2 (optimised): I employed my configuration of choice. This particular configuration has been fine-tuned over two years of exclusive use with the Divi theme. It includes minifying, merging, and enqueuing scripts and styles (except jQuery and Divi’s core JS files & CSS cache files) and utilises lazy loading. Apart from these features, the setup is rather standard. Additionally, I ran Swift’s image optimiser tool to try to reduce image sizes.
  • Swift Performance AI: I only made a couple of changes to the default setup – I enabled GZIP in the settings and added the Nginx rewrite headers as advised. Other than that, I left the rest of the settings untouched. This configuration is nearly out-of-the-box and took just a fraction of the time I spent perfecting my settings for Swift Performance 2.
  • WP Rocket (unoptimised): Similar to Swift Performance 2’s unoptimised setup, I merely installed the plugin and let it build the cache. No further configurations were made.
  • WP Rocket (optimised): My goal here was to replicate my optimised Swift Performance 2 settings tailored for the Divi theme. The setup involved minifying, merging, and asynchronously loading scripts and styles (excluding jQuery and Divi’s core JS files & CSS cache files). I also ran WP Rocket’s image optimisation tool, Imagify.

Benchmark results (full data)

Interestingly, the results from both Google PageSpeed tests reveal an unexpected pattern: the ‘No Cache’ instance surprisingly outperformed the ‘Swift 2 (unoptimised)’ instance. Initially, this outcome was quite startling, as one would typically expect a caching plugin, even an unoptimised one, to improve performance compared to having no cache at all.

However, this data underscores a critical distinction between Swift Performance 2 and its successor, Swift Performance AI. It appears that Swift 2 is highly dependent on the user’s ability to optimise its configuration, making it less user-friendly for non-developers or those less familiar with the intricacies of the WordPress platform. In contrast, Swift AI seems to offer a more hands-off approach, potentially delivering better results right out of the box.

InstanceScoreFirst Content PaintLargest Content PainTotal Blocking TimeCumulative Layout ShiftSpeed Index
Swift AI851.37 s4.03 s143 ms0.032.13 s
Swift 2 (optimised)791.67 s7.23 s146 ms0.101.77 s
WP Rocket (optimised)431.836.00 s1,750 ms0.045.83 s
No Cache333.63 s10.23 s1,660 ms0.109.03 s
WP Rocket (unoptimised)314.40 s12.90 s1,217 ms0.109.43 s
Swift 2 (unoptimised)236.73 s11.90 s2,073 ms0.217.90 s
The final mobile results from Google Pagespeed. These figures are the rounded averages derived from 3 runs.
InstanceScoreFirst Content PaintLargest Content PainTotal Blocking TimeCumulative Layout ShiftSpeed Index
Swift AI990.43 s0.93 s0 ms0.020.77 s
Swift 2 (optimised)980.50 s1.00 s13 ms0.000.67 s
WP Rocket (optimised)910.50 s1.47 s157 ms0.021.17 s
WP Rocket (unoptimised)691.23 s2.67 s80 ms0.162.23 s
No Cache651.03 s2.53 s200 ms0.162.57 s
Swift 2 (unoptimised)631.90 s2.80 s180 ms0.172.07 s
The final desktop results from Google Pagespeed. These figures are the rounded averages derived from 3 runs.
InstanceGradePerformanceStructureFirst Content PaintLargest Content PainTotal Blocking TimeCumulative Layout ShiftSpeed IndexTime to Interact
Swift 2 (optimised)A100%94%319 ms580 ms0 ms0.005.11 ms526ms
Swift AIA99%98%183 ms314 ms0 ms0.07309 ms183 ms
WP Rocket (optimised)A93%96%194 ms359 ms202 ms0.02349 ms1,133 ms
WP Rocket (unoptimised)A91%92%278 ms727 ms172 ms0.15611 ms1,400 ms
Swift 2 (unoptimised)A90%91%425 ms856 ms180 ms0.15733 ms1,466 ms
No CacheB76%92%1,533 ms1,833 ms174 ms0.101,733 ms2,533 ms
The final results from GT Metrix. These figures are the rounded averages derived from 3 runs.

Conclusion

The results of the benchmark tests provide some valuable insights into the performance of these caching plugins. While Swift Performance AI shows excellent performance with minimal configuration, Swift Performance 2, when optimised, proves to be a strong competitor.

So, which plugin should you choose for your WordPress site? For those who prefer a ‘set it and forget it’ approach, Swift Performance AI is a fantastic choice. It requires almost no configuration and performs impressively right out of the box. However, if you prefer to have a more hands-on approach and have the technical expertise to tweak settings to your preference, Swift Performance 2 still holds its ground.

As for me, I am going to give Swift Performance AI a test run on my website, to see how it holds up over time. Being a long-time user of Swift Performance 2, it’s going to be an interesting experience. Nevertheless, I am not ready to let go of my old swift-performance.zip just yet.

If you’ve enjoyed this post, why not check out some of my others?

FAQ

Is Swift AI faster than Swift Performance 2?

In my testing, Swift AI scores higher on both Mobile & Desktop using Google Pagespeed. However, while it does load exceptionally fast, I noticed Swift AI can cause content to ‘jump around’ during the loading process on some sites, where as Swift Performance 2 had no such issue. It’s worth testing whether this affects your site, and you may want to tweak some settings to help potentially resolve this problem. Read more to see the full benchmark results.

Is Swift AI faster than WP Rocket?

In my testing, Swift AI scores higher on both Mobile & Desktop using Google Pagespeed when compared against WP Rocket with & without Imagify. I compared Swift AI against WP Rocket in its out-of-the-box configuration, and with some optimisation done via script & style merging. Read more to see the full benchmark results.

How fast is Swift AI?

Swift AI took an uncached website from 33 & 65 (Desktop & Mobile scores on Google Pagespeed), to 85 & 99 with no configuration. This makes it a great choice for users who want a ‘set it and forget it’ experience with their cache. However, we did find that it could cause content to ‘jump around’ during the loading process. So please test if this happens on your site, and consider turning the optimisation sliders down to help resolve the problem.