WordPress and Caching Plugins.

WordPress and Caching Plugins. In this post I’l be talking about caching plugins, what their purpose is, how they work and the difference between different types of caching plugins.

What is Caching?

What is caching, and what does it do?

Some of you might be thinking “caching makes things quicker”. Well it can, and that’s generally it’s purpose, but it’s not like there’s some kind of accelerator pedal in your WordPress that you press by installing a caching plugin.

Caching is effectively the “remembering” or “recording” of generated information so that it can be recalled without the need for the generation part to take place again.

As it’s usually the generation part that takes time, eleminating this often results in reduced time for things like page load (in the context of a website).

It might help if you think of this as a sum that you have to do.

Let’s say you’re in a DIY store, and you need to buy some wallpaper to paper 4 walls in a room. You know the height and width of each wall, and you know the area of a a roll of wallpaper, and you need to work out how many rolls of wallpaper you need to buy.

The sum you have to do is:

(height of wall 1 x width of wall 1 / area of wallpaper roll) + (height of wall 2 x width of wall 2 / area of wallpaper roll) + (height of wall 3 x width of wall 3 / area of wallpaper roll) + (height of wall 4 x width of wall 4 / area of wallpaper roll) = number of wallpaper rolls needed to paper room.

But if you “cache” the wall areas, the sum becomes “easier” and can be done in less time:

(wall 1 area / area of wallpaper roll) + (wall 2 area / area of wallpaper roll) + (wall 3 area / area of wallpaper roll) + (wall 2 area / area of wallpaper roll) = number of wallpaper rolls needed to paper room.

And if you cache the number of rolls needed for each wall, the sum becomes even easier and even quicker:

Wall 1 rolls + wall 2 rolls + wall 3 rolls + wall 4 rolls = number of wallpaper rolls needed to paper room.

Or you could just cache:

Number of wallpaper rolls needed to paper room.

Now to put this in the context of WordPress here’s the no caching WordPress:

Request for page reaches site.
WordPress executes WordPress core PHP, theme PHP and plugin PHP.
PHP interacts with database.
PHP and database, between them generate page output.
Output is received by browser, browser renders page, page is displayed in browser.

With caching it’s a bit different (and there can be a difference in what’s cached where and how it’s served, but I’ll come to that in a moment). Now imagine if the above had already happened, and the page output had been remembered, and turned in to an HTML file, and that was served instead instead of steps 2, 3 and 4 in the above taking place, it would be more like this:

Request for page reaches site.
Cached HTML file is served to provide page output.
Output is received by browser, browser renders page, page is displayed in browser.

That is roughly how some caching plugins available to WordPress (such as the WP Fastest Cache plugin).

So Caching Makes Things Faster, Right?

The closest I’m prepared to commit to a yes in answer to this question is “it can”.

Why only “it can” rather than “it does”?

The example I gave above (with the wallpaper) is effectively an analogy for what WordPress is doing. Whilst this can and does reduce page load times, there’s other factors that can cause delays in page load times. These other factors won’t always be improved by using a caching plugin.

Once WordPress has generated page output, the browser then has to render the page output to turn it in to a web page that’s seen by a human. This browser rendering also takes time, and there can also be delays to browser rendering caused by page output itself.

Caching itself doesn’t usually affect what the page output contains (although there can be exceptions).

If the page output itself causes a delay in browser rendering, using a caching plugin may well cache, and serve, the part causing the delay. Therefore caching doesn’t affect the delay specific to the browser rendering, it only affects the time it takes to generate and serve what’s causing the delay in browser rendering, but it doesn’t reduce the browser rendering delay itself.

Make sense? No? OK, let me put it another way.

Take a tool like https://pagespeed.web.dev/ for example. This tool analyses page output to help you eliminate delays specific to browser rendering.

If you run your site through https://pagespeed.web.dev/ and a issues like “eliminate render blocking resources”, “reduce unused Javascript” and “excessive DOM size” are flagged, caching alone won’t make much, if any, difference to this. This is because what’s being flagged as problematic will still be cached and served when using a caching plugin.

OK, I’m generalising a bit here and this can be confusing and you might well be sat there reading this thinking “I installed a caching plugin and it sorted out the stuff in pagespeed”. That’s because the caching plugin you’ve used does more than caching alone. Caching plugins will often do more than caching alone, such as inlining CSS, or deferring Javascript, but this isn’t caching, this is effectively optimisation in an automated manner.

If you cache before carrying out any optimisation on your WordPress then you’re potentially caching a lot that doesn’t need to be cached, and this will reduce how effective the caching is for your site.

What this means to you:

If you do this:

Made site, bit slow, caching will sort it out!

It’s not going to be as effective as this:

Made site, bit slow, what problems are flagged in https://pagespeed.web.dev/? Address those, then cache.

Although the latter is a lot more work and takes more time it’s more likely to eliminate this situation:

Using a caching plugin didn’t make much difference to my site’s performance.

But then again, it is possible to use a caching plugin, not see much improvement in performance and this situation not be a product of a lack of upstream optimisation. It could be as simple as not having configured the caching plugin correctly.

It’s also possible that the caching plugin you’re using doesn’t actually cache the part that you need it to that would result in an improvement in performance. This is because different caching plugins work in different ways, and what caching plugins actually do varies between plugins.

Working like this, at best will result in some minimal performance improvement and at worst have zero effect:

Made site, bit slow, caching will sort it out!

Working like this will result in a much greate likelihood of there being an improvement in performance:

Make site
Run site through https://pagespeed.web.dev/
Address issues flagged by pagespeed
If site is still slow, work out what is causing the slow
Install caching plugin that provides capability to cache what is causing the slow
Configure caching plugin correctly

Really, what I’m saying here is that you’ll see a much greater improvement in performance it you have to look at your WordPress and what it’s doing, and what’s causing issues with performance and work out how to address these issues, THEN use an appropriate caching plugin and configure it correctly. You’ll see a greater improvement in performance, as opposed to just banging a caching plugin in to your WordPress and hoping for the best.

Yes, it is more work, yes, it wil take more time, yes you’re going to have to work things out, but if you do, this effort pays dividens in the performance increase you’ll see.

The alternative to the above is going to be something along the lines of trying multiple caching plugins, only to find the site still has poor performance, (which is effectively a waste of time).

Different Caching Plugins Work in Different Ways.

I’m going to use 3 caching plugins as examples for this part, which are:

These three plugins are all quite different in how they work.

For this to make sense I’m going to have to outline some terminology.

These aren’t technically caching, they’re more optimisation specific (although you may see some of these options in caching plugins config):

Minify: Taking the spaces and comments out of CSS and JS to reduce the overall size of the file.
Combine: Combining the contents of multiple files in to a singular file.
Inline: Instead of linking to an external CSS file, the CSS styles are included directly within the HTML document.
GZip/Compression: Compressing page output (which is then decompressed by the browser) to reduce the amount of data transferred over the wire.
Defer: Defer is used in the <script> tag to indicate that the script should be executed after the HTML document has been parsed. When a script is deferred, it won’t block the parsing of the HTML document (so this stops scripts being render blocking).
Async: Async is also used in the <script> tag but it’s to indicate that the script should be fetched in the background while the HTML parsing continues. It doesn’t wait for the script to be fully downloaded and executed before parsing the rest of the HTML (which stops the script being render blocking). The script is executed when it becomes available.

These are to do with caching (rather than optimisation):

Preload: Making a copy of the cache in advance of pages being visited.
Caching policy: This tells a browser how long it should cache static resources, and what should be cached.
Disk Cache: A local file system based cache of HTML files that have been generated based on page output.
Object cache: I’ve written a whole post dedicated to object caching alone. Object caching is an underlying service (Redis or Memcached) that can be used to cache “Objects” specific to your site such as the products of database queries, and the results of commonly used PHP execution.
Opcache: This is a caching engine for PHP that improves the performance of PHP scripts by storing precompiled script bytecode (0’s and 1’s type computer code) in shared memory.

Now we’ve got the terminology out of the way, let’s take a look at some caching plugins.

WP Fastest Cache

WP Fa s test Cache is quite lightweight and easy to use/configure. Install it, activate it, tick the boxes, save, done.

WP Fastest Cache creates a local disk cache of HTML files (your site’s pages) and also a disk cache of optimised CSS and JS. It then adds rules to your WordPress to serve these instead of generating page output by executing the PHP and this interacting with the database to generate page output as and when pages are requested.

WP Fastest Cache also sets a caching policy (you find out more about this in this post about serving static assets with an efficent caching policy) which tells browser to cache static assets, and how long it should cache these for. It can also be used bring GZip compression in to effect (more about this in this post about enabing browser compression).

When using the free version of WP Fastest Cache, the configuration options look like this:

As you can see it’s not very configuration heavy, and it’s quite obvious what it’s going to do (now that you know the terminology).

Obviously there are things mentioned in the terminology above (such as object caching and opcode) that this plugin doesn’t do, or provide configuration options for. Consequently it doesn’t do as much caching (or at least use as many caching facilities) as other plugins but it is a lot easier to configure due to this.

On the plus side, because it doesn’t do as much, it doesn’t have a particularly large resource overhead.

Whether you’ll see an increase in performance depends a bit on the type of site you have and how it works.

If you have a handful of pages with fairly static content, your site doesn’t do a huge amount of processing (i.e. nothing fancy), and there’s not a huge amount of interaction with the database, and you’re looking for something quick and easy to use, then WP Fastest Cache can be a good fit.

If you’re running a more complicated site such as a Woo Commerce based store there’s going to be a lot more processing and databse interactions, and WP Fastest Cache won’t help with this aspect. It will help with cached site pages, but not with all the database interactions involved with a more complicated site.

WP Fastest Cache (free version) is Good for:

Static Content Websites: WP Fastest Cache is well-suited for static content websites where the majority of the content doesn’t change frequently. It can efficiently cache static HTML pages, reducing server load and improving page load times for visitors.
Blogs and News Sites: Websites that primarily consist of blog posts or news articles can benefit from WP Fastest Cache. It helps in caching these content pages, resulting in faster loading times and improved overall performance.
Small to Medium-sized Business Websites: Small to medium-sized business websites with relatively static content, such as company information, services, and contact details, can use WP Fastest Cache to enhance page loading speed and provide a better user experience.
Portfolio Websites: Portfolio websites showcasing the work of photographers, designers, or artists often have static pages. WP Fastest Cache can be beneficial in optimizing the loading times of these pages, especially when there are numerous images to display.
Brochure Websites: Websites serving as online brochures with fixed content and minimal dynamic elements can leverage WP Fastest Cache to speed up page rendering.
People that don’t like lots of configuration options.

WP Fastest Cache (free version) is Not So Good for:

Highly Dynamic Websites: WP Fastest Cache might not be the best choice for highly dynamic websites where content changes frequently or is personalized for each user. Caching dynamic content could lead to outdated or incorrect information being displayed.
E-commerce Sites with Real-time Updates: E-commerce websites with real-time inventory updates, dynamic pricing, or frequent product additions and removals may face challenges with caching. Changes in product availability or pricing might not reflect accurately with caching enabled.
Membership or Login-based Sites: Websites that require users to log in or have personalized content based on user roles may encounter issues with caching. Caching personalized content for one user might result in incorrect content being displayed to another.
Websites Relying Heavily on Ajax: Websites utilizing a lot of Ajax requests for dynamic content loading might face challenges with WP Fastest Cache. Ajax-driven content updates may not work as expected with full-page caching.
Sites Requiring Real-time User Interaction: Websites that heavily rely on real-time user interactions, such as live chat applications or real-time collaborative editing, may not benefit from caching. Caching might hinder the responsiveness of these features.

W3 Total Cache

Compared to WP Fastest Cache, W3 Total Cache is VERY config heavy. There’s about 8 pages of config options, compared to the one in WP Fastest Cache. This is because it does more (or can be configured to do more) than WP Fastest Cache.

I’ve written a post covering how to configure W3 Total Cache in WordPress which you can find here.

W3 Total Cache can do all the things that WP Fastest Cache can do, and W3 Total Cache can also do more!

One of the main things that W3 Total Cache can do is object caching (more information about object caching can be found here).

W3 Total Cache can also use a disk cache in the file system of your hosting account. This works in the same way that WP Fastest Cache’s caching system works.

W3 Total Cache also has options to using either the disk cache, or the object cache for different types of caching it can do (database caching and page caching, for example). So you can use the disk cache, to cache your sites pages, and you can use the object cache to cache datbase objects.

You can use these different caching mechanism to spread the caching load of different aspects of your site that can be cached. Use this caching mechanism to cache that and that caching mechnism to cache this, that kind of thing.

W3 Total Cache also has a built in setup guide that you can use to work through the many different caching options it provides as well, which is a nice touch.

There’s an extensive FAQ and various guides provided by the people that made W3 Total Cache, which can be found here.

There’s also a post on this blog covering how to configure W3 Total Cache.

To give you an overview of what W3 Total Cache can do:

Page Caching: Caches dynamically generated HTML pages to reduce server load and improve page load times.
Minification: Minifies HTML, CSS, and JavaScript files to reduce their file sizes, improving load times.
Object Caching: Implements object caching to store frequently used database queries, reducing the need to query the database repeatedly.
Browser Caching: Configures browser caching rules for static assets (images, stylesheets, scripts), allowing visitors to reuse cached resources and speeding up subsequent visits.
Database Caching: Caches database queries to reduce the load on the database server.
CDN Integration: Integrates with Content Delivery Networks (CDNs) to serve static assets from distributed servers, improving content delivery speed.
Mobile Optimization: Provides options for optimizing and caching content specifically for mobile devices.
Fragment Caching: Implements fragment caching for parts of a page that are dynamic, allowing certain sections to be cached while others remain dynamic.
Reverse Proxy Integration: Supports integration with reverse proxy servers, such as Varnish, to further optimize caching.
Lazy Loading for Images: Delays the loading of images until they are about to appear in the user’s viewport, reducing initial page load times.
Import/Export Settings: Allows users to export and import plugin settings, making it easier to replicate configurations on multiple sites.
WP-CLI Compatibility: Compatible with WP-CLI, enabling users to manage caching configurations through the command line.
Database Cleanup: Provides options for cleaning up and optimizing the WordPress database to improve efficiency.
SSL Support: Works with websites using SSL certificates, ensuring compatibility and secure connections.
Page, Post, and Feed Cache: Allows caching of individual pages, posts, and feeds.
Minification of Inline, Embedded, or 3rd Party JavaScript and CSS: Minifies not only external files but also inline, embedded, or third-party JavaScript and CSS.

Which of these features you’ll need to use and how depends on the type of site you have and how it operates, so you might find that you have to undertake a bit of tuning to get it running well, but it’s worth the effort!

W3 Total Cache (free version) is Good For:

Static Content Websites: W3 Total Cache is suitable for websites with predominantly static content, such as blogs, news sites, or informational pages. It can cache static HTML pages, improving page load times for visitors.
E-commerce Sites with Static Elements: For e-commerce websites where product pages, category pages, and other static elements dominate the content, W3 Total Cache can be beneficial. However, dynamic elements like real-time inventory or pricing changes may require careful configuration.
Content-Rich Blogs: Blogs with a substantial amount of content, articles, and images can benefit from the page caching, minification, and browser caching features to enhance overall performance.
Business Websites with Limited Dynamic Content: Small to medium-sized business websites that primarily provide information about services, contact details, and other static content can use W3 Total Cache to improve loading times.
Portfolio Websites: Portfolio websites showcasing the work of photographers, designers, or artists, where the content is relatively static, can leverage W3 Total Cache for faster page rendering.
Websites with Moderate Traffic: Websites with moderate traffic that experience occasional spikes can benefit from caching to handle increased visitor loads efficiently.
Mobile-Optimized Websites: W3 Total Cache offers mobile optimization features, making it suitable for websites targeting mobile users.

W3 Total Cache (free version) is Not So Good For:

Highly Dynamic Websites: Websites with highly dynamic content that changes frequently might face challenges with caching, especially if real-time updates are crucial. Dynamic elements like user-specific content may not cache well.
E-commerce Sites with Real-Time Updates: If an e-commerce site has frequent real-time updates, such as changes in inventory, dynamic pricing, or live stock levels, extensive caching may not be suitable. It could lead to outdated information being displayed.
Membership or Login-Based Sites: Websites that require user logins or display personalized content based on user roles may face challenges with caching. Caching personalized content might lead to incorrect information being displayed to users.
Sites Relying Heavily on Ajax: Websites that heavily use Ajax for dynamic content loading might face challenges with W3 Total Cache, as Ajax-driven content updates may not work seamlessly with full-page caching.
Websites with Strict Security Policies: Some security-conscious websites may have restrictions on caching certain content for security reasons. Careful consideration and testing are necessary to ensure that caching mechanisms align with security policies.

I used to use the W3 Total Cache plugin for this site.

Used to?

Well, see, there’s this other caching plugin that I now use, and that’s:

LiteSpeed Cache

The Litespeed Cache Plugin is a little bit “another level” compared to W3 Total Cache and it’s miles apart from WP Fastest Cache. You can find a post covering how to configure the Litespeed Cache plugin for WordPress here.

This is because it was developed by the people that make the Litespeed web server. The Litespeed web server is a drop in replacement for Apache (I’ve written an entire post dedicated to the Litespeed Web Server here).

The idea of the Litespeed Cache plugin is that it’s designed to work in conjunction with the Litespeed web server (to provide an “in WordPress” way of utilising and manage the caching mechanisms available in the Litespeed web server). The Litespeed Cache plugin can also be used to make use of other caching mechanisms available in the underlying stack such as object caching. It can also make use of OPcache as well.

Having read the pragraph above you might think “That sounds like you need Litespeed on the server to be able to use that plugin”, and I wouldn’t blame you for thinking that, but you can actually use this plugin even if there’s no Litespeed server running in your hosting! Crazy, eh? How does that work?!

If you don’t have the Litespeed web server running on the platform you’re using for hosting, the Litespeed Cache plugin can detect if this is the case, and if it does, it uses an external server (that is running the Litespeed web server) to cache and call parts of your site, and serve it to visitors. There is a little bit of a performance hit compared to using a local Litespeed server, but it’s not as much as you might think.

The Litespeed Cache plugin is very versatile in this capacity.

Now, you might think that given this CDN like facility and all the things this plugin can do, that there’s going to be some epic configuration involved, but they’ve covered this too!

When you install and activate the Litespeed Cache plugin there’s a “presets” page that you can see, which looks like this:

These presets are 5 configuration profiles that you have the option of applying to your site.

So setting up and configuring this plugin is quite easy:

Install and activate the Litespeed Cache plugin
Apply a preset
Configure obejct caching
And if Litespeed isn’t running in your hosting use the general settings to sign up for QUIC.cloud account and request a domain key.
Twek the Litespeed cache plugin options according your needs.

A complete guide covering how to configure the Litespeed Cache plugin for Wordpres can be found here.

If Litespeed is running locally on your hosting, you’ll most likely see a large performance improvement. To give you an idea, when I got this plugin setup and running (with local Litespeed) my TTFB (time to first byte) dropped from about 2.4 seconds, to 0.2 secons. That’s quite an improvement. You can read more about the adventures I had doing this in my post about the Litespeed Web Server.

I’ve messed about with a lot of caching plugins, and I’m yet to see such an improvement in performance gained with such a minimal effort.

So how does it do this?

Well, this is going to sound s bit wierd, but some of it is like WP Fastest Cache’s caching mechanism (files on disk), and obviously there’s object caching as well, plus the additonal OPcache.

The main difference is, that when using the Litespeed Cache plugin along with the Litespeed web server the caching is “more” inegrated with the web server itself, which is what’s handling the requests for your site.

I’ll admit I’m simplifying this a bit (a more in depth explanation can be found on the post about the Litespeed Web Server) but the key point here is that this plugin is VERY easy to use, and can result in a big performance increase when using the Litespeed web server, and a fairly good performance increase, even if you don’t have the litespeed web server available in your hosting.

One of the slight down sides about this plugin is that it’s very caching centric (as opposed to having options specific to optimisation, which a lot of other caching plugins do), so you do have to carry out some optimisation to get your page output looking good before using Litespeed Cache plugin, and you have to do this (in most cases) independantly of this plugin.

For example, lets say you have some render blocking CSS in your page output. The Litespeed Cache plugin won’t sort this out for you. BUT, if you address the render blocking CSS, then use the Litespeed Cache plugin your caching will be effective AND your page output good, and you’ll see more of a performance increase.

The other good thing about this plugin is it’s kind of designed to bridge the CMS to web server gap to unify the two and get them working better together, rather than being two slightly disparate aspects of the same system.

Here’s an overview of the Litespeed Cache plugin’s functionality:

Page Caching: LiteSpeed Cache provides full-page caching to store static copies of dynamically generated pages. This reduces the server load and improves the speed of delivering content to visitors.
Object Caching: Implements object caching to store and retrieve frequently used database queries, reducing the need to repeatedly query the database.
Browser Caching: Configures browser caching rules for static assets like images, stylesheets, and scripts. This allows visitors to reuse cached resources and speeds up subsequent visits.
CDN Support: Integrates with Content Delivery Networks (CDNs) for efficient content distribution, resulting in faster page loading times, especially for visitors from different geographical locations.
Lazy Load for Images: Delays the loading of images until they are about to appear in the user’s viewport, reducing initial page load times.
Minification: Minifies HTML, CSS, and JavaScript files to reduce their file sizes, improving load times.
Database Optimization: Provides options for optimizing and cleaning up the WordPress database to improve efficiency.
Cache Purge: Offers various options for cache purging, including manual purging, automatic purging on content updates, and support for third-party cache purging plugins.
HTTP/2 Push for CSS/JS: Utilizes HTTP/2 Push to proactively send critical CSS and JavaScript files to the browser, reducing round-trip times.
Image Optimization: Includes image optimization features to compress and resize images automatically, reducing file sizes without compromising quality.
Database and Object Caching Exclusions: Allows users to exclude specific pages or content from caching or object caching if needed.
Advanced Edge Side Includes (ESI): Implements Edge Side Includes to allow for more granular control over caching by including or excluding specific parts of a page from caching.
Heartbeat Control: Provides control over the WordPress Heartbeat API to reduce unnecessary server requests.
Multisite Support: Offers support for WordPress Multisite installations, allowing network-wide cache management.
WooCommerce Compatibility: Compatible with WooCommerce, the popular e-commerce plugin for WordPress, providing optimizations for online stores.

Litespeed Cache plugin is Good For:

Websites Hosted on LiteSpeed Web Server: The LiteSpeed Cache plugin is most suitable for websites hosted on servers running LiteSpeed Web Server. LiteSpeed Cache is specifically designed to work seamlessly with LiteSpeed Web Server, leveraging server-level optimizations for improved performance.
High-Traffic WordPress Sites: For high-traffic WordPress websites, LiteSpeed Cache can efficiently handle increased loads and deliver content faster. Its advanced caching features and optimizations are beneficial in handling a large number of concurrent visitors.
E-commerce Websites: LiteSpeed Cache is suitable for e-commerce websites, especially those running WooCommerce. Its optimizations, including page caching and image optimization, can enhance the performance of online stores.
Global Audience with CDN: Websites targeting a global audience can benefit from the LiteSpeed Cache plugin when combined with a Content Delivery Network (CDN). The plugin integrates seamlessly with CDNs to ensure faster content delivery to users worldwide.
Lazy Loading for Images: Websites with a significant number of images can leverage LiteSpeed Cache’s lazy loading feature to defer the loading of images until they are about to appear in the user’s viewport. This improves initial page load times.
Multisite Installations: LiteSpeed Cache is suitable for WordPress Multisite installations, providing network-wide cache management. This is beneficial for administrators managing multiple websites within a single WordPress network.
Advanced Caching Needs: Websites with advanced caching needs, such as Edge Side Includes (ESI) for granular control over caching, can benefit from LiteSpeed Cache. ESI allows including or excluding specific parts of a page from caching.

Litespeed Cache plugin is Not So Good For:

Non-LiteSpeed Web Server Environments: If your website is hosted on a server using a web server other than LiteSpeed (e.g., Apache or Nginx), the LiteSpeed Cache plugin may not be fully compatible or provide the same level of optimization.
Compatibility Issues with Specific Themes/Plugins: In some cases, certain themes or plugins may not be fully compatible with LiteSpeed Cache. It’s essential to test and ensure compatibility, especially if the website relies on specific functionalities or features provided by other plugins.
Limited Server Control: Websites hosted on shared hosting environments with limited control over server configurations may not fully leverage LiteSpeed Cache’s server-level optimizations.
Sites with Strict Security Policies: Some security-conscious websites may have restrictions on certain optimizations or caching strategies. It’s crucial to consider whether LiteSpeed Cache aligns with the security policies of the website.
Websites with Frequent Dynamic Content Updates: If your website relies heavily on real-time content updates or has frequently changing dynamic content, caching strategies may need to be carefully configured to avoid displaying outdated information.

In Conclusion.

Different cahing plugins work in different ways.
Different ways of working provide different advantages and disadvantages.
The plugin that’s best to use is in part dictated by your site, and in part by you and how much config you’re willing to undertake.
It’s always better to optimise upstream of caching, rather the caching unoptimised content.