If you are reading this blog, its likely that you fit into one of three main categories: Web Developer, Web Operations, or Business/Marketing. If that assumption is true, its probably also likely that you care about a website and want to ensure that its fast today and stays fast going forward. So if both of those statements are true, what are the types of website stats you want to look for?

Well, you probably will want to look for the following types of information which fall into three main categories:

1. Overall Connectivity & Performance

• DNS Resolution Failures
• TCP Connection Failures
• User Experience

2. HTML Page Performance

• HTML Network Performance
• Response Status Codes
• Response Content
• Response Header Content

3. Asset Performance

• Asset Status Codes
• Asset Network Performance

Within the Yottaa service, you will find all of these under the Issues which are part of the configuration for a Monitor, but all of these are things you should be watching for no matter what solution you use to monitor your web properties. Here is how we configure these issues in the Yottaa interface: 

DNS Resolution Failure

A DNS resolution problem means that there is a major issue resolving the DNS record for the site. If a customer’s browser cannot interpret the DNS information, they won?t be able to find your website, so this is a big problem and you probably want to know about it right away. As a result, we classify it as a Critical Error by default. To get a better understanding of why DNS is so important, check out this webinar recording we did in September.

TCP Connection Failure

A TCP connection failure means that the site isn’t available regardless of whether the DNS resolution worked or not. Some possible reasons for a TCP connection failure could include a firewall blocking the site or the server being too busy, resulting in a connection time out. Within Yottaa, we include both DNS Resolution and TCP Connection Failure under a single issue called Network Connectivity.

User Experience

User Experience refers to the stats that appear under Frontend User Experience in Yottaa Tests and Yottaa Monitors as well as in WebPageTest.org. These are Time to Title, Time to Render, Time to Display, and Time to Interact.

So what are some good or bad numbers to watch for when monitoring these stats? It depends on what makes sense for your environment. That said, recently we added a blog post showing research we have done looking at how well a collection of about 14,000 websites performed. It?s definitely worth reading the entire post, but for now, here is the summary chart.

Let’s look at the numbers for the 90th percentile (the 90th percentile means that 90% of all sites are faster than this number). If you want to ensure your Time to Title is faster than the values in the 90th percentile, you might have your monitoring solution alert you when slower than 3,382 milliseconds. To make things a little simpler, let’s just go with 3 seconds.

Take a look at the following screenshot showing how you might configure this if using Yottaa’s Issues based on the numbers in the 90th percentile chart. In case you aren’t familiar with these stats, check out this e-book we wrote up recently.

HTML Network Performance

A network performance issue can be any one of the stats that typically correspond to a server’s backend performance. These are the times for DNS resolution and Connection, as well as the Time to First Byte and Time to Last Byte. To get a better idea of what each of those stats really means, check out the great e-book I referred to above.

Let?s look at the numbers for the 90th percentile again. So if you want to be alerted if your DNS time, or the time required to resolve your webhost?s IP address, is longer than those experienced by the 90th percentile, you might enter 255 milliseconds for that particular alert. You could also add a Network Performance Issue that fires if the Time to First Byte is longer than 1,663 milliseconds. In the screenshot below, you can see how to configure these issues in the Yottaa interface, but any monitoring tool should be able to do this.

HTTP Response Status Code Issue

HTTP response status code issues refer to the status codes the server sends with each request. Usually when everything works, you will get a 200 status code. But when things don?t work as expected you might get a 400 (Bad Request), 403 (Forbidden), 500 (Internal Error), or many others. If you are curious, you can get a full list of possible status codes onthis Wikipedia page.

In your monitoring solution, you should configure alerts to fire anytime you get any status code of 400 or greater. This signifies some sort of error, either caused by the server or by the browser.

HTTP Response Content

Sometimes you will want to get alerted if there is specific content on the page you are monitoring. If your site has a database backend and the database has a standard response if nothing relevant is found, you could look for that specific phrase. In the above example from the Yottaa service, an issue will fire if the content body contains the word Invalid.

HTTP Response Header

Some pages on your site will issue cookies, set cache times, or perform other functions using specific headers in the HTTP response. You will probably want to set up alerts based on the lack of those headers. You can also look for specific text included in a header. This allows you to look for the lack of a Set-Cookie header, or maybe a Cache-Control header that includes the text max-age=0. In the above example from Yottaa, we trigger an issue if the Response Header Set-Cookie does not exist.

Asset Network Performance

Asset network performance refers to the same statistics as the above HTML network performance section but are focused on the assets instead of the HTML. What is an asset? An asset is anything that is referred to in the HTML. Examples of typical assets include JPG, GIF, and PNG images, CSS style sheets, JavaScript files, AVI and MOV video files, and more.

In the screenshot below, I have configured Yottaa to trigger an issue if any of the asset network performance times are slower than those seen by the 90th percentile.

Asset HTTP Status Code

Assett HTTP Status Codes is similar to HTTP Response Status Codes except that it is for the assets instead of the HTML file. Everything else from the above section applies here as well.

I hope that this gives you a feel for what kinds of information you should be looking for in whatever monitoring solution you are using. If you have any questions about how to configure those issues in Yottaa or if you have suggestions for other special stats to watch for, leave a comment below.