Skip to content
System nominalUTC --:--:--Articles 080

5 Free Plugins That Make WordPress Faster Without Touching Code

Caching, minification, image compression and database cleanup, with the current version and update date of each plugin and an honest note on what it cannot fix.

Tomas Lindqvist · @tlindqvist

Hardening and operations

Topic
PERF
Section
Performance
Published
16 OCT 2026
Reading time
8 MIN
Words
1785W
Technical cover graphic for 5 Free Plugins That Make WordPress Faster Without Touching Code
Generated schematic — PERF series, REV 2.6.

A site owner installs a caching plugin, clears the cache, tests the homepage on a phone, and gets roughly the same load time as before. So they install a second caching plugin. Now the site is slower, because two plugins are fighting over the same page output, and one of them is writing its cache to a directory the other one invalidates.

Nothing about that story is unusual. "Make WordPress faster" is not one problem, and no single plugin solves it. Three things decide how a page feels: how long the server takes to produce the HTML, how much CSS, JavaScript and image data has to arrive after that, and what happens to both when traffic arrives all at once. A page cache fixes the first, minification and image compression fix the second, and a badly configured plugin of either kind makes the third worse.

Five free plugins cover those three jobs without touching a theme file or writing a line of code. Every version and date below was read from the plugin's own wordpress.org listing on 2026-10-16.

Measure two numbers before you install anything

Open the site in a private window, then in your browser's network panel look at two figures: time to first byte, which is the server's contribution, and total transferred bytes, which is everything else. Run the same page once through PageSpeed Insights on mobile for a second opinion. Write both numbers down.

If time to first byte is over roughly half a second on an uncached page, the problem is on the server side and caching is the right first move. If first byte is fast but the page weighs four megabytes, caching will barely move the needle. You can also check the admin side cheaply: the plugin list will tell you whether you are running two caching plugins, which is the most common cause of a site that got slower after an optimisation attempt.

One more number worth having: how many plugins are active. Twenty is not automatically a problem, and two can be enough if one of them queries the database on every page load. What matters is whether a plugin runs during a front-end request, not how many are installed.

Then install one plugin at a time. Change one thing, measure the same page the same way, and keep the change only if a number moved. Sites that get slower after an optimisation round almost always did three things at once and can no longer tell which one broke the page.

Three plugins that change how fast the page arrives

Autoptimize, for the CSS and JavaScript the site already loads

Autoptimize is a small, focused tool: it minifies and concatenates your stylesheets and scripts and can inline the critical CSS. Installed from the wordpress.org listing, version 3.1.16 was published on 2026-09-26, it has around 800,000 active installations, and it is tested against the current WordPress. It is for a site whose page weight is the problem, one built on a theme plus a page builder that each enqueue their own CSS and half a dozen small scripts.

Where it stops being enough: it does not cache pages and it does not touch images. It also needs one careful afternoon. With the default aggressive settings it will merge scripts in an order the theme did not expect, and a slider or a checkout page will break. Enable one option at a time, test the interactive pages, and read the plugin's own exclusion settings before you ask it to aggregate jQuery.

LiteSpeed Cache, if your host runs LiteSpeed

LiteSpeed Cache is the largest of the free page caches, with around seven million active installations. Version 7.9.1 was published on 2026-09-01 and it is tested against the current WordPress. It does page caching, object caching, image optimisation, minification and database cleanup in one plugin, which is a genuine advantage: you are not stacking five plugins that disagree about cache invalidation. It is for the site that already has a LiteSpeed or OpenLiteSpeed server and wants one plugin doing the work of four.

On a store or a membership site, the object cache is the part worth having even before the page cache, because it keeps repeated options and query results out of MySQL inside a single request. That is also where it overlaps with your host's own caching layer, and running two object caches against the same Redis instance is a reliable way to produce stale pages that nobody can reproduce.

Where it stops being enough: on an Apache or Nginx host without LiteSpeed, the most valuable half of it is unavailable, and the plugin's own documentation is direct about which server modules it needs. If your host does not run LiteSpeed, you are configuring a plugin that cannot use its best features. Ask your host which web server you are on before you install it, and if the answer is Apache, use the next plugin instead.

WP Super Cache, for hosts where nothing else is available

WP Super Cache takes the oldest approach and it still works: it writes a static copy of each page so a cached request never boots PHP at all. Version 3.1.4 was published on 2026-09-30, around a million sites run it, and it is tested against the current WordPress. It is for cheap shared hosting where you cannot install a server-level cache and your host has no opinion about which plugin you use.

Where it stops being enough: it generates a static page and stops there. It does not minify, compress images or clean the database, so it is one third of the job rather than a complete answer. Its settings screen is also denser than it needs to be, and the difference between simple and expert mode is not obvious from the labels. Accept the defaults unless you have a specific reason not to.

One configuration detail is worth knowing before you rely on it. The plugin serves a cached copy only for visitors who are not logged in and have no comment cookie, which is correct behaviour and also means the cache does nothing for the client who is checking their own site while logged in. Test in a private window, or you will spend an afternoon optimising a page that was never cached for you in the first place.

Two plugins that change how much has to arrive

Smush, for the images nobody resized before uploading

Smush compresses images on your own server rather than sending them to an external service, which keeps freelancers out of the loop. Version 4.3.4 was published on 2026-09-29, it has about a million active installations, and it is tested against the current WordPress. It compresses the files already in the media library in bulk and lazy-loads images below the fold. It is for the site where the single heaviest asset is a hero photograph someone uploaded straight from a camera.

Where it stops being enough: the free version caps compression on very large originals and does not convert them to newer formats, so a 3 MB JPEG may still leave the free tier heavy. It is also a one-way operation. Compressed images are not reliably restorable, so take a backup before you run bulk compression on a library you cannot re-upload.

WP-Optimize, for the database the site has been carrying around

WP-Optimize cleans the parts of the database that grow and are never read: post revisions, expired transients, spam comments and the overhead left by deleted rows. Version 4.7.0 was published on 2026-09-21, around a million sites run it, and it is tested against the current WordPress. It is for the site that has been live for two years and never removed anything, where the options table and the revisions table have quietly become the slowest thing in a request.

Where it stops being enough: it is a database and maintenance tool first. Its caching and minification features are useful, but a site whose bottleneck is uncached page generation needs a dedicated page cache, and WP-Optimize will not replace the plugin above. Skip the automatic cleanup schedule until you have run one manual cleanup and checked the site afterwards.

What five free plugins cannot fix

Together these cover minification, page caching, image weight and database hygiene. That is most of what is available to someone who cannot change the server, and on a small site it is often enough to move a mobile score out of the red.

It does not cover the server. PHP worker limits, an undersized database instance and network distance between the host and the visitor all set a ceiling that no plugin can lift, and on a managed host that ceiling is usually the number you are actually fighting. It also does not fix a page builder that loads two megabytes of CSS and JavaScript on every page. Minification reduces that; it does not remove it.

There is one more honest limit. A plugin that queries the database on every request, such as a related-posts or filtering plugin, will still do that work on any page you choose not to cache, and the free caches above will not cache logged-in users or a cart without extra configuration. If that describes your site, the free tier is where you start, not where you finish.

Monday: what I would do in this order

  1. Check the plugin list and deactivate any second caching plugin. This is free and it fixes more sites than any install.
  2. Install one page cache that matches the host: LiteSpeed Cache on LiteSpeed, WP Super Cache anywhere else.
  3. Run Smush over the media library once, after taking a backup.
  4. Add Autoptimize, then enable its options one at a time and test the pages that contain forms, sliders and a cart.
  5. Run WP-Optimize manually, look at the site, and only then turn on a schedule.

Keep a note of the two numbers you wrote down at the start, with the date. Free plugins change version more often than paid ones, and the honest way to find out whether this month's round of updates helped is to compare against something you recorded rather than against a feeling.

If you have done those five things and the numbers have not moved, the constraint is the host or the page builder, and paying for a plugin will not change that. The paid tools become worth considering when you need per-page control over what loads, or support you can hold to a response time, which is the point at which the free set stops being the right answer. Paid caching and speed plugins: when the free tier stops being enough compares what the commercial tiers actually add, and who should keep the free five.

Tomas Lindqvist · @tlindqvist

Hardening and operations

Threat models plugins, audits capability and nonce handling, and builds the observability that tells you an integration broke before a customer does.

Continue

Related in Performance