# What is a good page load time? Targets in seconds, and how to measure

> A good page load time means the main content is visible within 2.5 seconds on a phone, the page reacts to taps within 200 ms and nothing jumps, for at least 75 % of visits. The targets per metric and how to measure yours.

Updated 2026-09-26 · Speed & Core Web Vitals · HTML version: https://getreport.app/guides/what-is-a-good-page-load-time

A good page load time is one where the main content is on screen within 2.5 seconds, the page reacts to a tap within 200 milliseconds and the layout does not jump, for at least three out of four visits on both phones and computers. Those are Google's Core Web Vitals thresholds, and they are a better answer than a single "loads in X seconds" figure, because a page load happens in stages and visitors judge the stage where they can see and use the page.

This guide is for anyone who has been asked "how fast should our website load?" and wants a number they can defend. It gives the targets for each stage, explains why averages mislead, shows how real sites compare and how to measure your own page load time. For the wider topic of speed and how to improve it, see the [page speed guide](https://getreport.app/guides/page-speed).

## Quick answer

| Stage the visitor notices | Metric | Good | Poor |
| --- | --- | --- | --- |
| The server starts answering | TTFB | 0.8 s or less | over 1.8 s |
| Something appears | FCP | 1.8 s or less | over 3.0 s |
| The main content is visible | LCP | 2.5 s or less | over 4.0 s |
| The page reacts to a tap | INP | 200 ms or less | over 500 ms |
| The layout stays still | CLS | 0.1 or less | over 0.25 |

- **Judge at the 75th percentile of real visits,** not the average and not your own best run.
- **Mobile first:** phones on mobile networks are where most pages miss the targets.
- **The browser's "load" time is a poor target.** It includes files the visitor never sees and ignores whether the page was usable earlier.
- **LCP is the closest thing to "page load time"** that visitors and Google both care about.
- Measure your pages for free with the [website speed test](https://getreport.app/tools/speed-test).

## What "page load time" really means

Ask five tools for your page load time and you may get five numbers, because they time different moments:

- **The `load` event** is when the browser has fetched every file the HTML asked for, including images far below the fold. It is what older tools and the "Load" figure at the bottom of the Network panel in developer tools report. A page can be fully usable seconds before it, or still blank-looking long after it if scripts build the page later.
- **"Fully loaded"** in some tools also waits for network activity to go quiet, which counts analytics beacons and chat widgets nobody waits for.
- **First Contentful Paint (FCP)** is when the first text or image appears.
- **Largest Contentful Paint (LCP)** is when the largest image or text block in the viewport is painted, usually the hero image or the headline. This is the moment most visitors would call "loaded".

Since 2020, Google and the web performance community have moved away from a single load time towards these user-centred timings. When someone quotes a page load time, ask which moment they measured, on which device, over which network, and whether it was one test or real visitors.

## Good page load time, stage by stage

The thresholds in the table above come from Google's Core Web Vitals documentation on web.dev (LCP, INP, CLS) and its guidance on the supporting metrics (TTFB and FCP). Each is measured at the 75th percentile: the value three out of four visits stayed within.

**TTFB, 0.8 s or less.** Nothing appears until the server answers. A cached page on decent hosting answers in 100–300 ms from nearby; an uncached CMS page often takes over a second. See [TTFB: what a slow server looks like](https://getreport.app/guides/ttfb-what-a-slow-server-looks-like).

**FCP, 1.8 s or less.** The first sign of life. A slow FCP with a fast TTFB usually means render-blocking CSS or JavaScript.

**LCP, 2.5 s or less.** The core target. If you want one number for "how fast should a website load", this is it: main content visible within 2.5 seconds for 75 % of visits.

**INP, 200 ms or less.** Not a load time, but it decides whether a page that *looks* loaded is usable. A page that shows its content in 1.5 s and then ignores taps for another two seconds does not feel fast.

**CLS, 0.1 or less.** A page that is still moving is not finished loading as far as the reader is concerned.

Lab tools add two numbers that only exist in a simulated test. Lighthouse's green range on mobile is **Speed Index at 3.4 s or less** (how quickly the visible area fills in) and **Total Blocking Time at 200 ms or less** (how long the page was too busy to respond during load). They are useful for diagnosis, and neither is used by Google for ranking.

> **Check: Largest Contentful Paint.** LCP is when the biggest thing on screen — usually the hero image or headline — finishes loading. Visitors judge "is this site slow?" on it, and Google uses it for ranking.
>
> 1. Find the LCP element (named in your report) and make it lighter, earlier or both — a compressed WebP/AVIF, sized to the screen, without lazy loading.
> 2. Preload it with <link rel="preload" as="image"> or add fetchpriority="high" on the <img>.
> 3. Cut what comes before it — render-blocking CSS/JS and slow server responses push LCP back.

> **Check: Interaction to Next Paint.** INP measures how quickly the page reacts when someone taps or clicks. Lab tools cannot simulate it, so this comes from real Chrome users; slow responses feel like a frozen page.
>
> 1. Break up long JavaScript tasks and defer third-party scripts so the main thread is free when people interact.
> 2. Respond to input visually first (a pressed state, a spinner), then do the heavy work.
> 3. Reduce DOM size and avoid layout-heavy work inside click handlers.

> **Check: Cumulative Layout Shift.** CLS measures how much the page jumps around while loading — the button that moves just as someone taps it. It is one of Google's three Core Web Vitals.
>
> 1. Give every <img>, <video>, ad slot and embed explicit width and height (or aspect-ratio) so space is reserved before it loads.
> 2. Preload the main web font and use font-display optional, or swap with a size-adjusted fallback font, so text does not reflow.
> 3. Never insert banners or content above existing content after load.

## Why averages mislead

"Our average load time is 1.9 seconds" sounds good and says little. Averages are pulled down by the many fast visits from people on good connections, often including your own team, and hide the slow quarter of visitors on older phones and weak networks. Those are exactly the visitors who leave.

That is why Google's thresholds use the 75th percentile. A page passes when at least 75 % of visits are good, so a fast office network cannot hide a slow experience on a train. Two more reasons averages mislead:

- **Mobile and desktop differ.** The same page can pass on desktop and fail on phones. Look at them separately; Google assesses them separately.
- **Pages differ.** The home page is often the fastest page on a site because it gets the most attention and the most caching. Product, category and article templates carry most traffic and are often slower.

## How fast do real websites load?

There is no meaningful "average website load time" across the web, but there is good data on how many sites meet the targets. The HTTP Archive's 2025 Web Almanac, based on Chrome UX Report data from mid-2025, found that on mobile:

- 62 % of sites had a good LCP,
- 77 % had a good INP,
- 81 % had a good CLS,
- and 48 % passed all three Core Web Vitals, against 56 % on desktop.

So loading the main content within 2.5 seconds is the hardest target for most sites, and more than a third of sites miss it on phones. Meeting all three thresholds puts a page in roughly the faster half of the web on mobile. That makes the targets demanding but realistic: plenty of ordinary sites on ordinary hosting meet them.

To see where you stand against the sites you actually compete with, compare directly:

> **Free tool:** [Website speed test comparison: up to 5 sites](https://getreport.app/tools/compare-speed): Free website speed test comparison: put your site next to up to four competitors on PageSpeed score, real-user Core Web Vitals, page weight and requests.

The comparison runs the same test on your site and up to four others on the same device and marks the best result in each row.

## How to measure your page load time

> **Free tool:** [Free website speed test and page speed check](https://getreport.app/tools/speed-test): Free website speed test for any page: Lighthouse lab results and real-user Core Web Vitals on mobile and desktop, with a fix for each slow part. No sign-up.

The speed test runs Lighthouse through Google's PageSpeed Insights on a throttled phone and on desktop, and shows the Core Web Vitals of real Chrome visitors from the Chrome UX Report beside it, where Google has enough data. Read it in this order:

1. **Field data first.** The real-visitor LCP, INP and CLS at the 75th percentile, over the last 28 days. This is your page load time as visitors experience it.
2. **Lab metrics second.** TTFB, FCP, LCP, Speed Index and TBT from one simulated visit. They explain the field numbers and show the effect of a change the same day.
3. **The LCP element.** Which image or text block is the main content, and what delayed it.

> **Check: Real-user Largest Contentful Paint.** LCP is when the biggest element on screen finishes loading. Google's threshold for "good" is 2.5 s at the 75th percentile of real Chrome users.
>
> 1. Find the LCP element in the Speed module and make it smaller, earlier or both.

A few rules make the numbers trustworthy:

- **Test several templates,** not only the home page. For a list of pages, the bulk tool tests up to 50 URLs at once and puts LCP, TBT and CLS in one sortable table.
- **Run lab tests three times** and compare the metrics rather than the score. A few hundred milliseconds of variation between runs is normal.
- **Test logged out.** Logged-in visitors often bypass the page cache.
- **Keep the report links.** Before-and-after comparisons are only useful when you know exactly what was tested.

> **Free tool:** [Bulk PageSpeed Insights: test 50 URLs at once](https://getreport.app/tools/bulk-pagespeed): Free bulk PageSpeed Insights: run Google's Lighthouse test on up to 50 URLs at once, with Core Web Vitals, LCP, TBT and CLS in a sortable table and CSV.

When lab and field disagree, trust the field and use the lab to find the cause. [Field data vs lab data](https://getreport.app/guides/field-data-vs-lab-data) explains the four combinations, and [how to read a website speed test](https://getreport.app/guides/reading-a-website-speed-test) walks through a full result.

## Targets by type of page

The thresholds are the same for every page, but where the risk lies differs by template. Use these as the checks to make, not as extra numbers:

| Page type | What usually decides the load time | What to watch |
| --- | --- | --- |
| Home and landing pages | Hero image or video, sliders, marketing tags | LCP element not lazy-loaded; video with a poster image |
| Product pages | Gallery image, variant picker, reviews and upsell apps | LCP on the first product image; INP on variant and add-to-cart |
| Category and listing pages | Dozens of product images, filters | CLS from tiles without dimensions; INP on filters |
| Articles and blogs | Web fonts, ads, embeds | CLS from ads and embeds; FCP delayed by fonts |
| Checkout and forms | Scripts, validation, payment widgets | INP when typing and submitting |

If you want a stricter internal target than Google's, set it as a **speed budget**: for example LCP under 2.0 s in the lab on your product template and no more than a set amount of JavaScript. [Speed budgets](https://getreport.app/guides/speed-budgets-setting-one-and-holding-to-it-in-ci) shows how to write one and check it on every release.

## If your load time is too slow

Most slow pages come down to a few causes: a slow server, a heavy hero image, render-blocking CSS and JavaScript, too many third-party scripts and layout shifts from images and fonts. [Why is my website slow?](https://getreport.app/guides/why-is-my-website-slow) shows how to tell them apart from a test result, and the [page speed guide](https://getreport.app/guides/page-speed) has the fixes in the order that pays off. If search is your main concern, [how important page speed is for SEO](https://getreport.app/guides/page-speed-and-seo) explains how much the load time matters for rankings.

## Common mistakes

- **Quoting the `load` event as the page load time.** It measures files, not what the visitor sees.
- **Using the average.** Judge the 75th percentile, separately for mobile and desktop.
- **Testing from the office.** A fast laptop on fibre hides what a mid-range phone on a mobile network sees.
- **One run, one page.** Test several templates, three times each.
- **Treating 2.5 s as "fast enough" for the lab result only.** The field number for real visitors is what has to pass.

## Questions people ask

### What is a good page load time?

A good page load time shows the main content within 2.5 seconds (Largest Contentful Paint), reacts to taps within 200 ms and keeps layout shift at 0.1 or less, for at least 75 % of real visits. Those are Google's Core Web Vitals thresholds. The server should start answering within 0.8 s and the first content should appear within 1.8 s. Measure on mobile first, where most pages fall short.

### How fast should a website load on mobile?

The same targets apply to phones and computers: main content within 2.5 seconds and a response to taps within 200 ms, at the 75th percentile of real visits. They are harder to meet on mobile because phones have slower processors and less stable connections. Google assesses mobile and desktop separately, and the 2025 Web Almanac found fewer mobile sites than desktop sites passing all three Core Web Vitals.

### What is the average website load time?

There is no meaningful single average, because tools time different moments and averages hide slow visits. Better data comes from the Chrome UX Report: the HTTP Archive's 2025 Web Almanac found that 62 % of sites showed their main content within 2.5 seconds on mobile, and 48 % passed all three Core Web Vitals on mobile. Compare your pages with those thresholds rather than with an average.

### Why does my page load time differ between tools?

Because each tool measures a different moment, from a different place, on different hardware. One reports the browser's load event, another Largest Contentful Paint; one simulates a slow phone, another uses a fast desktop connection; one is a single lab run, another 28 days of real visitors. Compare like with like, run each test several times, and use real-visitor field data as the final judge.

### Is the browser's load event still worth tracking?

Not as a target. The load event fires when every file the HTML requested has arrived, including images far below the fold, so it can be late on a page that was usable much earlier, and early on a page that scripts build afterwards. Track Largest Contentful Paint for loading, Interaction to Next Paint for responsiveness and Cumulative Layout Shift for stability instead.