Speed Is Money: How Core Web Vitals Drive Revenue
Author: WebGoodPeople
Amazon found that every 100 ms of latency costs 1% of revenue. For a store turning over 500M rubles a year, that's 5M rubles per 100 ms. If your TTFB is 700 ms instead of 100 ms, you're handing competitors 30M rubles a year. And that's only the direct loss from speed, before you count SEO and behavioral factors.
Core Web Vitals in 2026: what Google measures
Google uses three metrics to judge the user experience on a page:
LCP (Largest Contentful Paint) is the time to render the largest visible element. For a catalog that's usually a product image or a category heading. Good: under 2.5 s. Bad: over 4.0 s.
INP (Interaction to Next Paint) is the time from a user action (click, tap, input) to a visual response. It replaced FID in 2024 and got far stricter: it measures every interaction in a session, not just the first input, and takes the worst case. Good: under 200 ms. Bad: over 500 ms.
CLS (Cumulative Layout Shift) is the total shift of elements on the page during load. When a banner jumps down because a slider above it loaded late, that's CLS. Good: under 0.1. Bad: over 0.25.
These metrics are not recommendations. Since 2024 they are a ranking factor in Google search. Sites with poor CWV take a hit in position, especially on mobile, where the fight for the first page is hardest.
The state of enterprise Bitrix sites
We audited more than 40 enterprise stores on 1C-Bitrix over the past year. The typical picture:
- TTFB: 600-900 ms. The server generates a PHP template, runs 30-80 MySQL queries, assembles the page, and only then sends the first byte to the client.
- LCP: 3.0-4.0 s. After the HTML arrives, the browser still loads CSS, JS, fonts, and images. The largest element shows up after 3-4 seconds.
- INP: 220-350 ms. Heavy JavaScript (jQuery plus custom plugins plus analytics) blocks the main thread. Click a filter and you wait a quarter second for a visual response.
- CLS: 0.15-0.30. Banners, lazy loading without dimensions, dynamically injected blocks: all of it shifts the content.
By Google's classification that's "needs improvement" at best and "poor" in most cases. On mobile the numbers are worse: TTFB is the same, but LCP climbs on slow networks and INP grows on weaker processors.
Three ways speed drives revenue
Site speed affects money through three mechanisms, not one, and they reinforce each other.
Channel 1: Search ranking
Google uses CWV as a ranking factor directly. A site with LCP 1.8 s has an edge over a site with LCP 3.5 s, all else equal. In competitive niches (electronics, apparel, appliances) that can be the difference between the first and second page of results. And on page two of Google, conversion is effectively zero: 0.63% of clicks versus 27.6% for the top position on page one.
Channel 2: Bounce rate
Per Google, when load time rises from 1 s to 3 s the probability of a bounce goes up 32%. From 1 s to 5 s, it goes up 90%. Every visitor who leaves before the page loads is a lost conversion you already paid for, through ads, SEO, or content.
On mobile the effect is stronger: 53% of mobile users abandon a site if loading takes more than 3 seconds.
Channel 3: Conversion
Deloitte ran a study for retailers: a 0.1 s improvement in load speed lifts conversion by 8.4% for retail and 10.1% for the travel segment. This isn't theory, it's measured on real traffic.
Walmart found that every second of load-speed improvement raised conversion by 2%.
What headless delivers: real numbers
Here are production metrics from real projects where we moved the frontend of Bitrix stores to Next.js:
| Metric | Bitrix (before) | Next.js (after) | Improvement |
|---|---|---|---|
| TTFB | 600-900 ms | 90-150 ms | 6x |
| LCP | 3.0-4.0 s | 1.7-2.2 s | 2x |
| INP | 220-350 ms | 80-140 ms | 2.5x |
| CLS | 0.15-0.30 | 0.02-0.05 | 5x |
These aren't lab tests. This is data from the Chrome User Experience Report (CrUX) and real production monitoring.
Why the gap? Next.js fundamentally changes how content is delivered:
- SSR/SSG plus CDN: pages are generated on Edge servers or statically, so TTFB drops to a minimum.
- Automatic code splitting: the browser loads only the JavaScript for the current page, not the whole bundle.
- Image optimization: Next.js Image picks the format (WebP/AVIF), size, and quality automatically.
- Streaming SSR: HTML is sent in chunks, so LCP doesn't wait for the full page to generate.
- React Server Components: some components render on the server, which lowers the load on the client and improves INP.
Quick wins vs. architectural change
Some optimizations you can do right now, without changing the architecture:
- Image compression (WebP, lazy loading): LCP down 15-30%
- Deferred loading of non-critical JS: INP up 10-20%
- Setting dimensions for images and iframes: lower CLS
- HTTP/2, Brotli compression: TTFB down 10-15%
These help, but they don't fix the underlying problem. The server still generates the page in 600+ ms. The JavaScript bundle still weighs 400-800 KB. The monolith's architecture still sets the limits.
For a real breakthrough in speed you have to separate the frontend from the monolith. That's the only way to get a 6x faster TTFB and a 2x better LCP.
The compounding effect
6x faster TTFB plus 2x faster LCP plus 2.5x better INP isn't just "faster." It's a cascade:
- Google sees better CWV and raises your positions
- Higher positions bring more traffic
- A faster site means fewer bounces
- Fewer bounces mean more sessions deeper than one page
- Better INP means an instant response to actions, so more catalog interaction
- More interaction means higher conversion
- Every point of conversion grows revenue
The effect builds and compounds over time. Three to six months after moving to headless, stores see organic traffic grow 15-40%, not from new content but from better technical positions.
Next step
Start with a free CWV audit. We'll measure your site's current performance across every metric, show where you're losing positions and conversion, and put a number on the potential of moving to headless.