The Safari Performance Blind Spot

This guest post comes from Mehdi Daoudi, CEO of Catchpoint. You can follow him on Twitter or find him regularly contributing to the Catchpoint blog.

User Experience on the web has now become a differentiator – websites that are fast, sleek and easy-to-navigate get more traffic, more conversions and a better brand reputation. As competition is always just one-click away on the web, companies are now focused on providing the best experience possible to avoid losing visitors – and, ultimately, sales.  However, websites have become complex ecosystems, rich with media, third-party services and built off of internal and external platforms.  Figuring out the user experience is not an easy task as overall performance varies based on location, network, browser and operating system (OS), as well as the performance of the individual components on the page itself.

Why RUM?

Real User Measurement, or RUM, is a method of tracking the experience of end users or customers on a website.  The data provided allows companies to understand how different people experience their website from all over the world in hopes of catching and optimizing speed bottlenecks.  There are other methods of monitoring performance, such as with synthetic external testing (simulating end users in a clean lab setting) and onsite Application Performance Monitoring (APM).  Each method has its pros and cons, the biggest benefit to RUM is the ability collect data from the end users and correlate that to business metrics like conversions or sales.

Industry Performance Push

In 2012, the W3C (World Wide Web Consortium) adopted a new standard for collecting performance data from end users called Navigation Timing.  Navigation Timing defines how browsers should report timing during the loading and rendering of a webpage.

The most accurate RUM technology relies on the Navigation Timing specification to measure and collect data based on actual browser events.  Without support of Navigation Timing, RUM still works but only as a heuristic method.  Rather than capturing the 20+ Navigation Timing events, the heuristic method approximates user experience events by taking timestamps: when the page starts loading, at onload, when leaving the page, etc. Another issue with the heuristic method is that when a user visits a page, there is no data for how long it takes between the original GET request and delivering the HTML to the client on the first page load.  If the user navigates to a second page, then the heuristic method can measure the time between the request and the load, but there is no further segmentation. This is a major problem if trying to measure the backend processing time or performance of DNS or CDN servers. Using estimations for metrics does not give companies a clear picture of what exactly is going on in terms of user experience. Estimates lack clarity – they are nowhere near as rich as the data provided by Navigation Timing.  It is much harder to gain any real insight into what is dictating the end-user experience.

Unfortunately, not all browsers have integrated Navigation Timing into their Framework, leaving major performance blind spots for companies relying on RUM for performance data.  Apple’s mobile and desktop Safari browsers are included in this very small list, a huge problem as there is no precise way to measure and improve performance for Apple users.

Figure 1: Navigation Timing Spec

Figure 2: Example Heuristic Spec

One Bad Apple

Apple’s neglect of Navigation Timing is extremely detrimental to online companies given Apple’s market leadership in tablets and smartphones.  According to Monetate, in Q1 2013, 89.28% of tablet traffic came from iPad users.  That means almost 9 out of 10 people browsing on a tablet do not have the most optimized experience possible.  Does this hurt companies?  Yes, of course it does.   Does this hurt Apple?  Yes!  Of course it does!  If developers do not have data to create innovative websites for Apple users, then Apple users are getting less innovative experiences.

For example, Company X has a pretty good mobile site designed for iPad users.  During development the team tested the website internally on an iPad and was satisfied with the results.  Based on its marketing analytics tools, the company sees an average bounce rate of 10 percent to the tablet site.  One day the bounce rate spikes up to 30 percent and understandably, Company X wants to troubleshoot and figure out what is causing that increase.  But the team can’t see that their front end servers were taking an extremely long time to respond, causing users to get irritated and navigate away.  So Company X is left in the dark – losing opportunities and revenue.  And as for the users browsing Company X’s site on an iPad … they are likely left with a frustrating experience.

Advocating for Performance

A slow loading website does not cut it anymore – people expect fast websites and are quick to move on to the next website if their patience is tested.  Revenue and brand success are dependent on a fast-loading webpage, so precise data on speed, availability, reliability and consistency is absolutely necessary.

How can we get rid of this performance blind spot?  Browsers like Safari need to help developers by incorporating the Navigation Timing specification and we must join together showing our support to provide the best possible experience ever on the web.

As CEO of Catchpoint, a performance monitoring company, I want to drive successful online experiences across the board so I started a petition asking Apple to incorporate the Navigation Timing specification.  If successful, companies will get a clear picture to how their Web Service or app performs on mobile and desktop Safari browsers and be able to make further improvements, deliver enhanced customer experiences and earn more revenue.

If your company has an online presence or you are a Safari user, then you will benefit from Apple including Navigation Timing in an upcoming release.  Please, show your support and help us make the web better for everyone – sign the petition today.

Be sure to read the next Best Practices article: API Endpoint Versioning Methods: Sub-domain or Directory?