A good page load time in 2026 is when the main content appears within 2.5 seconds for at least three-quarters of your visitors, measured as Largest Contentful Paint. Supporting targets are a server response (TTFB) under 0.8 seconds, first content under 1.8 seconds, and taps answered within 200 milliseconds. Hit these on mobile, not just desktop.
The rest of this post explains why "load time" is a slippery number, sets out the targets by metric, and shows how real sites compare and what to aim for if you are starting from a slow baseline.
Key takeaways
- A good page load time in 2026 means LCP within 2.5 seconds for at least 75% of visits, checked on mobile as well as desktop.
- Supporting targets are TTFB of 0.8 seconds or less, FCP of 1.8 seconds or less and INP of 200 milliseconds or less.
- The often-quoted 3-second rule comes from a 2016 study and is not a current threshold, so use the 2.5-second LCP target instead.
- Field data covers a rolling 28-day period, so a fix can take up to four weeks to show fully.
Why is "page load time" hard to define?
Older tools reported a single "fully loaded" or onload time: the moment every file on the page finished downloading. That number is easy to measure but tells you little about what visitors experience. A page can look ready in 1.5 seconds and keep loading chat widgets and tracking pixels for another 8 seconds, or show a blank screen for 4 seconds and then appear all at once.
Google moved away from single load times to user-centred metrics for this reason. Largest Contentful Paint (LCP) asks "when did the main content show up?", which is what most people mean by load time.
What are the target load times for each metric?
These are Google's published thresholds, applied to the 75th percentile of real page loads, separately for mobile and desktop:
| Metric | Good | Needs improvement | Poor |
|---|---|---|---|
| Time to First Byte (TTFB) | 0.8 s or less | 0.8 to 1.8 s | Over 1.8 s |
| First Contentful Paint (FCP) | 1.8 s or less | 1.8 to 3.0 s | Over 3.0 s |
| Largest Contentful Paint (LCP) | 2.5 s or less | 2.5 to 4.0 s | Over 4.0 s |
| Interaction to Next Paint (INP) | 200 ms or less | 200 to 500 ms | Over 500 ms |
| Cumulative Layout Shift (CLS) | 0.1 or less | 0.1 to 0.25 | Over 0.25 |
LCP, INP and CLS are the Core Web Vitals. TTFB and FCP are supporting metrics that help explain a slow LCP. Our Core Web Vitals guide covers what each one measures.
What does "75th percentile" mean for my load time?
It means the target has to be met for at least 75% of visits, not on average. If your median visitor sees LCP in 2 seconds but a quarter of visits take 3.5 seconds, the page is rated "needs improvement". This is deliberate: it makes you care about visitors on older phones and weaker signals, not just the typical case.
How fast are other websites?
The HTTP Archive's 2025 Web Almanac, using July 2025 Chrome data, found that 48% of websites had good Core Web Vitals on mobile and 56% on desktop. For LCP alone, 62% of sites were good on mobile and 74% on desktop.
So meeting the 2.5-second LCP target on mobile already puts you ahead of a large share of the web. It is achievable, but not automatic.
Is under 3 seconds still the rule?
You will often see "53% of visitors leave if a page takes longer than 3 seconds". That comes from a Google and DoubleClick study published in September 2016, which said 53% of mobile visits are likely to be abandoned beyond 3 seconds. It was based on 2016 mobile networks and full page loads, not LCP. It is a useful reminder that speed matters, but it is not a current threshold, and it should not be quoted as a fresh statistic.
Use the 2.5-second LCP target instead. It is current, it is what Google measures, and it is measured on the content visitors actually wait for.
Is a good load time different on mobile and desktop?
The thresholds are the same, but mobile is much harder to meet. Phones have slower processors, mobile connections have higher latency, and Google's lab test simulates a mid-range Android phone on a throttled connection with a 4x CPU slowdown. A page that loads in 1.2 seconds on your office desktop can easily take 3 or more seconds on a phone. Always check the mobile figures first.
What load time should my type of site aim for?
The thresholds apply to every site, but some practical targets help:
- Brochure sites and local services: with a handful of pages and few scripts, aim comfortably under 2 seconds LCP. There is little reason to be slower.
- Online shops: product and category pages carry more images and scripts. Aim for 2.5 seconds on product pages, and watch INP on filters and "add to basket".
- WordPress blogs and news sites: advertising and embeds are the main risks. Keep the hero image fast and lazy load below-the-fold content.
- Web apps and booking systems: INP often matters more than LCP once someone is using the tool.
How do I measure my own page load time?
- Run PageSpeed Insights on your key pages. The top section shows your real-visitor LCP, INP and CLS at the 75th percentile.
- Check the Core Web Vitals report in Google Search Console to see which page groups fail.
- Use the Lighthouse LCP breakdown to see whether time goes on the server, discovering the image, downloading it or rendering it.
MakeItFlow runs these PageSpeed and Core Web Vitals checks as part of its website speed test, so you can track the numbers over time rather than as one-off screenshots.
My load time is poor. What should I fix first?
Google's guidance on LCP suggests that, roughly, server response and the main resource download should each take about 40% of the LCP time, with discovery delay and render delay each under 10%. If one phase is far bigger than that, it is your bottleneck:
- Large TTFB: improve caching and hosting. See how to reduce TTFB.
- Large load delay: the browser is finding the main image late. Do not lazy load it, and consider
fetchpriority="high". - Large download time: the image is too big. Resize and serve WebP or AVIF.
- Large render delay: render-blocking CSS, fonts or JavaScript are holding up painting.
Our guide to improving Largest Contentful Paint walks through each fix.
Frequently asked questions
Is 1 second a realistic page load time?
For LCP on a fast desktop connection, yes, for well-built pages. On mobile at the 75th percentile it is ambitious for most small-business sites. Aim for comfortably under 2.5 seconds first, then decide whether further gains are worth the effort.
Does page load time affect SEO?
Google says good Core Web Vitals align with what its ranking systems seek to reward, but relevance and quality come first. A fast page will not outrank a much more useful slow one. Speed matters most for conversions and for keeping visitors who arrive.
What is the difference between load time and response time?
Response time usually means TTFB: how quickly the server starts replying. Load time, in the useful sense, is LCP: when the main content is visible. A fast server is necessary for a fast load time but not sufficient, because heavy pages can still be slow.
Why is my lab load time good but field data poor?
The lab test is a single simulated visit with an empty cache from one location. Field data includes every real visitor, including those on old phones, poor signal or far from your server. Field data is the one Google uses in Search Console, so treat it as the verdict.
How long does it take for improvements to show in field data?
Field data in PageSpeed Insights covers a rolling 28-day period, so a fix takes up to four weeks to show fully. Lab tests show the change immediately, which is why you should use both.
What to do next
Check the mobile LCP for your five most-visited pages and note which are over 2.5 seconds. Start with the worst page that matters commercially. If you want speed, SEO and security checked together, run a free website audit with MakeItFlow and work through the performance section first.
Sources
Written by the MakeItFlow team
We build the website audit these guides are based on. Every fact is checked against the primary sources listed above and this guide was last reviewed on 25 October 2026 . How we research and check
Check your own site in 30 seconds
Run a free audit covering speed, SEO, DNS, email authentication and security headers — and get a prioritised fix list.
