Why we build for a 3G connection first
Every developer works on a fast machine with a good connection. That is the problem. The site feels instant on your desk, so you never find out that it takes eleven seconds on a four-year-old Android phone on mobile data, which is how a large share of your visitors will actually see it.
We now treat the slow case as the default case. Not as a final optimisation pass, but as the constraint we design against from the first day. It is a meaningful change in how a project runs, so it is worth explaining what it involves.
Retrofitting performance rarely works
The usual sequence is: build the site, launch it, notice it is slow, then hire someone to make it fast. This mostly fails, because by then the slowness is structural. The heavy framework, the design that needs six web fonts, the hero video, the four analytics scripts marketing added — none of those are things you can strip out afterwards without redoing the work.
Performance is not a feature you add. It is a consequence of decisions you already made. So the decisions have to be made with it in mind.
What we hold ourselves to
Vague goals do not survive a deadline. Numbers do. Our working budget for a typical marketing or business site:
- Under 1.5 seconds to first contentful paint on a mid-range Android device over mobile data
- Under 150 KB transferred for the initial view, compressed
- No render-blocking request to any third-party domain
- Usable without JavaScript for anything that is fundamentally a document
These are not aspirations. If a design cannot be built inside them, the design changes, or we have an explicit conversation with the client about what we are trading away and why. Writing the budget down early is what makes that conversation possible.
What it actually changes
Fonts
Web fonts are usually the single biggest avoidable cost on a business site. A typical setup pulls several weight files from a third-party domain, which means a DNS lookup, a TLS handshake and a download before any text renders in the right typeface.
This site uses no web fonts at all. The brand specifies a standard sans-serif, so we use the one already on the device. That is zero requests and zero bytes for typography, and text renders on the first paint instead of after it.
The fastest request is the one you never make. Most performance work is just finding requests that did not need to exist.
JavaScript
A great many sites ship a full client-side framework to render what is fundamentally a document. The framework has to download, parse and execute before anything appears — and parsing is the expensive part on a cheap phone, far more than the download itself.
For content sites we send HTML. The JavaScript on this page is a few
kilobytes handling the menu, the scroll animations and a progress bar, loaded
with defer so it never blocks rendering. If it fails to load,
every word on the page is still readable and every link still works.
Images
Images are where budgets quietly die. The rules we apply without exception: modern formats, correctly sized variants rather than one large file scaled down in the browser, explicit width and height attributes so the layout does not jump, and lazy loading for anything below the fold.
One uncompressed photograph straight from a phone camera can be larger than every other asset on the page combined.
Animation
Motion is not automatically expensive, but the wrong kind is. Animating layout properties forces the browser to recalculate positions on every frame, which is exactly what a slow device cannot afford.
We animate only transform and opacity, which the
browser can hand to the GPU. Scroll effects are batched into a single
animation frame rather than running work on every scroll event. And
everything is disabled outright when the visitor has asked for reduced
motion, which is both an accessibility requirement and a free performance
win on the devices least able to cope.
Test on the real thing
Lab tools are useful but they are not the truth. Throttling a fast connection in a browser simulates bandwidth; it does not simulate a weak signal, packet loss, a congested tower at 7pm, or a phone with four year old silicon and no free memory.
So we keep older mid-range Android devices in the studio and load the site on them on mobile data, in different parts of the valley. It is a low-tech method and it finds things no synthetic test does.
Why this matters here specifically
In Nepal the majority of traffic to most sites we build arrives on a phone, often on mobile data, frequently on a device in the lower half of the price range. A site tuned for a laptop on fibre is tuned for a minority of its own audience.
There is a commercial argument as well as a technical one. People leave slow pages. Every second of delay before your content appears costs you a share of the visitors you already paid to attract. Performance work is usually the cheapest conversion work available.
The short version
Decide your numbers before you start. Send less. Use what is already on the device. Test on a real phone on real mobile data. Almost everything else follows from those four.