Page load time explained

A fast website is vital to delivering a great end user experience. Amazon once famously found that every 100 ms of added latency cost them 1% in sales. That's why there's so many resources available on the topic, and companies often spend a lot of resources on optimizing their websites.

Tools like Panelbear help you understand how fast or slow your website is for every page view. You can then filter by country or page to slice and dice the data any way you need. In addition to measuring your website traffic, you can also set up page speed alerts and get notified when your website is underperforming.

How does a browser load a web page?

When you click on a link, your web browser starts a multi-step process to load all synchronous resources required to show the web page on your screen, this is called the Page Load Time. The longer this process takes, the longer a visitor must wait to interact with a website.

Once loaded, a website may perform additional asynchronous requests which do not block that initial page load. This is most commonly seen in Single-page Applications (SPAs), in which as the visitor interacts with the site, more resources are loaded and the view is updated in-place.

However, it's important to understand that the page load time only measures the time it took to initially load a site - it doesn't measure requests that happen after the initial load (eg. fetch requests or async scripts). Once the page has loaded and a visitor starts interacting with your page, no additional measurements are made as it's not considered part of the initial page load.

Here's the major steps involved when loading a web page on a modern browser:

A simplified view on what happens during these phases when someone opens your website:

1. The page load begins when a user initiates the navigation. For example when typing your website's URL in the browser or clicking on a link.

2. The browser then queues the request, and tries to resolve the domain name for the URL. It then attempts to establish a secure connection to your server, and sends the request.

3. Your server processes the request. This step includes all server side logic (e.g. database queries, rendering the HTML, etc...), and your server begins sending the response back to the browser.

4. The browser parses the HTML passed back to it, and renders the web page in the browser. This initial HTML may initiate further resource requests, such as stylesheets, Javascript files, images, etc...

5. Once all synchronous resources have been loaded and rendered into the browser window, a page load event is fired, marking the completion on the web page load for your visitor. This is where Panelbear considers the page load "complete".

Example performance metrics

Panelbear's Performance Monitoring measures and aggregates your page load time into various metrics: average, percentiles (p50, p75, p95), and a simplified breakdown of the browser timings. Additionally, you can filter these metrics by any country or page on your website to get a better picture of your site speed.

Load time average and percentiles

Page Load Average: This is the average page load time. It's usually a good enough metric to quickly tell you how fast or slow your overall performance is. However, averages can be misleading because they "hide" outliers - they are far from the full picture - and that's why we also include percentiles as explained below.

50th Percentile (p50): It indicates that 50% of the page views are accounted for in the value shown. For example a p50 of 2 seconds means that half the users experienced a load time longer than 2 seconds.

75th Percentile (p75): It indicates that 75% of the page views are accounted for in the value shown. For example a p75 of 3 seconds means that 75% of the users had a load time of 3 seconds or less (or 25% of the users experienced a load time longer than 3 seconds).

95th Percentile (p95): It indicates that 95% of the page views are accounted for in the value shown. For example a p95 of 5 seconds means that 95% of the users had a load time of 5 seconds or less (only 5% of the users experienced a load time longer than 5 seconds).

Browser timings: network, backend and frontend

The Timing Breakdown shows you a simplified view of the three main phases for loading the page:

• Network: Time spent on network related phases. These can vary greatly based on the connection speed that a visitor has, the type of connection (e.g. cable, 3G, 4G, 5G), etc... This metric includes:

  • DNS lookup
  • Establishing connection to server
  • Downloading response from the server

• Backend: An approximation for the time your backend server took processing the request, and preparing the response. We use the time to first byte (TTFB) as a proxy for your server response time. This corresponds to the time it took from sending the request, to when the first byte of the response arrived back from the server.

• Frontend: This metric tells you how much time was spent on parsing the server response, preparing the page resources and rendering them to the visitor's browser. This includes:

  • DOM processing
  • Rendering

How to speed up page load time

In case you're looking to further improve your site's speed and end user experience, you should look into keeping your page load time to a minimum.

Here's some general recommendations to help you speed up your website:

• Compress your resources using gzip or Brotli if available on your web server.
• Bundle static assets using tools like Webpack, to reduce the number of HTTP requests.
• Set cache headers whenever possible to avoid unnecessary HTTP requests between page loads.
• Consider using a CDN to cache static assets at the edge.
• Use defer or async for non-essential HTML script tags (eg. analytics). This avoids blocking render during the initial page load.

Additionally, you might want to check out our introduction to Core Web Vitals - a new set of standards proposed by Google which paint a more complete picture about the end user performance. After all, page load time is just one of many factors that affect your site's end user experience.