A Slow Site Loses Money: Core Web Vitals and Conversion

Money first: what every extra second costs

Two figures have circulated through the industry for years and underpin most speed discussions: a one-second delay cuts conversion by roughly 7%, and 53% of mobile users abandon a page that takes more than three seconds to load. These are industry figures rather than our own measurements, and they should be read as an order of magnitude rather than a constant for your specific site.

That order of magnitude converts easily into your own number. Take monthly revenue from organic and paid traffic, look at the mobile share of visits and the current mobile load time. If you are at four seconds instead of 2.5 with 70% mobile traffic, you already know what share of revenue is in play. That is how a speed conversation stops being technical and becomes a budget conversation.

It matters where exactly the money leaks. A slow homepage usually costs less than a slow product page or checkout: homepage visitors often already know the brand, while product pages receive paid traffic you have already paid for. So optimisation starts not where the scores are worst, but where the combination of traffic, revenue and poor scores produces the largest loss.

LCP, INP and CLS as the user experiences them

LCP answers "when did I see the thing I came for". It marks the render of the largest element in the viewport, usually the hero image, the headline or a video. Good is under 2.5 seconds, poor is above 4. This is the metric users experience as "the site is loading": until LCP happens, the person stares at empty space or a placeholder and decides whether to keep waiting.

INP answers "does the site respond when I tap". It measures the delay between a user action and a visible interface response across the whole visit. Good is under 200 ms, poor is above 500. This is the "I tapped and nothing happened, let me tap again" feeling that produces duplicate orders and convinces people the site is broken. INP replaced the older first input delay metric and judges pages more strictly.

CLS answers "does the page jump under my finger". It captures unexpected layout shifts: an image loading without reserved dimensions, an ad block appearing, a font arriving and reflowing the text. Good is under 0.1. The practical cost of poor CLS is higher than it looks: people tap the wrong button and land where they did not intend, which hits form and cart conversion directly.

One detail about search engines is frequently confused. Google has used Core Web Vitals as a ranking factor since 2021, so the influence is direct and stated. Yandex does not declare a separate speed metric in ranking but accounts for it indirectly through behavioural signals: a slow page produces bounces and short sessions, which are direct quality signals. The outcome for a site owner is the same, only the mechanism differs.

Lab data versus field data: why 98 out of 100 means nothing

There are two fundamentally different kinds of measurement, and swapping one for the other is the most common cause of wasted work. Lab data is a synthetic page run under controlled conditions: fixed network speed, a specific device, a clean cache. It is useful for debugging because it is reproducible. Field data is real measurement from real users on their devices and their connections.

Hence the classic situation: a PageSpeed Insights report shows 98 points while the real-user data block is red. The score is a lab result from one run on a notional device, the red block is what actually happens to your audience. Field data always takes priority: it is collected from real browsers and reflects the devices, networks and geography of your specific users.

For Russian traffic, Yandex Metrica belongs in that set. It reports load time broken down by device, region and source, and its session replay shows what a visit looks like end to end, including the moments when somebody taps an unresponsive button several times. The combination of browser field data, Metrica and a lab run for debugging gives the full picture and stops you optimising an imaginary problem.

• Field data comes first: it is your real audience, not a test device.
• Lab runs are for debugging and before-and-after comparison, not for reporting.
• Look at mobile and desktop separately, an averaged number hides the problem.
• Metrica reports speed by region, which is often the key breakdown in Russia.

Diagnosis: finding the real cause

Start with the network waterfall in browser developer tools, with network and CPU throttling switched on. The waterfall shows the request sequence and what is waiting on what. Look for three things: a long bar before the first byte, which points at a slow server; long chains where one resource waits for another; and large files loading ahead of what the user actually sees.

Next, find the LCP element itself, which the tools highlight directly on the page. What you do next depends on what it is. If it is an image, the questions are weight, format, dimensions and whether it carries a lazy-loading attribute it should not have. If it is a text block, a render-blocking font is almost certainly the culprit. If the element appears only after a script runs, the content is client-rendered and waiting on JavaScript.

Render-blocking resources are easy to identify: any stylesheet or script loaded in the head without deferring attributes delays first paint. Check third-party connections separately, meaning analytics counters, the support chat, ad pixels and callback widgets. In practice these routinely account for half the load time, they are usually added by marketing rather than engineering, and nobody reviews the list for years.

For INP the order differs: open the performance profiler and interact with the interface the way a user would. Look for long tasks on the main thread, stretches where the browser is busy for more than 50 ms and cannot respond to a tap. The culprits are standard: heavy event handlers, re-rendering large lists, synchronous work on keystrokes, and the same third-party scripts executing at the worst possible moment.

What to fix first: a list ranked by return per hour

Images give the highest return almost every time. Modern formats such as WebP and AVIF weigh 25-50% less at the same quality, and correct dimensions per screen save more still: serving a 2,000-pixel-wide image to a 390-pixel phone is the most common and most expensive mistake there is. One separate rule: the hero image above the fold is never lazy-loaded, and everything below the fold always is.

Third-party scripts are second on return and first on being underestimated. Analytics, chats, pixels, social widgets and callback tools together can cost whole seconds. The work has two steps: an audit to establish what is actually used and by whom, then deferring everything not needed in the first second. A support chat that initialises three seconds after load has never lost a single conversation and gives a full second back to LCP.

Fonts and critical CSS deliver a visible effect for modest effort. Loading a font without specifying display behaviour means text is either invisible or repainted with a shift. Limit the number of weights, use modern formats, set the display behaviour and preload what the first screen needs. Critical CSS, meaning the above-the-fold styles inlined into the page, removes render blocking at the start.

The server layer, caching and a CDN close out the list. Time to first byte above 600 ms means front-end work is pointless until the server is addressed: heavy database queries, no page caching, weak hosting. A CDN matters for an audience spread across a country, where the gap between one city and another served from a single origin is measured in hundreds of milliseconds, a pure loss that configuration fixes.

What you can actually fix on your platform

On Tilda and similar builders you can compress images, reduce block count, drop background video and remove surplus embedded scripts. You cannot control critical CSS, fine-grained resource loading order or the final HTML structure. The practical ceiling is usually this: moving from poor scores to acceptable ones is achievable, moving to excellent ones is not. If speed is critical to your traffic, that is an argument for changing platform rather than optimising forever.

On WordPress almost everything is fixable, and the main job is auditing existing plugins rather than adding a caching one. A typical site carries thirty plugins, each loading its own styles and scripts on every page including the ones where it is not used. Disabling half the unused plugins usually beats any amount of cache tuning. After that comes page caching, on-the-fly image optimisation, script deferral and a CDN where needed.

Bitrix has a built-in composite mode and its own caching mechanisms that deliver solid results when configured properly. The main problems usually sit elsewhere: heavy database queries inside component templates, unoptimised catalogue images and years of accumulated library includes. Here it is most effective to start by profiling the server side rather than the front end.

On Next.js and similar stacks the ceiling is highest: server rendering, automatic image optimisation, route-level code splitting, static generation for pages that rarely change. Poor speed here is almost always a consequence of specific code decisions: excessive client components, heavy libraries in the shared bundle, no request caching. All of it is fixable, and fixable predictably.

Which pages to start with: not the homepage

The instinct is to start with the homepage, and it is almost always the wrong priority. Take the landing page report, sort by traffic and by revenue contribution, overlay the speed data, and you get a list whose first three or four rows deliver more than a month of sitewide work. Usually those are product pages, service pages receiving paid traffic, and catalogue search results.

The second filter is template type. On most sites ten thousand pages are generated from five or seven templates, so fixing one product page template improves thousands of pages at once. That is an important difference from, say, content work: here the effort scales automatically, and a well chosen point of intervention lifts an entire section.

Finally, record the state before and after. Speed degrades on its own: marketing adds a pixel, an editor uploads an uncompressed image, a developer pulls in a library for one function. Without regular checks a site returns to its original numbers within months. The practical minimum is a monthly review of field data for the key templates, plus a rule that no new third-party script gets added without a justification.

Frequently asked questions

Related services

• Website support and improvementNot every project needs a rewrite. It is often cheaper to fix the speed, clear the technical SEO errors, add the missing sections and integrations, and end up with a working site without paying for a new build.
• Website development, end to endWe build sites that still hold up a year later: from a one-page CMS build to a store or a web application on React and Next.js. One team for design, code, integrations and launch.
• SEO and GEO website promotionSearch traffic is the one acquisition channel that keeps working after the ad budget stops. We run two tracks in parallel: classic SEO for Yandex and Google, and GEO, the work of getting your pages quoted inside AI Overviews, Yandex Neuro, ChatGPT and Perplexity, where a growing share of queries now ends. It starts with an audit, never with buying links.

Read next

• What to Build Your Site On in 2026: Tilda, WordPress, Bitrix or Next.jsBuilder, CMS or custom code is not a matter of taste but of scenario and planning horizon. We break down three-year cost of ownership, the ceiling of each platform, and what it costs to move if you picked wrong.
• SEO in Yandex in 2026: what changed and what no longer worksLink buying is dead weight, templated copy pushes pages into the low-value bucket, and behaviour manipulation is no longer a grey tactic but a way to lose the site. Here is what actually drives Yandex rankings in 2026.
• Redesigning a Site Without Losing Traffic: Stages, Risks and the SEO Migration ChecklistHalf of all redesign requests are really content, speed or offer problems. How to tell them apart, why a phased rollout beats a big bang launch, and what belongs in the migration checklist so the organic traffic survives.