Why Your Website Should Be Under 14kB

by Anton Van Assche - 7 min read

If you enjoyed my previous post about why simplicity rules, this one is for the nerds, the ones who want to know why keeping a page under 14kB isn't just bragging rights.

It has some logic behind it. A lot of it, actually. It boils down to TCP slow start, latency, how your browser works, and that thing called user experience.

(Yes, last time I was just playing around. This time, I actually wanted to understand what makes pages blazing fast.)

Small Pages, Big Wins

Smaller pages load faster - obvious, right? But there's more. A smaller page can:

  • Render content faster (improving first contentful paint)
  • Reduce bounce rates and improve user satisfaction
  • Use less bandwidth, which matters for mobile or metered connections
  • Work on older browsers, slow networks, and low-end devices
  • Improve SEO (Search Engine Optimization) by positively impacting Core Web Vitals

What is TCP Slow Start?

TCP (Transmission Control Protocol) ensures data reaches the browser reliably. When a browser first requests a page, the server doesn't know the available bandwidth. TCP slow start solves this by sending a small amount of data, waiting for an acknowledgment (ACK), then gradually increasing the amount sent.

Each round trip adds latency. Fitting your page into the first 10 TCP packets (~14kB) allows the browser to start rendering immediately, avoiding extra delays.

Why 14kB?

A TCP packet can carry roughly 1460 bytes of payload (1500 bytes max minus headers). 10 packets × 1460 bytes ≈ 14,600 bytes (~14kB). Staying under this limit helps pages load fast before congestion control slows data flow.

Latency Matters

Even a single round trip can add 50–500ms depending on connection type. Satellite internet, crowded mobile networks, and high-traffic servers can increase latency further. Multiple round trips multiply delays, and HTTPS adds extra handshakes. Keeping the initial payload small is critical.

What to Include in Your First 14kB

  • Critical CSS and minimal JS for initial render
  • Essential text content visible above the fold
  • Small images or placeholders

All other scripts, large frameworks, tracking pixels, and videos can load asynchronously after the initial render.

Caveats & Modern Protocols

HTTP/2 and HTTP/3 change the dynamics slightly with multiplexing, but TCP slow start still applies. Compressing your payload helps, but the first ~14kB uncompressed is what matters for initial render speed.

Conclusion

Making a page under 14kB isn't a law, it's a rule of thumb that forces you to prioritize speed, simplicity, and efficiency. Think of it as the nerdy sequel to my previous post: all the charm, none of the fluff, plus numbers to back it up.

P.S. If you just want the fun version, check out the humorous primer.

References & Further Reading