Most slow WordPress sites are slow for one of nine reasons, and in my experience the biggest one is almost never the thing the owner is worried about. It is usually hosting or fonts, not “too many plugins.” Here is how to figure out which one is actually yours.
I have worked on a lot of WordPress sites over the past five years, and the pattern repeats. Someone tells me their site is slow, they have already deleted half their plugins, and it made no difference. That is because they fixed the ninth most likely cause and left the first one running.
Let me go through them in the order they actually matter.
1. Your hosting is the problem more often than anything else
Before a single image or font loads, your server has to build the page and send the first byte. If that takes a second, you have already lost a second before anything appears on screen. Nothing you do in WordPress gets that second back.
This is called time to first byte. You want it under 0.8 seconds. On cheap shared hosting it is very often over a second, and during busy periods it can be much worse.
How to check: open your site, press F12, go to the Network tab, reload, and click the very first request. Look at “Waiting for server response.”
If that number is bad, stop reading the rest of this list and fix your hosting or your caching first. Everything else is rearranging furniture.
2. Caching is turned off, or it is not actually working
This one is sneaky because people install a caching plugin, see it activated, and assume it is doing something.
Caching means the server saves a finished copy of your page and hands that to the next visitor instead of rebuilding it. Without it, every single visitor triggers a full rebuild.
How to check: in that same Network tab, click the first request and look at the response headers for something like x-cache: HIT or cf-cache-status: HIT. If you see MISS, DYNAMIC, or nothing at all, your cache is not engaging. I see this constantly on sites where the plugin is installed and the host’s own cache layer is switched off, so the two never connect.
3. You are loading five font families you do not use
This is the one that surprises people, and it is genuinely common on page-builder sites.
Page builders like Elementor and Divi ship with default fonts. When you pick your own, the defaults often stay loaded. I regularly open a site and find four or five font families being requested, each one pulling every weight from 100 to 900 plus every italic. That is dozens of font files, requested from an outside server, blocking your page from painting.
Most sites need two typefaces and three or four weights.
How to check: view your page source and search for fonts.googleapis.com. Count the results. If you see more than two, you have found a real problem.
4. Your images are the wrong format or the wrong size
A photo straight off a phone can be 4 MB and 4,000 pixels wide, displayed in a box that is 600 pixels wide. The browser downloads all 4 MB and then shrinks it.
Convert to WebP, resize to roughly the size it actually displays at, and let WordPress generate the responsive versions. This is standard now, and honestly, most sites I see have already got this part right. If yours has not, it is the easiest win on this list.
5. Everything above the fold is lazy-loading
Lazy loading is good. Lazy loading the wrong thing is bad.
If your hero image or logo is set to load lazily, the browser deliberately waits before fetching the one image the visitor is staring at. That directly damages your Largest Contentful Paint score.
Rule of thumb: anything visible without scrolling should load immediately. Everything below that should lazy load.
6. Your page builder is loading a stylesheet for every widget
Open your source and count the tags. On a clean site you might see 8 or 10. On a page builder site it is routinely 25 to 30, one for the heading widget, one for the counter widget, one for each animation, one per page template, and so on.
Each one is a separate round trip.
Most caching plugins can combine these. Do it on a staging copy first, then check every page, especially anything with a form or an accordion. Combining CSS breaks layouts often enough that you have to look rather than assume.
7. Old JavaScript loading before your content
jQuery Migrate is a compatibility shim for code written over a decade ago. It still loads by default on a lot of sites, in the head, blocking rendering, for no reason.
Same story with icon libraries. I have seen sites load three separate Font Awesome stylesheets to display four social icons in the footer.
8. Too many plugins, but not the way you think
Plugin count is not the issue. Thirty lightweight plugins can be fine. Three bad ones can wreck a site.
The ones that cause real damage are the ones that load their assets on every page whether they are needed or not. A contact form plugin loading its CSS and JavaScript on all twelve of your pages when you have one form is a small tax on eleven pages.
The fix is not deleting plugins. It is telling them where to load. Asset CleanUp and Perfmatters both do this well.
9. Your database has years of junk in it
Every post revision, every spam comment, every setting left behind by a plugin you uninstalled in 2023. On an older site this adds up and every page load queries through it.
This is real, but it is last on the list for a reason. It is usually worth 100 or 200 milliseconds, not two seconds. Fix it after the eight above, not before.
So which one is yours?
Run your homepage through PageSpeed Insights and read the diagnostics rather than staring at the score. Then work in this order:
- Server response time, causes 1 and 2
- Render-blocking resources, causes 3, 6 and 7
- Largest Contentful Paint element, causes 4 and 5
- Everything else
Fix one thing, measure, then fix the next. If you change five things at once and the site gets faster, you have learned nothing about which change mattered, and you will not know what to undo if something breaks.
One more thing worth ruling out early. If your site got noticeably slower over a short period with no obvious cause, it is worth taking ten minutes to check whether you have been hacked. Injected malware runs on every page load, and sudden unexplained slowness is one of the more common first symptoms.
Questions people ask
How fast should a WordPress site load? Aim for your main content to appear within 2.5 seconds on a normal mobile connection. That is the threshold Google uses for a passing Largest Contentful Paint score. Under 2 seconds is comfortable. Over 4 seconds and people start leaving before they see anything.
Will deleting plugins make my site faster? Sometimes, but it is rarely the biggest win. A plugin only costs you speed if it loads files on pages where it is not needed, or runs heavy queries. Two or three specific plugins usually cause the problem, not the total count.
Does a caching plugin fix everything? No, but it fixes the largest single piece for most sites. Caching addresses server response time. It does not fix oversized images, font bloat or render-blocking scripts. Those need separate work.
Is my host really the problem? Check your time to first byte before deciding. If it is consistently over one second, your host or your cache setup is the bottleneck, and optimizing WordPress around it will only get you so far.
Does site speed affect my Google ranking? It is a real ranking factor, but a modest one directly. The bigger effect is indirect. Slow sites lose visitors before the page loads, and that costs you conversions and engagement, which matter more than the speed signal itself.
If you want a second opinion on your own site, send me the URL and I will take a proper look and tell you what is actually slowing it down. No charge, no pitch, just the list. If you want me to fix it afterwards, the Fix Sprint is a fixed price and I will show you the before and after numbers. If you would rather take the list and do it yourself, that is genuinely fine too.
