Blog Post

When Measuring Web Performance Causes Performance Problems

Apple has removed the Navigation Timing API on mobile due to performance issues. Learn more about this performance issue and how monitoring may be impacted.

Can you put the cork back in a champagne bottle after it’s been popped?

Back in July, the DevOps world rejoiced when Apple finally built a Navigation Timing API into Safari, first in the beta release of iOS 8, and then in the public release which came a couple months later. Naturally, we popped that metaphorical champagne. Given our longstanding efforts to get Apple to include this functionality in its default browser and thus help the DevOps world collect RUM data from a huge portion of internet users, who could blame us?

Well, things are decidedly less cheerful around the office this week, as Apple has quietly removed the Navigation Timing API on mobile due to what it ambiguously refers to as “performance issues.” What those performance issues may be, however, is anyone’s guess.

It would seem that the feature used to measure the performance of the webpages loading on the browser was in turn impacting the performance of the browser, or the device.

The Navigation Timing API is designed to provide the host server with data about the performance of the site as experienced by the end user, thus allowing DevOps teams to glean insight into the rendering path of the pages. But the fact of the matter is that for all of its advantages, it can cause performance problems if not integrated properly. Android and Windows phones have managed to do it without hampering performance (or at least they haven’t acknowledged any degradation), so perhaps some of their developers can expect a call from Apple in the next few days.

It’s unclear as of now if what the performance impact on iOS 8.1 was. But at the very least, it serves as a reminder to all of us in the DevOps world that we have an obligation to the users to only provide them with the best web experience possible, and the steps we take to achieve that goal should never be counter-productive.

It’s certainly not an ideal situation, but Apple deserves credit for admitting their mistake and putting the API on the shelf until they can figure out how to implement it without sacrificing performance on their browser. A company that cares about their users’ experience is something to be appreciated.

However, that doesn’t mean that we can’t be miffed about having our cookie – one that we requested for a long time — snatched away from us. The Safari Navigation Timing API gave us the capability to finally get insight into site performance for nearly sixty percent of mobile users, and now we’re back in the dark.

How long we’ll stay there this time remains to be seen, but we certainly hope that Apple won’t keep us shut out for too long.

Synthetic Monitoring
Real User Monitoring
API Monitoring
This is some text inside of a div block.

You might also like

Blog post

Mastering IPM: API Monitoring for Digital Resilience

Blog post

The SRE Report 2024: Essential Considerations for Readers

Blog post

Retail Resilience: Lessons Learned from Cyber Week 2023

Blog post

Adobe Experience Cloud Outage: The Impact of Relying on Third-party Services