Most websites are tested on the connection of the person who built them: fibre, in an office, on recent hardware, close to the server. Few readers are in that position. For the work we do, almost none are.
The reader we design for
The reader we hold in mind is on a phone, on mobile data, on a network that is intermittently congested and occasionally unavailable. They are paying for the bytes we send, by the megabyte.
This is not a charitable assumption about a small group of unlucky visitors. For anything we build that concerns Haiti, it is the median case. Designing for fibre and expecting the remainder to degrade gracefully inverts the priority.
The practical consequence is to stop treating performance as an optimisation phase and to treat it as an accessibility requirement. A page that cannot be loaded is not slow. It is unavailable.
What weight actually costs
Page weight is not the whole picture, but it is the part most within our control, and most of it is JavaScript.
An image is heavy and renders progressively. A megabyte of JavaScript is heavy, must be downloaded in full before it does anything, and must then be parsed and executed by a mobile processor slower than the machine it was written on. The same megabyte costs a reader on a modest device several times what it costs the engineer who added it.
The questions we ask of a dependency are therefore not limited to what it does. What does it weigh. Does it reach the browser at all. Is there a version of this feature that requires no JavaScript.
A considerable proportion of what a marketing site does requires none. Text, images, links and layout are capabilities browsers have always had. Animation, where weight tends to accumulate, can be expressed in CSS where it earns its place, and omitted entirely for readers who have asked for reduced motion.
Render on the server, then stay out of the way
The pattern we return to is straightforward: send finished HTML, and allow interactive elements to attach themselves afterwards.
A reader on a poor connection sees the article before the scripts arrive, and can read it if they never arrive at all. The elements that genuinely require the browser, a form, a language toggle, a reaction control, begin from a sensible server-rendered state and reconcile when they are ready.
This carries a second benefit that is easy to overlook. A server-rendered page can be cached at the edge and served from a location near the reader, which removes a round trip to our origin from the critical path. For a reader whose latency is already high, removing round trips contributes more than reducing kilobytes.
Make the first paint useful
Speed expressed as a single number matters less than what the reader can do at each moment.
A page that shows a loading indicator for one second and then everything at once is worse than a page that shows the headline and opening paragraph in three hundred milliseconds and completes afterwards. The first offers nothing during the wait. The second is already being read.
In practice this means the critical content, the words, belongs in the first response rather than in a script that runs after load. It means image dimensions are declared, so that nothing shifts when they arrive. It means a web font does not hold the text until it has finished downloading.
Fail in a way that tells the truth
Networks fail. What matters is what the reader sees when they do.
An empty page is the wrong answer, and a layout containing nothing, with no explanation, is worse. The reader cannot distinguish between no published articles, no connection, and a fault on our side. Each warrants a different response from them.
An empty state should therefore say which case applies, and offer the corresponding action. Nothing published yet reads differently from we could not reach the server, which reads differently from no results for your search. The last of those is a dead end unless it offers a way to clear the search.
How we know
None of this can be verified by intention. Throttle the connection in the browser’s developer tools to a slow mobile profile, enable CPU throttling, and load the page. Then repeat the exercise on a physical device. The measurements change, and so does the design.
It takes a few minutes, and it is the only way to establish whether we built the site we believe we built.