900 ms TTFB: What It Really Costs Per Month

Author: WebGoodPeople

You run a 50,000-SKU catalog, your TTFB is 900 ms, and once a week your team tells you "we should speed this up." This article shows exactly what that costs, in rubles per month, and which fixes pay back in how many weeks.

Baseline numbers (plug in your own)

Take a typical enterprise e-commerce segment:

  • 500,000 sessions/mo
  • 1.2% average conversion
  • 4,500 ₽ average order value
  • Catalog TTFB: 900 ms
  • Target TTFB: 400 ms (reachable with Next.js + ISR + CDN)

Baseline monthly revenue: 500,000 × 1.2% × 4,500 = 27,000,000 ₽/mo.

What each 100 milliseconds costs

Amazon's "100 ms = 1% of sales" rule was stated in 2006. Dozens of studies have tested it since. Exact figures vary by market and audience, but the range is stable:

  • Consumer retail: 0.8–1.2% conversion per 100 ms
  • B2B e-commerce: 0.5–0.8% (less sensitive, but not immune)
  • Fashion/premium: 1.0–1.5% (higher, because the audience is more impatient)
  • Mobile: 1.5–2× more sensitive than desktop

Let's stay conservative and use 0.8% conversion per 100 ms for mid-market e-commerce.

Cutting TTFB from 900 ms to 400 ms (a 500 ms gain) lifts conversion by +4%.

Extra monthly revenue: 27,000,000 × 4% = 1,080,000 ₽/mo.

Annual: 12.96M ₽.

What this means by category

E-commerce with a 50k+ SKU catalog

On catalogs this size, TTFB is also unbalanced: the homepage is fast, but category and filter pages are slow. The user behaves predictably: lands on the homepage, clicks a category, sees 900 ms of white screen, and some of them leave.

A separate calculation: the share of traffic going through category pages is usually 60–75%. If we apply the 4% gain only to that part:

  • 27M × 65% (share through category pages) × 4% = 702,000 ₽/mo

That's if we fix only the category pages and leave checkout and the homepage alone. A minimum pilot target.

B2B portals with catalogs and search

B2B conversion is lower (0.3–0.7%), but the average order is 5–20× higher. The math is similar, but it's more accurate to model it from:

  • RFQs/requests per month
  • Average cycle from session to deal
  • LTV of a closed customer

A typical estimate: a 500 ms TTFB gain = 3–5% growth in RFQs/mo. With a cycle of "50 RFQs/mo → 5 deals → 200k ₽ per deal," that's 3 extra deals per quarter = 600k ₽/quarter = 200k ₽/mo.

Content + programmatic pages

Sites with a large pool of SEO pages (catalogs, guides, comparisons). TTFB affects Core Web Vitals → Google ranking → organic traffic.

The link here isn't linear, but it's observable: sites that improve LCP from 4.0+ to under 2.5 see +10–20% organic traffic within 3–6 months. At 0.5% conversion and a 3,000 ₽ average order on 1M sessions/mo, that's 300–600k ₽/mo in extra revenue.

Fix options and their payback

Not all fixes are equal. Here are four options, from cheapest to most serious.

Option 1. Page caching via Varnish / nginx

Cost: 2–3 weeks of DevOps work. 300–600k ₽.

Gain: TTFB from 900 ms to 600 ms for ~60% of requests (cache hits). Conversion effect: ~1.5%.

Payback: 27M × 1.5% = 405k ₽/mo. Pays back in 1.5 months.

Limit: doesn't solve dynamic pages (cart, account). The cache invalidates on every catalog update.

Option 2. Move static assets to a CDN + edge rendering

Cost: 4–6 weeks of work. 800k–1.2M ₽.

Gain: TTFB from 900 ms to 300 ms for 70% of pages (everything except user-specific ones). Conversion effect: ~3.5%.

Payback: 945k ₽/mo. Pays back in 1–1.5 months.

Limit: requires a clean split between static and dynamic. On a monolithic Bitrix, that can be hard.

Option 3. Headless Next.js with ISR + partial migration

Cost: a 2-week pilot + 3–4 months of staged rollout. Pilot 800k–1.5M ₽, staged up to 6–10M ₽.

Gain: TTFB 150–300 ms on all public pages. Conversion effect: 5–7%.

Payback: 1.35–1.89M ₽/mo. Pays back in 4–6 months.

Limit: needs investment in the pipeline and team training. But the gain isn't only TTFB. It shows up across every other developer-velocity metric too.

Option 4. Full replatforming to a new CMS

Cost: 12–18 months. 20–40M ₽.

Gain: variable. Often the same as Option 3, but without the guarantee and at 4–5× the risk.

Payback: often none within an acceptable horizon. Plus a 40–60% chance of blowing the timeline.

Compared to Option 3, it's almost always worse on risk-adjusted return.

How to choose an option

Rule of thumb:

  • TTFB 700–1000 ms, catalog up to 20k SKU → Option 1 is often enough
  • TTFB 800+ ms, catalog 20–100k SKU → Option 2 or 3
  • TTFB 1000+ ms, catalog 100k+ SKU, fast growth, omni-channel → Option 3
  • You want it "like Amazon" → Option 3 (not Option 4)

48-hour CWV audit: what we hand back

If you want exact numbers for your own stack rather than a generic model, we run a free 48-hour audit. You get:

  1. Current TTFB across your top 20 page types (not just one).
  2. A shadow-revenue calculation on your real data (sessions, conversion, order value, which we request).
  3. A table of the four fix options with hours / ₽ / expected gain estimated for your stack.
  4. A recommended first step, usually a fixed-price 2-week pilot.

The audit commits you to nothing. If we see you don't need a migration, we'll say so.


Headless Next.js + Elasticsearch

900 ms TTFB: What It Really Costs Per Month — WebGoodPeople