Website Goals

TODO: Complete this page.

Pillars of website design:

  1. Usable by people on dial-up internet. I’m aware that it’s not an issue anymore in the US since the days that Dan Luu published their article on the subject, but I do think it’s important to optimize for people outside the US. (Aimed to have a page weight below 100kB, which produces about 15 seconds of bandwidth-induced load times on dial-up internet (you can do the math with a 56kbps line, it comes out to about 14.29 seconds of bandwidth-induced load times, and we’ll round up because 56kbps is never what dialup actually achieved in practice.) and an even lower page weight of 20kB of (compressed) render-blocking assets (which is just your homepage HTML and style.CSS file) to ensure an under 3 second bandwidth-induced load on dial-up. At time of writing (September 2025), Dan Luu successfully does this by serving a sole render-blocking HTML file compressed to 6.78kB, which decompresses to 20.21kB. Since a 56kbps line is able to download 7kB per second, he successfully keeps his bandwidth-induced load time to under 1 second. (Obviously, this is oversimplified, because it at these extremely low values the exact way in which his data fits into TCP packets starts to matter. Cite a source here, like that “keep your webpage under 14kB” article. I’m aware this is the most back-of-the-envelope math to ever be performed.))
  2. Instantaneous page navigation and perfect ergonomics on desktop connected to wifi with a 20ms ping.
  3. Maximal ergonomics on a phone with 5g NSA (non-standalone) network ping times, and subject to (sadly) non-trivial touchscreen latency even on an iPhone. This is where your 300ms delay removal comes into play, as well as the work you’re putting into using HTTP headers that prevent seeking a 304 code for re-pinging the server when navigating to a previously visited page, or where you’ve tried to make the browser re-render the page in the meantime with the stale-while-revalidate response directive. Also, in preparation for HTTP/3, you’ve tried to keep web page HTML weights always within 4-6kB in size (cite a source here for that number, and also try to understand it better yourslf before citing it) so that you can use HTTP/3’s 0-RTT optimization.
  4. Easily archivable with the Wayback Machine. A subcomponent of this goal means loading identical files from the server when the client is on mobile or desktop, regardless of which parts of those files actually get rendered.
  5. No JavaScript (as a political statement, and also as an intentional design choice to make sure that things you use don’t become added to the CSS standard later, making your design choices worse than what they would be if you’d used different tools.)
  6. Accessibility. I think it’s possible to design a website with screen readers in mind, and a lot of websites don’t do that. They focus on what the page looks like, but not how it’s semantically laid out. This is really important and I’d like to do it well. (Link the Tunetheweb article which goes over how to do this in-depth, and why/how you went about doing your header and footer elements the way you did, as opposed to how others have described they should be used.)
  7. Minimal UI movement
  8. Long-term readability, via picking a good font and good background colors. This is a website where I want you to stay a while, kick back, and enjoy yourself. Also, I’m kind of forced into making that kind of website, because making a website optimized for one-time page visits (like Strikingloo) is really hard to do perfectly, and I think the constraints of the internet make optimizing for repeated page navigations and long-term reading over multiple pages to be an easier route, not merely a worthwhile one.

Some things you’ve learned aren’t worth optimizing, but that you’d really like to optimize:

  1. Initial page load times. There’s an upper limit to how fast you can make a page load using current technology, and it mostly comes down to (a) latency and (b) the number of transfers you have to do even with HTTP/3 and current DNS support.

Some things that you never sought out to optimize:

  1. SEO
  2. Ad revenue
  3. Flashy animations or images
  4. Backwards compatibility with old browsers, like Internet Explorer.

Some things that you think are worth optimizing, but that you’ve chosen not to optimize.

  1. I11n. Support for readers of multiple languages is important, but–on a website like this, with lots of text content in the form of one-off articles, pages, and blog posts–it isn’t possible for me, an English speaker who only knows a smattering of Spanish and Japanese, to translate even the basic front pages of my website into multiple languages. I’ve declared this out of scope.
  2. Cross-browser compatibility for Safari. To be honest, the worst offender here is Safari’s (present-day in 2025) lack of support for SVG favicons. I think that’s a shame, since they’re obviously the best way to make a favicon. I think you should just do it the right way on your website and then wait for Safari to get its act together and support SVG favicons. 2a. (Maybe remove this) Having a variety of Favicon types, especially for compatibility with Safari. You’ve decided just to use SVG files and make them as compact as you conceivably can, then hope Safari adds support later. Also, you should double-check to make sure Android is okay with SVG icons, too? Once you publish your website, you should ask Uncle Chris to check for you. 2a’. UPDATE: Actually, it looks like Safari 26 beta now supports SVG icons everywhere in the interface, including favicons! That’s incredible news. You should research this a little to be sure of exactly how they did it. You found it on this wesbite: https://ios.gadgethacks.com/news/why-the-four-new-safari-features-in-ios-26-will-change-how-you-browse/

I also have side goals, of things that I think are important and will try to do, but will take some basic effort to accomplish and might be on the back-burner for a V1 website:

  1. Dark mode/light mode support, using the browser’s detected settings for the user. This will be hard to do while maintaining a coherent design language. I also don’t even know the basics of how to do it.
  2. Super optimized CSS selector design. I want to profile how much time my CSS selectors take and optimize the heck out of them, subject to solely constraints on the retaining semantic class names, not on maintainability. I think CSS should be pretty much a one-and-done design iteration process and I don’t care much about making it modifiable as I add more pages–but I do want to make it so I can easily go back and refactor it for existing pages if needed. Loris Cro should really make a dedicated SuperCSS file type for this.