Pinpoint Website Performance Issues

In order to be able to improve website performance, you must first be able to pinpoint where possible issues are originating from. Website performance problems can occur for many different reasons. Therefore, the goal of this article is to help identify common problem areas that should be further investigated if you are experiencing a slow website.

Tools to check your website performance

The first step in pinpointing which parts of your website can be improved upon is running a site speed test to help analyze performance. Site speed tests will provide you with information such as an asset's size, how many requests are made, the time it takes to fully load a page from a particular location, and much more. The following speed test tools are examples of sites that can be used to analyze site performance,

• KeyCDN Website Speed Test Tool. This lightweight speed test tool allows you to test your website's speed from 10 different locations. The waterfall view provides you with information regarding the loading order of your assets while clicking a particular asset reveals its response and request headers.

• Google PageSpeed Insights. Google's website analyzer grades sites with a score from 0-100 (the higher the number the better). The score is based on the number of rules passed which include everything from optimized images, minified CSS and JS, render block resources, browser caching, etc.

• Pingdom Website Speed Test. This site speed analyzer provides a similar waterfall view as KeyCDN's speed test tool. However also provides additional information such as: performance grade, page analysis, and history.

Read our article for a complete list of the 10 website speed test tools for analyzing website performance.

TTFB

TTFB, or time to first byte, is a very important measurement to be taken into consideration when looking to optimize website speed. A website's TTFB is calculated as:

HTTP request time + process request time + HTTP response time

To identify a resource's TTFB this can be seen by opening the Chrome Developer Tools, Navigating to the Network tab, selecting an asset, and viewing the Timing tab. In the example below for www.keycdn.com, the TTFB is 144.03 ms for the initial HTML document.

A website's TTFB can vary greatly depending the resources required to load the website. Therefore, this must be taken into consideration when evaluating the speed of your time to first byte. That being said, there can be various reasons for a slow TTFB, to name a few:

• a poorly configured web server,
• network problems,
• physical distance / network latency,
• and server performance.

Critical path

The critical path is the collection of events that must take place in order to render a webpage. Optimizing the critical rendering path means minimizing the event that resource A needs to rely on resources B to load. The less assets you have relying on one another, the faster the page will be able to display to the user. Chrome's DevTools Initiator column helps offer a bit more granularity into why a particular asset is being requested. This can be useful if you see a particular resource being loaded to generate your page but are unsure of why it is loaded or where it is coming from.

Clicking the initiator value will take you to the location where the asset is being called. This helps give website owners the ability to better see where an asset is being called from, which can be useful for purposes such as modifying an asset's location or removing the asset entirely to improve critical path rendering.

Render blocking resources

Closely related to the above mentioned critical path section, there may be resources that are blocking your site's DOM (Document Object Model) which will often times slow down your site's performance. Identifying a website's render blocking resources can be achieved by either using Google's Page Speed Insights Tool or a browser tool such as Chrome's Dev Tool.

Running a website through Page Speed Insights will provide a list of the render blocking CSS and JS files that may exist.

Render blocking resources can also be identified using Chrome DevTools by navigating to the Network tab, clicking on the "Show Overview" option, and reloading the page. All CSS and JS that loads before the blue line can be assumed to be blocking the DOM.

Completely eliminating the use of render blocking resources may not be possible in all cases. However, there do exists some recommendations to help prevent blocking resources such as lessening the amount of CSS files, minifying your CSS, moving your scripts to the bottom of the page (just before your </body> tag), etc.

For a detailed article and full list of recommendations, read our post Perceived Web Performance - What is Blocking the DOM?.

Number of HTTP requests

A high number of HTTP requests may also be the culprit of a slow loading website. HTTP requests occur when a user visits a website and wants to see a particular page. That page is made up of multiple assets and unless the asset is stored in browser cache, often times a request to the origin server, a proxy /CDN, or an external server must be made for each. The more requests being made can sometimes mean the more time a user must wait for the site to finish loading.

The number of requests a particular website must make varies greatly from site to site. Running a site speed test will tell you how many requests were needed in order to generate a particular page.

Analyzing the requests made to load your web page is important as there may be external requests, caused by plugins or other sources, that are slowing down your site.

Identifying where assets are delivered from

If you are using a CDN you are likely already familiar with the integration process of a CDN URL with your website. If you are a KeyCDN customer for example, your CDN URL with either be the predefined Zone URL (e.g. example-hexid.kxcdn.com) or a custom Zone Alias (e.g. cdn.yourwebsite.com).

When running a site speed test, it is important to distinguish between which assets are being delivered via the CDN or from anywhere else (e.g. the origin server or external sources). The screenshot below shows the various resources loaded to display KeyCDN's homepage.

As can be seen, the majority of the assets are delivered via the CDN since the request URL begins with https://cdn.keycdn.com. There are however a few resources which are making external HTTP requests in order to be retrieved. Distinguishing between CDN assets and non-CDN assets is important so that website owners can determine the source of the resources that are slowing them down.

Diagnosing a slow download

As mentioned above, knowing which domain your assets are coming from is important to help diagnose any performance problems. If you are experiencing a slow download of a particular asset, it is important to identify if the asset is coming from your server or a third party server. A major factor that can contribute to the slow download of an asset is distance. The further away a visitor is from the source of data, the longer the transfer of information will take, this is referred to as latency.

Implementing a CDN for assets that are hosted on your origin server can help reduce the amount of latency that users in various geographic locations experience. Furthermore, you can also run a traceroute command to a particular IP or domain to determine if there are any inconsistencies in the RTT times between network hops. Doing so will help you further determine which hop/router is causing the slow download.

Large image sizes

On average, images account for a large portion of a website's size. Using the page analysis feature on Pingdom's site speed test, we can see that images represent over half the size of KeyCDN's home page.

Being aware of the size of the various types of content that make up a website is important so that you can pinpoint what needs to be improved. Using an image optimization plugin such as Optimus, is an easy way to reduce image size while leaving the quality of the image itself unchanged. While optimizing existing JPGs and PNG is a great way to reducing image size, this can be taken a step further by converting existing images to WebP format in conjunction with Cache Enabler.

With WebP image sizes being up to 26% smaller than PNGs, converting to WebP image format can help greatly decrease a website's overall page size.

To see our full WebP test results, read our WordPress Cache Enabler article.

301 redirects

Avoiding 301 redirects is important as they add additional round trips which in turn increases latency. A 301 redirect is a method used to navigate traffic from location A to location B. An example of it's use might be for a URL that has changed and the website owner wants to direct traffic from the old URL to the new URL. Although useful in certain cases, 301 redirects aren't site speed friendly and should be minimized as much as possible.

Other suggestions to improve website performance

The following suggestions are not methods for pinpointing website issues per se however, should be taken into consideration if looking to further improve website performance.

HTTP/1.1 vs HTTP/2

HTTP/2 is rapidly expanding in popularity due to it's key improvements as compared to its predecessor HTTP/1.1. For example, HTTP/2 is binary, fully multiplexed, requires only one connection for parallelism, uses header compression, etc. Since no browser currently supports the new protocol unencrypted, websites are required to use an SSL certificate in order to benefit from HTTP/2's improvements. However, with Let's Encrypt now in public beta, SSL certificates can be obtained for free and are directly available within KeyCDN.

To measure the performance between HTTP1 and HTTP/2, Load Impact provides a test tool that displays the loading time of a URL performed by each protocol.

Using HTTP/2 results in a page load speed of 1.41 times faster than HTTP1. Taking advantage of HTTP/2 can help improve the overall user experience of a website by delivering content much faster. To check if your origin server or CDN supports HTTP/2, visit our HTTP/2 Test Tool.

Upgrade to PHP 7

Keeping the various components of a web server up to date is critical for reasons such as security patches, performance upgrades, and so on. If you are using PHP, upgrading to PHP 7 can help greatly improve performance as compared to PHP 5.6.

Based on the results from the above image, PHP 7 is able to handle 204 requests per seconds compared to PHP 5.6's 96 in WordPress 3.6 Additionally, PHP 7 is able to handle 183 more requests than PHP 5.6 in WordPress 4.1.

To view the full post with tests for various CMS/frameworks, see the PHP7 Infographic by Zend.

Summary

There are many ways to help improve a site's overall performance, however sometimes it isn't so obvious where you should start. The suggestions in this article aim to give website owner's a starting point as to where they may want to begin investigating to improve their site's loading times.