What Is Page Load Time?

min to read

May 11, 2020

The Botify Team

last updated on

July 3, 2024

Search engines measure and use the speed at which a page loads in the browser as a factor in their ranking algorithms.

In 2010, Google confirmed the use of pagespeed, or page loading time, as a ranking factor for desktop web search results. In 2018, they announced pagespeed as a ranking factor for mobile or smartphone web search results.

Why Page Speed Matters

Pagespeed, or page load time, has been a key factor for user experience since the early days of the web.

As web page technology, like the development and wide use of JavaScript libraries, has advanced over time, the use of this technology has been tempered by the speed, or bandwidth, of Internet connections and the processing and memory resources of devices.

In short: the more data and resources the server sends to the browser, the longer it takes to deliver the “package” across a web connection and the slower the page will be visually rendered in the web browser and become usable.

As web connection speeds have improved over time, users have tended to be less patient with pages that load slowly and more likely to leave a website to find a faster experience.

Page speed impacts traffic across all channels and sources, but since Google has led innovations in using page speed in web search ranking algorithms, reducing latency has become a core component of SEO.

Page Speed Factors

While anything that adds time to the page rendering process is a page speed factor, there are several issues that are most common:

1. Server Response Time

The time between when the user or browser requests the page and the initial response from the server is known as the server response time, also measured as Time To First Byte (TTFB), or the time at which the server sends the first data that the browser can use to construct and render the page.

While many things can cause a slow server response time / TTFB, some common issues are:

Unavailable server computing resources, for example when a website on a shared web hosting environment (with a small dedicated share of that web server’s computing resources) sees a spike in traffic exceeding the capacity of those resources. Solving this issue often requires migrating the website to a more powerful server.
Database efficiency or database server issues, for example any problem that causes a slow response from a database server used to store and provide content used to construct the page (as with an eCommerce content management system). Solving this issue can be technical, requiring database query or structure updates, or may require migrating the database to a more powerful server.
Geographic latency, or the delay caused by the physical distance between the server and the user, is often solved by a Content Deliver Network (CDN) which stores website data on a geographically-distributed network of servers, dynamically selecting the server closest to the user.

2. Render-blocking Resources

Issues with render-blocking occur when the primary content of the page is delayed while the browser loads other resources.

When a browser or crawler requests a page and receives the initial source code (HTML) from the web server, the code often contains scripts (usually JavaScript or JS), cascading style sheets (CSS) and other resources, which add features and functionality to the page and which are often located at separate URLs.

Since the browser or crawler has no way of identifying which resources are important for rendering page content, these resources are loaded in the order they occur in the HTML. When resources are large or require substantial computing resources on the user’s device, they can result in a significant delay in the visual rendering of page content.

This issue can often be minimized by one or more of the following solutions:

Set JS resources to load asynchronously
Remove unused portions of JS/CSS resources
Entirely remove unused or unimportant scripts to avoid loading them at all
Minify and compress JavaScript and CSS resources, reducing their load time

3. Image Compression and Offscreen Image Loading

Images can add substantial load time to a page and warrant attention when pagespeed is a concern.

As web connections and device screens have improved, webmasters have included more image files of higher resolution for a rich user experience. While high-quality images often have a substantial positive impact on user experience, they may slow down pagespeed significantly.

There are a few primary methods of reducing page latency from image loading:

Compress, or optimize, images to reduce their file size with minimal loss of visual clarity
Convert images to modern formats which are optimized for web delivery
“Lazy load” or defer off-screen images until the user scrolls down to where they occur on the page

4. JavaScript and CSS Minification/Compression

Minification or compression for JavaScript (JS) and Cascading Style Sheets (CSS) reduces the overall file size of these resources to improve pagespeed.

While not the biggest opportunity to improve pagespeed on most websites, these resources JavaScript (JS) and Cascading Style Sheets (CSS) resources, especially those from large libraries or for sites with many different pages and features, can add unnecessary delay to page load times.

While the simplest minification methods simply remove whitespace from these files (which can save a surprising amount of space), more sophisticated tools refine this code substantially to reduce overall file size by using shortened syntax or removing dead or unused code.

5. Resource Caching

For resources that are loaded across pages, such as images, JavaScript or Cascading Style Sheets, caching allows web browsers to store these resources locally (on the user’s device) for quick re-loading later, avoiding unnecessary repeated requests and responses for the same resources.

Caching instructions are sent from the server to the browser in HTTP response headers that include the following information:

Whether the resource can be cached and by whom
How long the resource should be cached for (in seconds)

For example, the following response header will set a caching policy that allows only the individual user’s browser to store the returned resource for one year:

Cache-Control: private, max-age=31536000

(A “public” Cache-Control value would allow an intermediate client, like a Content Delivery Network or CDN, to also cache this resource.)

Additionally, using a file “fingerprint” or version code can allow webmasters to leverage caching to reduce page load times while forcing the client/browser to download a new version of a resource – when the fingerprint is changed, the new URL will cause the browser to download a fresh copy (it looks like a new resource rather than an updated version of the same resource).

While web search users are often visiting a website for the first time, search engines potentially check for caching and use it in ranking algorithms to ensure referred users have a good experience. Google’s guidelines for web caching specify, “all server responses should specify a caching policy to help the client determine if and when it can reuse a previously fetched response.”

Google’s Pagespeed Insights service checks for resource caching and identifies the number of resources without a caching policy or with a short time limit in the caching policy.