Building Websites for Connections That Aren't Fast

A page that loads in two seconds on office fibre can take eight on mobile data in Beirut during a bad hour. The visitors on that connection are the ones who leave first, because they have learned to. If a meaningful share of your customers browse on variable connections — which in Lebanon is most of them — page weight matters more than design polish, and the gap is wider than it would be in a market with reliable infrastructure.

Why does this matter more here?

Three reasons that compound.

Mobile data does most of the work. A large share of browsing here happens on phones, on networks whose performance varies by the hour and by the neighbourhood. The connection someone had yesterday is not the one they have now.

Power cuts change how people browse. Someone browsing during an outage is on mobile data, possibly on a tower under load, on a battery they are conserving. That visitor has no patience for a four-megabyte page, and correctly so.

Older devices stay in service longer. Page weight is not only bandwidth — JavaScript has to be parsed and executed, and that is CPU work. A phone three or four years old does that work considerably slower than the one a designer is testing on.

The commercial consequence is straightforward. In a market with good infrastructure, a heavy site is a mild disadvantage. Here, it is a filter that removes customers before they see anything, and you never learn who they were.

What actually breaks first?

Rarely the text. In order:

Images. Almost always the largest thing on the page and almost always the least optimised. A single uncompressed hero photograph can outweigh an entire well-built site. We measured a live restaurant site recently carrying 1.9MB in five PNG heroes that should have been WebP — that one issue was most of its load time.

Fonts. A custom font loaded badly leaves text invisible until the file arrives. On a slow connection that can be several seconds of blank space where your headline should be. Loaded properly, the page renders in a fallback and swaps.

JavaScript. The slowest to recover from, because it has to download, parse and execute before anything depending on it works. A site that renders its content with JavaScript shows a blank page until all of that finishes. If a script request fails — which happens on unstable connections — it may never finish.

Third-party scripts. Chat widgets, analytics, embedded maps, tracking pixels. Each is a request to someone else's server at a speed you do not control. If their server is slow today, your page is slow today.

Notice that none of these are your content. The thing your visitor came for is usually a few kilobytes of text, arriving last, behind everything else.

What does building light actually involve?

Five decisions, made early, that are hard to retrofit.

Render on the server, not the browser. Send finished HTML. The page should be readable before any JavaScript runs, so a failed or slow script degrades the experience rather than preventing it.

Ship images in a modern format, sized for their slot. WebP or AVIF rather than PNG or JPEG, at the dimensions actually displayed. This is usually the single biggest available win — the details are here.

Load only what the page uses. Not the whole framework because one page needs a carousel. Most pages need very little JavaScript, and most sites send all of it to all of them.

Reserve space for everything. Explicit width and height on images so nothing jumps when a slow image finally lands. On a bad connection, layout shift is far more disruptive than on a fast one, because the gap between text arriving and images arriving is longer.

Prioritise the visible. The hero image should load first and never be lazy-loaded. Everything below the fold should wait. Getting this backwards is common and costly.

How do you test on a bad connection deliberately?

You cannot judge this from your own machine. Test it properly:

1. Chrome DevTools → Network → throttling → Slow 4G. Reload and watch what appears and in what order. This is the closest easy approximation of a real bad connection.
2. Disable JavaScript entirely and reload. If the page is blank, you have learned something important — that is roughly what a crawler sees, and what a visitor whose script request failed sees.
3. Use a real phone on mobile data, not wifi, ideally an older one. Simulations miss CPU limits.
4. Check the field data in PageSpeed Insights. Real visitor measurement, including everyone whose connection is worse than yours.

The gap between the lab simulation and your own experience of the site is usually the surprise. Most people building websites are on good connections on new hardware, which is the least representative possible test environment.

Isn't this a trade-off against design?

Less than people assume, and the assumption costs money.

Weight comes from unoptimised assets and unnecessary code far more often than from ambition. A generous, confident layout with good typography can be under 200KB. A cluttered one with a stock-photo slider can be four megabytes. The heavy one is not more designed — it is less edited.

Where there is a genuine trade-off, it is usually about motion and imagery, and it is worth making deliberately. An animation that delays your largest paint is costing you visitors. One that runs on transforms after the page is readable costs nothing. That is a technical decision inside a design one, and it is exactly where a lot of otherwise good sites lose.

The version of this we hit ourselves: our own homepage measured a 2.3-second Largest Contentful Paint because a hero paragraph faded in behind a delay. The page painted in 0.27 seconds. The animation, not the page, was the problem — the full account is in the speed pillar.

What about the site itself going down?

Worth separating from load speed, because they get conflated locally.

A site served as static files from a global network does not go down when the grid does. There is no server in Beirut to lose power. The files sit on edge locations worldwide and are served from whichever is nearest the visitor.

What an outage affects is your visitors' connections and your ability to respond to enquiries. Neither is fixed by hosting choices. Both are eased by a site light enough to load on a degraded connection and clear enough that someone can act without your involvement — which is most of the argument for handing the order to WhatsApp rather than a checkout.

Where to go next

Core Web Vitals in plain language covers how this is measured, and why page builders are slow covers the most common structural cause.

This is the constraint we design around first for Lebanese clients — how that works in practice, and what it meant for one Beirut business.

If you want to know how your own site behaves on a throttled connection rather than on office fibre, ask us to test it.