Improving Web Page Performance

datachart

Providing a fast internet site is important for several reasons. Understanding why your site loads slowly can be difficult if you don’t understand what to look for and why some symptoms point to one solution or another. In this article from David Berry, we learn some great information on what to look for, troubleshooting techniques, and tools available to help you resolve web page loading issues.

You can divide web performance into two main areas; backend performance and frontend performance.

Backend 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.

Frontend Performance

The second area of performance deals with what must happen within the browser in order to render a web page for the user. Not only must the HTML of the page be downloaded, but the browser must also download all of the other assets needed by the page, including CSS, JavaScript and images used on the page. Finally, the browser must then take all of this information and layout the page for the user. This is the front-end performance of the page.

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 http://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 majority of this time is needed for the browser to download all of the other assets needed for our page. This includes all of the CSS, JavaScript, fonts and images that are used by the page. With the advent of highly interactive web applications, we are downloading more of these types of files than ever, especially JavaScript files. And it simply takes time for the browser to download these additional assets needed by a web page.

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.

You should read the entire article for some really great information on this important subject.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s