ammarmahdi.com online
YYC

How to actually speed up a WordPress site

4 min read

Start by measuring, then fix the biggest thing, then measure again. Most WordPress sites are slow for two or three specific reasons, not a hundred small ones. If you chase every tip on the internet at once you will waste a weekend and still not know what helped.

Here is the order I work in when a site lands on my desk slow.

First, measure on a real page

Run the actual page a visitor would hit, not the homepage you have cached in your browser. I use two tools together:

  • PageSpeed Insights for the lab score and, more importantly, the field data from real Chrome users.
  • The Network panel in Chrome DevTools to see what is actually loading and how big it is.

You are looking at three numbers, the Core Web Vitals. Google’s “good” thresholds, measured at the 75th percentile of your real visitors, are:

  • LCP (Largest Contentful Paint) under 2.5 seconds.
  • INP (Interaction to Next Paint) under 200 milliseconds. INP replaced FID as a Core Web Vital in March 2024.
  • CLS (Cumulative Layout Shift) under 0.1.

Write these three numbers down before you touch anything. You cannot tell if a change helped if you never recorded where you started.

Fix hosting before you fix anything else

You cannot cache your way out of a slow server. If your time to first byte is over half a second on a warm cache, the host is the problem.

Cheap shared hosting puts hundreds of sites on one machine and hopes none of them get busy at the same time. For a client site that matters, I want managed WordPress hosting or a decent VPS with real CPU and memory. This single change often does more than every plugin tweak combined.

Add caching, in the right layers

Caching means doing expensive work once and reusing the result. WordPress needs it in a few places:

  • Page caching turns a dynamic PHP page into a static HTML file. This is the big one. A good caching plugin or server-level cache will cut your server response time dramatically.
  • Object caching with Redis stores the results of database queries in memory. This helps logged-in pages and busy sites where page caching cannot do everything.
  • Browser caching tells the visitor’s browser to keep your images, CSS, and JavaScript so the second page loads almost instantly. Set long cache lifetimes on assets that have a version in the filename.

Images are usually the largest thing on the page

On most sites I audit, images are the biggest single download by far, and they are almost always bigger than they need to be.

  • Serve modern formats. WebP is well supported and much smaller than JPEG or PNG.
  • Serve the right size. A 3000 pixel wide photo squeezed into a 600 pixel column wastes the difference. Use responsive image sizes so phones get small files.
  • Lazy load images below the fold so the browser does not fetch them until they are needed. WordPress does this by default now, but check it is actually working.
  • Do not lazy load your LCP image, usually the hero. Lazy loading the most important image makes LCP worse, not better.

Tame the database and the plugins

WordPress stores a lot of junk over the years: post revisions, expired transients, spam comments, orphaned metadata. A bloated database makes every query slower. Clean it out and keep autoloaded options under control.

Then audit plugins honestly. Every active plugin can add queries, scripts, and styles to every page. I have seen a single poorly built plugin load its CSS and JavaScript on all 200 pages of a site when it was only used on one. Deactivate anything you are not using, and for what remains, check what it loads where.

Cut the JavaScript you do not need

JavaScript is the most expensive thing a browser does, and it is the main driver of a bad INP score. Page builders and bloated themes ship a lot of it.

  • Remove scripts that load site-wide but are only used on one page.
  • Defer or delay non-critical JavaScript so it does not block the first paint.
  • Be skeptical of any plugin that promises to “optimize” by adding more JavaScript to manage your JavaScript.

Then measure again

Make one meaningful change, clear the cache, and re-run the same page. Keep the changes that move the numbers and undo the ones that do not. Performance work is a loop, not a checklist you run once.

Fast sites are not magic. They are the result of a host that can keep up, caching in the right places, images that are not oversized, and a refusal to ship JavaScript nobody asked for. Get those four right and you are most of the way to green.

If you want to go deeper on the three metrics themselves, I wrote a follow-up on Core Web Vitals for WordPress.