Website Update 2025
November 15, 2025 - Dallas McNeil - Web
I’ve made some major updates to my website to better align with my principles for software.
1. No External Runtime Dependencies
I don’t want to rely on other services existing and staying the same to display this site. It’s very common to fetch JavaScript libraries, fonts and images from external sites. There are advantages to that, such as in browser caching between sites1 and using CDNs that likely have the content cached and ready. But the downsides of inevitable future breaks or changes are not worthwhile. Being able to host the same set of files from anywhere and (hopefully) anytime in the future is more important to me. Of course, the browser is the biggest external dependency but there isn’t much choice in the matter today!
2. No JavaScript
I don’t want to require JS to display my site properly, it seems like a gross complication for what is just displaying some fairly simple static content. I used to use the Bootstrap 4 framework, mainly to support responsive design, but it’s really not necessary. A few CSS media queries can dynamically change layouts for different screen sizes, JS free! I still need to use JavaScript in a few small places, such as displaying equations with MathJax, so expect to see it on some pages as needed.
3. Fast Load Time
I spent a considerable amount of time looking at page load times. I want to leave a good first impression with performance being vitally important. Although I will probably use a CDN, chances are that this site isn’t accessed frequently enough to be cached at edge locations. I expect latency will remain a major factor for most loads and is unlikely to change. At the same time, throughput is only getting better and better globally. It is reasonable to expect at least a 10Mb/s connection as of 2025.
Considering these factors, I’ve observed a bad pattern in websites: sequential requests. It’s an easy trap to fall into
- Make the initial request for the page HTML
- The HTML links to separate CSS, requiring another fetch for it
- Potentially, that CSS includes links to fonts or images, requiring yet more fetches
This is pretty bad for load times when considering latency. If it takes 200ms to receive a response, then the absolute fastest time to load the full DOM with style is 400ms.
Why is this the case? Likely because most subsequently loaded CSS, fonts and images are common across pages and get cached locally. It’s really only the first load to a website that takes longer, and then following loads only need the HTML. These assets don’t need to be requested again.
20 years ago, when throughput was much lower, this was really important. But as I mentioned above, throughput is much better today and only getting better. So the time difference between sending a few extra KB or not really doesn’t matter. But it does make a huge difference when a subsequent request needs to be made.
I wanted to prioritise the first load time for this site so I made some intriguing choices.
- I bundle CSS in the head of every HTML file rather than linking to it. This removes the need for a second request to display the page
- Not only that, I embed the font into that CSS. Abiding by goal 1, relying on installed fonts is an external dependency2. The font is about 20KB with a minimal character set.
This means just with the single initial request, the entire DOM can be loaded with correct fonts. The only thing missing is images, which are requested separately. I would recommend including CSS with HTML, but I wouldn’t recommend including the fonts like I do. I might go back on this in the future.
Other measures to improve load time include:
- Using WebP for all images for the best quality to size tradeoff
- Minimising content so there is no extra whitespace or comments
Results
To compare between my site before and after, I used Chrome’s devtools. For tests, I disabled caching and limited the network to 10Mb/s and added 200ms of latency to requests. Looking at the timeline of requests, there is a massive impact.
Request timeline for old version. After the initial request for the page, many more requests need to be completed before all DOM content is loaded
Request timeline for new version. After the initial request for the page, the entire DOM is loaded and following requests are just for images
And comparing numbers
| Before | After | Reduction | |
| Time to load DOM content | 788ms | 257ms | 68% |
| Data for DOM content | 298KB | 39KB | 87% |
| Time to load all page content | 1220ms | 695ms | 43% |
| Data for all page content | 1008KB | 325KB | 68% |
This is also biased towards the older version. The new home page requires more images now.
Footnotes:
-
I had to check that caching assets between sites was a thing. There are many spooky privacy and security implications to that, but I’m glad to see that what once was, no longer is ↩
-
Web safe fonts are not formally defined and only assumed to be installed on systems. While a vast majority of systems will have it, there is no guarantee as I quickly found out when using Linux. ↩