Steve Souders

Subscribe to Steve Souders feed
Essential knowledge for making your web pages faster.
Updated: 31 min 48 sec ago

domInteractive: is it? really?

Fri, 08/07/2015 - 11:50

Netflix published a great article, Making Netflix.com Faster, about their move to Node.js. The article mentions how they use performance.timing.domInteractive to measure improvements:

In order to test and understand the impact of our choices, we monitor a metric we call time to interactive (tti).

Amount of time spent between first known startup of the application platform and when the UI is interactive regardless of view. Note that this does not require that the UI is done loading, but is the first point at which the customer can interact with the UI using an input device.

For applications running inside a web browser, this data is easily retrievable from the Navigation Timing API (where supported).

I keep my eye out for successful tech companies that use something other than window.onload to measure performance. We all know that window.onload is no longer a good way to measure website speed from the user’s perspective. While domInteractive is a much better metric, it also suffers from not being a good proxy for the user experience in some (fairly common) situations.

The focus of Netflix’s redesign is to get interactive content in front of the user as quickly as possible. This is definitely the right goal. The problem is, domInteractive does not necessarily reflect when that happens. The discrepancies are due to scripts and fonts that block rendering. Scripts can make domInteractive measurements too large when the content is actually visible much sooner. Custom fonts make domInteractive measurements too small suggesting that content was interactive sooner than it really was.

To demonstrate this I’ve created two test pages. Each page has some mockup “interactive content” – links to click on and a form to submit. The point of these test pages is to compare the domInteractive measurement with when this critical content becomes interactive.

Loading the domInteractive JS – too conservative test page, we see that the critical content is visible almost immediately. Below this content is a script that takes 8 seconds to load. The domInteractive time is 8+ seconds, even though the critical content was interactive in about half a second. If you have blocking scripts on the page that occur below the critical content, domInteractive produces measurements that are too conservative – they’re larger than when the content was actually interactive.

On the other hand, loading the domInteractive Font – too optimistic test page, the critical content isn’t visible for 8+ seconds. That’s because this content uses a custom font, and that font file takes 8 seconds to load. However, the domInteractive time is about half a second. If you use custom fonts for any of your critical content, domInteractive produces measurements that are too optimistic – they’re smaller than when the content was actually interactive. (Unless you load your fonts asynchronously like Typekit does.)

One solution is to avoid these situations: always load scripts and fonts asynchronously. While this is great, it’s not always possible (I’m looking at you third party snippets!) and it’s hard to ensure that everything is async as code changes.

The best solution is to use custom metrics. Today’s web pages are so complex and unique, the days of a built-in standard metric that applies to all websites are over. Navigation Timing gives us metrics that are better than window.onload, but teams that are focused on performance need to take the next step and implement custom metrics to accurately measure what their users are experiencing.

NOTE: I hope no one, especially folks at Netflix, think this article is a criticism of their work. Quite the opposite, their article is what gave me the idea to do this investigation. Netflix is a great tech company, especially when it comes to performance and sharing with the tech community. It’s also likely that they don’t suffer from these custom font and blocking script issues, and thus domInteractive is producing accurate interactive times for their site.

Categories: Software Testing