TTFB, LCP, and INP are different numbers and are treated differently. Our external measurements of live sites 31/07-01/08/2026, reasons for lost seconds and commands to repeat the test yourself.
The client writes: "the site slows down." You open it from a work laptop — it seems normal. You open it from the phone on the road - it really slows you down. The word "slow" means nothing until there is a number under it and the place where the number was taken.
Below is how we measure speed, what our measurements showed on 07/31–08/01/2026 on live sites, and which of these tests you can do yourself, without our participation and without paid services.
Most often, things that are treated differently are thrown into one pile.
TTFB (time to first byte) — how much time passes from the request to the first byte of the server's response. Pure server part: PHP version, cache, database requests, nginx settings. Google's web.dev documentation does not list TTFB as a Core Web Vitals, but describes it as a diagnostic metric that supports LCP, and calls the benchmark "good" at up to 800ms.
LCP (largest contentful paint) — the moment when the largest element of the first screen appeared on the screen. The official "good" threshold from the same documentation is 2.5 seconds. This already includes the server, the network, and the weight of the images.
INP (interaction to next paint) — the delay between the user's action and the interface's reaction, the "good" threshold is 200 ms. It's not about loading anymore, but about whether the scripts after it slow down the page.
A site can have a great TTFB and a failed LCP if the first screen has a two megabyte banner. The opposite also happens: the server thinks for a second, but the page is light, and the person hardly notices it. Therefore, the first practical question is what exactly is your bad number.
The mechanism here is straightforward and boring. Between the click and the appearance of the content, a person does not see anything. The longer the pause, the greater the proportion of visitors who close the tab — especially from the mobile Internet, where network latency is added to server latency. Whoever went to the first screen saw no product, no price, no button. He cannot be converted by any offer, discount or text, because he has not physically read anything.
Speed determines how many people your offer will be shown to at all.
And immediately the limit, so that there are no illusions. Speed doesn't make an offer attractive. If the price is higher than the market, the product is not available or the person came for the wrong thing - a site that loads in 200 ms will simply give them a reason to leave faster. Speed removes technical loss, it does not create demand. Exactly how much this will affect your sales depends on the niche, the competition, and how bad it is right now.
We took external metrics from live sites we ran or are running: a batch of sixteen sites, measured 07/31–08/01/2026, from an external network, without access to servers. The lightest to heaviest comparisons below apply to this lot. There are no customer names here - only the type of business.
Tactical Gear Store: TTFB 413.8ms, full HTML load 511.1ms. Catalog — 54,302 products confirmed by two independent methods: sitemap-index on 110,096 URLs for two languages and cross-validation by standard search, discrepancy 0.4%. The weight of the main HTML is 421.5 KB.
Your opinion helps us create better content
Help others learn about it - share the article on social networks
Thank you for helping us grow
Writes about what he builds himself: online stores on OpenCart, applications on Next.js, integrations and site speed. The articles carry measurements and checks a reader can repeat on their own project, not general advice. Commercial development since 2015.
Answers to common questions on the topic
Both, because they describe different things. TTFB is the time to the first byte, meaning how long the server thinks; LCP is when the visitor sees the main element of the screen. A slow TTFB spoils everything that follows, but a fast one does not guarantee a fast page: heavy images and scripts can ruin LCP on a flawless server. So look at the pair, not at whichever number is more convenient.
Because it is not one measurement method but two. The lab test re-simulates a slow device and network on every run, and a spread of a few points there is normal. Field data, by contrast, is collected from real visitors over 28 days and barely moves. Only identical measurements can be compared with each other — otherwise "it got worse" may mean only that the test ran at a different moment.
It affects whether a person reaches the action at all — and that is visible in the share of those who leave before the page loads. Turning this into a promised percentage of sales growth would be dishonest: once the page has loaded, price, range and the work of your sales team decide the rest. We are answerable for measured milliseconds, shown before and after, not for a revenue figure.
Most often not code optimisation but two simple things: images served at their real size in a modern format, and the removal of third-party scripts nobody uses any more. Server response time comes next. In our own measurements a store with 54,302 products returns the first byte in 414 ms, and a site with 164 pages in 244 ms — that is the result of engineering a specific project, not of one universal fix.
Only if the starting numbers were recorded beforehand — on the same pages, by the same method, on the same class of device. Without that, any "it feels faster" is unverifiable. Field data does not update instantly: a meaningful picture forms over several weeks, and drawing conclusions earlier is premature.
Subscribe to our newsletter and receive useful tips, insights and news about web development, marketing and business.
Site performanceOn 5 September 2026 we took our own site's response apart line by line and found five things that shipped to every visitor's browser although nobody used them. On 13 September a sixth turned up. Here are the bytes before and after, a lesson about characters versus bytes, and five checks for your own site.
Site performanceOn 16 August 2026 our site responded in 3.05 s, while neighbors on the same server responded in 0.2–0.3 s. The culprit was a mega menu query that pulled 4.3 MB of translations on every page. We break it down along with three similar cases, and show how to find the same thing on your own site.
Site performanceOn 17.08.2026 an audit showed a CLS of 0.2283 on our website’s desktop homepage. The cause turned out to be the font: the ch unit in a paragraph and a skewed decorative band. We break down which tips measurably did not help, what got us to 0.0056 and how to check your own site.
