I have done WordPress speed optimization on a lot of sites, and the boring truth is that the same dozen problems show up almost every time. It is very rarely one mysterious thing. It is a large hero image, a plugin loading a slider script on every page, a font served from a third party, and hosting that was chosen on price alone — all stacked on top of each other.
This checklist is in the order I actually work through a site, from biggest impact to smallest. Do the first five and most sites go from “slow” to “fine”. Do all twelve and you will have a site that loads in one to two seconds on a phone, which is what your visitors — and Google’s Core Web Vitals — care about.
First, measure the right thing
Before changing anything, open PageSpeed Insights, test your home page and your most important service page on mobile, and write down three numbers: Largest Contentful Paint (LCP), Interaction to Next Paint (INP) and Cumulative Layout Shift (CLS). Ignore the overall score for now; it is a summary that hides what to fix. The thresholds Google uses are LCP under 2.5 seconds, INP under 200 milliseconds, CLS under 0.1. I go into what each one means in the Core Web Vitals work I do; for now, they are your before-and-after.
The checklist, in order of impact
-
Hosting that runs PHP fast and has a server-level cache.
Nothing else on this list can rescue a slow server. Look for a host with recent PHP (8.2 or newer), NVMe storage, and a server cache such as LiteSpeed or Nginx FastCGI cache. A response time (TTFB) under 400 ms for an uncached page is the sign of a healthy server. If yours is over a second on a quiet site, moving hosts is the single largest improvement available.
-
Page caching that actually hits.
Install the cache that matches the server — LiteSpeed Cache on LiteSpeed hosts, the host’s own tool on managed platforms. Then verify it: load a page twice and check the response headers for a cache hit. I regularly find caching plugins that are installed, configured and not caching anything because of a stray “no-cache” header or a cookie. A cache that misses is worse than none, because you think the job is done.
-
Images: right size, modern format, lazy below the fold.
This is the biggest win on most sites. Export images at the size they are displayed (a 400-pixel card does not need a 3000-pixel file), convert to WebP, and let WordPress lazy-load anything below the fold — it does this by default now. The hero image is the exception: it should load eagerly with a high fetch priority, because it is usually your LCP element. On a portfolio site I recently converted 400 MB of PNG screenshots to WebP; the pages became eight times lighter with no visible change.
-
Fonts: self-host, subset, two families maximum.
Google Fonts loaded from Google’s servers costs an extra connection and, in some jurisdictions, a privacy concern. Download the WOFF2 files, serve them from your own domain, preload the one used in the headline, and use
font-display: swap. Two families is plenty; each extra weight is another file. -
Plugins: remove, do not just deactivate.
Every plugin is code that runs on every request, and many load CSS and JavaScript on pages that do not use them. Audit the list honestly. Sliders, social feed embeds, page builders you no longer use, “all-in-one” toolkits with thirty modules — each one is a candidate. Fewer plugins also means fewer updates and fewer security holes.
-
Scripts: defer what is not needed for the first paint.
Analytics, chat widgets, pixels, embedded videos and maps should load after the page is usable, not before. Most caching plugins can defer or delay JavaScript; Google Tag Manager can hold tags until interaction. Embedded YouTube videos deserve special mention: a single embed can add over half a megabyte; use a facade (a thumbnail that loads the player on click).
-
CSS: stop loading the whole builder on every page.
Page builders ship a lot of CSS. Elementor’s “improved asset loading” and per-widget CSS settings help; so does removing unused addon packs. If you use Elementor, my separate note on fixing a slow Elementor site lists the specific settings.
-
Database: clean revisions, transients and orphaned data.
Years of post revisions, expired transients and leftover tables from removed plugins slow queries on every page. Limit revisions in
wp-config.php, clean expired transients, and drop tables from plugins you deleted. Do this after a backup; it is routine but not reversible without one. -
Object cache for dynamic sites.
If your site has logged-in users, a store or a membership area, page caching cannot help those visitors. An object cache (Redis or Memcached, offered by most good hosts) speeds up the database queries behind every uncached page. For a simple brochure site, skip this.
-
CDN, if your visitors are far from your server.
A CDN serves images, CSS and scripts from a location near the visitor. It matters when you serve multiple countries or when the host is far from your customers. Many hosts include one; enabling it is usually a switch.
-
Third-party embeds and tracking: audit quarterly.
Pixels, heatmaps, chat tools and review widgets accumulate. Each one adds requests to another domain. Keep the ones you act on; remove the ones you installed “to see”. A quarterly review takes ten minutes.
-
Layout stability: fixed dimensions for images and ads.
CLS — content jumping while the page loads — is caused by images without width and height attributes, fonts swapping late, and elements injected above existing content. Give every image its dimensions (WordPress does this for media-library images), preload the headline font, and reserve space for anything that loads late.
What each fix is worth, roughly
| Fix | Typical LCP improvement | Effort |
|---|---|---|
| Better hosting + server cache | 0.5–2.0 s | Half a day (migration) |
| Page cache that hits | 0.3–1.5 s | 1 hour |
| Right-sized WebP images, eager hero | 0.5–2.0 s | 2–4 hours |
| Self-hosted, preloaded fonts | 0.2–0.5 s | 1 hour |
| Plugin audit | 0.2–1.0 s | 1–2 hours |
| Deferred scripts and embeds | 0.2–0.8 s (and big INP gains) | 1–2 hours |
| Database cleanup | 0–0.3 s (more on uncached pages) | 30 minutes |
Ranges are from sites I have worked on; yours will vary. The pattern does not: hosting, caching and images account for most of the difference between a slow site and a fast one.
Things that do not help (and sometimes hurt)
- Stacking optimization plugins. Two caching plugins fight. One good one, configured, beats three.
- Minifying everything blindly. Combining all CSS and JS into one file was good advice in 2015. With HTTP/2 it can make first paint slower. Minify, but do not combine unless you test it.
- Chasing a 100 score. The last ten points usually cost more than they return. A real site with real tracking will sit in the 85–95 range and be fast for every human visitor.
- “Speed” themes that strip your design. The theme is rarely the bottleneck; the images and plugins on top of it are.
Check that it worked
Re-run PageSpeed Insights on the same two pages, mobile. Then look at the field data at the top of the report — “Discover what your real users are experiencing” — if your site has enough traffic to show it. Lab numbers prove a fix; field numbers prove it held. Give it a month and check again.
If you only do one thing Convert and right-size your images, and make sure the hero loads eagerly. On most small business sites that alone moves LCP by a second or more.
Further reading: Web Vitals (web.dev).
FAQ
What is a good load time for a WordPress website?
Aim for the main content to appear within 2.5 seconds on a mid-range phone over 4G — that is Google’s Largest Contentful Paint threshold. On a decent host with caching and right-sized images, most business sites can reach 1–2 seconds.
Which WordPress caching plugin is best?
The one that matches your server. On LiteSpeed hosting, LiteSpeed Cache. On Nginx hosts with their own cache, use the host’s tool. Only add a generic caching plugin when the host provides nothing.
Do I need a CDN for a small business site?
If your customers are in one country and your host is there too, a CDN adds little. If you serve several regions, or the host is far from your customers, it helps noticeably. Many hosts include one.
Does Elementor make WordPress slow?
Elementor adds weight, but a well-built Elementor site loads in under two seconds. The slow ones usually have unoptimized images, too many addon plugins and no caching — the same problems any WordPress site can have.
Want the checklist done for you, with before-and-after numbers? Request a free speed audit — I will tell you which three items on this list are costing you the most before any work starts.
