Is WordPress Running Slow? 9 Causes and How to Fix Them

A WordPress site takes four or five seconds to load, the admin panel lags, and a client says, "it spins on their end." This is one of the most common problems site owners bring to us. The good news is that in nine out of ten cases, the cause is one of several well-known issues and can be identified within an hour.

Below are nine reasons why WordPress is slow, ordered from the most common. For each one, we explain how to recognize it and how to fix it yourself.

Table of contents

1. How to check whether WordPress really is running slowly?
2. Is shared hosting to blame?
3. Do you have too many plugins?
4. Are the images too heavy?
5. Is caching enabled on the site?
6. Which version of PHP is the site running?
7. Is the database overloaded?
8. Is the theme or page builder too heavy?
9. Are external scripts blocking loading?
10. Is wp-cron eating up resources?
11. Where to start fixing it?
12. FAQ

How to Tell Whether WordPress Really Is Slow

Before you change anything, measure it. Without measurement, you cannot know whether a fix helped, and "it seems faster" is not a result.

Three tools are enough:

• PageSpeed Insights (pagespeed.web.dev) shows Google's scores for mobile and desktop, as well as Core Web Vitals metrics. The most important is LCP, meaning the time it takes for the largest element on the page to become visible. A good score is below 2.5 seconds.
• GTmetrix or WebPageTest breaks down the loading process in a waterfall chart. You can see which file takes the longest to load.
• TTFB (Time To First Byte), meaning the time until the first byte of the server response arrives. You can check it in both tools or in the Network tab of your browser (F12). If TTFB exceeds 600 ms, the problem lies on the server or PHP side. If TTFB is low but the page still takes a long time to load, the likely culprits are browser-side files: images, scripts, and fonts.

This distinction is key. A high TTFB points to hosting, a lack of caching, outdated PHP, an overloaded database, or wp-cron. A low TTFB with slow loading points to images, a heavy theme, and external scripts. Plugins can cause problems with both.

Measure your homepage and one subpage, such as a post or product card. Save the results so you can refer back to them after every change.

Is shared hosting to blame?

This is the number one cause that website owners most often do not suspect, because “after all, I'm paying for hosting”.

On classic shared hosting, your site sits on one server alongside hundreds of other sites. The processor, memory and storage are shared. When a neighbour gets a traffic spike, sends out a newsletter, or someone attacks their site, your WordPress slows down too. PHP process limits add to the problem. When several people visit the store at once, subsequent requests have to wait in a queue.

How to spot it: TTDB fluctuates. 300 ms in the morning, 2 seconds in the evening, with no changes to the site. In the hosting control panel, you will see messages about exceeding resource limits (often called “resource limit reached” or “508”).

How to fix it: website optimization will only help partially. If the server is overloaded by other sites, you need to switch to hosting where resources are allocated specifically to you. On Saplo, every Box is a separate container with its own RAM and storage. Box S has 1 GB of RAM, Box M 2 GB, Box L 6 GB, and no other site can eat into that memory. Plan details are available in the price list.

Do you have too many plugins?

The number of plugins itself is not the problem. A site with forty lightweight plugins can run faster than a site with ten heavy ones. The problem is plugins that make lots of database queries every time someone visits the site or load their scripts on every subpage, even where they are not needed.

The most common culprits are feature-rich server-side analytics plugins, all-in-one security plugins that scan files on the fly, related posts plugins, sliders, and globally loaded forms.

How to identify it: install the free Query Monitor plugin. It will show the page generation time, number of database queries, and which plugin is sending them in the admin bar. A page that takes longer than 0.5 seconds to generate or makes several hundred queries has a problem.

How to fix it:

1. Make a backup of the site.
2. Disable plugins you have not used for months. Delete them, do not just deactivate them.
3. For heavy plugins, look for a lighter alternative.
4. Use a plugin such as Asset CleanUp or Perfmatters to disable loading a given plugin's scripts where they are not needed (e.g. contact form scripts only on the Contact page).
5. Measure again.

Are images too heavy?

A photo straight from a camera or phone weighs 4 to 8 MB and is 4000 pixels wide. It is displayed on the page at 800 pixels wide, but the browser still has to download the entire file. With three such photos on your homepage, LCP can reach several seconds, especially on a phone.

How to identify it: PageSpeed Insights shows recommendations such as “Serve images in next-generation formats” and “Size images appropriately”. In the waterfall chart, the longest bars are JPG or PNG files.

How to fix it:

• Before uploading, resize photos to a reasonable width, usually 1600 to 2000 pixels for full-width photos.
• Enable conversion to WebP or AVIF. Plugins such as Converter for Media, EWWW Image Optimizer and ShortPixel do this.
• Make sure lazy loading is working. WordPress added it automatically from version 5.5, but some themes disable it.
• Do not lazy-load the image visible at the very top of the page, such as a photo in the header. It determines the LCP.

Is the site using cache?

WordPress without cache runs PHP on every visit, connects to the database, assembles the page from dozens of queries, and only then sends it to the browser. With ten visitors at once, the server does the same work ten times.

There are two types of cache worth distinguishing:

• Page cache saves the ready HTML and serves it to subsequent visitors without running PHP. It is provided by plugins such as WP Super Cache, W3 Total Cache, LiteSpeed Cache (only on LiteSpeed servers), or WP Rocket (paid).
• Object cache stores the results of database queries in memory, most commonly in Redis. It helps where page cache does not work: in the admin panel, in the cart, and on the customer account page in a WooCommerce store.

How to recognize it: in Query Monitor, check whether object cache is active. The TTFB on a page you refresh for the second time should drop noticeably. If it does not, page cache is not working.

How to fix it: install one page cache plugin (not two at once, because they conflict) and enable object cache if the hosting provides Redis. On Saplo, installing WordPress from the catalog automatically connects the local Redis in Box and enables the Redis Object Cache plugin, with a separate prefix and database for each site. You do not need to configure anything manually.

What PHP version is the site running?

WordPress is written in PHP, and each new version of PHP is faster than the previous one. The difference between PHP 7.4 and PHP 8.3 can be noticeable on the same site, especially in the admin panel and on large stores. PHP 7.4 also no longer receives security patches.

How to check: In the WordPress panel, go to Tools, then Site Health, then Info, Server section. You will see the PHP version and memory limit.

How to fix it:

1. Make a backup.
2. Update WordPress, your theme and plugins to the latest versions. Old plugins may not be compatible with the new PHP.
3. Change the PHP version to 8.2 or 8.3 in your hosting panel.
4. Check the homepage, form, cart and panel. If anything breaks, go back to the previous version and find out which plugin is incompatible.

With Saplo, when you install WordPress, you can choose a PHP version from the list, from 7.4 to 8.5. We set 8.3 by default because practically every current plugin is compatible with it.

Is the database getting bloated?

The WordPress database grows over time. It collects post revisions (each save creates a new copy), posts in the trash, comment spam, expired temporary data (transients), and options left behind by plugins you removed long ago. The wp_options table is particularly dangerous. WordPress loads some of its rows on every page visit (options with the autoload flag). Once it grows to several megabytes, it slows down every visit.

How to recognize: Since version 6.6, WordPress Site Health itself warns about oversized autoload options. Query Monitor shows slow database queries.

How to fix:

• Limit the number of revisions by adding the define('WP_POST_REVISIONS', 5); line to the wp-config.php file.
• Clean the database with the WP-Optimize or Advanced Database Cleaner plugin: revisions, trash, spam, expired transients.
• Remove options left behind by uninstalled plugins. Advanced Database Cleaner shows which plugin each option belongs to.
• Always back up the database before cleaning it.

Is the theme or page builder too heavy?

Feature-rich themes sold with dozens of ready-made layouts load scripts and styles for all their features on every page, including features you never use. Page builders (Elementor, Divi, WPBakery) add deeply nested HTML code and their own CSS and JS files.

This does not mean you need to ditch the builder. It means you need to configure it.

How to identify: In PageSpeed Insights, the “Reduce unused JavaScript” and “Reduce unused CSS” recommendations point to theme or builder files. The page has several megabytes of scripts.

How to fix:

• In Elementor, enable the performance options in the settings (optimized asset loading, loading CSS from a file instead of inline).
• Disable any theme modules you do not use (sliders, icons, animations).
• When building a new site, consider a lightweight theme, such as GeneratePress, Kadence, or Astra, and use the block editor instead of a heavy page builder.

Do external scripts block page loading?

A chat widget, Facebook pixel, Google Analytics, Tag Manager with ten tags, a Google map, an embedded YouTube video, a review widget, fonts from Google Fonts. Each one requires a separate connection to another server and adds more kilobytes of scripts that you do not control.

How to recognize: You can see many files from third-party domains in the waterfall chart. PageSpeed Insights displays the recommendation “Reduce the impact of third-party code”.

How to fix:

• Review Tag Manager and remove tags from old campaigns.
• Load the chat only after user interaction or after a few seconds.
• Embed YouTube videos as thumbnails that load the player only after a click, as WP YouTube Lyte does.
• Download fonts to your own server instead of loading them from Google Fonts. This also resolves the GDPR compliance issue.

Is wp-cron a resource hog?

WordPress has a built-in task scheduler, wp-cron. It does not work like a real system cron, but instead runs when visitors arrive. On a high-traffic site, it runs too often, while on a low-traffic site, tasks such as publishing scheduled posts, making backups and sending store emails are delayed and can slow down the random visit that happened to trigger them.

How to recognize it: individual visits are noticeably slower than the rest for no apparent reason. The WP Crontrol plugin shows a list of tasks, often including tasks left over from removed plugins that have been hanging around for years.

How to fix it:

1. In WP Crontrol, remove tasks belonging to plugins you no longer use.
2. Disable wp-cron triggering by visitors by adding the line define('DISABLE_WP_CRON', true); to wp-config.php.
3. Set up a real system cron that calls wp cron event run --due-now every 5 minutes, or uses the wp-cron.php address. On Saplo, you get SSH access with full sudo from Box M onwards, so you can set it up with a single crontab line.

Where should you start the repair?

If you do not know where to start, follow this order, because the changes at the top are the cheapest and have the biggest impact:

1. Measure the site in PageSpeed Insights and record TTFB and LCP.
2. Back up the entire site and database.
3. Update WordPress, plugins, and PHP to 8.2 or 8.3.
4. Enable page caching and, if possible, object caching in Redis.
5. Optimize images and convert them to WebP.
6. Review plugins in Query Monitor and remove unnecessary ones.
7. Clean up the database and limit revisions.
8. Trim external scripts and configure the theme.
9. Measure again. If TTFB still fluctuates depending on the time of day, the problem is with the hosting, not the site.

In the latter case, no plugin will help. You need to move the site somewhere where the server resources are dedicated solely to you. If you are considering Saplo, we will move WordPress for you: migration is free, including the database and email, with no site downtime. You can learn more about how WordPress works on Saplo on the WordPress in the app catalog page and the WordPress hosting page.

FAQ

How many plugins are too many in WordPress?

There is no single limit. What matters is what the plugins do, not how many there are. A site with thirty lightweight plugins may run fast, while a single poorly written plugin can bring it to a halt. Check the page generation time and the number of queries in Query Monitor instead of counting the items on the list.

Is a cache plugin enough to speed up WordPress?

It often delivers the biggest one-time boost, but it does not solve everything. Page cache does not work in the admin dashboard, in the cart, or for logged-in store customers. There, an object cache in Redis, up-to-date PHP, and well-maintained plugins help. Cache will not fix heavy images or an overloaded server either.

Why is the WordPress admin panel slow while the site is fast?

Because visitors are served cached pages, while the admin panel is always generated on the fly by PHP and the database. A slow panel usually points to resource-heavy plugins, a bloated table wp_options, outdated PHP, or a missing object cache. Start by opening Query Monitor in the panel.

What is a good PageSpeed Insights result?

A score of 90 or higher is very good, while a score of 50 to 89 needs improvement. More important than the score itself are the Core Web Vitals metrics: LCP below 2.5 seconds, INP below 200 ms and CLS below 0.1. These metrics determine how the site is rated in Google.

Will changing hosting speed up WordPress?

Yes, if the problem is the server, meaning a high and unstable TTFB and messages about resource limits. No, if the site has heavy images and dozens of unnecessary scripts, because the same files will still have to be downloaded from the new server. Measure first, then decide.