[This article was written by Craig Lowell]

Tell us if you’ve heard this one before.

While WWDC 2015 produced more juicy stories such as their announcement of Apple Music and how the release of iOS9 is their most aggressive play yet to steal market share from their competitors, we noticed one little-reported aspect of the new operating system that is more about trying to just keep up with the competition as opposed to overtaking it: the support of Navigation Timing in Mobile Safari 9.

As a topic that has been near and dear to our hearts for a long time, we were obviously excited when we discovered that the Navigation Timing API would be supported in Safari 8.1, and equally dismayed when it was removed a few months later due to what Apple cited simply as performance issues. So we’re trying not to count our chickens this time, but it’s a good bet that a company as performance-minded as Apple wouldn’t go back to this same well a second time if they weren’t sure that they had worked out all the bugs.

What’s interesting about the Navigation Timing issue as it relates to Safari is that every other major browser already supports it, which made its unavailability a particular sore spot for developers and IT Ops professionals who need it in order to gain deeper insight into their RUM data. Without support of the API through the browser, the only way to get any information about real user experience was through a heuristic approach with JavaScript that only offered limited metrics about when a page started and finished rendering. Through the API, however, we can see data about DNS connections, Response Times, Load Times, etc. that eliminate most of the blind spots of the old-fashioned heuristic method.

At the same time, while the support of the Navigation Timing API is a great inclusion because it provides timings for the base html and browser events like DomContentLoaded and onload, it doesnot offer insight into the performance of page resources. This means that IT Ops professionals still have a blind spot in Safari. Adding support for the Resource Timing API would allow for reporting on timing of various resources such as images, CSS, JavaScript delivered from various locations, and help in pinpointing exactly what requests caused problems and why. The rumor we heard was that it was not added in the latest version due to privacy concerns (something that the W3C standard and other browsers account for even though it limits the effectiveness of the feature).

This also wouldn’t be as big of a deal if it wasn’t for Safari’s domination of the mobile browsing market. But with more and more online experiences shifting from desktop to mobile, the need for IT teams to get as much information as possible about the performance of their mobile pages is only going to increase.

So let’s cross our fingers and hope that the Navigation Timing API will stick around this time. Then we can move on to getting them to support Resource Timing as well…