Most WordPress performance guides hand you a checklist and call it a day. Install this plugin, tick that box, done. What they skip is the why — and without understanding why, you’re just clicking buttons and hoping. This walkthrough is different. I’m going to take you through the full picture: what actually slows a WordPress site down, where to look first, and what to do about it — in the right order.

Whether you’re a site owner who wants to understand what’s happening under the hood, or a developer looking for a structured approach you can hand to a client, this is written for both of you.

Let’s get into it.

First, Understand What “Performance” Actually Means

Before you touch a single setting, understand what you’re measuring. WordPress performance comes down to three things:

Load time — how long before the page is usable. Core Web Vitals — Google’s specific scoring criteria that affect your search ranking. Perceived performance — how fast the site feels, which isn’t always the same as how fast it actually is.

Google’s Core Web Vitals are the ones that matter most right now:

• LCP (Largest Contentful Paint) — how quickly the largest visible element (usually a hero image or heading) renders. Target: under 2.5 seconds.
• INP (Interaction to Next Paint) — how responsive the page feels when a user clicks or taps. Target: under 200ms. This replaced FID (First Input Delay) in 2024.
• CLS (Cumulative Layout Shift) — how much the layout jumps around while loading. Target: under 0.1.

You can check all three at PageSpeed Insights — just paste your URL and run the test. Do this before you change anything. You need a baseline.

Step 1 — Choose the Right Hosting Foundation

No amount of plugin wizardry fixes bad hosting. This is the most underrated variable in WordPress performance, and it’s the first thing I check when a client comes to me with a slow site.

Shared hosting puts your site on a server with hundreds (sometimes thousands) of other websites. When one of them gets a traffic spike, your site slows down too. You have no control over this.

What to look for instead:

• EasyWP by Namecheap — this is what I personally use and recommend to most clients. It’s managed WordPress hosting built on a fast infrastructure, beginner-friendly, and genuinely affordable without sacrificing the performance headroom you need. It also runs on Nginx, which handles WordPress well.
• Other managed WordPress options (Kinsta, WP Engine, Cloudways) — well-regarded in the community and worth considering for larger or more complex sites, though I haven’t worked with them directly. Each has built-in caching, staging environments, and WordPress-specific infrastructure.
• LiteSpeed servers — the web server software matters. LiteSpeed consistently outperforms Apache and Nginx for WordPress, especially when paired with the LiteSpeed Cache plugin. Worth checking what your host runs before choosing a cache plugin.

If you’re on shared hosting and your PageSpeed score is under 60 on mobile, seriously consider migrating before doing anything else. You’ll be optimising on a leaking foundation otherwise.

For developers: Check server response time (TTFB — Time to First Byte). Anything above 600ms is a hosting problem, not a code problem. Use WebPageTest to isolate TTFB from total load time.

Step 2 — Install a Caching Plugin

WordPress is dynamic by default — every page request triggers PHP execution and database queries. Caching saves the finished HTML output so the server can skip all that work for repeat visitors.

This single change can cut load times by 50–70% on most sites.

Recommended plugins:

• WP Rocket — premium, beginner-friendly, handles caching, minification, lazy loading, and more from one interface. Worth the cost if you don’t want to think about configuration.
• LiteSpeed Cache — free, extremely powerful, but only works on LiteSpeed servers. If your host runs LiteSpeed, use this.
• W3 Total Cache / WP Super Cache — free options that work on any host. More configuration required.

Basic cache settings to enable:

1. Page cache (generates static HTML files)
2. Browser caching (tells visitors’ browsers to store static assets locally)
3. Object caching (caches database query results — requires Redis or Memcached, usually a hosting feature)

After enabling caching, test your site in an incognito window (to bypass your own browser cache) and re-run PageSpeed Insights. You should see a measurable improvement immediately.

One thing to watch: caching and WooCommerce/membership sites need careful configuration. Cart pages, checkout, and account pages should be excluded from page cache, or logged-in users will see stale content. Most premium cache plugins handle this automatically, but always verify.

Step 3 — Optimise Your Images

Images are almost always the single largest contributor to page weight. On an unoptimised site, a single hero image can be 3–5MB. It should be under 200KB.

There are three dimensions to image optimisation:

3a. Compression

Remove data from image files without visibly degrading quality. Tools and plugins that handle this:

• Imagify — my go-to. Compresses images on upload, handles WebP conversion, and lets you bulk-compress your existing library. The free tier covers a reasonable volume; the paid plan is worth it once your site grows.
• Convert for Media — a solid free alternative for bulk conversion and compression, especially if you want to convert an existing library to WebP without spending anything. Does the job cleanly.
• Target: JPEG under 150KB for standard images, WebP format where possible

3b. Next-Gen Formats

WebP files are 25–35% smaller than equivalent JPEGs and PNGs. Most modern caching plugins and image optimisation plugins can serve WebP automatically with a JPEG fallback for older browsers. Enable this.

3c. Lazy Loading

Don’t load images that are below the fold until the user scrolls to them. WordPress has had native lazy loading since version 5.5 — it’s on by default for images using the standard <img> tag. If you’re using a page builder, check that it’s not overriding this.

The one image you should NOT lazy load: your hero image (the largest above-the-fold image). Lazy loading it actually hurts your LCP score. Make sure your hero image loads eagerly and is properly sized for both desktop and mobile.

For developers: Use the loading=”eager” attribute on hero images and implement <picture> elements with srcset for responsive image delivery. This ensures the browser downloads the right image size for the device — not a 2400px image on a 390px phone screen.

Step 4 — Minify and Combine CSS & JavaScript

Every CSS and JS file your site loads is a separate HTTP request. Minification removes whitespace, comments, and unnecessary characters from these files. Combining merges multiple files into one.

Most caching plugins include these features. The settings to look for:

• Minify CSS — enable
• Minify JavaScript — enable, but test thoroughly after. Aggressive JS minification can break functionality.
• Combine CSS — can improve performance, but test. Some page builders don’t handle this well.
• Defer or async JavaScript — non-critical JS should be deferred so it doesn’t block page rendering

A word of caution: don’t enable everything at once. Enable one setting, clear cache, test the front end, then move to the next. When something breaks — and something eventually will — you’ll know exactly what caused it.

For developers: Use the browser’s Network tab in DevTools (Chrome or Firefox) to audit what’s loading, in what order, and how large each file is. Look for render-blocking resources — scripts or stylesheets loading in the <head> without async or defer attributes.

Step 5 — Set Up a Content Delivery Network (CDN)

A CDN stores copies of your static assets (images, CSS, JS, fonts) on servers around the world. When someone in London visits your Lagos-hosted site, they download assets from a nearby CDN node instead of all the way across the Atlantic.

This is especially important if you have international visitors or clients.

Options:

• Cloudflare — free tier is genuinely useful. Proxies your traffic, provides CDN, DDoS protection, and browser caching headers. It’s what I use on most client sites.
• BunnyCDN — affordable, fast, easy to integrate with most caching plugins
• KeyCDN — pay-as-you-go, solid performance

If you’re on Cloudflare, enable “Auto Minify” for HTML, CSS, and JS in the Speed settings. Also enable “Rocket Loader” with caution — test it, as it can occasionally conflict with certain scripts.

For developers: Configure proper cache headers on your origin server so the CDN knows how long to cache different asset types. Static assets (images, fonts, CSS) should have long cache lifetimes (1 year). HTML should be short or no-cache.

Step 6 — Clean Up Your Database

A note for site owners: From this step onward, some of the optimisations involve settings and configurations that are best handled by someone familiar with WordPress internals. As a site owner, the plugin-based steps below are safe to follow on your own — but anything involving code edits, file access, or server configuration should be left to your developer. The good news: if you’ve worked through Steps 1–5 carefully, your site is already significantly faster. Steps 6–9 are the fine-tuning layer, not the foundation.

WordPress stores everything in its database — posts, pages, settings, revisions, transients, plugin data. Over time, this accumulates garbage: post revisions running into the hundreds, spam comments, orphaned metadata, expired transients.

A bloated database means slower queries, which means slower page loads.

What to clean:

• Post revisions (WordPress saves a new revision every time you update a post — limit this to 3–5 max)
• Spam and trashed comments
• Expired transients
• Orphaned post metadata (left behind by deleted plugins)
• Unused tables from uninstalled plugins

Plugins for this (site owners: start here):

• WP-Optimize — scheduled database cleaning and table optimisation. Install it, run the cleanup, and set a schedule so it maintains itself.
• Advanced Database Cleaner — more granular control and orphan detection. Better suited if you want more visibility into what’s being removed.

After cleaning, run the “Optimize tables” function inside either plugin. Think of it as a tidy-up that reorganises how data is stored for faster access — no technical knowledge required, just a button click.

For developers: Limit post revisions at the config level rather than relying solely on periodic cleanup:

// In wp-config.php

define(‘WP_POST_REVISIONS’, 5);

Step 7 — Audit and Trim Your Plugins

Every plugin you install adds code that runs on every page load. Some plugins add multiple CSS and JS files even on pages where they’re not needed. A site with 30+ active plugins almost always has performance issues rooted in plugin overhead.

The audit process (any site owner can do this):

1. Go to Plugins → Installed Plugins in your WordPress dashboard
2. Deactivate and delete anything you’re not actively using — old, forgotten plugins still consume resources even when inactive
3. For plugins you keep, make sure they’re updated. Outdated plugins are a performance and security risk.

That alone makes a difference. You don’t need to understand what each plugin loads — just removing what’s unnecessary is enough at this stage.

For developers: Go deeper with Query Monitor — it shows database queries, hooks, and scripts loaded per page, making it straightforward to identify which plugins are contributing the most overhead. Asset CleanUp lets you disable specific CSS/JS files on pages where they’re not needed — useful for contact form plugins that load scripts site-wide even on pages without a form.

Step 8 — Optimise Google Fonts Loading

Google Fonts are used on the majority of WordPress sites and are consistently one of the top performance issues I find in audits.

The problem: by default, Google Fonts load from Google’s servers, which adds an external DNS lookup and connection overhead. They also often cause a Flash of Invisible Text (FOIT) or Flash of Unstyled Text (FOUT) while loading — that momentary flicker you sometimes see when a page loads.

For site owners: the simplest fix is already built into most caching and performance plugins. In WP Rocket, for example, look for the “Fonts” tab and enable “Optimize Google Fonts loading.” In LiteSpeed Cache, it’s under the Page Optimization settings. Enable it, clear your cache, and check PageSpeed Insights again — the “Eliminate render-blocking resources” warning related to fonts should reduce or disappear.

If you’re not sure whether your plugin handles this, search for “Google Fonts” inside your performance plugin settings. Most modern ones do.

For developers: Full control means self-hosting the font files — download them via google-webfonts-helper, upload to the server, and serve locally to eliminate the external request entirely. Add font-display: swap to prevent FOIT. If remaining on Google’s CDN, at minimum add preconnect hints in the <head>:

<link rel=”preconnect” href=”https://fonts.googleapis.com”>

<link rel=”preconnect” href=”https://fonts.gstatic.com” crossorigin>

Step 9 — Fix Your Core Web Vitals Specifically

By this point, your general performance should be significantly improved. Now it’s time to address the specific metrics Google is scoring you on — LCP, INP, and CLS.

For site owners: you don’t need to understand the mechanics deeply to act on them. Here’s what you can do directly:

• LCP (how fast your main content appears): make sure your hero image is compressed as small as possible while still looking sharp. If PageSpeed flags it, it’s almost always an image size issue first.
• INP (how responsive your site feels to clicks): if this score is poor, it’s usually caused by a heavy third-party script — a chat widget, social media embed, or analytics tool loading too early. Disable them one at a time and re-test to find the culprit, or flag it for your developer.
• CLS (layout jumping while the page loads): this often comes from images without defined dimensions, or a font loading in and shifting text. Your performance plugin’s font optimisation (Step 8) addresses the font side. For images, make sure you’re always setting a width and height when uploading through your page builder.

If your scores are still struggling after working through this guide, this is the point where bringing in a developer to do a proper audit pays off — the issues at this stage are specific to your site and need hands-on diagnosis.

For developers: Preload the LCP image explicitly: <link rel=”preload” as=”image” href=”hero.webp”>. For INP, use the Chrome DevTools Performance tab to identify long tasks (anything over 50ms) and defer or break them up. For CLS, audit fonts with font-display: swap and ensure fallback fonts have matching metrics to minimise reflow. CrUX data in PageSpeed reflects real-world user experience — always check the Field Data tab, not just the lab score.

Step 10 — Monitor, Don’t Set and Forget

Performance degrades over time. New plugins get installed, the media library fills up, theme updates change what loads. Without monitoring, you won’t notice until Google tells you via a drop in rankings.

What to track:

• PageSpeed Insights score — run it monthly on your key pages
• Core Web Vitals in Google Search Console — this shows real-world data for your actual visitors, flagged by page
• Uptime and response time — tools like UptimeRobot (free) or Better Uptime alert you when something goes wrong

Set a reminder to run a full audit every quarter. It takes less than an hour if you’ve followed the steps in this guide, and it keeps your site where it should be.

Putting It All Together

Here’s the order of operations in summary:

1. Baseline — run PageSpeed Insights, note your scores
2. Hosting — verify you’re not on an undersized shared server
3. Caching — install and configure a caching plugin
4. Images — compress, convert to WebP, enable lazy loading (exclude hero)
5. CSS/JS — minify, defer non-critical scripts
6. CDN — set up Cloudflare or similar
7. Database — clean and optimise
8. Plugins — audit, remove, restrict asset loading
9. Fonts — self-host or preconnect
10. Core Web Vitals — target LCP, INP, CLS specifically
11. Monitor — ongoing, quarterly at minimum

You don’t need to do all of this in one sitting. The first three steps alone will produce a visible improvement on most sites. Work through the list progressively and test after each change.

Final Thought

A fast website isn’t a luxury — it’s a baseline expectation. Google factors Core Web Vitals into rankings. Visitors leave slow sites. And on mobile, especially with patchy connections, every second counts.

If you work through this guide and still can’t get your scores where they need to be, the bottleneck is usually one of three things: hosting that needs upgrading, a theme with poorly-written code, or a plugin conflict that requires proper diagnosis. Those are fixable — they just need a more hands-on approach.

If you’d like me to look at your site specifically, I offer performance audits as part of my WordPress services. You can reach me at edward@enigmaking.online or request an audit directly at enigmaking.online/audit.