A Fast WordPress Site: The Evidence-Based Setup

In short: to speed up WordPress, get page caching right and stop there before touching anything clever. Page cache, correct browser cache headers, compressed images with dimensions, and one self-hosted font family deliver most of the available gain. CSS and JavaScript combining, critical CSS and aggressive lazy-loading are where sites break and where measurable gains are smallest.

Most advice on how to speed up WordPress is untested. This guide is unusual for us in one respect: we can report first-hand, because we did this work on this site and measured the result. Where we describe a finding from our own setup we say so explicitly. Where we have not measured something, we say that too.

How we approached this

The findings below come from configuring caching on rankboast.com in August 2026 and verifying the response headers before and after. That is genuine first-hand evidence for one WordPress site on LiteSpeed hosting, not a controlled study across hosts. Our review methodology explains where we draw that line.

To speed up WordPress, start with page caching

Without a page cache, every visitor triggers PHP execution and database queries to rebuild a page that has not changed. With one, the server returns a stored copy. On our own site this took time-to-first-byte from hundreds of milliseconds to tens.

Match the cache to the host. On a LiteSpeed server, LiteSpeed Cache integrates with the web server directly. On Nginx or Apache, use a cache that suits that stack, or your managed host’s own. The important rule: run one page cache, not two. Two caching layers fighting each other produce stale pages and hours of confusion.

The subtle mistake we found on our own site

This is the finding most worth passing on, because it is invisible and it silently defeats every other change you make.

Our .htaccess contained a line reading ExpiresDefault "access plus 1 weeks" with no explicit rule for HTML. Because HTML fell through to that default, every page was served to browsers with Cache-Control: public, max-age=604800 — instructing every visitor’s browser to keep that copy of the page for a week.

The consequence: we changed the site navigation, purged the server cache, and still saw the old menu. So would every returning visitor, for up to seven days, no matter what we published. Server-side purging cannot reach a copy already sitting in someone’s browser.

The fix is to cache static assets hard and HTML not at all: images and fonts for a year, CSS and JavaScript for a month, HTML with no-cache, must-revalidate. The page cache still serves stored pages from the server, so nothing gets slower — browsers simply revalidate, which costs a conditional request rather than a rebuild. Check your own site’s HTML response header before assuming this is not you.

Images: the largest weight, the easiest win

• Serve modern formats. WebP or AVIF instead of large JPEG and PNG files.
• Set width and height on every image. This prevents layout shift, which is a ranking signal and an irritation.
• Never lazy-load the main image. The largest visible image should load eagerly with high priority. Lazy-loading it delays the exact element the browser measures.
• Resize before upload. A 4000px photograph displayed at 800px wastes most of its bytes.

This is why we deliberately did not enable our cache plugin’s built-in lazy-loading when we set it up: it defers images generically, including the one that should load first.

Fonts and scripts

Self-host one font family with two weights, preload it, and use font-display: swap. A third-party font request adds a DNS lookup and connection before any text renders.

For scripts, the effective move is removal rather than optimization. Every plugin adding front-end assets costs something on every page. Audit what is actually loading and remove what you are not using — that beats minifying code that should not be there.

What we deliberately left off

When we configured this site we enabled page cache, browser cache headers, CSS and HTML minification, and removal of the emoji script. We deliberately did not enable CSS/JavaScript combining, critical CSS generation, or plugin lazy-loading.

Those features can help, but they are also where sites break: combined files fight with conditional loading, generated critical CSS causes unstyled flashes, and lazy-loading damages the largest-element metric. They need testing on a staging copy, not enabling in bulk on a live site. If you want to speed up WordPress without risk, the conservative set delivers most of the benefit.

The order to work in to speed up WordPress

1. Measure first, on mobile, and note which metric is actually failing.
2. Enable one page cache and verify it is serving cached responses.
3. Check your HTML cache header for the trap described above.
4. Fix images: format, dimensions, and eager loading for the main one.
5. Self-host and preload one font.
6. Remove unused plugins and scripts.
7. Only then experiment with combining and critical CSS, on staging, measuring each change.

Common mistakes

Running two page caches. Stale pages and untraceable bugs.

Browser-caching HTML. Invisible, and it defeats everything else. We had this exact fault.

Lazy-loading the hero image. Directly worsens the metric you are trying to improve.

Enabling every plugin toggle at once. When it breaks you cannot tell which switch did it.

Optimizing instead of deleting. The fastest script is the one you removed.

Verdict

To speed up WordPress reliably: one page cache, correct cache headers, disciplined images, one font, fewer plugins. That set is unglamorous, low-risk and accounts for most of the achievable gain. The clever features are worth trying afterwards, on staging, one at a time — and if you only check one thing today, check what Cache-Control your pages send to browsers.

What we would need to test to say more

Our evidence is one site on one host, measured before and after. To make general performance claims we would need matched WordPress installations across several hosts and cache plugins, field data from real visitors over weeks, and isolated testing of each optimization. We have not done that, and we do not present our single-site findings as a benchmark.

Sources and methodology

The caching findings are first-hand from configuring rankboast.com in August 2026, verified by inspecting HTTP response headers before and after each change. No provider paid for or influenced this article. Research and drafting were AI-assisted. Errors are handled under our corrections policy.

Source links

• MDN: Cache-Control header reference
• web.dev: Largest Contentful Paint