Your WordPress site is slow for one of five reasons, almost every time: the server takes too long to build each page, there is no page cache (or two fighting each other), plugins and a page builder load heavy files on every page, images are far larger than the screen needs, or background jobs such as wp-cron run while visitors wait. This guide is the map: it shows how to tell which of these you have in about 15 minutes, what to fix first, and which detailed guide covers each fix, from caching plugin settings to Elementor and WooCommerce.
Quick answer
- Measure before you change anything. Run a speed test and the free WordPress theme and plugin detector on your home page and your most important template.
- Time to First Byte over 800 ms? The server is the bottleneck: turn on one page cache, update PHP (WordPress recommends 8.3 or newer), then look at the host.
- Server fast but the page still slow? It is front-end weight: a plugin over 150 KB on one page, a page builder that is half the page's code, oversized images or third-party scripts.
- Fast one minute, slow the next? Suspect wp-cron and other scheduled jobs that run on visitor requests.
- Only wp-admin is slow? That is the database, autoloaded options, the Heartbeat API or admin-only plugins, and it needs different fixes from the front end.
- Fix in this order: caching, heavy plugins, builder settings, images, scripts, then hosting. Re-test after each step.
Why is my WordPress site so slow? The five usual causes
WordPress builds every page on request: PHP runs the theme and every active plugin, queries the database and assembles the HTML, then the browser downloads whatever CSS, JavaScript, fonts and images that HTML asks for. Slowness can come from either half, and the symptoms tell you which.
| Symptom | Likely cause | What to measure | Where to start |
|---|---|---|---|
| Blank screen for a second or more before anything appears | Slow server, no page cache | Time to First Byte | Caching and hosting (below) |
| HTML arrives quickly, page fills in slowly | Plugins, page builder, render-blocking files | Plugin kilobytes, builder share, LCP | Plugins and page builders |
| Text shows, photos load late | Oversized or unoptimised images | Image weight and dimensions | Images |
| Page looks ready but taps and clicks lag | Too much JavaScript, third-party scripts | INP, Total Blocking Time | Plugins and third-party scripts |
| Speed varies wildly between visits | wp-cron, uncached pages, busy shared server | TTFB over several runs | wp-cron |
| Shop pages slow, blog fine | WooCommerce cart fragments, uncacheable pages | wc-ajax requests, cache headers | WooCommerce |
| Only the dashboard and editor are slow | Database, autoload, Heartbeat, admin plugins | Query Monitor, Site Health | Slow wp-admin |
The table matters because the common reflex, installing an "optimisation" plugin, fixes only some of these, and can make others worse. A caching plugin does nothing for a 3 MB hero image, and a second one breaks the first.
How to find what is slowing your WordPress site down
You need two measurements: how long the server takes to answer, and what the page loads after that. Both are available from the outside, without logging in to WordPress.
The detector reads every file the page loads from /wp-content/plugins/, plus the comments and headers that caching and SEO plugins leave, then loads the page in a real browser and assigns each request to its plugin. You get each plugin's kilobytes, request count and time, the theme and page builder, and whether any plugin is closed on wordpress.org or has not been updated in over two years. It only sees what the page loads for visitors: backup, security and admin-only plugins add nothing to the front end, so they do not appear.
The full getReport report runs these checks alongside the speed measurements:
Read the results in this order. If Time to First Byte is over 800 ms, start with the server and caching section; nothing on the front end will make up for a slow first byte. If TTFB is fine, the plugin table and the builder share tell you where the page weight comes from. For the server side, what PHP is doing inside each request, install Query Monitor on a staging copy: it lists slow database queries and HTTP calls by plugin.
Test more than the home page. A plugin that loads only on the shop or the contact page shows up only there, and a builder-heavy landing page can be three times the weight of a plain blog post.
Slow server and missing page cache
When Time to First Byte is high, visitors stare at a blank screen while PHP and the database build the page. getReport's TTFB check passes at 800 ms or less, warns up to 1.8 s and fails above that, the same thresholds Google uses for the metric. A cached WordPress page on decent hosting answers in 100–300 ms; an uncached page on a busy shared server can take well over a second.
The first fix is always a full-page cache, which stores the finished HTML and skips PHP for repeat requests. The second is PHP itself: wordpress.org recommends PHP 8.3 or newer, and most hosting panels switch versions in a click. After that, look for the plugin that does expensive work on every request, and move scheduled jobs off visitor requests. Our guide to server response time on shared hosting lists these fixes in order, with what each typically saves, and TTFB: what a slow server looks like explains how to read the measurement.
When a site is already cached and lean and still slow, the host is the limit. The comparison above shows how your server's first byte compares with other sites getReport has checked on the same host, once 50 sites on that host have been measured. Our guide to choosing a WordPress host by measured TTFB shows how to compare hosts with cached and uncached tests before you move.
Caching plugins: one, set up properly
A caching plugin is the single biggest speed fix for most WordPress sites, and the one most often set up wrong. Two rules cover most of it: run exactly one page cache, and pick the one that matches your server.
Two caching plugins break things. Two page caches expire at different times, two minifiers rewrite each other's output, and both write rules to .htaccess. The result is stale prices at checkout, scripts that stop working after "optimisation" and changes only you can see. Our guide on running two caching plugins and which one to keep matches plugins to hosts (LiteSpeed Cache on LiteSpeed servers, the host's own plugin on managed hosts, one general plugin elsewhere) and shows how to remove the other without leaving advanced-cache.php or a WP_CACHE line behind.
WP Rocket has safe defaults, which also means many of the switches that move Core Web Vitals are off after install. Our WP Rocket settings for Core Web Vitals goes through the tabs in the order that pays, names the settings that can break a site (delaying JavaScript and removing unused CSS need testing) and how to roll them back.
LiteSpeed Cache has more than a hundred switches, and some only work on a LiteSpeed server or through QUIC.cloud. Our LiteSpeed Cache settings for Core Web Vitals covers the roughly fifteen that make most of the difference, which ones need the LiteSpeed server, and which ones break WooCommerce.
Plugins: what each one costs
The number of plugins matters less than what each one does. Thirty small plugins that add nothing to the front end can be lighter than one slider that loads 400 KB of JavaScript on every page. A plugin costs you in two places: PHP work on the server for every uncached request, and CSS and JavaScript in the visitor's browser, often on pages that never use it.
getReport warns when a single plugin adds more than 150 KB to the page you tested. Sliders, form builders, social feeds, chat widgets and page builder add-on packs are the usual names at the top of the table. Our guide to what each WordPress plugin costs your visitors walks through the audit: what to delete, what to replace with something lighter, and what to load only on the pages that use it with an asset manager such as Perfmatters or Asset CleanUp.
Deactivated plugins do not slow the front end, because WordPress does not load their code, but delete them anyway: they still get security updates you will not apply. Plugins that are closed on wordpress.org or have not been updated in years are a security problem before a speed one; our guide to abandoned and closed plugins and how to replace them shows how to judge a replacement and swap it on staging.
Some plugins do the same job twice without being caching plugins. Two SEO plugins, such as Yoast and Rank Math together, do not slow the page much, but they print two titles, two canonicals and two schema graphs. Our guide to duplicate SEO plugins shows how to pick one and migrate settings without losing hand-written titles.
Page builders: Elementor, Divi and the block editor
A page builder ships a framework to every visitor: its own CSS, its JavaScript, icon fonts, and extra container elements around every heading and button so the editor can position them. That is the price of drag-and-drop, and on most builder sites it is paid in full because the builder's own performance settings were never switched on.
getReport attributes CSS, JavaScript and page elements to the builder it detects and warns when the builder makes up half or more of either, above a minimum of 100 KB or 600 elements. Our comparison of page builders and the block editor, measured gives honest ranges for Elementor, Divi, WPBakery, Bricks and Oxygen against core blocks, and sets out the options: tune the builder, use it only on the pages that need it, or rebuild.
For the two most common builders there are setting-by-setting guides. Elementor performance: asset loading, fonts and DOM size covers the Performance and Features settings, loading Google Fonts without hiding text, and cutting container depth. Divi performance settings covers dynamic CSS, critical CSS, the static CSS cache and how it interacts with a caching plugin. The builder's cost usually shows up in the report as render-blocking resources, unused CSS and a large DOM, so those findings shrink together once the builder is tuned.
Images and media
Images are the heaviest part of most WordPress pages, and the Largest Contentful Paint element is usually a photo. The common problems are photos uploaded straight from a camera or phone, backgrounds set in a page builder at 2,000–4,000 px, and a hero image that is lazy-loaded when it should load first.
An image optimisation plugin compresses uploads and can serve WebP or AVIF; our honest comparison of image optimisation plugins covers free local options and quota-based cloud services. No plugin fixes an image placed at the wrong size in a layout, though. For that, see responsive images with srcset and sizes, and make sure the hero is not lazy-loaded, as our guide to lazy loading done right explains.
Third-party scripts
Chat widgets, cookie banners, analytics, ad tags, embedded reviews and social feeds all run JavaScript on the visitor's device, often from several other servers. They do not show as plugins in the table when they are pasted into a header box or loaded through a tag manager, but they compete for the same main thread and slow down every tap.
Our guide to third-party scripts, tag managers, chat and ads shows how to find which ones cost the most and how to delay or replace them. Removing one chat widget often does more for Interaction to Next Paint than any caching setting.
Random slowness: wp-cron and scheduled jobs
A site that is fast most of the time and slow for no visible reason is often running its own housekeeping on a visitor's request. WordPress has no clock of its own: when someone loads a page, it checks for overdue jobs (scheduled posts, backups, sitemap rebuilds, WooCommerce's Action Scheduler, update checks) and runs them then.
The fix is to turn off the visitor-triggered trigger with define('DISABLE_WP_CRON', true); in wp-config.php and run the queue from a real server cron every five minutes. Our guide to wp-cron and scheduled tasks gives the exact cron line for common hosts, shows how to find the plugin that schedules a job every minute, and how to measure the spread in TTFB before and after.
WooCommerce: slow shop pages
WooCommerce adds two speed problems a normal site does not have. The first is cart fragments: a request to ?wc-ajax=get_refreshed_fragments that keeps the mini-cart count fresh, bypasses the page cache and costs a PHP request on every page where it runs. Since WooCommerce 7.8 it loads only with the Mini-Cart widget or block, but themes and plugins still enqueue it elsewhere.
The second is that cart, checkout and account pages must never be cached, so every cache layer needs the right exclusions. Our guides to WooCommerce cart fragments and caching the cart, checkout and account pages cover both, and the WooCommerce store checklist covers the rest of a shop's setup.
Why is the WordPress admin slow?
A slow dashboard is a different problem from a slow front end, because the admin is never cached and runs code visitors never see. The usual causes are autoloaded options that load on every request (Site Health warns above 800 KB since WordPress 6.6), a database swollen with revisions, expired transients and scheduler logs, Heartbeat requests from open admin tabs competing for PHP workers, and plugins that do heavy work only on admin screens, which the plugin detector cannot see from outside.
Our guide to a slow WordPress admin shows how to find the cause with Query Monitor and Site Health in about 20 minutes, with the SQL to size autoloaded options, a safe database clean-up, a Heartbeat filter that keeps autosave working, and the server basics (PHP version, OPcache, a persistent object cache) that help logged-in users most.
Settings left at their defaults
Some problems slow a site's search results rather than its pages. A launch left with "Discourage search engines" ticked, plain permalinks, a "Hello world!" post or an indexable staging copy costs traffic, not milliseconds. They take a minute each to fix; our guide to the WordPress rookie mistakes getReport checks lists all eight with the admin screen that fixes each one.
What to fix first
Work in this order, and re-test the same pages after every step so you know what each change bought. Our step-by-step guide on how to speed up a WordPress site walks through each of these fixes in detail:
- One page cache, switched on. Check that pages are served from it: a repeat test should show a much lower TTFB.
- PHP 8.3 or newer, from the hosting panel, after testing on staging.
- Remove or restrict the heaviest plugins from the plugin table, starting with the ones the page does not use.
- Turn on the page builder's performance settings, then regenerate its CSS and purge the cache.
- Resize and compress images, and make sure the hero image is not lazy-loaded.
- Delay or remove third-party scripts that do not earn their weight.
- Move wp-cron to a real cron if TTFB varies a lot between runs.
- Change host only when cached pages are still slow on a lean site.
How to verify
Re-run the speed test and the plugin detector on the same pages, three runs each, because single runs vary. Lab tests show the effect straight away; Google's Core Web Vitals come from real Chrome users over the last 28 days, so expect the field numbers in Search Console or the Core Web Vitals checker to move over about four weeks. Our guide to Core Web Vitals for site owners explains what each metric means and the targets to aim for.
Common mistakes
- Stacking optimisation plugins. Two caches or two minifiers make a site slower and less stable, not faster.
- Testing while logged in. Logged-in users usually bypass the page cache, so the site looks slower to you than to visitors. Test in a private window.
- Chasing the Lighthouse score. A score of 100 on desktop does not mean real phone visitors get a fast page; judge by Core Web Vitals field data.
- Blaming the number of plugins. Measure what each one loads; remove the heavy ones, not the most recent ones.
- Moving host first. A new host will not fix an uncached site with a 3 MB builder page.
- Turning on every switch at once. Enable settings one tab at a time and test, so you know which one broke the menu.
Questions people ask
Why is my WordPress site suddenly slow?
A sudden slowdown usually follows a change: a plugin or theme update, a new plugin, a cache that was cleared or switched off, or a traffic spike on shared hosting. Check what changed in the last few days, look at Time to First Byte to see whether the server or the page got slower, and re-run the plugin detector to spot a new heavy plugin.
Why is my WordPress site slow when I am logged in?
Logged-in users bypass the page cache on almost every WordPress setup, so each page is built from scratch by PHP and the database. The admin bar and admin-only plugins add more work on top. That is why the site feels slow to you but not to visitors. Test speed in a private window, and treat a slow logged-in experience as a server and database problem.
Will a caching plugin fix a slow WordPress site?
It fixes one cause: a slow server response. A page cache can turn a one-second Time to First Byte into 100–300 ms, which helps every page. It will not shrink oversized images, a heavy page builder or third-party scripts, and a second caching plugin makes things worse. Turn on one cache first, then measure what the page still loads.
How much does hosting affect WordPress speed?
Hosting sets the floor for Time to First Byte, which every other metric waits for. On cheap shared hosting an uncached page can take over a second; good hosting answers cached pages in about 100–300 ms. But hosting cannot fix page weight, so check that caching is on and plugins are lean before you move, and compare hosts by measured TTFB.
Is my WordPress theme making my site slow?
It can be. Multipurpose themes often load sliders, icon fonts and animation libraries on every page, and themes built around a page builder inherit the builder's weight. Run the plugin detector to see what the theme and builder load, then test a default theme such as Twenty Twenty-Five on a staging copy: if the same page gets much faster, the theme is the problem.
Does WooCommerce make WordPress slower?
WooCommerce itself is reasonably light, but shops have more uncacheable pages and more requests. Cart, checkout and account pages must bypass the cache, and cart fragments can add a PHP request to every page. Keep the cart fragments request to pages with a live mini-cart, exclude the right pages from every cache layer, and optimise product images, which are usually the heaviest part of a shop.
How long does it take to speed up a WordPress site?
The first round usually takes an afternoon: one caching plugin, a PHP update, removing the two or three heaviest plugins and compressing the largest images. Tuning a page builder or replacing plugins takes a few more hours. Lab results change straight away, while Google's Core Web Vitals field data takes about 28 days to reflect the improvement.