SHIFT64 Blog

I Bought the Domain Before I Ran the Test. EmDash Still Lost to WordPress.

Wed, 15 Apr 2026 10:00:00 GMT

TL;DR

I built two parallel content sites with identical posts: one on EmDash + Cloudflare Workers + D1 (emdashcms.pl), one on a hand-coded WordPress theme on Hetzner (emdash.pl). Both sites scaffolded with Claude Code.
I ran 4,732 cold-isolated curl measurements over ~3.5 days (182 runs × 13 pages × 2 sites), plus follow-up runs after every optimization.
WordPress was 6.4× faster on server processing (84 ms vs 543 ms mean). After I rewrote EmDash’s data fetching with server:defer and a batch tag API, the gap narrowed to 4.1× — still 322 ms vs 78 ms.
The Cloudflare paid Workers plan ($5/mo) made things slightly worse, not better.
Jacek Żmudziński, who reviews Search Console crawl stats for a living, looked at the download-time numbers blind. He filed ~1,300 ms in the “scrap and rebuild” tier. The same blind review put well-tuned WordPress in “decent” and Astro in “exemplary”.
After one week of indexing, the WordPress site has 4.3× more clicks, 3.9× higher CTR, and outranks the EmDash showcase site on the EmDash brand query itself (position 3.4 vs 13.7). And the WP site received zero updates the entire time.
I wanted EmDash to win. I was so sure it would that I bought emdashcms.pl before the first measurement. This article exists because the data did not cooperate.
Both repos (EmDash site and the WP comparison theme) are public — linked at the bottom.
In the meantime: come argue with me on X or on LinkedIn.

I read 150 EmDash takes in a week. Maybe 1 in 100 had installed it.

When EmDash launched, my feed turned into a wall-to-wall opinion war.

One side declared EmDash the final nail in WordPress’s coffin. The other side wrote it off as a toy that would never matter. And reading both camps for a week, I had the same dull feeling over and over: almost nobody had actually installed the thing. Maybe 1 post in 100 read like the author had genuinely touched the product. Not the loudest enthusiasts. Not the loudest skeptics. The other 99 were copy-pasting whichever side’s bullet points sounded better and going to bed. A handful had a measured, sober take. The vast majority were retransmitting marketing.

I was firmly in the enthusiast camp. Not “WordPress is dead” enthusiast — I run a WooCommerce performance practice, I know how stubbornly that ecosystem keeps shipping value — but enthusiast in the “this is exactly the missing piece for the small-business segment” sense.

So I did what enthusiasts do. I bought the domain — emdashcms.pl — before I had any measurements. I scaffolded the site in an evening with Claude Code. I was already drafting the migration playbook in my head.

Then I started actually using the site I’d just built.

I keep the Core Web Vitals Test Chrome extension pinned to my toolbar — the kind that sits there and quietly reports LCP, INP and CLS for whatever page I’m on, in real time. On most well-built sites I forget it exists. On a healthy page it does nothing. The icon turns red the moment a metric crosses the “poor” threshold.

Clicking through my own EmDash post pages, that little icon started blinking red. Not catastrophically. Not on every page. Just often enough that I couldn’t pretend I hadn’t seen it. The page I had built specifically to prove how fast EmDash was — was the page lighting up the warning lamp.

That was the moment. I closed the tab, opened a terminal, and started writing the benchmark this article is built on.

What I was hoping EmDash would unlock

This matters, because the disappointment only makes sense if you understand the expectation.

A huge slice of the SMB market sits on WordPress for one reason: a non-technical owner needs to edit the offer, the contact details, the team page, a service description, without filing a ticket. That’s it. They don’t need WooCommerce. They don’t need 47 plugins. They need a CMS.

What they get instead is the WordPress maintenance treadmill: plugin updates, security patches, the occasional surprise white screen, an annual “your site is slow” panic. Marketers and small-business owners I talk to are tired of it.

EmDash, on paper, is the answer to that complaint:

Astro for the runtime — zero-JS by default, edge-deployable, the kind of speed I’d brag about.
A real admin panel — so the client can edit content without touching code.
Cloudflare Workers + D1 — serverless, no server to patch, no PHP version to worry about.
Cloudflare’s blessing — they shipped migration tooling on day one, which sent a strong “this is going somewhere” signal.

If that combination delivered WordPress-grade ergonomics with Astro-grade performance, it would slot directly into the SHIFT64 worldview: own your stack, no reseller margins, no plugin treadmill, fast by construction. I was ready to recommend it.

That’s the bias I walked into the benchmark with. Keep it in mind as you read the numbers.

The setup

I wanted an apples-to-apples comparison, so I took deliberate care with the WordPress site. No Elementor, no page builder, no plugin soup. A hand-coded theme (also scaffolded with Claude Code) modeled on the same content structure as the EmDash site, with only Object Cache running. No full-page cache, no Cloudflare APO, no Varnish.

Why no full-page cache on WordPress? Because EmDash’s Worker still does work on every request — it queries D1, it composes HTML. To compare a cached HTML file against a Worker doing real work would be dishonest. I wanted both backends doing similar amounts of work per request, then measure how long that work actually takes.

	EmDash site	WordPress site
Engine	Astro 6 + D1 (SQLite at edge)	PHP 8.4 + MySQL
Hosting	Cloudflare Workers (serverless)	Hetzner (Frankfurt)
CDN	Cloudflare (native)	Cloudflare (proxy)
URL	emdashcms.pl	emdash.pl
Caching	Official `emdash-blog` template defaults — see below	Object Cache only
Built with	Claude Code	Claude Code
Network path	OVH Warsaw → CF Edge → D1	OVH Warsaw → CF Proxy → Hetzner Frankfurt (~400 km)

What “EmDash defaults” actually means

The EmDash site runs the official emdash-blog starter template unmodified — exactly what a developer gets the first time they scaffold an EmDash project. That template wires up three things adjacent to caching, and it is worth being precise about each, because “default caching” is doing a lot of heavy lifting in most online discussions:

D1 with session: "auto" — in astro.config.mjs, the database binding is declared as d1({ binding: "DB", session: "auto" }). This enables D1’s Sessions API, which is a read-replication / read-after-write consistency hint for D1 itself. It is not a page cache. Every query still goes over the wire.
Per-page cacheHint emission — every page that fetches content does it like this:
```
const { entries: posts, cacheHint } = await getEmDashCollection("posts");
Astro.cache.set(cacheHint);
```
Both getEmDashCollection() and getEmDashEntry() return a cacheHint describing how the result depends on the underlying collection / entry. The template dutifully feeds it into Astro.cache.set() on index.astro, posts/index.astro, posts/[slug].astro and pages/[slug].astro.
A bare Worker handler — src/worker.ts is exactly three lines:
```
import handler from "@astrojs/cloudflare/entrypoints/server";
export { PluginBridge } from "@emdash-cms/cloudflare/sandbox";
export default handler;
```
No caches.open(), no caches.default, no Cache API wrapper, no middleware setting Cache-Control on HTML responses. The only Cache-Control header anywhere in the template lives on the RSS feed (src/pages/rss.xml.ts → public, max-age=3600).

Now the catch. Astro.cache.set() only does anything if there is an experimental.cache provider configured in astro.config.mjs to actually consume the hints. The default emdash-blog template does not configure one — there is no experimental: { cache: ... } block. So in the unmodified template, the cacheHint mechanism is wired up at the call sites, but no consumer exists on the other end. The hints are emitted into a void.

The practical consequence: on the default emdash-blog template, every HTML request — human, curl, or Googlebot — runs the full data-fetching chain against D1 and renders the page fresh. That is the baseline these numbers measure. No HTML caching is in play. The Sessions API is doing what it does for D1 reads, the cache hints are being emitted but not stored, and the Worker is just rendering the page on every hit.

This is also exactly what we ran in the early days of the experiment, before any of the manual optimizations described later in this article. Everything starts from the unmodified starter.

Note one more thing in the table: WordPress has a longer network path. Every WP request hops through Cloudflare’s proxy and then crosses ~400 km to Frankfurt before any PHP runs. EmDash runs at the edge, in theory close to the test server. The geography favors EmDash. That’s important context for what comes next.

Methodology

Parameter	Value
Test period	2026-04-03 16:30 → 2026-04-07 06:28 UTC (~3.5 days)
Total measurements	4,732 (2,366 per site)
Runs	182
Pages tested	13 (homepage + 12 posts, identical content on both sites)
Tool	`curl` with full timing breakdown (`--write-out`)
Test server	OVH VPS, Warsaw
Isolation	New `curl` process per URL — no keep-alive, no client cache
Request order	Randomized per run (kills DNS-cache bias)

The cron schedule varied across three phases to force cold starts — 10-minute baseline (Workers stay warm) → 58-minute gap → 3-hour gap bursts firing :00/:01/:02 to separate cold-start cost from steady-state cleanly. Full phase-by-phase methodology, raw results.csv, and analyze.py in the benchmark repo.

The verdict from someone who reads crawl stats for a living

Before I show you my own numbers, here’s the part that pushed me from “huh, that’s unexpected” to “OK, I have to write this up properly”.

I sent the Search Console crawl-stats charts — just the download-time graphs, no labels, no commentary — to Jacek Żmudziński, Head of GEO & SEO at Makolab. At his level he isn’t personally picking through every client site any more — he runs a team that does — but he spent years living inside Google Search Console before that, and the instinct for what a healthy crawl-stats download-time chart looks like is the kind of thing you don’t unlearn. He grades these in his sleep.

He came back with a four-tier read on what he saw, blind:

Download time band	Jacek’s verdict	Where my sites landed
~1,300 ms	”Scrap and rebuild.”	EmDash post pages on cold starts
Typical for crawl-optimized WP	”Normal, expected”	The hand-coded WP comparison site
Well-tuned WordPress	”Decent”	What good WP hosting looks like
Astro / static-class	”Exemplary.”	The class EmDash should have been in

Two things hit me about this read.

First, the exact tier where Jacek wanted a teardown — the ~1,300 ms zone — is exactly where my cold-start spikes were living. Independent confirmation, with zero knowledge of which technology produced which line.

Second, the same expert had zero complaints about the WordPress site. The hand-coded WP theme, with nothing more than Object Cache, landed in the “normal, expected, optimized for crawl” tier. Astro — which is what EmDash is built on top of — got the “exemplary” gold star.

In other words: the technology choice EmDash is built from gets the highest grade. The execution that EmDash currently delivers gets “scrap and rebuild.” That gap is the whole story.

What Search Console actually shows after one week

Lab numbers are one thing. Field numbers are another. Both domains target the exact same keyword universe (emdash cms, em dash cms, emdash cloudflare, etc.). One was built on the technology I was rooting for. One was the boring control. Both have been in Google Search Console for roughly one week as of this writing:

EmDash site (emdashcms.pl) — submitted to Search Console on 2026-04-02.
WordPress site (emdash.pl) — submitted to Search Console on 2026-04-03, a day later.

(The screenshots below show the “3 months” filter because that’s the GSC default view — but the actual data only exists from the submission dates onward. Everything before April is a flat line.)

Before I show you the numbers, an important fairness note that makes the result worse, not better, for EmDash:

The WordPress site was submitted a day later — less time to accumulate impressions and clicks.
Since publication, the WP site has received zero updates — no new posts, no plugin changes, nothing. Set-and-forget, the way most SMB sites actually live in the wild.
During the same window, the EmDash site received a cache strategy update and three new articles. Active development.

So WordPress had a shorter indexing window, less content, and zero ongoing investment. EmDash had more time, more content, and active engineering. Here is what one week of indexing produced.

WordPress site (emdash.pl) — 1 week in Search Console (submitted 2026-04-03):

EmDash site (emdashcms.pl) — 1 week in Search Console (submitted 2026-04-02):

Search Console (1 week since submission)	WordPress (`emdash.pl`)	EmDash (`emdashcms.pl`)	Winner
Total clicks	65	15	WP — 4.3× more
Total impressions	195	175	~tied
CTR	33.3%	8.6%	WP — 3.9× higher
Average position	3.5	7.1	WP — half the rank
Top brand query — `emdash cms` (clicks)	48	1	WP
Top brand query — `emdash cms` (position)	3.4	13.7	WP
Top brand query — `em dash cms` (position)	2.3	4.3	WP

Read those last three rows again.

The WordPress site — the one I built in a day, never touched again, started a day late — outranks the EmDash showcase site on the EmDash brand query itself. Position 3.4 vs 13.7. Forty-eight clicks vs one. On a query where the EmDash site is, by name, the better topical match.

I want to be careful here. SEO is multi-causal. One week is very short — these numbers will move. Brand attribution is messy. The impression counts are within noise of each other, which suggests Google is showing both sites for similar queries. But two facts are hard to argue with even at this sample size:

Average position differs by half a rank tier (3.5 vs 7.1) — and Google’s ranking signals are dominated by Core Web Vitals, page experience, and crawl health, all of which favor the WP site based on the lab data above.
CTR differs by ~4× (33.3% vs 8.6%) on similar impression volume — which is what you’d expect when one site loads in 100 ms and the other has a 35% chance of a >800 ms cold start during business hours.

I cannot prove from one screenshot pair that performance caused the SEO gap. I can say that the site Jacek filed in the “scrap and rebuild” tier is losing to the site he filed as “normal, expected” on every Search Console metric that counts — and that the tier EmDash was supposed to be in, “exemplary” Astro-class, was a tier it never actually reached. That is not the direction the chart was supposed to go.

The numbers — server processing time

Server processing time is TTFB minus DNS, TCP and SSL. It’s pure backend work: database queries, HTML rendering. It isolates the part you can actually fix.

Metric	EmDash (CF Workers + D1)	WordPress (Hetzner)	Delta	Winner
Mean	543 ms	84 ms	+459 ms	WP — 6.4× faster
Median	543 ms	69 ms	+474 ms	WP
Min	129 ms	42 ms	+87 ms	WP
Max	2,196 ms	246 ms	+1,950 ms	WP
P95	864 ms	148 ms	+716 ms	WP
P99	1,121 ms	234 ms	+887 ms	WP
Std Dev	178 ms	42 ms
CV	32.8%	49.7%		EmDash (more consistent)

WordPress’s worst measurement (246 ms) is faster than EmDash’s best post-page measurement (~400 ms). That’s not a margin you optimize away. That’s a different category of latency.

The CV column is the only place EmDash technically wins. Cloudflare Workers are consistently slow rather than occasionally fast, which matters for capacity planning but does not help your user.

Total TTFB — what the user actually waits for

Metric	EmDash	WordPress	Delta
Mean	596 ms	136 ms	+460 ms
Median	593 ms	116 ms	+477 ms
P95	939 ms	233 ms	+706 ms
Max	2,294 ms	373 ms	+1,921 ms

Network breakdown

Phase	EmDash	WordPress
DNS	3 ms	3 ms
TCP	1 ms	1 ms
SSL	49 ms	47 ms
Server	543 ms	84 ms

Network is identical. The 459 ms gap is entirely backend work. Every chart in this article is really one chart with different y-axes: it’s the cost of fetching a content page from D1 at the edge versus from a local MySQL on the same physical box as PHP.

Per-page comparison — WP wins 13 / 13

Per-page numbers are remarkably consistent. WordPress wins every single one of the 13 tested pages. The EmDash homepage (225 ms) is the only sub-300 ms result EmDash delivers — and it cheats, because the homepage runs a single post-list query. Every EmDash post page clusters at 550–590 ms, because it chains three or more sequential D1 round-trips (entry → tags + related → related tags) at ~50–100 ms each. WordPress covers all 13 pages in 78–91 ms. Full per-page table in the benchmark report.

This is not a code-quality issue. EmDash uses Promise.all() where it can. The dependency chain is what it is. The bottleneck is the architecture, not the implementation.

Cold starts are real and they follow the working day

Once I forced 3-hour gaps to make Workers actually go to sleep, cold starts became the dominant story.

	Mean	Median	P95	Max	n
Cold (`:00`)	649 ms	548 ms	1,121 ms	2,196 ms	260
Warm (`:01`/`:02`)	549 ms	519 ms	703 ms	939 ms	520

The headline number (+18% on average) hides the more important fact: the >800 ms zone is cold-start exclusive. Out of 520 warm requests, exactly 2 crossed 800 ms. Out of 260 cold requests, 50 did. That’s a 48× higher chance of a slow page when the Worker had to spin up.

Cold starts also follow a daily cycle that maps almost exactly to the working day: mildest at 01:00–04:00 UTC (~550 ms average, 8–12% spike rate), worst at 10:00 UTC (745 ms average, 35% of requests crossing 800 ms, max 2.2 s). This correlates with global Cloudflare platform load, which I cannot control. Full hourly breakdown in the benchmark report.

WordPress, for the record, shows zero cold-start effect:

	Mean	Max
WP cold (`:00`)	80 ms	243 ms
WP warm (`:01`/`:02`)	84 ms	239 ms

Negative delta on cold. There is no cold start. PHP-FPM pools are warm because the box never sleeps.

I paid Cloudflare $5 to fix this. It got slightly worse.

Halfway through the experiment, I upgraded the EmDash account from the Free plan to the Workers Paid plan ($5/mo). Cloudflare’s docs don’t promise improved TTFB on the paid plan, but for $5 I wanted to be thorough.

The paid plan gives you more CPU time per request, more total requests per month, and Durable Objects. It does not, as far as I can tell, address D1 latency. The numbers confirm it:

Mean server processing: +72 ms (+14%) on paid vs free — 522 ms → 594 ms
% of requests over 800 ms: jumped from 5.0% to 8.5% on paid
% of requests over 1,000 ms: jumped from 1.8% to 4.3% on paid
WordPress control group moved by 1 ms in the same window — confirms the difference on the EmDash site is real, not test-server noise

After controlling for time of day (matching cold-start hours), paid is still ~52 ms slower on average. The result varies by hour and could be Worker pool placement noise, so I am not going to claim paid is categorically worse. But if you are upgrading because you read somewhere that paid Workers are faster: save your $5. The bottleneck is downstream of anything CPU limits will fix. Full Free-vs-Paid breakdown in the benchmark report.

What I tried to do about it

After the initial benchmark, I went into the EmDash code and did everything I could think of to reduce D1 round-trips. Two changes mattered.

1. `server:defer` on widget areas

Every post page rendered a sidebar (search, categories, tags, recent posts, archives) and a footer widget area before responding. Each widget made its own D1 query. The sidebar alone fired 7 queries on the critical path.

Astro’s server:defer directive moves a component out of the initial response — the page ships immediately with a placeholder, and the deferred component loads via a follow-up micro-request. The work still happens, but it doesn’t block TTFB.

This is not free. server:defer does not apply to components imported from node_modules, so it requires writing thin wrapper components inside the project just to gain access to the directive, plus skeleton fallbacks so the page does not pop when the deferred content arrives. None of it is documented as a thing you have to do. It is not part of the out-of-the-box EmDash experience. Full wrapper pattern + fallbacks are in the EmDash repo, on the perf/server-defer-widgets branch.

2. Killing an N+1 with an undocumented batch API

Every page that lists posts (homepage, archive, post detail with “read more”) was fetching tags per post in an N+1 loop — one D1 query per post. EmDash exposes getTermsForEntries, a batch API that fetches all tags in a single WHERE entry_id IN (...) query. It is undocumented. I found it by reading source. Applied across 5 listing pages (/, /posts, /posts/[slug], /category/[slug], /tag/[slug]). Full before/after diff in the EmDash repo on the perf/server-defer-widgets branch.

What it bought me

Metric	Before	After	Delta
Server mean	542 ms	322 ms	−220 ms (−41%)
Server median	547 ms	317 ms	−230 ms (−42%)
TTFB mean	593 ms	373 ms	−220 ms (−37%)
P95	732 ms	368 ms	−364 ms (−50%)
P99	1,094 ms	424 ms	−670 ms (−61%)
Max spike	2,196 ms	745 ms	−1,451 ms (−66%)
CV (consistency)	29.3%	11.6%	2.5× more stable

41% off the mean, 61% off the P99, max spike cut by two-thirds. That’s a real win — and I’d take it on any project. It is not enough.

Metric	EmDash (optimized)	WordPress	Ratio
Server mean	322 ms	78 ms	4.1× (was 6.4×)
Server median	317 ms	53 ms	6.0×
P95	368 ms	142 ms	2.6×
Max spike	745 ms	245 ms	3.0×

After every optimization I could think of, WordPress is still 4× faster. The remaining ~320 ms is the floor — roughly 8 sequential D1 round-trips at ~40 ms each. There is no code-level fix for that. It is the cost of asking a database that lives at the edge to answer a question that requires three follow-up questions.

And then I added edge caching

Once I’d exhausted the data-fetching optimizations, the only remaining lever was full-page caching. I added a Cache-Control: public, max-age=0, s-maxage=60, stale-while-revalidate=300 header via middleware — 60 s fresh at the edge, then 5 minutes of stale-while-revalidate.

There’s a trap here that ate an hour of my life: Workers on a custom domain bypass Cloudflare’s CDN cache layer by default. The standard Cache-Control header has no effect — responses go straight from Worker to client. To actually cache, the Worker entrypoint has to be wrapped in explicit caches.open() / match() / put() calls. Full middleware + wrapper implementation in the EmDash repo. Once that was in:

Page	Uncached (optimized)	Cached HIT	Improvement
Homepage	294 ms	~150 ms	−49%
Post pages	~325 ms	~110 ms	−66%

Cached EmDash post pages are now faster than uncached WordPress.

I want to be brutally clear about what this proves: nothing. WordPress without caching, vs EmDash with caching, is not a fair comparison. WordPress with WP Super Cache, or Cloudflare APO, or even a basic Varnish, would land in the same sub-100 ms territory. The point of the caching round was not to declare a winner. It was to confirm that edge caching is a workable mitigation for D1 latency, in case you want to ship EmDash to production with eyes open.

It is also exactly the lever that does not help you with the audience that started this whole article.

Why caching does not save you on Search Console

Here’s the part that sealed the verdict for me.

The two domains are still live as of this writing. Since the benchmark ended:

The WordPress site received zero updates. Zero plugin changes, zero new posts, zero touches. Set-and-forget, the way most SMB sites actually live in the wild.
The EmDash site received an updated cache strategy and three new articles. Active development.
I stopped warming the EmDash Worker (no more cron pinging it every 10 minutes). It is now serving traffic the way a real low-traffic SMB site would.

What happened to crawl stats?

The cache strategy update had no measurable effect on crawl response time. And once the warming stopped, cold starts actually got worse. Googlebot is the perfect cold-start victim: it shows up irregularly, often hits URLs nothing else has visited recently, and gets exactly zero benefit from the Worker being warm for human users five minutes ago. Every Googlebot fetch is, statistically, a cold fetch.

Edge caching helps the human user who loads a page that someone else loaded 30 seconds earlier. It does very little for a crawler that walks your sitemap once a day and sees a different URL each time. That’s why Jacek’s blind read landed where it did.

This is also why “just turn on cache” is not the answer for the use case I was originally excited about. If your client’s site needs to rank, the bot’s experience matters. And the bot keeps walking into a cold Worker.

After Jacek read the full article

Jacek Żmudziński — Head of GEO & SEO at Makolab, who already gave the blind verdict on the crawl-stats charts above — read the full preview and wrote back. With his permission, I am reproducing his note here in full, because it puts the SEO/GEO angle on this whole experiment better than I did:

I very often come across WordPress websites that are slow, overloaded with plugins, and create serious Cost of Retrieval issues. This is a key topic in SEO today — search engines pay the real cost of crawling, rendering, and indexing content. In the context of GEO and building visibility in AI, this efficiency matters even more.

WordPress has earned a reputation for being ‘heavy,’ but this benchmark is a real eye-opener. Seeing a hand coded WP theme outperform a modern edge/serverless stack by 6.4x proves that the engine isn’t the problem. It’s the technical debt and poor implementation.

That’s the real WordPress paradox. Plugins are both its biggest advantage and its biggest risk. WordPress itself isn’t the issue; it’s how it’s maintained. A well-built WP site is still a performance benchmark that’s very hard to beat.

The phrase Cost of Retrieval in Jacek’s first paragraph is doing a lot of work and is worth pausing on. It is the unspoken bill on every page of every site you ship — every byte a crawler downloads, every millisecond it waits, every render it has to finish to extract something usable. Crawlers operate on a budget, and they are the ones who decide which pages on your site get re-fetched often enough to stay fresh in the index. A site that costs Googlebot 400 ms per fetch instead of 80 ms is not just “five times slower” in some abstract sense; it is a site that gets re-crawled less often, whose updates land in the index later, and whose answers stay stale longer in the AI summaries that quietly read from the same crawl. That is the real downstream cost the EmDash side of this benchmark is paying — and it is the part Jacek puts a name on that the rest of this article had only been gesturing at.

WordPress is absurdly fast — when you don’t bury it in plugins

I want to take one quick detour from beating up EmDash to do something I almost never see done in 2026: say something nice about WordPress.

Here is what the inside of the WordPress comparison site actually looks like, measured by Query Monitor on production. Same hand-coded theme that produced the 84 ms server-processing mean in the benchmark above. No page builder. No plugin soup. Object Cache + Zend OPcache. That’s it.

Homepage (emdash.pl/):

Post page (emdash.pl/przyszlosc-cms-emdash/):

Metric	Homepage	Post page
Page Generation Time	15.4 ms	37.9 ms
Database Queries	2	3
Total query time	0.3 ms	0.5 ms
Peak Memory	4.3 MB (1.7% of 256 MB limit)	4.3 MB (1.7% of 256 MB limit)
HTTP API Calls	None	None
Object Cache hit rate	93.3% (1,228 hits, 88 misses)	95.1% (1,172 hits, 61 misses)
Opcode Cache	Zend OPcache	Zend OPcache

Read those numbers slowly.

PHP is generating the entire page in 15 milliseconds on the homepage and 38 milliseconds on a post page. The database is being asked 2 or 3 questions, and answering them in under half a millisecond combined. Object Cache is hitting 93–95% of the time, which is why MySQL is barely involved at all. Memory footprint is 4.3 MB on a 256 MB limit. There is no HTTP API call. There is no remote anything.

This is the unfashionable truth of WordPress in 2026: the engine itself is very fast. It is fast in the way a well-tuned C program is fast. PHP 8.4 with OPcache, a sane object cache, a hand-written theme, and a database with no plugin gunk in it — that stack will outrun a lot of “modern” alternatives, and the screenshots above are just the receipts.

The reason WordPress has a reputation for being slow is earned — but earned by the wrong WordPress. By Elementor. By Divi. By bad ThemeForest themes. By “we just installed a caching plugin.” By 47 active plugins each registering its own admin-ajax handler on every front-end page load. By a theme bloater plus three “SEO” plugins plus a contact form plugin plus a Stripe plugin plus a “we needed analytics” plugin. That WordPress will absolutely hand you a 2–3 second TTFB on a shared host. And then someone migrates that monstrosity to a serverless edge stack and reports “WordPress was slow, the new stack is fast.”

Yes — but you didn’t fix WordPress. You moved the bloat off WordPress.

If you take only one thing from this whole article, it should not be “EmDash is bad.” It should be: before you rewrite your stack to escape a slow WordPress site, ask whether you actually have a slow WordPress site, or whether you have a fast WordPress engine being smothered by 47 plugins you can simply uninstall. A hand-coded theme on the same hardware will frequently be the cheaper, faster, less risky migration than any rewrite — including this one.

The hand-coded WordPress here is the boring answer. It is not exciting. It is not on the front page of Hacker News. It is what actually runs almost every business website that has stayed up and ranked for a decade. The reason this benchmark exists at all is that I assumed something newer would do the job better. The data did not cooperate.

Where EmDash might actually win — and why my use case wasn’t it

I want to be careful here, because the wrong takeaway from this article is “EmDash is bad”. It isn’t. It’s wrong for the use case I evaluated it on — and that use case has a name: low-traffic content sites for small businesses, the kind where Googlebot is half your daily traffic and the marketing director updates the team page once a quarter.

If you flip the variables, the picture changes a lot.

Imagine a site with millions of pageviews a month. A news outlet, a high-volume e-commerce content hub, a global SaaS docs site. Everything I measured as a problem in this article inverts:

The Worker is never cold. It serves a steady stream of requests around the clock. The 18% cold-start penalty becomes a rounding error, because almost nothing is ever cold.
D1 reads are hot in local edge caches. The same handful of queries hit the same shards constantly, and the platform’s internal caching layers have actual data to work with.
The edge cache hit rate is high. With enough traffic to keep popular pages warm, s-maxage=60 produces a near-100% hit rate instead of the near-zero rate Googlebot sees on a quiet site.
The operational story is genuinely good. No servers to patch, no PHP version to upgrade, no “your site is down because the host migrated to a new IP.” For a 50M-pageview operation, deleting an entire layer of infrastructure is worth real money — possibly more than the latency gap costs.

I haven’t measured this scenario. I would not be shocked if a high-traffic EmDash deployment looks competitive with — or even beats — a comparably-managed WordPress one, exactly because the cold-start problem disappears at scale and the “no infrastructure” pitch starts paying for itself in real ops budget. That’s a different article and someone else’s measurements.

But that wasn’t my use case. My pitch for EmDash was the opposite end of the traffic curve: small-business sites, hundreds to a few thousand visits per month, content updated occasionally by a non-technical owner. At that traffic level, every dynamic the high-traffic story relies on inverts:

The Worker is cold most of the time, because traffic is sporadic and irregular.
Googlebot is a disproportionately large slice of total hits — and Googlebot fetches are always, statistically, cold.
The edge cache rarely warms up, because there isn’t enough repeat traffic to keep popular pages inside the s-maxage window.
You’re fighting cold starts continuously, on exactly the pages that matter most for SEO.

For that segment — the segment EmDash was supposed to be the small-business answer to — the data in this article is unambiguous: it does not solve the problem I hoped it would solve, and it is measurably slower than the WordPress comparison site I built specifically as a control.

If you’re running a high-traffic content operation and you find yourself in a “no more servers, please” mood, go test EmDash for real — your numbers might tell a very different story than mine, and the operational savings might be the deciding variable rather than the latency gap. But if your job is giving a small-business client a fast, low-maintenance content site that has to rank, this experiment is not encouraging.

What this means for SHIFT64

I started this experiment hoping to add a third tool to the SHIFT64 stack. Right now, the strategy doc is honest about what we ship: Astro for static, WordPress for content-heavy, WooCommerce for commerce. EmDash was supposed to fold into that as “the editable Astro for SMBs”. After 4,732 measurements, I’m not ready to recommend it for that role yet.

Here’s the lens I’m now using. For each of the three use cases I care about:

Use case	What I’d ship today	Why
Static / marketing site	Astro (the way shift64.com itself is built)	Sub-100 ms TTFB without thinking about it. Zero ops.
Content site that an owner edits	WordPress, hand-coded theme, proper hosting	Boring, fast, and the editing experience already exists.
WooCommerce	WooCommerce on dedicated, high-frequency hardware	This is what SHIFT64 actually does for a living.

Where I’d revisit EmDash:

Cloudflare ships D1 read replicas that cut per-query latency by 5–10×. This is the single change that would move EmDash from “4× slower than WP” into “competitive with WP”. It is not currently available.
Astro’s experimental.cache provider lands for the Cloudflare adapter, which would let EmDash do real tag-based purge-on-edit instead of the 60-second s-maxage window. That removes the staleness trade-off without losing the cache benefit.
An EmDash release where server:defer and batch APIs are the default, not the careful manual optimization I had to discover.

If two of those three land, this becomes a different article.

Caveats I want to head off

“You ran an old version.” Maybe. But I worked from the official starter and the documented APIs at the time of testing. If there is a better stack inside EmDash that I missed, it is not in the docs, not in the starter, not in the published examples, and not findable in the time a real consultant would spend evaluating a CMS. That itself is a finding.
“You should have used [X].” If “X” is a configuration that is publicly documented as the recommended setup, please point me to it on X or LinkedIn — happy to re-run.
“You should have tested a ‘realistic’ WordPress site — Elementor, Bricks, page builder, plugin soup.” No, and here’s exactly why. EmDash has no visual page builder. You write .astro template files by hand — that’s the only way to build with it. If I had compared a hand-coded EmDash site against an Elementor WordPress site, the comparison would have been unfairly stacked against WordPress, because page builders add hundreds of milliseconds of overhead that have nothing to do with PHP, MySQL, or how WordPress actually serves a page. So I built the WordPress comparison theme the same way I built the EmDash one: a custom theme, written by hand, no visual builder, no Elementor, no Bricks, no plugin soup pretending to be a CMS. Both sites are doing the identical job — rendering HTML from a hand-coded template against a database — using each platform’s native templating layer. The day someone ships a page-builder plugin for EmDash, I’ll happily re-run with both sides bloated equally. Until then, this is the apples-to-apples version.
“WordPress wasn’t optimized either.” Correct. That was the point. Both backends were doing real work on every request. The numbers on optimized WP would be even better.
“You should have tested it on Node.js. There are no cold starts there.” This is the most interesting objection so far, and it came from Maciek Palmowski after he read the preview. He also pointed out that EmDash runs fast on localhost in dev mode, which is the same observation from a different angle: take the edge round-trip out, and the engine flies. And he is right — EmDash is not strictly Workers-bound. Cloudflare’s own EmDash launch post says explicitly: “serverless, but you can run it on your own hardware or any platform you choose” and “You can run EmDash anywhere, on any Node.js server.” On a long-running Node process with a local SQLite or Postgres, the cold-start problem disappears, the D1 round-trip latency disappears, and the engine almost certainly lands in WordPress-class TTFBs or better, given that V8 + JavaScript is a significantly leaner runtime than PHP-FPM. I have not measured this. Two reasons:
1. I don’t currently have a clean Node-hosting setup to put it on for a proper apples-to-apples test against the same WordPress comparison site. That is fixable; I just haven’t fixed it. If anyone with a tidy Node host wants to re-run my benchmark scripts on their setup, the repos will be public — please go for it, and I will link your results in a follow-up.
2. Running EmDash on Node removes the headline feature. That same Cloudflare launch post is titled “Introducing EmDash — the spiritual successor to WordPress that solves plugin security.” The “solves plugin security” claim depends on plugins executing inside their own “Dynamic Workers” sandboxes — the v8 isolate architecture and the workerd runtime. That sandboxing primitive is a Cloudflare Workers thing. On a vanilla Node deployment, you get the speed, but you lose the plugin isolation model that Cloudflare put in the post title. The trade you are making is “my CMS runs fast but my plugins can do whatever they want to my server” — which is, structurally, the WordPress problem you were trying to escape in the first place.
So: yes, I would expect a Node-hosted EmDash to be fast — possibly faster than my hand-coded WordPress comparison. And I think that benchmark is genuinely interesting and should be run by someone with the right hardware. But it would be measuring a different product than the one Cloudflare actually launched. The product Cloudflare launched is the one I tested: Workers + D1 + plugin isolation. That is the version of EmDash whose performance envelope this article is about.
“The geography helps WP.” Actually it doesn’t — the WP traffic crosses ~400 km to Frankfurt while EmDash runs at the edge in (presumably) Warsaw. WordPress still wins by 6.4×. The longer path is dominated by 84 ms of fast PHP work.

Conclusions

WordPress is 6.4× faster than EmDash on raw server processing for a small content site, because the database access pattern matters more than the runtime fashion.
Aggressive optimization closes the gap to ~4×, but requires non-trivial developer effort and undocumented APIs. WordPress hits its number with zero tuning.
Cloudflare Workers cold starts are real, daily-cycled, and exclusive to the >800 ms zone. They matter most during business hours. They matter most for crawlers.
The Cloudflare paid Workers plan does not improve TTFB. If anything, slightly worse in this test.
Edge caching is a viable mitigation for human users, not for Googlebot. The crawl-stats verdict from a blind expert review confirms this.
EmDash is not currently a drop-in upgrade for the SMB-WordPress segment I was hoping to address. The architecture is fundamentally promising; the current performance envelope is not where it needs to be for that audience.

I don’t need EmDash to win. I want it to be a solid, credible alternative — the kind of thing I can put in front of a small-business client without a list of caveats. I still think the idea — Astro ergonomics, real CMS, no PHP — is worth pursuing. I just can’t recommend it today on the basis of “it will be faster than WordPress”, because the data says it won’t be.

Repos and discussion

Both repositories are public so anyone can re-run the benchmark, push back on the methodology, or extend it:

EmDash benchmark site — full Astro 6 + EmDash + Cloudflare Workers + D1 setup.
- main branch is the bare official emdash-blog starter (the “before” baseline)
- perf/server-defer-widgets branch is the “faster” version — contains the three optimization commits described above (server:defer on widget areas, batched getTermsForEntries, edge caching via Cloudflare Cache API). Includes wrapper components, skeleton fallbacks, middleware, and the Worker entry point wrapped with caches.open().
- /benchmark/ folder contains bench.sh (cron-scheduled curl collector), analyze.py (percentile / distribution analysis), the full report-v2.md, and raw results.csv — everything you need to reproduce the numbers in this article.
- The README also documents the gotchas I ran into along the way: cacheHint emitted without a consumer, server:defer not working on node_modules components, Workers on custom domains bypassing CDN cache, and the architectural D1 latency floor.
WordPress comparison theme (emdash-flavor) — hand-coded theme used as the control site. No page builder, no plugins beyond Object Cache, PHP 8.4 on Hetzner. Includes the seed content XML and the setup scripts that reproduce the exact comparison site from the wp-cli up.

In the meantime, the right place to argue with me is X or LinkedIn. I’d genuinely like to be wrong about this — if you can show me the configuration that gets EmDash to WordPress-class numbers without manually rewriting half the data layer, I will publish the follow-up.

Discuss this article:

Both sites in this benchmark were scaffolded with Claude Code. The benchmark ran 182 randomized runs across 13 pages on each site over ~3.5 days — 4,732 measurements total — plus 30 follow-up runs after each optimization. Raw data, analysis scripts, and both site repos are linked above.

Your First Playwright Test for WooCommerce

Fri, 03 Apr 2026 12:00:00 GMT

Performance Is Worthless If the Store Is Broken

You optimized your TTFB. You tuned Redis. Your Lighthouse score is green across the board.

Then a plugin update silently breaks the “Add to Cart” button. Nobody notices for three days — except your customers, who leave.

Performance tests answer one question: how fast? But there’s a more fundamental question they completely ignore: does it work at all?

That’s what Playwright answers. It launches a real browser, walks through your store like a customer would, and tells you — in seconds — whether the critical paths still function. Add to cart. Checkout. Payment. The flows that directly convert to revenue.

If you’re running a WooCommerce store and you’re not testing these flows automatically, you’re flying blind after every update.

Why This Matters for WooCommerce Specifically

WooCommerce is a plugin ecosystem stacked on top of WordPress. Every update — core, theme, or plugin — is a potential breaking change. And the failures are almost never loud. They’re silent:

A gateway plugin update changes the checkout form markup. The page loads fine. The “Place Order” button does nothing.
A theme update shifts a CSS class. Your cart popup stops appearing. The product page looks normal otherwise.
A WooCommerce minor release changes how shipping methods render. No errors in the log. Customers just can’t select delivery.

You won’t catch these by looking at the admin dashboard. You won’t catch them with uptime monitoring. You catch them by simulating what a customer actually does — clicking through the store, adding products, and completing checkout.

That’s exactly what Playwright does.

Getting Started

Install Playwright

You need Node.js on your machine. Then:

npm init playwright@latest

Accept the defaults. You’ll get a tests/ directory and a playwright.config.ts file. That’s your entire setup.

Write Your First Test

Create tests/woo-add-to-cart.spec.ts:

import { test, expect } from "@playwright/test";

const STORE_URL = "https://yourstore.com"; // Your store URL

test("add product to cart and reach checkout", async ({ page }) => {
  // 1. Open a product page
  await page.goto(`${STORE_URL}/product/sample-product/`);

  // 2. Handle the cookie banner — adjust the selector to match your plugin.
  //    Rejecting cookies keeps the test fast (no tracking scripts loaded).
  await page.getByRole("button", { name: "Reject all" }).click();

  // 3. Find the "Add to Cart" button and verify it's visible.
  //    If it doesn't appear within 5 seconds, the test fails.
  const addToCartButton = page.locator('button[name="add-to-cart"]');
  await expect(addToCartButton).toBeVisible();
  await addToCartButton.click();

  // 4. WooCommerce shows a cart notification after adding a product.
  //    The exact markup depends on your theme — adjust the selector.
  const viewCartButton = page.locator("#cart-popup a.wc-forward").first();
  await expect(viewCartButton).toBeVisible();
  await viewCartButton.click();

  // 5. Verify the product is in the cart — exactly 1 item.
  await expect(page.locator(".cart_item")).toHaveCount(1);

  // 6. Verify the checkout button exists. If it's missing,
  //    something broke in the cart template.
  const checkoutButton = page.locator(".checkout-button");
  await expect(checkoutButton).toBeVisible();
});

Every line with await tells Playwright: finish this step before moving on. Every line with expect is an assertion — if it fails, the test stops and tells you exactly what went wrong.

Run It

npx playwright test

That’s it. Playwright opens a browser, runs the scenario, and reports the result.

Want to watch it happen in real time?

npx playwright test --headed

If the test fails, Playwright saves a screenshot and a trace file. Open the report to step through what happened:

npx playwright show-report

When to Run Tests

You don’t need to run tests after every CSS tweak. But there are moments where skipping them is reckless:

WooCommerce core update — The most common source of silent checkout breakage. New versions can change cart structure, checkout fields, or how payment gateways hook in.
Theme update — Themes control the layout and CSS selectors your tests rely on. A theme update that breaks a test might mean the store is broken — or it might mean you need to update a selector. Check manually first.
Plugin install or update — Especially payment, shipping, and cart plugins. Plugin conflicts are WooCommerce’s greatest hit.
Custom code changes — Custom WooCommerce code, template overrides, new hooks. Easy to break something without noticing.
On a schedule — Even without changes on your end, external services (payment gateways, courier APIs) can go down. A daily or hourly test run gives you early warning before customers start complaining.

For automation, plug your tests into CI/CD (GitHub Actions works well) or schedule a cron job that runs npx playwright test at a set interval.

What to Test Next

One test is a good start. Here’s where to expand:

Product search and filtering — Does the search actually return results? Do category filters work?
Customer login and order history — Can returning customers access their accounts?
Coupon codes — Does the discount apply correctly?
Multiple payment methods — If you offer Stripe, PayPal, and bank transfer, test all three.
Shipping method selection — Can customers choose between delivery options?

Visual Regression

Playwright can also catch things no functional test will — layout shifts, broken styling, elements that moved after an update:

await expect(page).toHaveScreenshot("checkout-page.png");

This compares a screenshot against a baseline. If anything changes visually, the test flags it. Useful after theme updates when the store “works” but looks wrong.

The Full Picture

Playwright tells you the store works. Constant performance engineering as part of WooCommerce Care tells you it stays fast. You need both.

A store that loads in 400ms but has a broken checkout is worse than a store that loads in 2 seconds and actually converts. Start with one test. Run it after every update. Expand from there.

If you don’t want to build and maintain test suites yourself — we offer Playwright testing for WooCommerce as a service. Tests built around your specific store, your plugins, your custom logic. Not generic scripts. Real coverage for the flows that make you money.

Fast WooCommerce Search: An Experiment with RediSearch and SHORTINIT

Sat, 21 Mar 2026 18:00:00 GMT

WooCommerce search is slow. Not because someone wrote it badly — that’s just how WordPress works. Every keystroke in the search field boots the entire engine: plugins, themes, hooks, translations, sessions. By the time WordPress touches the database with your query, 100-300 milliseconds have already passed. The same problem affects checkout pages — it’s a systemic WordPress issue, not a search-specific one.

For autocomplete, where a user types a letter every 50-150 ms, that’s an eternity.

I’ve been experimenting with a different approach: RediSearch as the search engine + SHORTINIT as an ultra-fast WordPress bootstrap. A custom plugin, built from scratch. Early results on a cheap VPS: ~54 ms median full round-trip. Redis itself responds in under 10 ms.

In this post I’ll walk through what I’ve built so far, how it works, and why I think it’s a direction worth exploring.

Why Is the Default WooCommerce Search Slow?

Let’s start with what actually happens when a customer types something into your store’s search field.

A standard WordPress request looks roughly like this:

PHP loads wp-config.php
Loads every active plugin (even the ones that have nothing to do with search)
Loads the theme with all its hooks
Initializes translations, sessions, permissions
Only now fires the SQL query to the database

And that query? By default, WooCommerce searches post titles and content using LIKE '%search_term%'. MySQL can’t optimize this — it has to scan every row in the table.

Result: 30-50 MB of RAM and hundreds of milliseconds before your customer sees the first suggestion.

Plugins like FiboSearch or SearchWP solve part of this problem (FiboSearch Pro uses SHORTINIT internally), but none of the popular plugins use RediSearch as a full-text search engine.

RediSearch — What It Is and Why It Matters

Redis is a key-value database that keeps everything in RAM. It’s commonly used in WordPress as a cache for wp_options and sessions.

RediSearch is a Redis module that adds full-text search capabilities. Since Redis Stack (7.2+), it ships bundled with Redis — but it’s still a module, not a separate database. It enables indexing, prefix matching, and typo tolerance on top of data you already keep in Redis.

Why does this matter? Because Redis operates on RAM and responds in microseconds. In my test on an index of 2,500 WooCommerce products, a typical FT.SEARCH response time is 2-5 ms per query. Practically always under 10 ms.

Compare that to MySQL LIKE, which on the same product count can take 50-200 ms.

SHORTINIT — WordPress Without WordPress

This is where it gets interesting.

WordPress has a built-in constant called SHORTINIT that very few people know about. When you set it to true before loading wp-settings.php, WordPress loads the bare minimum:

wp-config.php (database credentials)
$wpdb (database object)
Core constants (ABSPATH, WPINC)

That’s it. No plugins. No themes. No hooks. No translations.

Instead of 30-50 MB RAM and 100-300 ms of bootstrap, you get ~5-10 MB and under 5 ms to the first line of your logic. The autocomplete endpoint starts faster than WordPress would take to load the list of active plugins.

The Catch

SHORTINIT means no access to wp_options, get_option(), or virtually any WordPress function beyond the raw $wpdb.

How do I deal with this? Plugin settings (Redis host, port, limits, search strategy) are saved to an auto-generated PHP file as define() constants. The config class detects which mode it booted in and picks one of two separate paths: if the MERIDA_SEARCH_REDIS_HOST constant exists, we’re in SHORTINIT and all config comes from constants (early return). Only when the constants aren’t there does it check whether get_option() even exists, and then reads from the database.

One or the other — never a mix. Unconventional, but it works surprisingly well.

Early Results from a Cheap VPS

I tested everything on a cheap VPS with a ~2 GHz processor. Deliberately not on a rocket — I wanted to see what this looks like under realistic conditions for a store that doesn’t spend a fortune on hosting. As I covered in why hosting should be step one, server quality sets the baseline for everything else.

First Observations

Disclaimer: these are sample requests from DevTools, not a full benchmark. Proper performance testing (including proper backend measurement methodology) is planned after confirming usability — meaning after I verify that search results actually make sense to the user. For now, I’m testing whether the architecture holds up.

What I’m seeing at this stage: median autocomplete response time (full cycle: client, server, Redis, response) sits around 50-60 ms. ~80% of requests come in under 90 ms. Redis itself responds practically always under 10 ms — the bottleneck is the network, not the application.

Three Ideas That Made a Difference

I don’t want to turn this into a full tutorial (not yet), but a few concepts are worth flagging — they might be useful to you even in a different context.

Precise First, Loose Later

Instead of immediately firing fuzzy search (which is slower and too liberal — “soap” fuzzy-matches “soup”), I use three passes:

Exact prefix — dryer* — match words starting with the typed phrase. Fastest and most accurate.
Query trimming — remove filler words (“to”, “for”, “the”, “a”) and search again
Typo tolerance — %dryer% — allows minor spelling mistakes, fires ONLY when the previous passes returned nothing

The key rule: if exact matching returns results, typo tolerance never fires. Zero wasted work.

Diacritics Normalization

Product titles are indexed twice: with diacritics and without. A user typing “rak” matches “rąk” (Polish for “hands”). In any e-commerce market with non-ASCII characters, this is essential — customers routinely skip special characters when searching.

Re-Ranking Results After Redis

RediSearch sorts results by how well they match the query textually. But it knows nothing about the store’s context. So after Redis responds, PHP applies corrections: an exact SKU hit goes to the top, out-of-stock products drop in ranking, promoted products rank higher, and titles starting with the search phrase get a boost.

Redis returns 5x more candidates than needed, PHP recalculates scores and trims to the limit.

When Does This Make Sense?

Let’s be honest — for 90% of WooCommerce stores, this is overkill. If you have 200 products and a few dozen daily visitors, FiboSearch (free or pro) will do the job.

This approach starts making sense when:

You have thousands of products and want sub-100 ms round-trip search
You have your own server (VPS or dedicated) where you can install the RediSearch module
You want full control over search logic (synonyms, field weights, re-ranking)
You care about resource efficiency — the autocomplete endpoint uses ~5-10 MB RAM instead of 30-50 MB

On shared hosting this will be difficult — most providers don’t offer Redis with the Search module, and even if Redis is available, loading custom modules is usually not an option. A VPS or dedicated server gives you full control here.

What’s Next?

This is just the beginning. What’s planned:

Thorough testing of search result quality — because speed without accuracy is pointless
Load testing under heavy traffic (many concurrent users, larger indexes)
If the plugin goes to production — a full case study with real data

If this caught your attention, have questions, or want to talk WooCommerce — find me on LinkedIn. You can also leave a comment below.

At SHIFT64 we engineer WooCommerce performance for a living — from ongoing care and monitoring to custom solutions like this one. If your store could be faster — let’s talk.

Why Your WooCommerce Checkout Is Slow (And It's Not What You Think)

Thu, 05 Mar 2026 12:00:00 GMT

Why Your WooCommerce Checkout Is Slow (And It’s Not What You Think)

The Page You Can’t Cache

Every speed optimization guide starts the same way: install a caching plugin, enable a CDN, compress your images. And for 90% of your pages, that works. Homepage? Cached. Category pages? Cached. Product pages? Mostly cached.

But your checkout page is different.

Checkout contains user-specific data — cart contents, shipping address, tax calculations, payment tokens. No caching plugin can touch it. Every single checkout load runs the full PHP execution pipeline, hits the database, calls external APIs, and renders the result from scratch.

Your checkout page runs at bare server speed. Always.

That’s why a store can score 95 on Lighthouse and still have an 8-second checkout. The cache hides the problem everywhere else. Checkout exposes it.

And here’s the business case: Google and Deloitte’s “Milliseconds Make Millions” study found that a 100ms improvement in page load time produces an 8.4% increase in retail conversions. On checkout — the page where purchase decisions happen — every millisecond of latency is directly correlated with lost revenue.

How Bad Is It? Let’s Look at the Numbers

One Reddit user ran a clean test: fresh WordPress install, default Twenty Twenty-Four theme, all plugins deactivated except WooCommerce itself. The wc-ajax=update_order_review call — the AJAX request that fires every time the checkout page updates — took 700-1100ms.

That’s nearly a full second of server response time with zero plugins, zero customization, and a stock theme. The overhead is coming from WooCommerce itself: stock checks, shipping calculations, tax logic, payment gateway validation. All of it runs on every checkout page load — even if you don’t use half of those features.

Now add what a real store looks like:

Layer	Latency added	Source
WooCommerce core checkout logic	700-1100ms	Reddit benchmark, minimal setup
Stripe payment gateway	+1000-2500ms	GitHub issue #1261, 3.5x slowdown vs. cash-on-delivery
Real-time shipping rates (USPS/UPS API)	+200-800ms	External API round-trip
Tax calculation (Avalara)	+100-500ms	External API round-trip
reCAPTCHA validation	+100-300ms	Google API round-trip
Order Attribution Tracking	+50-200ms	WooCommerce default since 8.5

Add those up. A “normal” WooCommerce checkout with Stripe, one shipping API, and a tax service is doing 2-5 seconds of server-side processing before the browser even starts rendering the response. And this is before we talk about frontend JavaScript.

One developer on r/woocommerce summed it up: “What’s the #1 thing that slows down your WooCommerce store?” — The top answer, with the most upvotes: “It’s WooCommerce itself.”

The Four Layers of Checkout Latency

Most guides treat checkout slowness as a single problem. It’s not. There are four distinct layers, and you need to diagnose which one is killing you before you can fix it.

Layer 1: The Server

PHP is single-threaded. When a customer clicks “Place Order,” WooCommerce processes the entire checkout sequence — validate cart, calculate taxes, create order, call payment gateway — on one CPU core, in one line. It can’t split this across multiple cores. It can’t parallelize.

This means the clock speed of that single core determines your checkout speed. A server with 8 cores at 2.3 GHz will process checkout slower than a server with 2 cores at 5.0 GHz. More cores handle more concurrent requests — but each individual checkout runs only as fast as one core can go.

Most managed hosting providers run older server-grade processors (Intel Xeon, AMD EPYC) at 2.0-2.5 GHz. These are designed for density — packing thousands of tenants onto shared hardware — not for single-threaded speed. A high-frequency AMD Ryzen 9 at 5.0+ GHz processes the same PHP code roughly twice as fast per request. That’s the difference between a 1.5-second checkout and a 0.75-second checkout. Physics, not software.

How to check your CPU: SSH into your server and run:

lscpu | grep "Model name\|MHz"

If you see “AMD EPYC 7xx1” at 2.0 GHz on a shared host — that’s a hardware ceiling no plugin can overcome.

OPcache is critical for checkout. OPcache stores pre-compiled PHP bytecode in memory so PHP doesn’t recompile scripts on every request. On cached pages, this barely matters — the page is served from HTML cache anyway. On checkout, it matters enormously, because every request runs the full PHP stack.

One Reddit user discovered that two identical WooCommerce stores on the same hosting had drastically different checkout speeds. The difference? OPcache wasn’t enabled after a PHP version upgrade on the slower one. “This made such a big difference on AJAX functions (eg add to cart etc).”

Recommended minimum:

opcache.memory_consumption=256
opcache.max_accelerated_files=20000
opcache.revalidate_freq=60

Layer 2: The Database

Every checkout triggers dozens of database queries. The two biggest offenders:

The autoloaded options problem. On every page load (including checkout), WordPress runs:

SELECT option_name, option_value
FROM wp_options
WHERE autoload = 'yes'

This loads every autoloaded option into memory. On a fresh WordPress install, that’s a few hundred KB. On a mature WooCommerce store with 30+ plugins, it can exceed 10MB. And here’s the real problem: the autoload column has no index by default. On a wp_options table with 50,000+ rows, this single query can take hundreds of milliseconds.

Check your autoload size:

SELECT SUM(LENGTH(option_value)) AS autoload_bytes
FROM wp_options
WHERE autoload = 'yes';

If it’s over 1MB, you have a problem. Over 5MB, it’s an emergency.

The postmeta bloat problem (legacy order storage). If you’re still using WooCommerce’s legacy order storage, every order creates 1 row in wp_posts and ~29 rows in wp_postmeta. A store with 50,000 orders has over 1.4 million rows in postmeta. The JOIN queries that WooCommerce runs during checkout slow to a crawl.

The fix: migrate to High-Performance Order Storage (HPOS). HPOS replaces the wp_posts/wp_postmeta model with optimized dedicated tables. Benchmarks show:

5x faster order creation
1.5x faster checkout throughput under concurrent load
40x faster admin order filtering

If you haven’t migrated yet, this is likely your single biggest database bottleneck.

Layer 3: External APIs (The Silent Killer)

This is the layer most optimization guides miss entirely.

During a typical checkout, WooCommerce makes multiple blocking HTTP calls to external services:

Payment gateway — Stripe processes the charge (1-3 seconds round-trip)
Shipping rates — USPS/UPS/FedEx APIs return real-time shipping options (200-800ms)
Tax calculation — TaxJar or Avalara calculates tax in real-time (100-500ms)
Address validation — Some setups validate the shipping address against external databases
Fraud prevention — reCAPTCHA or similar services verify the customer

Each of these is a synchronous HTTP call. PHP waits for each response before continuing. They don’t run in parallel — they stack.

The compounding is brutal. Take a checkout with Stripe + USPS real-time rates + Avalara tax + reCAPTCHA:

Stripe API:     ████████████████ 1800ms
USPS API:       ██████████       500ms
Avalara API:    ████████         400ms
reCAPTCHA:      ████             200ms
                                 ─────
Total blocking:                  2900ms

That’s nearly 3 seconds of waiting — and none of it is your server’s fault. Your PHP code is literally idle, waiting for external services to respond. No amount of server optimization will fix this. You need to either reduce the number of external calls or find ways to make them non-blocking.

How to find hidden API calls: Install Query Monitor and check the HTTP API Calls panel on your checkout page. You may discover plugins making calls to dead endpoints — one developer found that old, forgotten plugins were making API calls to services that no longer existed, and the timeout on those calls was adding 5-10 seconds per request.

Layer 4: The Frontend

After the server finishes processing, the browser still needs to render the checkout page. This is where payment gateway JavaScript creates problems.

Stripe’s JavaScript overhead: The official Stripe plugin loads 3 stylesheets globally, injects scripts on product pages (not just checkout), creates an analytics iframe, and sets cookies — all without regard for consent APIs. One developer documented that after simply enabling the Stripe plugin, the checkout JS payload increased significantly and the payment buttons took 10-15 seconds to render on a budget host.

The checkout block paradox: WooCommerce’s newer block-based checkout loads approximately 300 KB of compressed JavaScript — roughly 3x larger than the classic shortcode checkout. The request count nearly doubles. However, WooCommerce’s own data shows a 27% increase in checkout conversions from the block checkout due to better UX. Faster isn’t always better if the UX is worse.

Theme overhead on checkout: Multipurpose themes (Flatsome, Woodmart, Divi) load their entire CSS/JS stack on every page — including checkout. Sliders, animations, megamenu scripts, font libraries. None of it is needed on checkout. One developer reported that switching from a commercial theme to a custom lightweight theme cut their checkout page load from 6 seconds to 2.8 seconds.

How to Diagnose Your Specific Bottleneck

Don’t guess. Measure.

Step 1: Isolate server response time

Open your browser DevTools, go to your checkout page, and find the main document request in the Network tab. Look at the TTFB (Time to First Byte).

TTFB	Diagnosis
< 200ms	Excellent. Your server isn’t the problem.
200-500ms	Acceptable. Room for optimization but not critical.
500-1000ms	Slow. Server-side investigation needed.
> 1000ms	Your server is the primary bottleneck.

Step 2: Install Query Monitor

Query Monitor is the single most useful diagnostic tool for WooCommerce performance. On your checkout page, check:

Queries by Caller — which plugins generate the most database queries?
Slow Queries — any query over 50ms is a red flag
HTTP API Calls — which external APIs are being called, and how long each takes?
Autoloaded Options — how much data is being autoloaded?

Step 3: Check the wc-ajax=update_order_review call

This AJAX request fires every time the checkout page updates (changing shipping method, entering an address). Open Network tab, filter by “update_order_review,” and watch its timing. This is the purest measure of your checkout’s server-side performance.

Step 4: Test with a baseline

Create a simple PHP file on your server:

<?php echo microtime(true); ?>

Measure its TTFB. If even this takes 500ms+, your server itself is the bottleneck — before WordPress, before WooCommerce, before any plugin. This tells you whether the problem is infrastructure or application.

What Actually Works (Not “Install a Caching Plugin”)

Based on the diagnosis above, here’s what to fix — in order of impact.

If your TTFB is over 1 second: fix the server first

No plugin can overcome slow hardware. If your server runs at 2.0 GHz on shared infrastructure, the checkout will be slow regardless of what you optimize. The single highest-impact change is moving to dedicated high-frequency CPU. We’ve benchmarked WooCommerce checkouts on AMD Ryzen 9 (5.0+ GHz) vs standard Xeon hosts — the difference is typically 40-60% faster server response time, which translates directly to checkout speed.

If Query Monitor shows 200+ database queries: fix the database

Migrate to HPOS if you haven’t. 5x faster order creation is not a marginal improvement.
Audit autoloaded options. Disable autoload on everything that isn’t needed on every page.
Clean orphaned data. _wc_session_ entries, transients, revision postmeta — these accumulate silently.

If external API calls dominate: reduce blocking calls

Use flat-rate or table-rate shipping instead of real-time carrier APIs where possible. Real-time rates look nice but add 200-800ms per checkout. If your shipping is predictable, pre-calculate it.
Evaluate your tax solution. TaxJar responds in under 20ms. Avalara can take hundreds of milliseconds. If you’re using Avalara, consider whether the additional complexity is worth the latency.
Audit payment gateway plugins. Run checkout with each gateway individually and compare timing. Stripe’s documented 3.5x overhead is gateway-specific — alternatives may be faster for your use case.
Remove dead endpoints. Query Monitor’s HTTP API panel reveals plugins calling APIs that no longer exist. The timeout on those calls can add 5-30 seconds.

If frontend JavaScript is the bottleneck: audit what loads on checkout

Disable plugins per page. Tools like Asset CleanUp or Perfmatters let you prevent non-essential plugins from loading CSS/JS on checkout. Your countdown timer, your popup plugin, your slider — none of them belong on checkout.
Evaluate the checkout block vs shortcode. Block checkout is heavier (3x JS) but converts 27% better. Test both and measure conversion rate, not just page speed.

The Uncomfortable Truth

Most WooCommerce speed guides are written by hosting companies or plugin vendors. Their advice naturally gravitates toward what they sell — “upgrade your hosting plan” or “install our optimization plugin.”

The reality is more nuanced. Checkout latency is a compounding problem across four distinct layers, and the fix depends entirely on which layer is your bottleneck. A caching plugin won’t help because checkout can’t be cached. A faster CDN won’t help because the latency is server-side. And “disabling plugins” is a blunt instrument that often breaks functionality you need.

The approach that actually works: measure each layer independently, identify the dominant bottleneck, and fix that first. Then move to the next layer.

Every update we deploy through WooCommerce Care goes through this exact diagnostic process. We profile the checkout, identify where the milliseconds are hiding, and eliminate them layer by layer — server tuning, database optimization, API audit, frontend cleanup. Then we verify with automated Playwright tests that the entire purchase flow still works end-to-end.

If your checkout takes more than 2 seconds and you’re not sure where the latency lives — that’s exactly what we diagnose.

Checkout Speed Diagnostic Checklist

Before optimizing, measure:

Checkout TTFB (browser DevTools > Network > main document)
wc-ajax=update_order_review response time
Total database queries on checkout (Query Monitor)
Autoloaded data size (SQL query above)
External HTTP API calls and their timing (Query Monitor)
JavaScript payload size on checkout page
PHP baseline TTFB (test.php with just echo microtime())
CPU model and clock speed (lscpu)
OPcache status (php -i | grep opcache)
HPOS migration status (WooCommerce > Settings > Advanced > Features)

The Staging Paradox: Why a Perfect Copy of Production Is a Ticking Time Bomb

Wed, 04 Mar 2026 12:00:00 GMT

The Staging Paradox: Why a Perfect Copy of Production Is a Ticking Time Bomb

The Mantra Everyone Gets Wrong

“Never test in production.”

Every WordPress developer knows it. So we clone the production database to a staging domain, check that the site loads, and move on with our day. Responsible engineering. Problem solved.

Except that staging site just sent 800 abandoned cart emails to real customers. With discount codes. For carts they already purchased.

A perfect 1:1 copy of production is not a safe testing environment. It’s production running on a different domain.

Every cron job, every API key, every webhook endpoint, every sending queue - it all came along in the database dump. And unless you actively neutralize every one of those connections, staging is just production with a false sense of security.

What Went Wrong: A Real Scenario

Here’s what a typical WooCommerce staging disaster looks like.

The store: WooCommerce with ShopMagic for abandoned cart recovery, Stripe for payments, GA4 tracking conversions, and webhook integrations to a fulfillment center.

What the developer did: Cloned the database. Checked that the homepage loads. Started working.

What happened within 24 hours:

Event	Business impact
ShopMagic’s abandoned cart cron job fired	Hundreds of customers received “You forgot something!” emails with discount codes for carts they’d already purchased
GA4 kept tracking	Conversion data polluted with test transactions, skewing ROAS calculations for weeks
Webhook fired on test order	Fulfillment center received and shipped a test order to a real address

Dozens of customer complaints. Corrupted analytics. Damaged trust.

All from a “safe” staging environment.

The Contradiction at the Core of Staging

A useful staging environment has to satisfy three requirements that directly conflict with each other:

1. Functional parity. You need the same code, plugins, themes, and configurations that run in production. Staging with deactivated plugins or different versions gives you false confidence - you’re testing something that doesn’t exist in production.

2. Data isolation. No data can escape to external systems. No emails to customers, no analytics events, no webhook calls to production endpoints, no real payment processing.

3. Sandbox mode. Where full isolation isn’t possible (payment gateways, external APIs), you need test credentials that mirror production behavior without real-world consequences.

The conflict is obvious: you want ShopMagic active so you can test abandoned cart recovery, but you can’t have it emailing hundreds of real customers about carts they already purchased.

Most developers resolve this conflict by breaking requirement #1 - they deactivate plugins. That’s the wrong answer.

Five Ways Developers Get This Wrong

1. Deactivating plugins instead of neutralizing them

The instinct is to deactivate ShopMagic or whatever else looks dangerous. But now you can’t test whether your abandoned cart sequence fires at the right time, whether the discount code generates correctly, whether the email template renders your product data. You miss bugs in automation logic and plugin interactions. You’re testing a system that doesn’t match production.

The answer isn’t deactivation. It’s neutralization - keep the plugin running, but sever its external connections. The automation still fires, the email still generates - it just lands in MailHog instead of a real inbox.

2. Relying on plugin “test mode” settings

“The plugin has a test mode checkbox. I’ll just enable it after sync.”

The problem: those settings live in the database you just cloned. Production values overwrite whatever you configured last time. Miss one plugin, and you have a data leak.

3. Trusting `WP_ENVIRONMENT_TYPE`

“My plugins detect the environment automatically.”

Many plugins ignore WP_ENVIRONMENT_TYPE entirely. Legacy code paths bypass environment checks. Third-party integrations don’t follow WordPress conventions. This constant is a hint, not a guarantee.

4. Manual checklists

A 47-point staging setup checklist sounds thorough until someone adds a new plugin and forgets to update it. Or a junior developer inherits the project. Or you’re under pressure on a Friday afternoon and skip three steps.

Humans are unreliable. Automation isn’t.

5. Forgetting background processes

You deactivated the email plugin, but WP-Cron jobs are still queued. Action Scheduler tasks persist in the database. Plugin-specific scheduled tasks fire regardless of what’s active in the admin panel.

Deactivating a plugin doesn’t clear its queue. The damage is already loaded.

The Right Approach: Neutralize, Don’t Deactivate

The pattern we use across WooCommerce Care deployments is straightforward:

Keep every plugin active. Cut every external connection.

This means: replace production API keys with sandbox credentials, route all email through a local catch-all, swap analytics IDs with dummy values, redirect webhooks to null endpoints, and clear every background queue.

The staging site should behave identically to production in every way - except nothing escapes.

The Universal Email Trap

The simplest, most reliable safety net is an MU-plugin that intercepts every email WordPress sends and redirects it to a single catch-all address. This works regardless of which plugin sends the email - WooCommerce, ShopMagic, membership plugins, custom code, anything that uses wp_mail().

wp-content/mu-plugins/staging-email-trap.php

<?php
/**
 * Plugin Name: Staging Email Trap
 * Description: Redirects all emails to a single catch-all address on non-production environments.
 */

if (defined('WP_ENVIRONMENT_TYPE') && WP_ENVIRONMENT_TYPE !== 'production') {

    add_filter('wp_mail', function($args) {

        $catch_all = 'staging@example.com';

        // Preserve original recipient
        $original_to = is_array($args['to']) ? implode(', ', $args['to']) : $args['to'];
        $args['subject'] = '[STAGING → ' . $original_to . '] ' . $args['subject'];

        // Redirect email
        $args['to'] = $catch_all;

        if (!empty($args['headers'])) {

            $is_string = is_string($args['headers']);

            $headers = $is_string
                ? preg_split('/\r\n|\r|\n/', $args['headers'])
                : $args['headers'];

            $headers = array_filter($headers, function ($header) {
                $header = trim($header);
                return stripos($header, 'cc:') !== 0 && stripos($header, 'bcc:') !== 0;
            });

            $args['headers'] = $is_string
                ? implode("\r\n", $headers)
                : $headers;
        }

        return $args;

    }, 1);

}

How it works:

On any non-production environment, it intercepts every wp_mail() call
Rewrites the recipient to your catch-all address
Prepends the original recipient to the subject line so you can see who would have received it
Strips CC and BCC headers to prevent any leakage

Why this is better than plugin-by-plugin neutralization:

One file, covers everything
Works for plugins you haven’t audited yet
Works for custom code that sends email directly
Doesn’t require understanding each plugin’s internals
The email still generates and sends - you can inspect templates, content, timing - it just lands safely in your inbox instead of a customer’s

What this doesn’t catch. The wp_mail filter only intercepts emails that go through WordPress’s built-in mail function. Three categories of plugins bypass it entirely:

Direct PHPMailer usage. Some plugins instantiate PHPMailer directly instead of calling wp_mail(). In our stack, we disable PHPMailer’s default send method at the server level - which is good practice for other reasons too (deliverability, logging, security). But if your setup allows raw PHPMailer, the trap above won’t see those sends.
External API senders. Plugins that send via Mailgun, SendGrid, or Brevo API calls never touch wp_mail() at all. The email leaves PHP as an HTTP request to a third-party API - invisible to any WordPress mail filter.
Plugins with their own SMTP stack. MailPoet’s Bridge service, some transactional email plugins, and certain SMTP plugins maintain their own sending connection. They bypass both wp_mail() and PHPMailer.

The takeaway: audit your plugin stack. Run a test email from every plugin that sends mail and check whether it lands in your catch-all. If it doesn’t - that plugin is bypassing wp_mail() and needs its own neutralization (API key removal, endpoint blocking, or the plugin-specific MU-plugin approach we show in the MailPoet case study below).

The Post-Sync Sequence

After importing the production database to staging, run this sequence before any WordPress bootstrapping:

# 1. Temporarily deactivate plugins that auto-execute on load
wp plugin deactivate mailpoet woocommerce-gateway-stripe --quiet

# 2. Run neutralization (swap keys, sanitize data, clear queues)
wp eval-file neutralize-staging.php

# 3. Reactivate with safe configuration
wp plugin activate mailpoet woocommerce-gateway-stripe --quiet

# 4. Verify
wp cron event list --format=table
wp eval "wp_mail('test@staging.local', 'Test', 'Body');"
# ↑ This should land in MailHog, not real SMTP

The deactivate-neutralize-reactivate sequence is critical. Some plugins fire hooks on activation that would use the production credentials still in the database. You need the credentials swapped before the plugin loads.

Case Study: Neutralizing MailPoet

MailPoet is a good example of why staging neutralization matters. It stores sending queues and subscriber data in custom database tables, can take over WooCommerce transactional emails, and connects to an external sending service (MailPoet Bridge) for the paid version.

The question with any email plugin on staging is: will it actually send? The paid MailPoet sending service may reject sends from a mismatched staging domain - but “may” isn’t good enough when 50,000 real subscriber emails are in the database. The safe approach is to neutralize regardless, so you never have to wonder.

Step 1: Kill the sending pipeline

-- Force MailPoet to use PHP mail() (which we route to MailHog)
UPDATE wp_mailpoet_settings
SET value = 'website'
WHERE name = 'mta_group';

-- Remove API keys that authenticate with MailPoet's bridge
DELETE FROM wp_mailpoet_settings
WHERE name IN ('premium_key', 'mss_key');

Step 2: Clear every queue

DELETE FROM wp_mailpoet_scheduled_tasks
WHERE status IN ('scheduled', 'paused');

TRUNCATE TABLE wp_mailpoet_sending_queues;

Step 3: Sanitize subscriber data

UPDATE wp_mailpoet_subscribers
SET email = CONCAT('user_', id, '@mailhog.staging.local')
WHERE email NOT LIKE '%@yourcompany.com';

Even if something slips past steps 1 and 2, the emails go to fake addresses that route to your local catch-all.

Defense in depth: the MU-plugin safety net

SQL neutralization handles the database. But for an extra layer of protection, deploy a must-use plugin that blocks MailPoet’s external connections at the PHP level:

wp-content/mu-plugins/staging-safety-mailpoet.php

<?php
/*
Plugin Name: MailPoet Staging Safety
Description: Neutralizes MailPoet on non-production environments
*/

if (defined('WP_ENVIRONMENT_TYPE') && WP_ENVIRONMENT_TYPE !== 'production') {

    // Kill MailPoet's independent cron system
    add_filter('mailpoet_cron_enabled', '__return_false');

    // Inject error into the sending pipeline
    add_filter('mailpoet_sending_methods_errors', function($errors) {
        $errors[] = 'STAGING SAFETY: Sending blocked by mu-plugin';
        return $errors;
    });

    // Block all requests to MailPoet's bridge service
    add_filter('pre_http_request', function($response, $args, $url) {
        if (strpos($url, 'bridge.mailpoet.com') !== false) {
            return new WP_Error('staging_block', 'Blocked on staging');
        }
        return $response;
    }, 10, 3);
}

This MU-plugin loads before MailPoet does. Even if someone restores the production database and forgets to run the neutralization script, the safety net catches it.

That’s three independent layers: database neutralization, email sanitization, and a PHP-level block. All three would have to fail simultaneously for a real email to escape.

The Neutralization Matrix

Every plugin with external connections needs the same analysis. Here’s the reference:

Plugin	Risk	Neutralization
Stripe	Real charges	Swap to test API keys (well-documented test mode)
PayPal	Real charges	Sandbox credentials
GA4 / GTM	Analytics pollution	Dummy measurement ID
Meta Pixel	False conversion events	Test pixel ID or block outbound requests
ShopMagic	Abandoned cart emails to real customers	Dequeue scheduled automations + route email to catch-all
WooCommerce Subscriptions	Recurring charges on real cards	Test gateway + test mode flag
MailPoet	Mass email, sender reputation damage	Switch to PHP mail() + sanitize subscribers + clear queues
Klaviyo / Mailchimp	List pollution, real email sends	Disconnect API or swap to test account
Membership plugins	Renewal emails to real members	Route email to catch-all + clear scheduled renewals
Zapier / Webhooks	Triggers production automations	Null endpoints or staging-specific URLs
Action Scheduler	Fires queued tasks from production	Purge pending/scheduled actions

For each plugin: identify where credentials live (wp_options, custom tables, wp-config constants), write the neutralization SQL, automate it with WP-CLI, and add a safety-net MU-plugin if the risk justifies it.

Automate or Accept the Risk

The neutralization steps above aren’t complicated. The problem is consistency.

On your tenth staging sync, at 6 PM on a Friday, with a client waiting for a fix - that’s when steps get skipped. That’s when someone forgets that the new Klaviyo integration wasn’t in the original checklist.

The answer is a post-sync script that runs automatically:

#!/bin/bash
# post-sync.sh - runs immediately after database import
set -e

echo "=== Staging neutralization ==="

# Deactivate plugins that auto-execute
wp plugin deactivate mailpoet woocommerce-gateway-stripe --quiet 2>/dev/null || true

# Run neutralization
wp eval-file neutralize-staging.php

# Reactivate with safe config
wp plugin activate mailpoet woocommerce-gateway-stripe --quiet

# Clear all caches
wp cache flush
wp rewrite flush

echo "=== Staging secured ==="

Commit this script to the repository. Run it as part of every sync. No exceptions.

Over time, you build a neutralization library - one script per risky plugin. New project? Apply the relevant scripts. New plugin added to production? Audit it, write the neutralizer, add it to the pipeline.

Once the staging environment is neutralized, the next step is verifying that everything still works. Automated Playwright tests can walk the full purchase flow - add to cart, checkout, payment, order confirmation - on the neutralized staging clone before anything touches production.

The Paradox, Resolved

The ideal staging environment is not a perfect copy of production. It’s a functionally identical but externally dead mirror.

You’re not testing whether ShopMagic can send abandoned cart emails - it can. You’re testing whether your automation triggers at the right time, whether the discount code generates correctly, whether the email template renders your product data.

The email itself lands in MailHog. You inspect it. No consequences.

Test the same code. Capture the same events. Let nothing escape.

That’s not a compromise. It’s the only way staging actually works.

This process - staging neutralization, automated verification, safe deployment - is exactly what we deliver as part of WooCommerce Care. Every update goes through a sterile staging environment before it touches production. If you’re tired of crossing your fingers after every deploy, let’s talk.

Staging Safety Checklist

Before declaring your staging environment ready:

All email routed to a local catch-all (MailHog, Mailtrap)
Payment gateways using sandbox/test API keys
Analytics IDs replaced with dummy values
Marketing pixels disabled or using test accounts
Webhook endpoints redirected to staging or null URLs
Background queues cleared (WP-Cron, Action Scheduler, plugin-specific)
All production API keys replaced with sandbox equivalents
Customer and subscriber emails sanitized
License keys removed or replaced with dev licenses
MU-plugin safety net deployed
Post-sync script tested, committed, and running automatically

Why Hosting Should Be Step One in WordPress Optimization

Sun, 08 Feb 2026 16:51:25 GMT

There’s a recurring pattern in the WordPress world: a client reports that their site is slow. The specialist dives into profiling, analyzing database queries, trimming plugins. Hosting? Left untouched. After all, you should optimize what you have before throwing money at hardware.

Sounds reasonable - and in many cases it is. But there’s a line beyond which this approach becomes fundamentally wrong.

That line is where a server returns multi-second TTFB on a simple business site - Gutenberg, 7 plugins, no WooCommerce, no Elementor - without any caching.

A site like this on a decent host should achieve a TTFB of 200-300 milliseconds with zero caching. Google considers 800ms the acceptable threshold. I wouldn’t even raise an eyebrow if TTFB hovered around 800-1200ms - for many, that’s still an acceptable trade-off relative to cost.

But 3-4 seconds? That’s several hundred percent above the norm. And no amount of code optimization will fix it.

A Ticking Time Bomb

Let’s say you manage to squeeze decent results out of such a host using cache. The site loads, the client is happy.

But you’ll never reach a 100% cache hit ratio.

And once the optimization process wraps up and ongoing oversight disappears, it only takes one of the following to bring the whole thing crashing down:

A new traffic channel with URL parameters that the cache doesn’t ignore
A new plugin or plugin update that conflicts with the cache configuration

A few months later, the site owner might launch an expensive ad campaign, and instead of getting cached pages, visitors wait 4 seconds per load.

The campaign has an absurd bounce rate because of one small oversight.

The entire optimization investment - wasted. Because underneath it all, there’s still a terrible server.

My Data - Same Code, Two Servers

I recently took on the optimization of a WordPress site. It was sitting on a weak host, so from the very beginning I made it clear: there’s no point investing in code optimization if we leave the site on this server.

We agreed on a migration to proper hosting, and in the meantime I handled the optimization on a dev environment. Once it was done, I ran benchmarks on both environments - to get hard data.

Results on the Old Host

Old theme (before optimization):

Times (TTFB, no cache): 2.16s, 2.55s, 2.52s, 2.52s, 3.47s, 4.14s, 4.24s, 2.93s, 2.90s, 2.61s, 2.89s, 2.36s, 2.44s

Average: 2.90s

New theme (after optimization):

Times: 2.29s, 2.15s, 2.85s, 3.45s, 2.52s, 2.28s, 2.64s, 3.72s, 2.43s, 2.33s, 2.47s, 2.13s

Average: 2.61s

10% faster. Still 326% above the recommended TTFB threshold.

Query Monitor showed nearly a full second faster than the cfOrigin header from Cloudflare. In Query Monitor, the difference in database query times was clear - the optimization was clearly working. But the LiteSpeed server added so much overhead that the whole effort translated to a modest 10% improvement with still terrible results.

Be honest - would you pay a developer for a day and a half of work for that kind of progress? I wouldn’t.

Results on the Target Host

Same theme versions, same code - but on a proper server.

Old theme on the new host:

New theme on the new host:

In addition to full TTFB, I also measured the server’s wait time - how long the server actually spent processing the request: PHP + Nginx.

Full TTFB: 0.38s vs 0.49s

Server wait time: 0.21s vs 0.33s

22% improvement and TTFB with over 400ms of headroom below the recommended threshold.

If we strip out connection time and focus on the PHP + Nginx processing alone, the server delivers the page 36% faster.

That looks a bit better than 10% and times above 2.5s.

Foundation First, Optimization Second

Only after confirming real improvements do I move on to configuring cache.

Because even if I can’t predict every scenario - it’ll still be fine.

I also know that even a logged-in user (who won’t get a cached page) will be able to use the site quickly and comfortably.

Back to the Numbers

Let’s look at this from a business perspective.

If the old server could routinely add a full second of overhead (measured as the difference between Query Monitor timing and cfOrigin), then even investing hundreds of thousands and rewriting the application from scratch, we wouldn’t come close to matching the old theme version served from a better host.

You’re always limited by that one second of terrible web server overhead.

Sometimes it’ll be better, sometimes worse - but by trying to save on proper infrastructure, you can end up in an endless loop of development work that never reaches a happy ending.

And if you flip the order?

Migration alone improves performance from 2.90s to 0.49s. That’s nearly 6x faster.

Zero code analysis.

Zero refactoring.

One quick migration to a good host.

One day - and you have your result.

The costs may look higher if you compare hardware price lists side by side.

But if you factor in developer time, the migration alone might turn out to be far cheaper.

Stop Tolerating Bad Hosting

Years of price wars and dirty tricks in the hosting market have led to a situation where people accept as fact that hosting can be cheap and slow. And they just live with it.

That’s just how WordPress is!

We look the other way and try to mask it with cache. And that’s a straight path to making WordPress look like a joke as a platform.

Look at it from the perspective of a business considering WordPress for a new project.

Imagine a decision-maker stumbles upon an optimization course and sees that to make a simple business website reasonably fast on WordPress, they need to hire a performance specialist and dedicate three months to the process.

What do you think they’ll do?

Choose WordPress, or go with Astro, Next.js, or any other technology where this problem simply doesn’t exist?

By accepting this status quo, we as WordPress developers are shooting ourselves in the foot.

We normalize performance pathology and teach clients that “this is just how it works.” And then we wonder why WordPress is losing market share.

Of course, we should always strive for good design patterns and solve problems at the design stage - not patch them later when the site is already tanking.

But if the starting point of our project exceeds acceptable norms by hundreds of percent due to bad infrastructure, it’s our responsibility to draw a clear line and say: stop.

Let’s stop tolerating this.

This is exactly the thinking behind SHIFT64 - because I believe solid infrastructure should be a foundation, not a luxury.

Shift64 - Built with Astro

Thu, 29 Jan 2026 12:00:00 GMT

SHIFT64 is a digital agency focused on high-performance WooCommerce infrastructure. When it came time to build our own website, we needed a framework that matched our philosophy: speed, flexibility, and no unnecessary bloat. Astro was the natural choice.

Why Astro?

Astro ships zero JavaScript by default. For a content-heavy site like ours, this translates directly into faster page loads and better Core Web Vitals. But performance was only part of the equation.

Island Architecture lets us sprinkle interactivity exactly where we need it. A static pricing page stays static. A consent banner or contact form hydrates independently. No monolithic JavaScript bundle forcing users to download code they will never execute.

Content Collections give us type-safe content management without a heavy CMS. We define schemas, and Astro validates our data at build time. Broken links, missing fields, or malformed dates get caught before deployment.

Shuffle Templates + Tailwind CSS gave us a head start on design. We used Shuffle neubrutalism templates as a foundation—bold outlines, flat colors, strong shadows—and customized them with Tailwind to create a distinctive visual identity. The result is a look that stands out in a sea of generic agency websites while maintaining full design control through utility classes.

What We Built

This case study walks through three custom features we implemented:

Lessons Module — A protected content delivery system with token-based access and direct Brevo integration for efficient marketing consent updates.
Custom Offers CMS — An internal tool built on Cloudflare D1 for sending instant, custom audit proposals to clients.
Consent & Analytics Module — A privacy-first approach that loads services dynamically based on environment configuration.

Each section covers the architecture decisions, the tradeoffs we made, and practical takeaways you can apply to your own projects.

Lessons Module: Protected Content Delivery

Our WooCommerce Performance Course needed a way to deliver exclusive training materials to registered users. Rather than bolting on a heavy LMS plugin, we built a lightweight system using Astro’s content collections and middleware.

Course Structure

The content follows a simple hierarchy: a course contains lessons, and each lesson contains the actual learning material. Lessons are stored as MDX files, which means we can mix Markdown prose with interactive components like audio players.

Each lesson defines its metadata in frontmatter—title, lesson number, description, and whether it is published. Astro validates this schema at build time, catching any missing fields before deployment. Unpublished lessons appear in the navigation with a “#SOON” badge, giving users visibility into what is coming next.

Token-Based Access

We implemented a passwordless authentication flow. Users sign up with their email, and when they want to access content, they request a magic link. That link contains a short-lived token (15 minutes) that, once verified, creates a longer session (30 days).

The experience is frictionless: no passwords to remember, no account management overhead. Users click a link in their inbox and they are in. The session token lives in an httpOnly cookie, keeping it secure from client-side scripts.

Backend Validation with Brevo

When a user requests access, we don’t just generate a token blindly. The API route connects directly to Brevo’s API to verify the contact’s status. It checks if the email exists in our specific “Course Participants” list and verifies they have given marketing consent.

Only if these checks pass does the system generate the magic link. This ensures that only authorized users who have opted-in can access the educational content, keeping our email capability compliant and our content secure.

Middleware Protection

Astro’s middleware runs on every request before the page renders. Our middleware extracts the session cookie, verifies the token, and sets an isAuthenticated flag that pages and components can read.

Protected content uses a Paywall component. When authenticated, users see the full lesson. When not, they see a preview with a gradient fade and a prompt to log in. The protection happens server-side—there is no hidden content in the HTML for unauthenticated users to inspect.

The Learning Experience

Navigation between lessons is straightforward. Each lesson page includes previous and next buttons that respect the lesson numbering. Users can also jump back to the course overview at any time to see all available lessons.

We kept the experience intentionally simple. No progress bars, no completion certificates, no gamification. The focus stays on the content itself. Analytics tracking happens in the background for our business intelligence, but it does not affect the user interface.

Custom Offers CMS: Cloudflare D1 & Fast Edits

Originally, we considered a file-based approach for our pricing and offers, but we needed something more robust for custom client proposals. We built an internal CMS that allows us to generate unique, uuid-slugged offer pages (e.g., see a sample audit) instantly.

Powered by Cloudflare D1

We chose Cloudflare D1—a serverless SQL database—to store our offer data. This gives us incredible read performance at the edge, ensuring that clients see their audits instantly, no matter where they are located.

The CMS is simple but powerful. We can create a new audit offer, set the title, embed a video (like a Loom or Descript walkthrough), and write the micro audit in Markdown.

The Workflow

Create Offer: We generate a new entry in the Admin dashboard.
Write Content: We draft the specific findings and recommendations in Markdown.
Embed Media: We drop in a video embed code for a personal walkthrough.
Publish: One click pushes it live to the edge.

Because the data lives in D1 and the frontend is Astro, the pages are dynamic but feel as fast as static content. There’s no build step required to update an offer—changes are live the moment we hit save.

GDPR compliance is not optional, but that does not mean analytics has to be an afterthought. We built a consent system that respects user choices while maintaining the insights we need to improve the site. The guiding principle: the site works perfectly without any consent given.

When visitors first arrive, they see a consent banner with three clear options: Accept All, Reject All, or Customize. No dark patterns, no pre-checked boxes, no confusing language. The banner explains what we track and why.

Choosing “Customize” reveals individual toggles for each tracking service. Users can enable analytics while blocking marketing pixels, or vice versa. Their choice persists for 180 days across all subdomains.

We track four services, each serving a distinct purpose:

Google Analytics (GA4) — Traffic patterns, page performance, and user journeys. Helps us understand which content resonates.
Microsoft Clarity — Heatmaps and session recordings. Shows us where users click, scroll, and get stuck.
Meta Pixel — Conversion tracking for advertising campaigns. Only relevant when running paid social.
Cloudflare Analytics — Performance metrics at the edge. Lightweight and privacy-focused.

Environment-Based Loading

To keep our system flexible, we architected the ConsentManager to check for the existence of specific environment variables before even offering a service.

If META_PIXEL_ID is present in the .env (or Cloudflare secrets), the Meta Pixel service is loaded into the consent engine. If we remove that variable, the service completely disappears from the frontend—no code delivered, no options shown to the user. This allows us to turn tracking tools on and off infrastructure-wide without deploying code changes.

Graceful Degradation

Here is the key architectural decision: every tracking service defaults to “denied” until explicit consent. This is not just a legal checkbox—it is how the system actually works.

Google Analytics uses Consent Mode v2. Before the gtag script even loads, we set all storage permissions to denied. No cookies get written, no data collected. When users grant consent, we update the consent state and GA begins tracking. Revoke consent later? The state updates again and tracking stops.

Microsoft Clarity follows the same pattern with its own Consent Mode v2 implementation. The script loads, but waits for our signal before recording anything.

Meta Pixel checks consent before initializing. If denied, fbq('consent', 'revoke') ensures the pixel stays dormant. Granting consent triggers fbq('consent', 'grant') and tracking begins.

Cloudflare Analytics is the one service that loads automatically on Cloudflare Pages. For users who decline, we run a cookie blocker that monitors and deletes any __cfz_zaraz cookies every 500 milliseconds. It is aggressive, but it ensures compliance.

The User Experience

The consent flow prioritizes clarity over conversion. We want informed consent, not grudging acceptance.

First visit shows the banner. Users make a choice. The banner disappears with a smooth animation. Done. No nagging popups, no repeated asks, no banner creeping back after a few pages.

Need to change your preferences later? A link in the footer reopens the consent panel. Users can update their choices anytime without hunting through settings menus.

The site itself works identically regardless of consent status. No degraded experience, no “please enable cookies” warnings, no features locked behind consent walls. Analytics are for us, not a prerequisite for the user.

Cross-Tab Synchronization

One subtle feature: consent syncs across browser tabs. Grant consent in one tab, and other open tabs update immediately via storage events. The consent state also shares across subdomains through cookie domain settings. Log in on www.shift64.com, and your preference applies to course.shift64.com too.

This dual storage approach—localStorage for speed, cookies for cross-domain sharing—handles edge cases that simpler implementations miss.

The Blog You’re Reading

The blog itself uses Astro’s content collections with MDX for flexible authoring—mixing Markdown with interactive components. Code blocks get Shiki syntax highlighting at build time and a copy-to-clipboard button that appears on hover, making it easy to grab snippets directly into your editor.

Wrapping Up

Building SHIFT64’s website reinforced what we already believed: the best tools are the ones that get out of your way. Astro gave us the performance baseline. The rest—protected content delivery, type-safe pricing configurations, privacy-first analytics—we built ourselves.

That is the approach we bring to every project. We do not just configure off-the-shelf solutions and call it done. We dig into requirements, understand tradeoffs, and build systems that actually fit the problem. Whether that means shipping zero JavaScript for a marketing page or engineering a token-based authentication flow, we choose the right tool for the job.

The result is infrastructure you can trust. Fast, maintainable, and designed around real user needs rather than framework defaults.

If you are running a WooCommerce store and thinking about performance, hosting, or long-term care, we should talk. Our Black Box Deception page breaks down exactly what we offer and why transparent infrastructure matters. No pressure—just the information you need to make an informed decision.

Automatic WordPress Theme Versioning with Semantic Release

Sun, 25 Jan 2026 11:36:38 GMT

Anyone who works with WordPress themes knows this pain: manually editing versions in style.css, writing changelogs, remembering all the files when merging. What if I told you that an AI assistant can wire the entire pipeline and then handle your daily commits with short commands?

The Problem with WordPress Versioning

WordPress stores the theme version in a CSS comment in style.css, not in package.json like modern projects. Standard versioning tools don’t work out-of-the-box.

Key insight: The bridge between WordPress and Semantic Release is a single sed command that rewrites the Version: line in style.css during each release. Everything else — commit analysis, changelog generation, GitHub releases — works the standard way.

The solution is Semantic Release with the right configuration — deployed through a Claude Code skill that handles all the wiring.

One-Time Setup: Activate the Skill

Instead of manually creating configs, workflows, and scripts, run one Claude Code command:

/wordpress-theme-semantic-github-deployment

The skill auto-detects your environment — reads style.css header, git remote, branch name, existing package.json — and walks you through a short interview to select features.

What gets generated

File	Purpose
`.releaserc.json`	Semantic Release config — the heart of automation
`.github/workflows/release.yml`	Auto-release on merge to main
`.github/workflows/pr-lint.yml`	Blocks merge if PR title breaks convention
`package.json`	Node.js devDependencies
`CONTRIBUTING.md`	Developer guide with workflow reference

Optional features (selected during interview)

Feature	What it does
Beta testing (`beta.sh`)	Builds a ZIP with `-beta` directory suffix — WordPress treats it as a separate theme, so you can test stable and beta side-by-side
ZIP assets (`build-release.sh`)	Creates a clean installable ZIP (no `.git`, `node_modules`, configs) attached to each GitHub Release
GitHub beta releases (`beta-release.yml`)	Manual “Run workflow” button in Actions — pick any branch, get a pre-release with ZIP attached
WP Admin auto-updater (`includes/github-updater/`)	Dashboard widget showing current vs. latest version with one-click update. Works with public and private repos

Building a plugin instead of a theme? There’s an equivalent skill: /wordpress-plugin-semantic-github-deployment — same pipeline, adapted for plugin file headers.

Daily Workflow: Three Commands

Once the pipeline is set up, your daily work uses three commands from the commit-push-pr skill set:

`/sco` — Semantic Commit

Analyzes your diff, picks the right type and scope, stages specific files, and commits:

feat(search): add fuzzy matching helper
fix(cart): correct tax calculation to include base price
refactor(admin): extract settings into dedicated options handler

Stages files by name — never git add .. No secrets committed. Imperative mood, max 72 chars.

`/spr` — Branch → Commit → Push → PR

The full flow in one command. Creates a semantic branch name, commits, pushes with upstream tracking, and opens a PR with the correct title:

Branch:  feat/add-search-filter
Commit:  feat(search): add result filtering
PR:      feat(search): add result filtering

The PR body includes a summary and release impact type.

`/spu` — Push

Pushes the current branch to origin with upstream tracking. That’s it.

Why the PR title is everything

With Squash & Merge, GitHub flattens your branch into a single commit using the PR title as the commit message. Semantic Release reads that message to decide the version bump. The PR title is the only thing that determines your next version number.

Conventional Commits Reference

Prefix	Meaning	Version Change
`feat:`	New feature	minor (1.x.0)
`fix:`	Bug fix	patch (1.0.x)
`perf:`	Performance improvement	patch
`docs:`	Documentation only	none
`style:`	Code formatting	none
`refactor:`	Refactoring	none
`chore:`	Maintenance tasks	none
`feat!:` / `BREAKING CHANGE:`	Breaking change	major (x.0.0)

The Full Flow

sequenceDiagram
    participant Dev as Developer
    participant CC as Claude Code
    participant GH as GitHub
    participant GHA as GitHub Actions
    participant Rel as Release

    Dev->>CC: /spr (or /sco + /spu)
    CC->>CC: Analyze diff → pick type & scope
    CC->>GH: Create branch, commit, push, open PR
    GH->>GH: PR Lint validates title ✓
    Dev->>GH: Squash & Merge
    GH->>GHA: Trigger release workflow
    GHA->>GHA: Bump version in style.css
    GHA->>GHA: Update CHANGELOG.md
    GHA->>Rel: Publish v1.2.0 + ZIP asset

Post-Setup: GitHub Settings

After the skill generates the files, configure your repository:

Squash merge only — Settings → General → Pull Requests: enable “Allow squash merging” (default to PR title), disable merge commits and rebase merging.
Branch protection — Settings → Branches: require “Validate PR title” status check before merging.

First release gotcha: On some repos, the first squash-merge may not trigger the Release workflow. If it doesn’t fire, push an empty commit directly: git commit --allow-empty -m "ci: trigger release workflow" && git push. Subsequent merges work fine.

Summary

One skill sets up the pipeline. Three commands handle the rest:

/wordpress-theme-semantic-github-deployment  →  one-time setup
/sco                                         →  semantic commit
/spr                                         →  branch + commit + push + PR
/spu                                         →  push

Your team focuses on code. The robots handle versioning, changelogs, and releases.

Useful Links

wordpress-theme-semantic-github-deployment — Claude Code skill for setting up the release pipeline
commit-push-pr — Claude Code skills for semantic commits, pushes, and PRs
Semantic Release — documentation
Conventional Commits — specification
action-semantic-pull-request
GitHub Actions — documentation

SHIFT64 Blog

I Bought the Domain Before I Ran the Test. EmDash Still Lost to WordPress.

TL;DR

I read 150 EmDash takes in a week. Maybe 1 in 100 had installed it.

What I was hoping EmDash would unlock

The setup

What “EmDash defaults” actually means

Methodology

The verdict from someone who reads crawl stats for a living

What Search Console actually shows after one week

The numbers — server processing time

Total TTFB — what the user actually waits for

Network breakdown

Per-page comparison — WP wins 13 / 13

Cold starts are real and they follow the working day

I paid Cloudflare $5 to fix this. It got slightly worse.

What I tried to do about it

1. server:defer on widget areas

2. Killing an N+1 with an undocumented batch API

What it bought me

And then I added edge caching

Why caching does not save you on Search Console

After Jacek read the full article

WordPress is absurdly fast — when you don’t bury it in plugins

Where EmDash might actually win — and why my use case wasn’t it

What this means for SHIFT64

Caveats I want to head off

Conclusions

Repos and discussion

Your First Playwright Test for WooCommerce

Performance Is Worthless If the Store Is Broken

Why This Matters for WooCommerce Specifically

Getting Started

Install Playwright

Write Your First Test

Run It

When to Run Tests

What to Test Next

Visual Regression

The Full Picture

Fast WooCommerce Search: An Experiment with RediSearch and SHORTINIT

Why Is the Default WooCommerce Search Slow?

RediSearch — What It Is and Why It Matters

SHORTINIT — WordPress Without WordPress

The Catch

Early Results from a Cheap VPS

First Observations

Three Ideas That Made a Difference

Precise First, Loose Later

Diacritics Normalization

Re-Ranking Results After Redis

When Does This Make Sense?

What’s Next?

Why Your WooCommerce Checkout Is Slow (And It's Not What You Think)

Why Your WooCommerce Checkout Is Slow (And It’s Not What You Think)

The Page You Can’t Cache

How Bad Is It? Let’s Look at the Numbers

The Four Layers of Checkout Latency

Layer 1: The Server

Layer 2: The Database

Layer 3: External APIs (The Silent Killer)

Layer 4: The Frontend

How to Diagnose Your Specific Bottleneck

Step 1: Isolate server response time

Step 2: Install Query Monitor

Step 3: Check the wc-ajax=update_order_review call

Step 4: Test with a baseline

What Actually Works (Not “Install a Caching Plugin”)

If your TTFB is over 1 second: fix the server first

If Query Monitor shows 200+ database queries: fix the database

If external API calls dominate: reduce blocking calls

If frontend JavaScript is the bottleneck: audit what loads on checkout

The Uncomfortable Truth

Checkout Speed Diagnostic Checklist

The Staging Paradox: Why a Perfect Copy of Production Is a Ticking Time Bomb

The Staging Paradox: Why a Perfect Copy of Production Is a Ticking Time Bomb

The Mantra Everyone Gets Wrong

What Went Wrong: A Real Scenario

The Contradiction at the Core of Staging

Five Ways Developers Get This Wrong

1. `server:defer` on widget areas

3. Trusting `WP_ENVIRONMENT_TYPE`

`/sco` — Semantic Commit

`/spr` — Branch → Commit → Push → PR

`/spu` — Push