mirror of
https://git.sr.ht/~seirdy/seirdy.one
synced 2024-11-15 01:42:10 +00:00
6f937ac5a8
Thanks to some IRC users for pointing out how the rationale wasn't very obvious
146 lines
6.9 KiB
Markdown
146 lines
6.9 KiB
Markdown
---
|
||
date: "2020-11-23T12:21:35-08:00"
|
||
outputs:
|
||
- html
|
||
- gemtext
|
||
tags:
|
||
- web
|
||
- rant
|
||
- minimalism
|
||
title: An opinionated list of best practices for textual websites
|
||
---
|
||
|
||
*The following applies to minimal websites that focus primarily on text. It does not
|
||
apply to websites that have a lot of non-textual content. It also does not apply to
|
||
websites that focus more on generating revenue or pleasing investors than being good
|
||
websites.*
|
||
|
||
I realize not everybody's going to ditch the Web and switch to Gemini or Gopher today
|
||
(that'll take, like, a month at the longest). Until that happens, here's a
|
||
non-exhaustive, highly-opinionated list of best practices for websites that focus
|
||
primarily on text:
|
||
|
||
- Final page weight under 50kb without images, and under 200kb with images.
|
||
- Works in Lynx, w3m, links (both graphics and text mode), Netsurf, and Dillo
|
||
- Works with popular article-extractors (e.g. Readability) and HTML-to-Markdown
|
||
converters. This is a good way to verify that your site uses simple HTML and works
|
||
with most non-browser article readers (e.g. ebook converters, PDF exports).
|
||
- No scripts or interactivity (preferably enforced at the CSP level)
|
||
- No cookies
|
||
- No animations
|
||
- No fonts--local or remote--besides `sans-serif` and `monospace`. More on this
|
||
below.
|
||
- No referrers
|
||
- No requests after the page finishes loading
|
||
- No 3rd-party resources (preferably enforced at the CSP level)
|
||
- No lazy loading (more on this below)
|
||
- No custom colors OR explicitly set the both foreground and background colors. More
|
||
on this below.
|
||
- Supports dark mode and/or works with most "dark mode" browser addons
|
||
- A good score on Mozilla's [HTTP Observatory](https://observatory.mozilla.org/)
|
||
- Optimized images. You also might want to use HTML's `<picture>` element, using
|
||
jpg/png as a fallback for more efficient formats such as WebP or AVIF. Use tools
|
||
such as [oxipng](https://github.com/shssoichiro/oxipng) to optimize images.
|
||
|
||
I'd like to re-iterate yet another time that this only applies to websites that
|
||
primarily focus on text. If graphics, interactivity, etc. are an important part of
|
||
your website, less (possibly none) of this article applies.
|
||
|
||
Early rough drafts of this post generated some feedback I thought I should address
|
||
below. Special thanks to the eight IRC users who provided feedback!
|
||
|
||
About fonts
|
||
-----------
|
||
|
||
If you *really* want, you could use `serif` instead of `sans-serif`, but serif fonts
|
||
tend to look worse on low-res monitors. Not every screen's DPI has three digits.
|
||
|
||
To ship custom fonts is to assert that branding is more important than user choice.
|
||
Beyond basic layout and optionally supporting dark mode, authors should not dictate
|
||
the presentation of their websites; that is the job of the user agent. Most websites
|
||
are not important enough to look completely different from the rest of the user's
|
||
system.
|
||
|
||
### But most users don't change their fonts...
|
||
|
||
The "users don't know better and need us to make decisions for them" mindset isn't
|
||
without merits; however, in my opinion, it's overused. Using system fonts doesn't
|
||
make your website harder to use, but it does make it smaller and stick out less to
|
||
the subset of users who care enough about fonts to change them. This argument isn't
|
||
about making software easier for non-technical users; it's about branding by
|
||
asserting a personal preference.
|
||
|
||
### But wouldn't that allow a website to fingerprint with fonts?
|
||
|
||
I don't know much about fingerprinting, except that you can't do font enumeration
|
||
without JavaScript. Since text-based websites that follow these best-practices don't
|
||
send requests after the page loads and have no scripts, fingerprinting via font
|
||
enumeration is a non-issue.
|
||
|
||
About lazy loading
|
||
------------------
|
||
|
||
For users on slow connections, lazy loading is often frustrating. I think I can speak
|
||
for some of these users: mobile data near my home has a number of "dead zones" with
|
||
abysmal download speeds, and my home's Wi-Fi repeater setup occasionally results in
|
||
packet loss rates above 60% (!!).
|
||
|
||
Users on poor connections have better things to do than idly wait for pages to load.
|
||
They might open multiple links in background tabs to wait for them all to load at
|
||
once, or switch to another window/app and come back when loading finishes. They might
|
||
also open links while on a good connection before switching to a poor connection; I
|
||
know that I often open 10-20 links on Wi-Fi before going out for a walk in a
|
||
mobile-data dead-zone.
|
||
|
||
Unfortunately, pages with lazy loading don't finish loading off-screen images in the
|
||
background. To load this content ahead of time, users need to switch to the loading
|
||
page and slowly scroll to the bottom to ensure that all the important content appears
|
||
on-screen and starts loading. Website owners shouldn't expect users to have to jump
|
||
through these ridiculous hoops.
|
||
|
||
### Wouldn't this be solved by combining lazy loading with pre-loading/pre-fetching?
|
||
|
||
A large number of users with poor connections also have capped data, and would prefer
|
||
that pages don't decide to predictively load content ahead-of-time for them. Some go
|
||
so far as to disable this behavior to avoid data overages. Savvy privacy-conscious
|
||
users also generally disable pre-loading because they don't have reason to trust that
|
||
linked content doesn't practice dark patterns like tracking without consent.
|
||
|
||
Users who click a link *choose* to load a full page. Loading pages that a user hasn't
|
||
clicked on is making a choice for that user.
|
||
|
||
### Can't users on poor connections disable images?
|
||
|
||
I have two responses:
|
||
|
||
1. If an image isn't essential, you shouldn't include it inline.
|
||
2. Yes, users could disable images. That's *their* choice. If your page uses lazy
|
||
loading, you've effectively (and probably unintentionally) made that choice for a
|
||
large number of users.
|
||
|
||
About custom colors
|
||
-------------------
|
||
|
||
Some users' browsers set default page colors that aren't black-on-white. For
|
||
instance, Linux users who enable GTK style overrides might default to having white
|
||
text on a dark background. Websites that explicitly set foreground colors but leave
|
||
the default background color (or vice-versa) end up being difficult to read. Here's
|
||
an example:
|
||
|
||
<picture>
|
||
<source srcset="https://seirdy.one/misc/website_colors.webp" type="image/webp">
|
||
<img src="https://seirdy.one/misc/website_colors.png" alt="This page with a grey background, a header with unreadable black/grey text, and unreadable white-on-white code snippets">
|
||
</picture>
|
||
|
||
If you do explicitly set colors, please also include a dark theme using a media
|
||
query: `@media (prefers-color-scheme: dark)`.
|
||
|
||
Other places to check out
|
||
-------------------------
|
||
|
||
The [250kb club](https://250kb.club/) gathers websites at or under 250kb, and also
|
||
rewards websites that have a high ratio of content size to total size.
|
||
|
||
Also see [Motherfucking Website](https://motherfuckingwebsite.com/). Motherfucking
|
||
Website inspired several unofficial sequels that tried to gently improve upon it. My
|
||
favorite is [Best Motherfucking Website](https://bestmotherfucking.website/).
|