Site Speed: How to Make It Faster and Why Sales Depend on It

Site speed is one of the rare cases where a technical metric converts straight into money. On an auto parts store project we cut the time to render the main content from 4.8 to 1.9 seconds. Conversion to add-to-cart rose from 3.1% to 4.4% — at the same traffic that meant roughly 380 thousand roubles of extra revenue per month.

What exactly to measure

Forget the "overall score" on the green scale — it aggregates far too much. Look at three numbers: LCP (when the main element of the screen is painted), INP (the delay before a click gets a response) and CLS (how much the layout jumps). Thresholds and the measurement methodology are described in detail on web.dev. A breakdown of each metric and the ways to fix it is in the separate piece on Core Web Vitals.

Lab data lies, field data does not

A PageSpeed test runs on an emulated mid-range Android with a slow connection, while your marketer views the site from a MacBook on fast office Wi-Fi. Trust the field: Yandex.Metrica has a load time report broken down by device, and Search Console has a Core Web Vitals report based on real users. If the 75th percentile of mobile LCP is above 2.5 seconds, there is work to do.

Seven causes of a slow site, by frequency

• Unoptimized images: a 2.4 MB JPEG in a first-screen slider
• Blocking JavaScript from third-party services — chats, widgets, three analytics systems at once
• No server-side caching: every page is assembled from scratch on every visit
• Fonts that load before the text and leave a white screen for 1.5 seconds
• A heavy CMS theme with twenty plugins, three of which are actually used
• Database queries without indexes — on a 5,000-product catalog that adds 600–900 ms
• Hosting for 200 roubles a month, where you share a CPU with four hundred neighbors

What pays off fastest

In our experience 70% of the gain comes from three things: converting images to WebP or AVIF with explicit width/height, lazy loading everything below the first screen, and deferring third-party scripts. That is a week of front-end work and usually −40–55% off load time. The technical details of the loading and decoding attributes are well covered in the MDN documentation.

When speeding up is pointless

If the site is built on a closed-source website builder, or on a theme whose layout is assembled from nested tables, optimization hits a ceiling about halfway. We tell clients honestly: we will get LCP down to 3.2 seconds, and beyond that the only option is rewriting the front end. Sometimes building a new site on a modern stack is cheaper than patching the old one for six months — how that looks in terms of timelines and budget is shown in the web development section.

Speed and money: how to estimate the effect in advance

Take your current conversion rate, monthly traffic and average order value. A conservative estimate based on accumulated research: every −100 ms of LCP gives a +0.5–1% relative conversion gain in the range from 1 to 4 seconds. At 20,000 visits, 2% conversion and a 6,000 rouble order value, shaving off a second is roughly +60–100 thousand roubles a month. The figures are worth verifying on your own project with an A/B test, but the order of magnitude usually holds.

The order of work

• Take baseline metrics from the field rather than the lab, and record the date
• Find the three heaviest resources on the home page and on a product page
• Fix images and fonts — the cheapest part of the job
• Defer third-party scripts and keep only the ones actually in use
• Turn on server-side caching and HTTP caching for static files
• Repeat the measurement two weeks later and compare conversion over comparable periods

If the site is already in production and you are afraid to touch it, start by observing: a week of collecting metrics costs zero roubles and removes half the hypotheses. After that you can discuss the scope of work — we take on this kind of task as part of technical support too.