How We Calculate
Revenue Loss from Slow Hosting

What is TTFB and why does it matter?

Time to First Byte (TTFB) is the elapsed time between a browser sending an HTTP request and receiving the first byte of the server's response. It's the most direct measure of hosting infrastructure performance — before any page content, CSS, images, or JavaScript is involved.

TTFB is determined almost entirely by three things: server hardware speed, server software configuration, and geographic distance between the server and the visitor. A slow TTFB cannot be fixed by frontend optimization alone — it requires infrastructure changes.

Google's Core Web Vitals threshold

Google's Largest Contentful Paint (LCP) — a Core Web Vitals metric used in search rankings — cannot score "Good" if TTFB is above approximately 800ms. This creates a direct link between TTFB, search ranking, and organic traffic volume. Our model treats TTFB as the upstream cause of both conversion loss and SEO visibility loss.

The revenue impact model

Our model calculates revenue loss through two parallel pathways that operate simultaneously when a site is slow: direct conversion loss (fewer visitors complete a purchase) and ad spend waste (paid traffic bounces before converting).

Both pathways start from TTFB, estimate its effect on user behavior using published research rates, and apply that behavioral change to the site's revenue figures.

Pathway 1: Conversion loss

Slower page loads produce measurably lower conversion rates. We estimate load time from TTFB, then apply a per-second conversion penalty. This gives a revised conversion rate, which we multiply against traffic and average order value to calculate monthly revenue loss.

Pathway 2: Ad spend waste

If you're running paid traffic, bounce rate directly determines how much of your ad spend produces zero return. Slow hosting increases bounce rate; we calculate the fraction of ad spend effectively wasted as a result.

Formulas, step by step

Step 1 — Estimate total page load time

TTFB is a component of total load time. We estimate total load using a baseline of 1.5 seconds for the non-server portion (HTML parse, resource load, render), which is the median for sites measured by HTTP Archive.

// Estimated total load time from TTFB
loadTime = (ttfb / 1000) + 1.5

// Example: TTFB of 800ms
// loadTime = 0.8 + 1.5 = 2.3 seconds

Step 2 — Calculate conversion drop

Based on Portent (2019), Deloitte (2020), and Google/SOASTA research: each additional second of TTFB above the 200ms baseline produces between ~3% and ~10% conversion impact depending on vertical. Portent observed a consistent 4–7% relative drop per second; we apply the bottom of that range — 4% per second (0.4% per 100ms) — because it is the most defensible conservative value. We cap this at 40% maximum drop. The 0.04 coefficient below is the same value used in production code — nothing is hidden.

// Conversion penalty applied per excess second of load time
excessSeconds = (ttfb - 200) / 1000   // only count TTFB above the 200ms baseline
conversionDrop = excessSeconds × 0.04         // 4% per excess second = 0.4% per 100ms
conversionDrop = min(conversionDrop, 0.40)    // capped at 40%

// Example: TTFB of 1,200ms
// excessSeconds = (1200 - 200) / 1000 = 1.0
// conversionDrop = 1.0 × 0.04 = 4%

Step 3 — Calculate monthly revenue loss

// Monthly traffic and baseline revenue
monthlyTraffic  = dailyVisitors × 30
baselineRevenue = monthlyTraffic × (conversionRate / 100) × avgOrderValue

// Apply the conversion drop
monthlyLoss = baselineRevenue × conversionDrop
annualLoss  = monthlyLoss × 12

Step 4 — Calculate bounce rate increase (ad waste)

Based on Google's research on bounce rate vs load time: each 100ms of TTFB above 200ms increases bounce rate by approximately 1 percentage point. We cap this at 35%.

// Bounce rate increase from excess TTFB above 200ms threshold
excessMs        = max(0, ttfb - 200)
bounceIncrease  = (excessMs / 100) × 0.01   // 1 percentage point per 100ms excess,
                                             per Google mobile speed study (2018)
bounceIncrease  = min(bounceIncrease, 0.35)  // 35% max

// Monthly ad waste (if ad spend provided)
monthlyAdWaste  = monthlyAdSpend × bounceIncrease

Step 5 — Total loss and recovery projection

// Total monthly and annual cost of slow hosting
totalMonthlyLoss = monthlyRevenueLoss + monthlyAdWaste
totalAnnualLoss  = totalMonthlyLoss × 12

// Recovery projection (switching to fast hosting)
// Baseline uses InterServer's verified 3-sample avg TTFB of 162ms
optimalLoadTime  = (0.162) + 1.5 = 1.662s
recoveredRevenue = currentLoss - lossAtOptimalTTFB

Performance tier thresholds

We classify TTFB into five tiers. Thresholds are aligned with Google's Core Web Vitals documentation and Cloudflare's performance guidelines, adjusted slightly for practical impact significance.

Assumptions and their basis

Every model requires assumptions. We've tried to make ours explicit, conservative, and traceable to published sources.

• Load time baseline Non-server load time estimated at 1.5 seconds. Source: HTTP Archive median render time for CMS-based sites (2024). This is a median estimate — optimized sites may be lower, image-heavy sites higher.
• Conv. penalty rate A conservative lower-bound conversion sensitivity coefficient of 0.04 (4%) per additional second of TTFB above the 200ms baseline — equal to 0.4% per 100ms. Derived from Portent (2019) and corroborated by Deloitte/Google (2020). We apply the bottom of Portent's observed 4–7% per-second range to keep estimates defensible; the wider literature (Deloitte, Akamai, Google/SOASTA) spans roughly 3–10% per second depending on vertical, and our 4% sits at its low end. This exact coefficient (0.04) is what our production code applies.
• Bounce rate A conservative bounce sensitivity coefficient of 0.01 (1 percentage point) per 100ms of TTFB above 200ms, derived from Google's mobile speed study (2018). Capped at 35% to avoid unrealistic extrapolation for extremely slow sites. Production code applies this exact coefficient.
• Max conv. drop Capped at 40% total conversion drop regardless of TTFB. Rationale: users with high purchase intent will wait longer; some conversions persist even on slow sites.
• Optimal TTFB Recovery projections assume a target TTFB of 162ms — InterServer's verified 3-run average from our January–August 2026 benchmark set. This is our affiliate partner's measured baseline. We use it for recovery calculations and flag this conflict of interest explicitly.
• Traffic uniformity We assume consistent daily traffic. Seasonal spikes would amplify revenue loss during peak periods — our annual estimate may undercount for retail businesses with holiday traffic.

Limitations of this model

This calculator produces estimates, not audited revenue figures. Several real-world factors can make actual impact higher or lower than our numbers suggest.

Single measurement point

Our TTFB measurement is taken once, from a single server location. TTFB varies significantly by visitor geography, time of day, and server load. A site measured at 400ms may hit 900ms during peak traffic. We recommend running several tests at different times and using the average.

No CMS or page-type context

A homepage, a product page, and a checkout page have different conversion weights. We apply the conversion model uniformly. A slow checkout page causes disproportionately more revenue damage than a slow blog post — our model does not distinguish between them.

Industry variation

The research underlying our conversion penalty rates is drawn primarily from ecommerce studies. SaaS, lead-generation, and media sites have different conversion dynamics. Our figures are most accurate for ecommerce and least accurate for content-based sites.

What we don't model

We do not model: SEO traffic loss from poor Core Web Vitals scores (this adds to the actual loss), mobile vs desktop split (mobile users are more sensitive to latency), or returning vs new visitor behaviour (returning users tolerate more latency).

Data sources