When a client tells me their WordPress site is slow, they’ve usually already installed two or three speed plugins. Often that made it worse. Two caching plugins fight each other, an “optimise everything” setting breaks the menu, and the score barely moves.
This WordPress speed optimization checklist is the order I actually work in. It starts with measuring the right pages, moves through hosting, images, scripts and fonts, and ends with proof that the changes worked for real visitors, not just in one lucky test.
Speed work isn’t about adding tools. It’s about finding the three or four things actually costing seconds on your site, fixing those without breaking the design, and leaving the rest alone.
Short version
- Measure key templates on mobile, and trust Search Console field data over a single lab score.
- Fix server response first. No front-end trick can hide a slow server.
- The hero image is usually your Largest Contentful Paint. Never lazy load it.
- One caching plugin, configured for your host. Never two.
- Every plugin, script and font weight has to earn its place.
- Field data updates over 28 days, so judge results after a month, not an afternoon.
Core Web Vitals in plain English
Google measures page experience with three Core Web Vitals. A page passes when at least 75% of real visits meet the “good” threshold for all three:
| Metric | What it measures | Good | Poor | Usual WordPress cause |
|---|---|---|---|---|
| LCP, Largest Contentful Paint | How long until the main content, usually the hero image or heading, is visible | 2.5 s or less | Over 4 s | Slow server, heavy or lazy loaded hero image, render-blocking CSS |
| INP, Interaction to Next Paint | How quickly the page responds when someone taps or clicks | 200 ms or less | Over 500 ms | Too much JavaScript: sliders, chat widgets, tracking, add-on packs |
| CLS, Cumulative Layout Shift | How much the layout jumps while loading | 0.1 or less | Over 0.25 | Images without dimensions, late-loading fonts, banners injected at the top |
Keep these three in mind for the rest of the checklist. Almost every fix below exists to move one of them.
Step 1: Measure before you change anything
Every WordPress speed optimization checklist should start here, and most skip it. Without a baseline you can’t tell which change helped, which did nothing, and which made things worse.
1. Pick the templates that matter
Don’t only test the homepage. Choose one page of each type: the homepage, a service or landing page, a blog post, and for stores a product page and a category page. Most visitors land on these, not the homepage.
2. Start with field data
Open the Core Web Vitals report in Search Console, or the top section of PageSpeed Insights labelled with real-user experience. This is data from actual Chrome visitors over the last 28 days, and it’s what Google uses. Lab scores are a diagnostic tool, not the goal.
3. Run lab tests on mobile
Run PageSpeed Insights on each template, mobile first. Note three things: the LCP time, which element is the LCP (the report tells you), and the server response time. For a deeper look, a WebPageTest waterfall shows exactly what loads, in what order, and what blocks the page.
Pro move: run each lab test three times and use the middle result. Lab scores swing between runs, and one bad or lucky test sends you in the wrong direction.
4. Write the baseline down
A simple sheet is enough: page, LCP, INP from field data, CLS, server response, total page weight and number of requests. You’ll come back to it in Step 9.
Step 2: Fix hosting and server response
If the server takes two seconds to answer, nothing you do to images or scripts can make the page fast. So I check this first, even though I recommend changing hosts last.
5. Check Time to First Byte
Time to First Byte is how long the browser waits before the server starts sending the page. Google’s guidance treats 0.8 seconds or less as good. If yours is well above that on cached pages, the bottleneck is the server or the caching setup.
6. Use a current PHP version and an object cache
Ask your host or check the panel: WordPress should run on a currently supported PHP version. For dynamic sites, such as stores, membership sites or busy blogs, a persistent object cache like Redis cuts repeated database queries.
7. Set up one page cache that matches your server
Page caching serves a ready-made HTML copy instead of building the page on every visit. Match the tool to the server:
| Your hosting | Use |
|---|---|
| LiteSpeed server | LiteSpeed Cache plugin |
| Managed WordPress host with built-in caching | The host’s cache, plus an optimisation plugin with its caching turned off |
| Standard Apache or Nginx shared hosting | WP Rocket or a similar page cache plugin |
Watch out: never run two page caching plugins at once. It’s one of the most common causes of broken layouts, stale content and slower pages that I find on client sites.
8. Add a CDN when your audience is spread out
A content delivery network serves files from a location close to each visitor. It helps most when your visitors are far from your server, for example a UK business hosted in the USA. For a local business with a nearby server, it’s a smaller win.
Step 3: Fix images and the LCP element
On most sites I work on, images are the biggest single win, and the hero image is usually the LCP element.
9. Find your LCP element
PageSpeed Insights names it in the diagnostics. It’s usually the hero image, sometimes the main heading or a background image set in CSS.
10. Load the hero first, never lazy
Lazy loading is great for images further down the page and harmful for the first one. If the hero is lazy loaded, the browser waits to discover it. Exclude it from lazy loading and give it a high fetch priority:
<img src="hero.webp" width="1600" height="900"
fetchpriority="high" alt="...">Most caching and optimisation plugins have a setting to exclude the first images from lazy loading. Use it.
11. Serve modern formats at the right size
Convert images to WebP or AVIF, and upload them at roughly the size they’re displayed. A 4000-pixel photo straight from a camera shown at 800 pixels wide wastes most of what the visitor downloads. WordPress creates smaller sizes automatically; make sure your theme or builder uses them.
12. Give every image a width and height
When images have width and height attributes, the browser reserves the space before they load and the layout doesn’t jump. This is one of the quickest CLS fixes there is.
Step 4: Cut CSS and JavaScript
This is where INP problems usually live. Every plugin that adds front-end features adds scripts, and many load them on every page whether they’re needed or not.
13. Audit your plugins
List every active plugin and ask what it does on the front end. Delete the ones you no longer use. For the rest, Query Monitor and the Coverage tab in Chrome DevTools show which scripts and styles each page loads.
14. Load scripts only where they’re needed
A slider plugin that loads its files on every page when only the homepage has a slider is a classic waste. A contact form plugin loading on every blog post is another. Asset managers such as Perfmatters or Asset CleanUp let you switch scripts off per page or per post type.
15. Defer or delay non-critical JavaScript
Scripts that aren’t needed for the first screen, such as chat widgets, some analytics and social embeds, can be deferred or delayed until the visitor interacts. Most optimisation plugins offer this. Test carefully afterwards, because delaying the wrong script can break menus or forms.
16. Remove unused CSS, carefully
“Remove unused CSS” features can make a big difference on heavy themes and builders. They can also strip styles that only appear after an interaction, such as an open mobile menu. Turn it on, then click through every interactive element on mobile before you call it done.
17. Set a budget for third-party scripts
Tag managers, heatmaps, chat, review widgets and ad pixels add up fast. Decide which ones earn their place and remove the rest. The quickest third-party script is the one you don’t load.
Rather hand this over? I’ll measure, fix and send you a before and after report.
Step 5: Load fonts sensibly
18. Host fonts locally, load fewer weights, preload the main one
- Host Google Fonts on your own server instead of loading them from Google. OMGF does this automatically.
- Load only the weights you use. Many sites load eight or nine weights and use three.
- Preload the main body font file so text appears quickly.
- Use
font-display: swapso text shows in a fallback font instead of staying invisible.
Step 6: Elementor and page builder fixes
Elementor isn’t slow by itself. Old layouts, too many add-ons and heavy effects are. Most of my builds are Elementor, so this step gets its own section.
19. Use containers and turn on the performance features
Flexbox containers produce much less HTML than the old section and column structure. On older sites, converting the heaviest pages is worth it. Then review the performance options in Elementor’s settings, such as improved asset loading, and switch on the ones your site supports.
20. Keep add-on packs to a minimum
Each add-on pack loads its own styles and scripts, often on every page. If you only use two widgets from a pack of eighty, either disable the unused widgets in its settings or rebuild those two with core Elementor widgets.
21. Go easy above the fold
Sliders, entrance animations and video backgrounds on the first screen delay LCP and hurt INP. A strong static hero with one clear message usually converts better anyway. If you’re rebuilding repeated sections at the same time, my guide to Elementor global templates keeps the CSS lean as the site grows.
Step 7: WooCommerce fixes
22. Handle cart fragments
WooCommerce uses a script called cart fragments to update the mini cart without reloading the page. Recent WooCommerce versions only load it where the mini cart needs it, but older setups and some themes still load it everywhere. If your pages make an AJAX request on every visit, this is often why.
23. Exclude the right pages from cache
Cart, checkout and my account pages must never be served from the page cache. Good caching plugins exclude them automatically, but check, especially after changing caching tools.
24. Watch filters and product images
Product filter plugins can be heavy on large catalogues. Test category pages with filters applied, not just plain. And product galleries are image-heavy by nature, so Step 3 matters double here. On WooCommerce builds such as The Ice Butcher’s catalogue, category and product pages are the templates I test first.
Step 8: Clean the database
25. Remove the clutter, after a backup
- Old post revisions, auto drafts and trashed posts
- Expired transients
- Leftover tables and options from deleted plugins
- Large autoloaded options, which load on every single page request
Watch out: always take a full backup before a database cleanup. Deleting the wrong option can break a plugin, and some “cleaner” plugins are aggressive by default.
26. Limit revisions going forward
Adding define( 'WP_POST_REVISIONS', 10 ); to wp-config.php keeps the last ten revisions of each post instead of every single one.
Step 9: Verify and keep it fast
27. Retest the same pages the same way
Run the same tests on the same templates and fill in the “after” column of your baseline sheet. Then click through the site on a real phone. A faster site that broke the mobile menu isn’t a win.
28. Wait for the field data
Search Console and the real-user section in PageSpeed Insights use a rolling 28-day window. Lab scores improve straight away; field data catches up over the next few weeks. Judge the result after a month.
29. Make it a monthly routine
Speed slowly decays as plugins update and content grows. Once a month: check the Core Web Vitals report, test your key templates, and review any plugin added since last time.
WordPress speed optimization checklist: the usual culprits at a glance
| Symptom | Likely cause | Fix in this checklist |
|---|---|---|
| Everything is slow, even cached pages | Slow server or no page cache | Steps 5 to 7 |
| LCP over 4 seconds on mobile | Heavy or lazy loaded hero image | Steps 9 to 11 |
| Page jumps while loading | Images without dimensions, late fonts | Steps 12 and 18 |
| Taps feel laggy, poor INP | Too much JavaScript | Steps 13 to 17 |
| Store pages slow, rest of site fine | Cart fragments, filters, uncached product pages | Steps 22 to 24 |
| Admin dashboard slow | Database bloat, heavy plugins | Steps 13 and 25 |
Speed is also part of a good launch. If you’re about to go live with a new site, run it alongside my WordPress website launch checklist. For an existing site, work through this WordPress speed optimization checklist once, then repeat Step 9 every month.
Stuck on a step, or not sure which fix applies to your site? Tell me which page is slow and I’ll point you to the first thing I’d check.
Keep reading
Frequently asked questions
What is a good PageSpeed score for WordPress?
Focus less on the score and more on passing Core Web Vitals for real visitors, which you can see in Search Console. Lab scores change between tests, while field data is what Google uses.
Which Core Web Vital should I fix first?
Usually Largest Contentful Paint, because it’s often caused by a heavy or lazy loaded hero image or a slow server, and fixing it makes the whole site feel faster straight away.
Can I run two caching plugins at the same time?
No. Two page caching plugins fight each other and often cause broken layouts, stale content and slower pages. Use one that matches your server.
Do I need to change hosting to speed up WordPress?
Not always. Fix caching, images, scripts and fonts first. If server response is still slow on cached pages after that, the hosting is the bottleneck and moving is worth it.
Is Elementor bad for page speed?
Not by itself. Old section and column layouts, too many add-on packs and heavy effects above the fold are the usual problems. A clean Elementor build with containers can be fast.
How long until speed improvements show in Search Console?
Field data uses a rolling 28-day window, so expect the Core Web Vitals report to catch up over about a month. Lab tests show the change immediately.
$ need --help
Need this done on your site?
Tell me what is going on. I reply within one business day.
