How we cut a WordPress site's load time in half
Most slow WordPress sites are slow for the same handful of reasons — and almost none of them are fixed by installing another “speed” plugin. Performance is a process, not a product: measure, find the few changes carrying the most weight, ship them, then measure again. Here is the order we work through, and why measuring first saves you from optimising things that were never the problem.
Measure before you touch anything
Before we change a single line, we capture a baseline. That means a Lighthouse lab test for repeatable numbers and real-device field data — the Chrome User Experience Report behind PageSpeed Insights — for what visitors actually experience. We note the three Core Web Vitals (Largest Contentful Paint, Cumulative Layout Shift, and Interaction to Next Paint) and the server’s Time to First Byte, and we test the templates that matter: the home page, a typical post, and a key landing or product page.
Without a baseline you cannot tell whether a change helped, hurt, or did nothing — and you cannot prove the result afterwards. Optimising without measuring first is just guessing with extra steps.
Right-size the images
On almost every site we audit, images are the single biggest chunk of the page weight. Three fixes do most of the work: serve correctly-sized images instead of a 4000px hero scaled down in the browser, use modern formats such as WebP or AVIF, and lazy-load anything below the fold. We set explicit width and height (or an aspect ratio) on every image so the browser reserves the space and the layout does not jump as things load — that one habit alone kills most Cumulative Layout Shift. The one image we never lazy-load is the LCP image: that gets loaded with priority so the main content paints sooner.
Stop the render-blocking scripts
A typical WordPress page ships a dozen plugins, and each one queues its own CSS
and JavaScript into the <head>, blocking the first paint. We defer
non-critical JavaScript, inline the small slice of critical CSS the first screen
needs, and load the rest asynchronously. Half the battle is simply removing
scripts that have no business being there — a slider library loading on pages
with no slider, or analytics injected twice by two different plugins.
Trim the plugin surface
Every active plugin is code that runs on each request, queries the database, and has to be kept updated and secure. The goal is not a plugin-count contest; it is removing the ones whose cost outweighs their value and replacing the worst offenders with lighter alternatives or a few lines of theme code. Fewer plugins means fewer queries, a smaller attack surface, and less that can break on the next update.
Cache aggressively, at every layer
Caching is where a slow site becomes a fast one. Page caching serves static HTML to logged-out visitors so PHP and MySQL never run for the common case; object caching (Redis) keeps repeated database lookups in memory; and a CDN puts assets on a server near the visitor rather than halfway around the world. Add sensible browser-cache headers on top, and a page that once took most of a second to build is served in tens of milliseconds.
Mind the server and the database
Even a lean site is capped by where it lives. Running a current PHP version,
giving it enough memory, and choosing a host that is not overloaded all move Time
to First Byte directly. On the database side, a bloated autoloaded wp_options
table, years of orphaned post revisions, and stale transients left behind by
plugins quietly tax every single query. We clean these up — and set things up so
they stay clean.
What actually moved the needle
On a recent build, two changes did most of the work: deferring non-critical JavaScript and serving correctly-sized, modern-format images. A caching layer and a PHP version bump handled the rest. We did not guess at that order — the baseline told us where the time was going, so we spent the effort where it paid off. That is the whole point: a halved load time is rarely one heroic fix. It is four or five measured ones, applied in the right sequence.
If your site feels sluggish, the fastest route to a faster site is finding out exactly what is costing you the seconds. Diagnosing and fixing that is the core of our WordPress performance work — and it usually pays for itself in the visitors who no longer leave before the page loads.