There is a common belief that a custom-coded website is faster than one built on a template platform like Wix or Squarespace. We checked that belief against 1.1 million US business websites. In the aggregate, it is backward. The no-code builders pass Google's Core Web Vitals more often than hand-built sites do, and the reason has almost nothing to do with the tools involved.
This is original research from Stackra's own corpus: 1.1 million verified US business websites, built from a monthly crawl of live homepages, automated technology detection, and real-world speed data from the Chrome User Experience Report (CrUX), Google's field measurement of how actual Chrome users experience a site. Full methodology, baselines, and controls are at the bottom.
Two honesty notes before the numbers. First, this is observational field data, not a controlled experiment: we are comparing sites as they exist in the wild, not holding everything else equal. Second, Core Web Vitals is only measured on sites with enough real Chrome traffic to register, so sites too small to measure are left out, never counted as failures. We list exactly what is and is not controlled at the end.
Which platform type passes Core Web Vitals most often
We sorted every site into five platform types by its detected technology, then measured the share of each that clears all three Core Web Vitals thresholds at once. The managed no-code builders lead. Hand-built custom code, the thing many people assume is fastest, sits at the bottom, below the 67% all-site baseline.
"We built our own" is not a performance advantage in the aggregate. Hand-built sites pass Core Web Vitals less often than sites on Wix, Shopify, or WordPress.
Baseline is 67%, the pass rate across all eligible sites. Source: Stackra corpus, Chrome UX Report field data (US mobile), May 2026.
| Platform type | CWV pass rate | vs baseline | Sites measured |
|---|---|---|---|
| DIY builder (Wix, Squarespace, GoDaddy) | 82% | +15 | 66,845 |
| Ecommerce platform (Shopify, BigCommerce) | 75% | +8 | 42,468 |
| Enterprise DXP (Sitecore, AEM, Contentful) | 65% | -2 | 8,198 |
| Open-source CMS (WordPress, Drupal, Joomla) | 63% | -4 | 166,034 |
| Hand-built custom code | 59% | -8 | 78,389 |
Baseline is 67%, the pass rate across every eligible site. Source: Stackra corpus, Chrome UX Report field data (US mobile), May 2026.
Why hand-built underperforms: it comes down to how the page renders
Hand-built is not one thing. Split those same custom-coded sites by how they put content on the screen and the gap opens wide. Sites that ship finished HTML, meaning static and pre-rendered builds, are the fastest sites in the entire corpus. Sites that ship a blank shell and assemble themselves in the visitor's browser, meaning client-rendered single-page apps, are the slowest.
A plain client-rendered React app passes Core Web Vitals about as often as a coin flip. A statically generated site from the same custom-code family passes roughly six times out of seven.
Same "custom code" category, grouped by how the page renders. Source: Stackra corpus, hand-built sites with field data, May 2026.
| Build type | Render approach | CWV pass | Sites measured |
|---|---|---|---|
| Static site generators | Static / pre-rendered | 86% | 102 |
| Astro | Static / pre-rendered | 85% | 626 |
| Custom hosted (mixed) | Server-rendered + hydration | 72% | 17,532 |
| Nuxt | Server-rendered + hydration | 67% | 5,099 |
| Next.js on Vercel | Server-rendered + hydration | 64% | 2,560 |
| Single-page app (generic) | Client-rendered | 52% | 47,266 |
| React on Netlify | Client-rendered | 40% | 363 |
Build types with fewer than 100 measured sites excluded. Source: Stackra corpus, hand-built sites with Chrome UX Report field data, May 2026.
The engineering case study behind this finding: how we shipped HTML from a React SPA without rebuilding on a server framework.
The platform-tier version of the same effect: WordPress, Shopify, Squarespace, and Wix land in different performance tiers before you touch a setting.
The twist: link authority has nothing to do with speed
Speed is one thing a platform choice lines up with. Link authority, meaning how well-linked a site is across the open web, is another, and the two do not track together at all. We measured typical referring domains, roughly how many other websites link to a site, for the same five platform types.
This is exactly why Stackra keeps authority out of the performance score. Speed and authority are two real, separate signals. Folding one into the other would hide information, not add it.
Ordered by authority. Note this ordering is nearly the reverse of the speed ranking above. Baseline is 12. Source: Stackra corpus via Common Crawl webgraph, 2026.
The ordering is nearly the reverse of the speed ranking. The fastest category, DIY builders, has the lowest authority: 8 typical referring domains, below the baseline of 12. The highest-authority category, enterprise platforms at 64, sits at below-average speed. A fast site is not an authoritative one, and an authoritative one is not fast. The platform authority ranking mostly reflects what kind of business buys each platform, not anything the platform does to your links.
What this means for your site
The practical read depends on where you are.
- •Just launched a custom or vibe-coded site: check one thing first. Open your homepage, view the page source (Ctrl+U on Windows, Cmd+Option+U on Mac), and look for your actual headline text. If you see it, you ship HTML and you are in good shape. If you see only a blank container and script tags, your site renders in the browser, which is the pattern that scores lowest on speed and is also the hardest for AI crawlers to read.
- •On a no-code builder like Wix or Squarespace: your platform is handling this well on average. Speed is rarely your bottleneck. Put your energy into content and links instead.
- •Choosing how to build: the decision that moves your speed is not React versus Vue versus a builder. It is whether the pages ship finished HTML, static or server-rendered, or assemble in the browser. Pick the render path first, then the framework.
Baselines and controls
So you can weight the read, here is exactly what this comparison holds constant and what it does not.
| Held constant | Not controlled |
|---|---|
| US business sites only; infrastructure, aggregators, and spam removed | Category size mix differs (enterprise skews to larger organizations) |
| One row per registrable domain, so multi-tenant subdomains cannot flood a category | Business-type mix within each category is not held equal |
| Single crawl month and a single authority vintage | Field-data coverage varies by category, so measured populations are not identical |
| The same pass rule everywhere: LCP, CLS, and INP at their p75 field thresholds | No regression or matching; these are raw conditional rates, directional not causal |
Baselines: 67% of all eligible sites pass Core Web Vitals, and the typical site has 12 referring domains. Measured on 372,384 sites with field data out of 1,073,563 total.
Methodology
The corpus is 1,073,563 US business websites assembled from a monthly HTTP Archive crawl of live homepages, deduplicated to one row per registrable domain. Core Web Vitals come from the Chrome User Experience Report, field data from real US mobile Chrome users: a site passes when it clears Largest Contentful Paint at or under 2.5 seconds, Cumulative Layout Shift at or under 0.10, and Interaction to Next Paint at or under 200 milliseconds, all at the 75th percentile. Authority comes from the Common Crawl webgraph; typical referring domains is the geometric mean of inbound-linking-domain counts across sites present in the link graph, floored at 20 in-graph domains per group. Render strategy is inferred from detected JavaScript framework and hosting fingerprints.