Website Speed: When It Actually Moves Money and How to Check It with Semalt

Few digital marketing conversations have become as superstitious as the one about speed. There are companies chasing a green number in a lab tool for months while their product page takes six seconds to show the price to a real user on mobile data in the metro.

This article tries to restore order: what each thing measures, when speed genuinely affects the business, and which interventions return money versus those that only move the score.

Lab and field: two things confused daily

A lab tool loads your page under controlled conditions and returns a score. It is useful for diagnosis, because it points at heavy resources and render-blocking assets. But it describes nobody's actual experience.

Field data comes from real users, with their devices, their networks and their locations. It is the one correlated with behaviour: abandonment, pages per session, conversion. When the two disagree, field data wins, always.

Map first, engine second

Before touching a line of code it is worth knowing which pages matter. Search data gives you that in half an hour: which URLs receive impressions and clicks, which concentrate commercial queries, and which take most of the mobile traffic.

The interventions that actually return money

Ordered by effort-to-result ratio, based on what we see in real commerce and services projects.

Images. Still the number one problem on most sites: multi-megabyte product photos served to a phone. Modern formats, declared dimensions and deferred loading of off-screen assets solve a huge share of the problem without touching the architecture.

Third-party scripts. Chats, maps, ad pixels, A/B tests, consent banners. Audits routinely find eight to fifteen scripts, half of them inherited from campaigns that ended years ago. Removing the unused ones is free and is usually the single biggest improvement.

Visual stability. Content jumping while the page loads is not merely annoying: it causes mis-clicks and abandonment. Reserving space for images, ads and notices prevents most of it.

Server response time. If the server is slow to deliver the HTML, no downstream optimisation compensates. It is usually a caching misconfiguration rather than insufficient hardware.

Real mobile versus simulated mobile

There is an enormous difference between opening the site on a phone connected to office wifi and opening it the way a customer does: on mobile data, with battery saver on, moving, with fifteen tabs open. Almost every serious experience problem we have found appears in the second scenario and is invisible in the first.

The test we recommend is as simple as it is uncomfortable: leave the building, walk two blocks and complete the revenue action on a phone. Buy, request a quote, book. Whatever fails there is the quarter's priority list, ahead of any automated report.

Who should own performance

Speed tends to fall between teams: marketing measures it, engineering fixes it, and nobody prioritises it. The arrangement that works is naming one owner for the page inventory - which pages matter and what their field numbers are - and agreeing a fixed slot each quarter for the technical work. Without that slot, performance improvements only happen after an incident, which is the most expensive moment to make them.

When speed is not the problem

There are situations where investing in speed changes nothing, and recognising them before spending matters.

If the page already loads under two and a half seconds in the field, further improvement has marginal effect: the bottleneck is content, price or proposition. If the page gets no visits because it is neither ranked nor indexed, speed is irrelevant until traffic exists. And if the form asks for fourteen fields, no millisecond will fix conversion.

The hidden cost of third-party tools

This deserves its own section because it is by far the most widespread problem and the easiest to fix. In the performance audits we run on shops and service websites, the pattern repeats: eight to fifteen external scripts loading on every page, with nobody remembering what half of them are for.

The inventory takes an afternoon. List every script loading on the homepage and on a product page, and for each answer three questions: what it does, who inside the company uses it, and what would happen if it were removed. The third is the key, because it forces someone to defend each tool. The ones nobody defends get removed.

What usually turns up: pixels from campaigns that ended years ago, two analytics systems measuring the same thing, a chat nobody has answered in months, A/B testing tools with no active tests, and review widgets loading heavy iframes. Removing the surplus costs nothing, needs no redesign, and usually improves real experience more than any code optimisation.

Ecommerce: where it genuinely hurts

In a shop, the impact of speed is not evenly spread across pages. It concentrates in three moments, and those are the ones to measure separately.

The first is the product page on mobile, because that is where the user decides. If price, availability and the buy button are not in the first screen and under three seconds, improvements anywhere else on the site are secondary.

The second is filter navigation in large categories. Every filter application that takes several seconds multiplies abandonment, and it is usually also the point where URLs get generated that should never be indexed.

The third is checkout. Here the problem is rarely technical: it is unnecessary fields, validations that wipe entered data, and steps demanding account creation before showing shipping costs. No millisecond optimisation compensates for a badly designed form, and that is worth saying out loud when the conversation focuses only on the score.

How search engines actually weigh it

Page experience is one signal among many, and not the most decisive. Between two pages with equivalent content, the faster one has an advantage; between a slow page with the exact answer and a fast one without it, the first wins almost every time.

Where speed has a clear indirect effect is crawling: a slow server reduces how many pages get reviewed per visit, which in large catalogues delays discovery of new content. That is checked in the indexing module, submitting newly published URLs and watching how long they take to receive verified crawler visits.

What to measure once the site is already fast

If field data confirms the important pages load well, further investment in milliseconds has diminishing returns. At that point attention should move to what still blocks conversion: price clarity, visible shipping conditions, the number of steps to complete the action, and the quality of the information on the page itself.

Speed and crawling on large catalogues

On sites with thousands of URLs there is a second, less discussed effect. A slow server reduces how much gets crawled per visit, which delays discovery of new products and of updates to existing ones. In a catalogue that changes weekly, that delay translates directly into products that are live but invisible for days. The check is simple: submit a batch of newly published URLs and watch how long verified crawler visits take to arrive, before and after the server work.

A six-week work plan

Week one: map the pages that matter and run field measurement only on those. Weeks two and three: images and third-party scripts, which usually hold eighty per cent of the available improvement. Week four: visual stability and server times. Weeks five and six: measure again against the initial values and decide whether continuing is worth it.

That last step is the one almost nobody takes and the one that prevents months of sterile work: if after the obvious interventions the conversion improvement is nil, the problem was elsewhere and optimisation should stop.

How to justify investing in speed

The conversation with management usually stalls because a score is presented instead of an effect. What works is translating the problem into the pages that generate revenue: how many visits they get monthly, what share arrives on mobile, and how long the element that decides the purchase currently takes to appear.

With those three figures the proposal stops being technical. You are not asking for budget to “improve performance”, but so that the product page receiving thirty thousand monthly visits shows its price in under two seconds instead of five. The first framing competes with every other engineering request; the second gets approved.

And agree in advance how the effect will be verified: comparing behaviour on those specific pages four weeks before and four weeks after, with no other simultaneous changes. It is the only way the next budget request has a precedent.

Frequently asked questions