mPulse Feature Release - Metrics 2024

By Tsvetan Stoychev + Nic Jansma on

Tsvetan Stoychev
Nic Jansma

Table of Contents

The mPulse team is happy to announce the addition of 6 new system timers and 5 new system dimensions that are enabled for all mPulse applications.

These new timers and dimensions give mPulse customers additional ways of measuring the performance of their web applications:

New Front-End Timers:

New Back-End Timers:

New Dimensions:

All of these timers and dimensions are available in both the Legacy and New mPulse UIs.

Why are we adding new timers and dimensions to mPulse?

As web performance measurement continues to evolve, our customers are always experimenting with new ways of measuring their web applications.

One area our performance experts have focused in on is reducing the amount of noise in RUM metrics.

To combat noisy metrics, we have added 6 new mPulse system timers that offer finer-grained measurement of RUM data:

  • 4x new Front-End timers (FCP-FE, LCP-FE, TTVR-FE and TTI-FE) that exclude Back-End Time (TTFB) from the front-end components.
  • Time to Request (TTR) is similar to Back-End Time (TTFB) but excludes the server's Waiting Time (so navigationStart through requestStart instead of responseStart).
  • Unattributed Navigation Overhead (UNO) accumulates all of the "unknown" and "extra" time-spans of a navigation that aren't accounted for in other timers. This may include browser delays, disk access times, hidden time from cross-origin restrictions, etc.

For example, new timers like Largest Contentful Paint (Front-End) simply subtract Back-End Time (TTFB) from the measured result. This timer is a companion of LCP, focused on just the performance of the front-end as it relates to LCP. Removing the "noise" of back-end time from the measurement can help front-end teams focus on the part of the navigation timeline that they are in control of.

New mPulse Front-End Timers

(Note: Timers like Largest Contentful Paint (Front-End) and Back-End Time (TTFB) have different sample sets so in aggregate they won't add up to Largest Contentful Paint)

In the past, our customers have implemented many of these measurements as Custom Timers in mPulse; today they are available for all mPulse applications without needing to use a Custom slot.

All of the existing timers (like vanilla LCP) will remain; the four new * (Front-End) timers supplement those existing timers and mPulse customers can choose the ones they want to focus on.

In addition to the new timers, we have added the 5 new system dimensions that give customers the ability to slice and dice their data in different ways.

New mPulse Dimensions

For example, Page CDN Cache Status gives customers the ability to split their performance data by whether the page was a HIT, MISS or REVALIDATE on the CDN. Device Memory helps you understand the capabilities of the devices that are visiting your site. Since Device Memory seems well-correlated with new metrics like INP, it's useful to track this separately. The new BFCache Navigation and BFCache Not Restored Reason dimensions help measure BFCache navs, which are crucial for optimal performance. There are many reasons why browsers can decide a site is not eligible for BFCache, and giving these insights into your visitors' usage of BFCache in the wild can help find and fix these issues.

In the theme of reducing noise, you may wish to exclude or include subsets of your measurements based on these new Dimensions.

For more details on all of the new timers and dimensions, please read the descriptions below.

New Front-End Timers

The four new (Front-End) timers are companions to the existing timers, subtracting out Back-End Time (TTFB):

Front-End Timers

First Contentful Paint (Front-End) (FCP-FE)

First Contentful Paint (Front-End) (aka FCP-FE) is a new user experience timer that is a companion to the First Contentful Paint (aka FCP) timer.

It differs from FCP in that Back-End Time (TTFB) is subtracted from FCP-FE:

First Contentful Paint (Front-End) = First Contentful Paint - Back-End Time

FCP and FCP-FE Diagram

Why offer a new timer FCP-FE when we already have FCP?

Google suggests a list of more than 10 techniques to improve First Contentful Paint, including:

  • Eliminate render-blocking resources
  • Minify CSS
  • Reduce server response times (TTFB)
  • Avoid an excessive DOM size
  • etc.

Similarly, we have found cases in the mPulse data where:

  • Back-End Time (TTFB) was the main contributor for slow FCP and it made sense for the server time to be optimized.
  • Back-End Time (TTFB) had almost no impact on the FCP and it made sense to apply front-end optimization techniques such as Eliminate render-blocking resources, Minify CSS etc.

Depending on the situation (the website, the page group, what team is monitoring the metrics) you may want to focus on the front-end or back-end components of FCP. FCP-FE tracks FCP without the noise of the Back-End Time (TTFB) phase.

Largest Contentful Paint (Front-End) (LCP-FE)

Largest Contentful Paint (Front-End) (aka LCP-FE) is a new user experience timer that is a companion to the Largest Contentful Paint (aka LCP) timer.

It differs from LCP in that Back-End Time (TTFB) is subtracted from LCP-FE:

Largest Contentful Paint (Front-End) = Largest Contentful Paint - Back-End Time

LCP and LCP-FE Diagram

Why offer a new timer LCP-FE when we already have LCP?

Similar to FCP-FE, LCP-FE offers a slightly different view of LCP without the noise of the back-end.

A web.dev article for Largest Contentful Paint discusses the key components for how the metric is calculated:

Key Point: LCP includes any unload time from the previous page, connection setup time, redirect time, and Back-End Time (TTFB), which can all be significant when measured in the field and can lead to differences between field and lab measurements.

In other words, Back-End Time (TTFB) could contribute to a higher LCP if there is significant back-end and network overhead.

The web.dev article also mentions:

LCP reports the render time of the largest image or text block visible in the viewport, relative to when the user first navigated to the page.

When we are optimizing LCP, we often focus on speeding up the delivery of the largest image or text block by implementing techniques as:

  • Eliminate render-blocking resources
  • Reduce server response times (TTFB)
  • Use a CDN for delivering images
  • etc.

Depending on the particular case, it's possible that the main contributor for a high LCP is Back-End Time (TTFB).

With the help of the Largest Contentful Paint (Front-End) timer we can easily identify whether the back-end is the main contributor to LCP or not. This can help a developer decide where to focus their optimization efforts.

Time to Visually Ready (Front-End) (TTVR-FE)

Time to Visually Ready (Front-End) (aka TTVR-FE) is a new user experience timer that is a companion to the Time to Visually Ready (aka TTVR) timer.

It differs from TTVR in that Back-End Time (TTFB) is subtracted from TTVR-FE:

Time to Visually Ready (Front-End) = Time to Visually Ready - Back-End Time

TTVR and TTVR-FE Diagram

Why offer a new timer TTVR-FE when we already have TTVR?

The Time to Visually Ready (TTVR) timer marks the time when a page looks ready to be used by a visitor, based on a few signals:

  • First Paint (if available)
  • First Contentful Paint (if available)
  • Largest Contentful Paint (if available)
  • DOMContentLoaded event
  • Hero image loaded (if defined and if available)
  • A front-end framework is ready (if defined)

TTVR is calculated by picking the highest value of all the signals listed above. For more details, see the boomerang.js documentation.

The goal of TTVR-FE is to give an alternative view of TTVR without the noise of the back-end.

Time to Interactive (Front-End) (TTI-FE)

Time to Interactive (Front-End) (aka TTI-FE) is a new user experience timer that is a companion to the Time to Interactive (aka TTI) timer.

It differs from TTI in that Back-End Time (TTFB) is subtracted from TTI-FE:

Time to Interactive (Front-End) = Time to Interactive - Back-End Time

TTI and TTI-FE Diagram

Why offer a new timer TTI-FE when we already have TTI?

The Time to Interactive (TTI) timer marks the time when the page looks ready to use and is responsive to user input, based on a few signals:

  • Frame Rate (FPS)
  • Long Tasks
  • Delayed interactions

For more details on how TTI is calculated, you can review the boomerang.js documentation.

The goal of TTI-FE is to give an alternative view of TTI without the noise of the back-end.

New Back-End Timers

We are introducing two new back-end timers to break down the phases of Back-End Time (TTFB) even further.

Time to Request (TTR)

Time to Request (TTR) is similar to the Back-End Time (TTFB) timer in that it focuses entirely on the back-end parts of a navigation prior to when the browser parses the server's response.

TTR differs from Back-End Time (TTFB) in that it excludes any Waiting Time (on the server's response):

Time to Request (TTR) = Request Start - Navigation Start

Time to Request

In other words, Time to Request (TTR) focuses on the phases of a navigation prior to the HTTP request:

  • Unload (previous page)
  • Redirects
  • Service Worker Initialization
  • Browser Cache
  • DNS Lookup
  • TCP Connection
  • TLS Handshake

These early navigation phases are often complex to optimize and may require the help of network engineers or a Content Delivery Network (CDN).

Troubleshooting slow Back-End Time (TTFB) can be hard, but reviewing the Time to Request (TTR) data can help developers understand where slow-downs are coming from.

For example:

  • When TTFB is high and TTR is low, optimization efforts should be focused on the server's response generation times (Waiting Time)
  • When TTR makes up a majority of the TTFB, optimizations efforts should be focused on whatever phase is causing the most delay:
    • Previous page unload handler is blocking?
    • Too many redirects?
    • DNS not optimized?
    • etc.

Unattributed Navigation Overhead (UNO)

Unattributed Navigation Overhead (UNO) is a new system timer that is a grab-bag of all "unexplained" or "unmeasured" or "unattributed" portions of a navigation.

UNO is the sum of these four phases "in between" other well known phases like DNS and TCP:

  • (redirectStart - navigationStart)
  • (connectStart - domainLookupEnd)
  • (requestStart - connectEnd)

Unattributed Navigation Overhead

Unattributed Navigation Overhead (UNO) can reveal any hidden browser overhead that gets attributed to the Back-End Time (TTFB) phase.

As an example, here is the UNO for a retail domain:

Unattributed Navigation Overhead Example

While a median 24ms may not be a significant amount of time, on this site it differs by Page Group. In some cases we're seeing a median UNO upwards of 100ms or more.

The culprits are really hard to track down, but may be caused by:

  • Redirects from another domain (inbound marketing or search results)
  • Browser initialization delay, for example on browser launch from a hyperlink in another application
  • Browser overhead when navigating away from complex pages, taking a lot of time to stop and unload the previous page
  • Browser cache delay, for example disks spinning up
  • Browser resource contention with other applications or tasks

These delays are often outside of most developer's controls; measuring these regions in aggregate can give insight into the realistic overhead of the browser.

NOTE: 2024-04-25: The mPulse team has fixed a calculation error where, in some cases, the Unattributed Navigation Overhead (UNO) values were too high. Starting from 2024-04-25, we will display the correct values of Unattributed Navigation Overhead (UNO) in mPulse.

New Dimensions

Page CDN Cache Status

Page CDN Cache Status is a new mPulse dimension that exposes the cache status of the HTML page of the navigation.

This value is populated by inspecting the cdn-cache ServerTiming header for the root HTML page.

When using the Akamai CDN and mPulse Edge Injection, this header is generated automatically. For other environments, a cdn-cache ServerTiming header could be added to HTML's response to populate this dimension.

Page CDN Cache Status will be one of three values:

  • HIT: Cache hit
  • MISS: Cache miss
  • REVALIDATE: A conditional revalidation was needed (e.g. HTTP 304 response from Origin)

For example, when looking at Page Load beacons for a domain hosted on the Akamai CDN, we can clearly see HIT being significantly faster than MISS or REVALIDATE:

Page CDN Cache Status

Page Domain

Page Domain is a new mPulse dimension that simply extracts the domain name from the page's URL (or target domain of XHRs and Fetches).

This dimension is useful for customers that have installed mPulse on multiple top-level domains or sub-domains.

Page Domain

Many mPulse customers have been using a Custom Dimension (based on document.domain) track this data. A Custom slot is no longer needed with this new system dimension.

Device Memory

Device Memory is a new mPulse dimension that reports on the device's approximate memory via the navigator.deviceMemory API (which is currently only supported on Chromium browsers).

Device Memory

Device Memory could be used to focus reports on particular segments of your visitors, i.e. high-end or low-end devices, or to reduce the noise from outliers.

We have found that Device Memory shows a sizeable impact on metrics like Page Load and Interaction to Next Paint (INP).

BFCache Navigation

All modern browsers support Back-Forward Cache (BFCache) navigations, which are a browser optimization that allows faster navigations when the user clicks the Back or Forward button in their browser UI.

This dimension simply reports True or False for whether the navigation was a BFCache navigation or not.

BFCache Timers Example

Websites need to be authored in certain ways to be BFCache-eligible; optimizing for BFCache may require some work.

Compared to regular Back-Forward navigations, BFCache navigations can be significantly faster. As you can see above, Front-End Time, Load Time, FCP and LCP all differ between the two!

BFCache Not Restored Reason

For Back-Forward navigations that are not BFCache eligible (due to incompatibility with the site or browser), the notRestoredReasons API reports on those incompatibilities.

mPulse will capture all of the Not Restored Reasons for non-BFCache Back-Forward navigations. This dimension will report one of those reasons, if more than one reason caused ineligibility. A random reason is chosen:

BFCache Not Restored Reason

NOTE: The notRestoredReasons API requires Chrome 123+ (which is not yet available GA), so most domains won't see any data here yet (unless an Origin Trial is active).

What is needed to take advantage of these new timers and dimensions?

mPulse depends on Boomerang.js, an open-source JavaScript Real-User Monitoring (RUM) library for collecting performance data.

Some of these timers and dimensions depend on a specific version of Boomerang.js (or higher) to collect data. Other timers and dimensions depend on a specific browser version or Akamai CDN support, as noted below:

  • New Timers
    • First Contentful Paint (Front-End) (FCP-FE)
    • Largest Contentful Paint (Front-End) (LCP-FE)
    • Time to Visually Ready (Front-End) (TTVR-FE)
    • Time to Interactive (Front-End) (TTI-FE)
      • Boomerang 1.571+
      • Browser support for LongTasks for best accuracy
    • Unattributed Navigation Overhead (UNO)
    • Time to Request (TTR)
  • New Dimensions
    • Page CDN Cache Status
      • Any version of Boomerang
      • Any browser
      • Akamai CDN with mPulse Edge Injection
    • Page Domain
      • Any version of Boomerang
      • Any browser
    • Device Memory
    • BFCache Navigation
      • Boomerang 1.785+
      • Any browser supporting Back-Forward Cache Navigations
    • BFCache Not Restored Reason

In general, we recommend upgrading to Boomerang 1.792 to get maximum support for the above timers and dimensions.

You can follow the 1.792 upgrade directions here if needed.

Summary

With the large heterogeneity of modern systems and web platform features, tracking down performance problems becomes harder and harder.

Adding new capabilities to mPulse helps manage that (see also our recently released INP support). We hope these new timers and dimensions give mPulse customers the ability to better understand and reduce noise in their RUM data.

All of these new timers and dimensions are available in both the Legacy and New mPulse UIs. In the new mPulse UI, we also have a system dashboard highlighting the new features:

New mPulseUI Release Features - INP Timer, Metrics 2024

New mPulseUI Release Features - INP Timer, Metrics 2024

We are also actively experimenting with metrics such as Long Animation Frames (LoAF), and are testing better ways of measuring browser technologies such as Speculation Rules and Prerendering, Early Hints and more.

Please take a look at the new timers and dimensions and let us know if you're using them. We are always looking for new and interesting ways to measure website performance, and welcome all feedback.

You can do this either via the Contact Us button in mPulse or through your account manager.

← mPulse Feature Release - INP
mPulse Feature Release - LCP Metrics →