Need for Speed

This site had one primary goal: be as fast as possible. I don't care about conversion rates (a different topic where speed equals money), but inclusion. Many people are browsing with their (often weak) mobile phones exclusively and in suboptimal conditions (indoor cellular, shared WiFi spot). They are waiting several seconds for most "modern" websites to load!

While theoretically our average connectivity infrastructure and devices got faster during the years, the perceived performance of websites did not. Websites and -apps got increasingly complex, bloated and chock-full of tracking, advertising and other scripts running in the background.

I tend to believe that developers entering the field recently are just accustomed to using several frontend-frameworks for styling and logic, that stakeholders demand more "fancy" stuff from them, but everything must be as cheap as possible, that it forms a vicious circle.

I do not want this any longer, neither as a developer nor as a user. My blog has no stakeholders other than me. I know how to do this a better way. There are many people out there who do not have the privilege of owning the latest iPhone and can count on super fast WiFi oder at least LTE everywhere, but I want to provide them with my writings as well.

Website building, the basics

The fastest, leanest way to deliver some content-based websites to readers is via plain HTML, period. Handcrafted, small, accessible. Read: not a mess of div and gazillions of CSS classes or inline styles.

Building every single page completely by hand, updating listings, ... and so on is not a sustainable option for me. I need to render some templates and partials dynamically or things will get a mess very fast. But leveraging a full blown backend technology might be overkill, too! Aside from me writing something new, there are zero updates to stuff in any way, so why have precious miliseconds wasted for "rendering" every page on demand, having to maintain yet an other server or service and think about admin things?

There is a better way: static site generators. You can have "dynamic templates", sitemap generation, all the stuff one would do on demand with a web server, but without the web server. Everything gets compiled once, after you edited something, and uploaded as final HTML files.

Nowadays there are several good options out there, many people use Hugo or Jekyll.

I went with Zola because it smells like Rust and should be the fastest of them all. (yes, I like my tools on the command line to be fast, too!)

Used correctly, you should have lean, static HTML files at the end, which are fast by default.

Styling without bloat

Plain HTML doesn't look that awesome, at least for me. On the otherhand, I hate the noise many modern CSS frameworks add to my lean HTML, aside from being several hundreds of kilobytes in size themselves. So, what do I actually need?

• some basic text and spacing styles for all elements on the page
• no surprises with different browsers
• something like a responsive grid system

... not that much after all.

As it turns out, there is a recent push towards so called classless css frameworks, or as I would call them, portable stylesheets. They do exactly this: apply some sane defaults to texts, margins so on, without the need to markup your HTML with special classes. Nice!

My choice was sakura, but there is an increasing amount of choice available.

The only problem left is that they don't provide a responsive grid system. As I learned, this is actually not a big deal. Browsers do support native css grid now!

This empowers me to accomplish stuff like boxes next to each other with ease, just a few lines CSS required in total.

Overall, my css of this website here should be in the ballpark of just 2 kilobytes over the wire... quite a feat!

Hosting near you

So I have statically compiled HTML pages and a minimal css file, but the main driver for (not only) perceived performance is latency. If I put my files on a server somewhere, people on the other side of the world would have to wait hundreds of miliseconds until they can see my content.

I can then put a CDN with locations all over the world in front of the server, so things would get cached near you. But still, the very first call to something would go straight to my server again, resulting in waiting times.

I went a bit more fancy than that with CloudFlare Workers Sites. It boils down to this: I host my static files directly on the edges of the CDN. At least this is written on the marketing page of the provider, and seems to work as promised.

As a result, this website should be as fast as theoretically possible for a minimal amount of work on my part. Some clever inlining of only-relevant css in the HTML itself might shave off another milisecond, but stuff like this is not idiomatic and creates some friction on my writing part.

Next steps

I received some good hints from Hackernews and one thing bugged me: I have no idea what people are actually reading here. CloudFlare does offer some basic traffic data, but only at the domain level.

As someone who actually values privacy, just throwing something like Google Analytics in the HTML template wasn't an option. It would have added multiple times the weight of the actual site, too. And GDPR consent popup windows and the like is also something I love to hate.

Since I have no webserver logs to inspect with a script, there is only one solution left: use some frontend tracking that does nothing other than counting page views.

There are a few products out there now, but I see it as a learning project opportunity for me: create a frontend tracking tool that is as lean and fast as possible, that does not use any user data. Just the raw page visit information itself, the "+1" of an url so to speak.

I think it would be a good small learning project to build something that does exactly this one thing.

Closing thoughts

I hope I can make a small difference by putting speed front and center for my stuff, so as many people as possible can enjoy what I do. As a side effect, I already got some digital product ideas just from rebuilding this site, like a lean analytics service.