What Is a Good Page Load Time in 2026.

Ask ten people what counts as a good page load time and you get ten different guesses. Google has already answered this, in public documentation, with specific numbers. A Largest Contentful Paint under 2.5 seconds is good. Above that, Google labels it poor. That single figure is the closest thing to an industry standard that exists, and it is the number I check first on every site I audit.

I run BZ Development from Novi Sad, Serbia, and most of the work I do is fixing exactly this: sites that load slowly enough to lose visitors and rankings at the same time. So let me walk through what "good" actually means, because it is not one metric, it is three.

Page load time is measured in three separate parts

People say "load time" as if it were a single stopwatch reading. Google's Core Web Vitals split it into three distinct measurements, and each one tracks a different kind of slowness.

Largest Contentful Paint (LCP) measures how long it takes for the biggest visible element, usually a hero image or a headline block, to render on screen. Under 2.5 seconds is good, over 2.5 seconds is poor.

Interaction to Next Paint (INP) measures how long the page takes to respond after someone clicks, taps, or types. Under 200 milliseconds is good, over 500 milliseconds is poor.

Cumulative Layout Shift (CLS) measures how much the page jumps around as it loads, the annoying moment when a button moves right as you go to tap it. Under 0.1 is good, above 0.25 is poor.

A site can pass one of these and fail the other two. I have audited pages with a fast LCP and a CLS score that made the page feel broken because images loaded without reserved space and shoved the text down mid-read.

Why these thresholds are not arbitrary

Google did not pick 2.5 seconds because it sounds clean. These numbers come from Google's own research into user behavior and are published as part of the page experience documentation on web.dev. And they matter beyond user comfort: Core Web Vitals are a confirmed Google ranking signal, meaning a slow page is not just annoying, it is a page Google is less inclined to rank well, all else being equal.

That second part gets lost in a lot of conversations about site speed. Business owners think of load time as a courtesy to visitors. It is that, but it is also a mechanical input into how the page competes in search results. I have seen the two effects compound on real projects: a hospitality client in Croatia saw impressions climb 415% and clicks climb 230% over twelve months, tracked through Google Search Console, after a rebuild that addressed both technical SEO and site speed together. I am not claiming load time alone did that. Structured data, crawlability, and content all played a part. But speed was one of the levers, not a side note.

A good page load time is not a nice-to-have. It is the difference between a page Google is willing to rank and one it treats as a liability.

What actually slows a page down

In practice, the culprits repeat across almost every audit I run. Unoptimized images are the most common one: a photo exported at full camera resolution and dropped into a page without resizing or compression. Render-blocking scripts are the second: JavaScript that has to finish loading before anything else on the page can appear. Third-party embeds, tracking pixels, chat widgets, font loaders pulled from external servers, each one adds a network request the browser has to wait on before the page feels usable.

None of these are exotic problems. They are the accumulated weight of small decisions made without measuring the cost. A single uncompressed hero image can push LCP from 1.8 seconds to 4 seconds on its own.

How I check load time on a real site

I do not guess at this. I pull Core Web Vitals data from field measurements (real visitors, real devices) rather than relying only on a lab test run once from my own machine. Lab tests are useful for diagnosing a specific problem, but field data is what Google actually uses to judge the page, because it reflects the range of devices and connections your actual visitors have.

When I take on a performance job, the sequence is: measure LCP, INP, and CLS as they exist today, find the specific element or script responsible for each failure, fix that element, then measure again. No step in that sequence involves a general claim like "we will make your site fast." It involves a number before and a number after, on the same three metrics Google publishes thresholds for.

What a good load time is worth to a small business

If you run a restaurant, a clinic, a hotel, a shop, the traffic that a slow page turns away is traffic that was already looking for you. Someone searched, clicked, and waited. Every additional second past that 2.5 second LCP threshold is a chance for that person to leave before the page even finishes rendering, and Google's own field data across the web shows abandonment climbing sharply past that point.

A restaurant client of mine in Croatia, in a four month window tracked through Search Console, saw impressions rise 37% and clicks rise 7%, holding a 5.4% average click-through rate the entire time. Smaller numbers than the hospitality client above, shorter window too, but the pattern is consistent: fix the technical foundation, including load time, and the visibility follows.

Good page load time is not a vanity metric you check once and forget. It is a maintained state, one that erodes every time a new plugin, a new tracking script, or a new unoptimized image gets added to the page without anyone checking the cost.