Someone on your team says the site feels slow. Someone else opens it on their laptop, on office Wi-Fi, and it loads instantly. The conversation stalls there, and nothing gets fixed for six months. We've walked into this exact room more times than we can count.

So here's the version of web performance we'd explain to a founder over coffee — no code, no jargon, and no recommendation to rebuild anything. Once you understand what a browser is actually doing in those first few seconds, the fix list gets short and surprisingly boring.

What actually happens when someone opens your page

A web page isn't a file that arrives all at once, like a PDF. It's a shopping list. The browser fetches the list first, reads it, discovers it needs more things, fetches those, reads them, discovers more things, and so on. Every round of that is a trip across the internet and back.

1. 01The browser asks the internet where your domain lives, then opens a connection to that server. On a phone this handshake alone can take a few hundred milliseconds before a single byte of your site has moved.
2. 02The server sends back the HTML — the skeleton. At this point the page is blank.
3. 03The browser reads the skeleton and finds references to stylesheets, fonts, scripts, and images. It goes and fetches those. Some of them it refuses to draw anything until it has.
4. 04Once enough has arrived, it paints. Then it keeps loading the rest — analytics, chat widgets, tracking pixels, that carousel below the fold — while the person is already trying to read and tap.

Slow sites are rarely slow because one step is broken. They're slow because each step is a little heavier than it needs to be, and the steps happen in sequence.

Why 'it's fast on my laptop' is a trap

Your laptop has a fast processor, a cached copy of your own site, and an office connection. Your customer has a three-year-old mid-range Android, one bar of mobile data, has never visited before, and is standing in a queue. Those two experiences can differ by ten seconds on the same page.

The arithmetic is unforgiving. A 2 MB hero image on a typical mobile connection is several seconds by itself — before any of your fonts, scripts, or product photos have started. Nobody notices that image is 2 MB, because on the laptop where it was uploaded it appeared instantly.

The three numbers Google actually watches

You'll hear the term Core Web Vitals. It sounds like a compliance regime; it's really three questions written in plain language.

• Did the main thing show up quickly? (Largest Contentful Paint.) Usually your hero image, headline, or product photo. Google wants this under about 2.5 seconds. This is the number most sites fail.
• Did it respond when I tapped? (Interaction to Next Paint.) You tap 'Add to cart' and nothing happens for half a second because the browser is busy running scripts. Users read that pause as 'broken', tap again, and order two.
• Did it stop jumping around? (Cumulative Layout Shift.) The text moves as a late-loading banner pushes it down, and you tap the wrong thing. This is the one that makes a site feel cheap even when it's fast.

Those three cover almost everything a real person means when they say a site feels bad. They're worth knowing not because Google grades you on them — though it does — but because they're a decent translation of human frustration into something engineers can fix.

The four fixes, in the order we'd do them

1. Images — almost always the biggest win

On most sites we audit, images are more than half the page weight. The fixes are unglamorous: serve modern formats instead of giant JPEGs and PNGs, ship an image sized for the space it occupies rather than the 4000-pixel original, and let anything below the fold load only when the person scrolls toward it.

One caveat that catches teams out: don't lazy-load the hero image. It's the first thing people see, so telling the browser to defer it makes the headline number worse, not better. Defer everything below the fold; prioritise the thing at the top.

2. Fonts — the invisible text problem

Custom fonts arrive as separate downloads. By default, many browsers will hold text back until the font shows up — so your copy is written, delivered, and sitting there invisible, waiting on a decorative file. On a slow connection that's a second or two of blank page for no reason.

The fix is to show the text immediately in a fallback font and swap when the real one lands, host the font yourself rather than fetching it from a third party, and be honest about how many weights you actually use. Most brand systems ship four and use two.

3. Third-party scripts — the ones nobody remembers adding

Analytics, heatmaps, chat widget, two ad pixels, a review embed, a cookie banner, an A/B testing tool from a campaign that ended last year. Each was added in five minutes by a different person, and each one runs code on your customer's phone. This is usually where the tap-delay problem comes from.

Do an inventory. For every script, ask who reads its output and when they last did. Remove what nobody's looking at, load what's left after the page is usable, and stop letting a marketing tool block a checkout button.

4. Where your server is — and whether it's repeating itself

If your server sits in Virginia and your customers are in Dhaka, every request pays for that distance. A CDN — a network of caches spread around the world — keeps copies of your pages close to the people asking for them. For a mostly-static marketing site or catalogue, this can be the difference between a page that feels regional and one that feels local.

Related: if a page shows the same thing to everybody, the server shouldn't rebuild it from scratch on every visit. Build it once, cache it, and refresh it when the content changes. Most catalogue and content pages qualify. Most teams have never checked.

What we do before touching anything

Measure. Not because it's rigorous-sounding, but because performance work without a baseline turns into taste, and taste arguments never end. We take a mobile measurement on a throttled connection before we start, write it down, and re-measure after each change. That way you can see which fix bought you what — and stop when the remaining work stops paying.

It also protects you from the most expensive mistake in this whole area: rebuilding the site. Almost nobody who says 'the site is slow, we need a rewrite' has an image budget, a script inventory, or a caching layer. A rewrite that repeats those three mistakes produces a slow new site, at ten times the cost.

What this looked like in practice

When we built the Al-Bayt Elegance storefront, the audience was shopping on mobile data in Bangladesh, largely on mid-range Android, in a category where the photography has to look good — fabric drape and finish are the product. Fast and image-heavy pull in opposite directions, which is precisely why the four items above got decided up front rather than patched later.

That's the honest summary of most performance work: not clever, just decided early and defended. The teams with fast sites aren't the ones who optimised hardest. They're the ones who never let the page get heavy in the first place.

If your site feels slow and you'd like a second opinion before anyone proposes a rebuild, the discovery call ends with three written recommendations you could act on tomorrow — whether or not you work with us.