A while back, some friends at Akamai approached me about making an animated video about performance monitoring. I had a lot of fun doing it, and now I’m excited to announce that the video is ready for viewing.
My goal was to help people understand the history of performance monitoring, as well as give a layperson-friendly overview of how Navigation Timing, Resource Timing and User Timing work. I hope you find it helpful! (And if you’re more of a reader than a watcher, scroll past the video for a text version of what I covered.)
A brief history of performance monitoring
Getting an accurate measurement for how long it took a web page to load used to be difficult and somewhat imperfect. In the olden days — you know, 2005 — if you built a website, you had zero ability to look outside your own datacenters to get an understanding of its performance.
As websites evolved, the digital experiences we were able to serve over the web became more and more complex. Images, video and other rich content added more and more delay, which ultimately hurt the user’s experience.
Unfortunately, in the past, none of this could be captured with simple back-end measurements.
This lack of visibility into the user experience drove website owners to look at different ways of measuring performance. This yielded advanced measurement capabilities like synthetic monitoring and, later, real user monitoring, also called RUM.
Finally, with these tools, site owners could see beyond the walls of their organization to get a real sense of how their applications were performing in the wild.
Today’s browsers offer the ability to capture even more detail around performance
Navigation Timing provides an interface for web applications to capture detailed timing information for your web pages.
Confronted with all of this data around client-side performance, site owners today face a very different set of problems. What is the right metric? Which one should I use?
Whereas site owners were once faced with a limited set of data, which was often of questionable quality, today they struggle to make sense of a virtual firehose of information.
This is where today’s performance analysts come in, taking a brand-new approach.
The myth of the single perfect metric
All of these metrics — Navigation Timing, Resource Timing, and so on — serve a great purpose, depending on the answers you seek.
Depending on your role, the questions you ask will vary:
- If you’re in network operations, you may ask “How long does it take to get a response back from my servers?” The metric you care about is TCP/Connection Time.
- If you’re a developer, you might want to know how much time is spent serving the base HTML versus the remaining assets and resources on the page. To find out, you’ll need to compare your front-end time to your back-end time.
- If you’re in marketing, you may wish to ask “How much time is this third-party content adding to the page?” You need to track Resource Timing for each third-party script.
- If you’re a CEO, your most important question could be “How does my site stack up to the competition?” For that information, you’ll look to your site’s Speed Index score.
- And a much wider audience circles around the question: “What does the user perceive?” and “How fast does our site feel to our customers?”
If your organization spends cycle after cycle improving the user experience, you need a way to measure and benchmark that shows the fruits of your labor. Oftentimes when standardizing on a traditional metric of page load — which is based on when the load event fires on the page — we are unable to see and capture the significant impact our front-end optimizations have on the perceived speed of the page.
Fear no more! User Timing to the rescue!
By taking advantage of modern browser technology, we are now able to create our own definition of the user experience. After all, who knows your web application better than you?
The User Timing interface was introduced to give you the ability to set performance marks at key points in the loading of your page. Through the use of this interface, you can now simply place marks at key points in your application. These marks will monitor and track what you truly want to understand. Whether that is above-the-fold time for your product images or a combination of assets that are needed before you can call the page ‘done’, leveraging this interface is a great way to get there.
Start simple, by implementing basic metrics centered around user perception, such as measuring how long it takes to display the main navigation on your page or how long it took to load a product image. As you become more familiar and focused, you can extend User Timing to measure more complex use cases for your site, such as above-the-fold time or the load time for a set of critical assets.
Fortunately, mPulse provides first-class integration for User Timing out of the box. Other tools such as SpeedCurve (via WebPagetest) do as well. This makes it easy to start collecting these metrics today!
Welcome to the brave new world of end user performance monitoring. As you move through this journey, don’t be intimidated by the mountain of metrics before you. Three things to keep in mind as you move forward:
- Think about the specific questions you want answers for and who will be consuming this information.
- Evaluate your options and choose a metric, or set of metrics, that best are a best fit.
- Be open to experimentation as you move through the journey. The best insights often come after a number of iterations.
My fellow SOASTAN Nic Jansma has written an awesome set of posts that explain all three timings in great detail:
About the Author
Cliff Crocker is VP of Product for SOASTA, Inc. where he focuses on performance monitoring of web and mobile applications. Prior to joining SOASTA, Cliff led the performance, reliability and site analytics initiatives for @WalmartLabs. Cliff is an active participant in the web performance community, evangelizing the importance of correlating performance metrics with business intelligence to drive development efforts within eCommerce.