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.
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.
While anything that adds time to the page rendering process is a page speed factor, there are several issues that are most common:
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:
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:
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:
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.
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:
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.
1. Pagespeed Insights / Lighthouse Audits
2. Google Search Console
3. WebPageTest.org
4. Chrome User Experience Report
5. Crawling Tools like Botify
6. Google Analytics