Hand-Coded Websites vs. Website Builders — Real Lighthouse Numbers Compared | TiltStack
Hand-Coded Websites vs. Website Builders: The Real Performance Numbers
There's a claim we make in every discovery call: "Our custom-built sites perform significantly better than builder platforms."
We kept making that claim, but we wanted to actually back it up with data. So we did something simple. We ran PageSpeed Insights on a sample of small business websites — half built on popular drag-and-drop platforms, half built by us using our standard Eleventy stack — and recorded the results.
Here's what we found, and more importantly, why the gap exists and what drives it.
What We Measured
We ran PageSpeed Insights on:
- 2 Wix small business sites (local service businesses, live production sites)
- 2 Squarespace portfolio sites (post-launch, no unusual customization)
- 2 Framer AI-generated sites (built with the default AI flow, minimal edits)
- 3 recent TiltStack builds (Eleventy SSG, custom SASS, self-hosted assets on Firebase)
We focused on mobile scores, since Google's Core Web Vitals assessment is mobile-first, and that's what actually affects rankings.
| Platform | Avg Performance | Avg LCP | Avg TBT | Avg CLS |
|---|---|---|---|---|
| Wix | 42–61 | 4.1–6.8s | 280–640ms | 0.04–0.22 |
| Squarespace | 55–68 | 3.2–5.1s | 190–380ms | 0.02–0.08 |
| Framer AI | 38–58 | 4.4–7.2s | 310–720ms | 0.08–0.31 |
| TiltStack (Eleventy) | 91–97 | 0.8–1.4s | 0–40ms | 0.0–0.02 |
These aren't cherry-picked outliers. The pattern was consistent across every site we tested.
What Actually Causes This Gap?
If you want to understand the why, you need to look at what the browser actually has to do before your page appears. The builder gap comes down to three specific technical realities:
1. JavaScript Payload
Every major website builder ships substantial JavaScript to power its visual editor, drag-and-drop layer, and embedded analytics. That code runs in the browser even on published/live sites.
A typical Wix business page loads 300–600KB of JavaScript before anything meaningful renders. Our plain HTML + minimal JS Eleventy output for a comparable page is typically 8–30KB of JavaScript total — bundled by esbuild, deferred, and loaded only where it's needed.
Total Blocking Time (TBT) is the metric that captures this. TBT measures how long the main thread is blocked and unable to respond to user input. Builder sites routinely score 300–700ms on mobile. Our builds typically score under 50ms.
2. CSS Delivery and Specificity Wars
Builders generate CSS via their visual rendering engine. The output is functional but not optimal — you often see thousands of utility classes and inline styles that override each other, plus CSS for components that aren't even on the current page.
Our SASS compiles to page-specific CSS. The blog.css file only loads on blog pages. header.css loads synchronously (it's critical); everything else loads async with the media="print" onload pattern. The total CSS payload for a typical page is under 25KB uncompressed.
3. Unoptimized Image Pipelines
This is where builder sites hurt the most. Upload a JPEG in Wix and it serves that JPEG (or its own CDN-resized version) — often without WebP conversion, often without proper width/height attributes causing CLS, and never with fetchpriority="high" on the LCP image.
Every image in our builds is:
- WebP format — 30–50% smaller than JPEG for equivalent quality
- Self-hosted — no third-party CDN round-trip
- Tagged with explicit
widthandheightattributes — eliminates CLS entirely - The LCP image carries
fetchpriority="high"and a<link rel="preload">in<head>
Why This Matters for SEO Specifically
Google has been clear that Core Web Vitals are a ranking signal. The specific metrics that matter:
- LCP (Largest Contentful Paint): Target under 2.5s. Builder sites regularly fail this on mobile.
- INP (Interaction to Next Paint): Replaced FID in 2024. Heavy JS load makes this worse.
- CLS (Cumulative Layout Shift): Missing
width/heighton images is the #1 cause. Target under 0.1.
A site scoring 42 on PageSpeed is at a material competitive disadvantage against one scoring 95 — not because Google penalizes the 42 explicitly, but because LCP at 6 seconds means half your mobile visitors have already left.
What "Hand-Coded" Actually Means in Our Stack
We don't write every pixel of CSS manually — we're not masochists. "Hand-coded" in our context means:
- Eleventy (11ty) as the static site generator — zero client-side framework overhead
- Nunjucks templating — reusable components that compile to clean HTML at build time
- SASS compiled to lean, page-specific CSS
- esbuild for JavaScript bundling — only what's used, minified for production, target ES6
- Firebase Hosting with a global CDN for fast asset delivery
- No WordPress, no Wix, no Webflow, no page builder — the browser gets exactly what it needs and nothing else
Every page is a static HTML file. There's no server-side rendering overhead, no database query on load, no framework hydration step. The server hands the browser an HTML file and the browser renders it. That's the architecture.
The SEO Structural Advantages
Beyond performance, hand-coded sites let us implement SEO infrastructure that most builders can't match:
- Schema markup (JSON-LD): We auto-inject
BlogPosting,LocalBusiness, andFAQPageschema on every relevant page. This powers rich results in Google and is a strong signal for AI-generated answer engines (AEO/GEO). - Canonical URLs: Set correctly on every page — never duplicated across pages.
- Sitemap: Auto-generated by Eleventy at build time, always current, always accurate.
- robots.txt: Configured precisely, with the right directives.
- Semantic HTML:
<article>,<main>,<nav>,<header>,<footer>— not<div>soup. Correct heading hierarchy (<h1>through<h6>), enforced at the component level.
The Trade-off Conversation We Always Have
Builder sites win on speed to launch. A Wix site can be live in a day. Our builds take longer because they're built properly the first time.
But the question we ask clients is: are you optimizing for launch speed, or for compound growth?
A site that scores 45 on PageSpeed and has no schema markup and no technical SEO foundation needs to be significantly better on every other dimension to outrank a competitor's well-built site. For most SMBs competing for local or regional search traffic, that gap is hard to close with content alone.
If your goal is to rank and convert, the performance foundation matters from day one.
FAQs
Q1: Can my builder-based site ever score well on Lighthouse?
A: Yes — with significant effort. Disabling unused apps, careful image compression, and deferring scripts can push a builder site from 40 to 65–70. But the JavaScript overhead of the builder platform creates a ceiling that's difficult to break through without moving to a different architecture entirely.
Q2: Does a high Lighthouse score guarantee better Google rankings?
A: Not directly — it's one of many signals. But a low LCP score (3+ seconds on mobile) will actively suppress your rankings relative to competitors who pass Core Web Vitals. It's a necessary condition, not a sufficient one.
Q3: How much does a custom Eleventy build cost compared to a builder?
A: Builder subscriptions are cheaper upfront. Our custom builds start higher but include the technical SEO foundation, performance optimization, and design control that most builder plans simply can't provide. We publish detailed pricing at /blog/custom-website-cost-2025/.
Q4: Do you migrate existing Wix/Framer/Squarespace sites?
A: Yes. Migration is a core part of our service offering. We handle content migration, 301 redirects for all existing URLs, and ensure zero SEO equity is lost in the transition. See our web design and migration services.
Q5: What does TiltStack's build process look like from start to launch?
A: Discovery → design mockups → Eleventy build → SEO implementation (schema, sitemap, canonicals) → QA on real devices → Firebase deploy. The whole process is typically 3–6 weeks depending on scope. We can discuss your project here.
