Development

Page speed: why it's money

A slow website loses visitors before they see the offer. What usually slows it down, what can be fixed quickly and what's baked into the architecture.

Website speed is rarely seen as a commercial parameter. It doesn't show up in reports next to cost per request, and people start discussing it when someone complains. Yet slow loading subtracts from results twice: some visitors leave before the page appears, and the rest see it less often in search, because speed is part of how page quality is assessed.

How speed turns into losses

The mechanics are simple. A person clicked a link and is looking at a blank screen. While the screen is blank, they know nothing about your offer — no price, no terms, no arguments. Only the inertia of waiting keeps them there, and it runs out.

Then there are three typical outcomes, and all three are bad for you:

  • The visitor closes the tab and goes back to search, where they open the next result — a competitor.
  • The visitor waits for the page to load, but behaves more economically on a slow site: views fewer pages, opens fewer product pages, reaches the form less often.
  • The visitor taps a button, nothing happens, they tap again. At best that's a duplicate request; at worst, an abandoned cart.

Advertising works separately. You pay for each visit at the moment of the click, not at the moment of loading. If the page takes a long time to open, you've paid for a visit that effectively didn't happen.

And the third layer is search. Search engines measure the real user experience of loading; these metrics are known as Core Web Vitals: how quickly the main content appears, how quickly the page responds to an action, whether the layout jumps during loading. Speed doesn't outweigh relevance, but with comparable content quality it works against the slow site.

Speed isn't about technical perfectionism. It's about how many people actually saw what you paid to show them.

What usually slows things down

Images

The first and most common cause. A photo taken straight from a camera or downloaded from a stock library weighs many times more than the page needs. A dozen such images on the home page, and loading becomes heavy regardless of everything else.

Typical mistakes here: the original size instead of one prepared for the layout; an outdated format instead of modern ones; no variants for different screens, so a phone downloads an image meant for a large monitor; loading all of a page's images at once, including those far down the page.

The good news: this can almost always be fixed without reworking the site.

Unnecessary scripts

Code that runs in the browser first has to be downloaded, then parsed, then executed. On a weak phone, the last two stages take noticeably longer than on a developer's work laptop.

Scripts pile up unnoticed. A library was added for one effect, then another for a slider, then a whole icon set for six icons, then a heavy font package with every weight. Individually trivial; together, a delay before the first screen is drawn.

Third-party widgets

Chats, maps, forms from external services, review widgets, counters, ad system pixels, subscription pop-ups. Every such widget is code from someone else's server, whose speed you don't control.

The worst case is when a widget is connected in a way that blocks page rendering. Then someone else's slow server directly delays the display of your content. It's also worth simply counting the widgets: some were usually added for a task that was closed long ago, and removing them is the cheapest way to speed up.

The server and database queries

Sometimes the browser has nothing to draw because the server is taking a long time to think. The causes vary: inefficient database queries, no caching, a weak hosting plan, heavy computation on every page view. Outwardly it looks like "the site is slow in general", not tied to any particular image.

Fonts and jumping layout

A separate story — not a delay but unpleasant behaviour: text is invisible at first or shown in one font, then swapped; blocks shift; an ad is inserted in the middle and pushes content down. Formally the page loaded quickly; in practice it can't be used for the first few seconds. This is also counted in the page quality assessment.

Mobile internet is the norm, not the exception

Development and acceptance are almost always done on a fast connection and a good device. A real visitor often opens the site on a phone, in the underground, on the road, with a weak signal, on a device bought several years ago.

The difference between these two situations is huge, and it isn't just about connection speed. On a weak processor, it's executing code that costs the most: the more scripts, the bigger the gap. So speed should be checked under conditions close to real ones, not on the office Wi-Fi.

What can be fixed and what's built into the architecture

Some problems are solved in a targeted way and relatively quickly:

  1. Compress and properly prepare images, and serve different sizes for different screens.
  2. Defer loading of what isn't visible on the first screen.
  3. Remove unused scripts and libraries added "just in case".
  4. Connect third-party widgets so they don't block rendering, and load heavy ones on user action.
  5. Set up caching and compression on the server.
  6. Limit the set of fonts and their weights.

The other part can't be fixed in a targeted way. If a page is built so that the browser first downloads a large application and only then starts drawing content, no image optimisation will make up for it. The same goes for overloaded site builders and themes where every page loads the code for the entire feature set; for a database designed without considering data volume; for a server that rebuilds the page from scratch every time.

You can tell one from the other by this sign: if cleaning up images and scripts brings no noticeable improvement, the problem isn't the content but the structure. Then the honest conversation isn't about optimisation but about what to change at the foundation. We work through such cases in our work on websites and web applications.

What to do this week

  1. Open your site on a phone using mobile data — the home page, the catalogue and one inner page.
  2. Run the main pages through any public measurement tool and look at mobile mode, not desktop.
  3. Check how much the heaviest image on the home page weighs and whether it needs to be that size.
  4. List all third-party widgets and honestly answer which of them are still needed.
  5. Check whether the layout jumps in the first seconds of loading.
  6. Start measuring regularly, not once: speed degrades gradually, along with new content and new integrations.

Speed isn't a one-off job but a parameter that has to be maintained. It's easiest when it's tracked alongside the site's other metrics — in the same place where traffic sources and requests are watched, that is, in analytics.