Our last three website performance articles covered the why and how's of testing website performance, and introduced our two favourite performance testing tools, WebPageTest.org, and Lighthouse. In this article we'll get an overview of the common causes of slowing loading times, and how to spot them using our favourite testing tools.
Latency is the time it takes for a request from a client's browser to traverse the internet to reach the website server. A number of factors impact latency with the principal one being physical distance. Data on the internet travels at the speed of light, so you'd think distance wouldn't matter too much, however, even small amounts of time can compound to have a surprising impact. Here are some realistic examples of request latency:
- Sydney to Melbourne: 5ms
- Sydney to Perth: 25ms
- Sydney to San Francisco: 75ms
NOTE: Common tools used to determine latency between servers are Ping and Traceroute, they will provide you with Request Round Trip (RTT) latency, ie the time it takes for a request to get to the server and back. So 2 times the numbers above.
Here is an example of the effect of latency on a webpage load, we'll ignore internet speed and any potential network congestion and just focus on the effect of latency. We'll request a website hosted in San Francisco from a browser located in Sydney.
- Browser establishes a TLS (Secure) connection with server, 6 * 75ms = 450ms
- Browser sends HTTP Request for the main page = 75ms
- Server sends HTTP Response containing page which specifies 10 assets = 75ms
- Browser requests the 10 additional assets = 75ms
- Server responds with 10 assets 10 * 75 = 750ms
So in this example of a website with 10 assets, (a pretty simple page) we've shown that latency would add nearly 1.5s to the page load time. If the same site was hosted in say Melbourne, the time due to latency would be just 95ms. To solve this problem you would either move your website server or utilise a caching CDN like Peakhour.
How do I check for latency problems?
If there is a long distance between your server and your customers, eg your website is hosted in the US and your customers are in Australia, then page load times will be significantly affected by latency. A good tool to see indicative RTT times between cities is provided by wonder network. Webpagetest.org also provides a Traceroute tool which can give you indicative RTT times between its testing locations and your website.
2. Old version of HTTP
Browsers communicate with websites using a protocol called HTTP, this protocol formalises the steps needed to connect a browser and server so a webpage can be downloaded. Since the introduction of the web this protocol has gone through a number of revisions, the currently widely adopted version is HTTP/2.
Even though HTTP/2 was introduced over 5 years ago over 50% of websites are still only served over HTTP/1.1. Without getting too technical, HTTP/2 offers significant advantages over older versions by reducing the number of connections between a browser and server, and transferring information much more efficiently.
Simply by serving your website over HTTP/2 can achieve a 10-15% improvement in page load times.
How do I identify the version of HTTP my website is served over?
Run a performance test of your website using WebPageTest.org, once complete click on the 'Details' link in the report navigation. You will see the Waterfall View, click on the first request, circled below in this image:
It will bring up the request details including the Protocol used, circled below:
A slow initial response from the server to a page request is a common killer of page load performance. The majority of websites are built using some sort of Content Management System (CMS), eg Wordpress, Magento, Drupal, Shopify, to name a few. By default, a CMS has to construct a page each time a browser requests it, even if the content hasn't changed. This construction can involve executing a lot of code and querying a database several times before spitting out the HTML that forms the page.
The specification of your server, the number of CMS plugins, the state of your database, and the number of simultaneous users can all impact the response time. A slow server may take 10s or more to respond while even a fast server can still take over a second to generate a page, enough to pretty much make you fail the new Core Web Vitals guidelines before you even get started.
How do I check for slow server performance?
Server performance can be checked from the waterfall view in WebPageTest.org. The time taken to download the main document indicates whether server performance is impacting your page load. Here's an example:
The total time taken to download the main document here is over 1.3s, not too bad, but we've already used up over half the 2.5s required to achieve 'Good' for the Largest Contentful Paint (LCP) metric in web vitals
4. Page Weight
How do I check my page weight?
WebPageTest.org reports the page weight in the far right of its summary, circled here:
Over 27mb in images is what's weighing down this page.
Peakhour also has a fantastic pageweight tool that you can run for a page on your website and receive a full optimisation report for the images on the page, along with downloadable optimised images.
5. Blocking Resources
How do I identify blocking resources?
The easiest way to check is to use Google Lighthouse) to identify them for you. After running the report go to the opportunities section and expand the 'Eliminate render-blocking resources' section to see what it finds.
6. Third Party Resources
It is very common these days for websites to include third party resources. These are files that have to be fetched from a domain/url other than the one that the page is being requested on. Eg if you are requesting www.domain.com.au, it might include a resource from a third party, eg www.anotherdomain.com.au. Common third party resources might be analytics scripts (eg Google analytics), marketing tools (eg Mailchimp)
This forces the browser to open another connection to the third party, the time taken to do this, combined with the possibility the third party might be slow to respond (see latency and server performance above), can often ruin load times. If the resource in question is also a blocking resource the problem is compounded.
Spotting a problem with third party resources
WebPageTest has a section 'Domains' which displays all the individual domains that the browser connected to when loading the page:
There are many factors that can slow down your website, driving away customers and costing you money. You have to regularly test your website to check for issues and address them when you find them. Next we'll cover what you can do to fix the issues we've mentioned here.