A slow site costs you twice. Visitors leave before the page appears, and Google treats slow pages as a worse result. Paid ads suffer too, because a slow landing page wastes clicks you already paid for.
Most slow WordPress sites I see have the same handful of problems. This is the WordPress speed checklist I work through on client sites, in order. The order matters, because the early steps usually fix the most.
1. Measure before you touch anything
Run the page through PageSpeed Insights and look at the mobile result first. Note the three Core Web Vitals and Google’s thresholds for a good result, judged at the 75th percentile of real visits:
- LCP (Largest Contentful Paint): how long until the main content shows. Good is 2.5 seconds or less.
- CLS (Cumulative Layout Shift): how much the page jumps around while it loads. Good is 0.1 or less.
- INP (Interaction to Next Paint): how quickly the page reacts when someone taps or clicks. Good is 200 milliseconds or less.
Field data at the top of the PageSpeed Insights report is what real Chrome users experienced over the previous 28 days, and the pass or fail verdict comes from it. The lab data below is one simulated load on a mid-range phone: good for diagnosis, but not what your visitors felt.
Low-traffic pages often have no field data, so lean on the lab numbers and Search Console’s Core Web Vitals report. Test three templates, not just the home page, and save every report. You want a before-and-after comparison, not a feeling.
2. Caching
Page caching serves a ready-made copy of each page instead of building it with PHP on every visit. If your host runs LiteSpeed, use LiteSpeed Cache. Elsewhere, use the caching the host recommends, and never run two page caches at once.
Tools > Site Health confirms it’s working: WordPress reports whether it detects a page cache and the median server response time, and flags anything over 600 milliseconds.
Then turn on CSS and JavaScript optimization one setting at a time, testing after each, because some settings break sliders, forms or animations. In LiteSpeed Cache’s Page Optimization, I set Load JS Deferred to Deferred. Delayed can score better, but it holds scripts until the visitor interacts, which is where menus and forms break.
Stores also gain from an object cache such as Redis, and their cart and checkout pages must stay out of the page cache.
3. Images
- Convert images to WebP.
- Upload them at the size you display them, at most twice that width. WordPress only scales uploads above 2,560 pixels, far bigger than most layouts need.
- Lazy-load images below the fold, but never the main image at the top of the page.
- Give every image a width and height so the page doesn’t jump while it loads.
- Make the hero a real image rather than a CSS background, so the browser finds it sooner.
Images are often the single biggest win, especially on pages built with large hero photos. Avoid sliders at the top of the page: they load several big images to show one.
4. Fonts
Load fonts from your own server instead of an outside font service, load only the weights you actually use, and use font-display: swap so text appears straight away. Elementor has a setting to load Google Fonts locally.
Two families with two or three weights each is plenty, and inline SVG icons are far lighter than a whole icon font loaded for a few icons.
5. Plugins and scripts
Every plugin can add CSS and JavaScript to every page. Go through the list and ask of each one: does this still earn its place? Remove what you don’t use. Replace heavy plugins with lighter ones where possible, and stop chat widgets, sliders and popups from loading on pages that don’t need them.
The free Query Monitor plugin shows which plugins run slow database queries, and the Coverage panel in Chrome DevTools shows how much of each CSS and JavaScript file a page uses. Chat, video and map embeds often hurt INP the most, so load them on click where you can.
6. The database
Old revisions, expired transients and leftovers from deleted plugins slow down every query. Clean them up after taking a backup, with LiteSpeed Cache’s Database screen or a plugin such as WP-Optimize.
To cap revisions, add define( 'WP_POST_REVISIONS', 5 ); to wp-config.php. On stores, also check WooCommerce > Status > Scheduled Actions, where completed actions can quietly pile up.
7. Hosting and CDN
If the server is slow to answer before anything else happens, no plugin can fix that. That wait is Time to First Byte, and web.dev suggests aiming for 0.8 seconds or less. It isn’t a Core Web Vital, but it’s the first slice of every LCP measurement.
Check the PHP version under Tools > Site Health > Info > Server, since newer supported versions are usually faster. A CDN such as Cloudflare helps visitors far from your server. If the hosting itself is the bottleneck, the honest answer is to move, and the numbers from step 1 will show it.
8. Measure again
Run the same tests on the same pages and compare. Lab numbers change straight away. Field data is a 28-day window, so real-user results catch up over the following weeks.
Check that forms, checkout and tracking still work. Speed that breaks a form isn’t a win, and deferred scripts are a common reason a conversion tag stops firing. Here’s how I test tracking end to end.
When the numbers won’t move
- LCP is still slow. Find the LCP element in the PageSpeed Insights diagnostics. Usually it’s lazy-loaded, a CSS background, in a slider or fading in. If the server is slow too, check the cache is hitting: open the page in a private window, and in Chrome DevTools > Network the page request should show
x-litespeed-cache: hitorcf-cache-status: HIT. - CLS keeps coming back. Look for images or embeds without dimensions, a cookie bar pushing content down, or a web font swapping in at a different size.
- INP is poor. Something heavy runs on tap, like a mega menu or an add-to-cart script. Record it in the DevTools Performance panel, then trim or defer it.
- Something broke. Undo the last change, then exclude that script from defer or delay rather than switching the feature off. If the whole site goes down, here’s how to fix the WordPress critical error safely.
The WordPress speed checklist in one place
- Baseline reports saved for three templates, mobile first.
- One page cache, confirmed in Site Health and the response headers.
- CSS and JavaScript settings enabled one at a time, each tested.
- Images in WebP, sized to the layout, with width and height.
- Hero image not lazy-loaded, not a CSS background, not in a slider.
- Fonts local, only the weights in use, swap on.
- Unused plugins removed, chat and video loading only where needed.
- Database cleaned after a backup, revisions capped.
- Server response time and PHP version checked.
- Forms, checkout and tracking tested after every change.
Questions I get about WordPress speed
Do I need a score of 100 in PageSpeed Insights?
No. The score is a lab result from one simulated visit. The Core Web Vitals assessment from real visitors matters more, and a site can pass it with a score well below 100.
Which caching plugin should I use?
The one that matches your server: LiteSpeed Cache on LiteSpeed hosts, otherwise whatever your host builds in or recommends. One page cache set up carefully beats two fighting each other.
How often should I check speed?
After every big change, like a new plugin, a theme update or a redesign, and monthly otherwise. Search Console’s Core Web Vitals report is the easiest early warning.
If you’d like a second pair of eyes on your site, see my speed optimization service or ask for a free review.
