Work Out Which Kind of Slow You Have
A WordPress site is usually slow for one of three reasons: the server takes too long to build the page, the page sends too much to the browser, or something on the page keeps moving or blocking after it arrives. Each has a different fix, so the first job is to find out which one you have before installing anything.
This is written for the person who owns or looks after a WordPress site and has been told it is slow, whether by a customer, a speed score, or their own impatience. The first half is how to measure so you stop guessing. The second half is the causes, in the order that tends to pay off.
Slow to start and slow to finish are separate problems
When someone opens a page, two clocks run. The first is how long the server takes to send back the first byte of HTML. The second is how long the browser then needs to download images, scripts, and styles and paint the screen. A site on an overloaded server can have tiny pages and still feel slow. A site on a fast server can send a four-megabyte hero image and feel just as slow.
Google's Core Web Vitals put numbers on the second clock. A page is rated good when its largest element appears within 2.5 seconds (Largest Contentful Paint), when it responds to a tap or click within 200 milliseconds (Interaction to Next Paint), and when it shifts no more than 0.1 on the layout shift score. Those thresholds are judged at the 75th percentile of page loads, which means a quarter of your visitors can have a worse experience than the number you are shown. The first clock is not one of the three, but it feeds the first: a page cannot paint its largest element before the HTML has arrived.
Lab Scores and Field Data Answer Different Questions
PageSpeed Insights shows two kinds of result and they often disagree. Lab data comes from Lighthouse running one simulated load on one simulated device, which makes it good for debugging. Field data comes from the Chrome User Experience Report and reflects real visitors over the previous 28 days.
Use lab data to find out why and field data to find out whether. If the lab score is a 95 and the field report says your largest paint is slow, real visitors on real phones are having a worse time than the simulation suggests, and the field report is the one to believe. The 28-day window also means a fix will not show up in field data for weeks, so do not conclude that a change did nothing after three days.
Check the front of the site and the dashboard separately
If only the public site is slow, the cause is usually page weight, missing caching, or render-blocking files. If the dashboard is slow as well, look at the server and at what runs on every request, because the admin is never served from a page cache. A slow dashboard with a fast front end is the classic sign of a heavy plugin, a database that has grown untidy, or a PHP setup with too little memory. A slow front end with a fast dashboard points at images, scripts, and caching.
That one test cuts the search in half and takes about a minute, which is why it comes first.
Test the Way a Stranger Sees the Site
Open the page in a private window so you are logged out. Logged-in sessions skip the page cache on most setups, so your own experience can be far slower than anyone else's. Then run PageSpeed Insights on the mobile tab, not the desktop one, and test the page that earns money rather than only the home page. A product page, a booking page, and a long blog post each fail in their own way.
Also test at an hour when the site is busy. A cron job, a backup, or a traffic spike at 2 a.m. produces a different result from the middle of a Tuesday.
Write the Baseline Down Before Changing Anything
Record three numbers for each page you care about: the largest paint time, the time to first byte, and the total page weight in megabytes. A spreadsheet row per page is enough. Without a starting point, every later change becomes an opinion.
Change one thing at a time and measure again. Turning on five optimizations at once and finding that the checkout broke leaves you no way to tell which of the five did it. That outcome is common enough that it is worth planning around.
The Usual Causes, in the Order Worth Checking
The list below is ordered by how often each cause turns out to be the real one on small business sites, and by how cheap it is to rule out. Work down it and stop when the numbers move.
Every Uncached Visit Rebuilds the Page from Scratch
Without a page cache, WordPress runs PHP, asks the database for the posts, menus, widgets, and options, assembles the HTML, and sends it, for every single visitor. With a page cache, the finished HTML is saved once and handed out again until something changes. The difference between the two is often the single largest speed gain available.
You can see whether caching is working in the response headers of a page. Open your browser's developer tools, load the page logged out, and look at the response headers for a cache status or an age value. If every reload shows a fresh build, nothing is being cached. Be careful about what must stay out of the cache: the cart, the checkout, the account pages, and anything personalized. A cache that serves one customer's basket to another customer is worse than a slow site.
One plugin or one outbound call can stall every request
A page can only be as fast as the slowest thing it waits for. Plugins that call out to another service on every load, such as a licensing check, a social feed, or a remote font, add that service's response time to yours. If the remote end hangs, your page hangs with it.
The free Query Monitor plugin is the quickest way to see this. It lists database queries, including slow, duplicate, and failing ones, and HTTP API requests with the component responsible and the time each took. Install it on a staging copy where possible, load the slow page, and sort by time. The culprit is frequently a single plugin you forgot you had. Deactivating it and measuring again is a fair test; deleting plugins in bulk is not.
The options table collects weight that loads every time
Every WordPress request loads the options marked to autoload from the wp_options table, whether or not that request needs them. Over the years, removed plugins leave their settings behind, and some plugins store large blobs of data as autoloaded options. The result is a database read that grows quietly while nobody is looking.
A query such as SELECT SUM(LENGTH(option_value)) FROM wp_options WHERE autoload = 'yes'; tells you how many bytes load on every request on that site. Your table prefix may not be wp_. If the number is in the megabytes, find the largest rows and decide, one by one, whether the plugin that wrote them is still installed. Take a database backup first and do not delete a row you cannot name.
Images are usually the heaviest thing on the page
On most small business sites the largest element on the page is a photo, and it is often several times bigger than it needs to be. Check the actual dimensions the browser displays against the dimensions of the file. A 4000-pixel photograph shown in a 800-pixel column is paying for pixels nobody sees.
Three habits matter. Serve a modern format such as WebP. Let WordPress's responsive image sizes do their job by not hard-coding full-size files into page builders. And do not lazy-load the image at the top of the page: the browser should fetch it first, because it is the thing the Largest Contentful Paint measurement is waiting on. Lazy loading belongs on images below the fold.
Old PHP and thin hosting cap everything above them
No amount of tuning rescues a site on an unsupported PHP version or a crowded shared server. Newer PHP releases run WordPress code faster, and old ones stop receiving security fixes; the supported versions page on php.net shows which are current. Check your version in Tools, then Site Health, then Info.
Hosting shows up as time to first byte. If an uncached request takes a long time to start even on a nearly empty page, the server is the limit, and the options are a better plan or a better host. This is also where the line between a performance problem and a hosting problem gets blurry, and it is worth knowing which one you have before paying to fix the wrong one.
The dashboard and background tasks slow things down quietly
WordPress runs scheduled tasks when visitors arrive, using a mechanism called WP-Cron. On a busy site with heavy tasks, that work competes with real visitors; on a quiet site, tasks get delayed, which is the cause of missed scheduled posts. The editor's Heartbeat calls, which keep a post locked and autosaved, can also pile up when many people have the dashboard open at once.
Moving WP-Cron to a real scheduled job on the server is a common fix, but it is a server change, not a settings toggle, so make it deliberately and test that scheduled posts still publish afterwards.
Most of these checks are free and take an afternoon. If you would rather not spend the afternoon, that is what WordPress speed optimization from Cascadia covers: full-page caching, server-side object caching, a global CDN, automatic image compression with WebP delivery, critical CSS, and Core Web Vitals tracking, with the work tested against your live site so carts, checkout, and account pages stay out of the cache. The setup is re-optimized daily so it holds as the site changes. If the audit shows the server is the real limit, managed WordPress hosting is the other half, and WordPress maintenance keeps plugins and PHP current so the problem does not creep back. The performance comparisons lay the choices out next to speed plugins. Two neighboring posts are worth reading: the white screen of death for when an update goes badly, and the security checklist for the other thing an unmaintained site tends to collect.
