As websites continue to advance, the underlying protocols that they run on top of must change in order to meet the demands of user expected page load times. This blog is the first in a series on APMdigest where I will discuss web application performance and how new protocols like SPDY, HTTP/2, and QUIC will hopefully improve it so we can have happy website users.

Web Performance 101

The performance of your website is obviously very important. When visitors comes to your company website, they won't stick around very long if it's slow. If those visitors are users of your web application, they may not be for long if they encounter a consistently slow performing app.

Google and other companies have done studies showing that users begin to think of leaving a site if they see nothing within 1 second. Much of this is from a book written by Jakob Nielsen in 1993 called Usability Engineering. Since that time, 1-second response times have been the benchmark of a fast performing website. It still is today, and is not likely change over time.

As performance degrades to over 1 second, users start to think about going elsewhere. If there are other legitimate competitors, you're probably lost that visitor to them already. At 10 seconds of page loading, most users are long gone, even with no competitors. Most will not suffer through waiting that long for a webpage to load.

It's clear to see that a slow website will affect your company's bottom line, particularly if you do most or all of your business online. A slow site leads to higher bounce rate when the visitor hits the Back button before seeing the goodness of your products or services. A slow site also leads to lower conversions because visitors won't buy what you're selling because they may equate the slow site to a poor product or service.

So we want to make our websites and web applications fast. But how can we go about doing that?

First let me tell you about a myth ...

The Bandwidth Myth

According to CDN provider Akamai's State of the Internet report published for Q3 2015, the global average connection speed for the Internet was measured at 5.1Mbps. The top 10 countries are well above that figure with a minimum speed of 14Mbps. Average peaks are measured at 32.2Mbps.

5.1Mbps may seem small for those who live in areas with much higher available speeds for businesses and residents. For others, this may be blazing fast. It's all local.

But anyone who has worked in performance engineering or similar fields knows that bandwidth capacity or speed isn't the only parameter that determine good web performance. In fact, it's very insignificant, especially nowadays with big bandwidth speeds possible, as evidenced by Akamai's report.

Many Internet service providers, however, don't advertise them that way.

They talk up bandwidth, while barely mentioning some other more important parameters: network latency, server response time, application design, etc. Bandwidth speed is not nearly as much as important as how low a latency there is between where the web server is located, and where visitors are coming from.

So how do we go about looking on the other parameters? Let's first look at what happens when make a web request.

Anatomy of a Web Page Request

A web page request involves many steps.

We have:

■ DNS requests

■ Opening up TCP connections

■ Authenticating with TLS

■ The HTTP request itself to get web page data

■ Processing of the request on the server

■ The download of the requested content

There can be many substeps in between, but that's it at a high level. So it is very important to optimize the above steps to ensure that they are occurring as fast as possible, and improve web performance.

But how can you do that?

Glad you asked. Read Web Performance 101 - 4 Recommendations to Improve Web Performance for some common recommendations to optimize the steps of a web page request.