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

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.

Quick answer

• 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.

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.

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.

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:

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

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.

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.

When lab and field disagree, trust the field and use the lab to find the cause. Field data vs lab data explains the four combinations, and how to read 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:

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 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? shows how to tell them apart from a test result, and the page speed guide has the fixes in the order that pays off. If search is your main concern, how important page speed is for 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.