Web Performance Calendar

I promise you, UNO (Unattributed Navigation Overhead) is the best Christmas present you will get this year!

UNO, not the card game, is the missing piece for many of your unsolved performance puzzles!

UNO, not the organisation, even restores peace by keeping teams from pointing fingers and calling each other names when inexplicable things happen.

In this blog post I describe a real use case where UNO, another 3-letter acronym, helped to reduce Largest Contentful Paint (LCP) by several seconds.

Why UNO?

Have you ever noticed that there are gaps between the individual components of Time To First Byte (TTFB)? Are you aware that we actually don’t know nor measure what the browser is doing during these unattributed times?

As the saying goes, “if you can’t measure it, you can’t improve it”. That’s why we decided to introduce UNO, a new metric that equals the sum of all these unattributed gaps.

In an ideal world, Unattributed Navigation Overhead (UNO) would be ZERO! However, this is rarely the case!

If you are worried that this is another blog post about microtuning to save a few nanoseconds, rest assured that these gaps can be a fundamental part of your TTFB.

How big is UNO?

UNO ranges from just a few milliseconds to several seconds of devastating overhead!

Here is UNO captured using mPulse Real User Monitoring (RUM) data for 2 different sites, over a 30 day period, and for several percentiles (P10, P75, P98 and P99).

For site A (left), the 10th percentile is only 2ms, a neglectable value likely linked to rounding errors. At the higher percentiles (P98+) UNO does become a more significant overhead with a value larger than 100ms. I agree we can debate if this overhead is worth a blogpost.

Site B (right) however shows catastrophic data for UNO! At the 10th percentile UNO is only 8ms. From the P75 onward though, we see that UNO first makes a jump to 421ms, then drastically increases to 4.51 seconds at the P98 and finally settles at 6.15 seconds for the P99.

In other words: Site B has a serious performance problem! (Remember? These high UNO values are part of TTFB and ultimately LCP) However, it’s unclear what the problem is, because it is all Unattributed overhead!

Importantly though, just because it’s Unattributed doesn’t mean we can’t speculate on or deduce what’s behind these delays! Let’s look at one very common reason for UNO next.

Fixing slow UNO values

Let us take the example of Site B with UNO values of several seconds!

This high value was the reason for multiple teams (CDN, Backend, Database, Networking, DNS and more) being in “escalation mode” for several weeks.

It started with the public Chrome User Experience Report (CrUX) showing us that a large number of their users experienced a poor LCP.

CrUX also pointed towards TTFB, a key component of LCP, as the culprit. On the graph below (from treo.sh) you see a poor TTFB for 19.5% of all measurements.

The customer started a program to reduce their TTFB; all hands were on deck to help bring it down and everyone was pointing fingers at each other:

• Tune the CDN, it must be the CDN
• Tune the Database, it must be a missing Index
• Tune DNS, it is always DNS
• Tune the infra, we need more RAM and CPU
• Tune the application, it must be slow code
• …

After each team saved a few milliseconds, none of the changes really moved the needle significantly. The teams were frustrated and the tension in the meetings was real. No one felt they were responsible, and each of the teams had plausible data to back up their claims!

After a few months of tweaking, hoping and waiting for the 28-day window in CrUX to show progress, nothing significant happened and everyone was confused!

Measuring UNO

At some point this unsolvable problem fell into my lap and a few days after activating mPulse RUM, their high UNO values immediately stood out to me.

When analysing their RUM data, we noticed 2 interesting patterns:

• All paid traffic (via advertising, paid search and affiliates) shows significant (800+ms) UNO values compared to non-paid traffic.
• UNO varies a lot based on the paid traffic source

The image above shows the variation of UNO based on the traffic source (using the utm_campaign query string). We measured UNO values between 800 and 1000ms for Publisher Z (green), Publisher Y (orange) is slightly slower (900-1200ms), while the impact of Publisher X is devastating with an additional penalty of 2500 up to 5000ms.

Why is UNO this big?

I manually looked at some ads with Publisher X and used the Chrome devtools network tab to try and figure out what was happening. I immediately noticed two redirects that took a long time.

This screenshot of the network tab in Chrome Devtools shows the redirect chain when a user clicks on a paid link in the Google search results.

Prior to the actual marketing landing page (200 Status) the browser received two redirects (302 Status). These 2 redirects have a combined overhead of 1222ms (574+648ms) contributing to the total TTFB.

In DevTools this overhead of 1222ms can clearly be attributed to redirects, however this is not the case when looking at RUM data:

In RUM, the above example actually shows a redirect overhead of 0ms and the 1222ms is not attributed! In RUM it looks as if no redirects have taken place at all.

This strange behaviour is due to the privacy concerns of the Navigation Timing API, which does not attribute the overhead caused by cross-origin redirects! It still (intentionally) does include the total redirect time in its TTFB measurements however, it just doesn’t tell you where it’s coming from.

Bad news! This is not only for paid traffic or slow publishers, the same can happen with URL shortening services or links originating from social networks.

Reducing UNO

Measuring UNO was a game changer for the teams of Site B! Suddenly, all the engineers realised that none of their performance issues were under their direct control and that any additional tuning steps would be pointless compared to the seconds of overhead associated with UNO.

Nevertheless, we still had a problem to solve! After a few meetings, we decided to:

• Reduce advertising with the publishers having the slowest ad providers.
• Compensate for this with more advertising with the faster providers.
• Submitted suggestions to Ad Providers improving their redirect times.

All these actions resulted in a reduction of the customer’s UNO, their TTFB and ultimately their LCP!

According to CrUX we started with almost 20% poor TTFB experiences and a P75 of 1.4 seconds. After the initial changes this dropped to 8.5% and 0.8 seconds.

This is still a high number as the majority of inbound traffic comes from paid advertising, all of which are still subject to redirection overhead.

UNO and CrUX

CrUX is very popular and undoubtedly a valuable RUM tool. The downside of CrUX is that you have no attribution at all: No DNS, no TCP, no TLS, no redirects,…. or any other component of TTFB!

Therefore, you could say the UNO value of CrUX is always equal to the full reported TTFB, as everything is “unattributed” and there’s no way to know where a slowdown is coming from.

A good Real User Monitoring (RUM) solution leaves you with no blind spots!

If your RUM solution (DIY, open source or commercial) captures all the individual components of TTFB, UNO is clean and only captures the truly unknown.

If this is not the case, the number of unknowns increases and so does UNO.

Summary

Start measuring UNO today! Not only will this make your analysis easier by freeing you from tricky performance blindspots, it will also reduce the number of heated discussions when there are unexplained performance issues!

If you see a high UNO value, it is probably a cross-origin redirect! However, you can’t be 100% sure as it could be something else, it is called Unattributed for a reason! In those cases, trying to figure out a common pattern for the high UNO cases in RUM (like I did with the publishers) and then using other tools (like the Browser devtools) can help you get to the bottom of the issue!

That was my 2024 Christmas present to you and I hope you enjoyed it! If you need any gift suggestions for me, I love 3-letter acronyms and I have a passion for fast things: PS5 🙂

Ho Ho Ho,
Tim

(Final note: mPulse already captures UNO out of the box, hopefully more RUM tools will follow soon!)