Page Load Time: What It Is, What Is Good and How to Reduce It

Page load time defined: what the clock starts and stops on

Page load time is the number of seconds between the browser starting to navigate to your page and the window load event finishing. Navigation starts when someone types the address or follows a link. The load event fires once the HTML, stylesheets, scripts, images and frames that the page asks for at load time have arrived and been processed.

The MDN page load time definition from MDN Web Docs frames it as the span that begins at navigation start and ends as the load event starts. It also warns that the figure is imperfect, because it varies with the device, the network and distance from the server. Our report stops the clock at loadEventEnd, a few milliseconds after the load event begins. The W3C Navigation Timing specification exposes that moment through the PerformanceNavigationTiming entry, so the value we show agrees with what you can read yourself from the browser Performance API.

What the clock misses matters as much as what it counts. Lazy loaded images far below the fold, timer driven scripts and widgets that appear after a click all arrive too late. You will also see it called website load time or page loading time. It is the same measurement, and we use page load time throughout.

Page load time vs page speed, TTFB, FCP and LCP

Load time is easy to confuse with the other speed numbers, because each one marks a different moment in the visit. The table puts them side by side with the mark that counts as good.

Google assesses these marks at the 75th percentile of real visits, so a single lab reading, ours included, cannot pass or fail a Core Web Vital. It can only point at a problem worth chasing.

Page load time is not a Core Web Vital, and the two can disagree. A page can paint its main content in 1.5 seconds and still log a long load time because a chat widget finishes late. The reverse happens too: a client side framework can render the hero text after an API call, long after the load event has fired, so the load time looks fine while LCP is slow.

Page speed is the umbrella word for all of them: read what page speed means for SEO for the broad view, and use our Largest Contentful Paint test page for the paint metric.

Why page load time matters for visitors and SEO

Visitors judge a slow page quickly. When nothing seems to happen they tap back or open another result, and a phone on a weak mobile connection makes every extra megabyte feel worse.

For search, be precise about what Google says. Google Search Central publishes Google page experience guidance, which states that page experience is not a single ranking signal and that relevance still comes first. Its ranking systems do favor content with good page experience, and Core Web Vitals are part of that picture. Our Core Web Vitals guide covers those metrics in detail.

The indirect effects are worth treating as expectations, not published rules. Google has said that a site which answers quickly can be crawled more heavily than one that struggles. Visitors who never have to wait are also more likely to keep reading, sign up or buy. Bounce rate in your analytics is a useful sign of that cost, though nothing Google publishes says it moves rankings.

How SEO Site Checker measures your page load time

Our audit opens your URL in a real headless Chromium browser, waits up to 20 seconds for the load event, and reads the timing the browser recorded.

The exact rule: page load time equals loadEventEnd minus the start of navigation, in seconds, rounded to two decimals. Up to 3.00 passes, above 3.00 and up to 5.00 is a warning, and above 5.00 fails.

This is a lab test of one cold visit from our server, so expect it to differ from what your visitors see. Run it yourself with the free SEO score checker.

What the browser measures

The load event waits for stylesheets, scripts written into the page (async ones included), images and iframes, and for anything those scripts add before it fires. Timers, fetch calls made after load and clicks do not hold it back. In our window of about 1280 by 720 pixels, a lazy image near the top is fetched early and counts, while images far down the page usually wait for scrolling and stay out.

Pass, warning and fail ranges

Only a pass adds to your score, because the score is passed checks divided by total checks, so an amber warning and a red fail both leave the point unearned. A 6 second result points at something structural, such as a slow server or a heavy script bundle, so read the waterfall before polishing small things.

Mobile devices, slow networks, warm cache visits and real user data are not tested, so a pass here says nothing about them.

What you see in the report

The row shows an icon, the time followed by Seconds, a short message, and a How to Fix button on a warning or a fail. The button opens the same steps you will find further down this page.

One wrinkle: the message text compares your time with a fixed 2.5 second reference, while the icon follows the 3 and 5 second rules. A result between 2.51 and 3.00 seconds therefore shows a green tick beside a message calling the page slower than that reference, and the tick is the verdict.

Two situations stop us from timing your real page. If the page does not finish loading within 20 seconds, the audit returns an error such as Unable to fetch page instead of a number. That can mean the page is too slow, or that our server could not reach it because of a DNS problem, a firewall rule or a country block. Open the URL in a private window to rule out an outage, check firewall and bot rules for blocks on data center addresses, and look in the Network panel for a request that never completes.

If a bot protection screen answers in place of your page, we time that screen and show a banner saying so. Allow the checker's requests in your firewall or CDN rules, or test again with the protection relaxed for a few minutes, otherwise the number describes the challenge page and not your site.

What is a good page load time?

There is no single ideal page load time, so treat these ranges as working guidelines, not Google thresholds.

Google sets its good marks per metric, at the 75th percentile of real visits. LCP of 2.5 seconds, INP of 200 ms and CLS of 0.1 are the three Core Web Vitals, and the official Core Web Vitals thresholds are on web.dev. The marks for FCP (1.8 seconds) and TTFB (0.8 seconds) come from separate web.dev guidance on those metrics. They are not Core Web Vitals, and the linked page does not state them.

Context changes what is acceptable. A heavy web app, a media site and a five page brochure site have different budgets, and a visitor on a congested mobile network needs a lighter page than someone on fiber. Average load times in statistics articles vary by source, device and year, so treat them as background and aim to cut a measurable chunk from your own time.

How to check page load time

You can read the number four ways, from no effort to very precise. Use more than one, because each tells you something different.

1. Run the free report. Enter your address in our page load time checker and read the Page Load Time row.
2. Use the Chrome DevTools Network panel. Open DevTools, switch to Network, tick Disable cache, reload the page and read the summary bar at the bottom, then study the waterfall chart for the slowest requests. DOMContentLoaded shows when the HTML was parsed, without waiting for images, and Load shows when the load event fired. Pick a profile such as Fast 4G or Slow 4G in the throttling dropdown to see how a slower connection changes the Load figure.
3. Read it from the console. Once the page has fully loaded, paste the snippet below into the Console. It reads the navigation entry and divides by 1000 to give seconds. If you run it before the load event has finished, you get 0.
4. Combine lab and field data. Run Lighthouse in DevTools or open PageSpeed Insights. Both work as a website speed test with lab data, and PageSpeed Insights also shows Chrome UX Report field data when your site has enough traffic, but that data covers only Chrome users over a rolling 28 day window, so it does not replace your own monitoring. Trust field data for how people really fare, and lab data to find causes.

const nav = performance.getEntriesByType('navigation')[0];
console.log(((nav.loadEventEnd - nav.startTime) / 1000).toFixed(2) + ' seconds');

The snippet uses the same two values our report does. Test three times and note the median, on mobile and on desktop, for the home page, a typical product or article, and your slowest template.

Why your page load time changes between tests

Two tools rarely agree, and two runs of one tool can differ. Picture one run from a data center that reads 2.4 seconds, and a second run a minute later that reads 3.6 because an ad call answered slowly and the consent banner script finished last.

Rule of thumb: compare like with like. Use the same tool and settings, run several tests, and judge the trend, not one reading.

• Location and connection. A data center on fast fiber loads a page quicker than a phone on 4G.
• Cache state. Repeat visits reuse stored files, so a cold lab run often reads slower than what many real visitors get.
• Server and third parties. Shared hosting load, ad calls, consent banners and chat widgets finish at different times from one minute to the next.
• What gets timed. A bot protection screen can be the thing that loads, and logged in pages differ from the public one.

How to reduce page load time: fixes in order of impact

Most slow pages share a handful of causes: a slow server, unoptimized images, large JavaScript bundles, too many HTTP requests, long redirect chains, heavy web fonts and uncached files. Open the Network waterfall, sort by size and by time, and fix the largest or slowest items first.

Speed up the server response

Turn on page caching, run a current PHP version if your site uses PHP, trim slow database queries and host close to your visitors. A TTFB under 0.8 seconds is the web.dev good mark, and a late first byte delays everything after it. Our article on how hosting speed affects rankings explains the trade offs. Cut redirect chains too, so links point straight at the final URL, since each hop adds a round trip.

Shrink and modernise images

Resize each image to its displayed size, compress it, serve WebP or AVIF where you can, and always set width and height. The free Image Compressor can shrink your images and convert them to WebP or AVIF, and it needs no account.

<img src="/images/team.webp" alt="Our team at the studio" width="800" height="450">

Minify, defer and remove scripts

Minify CSS and JavaScript, defer anything that is not needed for the first view, and delete plugins and tags nobody uses. Audit third party scripts one at a time, since one tag manager can pull in a dozen more files. The CSS Minifier is a quick way to shrink a stylesheet.

<script src="/js/app.min.js" defer></script>

Clear render blocking files

Inline the small amount of CSS the top of the page needs and load the rest later. Preload your key font and add font-display: swap to its @font-face rule so text shows while the font downloads. The preload tag needs crossorigin even for a font on your own domain, otherwise the browser fetches the file twice. The render blocking resources page goes deeper on blocking CSS and JavaScript.

<link rel="preload" href="/fonts/body.woff2" as="font" type="font/woff2" crossorigin>

Cache files and use a CDN

Browser caching lets repeat visitors reuse files. Add gzip compression or Brotli for text files, and put static files behind a CDN such as Cloudflare, which also serves them over HTTP/2. Our CDN usage test shows whether your site already uses one.

Give a file a one year lifetime only if its name changes with its content, such as app.3f9c1.css. For those, send Cache-Control: public, max-age=31536000, immutable from your build or CDN. Stable names like /images/team.webp need a shorter lifetime, so the Apache sample below uses one month for images and one week for CSS and JavaScript. Expiry only applies to the MIME types you list, and the JavaScript type depends on your server's mime.types file: older setups send application/javascript and current ones text/javascript, so the sample lists both.

<IfModule mod_deflate.c>
  AddOutputFilterByType DEFLATE text/html text/css text/javascript application/javascript
</IfModule>
<IfModule mod_expires.c>
  ExpiresActive On
  ExpiresByType image/webp "access plus 1 month"
  ExpiresByType image/avif "access plus 1 month"
  ExpiresByType image/jpeg "access plus 1 month"
  ExpiresByType image/png "access plus 1 month"
  ExpiresByType image/svg+xml "access plus 1 month"
  ExpiresByType text/css "access plus 1 week"
  ExpiresByType text/javascript "access plus 1 week"
  ExpiresByType application/javascript "access plus 1 week"
</IfModule>

If your server runs Nginx instead of Apache, a comparable setup is below. It turns on gzip, gives images 30 days and CSS and JavaScript seven. Put the gzip lines in the http or server block of your config, keep the location blocks inside the server block, and reload with nginx -s reload. Brotli needs a module on either server, so most people get it from their host or CDN.

gzip on;
gzip_types text/css text/javascript application/javascript image/svg+xml;
location ~* \.(avif|webp|jpe?g|png|svg)$ {
  expires 30d;
}
location ~* \.(css|js)$ {
  expires 7d;
}

Lazy load below the fold

Add loading="lazy" to images and iframes that start offscreen, but never to the main image at the top, as in <img src="/images/map.webp" alt="Office map" width="600" height="400" loading="lazy">. Total page weight drives load time, so see our guide to web page size for what a sensible budget looks like.

Retest and keep a budget

Measure after each change, not after five, so you know which fix paid off. Ticking Disable cache shows the cold load our report sees.

Rerun the report and the DevTools check each time, compare with your first reading, and write down a target time and a maximum page weight so tuning becomes a habit.

Reducing page load time on WordPress, Shopify and other platforms

The table lists the highest impact changes for common platforms.

Page load time checklist and performance budget

Copy this list into a ticket or release checklist and tick it off after each deploy, so a slow build is caught before visitors see it.

• Fast first byte. The server answers in under 0.8 seconds with a page cache on.
• Light images. Every image is resized, compressed, in a modern format and has width and height set.
• Lean scripts. CSS and JavaScript are minified, non critical scripts are deferred and unused plugins are gone.
• Cached files. Static files have long cache lifetimes and go out compressed or through a CDN.
• A written budget. A target load time and a maximum page weight are checked after every release.