Why Is My WordPress Site So Slow? A 9-Step Check-Up for WooCommerce Stores

In September 2026, only 39% of the WooCommerce stores measured by HTTP Archive passed Google's Core Web Vitals on mobile. Only 12% had a server response time rated “good”.

So if your store feels slow, you are far from alone. But “slow” is not a diagnosis. It's a symptom.

Most guides give you 18 tips and a cache plugin to buy. This one gives you 9 tests. You run them, you read the numbers, and you fix what is actually broken.

To keep it honest, we ran every test on our own WooCommerce test store: WooCommerce 10.9, the default Twenty Twenty-Five theme, 94 products, no cache. First as it was, with 7 plugins. Then with the plugins you find on most stores: a wishlist, product reviews, AliExpress imports, PDF invoices, order tracking, a live chat. 15 plugins in total. You'll see the real results at each step. Spoiler: what slowed it down was not only what we expected.

Source of the opening figures: HTTP Archive Core Web Vitals Technology Report, Chrome UX Report data for September 2026 (our calculation: origins passing over origins measured).

The 6 words you'll see, in plain English

• Server: the computer, at your host, that builds your pages and sends them to your visitors.
• Server response time (TTFB): how long your visitor stares at a blank screen before your page starts arriving.
• Cache: a ready-made copy of a page, kept aside so it can be served instantly instead of being rebuilt.
• PHP: the language WordPress and WooCommerce are written in. Your host chooses its version, and newer is faster.
• Plugin: an add-on you install. Each one adds code that may run on every page, even when you don't see it.
• Admin: your back office, where you manage products and orders. Your customers never see it.

Step 1: Is your site really slow, and for whom?

Free tool2 minutesNo plugin needed

Symptom. It “feels” slow. A customer complained. Or a speed test showed a red score and you panicked.

Test it.

1. Open PageSpeed InsightsAt pagespeed.web.dev, paste the URL of your most visited product page, not just your home page.
2. Read the top block first“Discover what your real users are experiencing” shows data from real Chrome visitors over the last 28 days.
3. Then read the lab testThe score and the five metrics below come from one simulated visit on a mid-range phone.

What it means. Google's thresholds, from web.dev, apply to 3 visits out of 4:

“No Data” in the top block is normal for a small store: there isn't enough Chrome traffic yet. You then work with the lab test, and with your own measurements in the next steps.

Speed also matters for search, with a nuance. Google says Core Web Vitals “are used by our ranking systems”, but it “always seeks to show the most relevant content, even if the page experience is sub-par” (Google Search Central).

On our test store, with the usual 15 plugins. Score 67 on mobile, no real-user data. The main photo took 3.8 seconds to show up, well above the 2.5-second target. And a surprise: a CLS of 0.373, deep in the red. The page wasn't only slow, it jumped.

pagespeed.web.dev

The fix. Nothing yet. Write down your score, LCP, INP or TBT, and CLS in a “before” table. Run the test 3 times and keep the middle value.

Step 2: Does your server take too long to answer?

Free tool5 minutesNo plugin needed

Symptom. A blank screen before anything appears. Every page is slow, even the simplest one.

Test it.

1. Open Chrome's developer toolsRight-click, Inspect, then the Network tab. Tick “Disable cache”.
2. Reload the pageClick the very first line, the page itself, then the Timing tab.
3. Read “Waiting for server response”That's your Time to First Byte (TTFB). Do it on 4 pages: home, a product page, the cart, and any page while logged in.

Think of a restaurant. Without a cache, the kitchen cooks every dish from scratch for each customer, even the same dish ordered a hundred times a day. With a cache, the dish is already on the counter. Your server is the kitchen, and a WooCommerce page is a complicated dish.

What it means. According to web.dev, “most sites should strive to have a TTFB of 0.8 seconds or less”. It isn't a Core Web Vital, but everything else waits for it. WordPress's own Site Health check flags a page response over 600 ms.

• Fast home page, slow cart: a page cache hides a slow server. Your cart and checkout, which can't be cached, pay the full price.
• Everything slow: no page cache at all, or a server and PHP setup to review (step 3).

On our test store. With its 7 plugins, every page took about half a second to be built: 0.45 s for the home page, 0.51 s for a product page, 0.47 s for the cart. With the usual 15 plugins, 0.6 to 0.7 s. On the same server, a plain image file came back in 7 milliseconds. So nearly all the wait was the server building the page with PHP, for every visitor.

Then we tried the classic fix for one evening: a page cache, with LiteSpeed Cache on its default settings, since our test server runs LiteSpeed.

Server response time measured from the server itself, 4 requests per page, October 21, 2026. We removed the cache afterwards to keep the store in its original state.

The fix.

• Add a page cache. Free options: LiteSpeed Cache if your host runs LiteSpeed (its cache needs a LiteSpeed server or its CDN), or WP Super Cache anywhere. Paid: WP Rocket, from €49.95 a year for one site according to its pricing page in October 2026. Whatever you pick, the cart, checkout and My Account pages must stay uncached, as WooCommerce recommends.
• Speed up what can't be cached: PHP and its caches, in step 3.

Step 3: Read your Site Health report

Built into WordPress5 minutesNo plugin needed

Symptom. You don't know where to start. Or the site has “always” been slow.

Test it. In your admin, go to Tools, then Site Health. Open the Status tab and look at every line tagged “Performance”.

your-store.com/wp-admin/site-health.php

What it means.

On our test store. PHP 8.1, which no longer gets security fixes according to php.net. No page cache. No persistent object cache. And the big one: the opcode cache wasn't just disabled, its extension wasn't even loaded. That's a hosting setting we can't change ourselves. Autoloaded options, on the other hand, were healthy: 89 KB.

The fix. Start with what Site Health lists as critical. For PHP and OPcache, you don't touch anything yourself: copy the lines from Site Health into a message to your host. That one email often does more than any plugin.

Step 4: Find the plugins that load everywhere (Query Monitor)

Free plugin15 minutesA bit technical

This step is the most technical one. If it feels like too much, read the results below, then hand the test to a developer: show them this section, they'll know what to do.

Symptom. Your server is slow even on pages that can't be cached. Or the site got slower after you installed something.

Test it.

1. Install Query MonitorIt's free, and only admins see its panel.
2. Open a product page while logged inClick the new item in the admin bar. Read the page generation time and the number of database queries.
3. Open “Queries by Component”It shows how much work each plugin does on this page. Then check “HTTP API Calls”: calls to outside services while the page loads.

Query Monitor, product page

What it means. Many plugins load their code on every page, even where they're useless. An AliExpress importer runs when a customer reads your home page. A reviews plugin runs on your checkout. Each one costs a few milliseconds of server time, on every visit, and it adds up.

On our test store. We then installed the plugins you find on most WooCommerce stores: a wishlist (YITH WooCommerce Wishlist), product reviews (Customer Reviews for WooCommerce), AliExpress imports (Ali2Woo), PDF invoices (PDF Invoices & Packing Slips), order tracking (ParcelPanel) and a live chat (Tidio). 15 plugins in total. And we timed how long each one takes to load, on every page:

Measured on October 21, 2026, on a product page: time to load each plugin's main file, with a temporary timer on the server, median of 4 requests. Work done later in the page is not split by plugin.

The whole page now took 0.73 s to build instead of 0.51 s, with 245 database queries instead of 152. Your visitors wait longer before seeing anything, on every page, and you didn't change a thing on your products.

The fix. Update the plugin, or replace it. If nothing stands out in Query Monitor, run the conflict test that WooCommerce recommends on a copy of your site: deactivate half of your plugins, measure, and keep halving until you find the culprit. With 20 plugins, 5 rounds are enough. Then uninstall Query Monitor: you don't need it all year.

Step 5: Count what your plugins load for visitors, and cut

Free tool10 minutesNo plugin needed

Symptom. Product pages feel heavy. PageSpeed Insights talks about “unused JavaScript”. You have a lot of plugins and wonder which ones hurt.

Test it. In Chrome's Network tab (“Disable cache” ticked), filter on JS, then CSS. The bottom bar shows the number of files and the size transferred. Each file's path tells you which plugin loaded it: /wp-content/plugins/plugin-name/.

On our test store. With the same usual plugins, here is what a visitor downloads on one product page:

Who added what: YITH Wishlist loaded 151 KB (7 files) on every page, home page included. Ali2Woo added 45 KB, Customer Reviews 32 KB. And these plugins pulled in extra WordPress libraries: 204 KB instead of 68 KB. ParcelPanel, PDF Invoices & Packing Slips and Tidio (not yet connected to an account) loaded nothing on this page.

The fix: be ruthless. Go through your plugin list, one by one, and ask two questions:

1. Do I really use it?Not “it might be useful one day”: do you use it every week? If not, delete it. Deactivating isn't enough, because some leave scheduled tasks and settings behind.
2. Does it load everywhere?If you need it but it loads its files or its code on every page, replace it with a lighter plugin that only loads where it works.

Why stores end up with so many plugins, and how Plume simplifies it

On WooCommerce, almost every need is a plugin. One for order tracking. One to sync your AliExpress orders, like Ali2Woo. A chatbot. A plugin for invoices. Each comes from a different vendor, with its own menus, banners, scripts and scheduled tasks. After a year, a small store easily runs 20 or 30 of them.

That's exactly why we built Plume: a lightweight WooCommerce suite that covers those everyday needs, in one place. Each plugin does one job, and “a plugin's scripts only load on the pages where it works”. We measured our plugins on the same store, the same way, next to the usual ones:

Server time added on every product page, and files downloaded by visitors, measured on October 21, 2026. Two honest notes. Plume Invoices costs a bit more server time than PDF Invoices & Packing Slips, because it also handles e-invoicing. And Tidio loads nothing until you connect it to an account; once connected, its widget downloaded about 526 KB on Tidio's own site in our chat test.

Overall, the same four jobs cost about three times less server time with Plume, and a fraction of the files. With one subscription, one style and one support, instead of four vendors.

But let's be clear: lighter plugins won't fix a server with no cache or a 3 MB product photo. For most stores, steps 2, 3 and 6 matter as much. Do them too.

Step 6: Check your largest image, and what makes the page jump

Free tool5 minutesNo plugin needed

Symptom. The page shows up, but the big photo arrives last. Or things move while the page loads, and your customer taps the wrong button.

Test it. In PageSpeed Insights, scroll down to the diagnostics and open two of them: “Largest Contentful Paint element”, the biggest thing on screen (on a product page, usually your main photo), and “Layout shift culprits”, the elements that make the page jump. Then, in the Network tab, filter on Img and compare each image's size with the size it's displayed at.

What it means. A 4,000-pixel photo shown 800 pixels wide, or several megabytes for one image, explains a slow LCP on its own. And a high CLS means some element appears late and pushes the rest: a gallery, a banner, an image without set dimensions.

On our test store. The product page downloaded 280 KB of images on a computer, but 575 KB on a phone. High-density phone screens pick bigger versions of the same photos. PageSpeed suggested saving 41 KB with better image delivery, and listed the layout shift culprits behind our 0.373.

The fix. Resize photos before uploading them, export them in WebP, and keep your image sizes reasonable in WooCommerce's settings. Never delay the loading of the main product photo: it's the one your customer is waiting for. For layout shifts, fix the elements PageSpeed lists, starting with the first one.

Step 7: Why is your WooCommerce admin so slow?

Built into WooCommerce15 minutesNo plugin needed

Symptom. The order list takes seconds to open. Saving a product drags. Your store is fast for customers, but not for you.

Why a cache doesn't help. The admin is never served from a page cache. Every click is built by PHP and the database. On our test store, the order list took about 1.05 seconds to answer, twice as long as a product page.

Test it, in this order.

1. How your orders are stored (HPOS)WooCommerce, Settings, Advanced, Features. “High-performance order storage” is a newer, faster filing system for orders. It's on by default for stores created since WooCommerce 8.2 (October 2023). Older stores may still use the old one.
2. Scheduled actionsWooCommerce, Status, Scheduled Actions. This is WooCommerce's to-do list: emails to send, data to clean. Look at the Pending and Failed counts.
3. WP-Cron, the alarm clockWordPress only works through that to-do list when someone visits your site. A quiet store at night piles up tasks.
4. Open admin tabsEach admin tab left open checks in with your site every 15 to 120 seconds. Ten tabs all day add up.

your-store.com/wp-admin

What it means.

On HPOS, WooCommerce's own benchmark on about 400,000 orders measured order creation about 5 times faster, and checkout about 1.5 times faster (WooCommerce developer blog). That's their large test store, not a promise for yours.

your-store.com/wp-admin

Step 8: Test the cart and checkout

Free tool5 minutesNo plugin needed

Symptom. The “Add to cart” button reacts slowly. The cart or checkout takes a while to show up.

Test it. In the Network tab, type wc-ajax in the filter box and browse a few pages. Does a request called get_refreshed_fragments appear on every page? It's a small background request that refreshes the mini-cart icon. Then load your cart and check its weight and its server response time (step 2).

What it means. Since WooCommerce 7.8 (June 2023), this mini-cart refresh no longer runs on every page by default, only where the mini-cart needs it (WooCommerce developer blog). Many older guides still tell you to disable it. If you still see it everywhere, your theme or a plugin forces it.

On our test store. No fragments request on our pages. But the cart was by far the heaviest page: 862 KB and 80 requests, including 671 KB of JavaScript. That's WooCommerce's block-based cart and the WordPress block libraries it needs, with no extra plugin involved. And since the cart can never be cached, its server time stayed at about half a second, cache or not.

The fix. Make sure your page cache excludes the cart and checkout. Then speed up the server side, since nothing else helps here: recent PHP with OPcache, an object cache (step 3). Finally, check which plugins add fields or scripts to the checkout (step 4).

Step 9: Fix one thing, then measure again

Free10 minutesAfter each fix

Change one thing at a time. Same page, same tool, same device. Run each test 3 times and keep the middle value. Then write it next to your “before” number.

Be patient with PageSpeed's real-user block: it covers the last 28 days, so an improvement takes up to four weeks to show fully. The lab test and your server response time, on the other hand, react right away.

Call a developer if your server stays slow with no plugin to blame, if your database weighs several gigabytes, or if Query Monitor points to your theme.

Your check-up result

Here is the full grid. Find your symptom, and start with the first line that applies to you.

Measure before you buy. Most slow stores don't need another plugin. They need the right one fix.

Our own test store is the proof. Its first problem was a server rebuilding every page, with no page cache and no opcode cache. Then the usual plugins: 0.2 s more server time and almost 400 KB more on every product page. Then a page that jumped, and phone images twice as heavy. Measure in that order, and you won't pay for a fix you didn't need.

And when it's time to clean up your plugin list, keep one question in mind for each of them: does it earn its place on every page?

Johan, founder of Plume

I sell on WooCommerce myself, and I build lightweight plugins out of what I run into with my own stores. Plume is the essentials of a store, without the bloat.