The question, and why it looked so promising
We already publish what slows sites down per platform. The obvious next cut is by what the site is for: surely a store, with its product grids and cart scripts, breaks differently from a publisher carrying ad tags, and differently again from a one-screen landing page.
If true, that’s worth knowing — it changes what we’d tell each owner to look at first. So we sorted all 168 sites by markup and compared the bottleneck profiles.
The first table was everything we’d hoped for:
| Bottleneck | Content | Corporate | Landing | Ecommerce |
|---|---|---|---|---|
| Stale or wasteful resource hints | 5% | 42% | 38% | 9% |
| Inline scripts run during render | 5% | 42% | 38% | 9% |
| Text invisible while fonts load | 5% | 39% | 33% | 9% |
| Hero background waits for the stylesheet | 5% | 35% | 29% | 9% |
An eightfold gap, repeated across four independent measurements. Publishers apparently don’t have the problems that corporate and landing sites do.
Then we held the platform fixed
The same comparison, restricted to WordPress sites only — same four bottlenecks, same buckets, with the one variable we hadn’t controlled for now constant:
| Bottleneck | Content (14) | Corporate (24) | Landing (6) |
|---|---|---|---|
| Stale or wasteful resource hints | 0% | 0% | 0% |
| Inline scripts run during render | 0% | 0% | 0% |
| Text invisible while fonts load | 0% | 0% | 0% |
| Hero background waits for the stylesheet | 0% | 0% | 0% |
Zero everywhere. Restricted to Duda sites instead, the same four rows read 100% in every bucket.
There was never a site-type effect. Our “corporate” and “landing” buckets were 45 Duda sites between them, and “content” was mostly WordPress publishers — so sorting by type had quietly sorted by platform, and the platform is what the numbers were describing all along. The eightfold gap was a mixing ratio.
What survived
One difference held up inside a single platform. Among WordPress sites, off-screen rendering was worth fixing on 14 of 14 publishers versus 63% of corporate sites — and that one has an obvious mechanism behind it rather than a composition artefact: article pages are long, so more of the document is laid out below the fold before anyone scrolls there. It’s a sentence worth knowing. It is not a different set of problems.
The other thing we learned was about the taxonomy itself. The buckets we set out to measure — store, publisher, landing page — captured 91 sites. The remaining 77, the largest group, were none of them: ordinary multi-page business and SaaS sites with a homepage, some service pages and a contact form. A three-way split that leaves out the biggest category isn’t describing the web we audit.
Why we’re publishing a null result
Because the alternative was three pages that read differently and say the same thing. The tables above are what a “speed optimization for online stores” page would have been built on, and every number on it would have been a fact about Duda and WordPress wearing a costume. Google has a name for the result — pages “created to rank for specific, similar search queries” is its definition of doorway abuse — but the reason not to ship them is simpler than the penalty: they wouldn’t have been true.
The finding also has a practical edge for anyone doing this analysis on their own data: a bottleneck comparison across site categories is only meaningful within one platform. Run the cut, then run it again with the platform pinned. If the gap doesn’t survive, it was never yours.
For what it’s worth, we still think an ecommerce page will eventually be worth writing — just on a different axis. What a store loses to a slow page is measured in abandoned carts, and that argument is genuinely its own. The technical causes, on this evidence, are whatever its platform ships.
Method and limits
Every completed audit with a stored copy of the original HTML. Each site was classified from its own markup — product and article schema, cart markers, article density, ad networks, outbound link count — then we compared how often each optimization had something to fix in each bucket. Then we ran the identical comparison inside a single platform, where site type is the only thing left varying.
Measured on 21 Jul 2026 across 168 sites. These figures are frozen at that date — we don't quietly restate a published study when the audit base grows.
What this doesn't show
- Not a random sample of the web, and the composition matters more than usual here: one batch of 48 small-business Duda sites and a large group of WordPress publishers are exactly what produced the confound described below.
- The classifier reads markup, not meaning. Subscription pricing pages carry Product and Offer schema just like a store does — 6 of the 11 sites it called "ecommerce" were SaaS marketing sites on inspection, leaving 5 genuine stores. Too few to conclude anything about stores specifically.
- A negative result on this sample is not proof that no difference exists. It shows that on 168 sites, site type explains nothing that platform doesn't already explain better.
Sources
- Confounding — Wikipedia
A confounder is traditionally understood to be a variable that (1) independently predicts the outcome, (2) is associated with the exposure, and (3) is not on the causal pathway between the exposure and the outcome. Failure to control for a confounder results in a spurious association between exposure and outcome.
- Spam policies for Google web search — Doorway abuse — Google Search Central
Doorway abuse is when sites or pages are created to rank for specific, similar search queries. They lead users to intermediate pages that are not as useful as the final destination.