Why your WordPress site is slow, and what actually fixes it

Most slow WordPress sites are not slow for one big reason. They are slow for six or seven small ones stacked on top of each other: an oversized hero image, a theme loading scripts you never use, a chat widget, three font families, a cheap server and no caching. Fix one and nothing much changes. Fix them in the right order and the site feels completely different.

Here is the order I work through when a site lands on my desk because it has become slow.

1. Measure before you change anything

Run the page through PageSpeed Insights and look at two different things:

• Field data (the top section, when there is enough traffic). This is how real visitors experienced the site over the last 28 days. It is what Google uses.
• Lab data (the score and the list of opportunities). This is one simulated test. It is useful for finding problems, but the score moves around between runs.

The three Core Web Vitals to watch are:

• LCP (Largest Contentful Paint): how long the main content takes to appear. Good is 2.5 seconds or less.
• INP (Interaction to Next Paint): how quickly the page responds when someone taps or clicks. Good is 200 milliseconds or less.
• CLS (Cumulative Layout Shift): how much the layout jumps around while loading. Good is 0.1 or less.

Write down the numbers for your home page and your most important landing page. You will want them later to prove the changes actually worked.

2. Fix the images first

Images are still the most common reason for a slow LCP. The usual problems:

• A 4000-pixel photo straight off a camera or phone, shown in a box 1200 pixels wide.
• JPEG or PNG where WebP or AVIF would be a fraction of the size.
• The main hero image being lazy-loaded, so the browser waits before even starting to download it.

Resize images to the largest size they are actually displayed at, convert them to WebP or AVIF, and make sure lazy-loading applies to images further down the page but not to the first big image a visitor sees.

3. Turn on proper caching

Without page caching, WordPress rebuilds every page with PHP and database queries on every single visit. With it, most visitors get a ready-made HTML file.

• Use one page-caching solution. If your host runs LiteSpeed, use LiteSpeed Cache. Otherwise WP Rocket or your host’s own caching are good options. Two caching plugins fighting each other is a common cause of broken layouts.
• If the site has logged-in users or a WooCommerce store, an object cache such as Redis helps the pages that cannot be fully cached.
• Put a CDN such as Cloudflare in front if your visitors are spread across countries.

4. Cut the scripts you don’t need

This is the part caching plugins cannot fix for you. Every plugin that adds something to the front end (sliders, popups, chat widgets, social feeds, animation libraries, tracking pixels) adds JavaScript the browser has to download and run. Too much JavaScript is also the main cause of a poor INP score.

• Go through the plugin list and remove anything that is not earning its place.
• Stop plugins loading their files on pages where they are not used, for example a contact form plugin that loads on every page.
• Delay third-party scripts such as chat and tracking until the visitor interacts with the page.

5. Tidy up fonts and CSS

A site using three font families with five weights each can easily download a megabyte of fonts before any text appears.

• Stick to one or two families and only the weights you actually use.
• Host the fonts on your own site in WOFF2 format and preload the one used in the first screen.
• Remove unused CSS where your theme or builder allows it, and let the critical CSS load first.

6. Look at the server

If the server takes a long time to respond before anything even starts downloading, no amount of front-end work will fully fix it. Check the Time to First Byte in PageSpeed Insights or your browser’s developer tools.

• Make sure the site runs a current, supported version of PHP.
• Clean up the database: old revisions, expired transients and leftover tables from plugins you removed long ago.
• If the site has outgrown cheap shared hosting, moving to a well-configured VPS or better managed hosting is often the single biggest improvement.

What doesn’t work

• Installing a “speed plugin” and ticking every box. Aggressive settings often break menus, forms or sliders, and can make the real experience worse while the lab score goes up.
• Chasing a perfect 100. The score is a diagnostic tool, not the goal. A site that passes Core Web Vitals for real visitors and feels fast on a mid-range phone is the goal.
• Treating speed as a one-off job. New plugins, new images and new tracking scripts slowly add the weight back. Check the numbers again every few months.

A quick checklist

1. Record your current Core Web Vitals for the key pages.
2. Resize and convert images; don’t lazy-load the hero image.
3. Use one page-caching solution, plus a CDN if your audience is international.
4. Remove unused plugins and delay third-party scripts.
5. Limit fonts and let critical CSS load first.
6. Check server response time, PHP version and database bloat.
7. Measure again and compare with your starting numbers.

If you would rather have someone go through this properly on your site, including the server side, that is exactly what my speed and Core Web Vitals service covers. You can also just send me the link and I’ll tell you what I think is slowing it down.