The 20-Minute WooCommerce Speed Audit (No Code, Just a Browser)

6 in 10 WooCommerce stores fail on mobile. You can’t tell whether yours is one.

60.4% of WooCommerce stores fail Google’s Core Web Vitals on mobile (HTTP Archive, June 2026 crawl). Six in ten. On a $10,000-a-month store, shaving a tenth of a second off load time is worth roughly $500 a month — so whether you’re one of the six is a question with a price on it.

You’ve run the test everyone runs: your homepage, on your phone, snapping open fast. Then a customer emails that checkout “hung.” It works when you try it, and the ticket dies.

That $500 comes from a 30-million-session study where a 0.1-second mobile improvement lined up with +8.4% conversions (Deloitte, 2020). Apply it: $6,000 of mobile revenue × 8.4% ≈ $500. A scenario, not a forecast, since those were 37 large retail brands, far bigger than your store. Full derivation in Why Your WooCommerce Store Is Slow.

So guessing costs you twice: once in the months you don’t fix it, once in the invoice you pay the wrong person. Twenty minutes with a browser ends the guessing, because the test you already ran tells you nothing.

Your store has two speeds. You’ve only ever measured one.

Strangers get one speed. Buyers get another.

Your homepage is cached, so it answers fast. Cart, checkout, my-account and logged-in browsing — the money path — run uncached, and nobody measures them in the state that matters, signed in with a cart.

WooCommerce core does it on purpose. It sets DONOTCACHEPAGE on cart, checkout and my-account, and WP Rocket, WP Engine, Kinsta and LiteSpeed honour it. Caches skip anyone carrying a login cookie too. Two exceptions change nothing for the homepage test: some setups cache per user, and a store with no page cache has one slow speed. Checkout bypasses cache either way. The cache-bypass walkthrough covers WC_Cache_Helper and the DONOTCACHE* constants.

Which is why the audit bothers with the server. On mobile, only 13.5% of WooCommerce stores have a good TTFB — the wait before the first byte. Shopify’s is 83.2% (HTTP Archive, June 2026). One company’s CDN against fifty thousand hosts. Read it as an industry pattern, not a diagnosis of your store, and it’s measured on logged-out, cacheable pages too. Most Woo stores fail there before the money path adds anything, so where does the second speed’s time go?

Every slow store is slow in one or more of four legs

The ranked list of reasons stores get slow walked six legs a request runs through. A browser alone can probe four:

• the server leg — how fast your host answers
• the uncacheable work — plugins and queries WooCommerce runs to build a page it can’t cache
• the front end — theme, images, scripts
• the third parties — chat widgets, trackers and payment scripts from someone else’s server

Three hand a browser a number. The uncacheable work leaks a difference.

Each leg leaks a signal a plain browser can read

Start the clock. Five checks across four legs. The uncacheable work gets two, and one of them turns a stopwatch into evidence by timing a single page twice.

Front-end leg: PageSpeed Insights on the three money pages

Run PageSpeed Insights on your homepage, one product page, and the checkout. Read the Mobile tab. 6–9 minutes.

Two warnings. PageSpeed opens checkout logged out with an empty cart. Plenty of stores bounce an empty checkout elsewhere, so check the URL at the top of the results is the one you typed; if it isn’t, write down checkout redirected, not testable here and don’t use that run.

Second, the table applies to the field data section. Those are the real-user numbers from the past 28 days. Checkout often lacks the traffic for them, and no field data is a legitimate result: write down no data. Never read the site-wide summary labelled Origin as your checkout number.

Reading	Good	Needs work	Fail	What it is
LCP	≤2.5s	2.5–4.0s	>4.0s	when the main content paints (web.dev)
INP	≤200ms	200–500ms	>500ms	how fast the page answers a tap (web.dev), field data only
CLS	≤0.1	0.1–0.25	>0.25	how much the layout jumps (web.dev)
TTFB	≤0.8s	0.8–1.8s	>1.8s	wait before the first byte (web.dev); a “rough guide”, not a Core Web Vital

One trap. LCP contains TTFB. Good LCP is 2.5s, good TTFB 0.8s, so the front end gets a 1.7-second budget. LCP 4.2s on TTFB 1.9s leaves 2.3s — over budget, a developer conversation. LCP 3.0s on the same TTFB leaves 1.1s, so your theme is fine and the server owns this one. Both are 75th-percentile figures over different visitors, so the remainder is a size, not a measurement.

One rule-out first: click the element PageSpeed names as your LCP. A hero image you uploaded is your problem, not your developer’s code.

PageSpeed only ever sees the logged-out view. So log in.

Uncacheable-work leg: the logged-in stopwatch test

Log in as a customer, not as admin — the admin view carries overhead no buyer loads. No customer account? In wp-admin, Users → Add New, give it the Customer role, sign in through My account. Do the timing on a second device or with a screen recording; your connection sits inside every number here. 4–5 minutes.

Time one product page logged in. Then open a private window, time the same URL logged out, and subtract. Same page, same server, same network. The only change is the cache the login cookie turns off, so the difference is the uncacheable build. The private window also keeps you logged in.

Then walk the money path: add an item, time the cart and the checkout, and stop short of paying. That’s what a buyer waits through. Report it as it stands; don’t subtract anything, because checkout runs different templates and payment scripts than a product page, so checkout-minus-product-page isn’t clean.

My lines, not Google’s, low confidence: a logged-in page over 3 seconds warns, over 5 fails. For the difference between the two timings, no published line exists at all. So compare it to the logged-out page rather than to a number: a difference bigger than that page’s own time means the uncached work costs more than the whole cached page, however good the seconds look.

Server leg: TTFB, straight off PageSpeed

You already ran this one. TTFB sits in the field data from the first check, so it costs 0 extra minutes. If checkout came back no data, read your homepage’s TTFB. You’re holding server plus network, on a page the cache already helped. Bad there means worse everywhere.

With no field data at all, the lab section carries the fallback — the audit titled “Reduce server response times.” It fails past 600ms, measured live on the URL you asked for (Chrome); as of Lighthouse 13 it sits inside the “Document request latency” insight.

Rule out the network before you blame the host — a redirect chain, or a CDN far from your customers, inflates TTFB while the server behaves perfectly. Use your browser’s find command on the PageSpeed results to search for “redirects.” The item is called “Avoid multiple page redirects.” If you can’t check the CDN, say so rather than claiming a rule-out you can’t make.

Uncacheable-work leg: the plugin suspect list

Open the Plugins screen in wp-admin. Note the inactive ones and the pending updates on the handover list: inactive plugins don’t run, so they’re neglect evidence rather than a cause. Don’t delete anything mid-audit; that’s a decision for after a backup. Then spot-check up to ten of the active ones. “View details” shows the last-updated date, for wordpress.org plugins only, so read the vendor’s changelog for paid extensions; no findable changelog counts as stale. 5 minutes.

Another of my own lines, low confidence — five or more untouched in 12-plus months earns a warning. Plugin count is folklore, and the plugin-count myth covers why the work a plugin executes is what matters. This screen doesn’t measure the leg; it produces the suspect list to hand over.

So it’s a maintenance conversation, the one you can open today. Carefully — don’t deactivate payment, shipping, subscription or integration plugins on a live store to see what happens.

Third-party leg: the provider list already in your PageSpeed run

Scroll past the metrics in that run to the audit list — Insights now, Diagnostics in older versions — and search for “third.” 1–2 minutes. The audit fails when your third parties together block the main thread past 250ms (Chrome). That’s a total across all providers, not a per-provider limit, so twelve small widgets can fail it while no single one looks guilty. If the search turns up nothing, write down no count rather than zero.

My heuristic, low confidence: more than ten providers warns. Read it for the biggest blocking contributors, not the row count. The ones you added — a chat widget, an extra tracking pixel, a second analytics tag — you can cut today. Payment, fraud and consent scripts, and whatever your agency added, are someone else’s call.

The 20-minute arithmetic

Add it up: 6–9 minutes for PageSpeed across three pages, 4–5 for the stopwatch pair, 0 for TTFB, 5 for plugins, 1–2 for third parties. That’s 16–21 minutes of testing — call it twenty once you’ve logged in and written the numbers down. Experiential estimates, and the low end is optimistic; Google doesn’t document how long a PageSpeed run takes.

One check sits outside the 20. Re-run PageSpeed at your busiest hour and again at a dead one, comparing only the lab “Reduce server response times” number — field data won’t move for weeks, but the lab one is live, so contention on a shared host shows up as the gap between runs.

Twenty minutes ranks the legs. Each points at a conversation.

The output is ranked suspicion: who to call first, and what would clear them

• Your host. A bad TTFB with the network ruled out, and a small logged-in difference. Cleared by: a good TTFB on a page the cache didn’t help.
• Your developer. Two ways in. The front end, if LCP minus TTFB is over the 1.7-second budget on a page whose LCP element isn’t a hero image you uploaded. The uncacheable build, if the same-URL logged-in difference is large on a clean TTFB. A clean field TTFB never clears a slow money path; PageSpeed measured where the cache was helping. Cleared by: a small remainder and a small difference.
• You. Third-party providers you added, plus a stale-plugin list you can prune. Cleared by: a short list on both counts.
• Nobody yet, and that’s a result too. Five good readings and a store that still feels slow points at time, not a layer: peak-hour contention, a cron job, a backup window, or a regression too recent for a 28-day window.

So a slow checkout showing neither of those signals is a conversation with both the host and the developer, not a confident single name.

The honest sentence: “The same product page takes 1.4 seconds logged out and 3.6 logged in, checkout takes 5.1, and homepage TTFB is 0.6 with no redirect chain. Most of that is the uncacheable build, so it’s a plugin and developer conversation before it’s a hosting one.”

None of this makes your developer bad. It makes them unmeasured: nobody has handed them a number from the pages that matter.

Whoever you take your sentence to re-measures with their own incentive, and your five readings are how you check their answer before you pay the invoice.

The deliverable is a sentence, not a score

Twenty minutes converts “it feels slow” into one sentence: a number, a name to say it to, and the thing that would prove that name innocent. If that tenth of a second, worth roughly $500 a month, is sitting in your host’s lap, you stop paying your developer to hunt for it, and you finally know whether you’re one of the six.

Key takeaways

• 6 in 10 WooCommerce stores fail mobile Core Web Vitals (June 2026), and only 13.5% have a good mobile TTFB against Shopify’s 83.2%. Your homepage passing proves nothing about a populated checkout.
• Your store has two speeds and buyers only get the uncached one. Time one product page logged in, then the same URL logged out in a private window; the difference is the uncacheable build.
• LCP contains TTFB, so subtract before you blame your theme; a remainder over ~1.7s is the front end. TTFB is server plus network, so rule out redirects and CDN distance first.
• Five checks, twenty minutes, no code, and out comes a name to call plus the reading that clears them. No data is a legitimate result, and a clean TTFB never clears a slow money path.

If the audit turns up a reading you can’t place, I’m happy to point you in the right direction.

---

Where the numbers come from

All sources accessed July 2026. Core Web Vitals figures are stamped “as of the June 2026 crawl” and update monthly; PageSpeed’s panel names and audit titles drift between Lighthouse versions.

• HTTP Archive — Core Web Vitals Technology Report (June 2026 crawl) — 60.4% of WooCommerce stores fail mobile CWV (221,590 of 560,194 origins pass); 13.5% good mobile TTFB for WooCommerce against 83.2% for Shopify. Recomputed from raw counts, 25 July 2026.
• Deloitte / Google, “Milliseconds Make Millions” (2020) — 0.1 s ↔ +8.4% conversions, +9.2% AOV; 37 brands, ~30M sessions; correlational, 2019 data. The $500/month figure applies that rate to a $10k/month store with $6k of mobile revenue — a scenario, not a forecast, and the study’s brands are far larger than the stores this is written for. Full derivation and caveats in Why Your WooCommerce Store Is Slow.
• web.dev — LCP (good ≤2.5s) · web.dev — INP (good ≤200ms; best measured in the field) · web.dev — CLS (good ≤0.1) · web.dev — TTFB (good ≤0.8s, poor >1.8s; “because TTFB isn’t a Core Web Vitals metric, it’s not absolutely necessary that sites meet the ‘good’ TTFB threshold”) · web.dev — Optimize LCP (LCP contains TTFB; the ~40% figure there is a recommended budget allocation for a well-optimised page — the page explicitly warns that converting those percentages into absolute numbers “is not recommended,” which is why this article subtracts measured values instead).
• PageSpeed Insights — about field data — field data requires a URL that is “public (crawlable and indexable)” with enough real-user samples; below that, “PSI will fall back to origin-level granularity,” and below that it shows nothing. This is why checkout frequently returns no field data, and why the origin summary must not be read as a checkout number.
• Chrome / Lighthouse — Reduce server response times — lab-measured server response, fails past 600ms; moved into the “Document request latency” insight as of Lighthouse 13.
• Chrome / Lighthouse — third-party summary — “If the total blocking time is greater than 250 ms the audit fails” — a total across all providers, not a per-provider threshold.
• Cache-bypass mechanism (WC_Cache_Helper, the DONOTCACHE* constants) and cache-plugin behaviour (WP Rocket / WP Engine / Kinsta / LiteSpeed), the relay-leg model, and the plugin-count folklore: cited in depth in Why Your WooCommerce Store Is Slow rather than re-listed here.
• Heuristic thresholds — logged-in page (3s warn / 5s fail), stale plugins (5 or more untouched 12+ months), third-party providers (>10) — are my own low-confidence lines. No official standard exists for any of them, and none at all exists for the difference between the logged-in and logged-out timings, which is why the article reads that one against the logged-out page instead of against a number. The Core Web Vitals and TTFB thresholds above are the primary ones.