Worth being upfront about what this actually is: WordPress, Webflow, Wix, and Squarespace have real, independently published Core Web Vitals benchmark data from third-party research. EmDash — newer, and not yet the subject of an independent large-sample study — doesn't. Rather than inventing a specific number for EmDash to complete a tidy comparison table, this compares the documented data for the established platforms against EmDash's actual architecture, honestly labeled as architectural reasoning, not a lab result.

The Real, Published Numbers

Webflow sites average 2.3 times faster LCP scores than WordPress, due to not having a server-side rendering step for each request — Webflow sites are essentially static HTML served from CDN. Without a CDN, a standard WordPress site on shared hosting will have TTFB of 500-2000ms, while Webflow consistently achieves 250-400ms. Wix and Squarespace ship the highest Core Web Vitals pass rates on mobile because they aggressively control theme, image delivery, and hosting.

That's genuine, sourced benchmark data, and it tells a clear story: platforms that skip per-request server rendering (Webflow's static-HTML-from-CDN model, and to a large extent Wix/Squarespace's tightly controlled hosting) post meaningfully better default numbers than a platform that renders fresh on every request across wildly inconsistent hosting tiers, like WordPress does at the low end.

Where EmDash Fits Architecturally

EmDash's rendering model shares the same core property that gives Webflow its advantage — it doesn't ship a heavy client-side framework by default. It's built on Astro's islands architecture, which hydrates only the specific interactive components a page actually needs rather than shipping a full JavaScript bundle for a mostly-static page. That's a real, mechanistic reason to expect a low JavaScript payload and a correspondingly strong INP baseline — not a benchmark claim, a description of what the architecture does.

Where EmDash differs from Webflow's model specifically: EmDash runs server-side rendering (SSR) by design, so content updates appear instantly without a rebuild — the direct trade-off against Webflow's fully static, pre-built-and-cached approach. That means EmDash's LCP and TTFB numbers will depend more on your hosting choice (a well-configured Cloudflare Workers/D1 deployment versus a cheap shared Node.js host) than Webflow's more uniform, CDN-first delivery model does.

An Honest Comparison Table

• WordPress (unoptimized, shared hosting) — TTFB 500-2000ms; documented, real, low floor.
• WordPress (well-optimized, managed hosting + CDN) — competitive with static-first platforms; documented, real, high ceiling.
• Webflow — TTFB 250-400ms typical, no per-request server rendering; documented, real.
• Wix / Squarespace — highest mobile CWV pass rates from tightly controlled hosting and image delivery; documented, real.
• EmDash — minimal-JS islands architecture (mechanistic advantage for INP); SSR by design (LCP/TTFB depends on your hosting choice); no independent third-party benchmark published as of this writing.

What Actually Determines EmDash's Real-World Numbers

• Hosting choice — Cloudflare Workers with D1 (edge-distributed) versus a single-region Node.js VPS will produce meaningfully different TTFB, the same way any SSR platform's numbers vary by hosting.
• Database round-trip time — since EmDash queries a real database per request rather than serving pre-built static files, database latency is part of your TTFB in a way it isn't for Webflow's static model.
• Image handling — whether you're using EmDash's responsive image generation (via Astro's image service) consistently across your templates.
• How much interactive JS you add — Astro's islands model keeps the baseline low, but adding heavy React/Vue components still adds real weight; the architecture sets a low floor, not a hard ceiling you can't exceed with your own choices.

How to Actually Get Real Numbers for Your Own Site

• Run PageSpeed Insights (or the CrUX API directly) against your live EmDash deployment once it has real traffic — lab data alone won't capture your actual visitor conditions.
• Compare your own site's LCP/INP/CLS against the documented thresholds (LCP under 2.5s, INP under 200ms, CLS under 0.1) rather than against an unverified platform-wide claim.
• If evaluating EmDash against a specific alternative for a specific project, build a comparable minimal page on both and measure directly — the only benchmark that actually predicts your outcome is one built on your real content and hosting choice.

Frequently Asked Questions

Why doesn't EmDash have published benchmark data yet?

It's a newer platform than WordPress, Webflow, Wix, or Squarespace, none of which had independent third-party studies in their first years either — this kind of large-sample, real-user benchmark research typically follows meaningful market adoption, not the other way around.

Is it fair to compare an SSR platform like EmDash against a fully static one like Webflow at all?

It's a genuine trade-off worth naming directly rather than avoiding: Webflow's static model has a performance advantage by default; EmDash's SSR model trades some of that default advantage for instant content updates with no rebuild step. Neither is strictly better — it depends whether your priority is the lowest possible default latency or live content without a build pipeline.

Should I trust a CMS vendor's own performance claims?

Be skeptical of any platform's self-reported benchmark, EmDash included in any future claims it might make — prioritize independently published, sourced data (the kind cited in this piece for Webflow, WordPress, Wix, and Squarespace) or your own direct measurement over vendor marketing.

What's the single biggest lever for EmDash's real-world speed?

Hosting choice, specifically whether you deploy to Cloudflare Workers with D1 (edge-distributed, low regional latency) versus a single-region traditional host — that decision affects TTFB more than almost anything else in the stack, the same way it does for any SSR-based platform.

The Bottom Line

WordPress, Webflow, Wix, and Squarespace have real, sourced Core Web Vitals data worth comparing directly — EmDash doesn't yet, and claiming otherwise would just be marketing dressed as a benchmark. What EmDash does have is a real architectural reason (Astro's islands model) to expect a strong JavaScript-driven INP baseline, with LCP and TTFB depending more on your own hosting and database choices than a static-first platform's numbers do. See our broader explainer on Core Web Vitals and CMS architecture for the mechanisms behind all of this.

Sources

• PageSpeedMatters — WordPress vs Webflow vs Squarespace: Speed Compared 2026