Traditional nav timing metrics have given us a lot in the way of understanding how our pages and apps are performing, but as users’ expectations rise and page complexity grows, you need to really understand how users are perceiving the performance of your website beyond traditional page load timing. The goal of the new perceived performance metrics is to capture other important aspects of your visitor’s overall experience during page load and beyond.
We’ve all had the experience of seeing a page load and looking at a perfectly rendered button, only to click it and have nothing happen. Then we always follow up with the rapid-fire “rage click” just to double check it’s not really working. Understanding when your page is visually ready — when it’s actually interactive and when your users first try to interact with the page — is imperative to creating that “delightful” user experience we all strive for.
As part of the Spring 2018 release, the new perceived performance metrics in mPulse give you a better understanding of when your site is actually ready for use, when users believe your site is ready, and when they interact with it. This gives you a better understanding of how users are interacting with your app so you may correlate those behaviors to user sentiment, and ultimately with desirable or undesirable outcomes.
Perceived Performance Metrics
Time to Visually Ready: When did the user feel like they could interact with the site? When did it look ready?
Time to Interactive: After the page was Visually Ready, when was the first time the user could have interacted with the site, and had a good (performant) experience?
Time to First Interaction: When was the first time the user tried to interact (key, click, or scroll) with the site?
“This all sounds fantastic,” you say, “but how are you actually capturing these new metrics?”
Below are details on how Visually Ready (VR) and Time to Interactive (TTI) are calculated.
To calculate Time to Interactive, we need to figure out two things:
Does the page appear to the visitor to be interactable?
We’ll use one or more Visually Ready signals to determine this
If so, what’s the first time a user could interact with the page and have a good experience?
We’ll use several Time to Interactive signals to determine this
For the first question — “Does the page appear to be interactable?” — we need to determine when the page would look to the user like they could interact with it.
It’s only after this point that TTI could happen. Think of Visually Ready as the anchor point of TTI — it’s the earliest possible timestamp in the page’s lifecycle that TTI could happen.
We have a few signals that might be appropriate to use as Visually Ready:
First Paint (if available)
We should wait at least for the first paint on the page, i.e., IE’s msFirstPaint or Chrome’s firstPaintTime
These might just be paints of white, so they’re not the only signal we should use
“The DOMContentLoaded event is fired when the initial HTML document has been completely loaded and parsed, without waiting for stylesheets, images, and subframes to finish loading”
This happens after domInteractive
Available in NavTiming browsers via a timestamp and all other browsers if we’re on the page in time to listen for readyState change events
Hero Images (if defined)
Instead of tracking all above-the-fold images, it could be useful to know which specific images are important to the site owner
Defined via a simple CSS selector (e.g., .hero-images)
Can be measured via ResourceTiming
“My Framework is Ready” (if defined)
A catch-all for other things that we can’t automatically track
This would be an event or callback from the page author saying their page is ready
They could fire this for whatever is important to them, e.g., when their page’s click handlers have all registered
Once the last of all of the above have happened, Visually Ready has occurred.
Time to Interactive
After the page is Visually Ready for the user, if they were to try to interact with the page (key, click, scroll), when would they have a good experience (i.e., the page responded in a satisfactory amount of time)?
We can use some of the signals below, when available:
Available in all modern browsers: By using requestAnimationFrame we can get a sense of the overall framerate (FPS)
To ensure a “smooth” page load experience, ideally the page should never drop below 20 FPS
20 FPS gives about 50ms of activity to block the main thread at any one time
Great indicator that the page would not have been interactable and in some cases, attribution as to why
Only available in Chrome
Page Busy via setTimeout or requestIdleCallback polling
By measuring how long it takes for a regularly scheduled callback to fire, we can detect other tasks that got in the way
Can give an estimate for Page Busy Percentage (%)
Available in every browser
Putting these two together, here’s how we measure Visually Ready and Time to Interactive:
Determine the highest Visually Ready timestamp (VRTS):
First Paint (if available)
Hero Images are loaded (if configured)
Framework Ready (if configured)
After VRTS, calculate Time to Interactive by finding the first period of 500ms where all of the following are true:
There were no LongTasks
The FPS was always above 20 (if available)
Page Busy was less than 10% (if the above aren’t available)
How users perceive their experience on your site is everything. Your goal is to never frustrate your users, so ensure that your site is both visually ready and interactive using these new metrics from mPulse. Whether they’re searching for something, buying something, clicking on a story, or trying to update a status, you want them to be able to achieve their goal as quickly as possible — which ultimately translates to longer sessions, return visits, and a bigger bottom line for you.
To read more about measuring what matters and all the new capabilities in mPulse, check out these related posts:
- mPulse: Measure What Matters — New Metrics to Improve User Experiences
- What’s Inside Matters — Page Construction Metrics
- How You Get There Matters — Middle-mile Visibility to Drive CDN Strategy
This is a Security Bloggers Network syndicated blog post authored by Lauren Younger. Read the original post at: The Akamai Blog