Road to 512kB

A year ago I built my website using SvelteKit as it was the only Frontend framework that I haven't touched. After a bit I revisited my decision.

I'm fascinated by performance and optimizations of systems. My website is and will always be static. I don't need to handle user interaction that exceeds routing. Might SvelteKit and JavaScript be the wrong tools?

Finding the right tool

Over time I played with the thought of how much I could reduce the build size of my website. At the same time I discovered the 512KB Club. I set myself the goal to get my website to under 10kB.

First assessment

Every time someone accessed my old website ~140kB were sent from server to client. Most of that fonts and JavaScript:

text/html

text/css

application/javascript

font/woff2

img/favicon

Getting my build under 10kb

To get to <10kB I needed to prioritize. Yes, 70kB of JavaScript are unnecessary for a static website. Yes, 46kB for fonts don't need to be part of the final build either. I decided to dump both SvelteKit and fonts.

Dumping JavaScript left me with bare CSS and HTML, which are exactly the right tool for my project. To make my life easier I chose 11ty, a static site generator (SSG). Setup was easy and I was productive sooner compared to other SSG alternatives. I am able to write content in markdown and have it compile to html.

Removing special fonts reduced the build by another 30% for each (uncached) request. The font-sets that I defined are the following and should cover +95% of users due to fallback fonts:

• Regular Text: Optima, Candara, "Noto Sans", source-sans-pro, sans-serif;
• Code Blocks: Menlo, Monaco, "Andale Mono", "lucida console", "Courier New", monospace;

I saved another couple kB's by using an emoji as favicon instead of creating one that takes up additional space. My website is hosted on GitHub with an automatic deploy pipeline. Access from within North America should be fast.

As of now, 07/27/224, transferred size via Cloudflare shows the following:

Next iteration?

To save further, I could avoid serving .html via different routes. Instead content could be rendered dynamically through CSS and html selectors. While this would save separate GET requests for content, it would clutter my codebase. I'm not sure if that is a trade-off I'm not willing to take.