The 14KB Website: My Journey from Bloat to Barebones HTML

Let’s face it - modern websites have become quite the heavyweight champs! The average page weighs over 2MB, and my personal site was even heavier. I had built it as a React single-page app with a whopping 87 npm dependencies. My Webpack build took a staggering 14 seconds, and to top it off, Lighthouse gave me a disheartening score of 38/100 on mobile. Honestly, I found myself spending more time updating packages than actually creating content.

So, I decided to make a bold move. I completely rebuilt my site with just four plain HTML files, added SQLite via WebAssembly for search functionality, and hosted it on the edge. The outcome? A featherlight 14KB site that loads faster than you can blink. No frameworks, no bundlers, and definitely no node_modules nightmares.

Here’s why this change is significant.

The Numbers Don’t Lie

Metric	Old React Site	New Vanilla Site
Page weight	2,341 KB	14 KB
DOM ready	4.8s	0.3s
Lighthouse score	38	99
Build time	14s	None
Dependencies	87	0
Files to deploy	1,142	4
Hosting cost	$12/month	Free

That’s a 99.4% reduction in weight! My old site needed a loading spinner, while the new one displays content almost instantly.

What Can You Fit in 14KB?

Believe it or not, 14 kilobytes is less than most website icons! It’s smaller than Google’s tracking scripts and even smaller than a single Tailwind CSS file. Here’s what I managed to cram in:

• index.html: The main page with essential CSS baked in
• blog.html: Blog listings with pre-rendered summaries
• search.html: Full-text search using SQLite/WASM
• contact.html: A basic email form

For styling, I went with a simple 20-line CSS reset in a <style> tag, semantic HTML selectors, and two CSS variables for colors. The entire design is just 187 lines of CSS and works seamlessly on any device.

The SQLite WASM Trick

Here’s the cool part: instead of setting up a search backend, I used SQLite compiled to WebAssembly. Here’s how the search works:

1. Your browser downloads a 1.8MB .wasm file (which gets cached after the first load)
2. Queries run against a local 340KB SQLite database
3. Results pop up in under 50ms - no waiting for a server

This is edge computing in its simplest form: your browser acts as the database server. Here’s a little snippet on how it’s implemented:

<script type="module">
import sqlite3InitModule from 'https://esm.sh/@sqlite.org/sqlite-wasm@3.45.0/sqlite-wasm.js';
const sqlite3 = await sqlite3InitModule();
const db = new sqlite3.oo1.DB('/search-index.sqlite3');
const results = db.exec(`SELECT title, url FROM posts WHERE content MATCH '`, { bind: [query] });
</script>

No servers. No ORMs. Just a file and a query.

Why We’re Stuck in Framework Land

It seems we’ve all accepted that websites need to load hundreds of KBs of JavaScript just to display some text. The average React page loads 327KB before showing anything. Even “static” frameworks like Next.js come with their own hydration overhead.

Here’s the uncomfortable truth: most content sites don’t actually need frameworks. My new site handles:

• Dark mode toggle: 12 lines
• Mobile menu: 8 lines
• Search functionality: 40 lines

That’s a mere 60 lines of plain JavaScript - no dependencies or build steps needed.

Real Performance Gains

The difference in performance was striking:

• Core Web Vitals pass rate: 23% → 100%
• Largest Contentful Paint: 4.2s → 0.6s
• Layout shift: 0.18 → 0.02

When I tested on a budget Android phone over 3G, the results were eye-opening:

• React site: 19 seconds to become interactive
• Vanilla site: 1.8 seconds to become interactive

When This Approach Doesn’t Work

Now, I should mention that this isn’t a one-size-fits-all solution. If you need features like:

• Live updates
• Complex client-side state
• Collaborative features

…then a framework might be the way to go. But for blogs, documentation, and marketing sites? The overhead of a framework just isn’t worth it for your visitors’ bandwidth.

How to Build Your Own

If you’re curious about trying this out, here’s a simple step-by-step guide:

1. Start with HTML - Just use semantic tags, no templates
2. Inline essential CSS - Keep it to about 20-40 lines in a <style> tag
3. Use one JS file - No need for jQuery or Alpine for basic UI
4. Let browsers handle routing - Anchor tags are perfectly fine
5. Host on the edge - Options like Cloudflare, Netlify, or Vercel work great
6. Measure everything - Aim for under 100KB total

Why This Matters

The web was originally designed for documents. My 14KB site:

• Loads in a single network request
• Works without JavaScript
• Passes all accessibility checks

Interestingly, my React version actually failed accessibility checks because screen readers couldn’t wait for hydration to finish.

Bloat isn’t accidental - it’s a choice we make. Every dependency forces your visitors to pay for your convenience. For content sites, that trade-off rarely makes sense.

Common Questions

Q: Is 14KB realistic with images/fonts’
A: Not exactly - this covers just HTML, CSS, and JS. Use system fonts and optimized images. The goal isn’t to hit 14KB precisely, but to reconsider every unnecessary byte.

Q: What about SEO’
A: Google loves fast, semantic HTML. My indexed pages increased by 40% because crawlers didn’t need to execute JavaScript.

Q: How should I handle comments’
A: Consider using GitHub issues, a lightweight API, or even pre-generate comments with SQLite.

Q: Is SQLite WASM secure’
A: Yes! It runs in the browser sandbox without server access, keeping things safe.

Q: Does this work for e-commerce’
A: Not for checkout flows, but it’s perfect for product and marketing pages.

I’m not 100% sure, but I think this minimalist approach can really make a difference for many websites. What do you think? Would you consider going for a lighter setup like this? I’d love to hear your thoughts!

References & Further Reading

• Google PageSpeed Insights
• Wikipedia: Website speed optimization