Website Philosophy

My reasoning behind some of the unusual technological decisions on aaronmassicotte.com

· updated Jul 17, 2026 · tech

Introduction

Computing has come a very long way over the recent decades, but one thing which astounds me is how incredibly inefficient things have ended up. Because performance is so high and storage so cheap, software has gotten bloated with dead code that never gets used, or worse resources that are wasted. I think the best examples are when modern software takes longer to load with hardware 100X more powerful than what existed maybe 2 decades prior

The web is one of the biggest offenders, with javascript being the culprit. Web pages load sometimes more than 10 megabytes of content just to share a simple blog article with somebody. Images are uncompressed, multiple heavy trackers are running in the background, and many features are loaded which never get used. This degrades the user experience, causes unnecessary network traffic, wastes energy, and is generally poor practice. The dirty hidden truth behind the sleek designer UI of most webpages

So my quest with this website is to prove how far things can go when the technology is kept simple.

The Tech

This website was built with Hugo and serves static files wherever possible

The stylesheet is handwritten, holding only the pieces this site actually uses. Minified and compressed it comes to about 5 kb, and the whole homepage, markup and styles and analytics together, arrives in under 10 kb

The analytics are done with a self-hosted instance of Plausible, which adds only 1 kb to the browser

The static files come straight from a single small server, brotli compressed ahead of time so nothing is compressed per request

Even the small flourishes are made to cost almost nothing. The colour that shifts with the season and the hour adds about half a kilobyte to the cached stylesheet. The moon adds roughly two hundred bytes to each page. Both are drawn with gradients rather than images, so they replace a download instead of adding one

Color changing

The accent color here isn’t fixed. It shifts with the calendar and the clock: the month sets a base hue (spring leans magenta, summer green, autumn orange, winter purple) and the time of day tints it (warm yellow at dawn, none at midday, indigo at dusk, blue at night). Every combination is nudged to stay legible, and it costs no extra request, only the handful of bytes that hold the palette

Pick a month and a time of day and the whole page recolors. Reloading returns it to now

The moon

In dark mode a faint moon sits in the top corner. It is not a picture: it is two gradients and a mask, so it costs no request. Its fullness follows the real lunar phase, worked out from the date because the lunar month is a fixed 29.53 days, so the phase is just arithmetic. It arcs across the header with the hour, sets low into the page, and slips away for a few hours around midday, the way the real moon does

Look up on a clear night and it should more or less match. The phase and the position together are about two hundred bytes in the same head script that sets the colour

Drag to steer it. In dark mode the faint corner moon follows along too, and reloading returns it to now

Performance optimizations

Keeping the page small is only half of it. The site is tuned at every layer between the file and the screen: how things are built and compressed, how they are cached, and how the connection itself is set up. Almost all of the work happens once, ahead of time, so a visitor pays for hardly any of it

Build and delivery

Every text file is compressed once when the site is built, at the strongest brotli and gzip settings, and both copies are shipped. The server hands over the finished compressed file, so nothing is compressed again for each visitor. Files under about 256 bytes are left alone, since a compressed copy of something that small would only come out larger. Stylesheets and scripts are named with a hash of their own contents and cached for a year, so a browser fetches each one once and the name changes only when the file does. Even the site icon is written straight into the page instead of fetched as a separate file

The connection

The files come from a single small server with no CDN in front, so the connection is tuned to make that origin quick. It speaks both HTTP/2 and HTTP/3 over QUIC. A returning visitor resumes the encrypted session from a ticket rather than repeating the full handshake, which is the largest saving of all. The security certificate is issued in two forms, RSA and ECDSA, so each browser is handed the faster one it can use. Compression at the proxy is set to a middle level rather than the maximum on purpose: the maximum was measured at roughly 44 milliseconds per request for a few hundred bytes, a poor trade with no CDN to absorb it, and the files built ahead already carry the strongest setting. One shortcut, 0-RTT, was left switched off deliberately, since its replay risk is not worth the small saving. Links you are likely to open next are quietly fetched in advance so the following page appears at once

The stylesheet

The css is handwritten, holding only the pieces the site actually uses. The styling for the comment box lives in a separate file that loads only if someone opens the comments, so it never sits in the way of the first render. The comment system’s own stylesheet, around 14 kb, used to be fetched uncompressed from its server every time comments loaded; it is now folded into that same cached and compressed file. Small touches like the expand arrow are drawn with css shapes rather than embedded images

JavaScript

There is almost none, and what little exists stays out of the way. The analytics load only after the page has finished, so they never delay anything a visitor sees. The one small inline script is placed before the stylesheet on purpose, so it does not have to wait for the css to arrive. Comments load only when asked for, by a click, unless you are already signed in. Icons are drawn once into a hidden sprite and referenced from there instead of repeated on every use

Images

Every image is prepared in several sizes and the browser picks the one that fits the screen. Anything below the fold waits until it is scrolled near, and each image reserves its width and height so the page does not jump as it loads. Galleries show their first photo at once and load the rest as you go. Videos fetch only their metadata until played

Each new flourish is held to the same rule: it may add bytes only if it adds something real, and wherever it can it replaces a download instead of adding one

Reality

I just want to make clear that this isn’t meant to be a persuasive argument for us all spending hours obsessing over small details. Businesses need to make money; it is not necessary nor the biggest issue to tackle. I hope that one day things can be as efficient as MenuetOS