Why is my WordPress site slow? In most cases, because of what runs on every page load: too many plugins loading their scripts and styles everywhere, heavy queries against an overloaded database, oversized images and a server doing all of that work without a cache. Hosting matters, but it is rarely the first problem. The plugin stack usually is.
Here is the order I check things in when a client sends me a slow site, and what usually fixes each one.
Measure first
Before changing anything, get numbers. Run your home page and your most important page through PageSpeed Insights on mobile. Write down the Largest Contentful Paint and the Time to First Byte. Then open your admin and time how long the dashboard and your busiest list screen take to load.
Those two views tell you different things. A slow front end with a fast admin points at images, scripts and design. A slow admin points at the database and at plugins doing work they should not be doing.
1. Count what loads on every page
Open your home page, view the source, and count the stylesheets and scripts. On a lot of sites I audit, a contact form plugin loads its files on every page even though the form lives on one. A slider plugin loads on pages with no slider. A booking widget loads on the blog. Every one of those files is a request the visitor’s phone has to make.
The fix is to load assets only where they are used. Well-built plugins do this on their own. For the ones that do not, a developer can stop them loading on pages that do not need them. When I build plugins, every file loads only on the screen that renders it.
2. Look for plugins that overlap
The typical slow site has twenty to forty plugins, and several of them do the same job. Two caching plugins. A page builder plus an add-on pack plus a second add-on pack. A forms plugin with three add-ons bolted on to make it do what one well-built plugin should.
Each plugin also runs code on every request, even when nothing on the page uses it. List every plugin, write next to it what it does for the business, and remove anything that does not earn its place. If a stack of add-ons exists to fake one workflow, that is often where a single custom plugin pays for itself.
3. Check the database
A slow admin is almost always a database story. The usual suspects:
- A bloated
wp_postmetatable. Plugins that store entries, bookings or logs as posts fill it with millions of rows. I explain why in custom post types vs custom tables. - Autoloaded options. Settings marked to load on every request, often left behind by plugins you deleted years ago.
- Old revisions, transients and logs. Thousands of saved versions and expired cache rows nobody cleans up.
Cleaning these up can make an admin feel new again. Fixing the plugin that keeps filling the table is what makes it stay that way.
4. Fix the images
Images are the most common reason a page’s main content loads late. A 4,000 pixel photo shown at 800 pixels wide is wasted weight on every visit. Resize images to the size they are shown, serve modern formats like WebP or AVIF, give every image a width and height so the layout does not jump, and lazy load the ones below the fold. Do not lazy load the main image at the top of the page: that delays the very thing Google measures.
5. Add caching, then look at hosting
Page caching lets the server send a ready-made page instead of building it with PHP and database queries on every visit. Most good hosts include server-level caching, and the official WordPress optimization guide covers the options. An object cache helps the admin and logged-in pages.
Only after all that would I blame the host. A cheap shared plan can be the bottleneck, but moving a bloated site to a faster server just makes a bloated site slightly faster.
6. Watch out for the page builder
Page builders are not slow by nature. Slow page builder sites come from deep nesting, dozens of add-on widgets and every animation switched on. A clean Elementor build with global styles and native widgets loads fine. I wrote about how I build them in Elementor website design your team can edit.
What “fast” should look like
Google’s Core Web Vitals are the clearest target: the main content should appear within 2.5 seconds, the page should react to a tap within 200 milliseconds, and the layout should not jump around while it loads. My Core Web Vitals fix list goes through each one for WordPress.
Speed is also why I build plugins the way I do. My Plugin Stack page shows the difference between data in a crowded shared table and data in a table built for it.
Frequently asked questions
How many plugins is too many for WordPress?
There is no magic number. Ten badly built plugins can be slower than thirty good ones. What matters is what each plugin loads and runs on every request, and whether two plugins are doing the same job.
Will a caching plugin fix a slow WordPress site?
It helps visitors who are not logged in, sometimes a lot. It does not fix a slow admin, slow checkout or slow logged-in pages, because those are not cached. The underlying plugin and database problems are still there.
Is my hosting the reason my site is slow?
Sometimes. Check the Time to First Byte in PageSpeed Insights. If it is high even on a simple page with caching on, the server may be the limit. If the server is quick and the page is still slow, the problem is on the site.
