How to Measure Website Performance
Measuring Website Speed - Marketing Versus IT
IT is traditionally responsible for making sure a website loads efficiently in users browsers. However, the business metrics affected by website speed are all marketing related.
Faster websites deliver:
• Improvements in SEO rankings
• Increased onsite conversion rates
• Reduced bounce rates
• Increased page views per browser session; and
• Increase customer satisfaction and repeat visit rates.
As well as understanding the movement of these vital digital business indicators, marketers should also understand movements in website speed and the impact it has on these metrics.
How Should We Measure Website Speed?
When you want to understand how your website is performing, there are two ways you can approach the problem;
1. Fire synthetic browse tests at your website; or
2. Monitor and measure the speed of the pages downloaded by your users (Real User Monitoring orRUM).
Both of these methods have some benefits and some shortcomings in so far as they help marketers understand the performance of their website.
Synthetic testing is a quick and easy way to produce a website performance metric. However, the metric may not be correct.
Synthetic website testing involves setting up browsers or emulated browsers to make requests against your website for specific pages at regular intervals (say every 5, 15 or 30 minutes). Some providers of synthetic testing will allow you to set up multiple pages in a browse sequence and even enter login information, search parameters or product selection. With these multi step tests you can synthetically test the login and checkout process.
There are lots of providers of synthetic browse tests available in the market today and setting up the tests are both quick and cost effective. Examples are; Pingdom, Site 24x7, Site Confidence, Watchmouse, Website Pulse and the free WebPageTest among many others.
The limitations of Synthetic website tests arise because, by their nature, synthetic tests are not your users. Your users will be a widely diverse mix of users, on a range of different devices, operating systems, browser types, bandwidth connections, geographic locations and internet service providers. Trying to replicate this using synthetic testing is neither practical nor cost effective.
While some synthetic test offerings do run real browsers and others provide levers to adjust the browser type or bandwidth, it still cant be truly representative of all of your users.
So if synthetic tests can only provide an indication of performance for a particular user browsing a discreet set of pages, in what ways are they useful?
• Firstly, the top benefit of Synthetics is to let you know when your website is not responding. Pinging your site with a Synthetic test is a great way to know if a page (or a transaction) is not responding or failing to properly execute.
• Synthetic tests can also provide a benchmark to monitor the performance of that specific set of pages for a specific user over time; with the benefit of consistency.
• Finally, if the synthetic transactions are run using a real (or a well emulated) browser and the test downloads the whole page (rather than just the HTML), synthetic tests can provide you with some insight into what may be taking up time when your pages are delivered to a browser. In other words, Synthetic tests can be a helpful diagnostic tool for the IT team to help you focus your web performance spend.
While the above benefits are all valid, they are limited (as noted above) by the fact that the results you are gathering and analysing are not for real users of your website; no matter how real the real browser monitor is.
Real User Monitoring (RUM)
When you want to understand your website performance, the best way has to be to understand the performance for your users; the real ones.
Websites do have different user bases and these can often have different browsing characteristics so you need to understand whether your web pages are performing in your users browsers at the time when they are browsing. RUM works by inserting a piece of Java Script into every web page served for your website. This is not as simple as setting up Synthetic tests as it will generally involve a tech team to deploy the Java Script file. When that Java Script runs on the users computers, the users browsers send back information relating to the users and the pages download. Metrics (including page speed) are sent to a data collection point. This data is then made available to you in a portal. Google Analytics is an example of Real User Monitoring.
This sounds pretty good but of course there are some limitations;
• Not all browsers support the data gathering requirements of all of the Real User Monitors so you wont necessarily have a 100% complete picture of the performance of your website for all users. This problem is diminishing as the percentage of older browsers diminishes.
• Most real user monitors available today are not particularly good at providing you with information to help diagnose the cause of page performance issues.
Taking up the second of these points, RUM available today measures in fairly broad chunks. For example;
1. The time it takes to generate the page at your servers,
2. The time it takes to make a network connection; and then
3. The time it takes to download and render in the browser, all of the items which have come from both your servers and third party servers (like Facebook, Ad Servers or Google Fonts) which may send content to make up the web page.
Across the top 50,000 websites in the world, 80-90% of the time to render a page in a browser is in that third chunk. Thats the chunk of time we need to know more about in order to really focus our web performance efforts.
Synthetic tests provide us with the information we need about that big relevant chunk of time but dont provide information for all users. Real User Monitoring provides information about all users but no detail on the main period of the page load time. Introducing Real User Page Insight Monitoring.
Real User Page Insight Monitoring (RUPI)
A part of the Section team tool kit, RUPI gathers page load and performance metrics for modern browsers.
RUPI provides a deep level of insight into the reasons for page performance as experienced by your real users. RUPI gives you a breakdown for your users of the reasons for their page load times. This allows you to analyse the results and make informed decisions on web performance actions.
For example, a Section customer was watching their page performance in Google Analytics and was in despair about the average page load time presented. When confronted with the Median and 95th percentile scores, we were able to establish that there was a very long tail of slow loading pages for a smaller number of users. RUPI told us that the page load times were related to image files being downloaded and that these users were on very low bandwidth connections (56k) in markets not of interest to the customer. The action to take as a result? Do nothing. In this instance, it was not affecting their business and time was better spent focussing on reducing the median page performance metric rather than the mean.
Often, viewing this level of detail can provide a long list of clear action points you can tackle to improve the page performance for your users. More importantly, it can provide assistance with prioritisation of that list as you can identify the most important page performance items for your most important users.
Marketers and IT teams should monitor and measure the performance of their website. It should know what is slowing down a website and what to do to fix it. Marketing should be watching for website performance changes and all the benefits page speed can deliver. Marketing should insist on understanding the Real User page performance indicators.
Real User Page Insight Monitoring provides all the benefits of traditional Real User Monitoring with the added benefits of being the best website performance diagnosis tool. It is the right way to measure and monitor your websites performance for your users. That is not to say that your synthetic monitoring should be abandoned as it is still the king when it comes to website uptime monitoring.