05 Dec 2018

...new feature (beta)!

We've just rolled out a brand new feature: response time monitoring.

As well as monitoring websites for uptime and downtime we now monitor the time it takes for each website to respond.

The response times are logged and can be viewed in graphical format. Read on to see some pretty graphs of response times...

monitor response time for website


Why Monitor Response Time?

1) If a webpage is slow the experience for the visitor is usually bad. Many users simply leave a site if it doesn't respond within a few seconds.

2) When a site has a high response time it is usually an indication that the server is struggling. Slow response times are really common when servers are overloaded and the information can be used to identify server problems or to explain that there is a problem when contacting a web host.

3) Slow response times and high levels of downtime are linked. A site that has a high response time is more likely to suffer from downtime than a site that is running quickly.

What Is Response Time?

Don't confuse page load time with response time!

Page load time is "the time it takes to download and display the entire content of a web page in the browser window". This very much depends on the size of the webpage to be displayed - heavy pages with lots of large images or video will take longer than light pages with just text and a few optimised images. This is not a good value of response time.

Response time is sometimes defined as Time To First Byte, i.e. "the time taken to receive the first byte of data" from the server. However, this is not perfect because it is shorter than the time taken for the first byte of data to actually appear in the web browser.

We use Time To Receive Headers as response time because this most accurately reflects when website users see a response... headers are received immediately before the first content is loaded to the web browser.

You can find more technical detail on defining response time at the end of the post: When is a website considered down as opposed to just slow?

Logs & Stats

All users now have access to response time logs and stats. If you are already a Downtime Monkey user you don't need to do anything - all accounts have been upgraded automatically to include this new feature.

Free plan users can see individual response times (monitored every 3 minutes) for the last 24 hours and daily averages of response times for 90 days.

Pro Plan users can view individual response times (monitored every minute) for the last 24 hours, for the last 7 days and daily averages of response times for 2 years.

Graphs

Here are a some response time graphs taken from real websites. You can see the difference between a fast website and a site that has problems:


Fast website: response times every minute for 24 hours

This website was running well with responses mostly around 100ms. There were a couple of periods of slightly slower responses but no major problems.

Response Time (milliseconds) vs Time (UTC)


Overloaded website: response times every minute for 6 days

This website was running slowly and was frequently overloaded by comment spam bots. Even during better periods the response times were approximately 1-3 seconds and during periods of overloading they rose to more than 15 seconds. This site also experienced regular downtimes with only 82.139% uptime during 7 days!

Response Time (milliseconds) vs Time (UTC)

Response Times for Your Monitors

To view the response time graphs and stats simply login, navigate to your website monitors and click on 'view stats' for the website in question.

If you don't have an account yet, you can sign-up for a free account and begin monitoring your websites in seconds!

Note this feature is in a short period of beta testing and there may some changes as testing progresses.

 

30 Nov 2018

Previously we answered the question: Why Whitelist an Email Address?

TLDR; "If you expect to receive important emails from a trusted email address it is worth whitelisting the address to make sure that emails won't be accidentally blocked by an overzealous email client."

In this post we cover how to do it in Yahoo! Mail by adding a filter...

1) Login to Yahoo! Mail and select settings by clicking on the gear icon:

Yahoo Mail Settings


2) Scroll down the menu and select 'More settings':

Yahoo Mail More Settings

3) In the left-hand menu select 'Filters':

Yahoo Mail Filters


4) Select 'Add new filters':

Yahoo Mail Add New Filters


5) Type a name for your filter - here we chose "Whitelist Website Downtime Alerts":

Yahoo Mail Set Filter Name


6) Under 'Set rules', select 'From' as the rule and 'contains' as the criterion for the filter. The filter will be applied to any email that comes from an email address that contains the text you add:

Yahoo Mail Select From Address


7) Input the email address that you want to whitelist - here we input 'monitor@downtimemonkey.com' to whitelist all emails that come from this address:

Yahoo Mail Set From Address


8) Under 'Choose a folder to move to' select 'Inbox'. This ensures that all emails will arrive in the inbox and never be sent to spam:

Yahoo Mail Move To Inbox


9) Click save:

Yahoo Mail Save Filter


10) Once the filter has been successfully created, you can view it under 'Your Filters':

Yahoo Mail Filter Complete


Whitelisting A Whole Domain

In 'Step 7' a single email address was whitelisted. It's also possible to whitelist all emails associated with a domain.

By adding downtimemonkey.com to the contains field instead of monitor@downtimemonkey.com we would whitelist every email address belonging to downtimemonkey.com.

 

23 Nov 2018

...and how you can too!

We've just spent several days improving the accessibility of the Downtime Monkey website. Last week we carried out an audit of the site with Google's new tool web.dev, which is currently in beta.

The tool returned high scores for three of the four aspects that were tested: performance (i.e. website speed), best practices and SEO (i.e. optimisation for search engines).

This was no surprise as we'd focused heavily on best practice and SEO when developing the site and in January we undertook a very thorough performance audit where we reduced page load time by more than half.

However, the accessibility score was just 48%, so there was plenty of room for improvement.

Here are the scores before:

Accessibility Score 48%

...and after the accessibility improvements were completed:

Accessibility Score 90%

Side note: all of the pages with embedded YouTube videos showed reduced performance scores. This has previously been covered in-depth in this post on improving page speed.

What Is Accessibility?

From Wikipedia:

"Web accessibility is the inclusive practice of ensuring there are no barriers that prevent interaction with, or access to websites, by people with disabilities. When sites are correctly designed, developed and edited, generally all users have equal access to information and functionality."

In practice, this (mostly!) means ensuring that screen-reader software can access and interact with all the content that is in place on a website.

Why Improve Accessibility?

The web is possibly the modern world's greatest tool and good accessibility means that more people have access to this brilliant tool and all the benefits that come from it.

But that is not the only reason to improve accessibility...

If your website is inaccessible you are losing some users, which means that you are losing customers.

Improving accessibility is very straightforward, and we've provided full details of the optimisations that we made so that you can apply them to your own website.

Step 1: Run A Test

Our starting point was a website that had already been developed with accessibility in mind but had never been thoroughly tested.

Testing with web.dev is easy. Simply input the URL of the webpage that you want to test and hit 'run audit'.

The results include an overall score and a list of recommendations for each of the 4 categories. Here we're only concerned with the accessibility category.

Step 2: Act On The Recommendations

Following the recommendations is straightforward but it is time consuming as every page on a website must be tested and corrected individually.

This is because improving accessibility is about making all content visible to screen-readers.

It is easy to forget to add an 'alt tag' to an image or an 'input label' to a form field, and a few omissions can drastically reduce the accessibility of your website.

Here are some improvements that are easily made:

Alt Tags For Images

The error: "Image elements do not have [alt] attributes".

All images must have an 'alt tag' in place. This should consist of a few words that describe the picture so that a screen-reader can read out a description of the image.

For example:

			
<img src="images/blue-bird.jpg" alt="blue bird in forest">
			
		

Labels For Input Fields

The error: "Form elements do not have associated labels".

Most input fields should have an associated 'label' so that screen-readers can read out a description of the input field, letting the user know what to input into the field.

Note that labels are not required for hidden inputs, buttons or 'submit' inputs.

The common inputs that require input labels are:

			
<input type="text">
<input type="password">
<textarea>
<input type="radio">
<input type="checkbox">
<select>
<input type="tel">
			
		

It is best to apply the label 'explicitly', as in the following example. Note that the 'for' attribute should match the 'id' of the input:

			
<label for="name">Name</label>
<input type="text" id="name" value="">
			
		

Invisible Labels For Self-Explanatory Input Fields

The error: "Form elements do not have associated labels".

Sometimes an input field is self-explanatory for sighted users. One example from Downtime Monkey is the 'select your country' dropdown menu - it's obvious from the design of the site that the user needs to select their country. Adding a visible label here would actually decrease user experience.

But screen-readers can't read the design of the site!

The solution is to add a label that is visible to screen-readers but not shown on-screen. This is best done by creating a CSS class for 'screen-readers-only' and applying that to the label.

Here is the HTML:

			
<label for="add_country" class="screen-reader-only">Select Your Country</label>
<select id="add_country" name="add_country" onchange="this.form.submit()">
	<option class="country-placeholder" selected disabled> -- Select your country -- </option>
	<option class="country-option" value="1">Country 1</option>
	<option class="country-option" value="1">Country 1</option>
</select>
			
		

When creating the CSS class it is important not to use 'display: none' or 'visibility: hidden' because screen-readers skip content that is hidden like this.

Instead we positioned the content off-screen. This is the CSS:

			
.screen-readers-only {
	position: absolute !important;
	top: -1000px !important;
	left: -1000px !important;
}
			
		

Aria Labels For Image Links

The error: "Links do not have a discernible name".

Sometimes images are used as links - a common example is a logo that links to the home page of a website.

This poses a problem for screen-reader users as they cannot see the image and no text is in place.

The solution is to add an 'Aria Label' which describes the landing page:

			
<a aria-label="Home" href="index.php">
	<img src="images/downtime-monkey-logo-white.png" alt="downtime monkey logo">
</a>
			
		

Titles For iframes

The error: "frame or iframe elements do not have a title".

The cause of this error was embedded YouTube videos and it was something that we had missed completely.

Embed code supplied by a YouTube video comes without a title. Unfortunately this means that screen-reader users can't tell what the video is about or even that the iframe contains a video!

This can be rectified by adding a 'title' to the iframe:

			
<iframe src="https://www.youtube.com/embed/-SyWKnrECsc?ecver=1" frameborder="0" gesture="media" allowfullscreen title="Video on how to monitor a website"></iframe>
			
		

Allow Users To Scale The Webpage

The error: "user-scalable='no' is used in the meta name='viewport' element or the maximum-scale attribute is less than 5".

We have spent a lot of time ensuring that the website worked well across all screen-sizes from tiny phones to large widescreens. Part of this was making sure that the text is sized appropriately for the screen that it is shown on.

So it was really annoying when some phones (we're looking at you iphone!) override this, apply their own zoom and muck-up the beautiful text sizing!

To prevent this we had used 'user-scalable=no' so that the correct text sizes were seen on iphones.

Unfortunately a side-effect of this was that everyone was prevented from zooming - so partially-sited users who need larger text would be unable to zoom.

This was easily fixed by removing 'user-scalable=no' from the meta viewport (iphone users will just have to live with slightly less perfect text sizing!):

			
<meta name="viewport" content="width=device-width, initial-scale=1.0">
			
		

Aria Labels For Icon Forms

The error: "Form elements do not have associated labels".

Sometimes when an icon is clicked a form is submitted. A common example is when a 'trash icon' is used to submit a form which deletes something.

This makes for a great user-experience for sighted users but there's no text present for a screen-reader to read.

The solution is to add an 'Aria Label' which describes what happens when the icon is selected. Note that in the following example the 'trash icon' is a Font Awesome icon which is supplied by its Unicode value &#xf1f8;

			
<input type="submit" value="&#xf1f8;" name="delete" class="fa blue" title="delete monitor" aria-label="delete monitor">
			
		

Aria Labels For Icons That Show Important Information

In this case there is no error from web.dev because icons only need to be labelled under certain circumstances.

When an icon is present purely to add style there is no need to add a label. For example, on Downtime Monkey when a user's list of monitors is displayed, every website that is up has a tick icon shown beside the word "UP". No extra information is provided by the icon so there is no need for a label.

However, when an icon provides additional information it is important to use an 'Aria Label' so that a screen-reader can provide the information to its user.

An example, again from the user's list of website monitors, is that the bell icon is shown when email alerts for a specific monitor are turned 'on' and the bell-slash icon is shown when email alerts are turned 'off'.

Here's the code for when a monitor has alerts turned on - again, Font Awesome was used for the icon:

			
<a title="email alerts on" aria-label="email alerts on" class="blue no-underline">email: <i class="fa fa-bell"></i></a>
			
		

Aria Labels For Icon Links

The error: "Links do not have a discernible name".

Sometimes an icon is used as a link. For example, a PDF icon is linked to a receipt document in a user's 'order history' so they can easily view and print their order details.

However, screen-readers need text to provide the context of the link.

Again, adding an 'Aria Label' to the link solves this problem.

			
<a href="invoice-pdfs/325.pdf" aria-label="Receipt 325"><i class="fa fa-file-pdf-o"></i></a>
			
		

Button Roles & Aria Labels for Linked Spans

In this case no error was caught by web.dev, however accessibility improvements were made.

In Downtime Monkey, modals are used as an alternative to dropdown menus because they provide better user experience.

The image below shows the modal that is used to display the 'user menu'.

User menu modal

Note that in the top right corner of the modal there is an 'x' which can be clicked on to close the modal.

This x is a span that acts as a button and this is potentially confusing for screen-reader users as it doesn't provide context for the link.

The solution is to add a 'role' to the link to tell screen-readers that it acts as a 'button' and also to add an 'Aria Label' to describe what the button does:

			
<span id="settings-close" role="button" aria-label="close menu" class="modal-close">×</span>
			
		

High Colour Contrast - Not Implemented

The error: "Background and foreground colors do not have a sufficient contrast ratio".

Low-contrast text can be difficult to read for partially sited users and high-contrast text is recommended to make text easier to read for everyone.

Most of the text on the site passed, but some blue, green and orange text failed.

However, implementing new colours is a big job. Simply upping the contrast of the current colours considerably reduced the user experience for most people. The high contrast text was either really bright (so bright that it hurt) or very dark (dark enough that it made it hard to distinguish between small headings and paragraph text).

It became evident that introducing high-contrast colours would involve redesigning the site. We thought long and hard about this and in the end it was decided that the benefits of keeping the colour scheme outweighed the disadvantages, although we may revisit this in the future when we have more time to spend on redesign.

Step 3: Re-run The Test

Running the test after making the changes provides a check to ensure that fixes have been applied correctly.

You should also see the accessibility score improve and congratulate yourself on a job well done :)

Accessibility Score 90%
 

15 Nov 2018

...for Office365 and 'Outlook for the web'.

In a previous blog post we answered the question: Why Whitelist an Email Address?

TLDR; "If you expect to receive important emails from a trusted email address it is worth whitelisting the address to make sure that emails won't be accidentally blocked by an overzealous email client."

Here we provide step-by-step instructions on how to do it in Outlook for Office365 by adding the email address to your safe senders list...

1) Check that you are using the web version of Outlook.

Outlook has had a lot of different versions over the years and Microsoft has managed to cause real confusion as to which version is which!

This article refers to the web version of Outlook which is known as 'Outlook on the web' as well as 'Office365 Outlook' and 'Outlook for Exchange Server'. Older versions were formerly know as 'Outlook Web App (OWA)', 'Outlook Web Access' and 'Exchange Web Connect'... we're not joking.

If the top left of the webpage that you are looking at is similar to the screenshot below, you are in the right place:

Office365 Outlook


2) Select settings by clicking on the gear icon:

Office365 Outlook Settings

3) Scroll down and select "Mail":

Office365 Mail Settings


4) Select "Block or Allow" from the Options menu, under Mail > Accounts:

Office365 Block or Allow


5) Add the email address that you want to whitelist to the 'Safe Senders and Recipients' field and click the '+' button. Here we have added monitor@downtimemonkey.com to make sure that a website downtime alert email is never missed:

Office365 Outlook create safe sender


6) The whitelisted email address will appear in your Safe Senders list:

Office365 Outlook safe sender added


7) When you click away from the page you'll be prompted to save your settings:

Office365 Outlook save changes


Whitelisting A Whole Domain

In 'Step 5' a single email address was whitelisted. It's also possible to whitelist all emails associated with a domain.

By adding downtimemonkey.com to the Safe Sender field instead of monitor@downtimemonkey.com we would whitelist every email address belonging to downtimemonkey.com.

 

08 Nov 2018

In the last blog post we answered the question: Why Whitelist an Email Address?

TLDR; "If you expect to receive important emails from a trusted email address it is worth whitelisting the address to make sure that emails won't be accidentally blocked by an overzealous email client."

Here we provide step-by-step instructions on how to do it in Gmail by creating a filter:

1) Login to Gmail, click on the gear icon and select "Settings":

select Gmail settings


2) Select "Filters and blocked addresses":

select Gmail filters

3) Scroll past all your existing filters and select "Create a new filter":

create new filter Gmail


4) Add the email address that you want to whitelist to the "From" field. Here we added monitor@downtimemonkey.com to make sure that we never miss a 'website down' alert:

add email to filter Gmail


5) Check the "Never send to spam" box and click "Create Filter". The email address will now be whitelisted!

create filter Gmail


Whitelisting A Whole Domain

In 'Step 4' we whitelisted a single email address. It's also possible to whitelist all emails from a domain.

By adding @downtimemonkey.com to the "From" field instead of monitor@downtimemonkey.com we would whitelist every email address belonging to downtimemonkey.com.

Whitelisting Multiple Email Addresses

To whitelist more than one email address simply add each email address separated by the pipe symbol. For example, "monitor@downtimemonkey.com | verify@downtimemonkey.com".

The pipe symbol is a vertical bar '|' that can be added with shift and backslash on most keyboards.

 

31 Oct 2018

TLDR; "If you expect to receive important emails from a trusted email address it is worth whitelisting the address to make sure that emails won't be accidentally blocked by an overzealous email client."

Whatever email client you use, be it Gmail or Thunderbird, Outlook or Apple Mail, you can be sure that it comes with some kind of spam management built in.

Most of the time this works well - legitimate emails are delivered to your inbox and spam is either rejected or gets funnelled to your spambox.

whitelisting an email address


However, differentiating between genuine emails and spam is a notoriously difficult problem to automate and despite utilising sophisticated artificial intelligence, email clients intermittently fail to do this successfully.

This means you will occasionally see spam emails make it through to your inbox, or worse... legitimate emails may be incorrectly blocked and you miss them!

Whitelisting Prevents Overzealous Blocking

If you expect to receive important emails from a trusted email address it is worth whitelisting the address to make sure that emails won't be accidentally blocked by an overzealous email client.

You can do this for monitor@downtimemonkey.com to be 100% sure that you'll receive your email alerts if a website that you monitor goes down.

It's very unlikely that these emails would be blocked (we've never had problems) but whitelisting is straightforward and gives peace of mind.

How To Whitelist An Email Address

Whitelisting is completed in the email client and each email client is different.

So far we've written posts that give step-by-step instructions (including screenshots) on how to whitelist email addresses in Gmail, Outlook for Office365 and Yahoo! Mail.

 

26 Sep 2018

One of our main aims when developing Downtime Monkey is to make the user experience outstanding.

With that in mind we've rolled out an improvement to the user interface that enables you to view the current status of all your websites at a glance.

Here's a screenshot of the new 'overview box' - this is now the first thing you'll see when you view your monitors:

website monitoring user interface


Down Websites Listed First

Every website monitor is still listed individually. Individual monitors now appear just below the 'overview box' and can be easily scrolled through.

We've also made a small change to the list of monitors - previously all monitors were listed in alphabetical order but now websites that are down are shown first:

website monitor list


Who Benefits?

These changes should benefit users who monitor lots of websites because they can quickly find any websites that are down without having to scroll through a long list of monitors.

Since Free Plan users can monitor up to 60 websites, Pro Plan users can monitor up to 1000 sites and Enterprise users have unlimited monitors, this could benefit everyone and we've rolled it out across the board.

To check out the new user experience simply sign up, add some websites to monitor and view your monitors. It takes less than 2 minutes!

 

28 Aug 2018

Over the last few months we've made several upgrades for Pro users, including: bulk import of monitors and customisable alert times.

This time, we have an upgrade for our Free Plan users...

free email support


Feedback and FAQs

Until today email support was for Pro customers only.

Free account holders could provide feedback, report problems or ask questions via our online feedback form but didn't have access to email support.

When a good question was asked - we'd add it to our list of FAQs which can be viewed by anyone who is logged in.

Email Support For All Users

In reality though, every time a Free account holder asked a question through the feedback form we emailed them right back... it just seemed like the right thing to do.

With this in mind we're now officially providing email support to Free customers as well as Pro users.

To contact support, simply sign-up and visit help and support. Email us at the address provided and we'll get right back to you.

 

26 Jul 2018

...as opposed to just slow?

When you visit a webpage that is down, most of the time you'll see an error: you'd see a 404 error if the page can't be found or a 503 if the server isn't unavailable.

Although this is not what you want to see, it is helpful. You know that the site is down and have a rough idea why.

But sometimes you don't see an error... just a spinning wheel.

You may wait for 5 seconds, or 20 seconds, or a minute but at some point if the webpage doesn't appear, you'll decide that the site is not just slow, but down.

snail saying 'when is website down or slow'


Timeout Threshold

Downtime Monkey's monitoring scripts go through the same decision-making process.

If a server is running so slowly that it doesn't respond, at some point we have to call time and mark the site down.

The question is: "How long should we wait?"

Experimenting With Timeout Threshold

Over the past few months we have been varying the timeout threshold.

We've used various times betweeen 9 seconds and 30 seconds and examined the effect the changes have had on the efficiency and run-times of our monitoring scripts.

The aim was to find the timeout setting that allowed our monitoring scripts to run most efficiently and quickly, and set timeouts to this value.



Speed & Efficiency

We found that the monitoring scripts were quickest and most efficient when the timeout setting was lowest - this isn't surpising really but it forced us to re-think our approach.

If we dropped the timeout setting further the scripts would run faster still - in theory we could set timeouts to 1 millisecond and the monitoring scripts would be super fast. However, websites would constantly be marked as down when they didn't respond in time.

Obviously, it is unreasonable to expect a website response within a millisecond - but this poses the question: "What is a reasonable timeout setting?"

New Approach

Instead of choosing the timeout threshold that lets our monitoring scripts run fastest, we decided to use the value that is most widely considered appropriate.

So we set up a survey asking: "How long without a website response before you consider the site down, as opposed to just slow?"

The options for answering were: 5 seconds, 10 seconds, 20 seconds, 30 seconds and 1 minute.

Google+ was chosen because of the high response rate to polls.

We polled 9 Google+ communities (details here) with specific communities being selected because of the appropriate knowledge of the community members and their enthusiasm for past polls.

Thanks to everyone who took part!

Survey Results

Here are the full results from all polls combined:

Total Votes:

971

5 sec:

23.58%

10 sec:

43.46%

20 sec:

13.39%

30 sec

10.50%

1 min

9.06%

Mode Timeout

10 sec

Mean Timeout

17 sec

website down or slow results

Mode and Mean

The most popular choice (the mode) was 10 seconds.

The average time (the mean), taking all votes into consideration, was 17 seconds.

It's noteworthy that 10 seconds was the most popular choice by a considerable margin and that this result was repeated across all individual polls: in every community 10 seconds was the most popular choice.

The distibution of votes was also very consistent across the individual polls - we were surprised at how reproduceable the results were. In every poll the mean time was between 16 and 19 seconds.

You can see results from each individual poll towards the end of the post.

Putting The Results Into Practice

We have now set the timeout threshold on all our monitoring scripts to 17 seconds, the mean choice of all votes.

It's true that our scripts would run slightly faster if we used a lower timeout but we believe that this is the most appropriate timeout setting for our users, based on the opinions of the tech/developer/designer community.

sloth talking about slow website


What Happens After A Monitor Times Out?

When a monitor passes the timeout threshold without a response, the site is marked as down and the event is recorded with a response code of 0.

Stats for the monitor are automatically updated to take the downtime into consideration.

Pro users can view all individual timeouts, and will see the explanation: "No Response: No HTTP code was received. Possible reasons for this are timeout (the server is not responding in time) or being blocked by a firewall."

SMS and email alerts will be sent if the site remains down for the time specified by the user in their alert settings.

Free users receive SMS alerts instantly and email alerts if the site stays down for one minute. Pro users can set their own custom alert times.

Results From Specific Polls

Programming

Number of Votes:

283

Mean Timeout:

16 seconds

programming website down or slow results

PHP Programmers

Number of Votes:

156

Mean Timeout:

16 seconds

PHP programmers website down or slow results

Computer Science

Number of Votes:

136

Mean Timeout:

17 seconds

computer science website down or slow results

Web Development

Number of Votes:

98

Mean Timeout:

18 seconds

web development website down or slow results

Computer Programmers

Number of Votes:

78

Mean Timeout:

16 seconds

 computer programmers website down or slow results

Cloud Computing

Number of Votes:

74

Mean Timeout:

16 seconds

cloud computing website down or slow results

Web Design

Number of Votes:

62

Mean Timeout:

16 seconds

web design website down or slow results

Web Designers

Number of Votes:

50

Mean Timeout:

17 seconds

web designers website down or slow results

Web Design & Development

Number of Votes:

34

Mean Timeout:

17 seconds

web designers website down or slow results
 

Defining Response Time

You may already have asked: "How is response time evaluated?" Good Question.


'Response Time' is not 'Page Load Time'

It's important not to confuse response time with page load time when considering the question: "How long without a website response before you consider the site down?"

Response time is always much quicker than page load time - read on to see why...


What happens when you visit a webpage

When you visit a website your computer sends a request to the web server, asking for the webpage data.

The server sends a response, which includes a status line, HTTP headers and webpage content.

The first thing that is received by your computer is the status line - this is just one line and contains only a few bytes of data. It tells your computer whether the request was successful or not.

Next, your computer receives the HTTP headers which contain details about the webpage - these are several lines long and typical headers size is 700-800 bytes (although they can be anything from 200 bytes to over 2KB).

Finally, your computer receives the webpage content - the data size varies considerably depending on the webpage but is usually in the megabytes. In 2017 the average webpage size was 3.034MB - that's over 3 million bytes!


Time To First Byte

Time to first byte (TTFB) is the time taken to receive the first byte of data of the status line (technical details here).

TTFB is sometimes used for response time. However, we don't think this is accurate because it's not the same as "the time of the first data byte of the page" appearing in the web browser.


Page Load Time

Page load time is "the time it takes to download and display the entire content of a web page in the browser window".

This is irrelevant to response time because content-heavy web pages can take a long time (sometimes minutes!) to fully load.


Time To Receive Headers

We consider the time taken to receive headers is the most practical measure of reponse time - headers are received just before the first content is loaded to the web browser. This is used to record response time in our monitoring scripts.