# How fast is fast enough for a website? > Fast enough is Google’s ‘good’ line on three measures, for three visits in four on phones: the main content in 2.5 seconds, a reply to a tap within 200 milliseconds, and a page that barely jumps. Below that line, fix speed first. Above it, I would usually spend the money on the offer. By Dion Zeneli · 5 February 2026 · updated 12 November 2026 · 5 min read Source: https://www.theweb0.com/blog/how-fast-is-fast-enough Filed under: Websites, Numbers, Interactive --- Nobody can tell you what one second is worth on your site, and that includes me. What I can tell you is where the line is, what companies found when they measured crossing it, and what usually keeps a marketing site on the wrong side of it. ## Where is the line? Google publishes three measures, the Core Web Vitals, and gives each a "good" mark.[^vitals] | Measure, and what it times | Good | | --- | ---: | | **Largest Contentful Paint (LCP).** How long until the biggest thing on screen has loaded. | 2.5 s or less | | **Interaction to Next Paint (INP).** How long the page takes to answer a tap, click or key. | 200 ms or less | | **Cumulative Layout Shift (CLS).** How much the page jumps while you use it. | 0.1 or less | Over 4 seconds, 500 milliseconds or 0.25, Google calls it poor. The band in between "needs improvement". Google measures them at the 75th percentile of real visits, with phones and computers counted apart. In plain words: three visits in four have to be good. Not the average visit, and not your own laptop on the office wifi. ## How many sites are over it? Fewer than half, on phones. *Drawing: Websites with good scores on all three Core Web Vitals, July 2025. Source: [HTTP Archive Web Almanac](https://almanac.httparchive.org/en/2025/performance). See it at https://www.theweb0.com/blog/how-fast-is-fast-enough* On phones, the first measure is the one sites fail most often: 62% pass LCP, against 77% for INP and 81% for CLS.[^almanac] So a slow site is most often slow to show its main content, not slow to respond once it is there. ## What did getting faster earn, where someone measured it? These are published results with a method behind them. **+8%** More sales after a 31% better LCP on one landing page, in an A/B test on paid traffic split 50/50. (Source: [web.dev, Vodafone, 2021](https://web.dev/case-studies/vodafone)) **+8.4%** More retail conversions from a mobile site 0.1 s faster. 37 brands, 30 days. (Source: [55 and Deloitte for Google, 2019](https://web.dev/case-studies/milliseconds-make-millions)) Vodafone's changes are worth reading, because they are ordinary ones. It moved a widget's rendering from the browser to the server, sent the important HTML ready-made, and resized the hero image.[^vodafone] Nothing exotic, and both versions looked the same. > **A number I leave out.** > > A 2022 Portent study is quoted everywhere: "A site that loads in 1 second has a conversion rate 3x higher than a site that loads in 5 seconds."[^portent] It does not say which load measure it used, and it compares different sites, not one site made faster. I don't put it in a sum. Rakuten 24, an online shop for everyday goods in Japan, ran the same kind of test on one landing page for about a month. The faster version had a 33.13% higher conversion rate. Its caption says version A loaded "within 1.6 seconds" and version B "within 2 seconds".[^rakuten] The page does not say which measure that is. If it is anything like LCP, both versions were already under the 2.5 second mark, and the faster one still won. Treat the line as a floor, not a ceiling. ## Is there a formula from seconds to dollars? No. Say it plainly, because someone will try to sell you one. Every study above measured someone else's site, often one page, often one step. None of them says that ten tenths of a second are worth ten times one. What you can do is size the question with your own numbers. Drag the page weight below and watch the download time against Google's mark, then put in your own traffic to see what one published step would be worth if it held for you. *Interactive: Page weight, time and money. Megabytes divided by the speed of the line. The money half uses your numbers and one published study, and it is a sizing, not a forecast. Use it at https://www.theweb0.com/blog/how-fast-is-fast-enough* ## What slows a marketing site down? Four things, in the order I look at them. 1. **The hero.** The big image or video at the top is usually what LCP times. On 76% of mobile pages, the largest element is an image.[^almanac] Size it for the screen, compress it, and load it first, never lazily. 2. **Fonts.** 87% of mobile pages load at least one web font.[^almanac] Each file is something the text may wait for. Two families and a few weights are plenty. 3. **Third-party scripts.** Tag managers, chat widgets, heatmaps, consent tools. The Almanac names JavaScript from "third-party widgets and analytics" among the causes of slow responses.[^almanac] Every script needs an owner and a reason to stay. 4. **Building the page in the browser.** A page that assembles itself in JavaScript shows little until the script has run. HTML rendered on the server arrives ready to read. It was one of Vodafone's changes. ## How much speed should I pay for? Get every key page over all three lines on phones, measured on real visits. Below the line, I fix speed before anything else, because the fixes are known and the tests above say they pay. Over the line, the case gets thinner. Rakuten says faster can still win. But each further tenth of a second costs more to find, and Google is clear that speed is not the whole game in search. It uses Core Web Vitals in ranking, yet it "always seeks to show the most relevant content, even if the page experience is sub-par."[^pe] Past good, I would usually spend the next dollar on what the page says. ## How do I check my own site? Use field data, not a lab score. PageSpeed Insights shows the Chrome User Experience Report for your address: real visits over the previous 28 days, at the 75th percentile. Its lab test is a simulated load on one device and one connection.[^psi] When the two disagree, the field data is the one your buyers had. My [site check](https://www.theweb0.com/tools/site-check) reads a page's HTML the way a crawler does, including how heavy it is. It does not time real visits, so use PageSpeed Insights for these three. Speed is part of every [website I build](https://www.theweb0.com/services/websites), checked against these three lines before launch. [^vitals]: The thresholds and the 75th percentile rule are from [web.dev, Web Vitals](https://web.dev/articles/vitals) (updated 31 October 2024). The "poor" marks are from the pages for each measure: [LCP](https://web.dev/articles/lcp), [INP](https://web.dev/articles/inp) and [CLS](https://web.dev/articles/cls). All checked 11 November 2026. [^almanac]: HTTP Archive, Web Almanac 2025, Performance chapter, with data from July 2025. INP is counted per website, LCP and CLS per page. [almanac.httparchive.org](https://almanac.httparchive.org/en/2025/performance), checked 11 November 2026. [^vodafone]: web.dev, Vodafone case study, 17 March 2021. Each version had about 34,000 visits a day. The faster version also raised lead-to-visit rate by 15%. [web.dev](https://web.dev/case-studies/vodafone), checked 11 November 2026. [^rakuten]: web.dev, Rakuten 24 case study. The A/B test ran on one high-traffic landing page, with traffic split evenly. The page shows no date. [web.dev](https://web.dev/case-studies/rakuten), checked 11 November 2026. [^portent]: Michael Wiegand, Portent, 20 April 2022: 20 sites, a 30-day snapshot of page speed. [portent.com](https://www.portent.com/blog/analytics/research-site-speed-hurting-everyone.htm), checked 11 November 2026. [^pe]: Google Search Central, page experience documentation. [developers.google.com](https://developers.google.com/search/docs/appearance/page-experience), checked 11 November 2026. [^psi]: Google, PageSpeed Insights documentation. [developers.google.com](https://developers.google.com/speed/docs/insights/v5/about), checked 11 November 2026.