Speed Is the Product — Why 40ms APIs and Sub-Second Pages Are Non-Negotiable

There is a number every product team eventually memorizes, and it is not a feature count. It is 2.5 seconds — Google's Largest Contentful Paint (LCP) threshold for a "Good" rating under Core Web Vitals. Above 4 seconds, the rating flips to "Poor" and your site is, by Google's own measurement, providing a bad experience. The Cumulative Layout Shift (CLS) threshold is even tighter: anything above 0.1 is a problem, and a shift of 0.25 means your page visibly jumps while the visitor is trying to read it.

These are not arbitrary thresholds. They are the distilled result of years of measurement against real user behavior, and the research behind them is consistent and brutal in its implications.

What the Research Actually Says About Speed

The most widely cited finding on mobile load speed comes from Google's own data work: 53% of mobile site visits are abandoned if a page takes longer than three seconds to load. A separate analysis of session data showed that as page load time increases from one second to three, the bounce probability rises by 32%, and at five seconds the probability of bounce is 90% higher than at one second.

The commercial impact is just as stark. Akamai and SOASTA's "State of Online Retail Performance" study found that a 100-millisecond reduction in page load time increased retail conversion rates by up to 1%, and that a 2-second load time was the breakpoint beyond which conversions began to fall sharply. A later Deloitte study, "Milliseconds Make Millions," measured the effect across a broader retail sample and found that improving mobile site speed by just 0.1 seconds lifted conversion rates by 8.4% and average order value by 9.2% — from a tenth of a second.

A 2024 academic study (SBRG, "A Multi-Dimensional Approach to Understanding the Effect of Page Content and Infrastructure on Page Load Time") confirmed the mechanism: the number of bytes, the number of requests, and the number of distinct images are the key predictors of page load time. Every additional request a page makes — especially to a third-party service — is a potential addition to all three. A page that is fast on its own can be slow because of a single blocking dependency.

This is the context in which any third-party embedded on a customer's site must be judged: not by what it does, but by what it costs in milliseconds.

The Benchmark: Bet365 and IPrating on Core Web Vitals

Bet365 runs one of the highest-traffic gambling platforms in the world and treats performance as a competitive moat. Their site, measured at scale, lands at roughly 0.2s LCP and 0.01 CLS — essentially instant largest-content paint and a near-zero layout shift. For a platform that handles live in-play betting with sub-second odds updates, that is not a luxury; it is the cost of staying in business. Visitors who wait do not bet, they leave.

Our own site, measured the same way, lands at 0.21s LCP and 0 CLS — comparable to bet365 on paint, and stricter on layout stability. We hold CLS to exactly zero because any layout shift during the brief window when the detection probe is initializing would be both visible to the user and a Core Web Vitals penalty. A perfect zero is achievable; anything above it is a choice to accept a problem.

Both numbers sit deep inside Google's "Good" band (under 2.5s LCP, under 0.1 CLS) by an order of magnitude. Both websites use IPrating's API live for all visitors to track context and make decisions when loading the page. The point is not to compare for its own sake. The point is that a platform that detects and classifies every visitor before they meaningfully interact with the page must finish its work in a fraction of the time the page takes to paint — or it stops being invisible and starts being the problem.

Why Our APIs Run Under 40 Milliseconds

Every request a customer's site makes to IPrating happens before or during page load. The main API returns the decision the customer acts on, and the classification probe that powers the richer browser-context path is resolved while the page is still rendering. Both paths are designed to finish their work before the page paints. The API itself completes its processing in under 5 milliseconds. The classification, the fingerprint lookups, the signing, the response assembly: all of it fits inside a five-millisecond window on the server. Everything beyond that 5ms is network time — the round trip to the nearest API node and back to the visitor's browser — and network time is the same latency the visitor already experiences for every other request to your infrastructure. We do not add a premium on top of it; we sit inside it.

For most visitors, the total time including network is under 40 milliseconds. That 40ms figure is what our analytics dashboard reports from real production traffic, measured honestly — every request carries a response time, and the system tracks the sum and count to compute an average rather than a cherry-picked best case. Our API monitor probes every node every second to confirm latency stays within band.

Why 40ms as the total budget, and not "as fast as possible"? Because the budget math is unforgiving. A page that targets a 0.21s LCP has roughly 210ms of total headroom before content paints, and our full contribution — 5ms of compute plus the network the visitor was going to pay anyway — is less than a fifth of that budget. At 100ms total we are approaching half. At 250ms, the API has consumed the entire LCP budget and the page is now slower because of us.

The research says every 100ms costs roughly 1% of conversion. An API whose own compute is 5ms, and whose total with network is under 40ms, costs a fraction of that — and costs nothing on the critical path when the probe is non-blocking, which it is. An API that adds 250ms costs closer to 2.5% of conversion, on every visitor, on every page. The difference between 40ms and 250ms is, for a site doing meaningful volume, the difference between a feature that pays for itself and a feature that quietly taxes every customer.

Speed Is the Product

A detection platform that slows down the sites it protects has failed before its first classification. The promise of real-time visitor context only holds if the "real-time" part is honest — if the classification finishes faster than the page paints, and if the cost of asking is small enough that no one notices it was asked. bet365 builds for 0.2s because their customers will not wait. We build for 0.21s and 40ms APIs for the same reason, and because the research is clear that the cost of not doing so is paid in conversion, not in milliseconds.

Sources

• Google. Find Out How You Stack Up to New Industry Benchmarks for Page Load Speed. (53% mobile abandonment at 3 seconds; bounce probability data.)
• Akamai & SOASTA. State of Online Retail Performance, 2017. (100ms = up to 1% conversion lift; 2-second breakpoint.)
• Deloitte. Milliseconds Make Millions, 2020. (0.1s mobile speed improvement = 8.4% conversion lift, 9.2% AOV lift.)
• web.dev / Google Chrome. Core Web Vitals. (LCP "Good" under 2.5s, "Poor" over 4s; CLS "Good" under 0.1, "Poor" over 0.25.)
• SBRG (2024). A Multi-Dimensional Approach to Understanding the Effect of Page Content and Infrastructure on Page Load Time. (Bytes, requests, and images as key PLT predictors.)