Have you ever had one of your users ask you to slow your website down? Has someone ever complained to you that they didn’t have a long enough wait before a web page in your application loaded? No, it is very unlikely. Whether your users are internal or external to your organization, they expect the web sites that they use to perform well.
This infographic at Kiss Metrics reports that 47% of e-commerce site users expect a page to load within 2 seconds, and the slower the page loads, the more likely that the customer will abandon the site altogether. It is not just the website performance of e-commerce sites that matters: Often, nowadays, your website is the first impression that customers, partners or potential employees get of your company. Whenever we use a web site, we form perceptions of the company that the website belongs to. These perceptions are based on a broad range of characteristics such as the aesthetics of the site and how easily we are able to navigate the site to find the information or perform the transaction we need to; however the performance of the site matters as well. Imagine that you visit a website and you have to wait ten seconds for each page on the site to load. Regardless of the quality of the product or service that company is offering, your perception of that product and the company won’t be helped by the slow load times you have to endure on their web site.
These challenges are not just limited to e-commerce sites or sites on the public internet. Most enterprise applications today are built as web applications. A one second delay may not seem like very much, but these seconds add up for the hundreds of users who may be accessing your web application throughout the day as part of their work. These delays affect how fast your users can perform tasks and serve your customers. Slow, inefficient web pages ultimately show up as lost productivity for your users.
Components of Website Performance
You can divide web performance into two main areas; backend performance and frontend performance.
When you navigate to a web page, the browser sends a request to a web server for that page. When the web server receives that request, it most often times needs to dynamically construct at least some of the content on that page. The time within which the server can create this content and return it to the browser is a measure of the backend performance of the page. The efficiency of your database queries, the time it takes to complete any web service calls and the performance of your C# or VB.NET code (if you are using ASP.NET) all contribute to this backend performance.
We will use the example of loading the homepage for simple-talk.com to demonstrate the difference between the frontend and backend performance of a web page.
We see that it took a total of 495 milliseconds to download the HTML for the homepage of simple-talk.com. If we click on the first row in the table (the one labeled www.simple-talk.com) and move over to the timing tab, we can see a breakdown of the timing for this resource.
We want to pay particular attention to the value labeled “Waiting (TTFB)”. This figure includes the amount of time it took to process the request on the web server as well as the amount of time it took for the HTTP request to travel over the network. In this instance, this value is 296 ms, so we know that our web server was relatively fast in handling our request.
By capturing a video of the website as it loaded, I was able to measure the time it took from when I entered the URL into my browser until the point in time where the browser started rendering the page to the screen and also until the page was visually complete for “above the fold” content. After 1.97 seconds, the browser started rendering the page to the screen and at the 2.4 second mark, I had a visually complete page on my screen.
We need to understand the difference between the two metrics, one that told us how long it took for the initial HTML page to load (495 ms) and the other that told us how long before the page was visually complete and ready for the user to interact with it (2.4 seconds), as it is this difference that represents the frontend performance of the web page. Many articles on Simple Talk over the years have focused on the backend (server and database) components of performance. We can see from this example that the frontend aspects are also important, and can often account for a much larger portion of the time that the user spends waiting for the web page to be rendered. So let’s understand what is happening during this time interval between the point when the HTML for our page has been downloaded and when the page has been rendered to the user.
The browser also spends time laying out and rendering the page to the user. Web layout is a dynamic process that depends on other factors such as the screen resolution of the user viewing the page. Upon downloading and parsing all of the HTML and CSS for your page, the browser has to go through this layout process and calculate the size and position of all of the elements within the page so that the page can be rendered. As such, the order in which we load certain resources turns out to be very important so these calculations can start as soon as possible.
As I will soon explain, the homepage for Simple-Talk.com can be improved. However, a web page that renders to the user in 2.4 seconds is actually fairly reasonable. It is quite typical to find web pages that take several seconds for the browser to download the required assets and layout the page, with the result that the user sees an empty or incomplete page for an extended period of time. The data from Kiss Metrics should be enough to convince you that we can, and must, minimize the amount of time that the user has to wait to view our pages. To do this effectively, we need to understand the factors that contribute to the frontend performance of our web pages and learn how to identify and correct frontend performance issues when they appear.
What Drives Frontend Performance?
We’ve touched on a couple of the factors that determine how quickly a web page can be rendered to a user, but let’s take a few minutes to understand these more in depth.
First and foremost, the total size of a web page and all of its assets determines how quickly your page can be downloaded and rendered to a user. For any website on the public internet we must assume that the user is connecting over what is, relatively speaking, a slow network connection. Broadband connections vary widely depending on where you are, but still only average 5 Mbps worldwide. (https://www.akamai.com/us/en/about/news/press/2015-press/akamai-first-quarter-2015-state-of-the-internet-report.jsp). Connection speeds from mobile networks are even slower, often around 4 Mbps or less; and these numbers generally represent best case scenarios, not when the network is congested during peak usage in the evening due to all of your neighbors streaming their favorite shows from Netflix.
Connections Speeds Around The World
How fast is the average Internet connection speed in the country you live in? The Akami State of the Internet Report provides the answers.
If you are developing line-of-business applications in a corporate environment, you may be tempted into thinking that all of your user’s have fast network connections, so the size of your pages is not the most important factor. However, you may have some branch offices with slower network connections. Furthermore, today we are seeing more and more remote workers than ever before, and these workers are probably connected over a VPN connection using a standard broadband Internet connection. So for your page to remain fast for these users, the overall page size remains an important consideration.
Number of Network Requests
We also need to be concerned about the total number of requests that the browser must make to the server in order to render a page. Just as you would expect, the more requests a browser must make, the longer a web page takes to load and render to the user.
Every request sent from the browser to the web server will experience network latency. Simply put, it takes time for a network packet to travel from its source to its destination. The further geographically you are from the web server, the longer it takes each of your HTTP requests to travel over the network to the server. In addition, mobile networks tend to incur higher amounts of network latency than a traditional broadband connection. The latency that occurs on each request acts like a small delay. For pages that have to make hundreds of requests for all of the assets necessary to render the page, all of these small delays can add up to a noticeable one.
Ordering of Components within your web page
Before the browser can lay out your webpage, it needs to have finished loading all of the CSS for the page. Therefore, we want to make sure that our all of our CSS resources are located in the document head so they will load early on in our page load lifecycle. Once the browser has all the HTML parsed and all of the CSS loaded, it can lay out the page and start to render something to the screen. And once again, we want this to occur as soon as possible to give some visual cues to the user that something is indeed happening on our website.
Analyzing Your Pages
Fortunately today, we have free tools that can allow us to quickly analyze a web page for performance best practices and give us a report card on the items that need to be fixed. The first of these tools is Google PageSpeed Insights (https://developers.google.com/speed/pagespeed/insights/). PageSpeed Insights can analyze any site that is publicly accessible on the Internet. A sample output from the analysis is shown below.
As you can see, each recommendation is marked as having a high, medium or low impact of the performance of the page. Clicking into each recommendation also provides you with additional details about why PageSpeed Insights is giving you that recommendation.
A similar tool is YSlow (http://yslow.org/) which was originally developed by the Yahoo! Exceptional Performance Team. YSlow contains a more extensive set of rules than PageSpeed Insights and is available as a browser extension for Chrome, Firefox, Safari and Opera. Since YSlow runs in your browser, it can also be used to analyze pages located behind your firewall.
Which tool you end up using is a matter of personal preference, but what is important is to know of the existence of these tools and use them to analyze the pages on your website on a regular basis. While it is possible to produce a checklist of performance best practices, these tools have already done that for you, and they tell you exactly what areas to focus on in order to improve the performance of your pages. They also each give you an overall page score, which serves as an overall barometer for the efficiency of your page and that you can track to make sure you don’t see a significant degradation when changes are made to your site.
Optimizing Your Pages
After analyzing your pages, you may want to learn about the recommendations that are being made and their impact on performance. Both PageSpeed Insights and YSlow offer very good documentation which explains why a recommendation was made and how it impacts page performance.
Some of the most common recommendations and how to address them are listed below:
<clientCache cacheControlMode="UseMaxAge" cacheControlMaxAge="90.00:00:00" />
This will instruct IIS to cache all static files in this directory and all subdirectories for the time specified, in this case 90 days. By having separate web.config files for each directory, you can effectively define different caching policies for each directory tree.
Optimize Images – Images are often the largest assets on a web page. First, make sure the dimensions of the image you send to the browser is no larger than the size the image will display on your page. If an image has a size of 300×300 pixels on your page, send an image of 300×300 pixels. A larger image will take more bandwidth to send and just be scaled to the smaller size in the browser anyway.
Second, use tools like PNG Crush or Kraken.io to apply lossless compression to your images and reduce their file size. For JPEG images, a slight change in the quality setting can dramatically decrease the file size with only slight visual differences.
Place All CSS Files and <style> Tags in the Document Head – Before the browser can layout the page, it must download all of the CSS files for the page. Therefore, we want to load our CSS as early as possible, so CSS should be in the document head.
To create web sites that are quick and responsive, we must consider both frontend and backend performance issues. For frontend performance issues, tools like PageSpeed Insights and YSlow can quickly help us how well our pages follow known best practices for performance. Further, these tools tell us exactly where our greatest opportunities for improvement are, all in the matter of a few seconds. Given the how easy these tools are to use, there is really no reason not to make regular use of these tools to make sure that the pages in your website load as quickly as possible for your users.