MONDAY 25TH OF JUNE 2018
When looking to improve the performance and user experience of our sites we often start by looking at the network:
What's the time to first byte?
How many requests are we making and how long are they taking?
What's blocking the browser from rendering my precious pixels?
While these are entirely valid questions, over the last few years we've seen a growing number of web performance issues that are caused, not by the network, but by the browser's main thread getting clogged up by excessive CPU usage.
When creating great user experiences, managing CPU usage is now just as important as fast networks.
How often have you been on your mobile and loaded what looks like a complete page only to discover than when you tap or scroll nothing happens or the page lags far behind your input? We need a fresh set of questions that reflect how congested the CPU on our devices might be and how that affects users:
How long is the browser's main thread trashing at 100% CPU?
When can users start interacting smoothly without interruption?
Which scripts are hurting my users?
First Interactive is a Synthetic metric that marks the point in time when the browser's main thread is not blocked for more than 50ms by any single task so it will be able to respond to user input quickly.
First Input Delay is a RUM metric that we recently added to LUX. It measures the time from when a user first interacts with your site (i.e. when they click a link or tap on a button) to the time when the browser is actually able to respond to that interaction.
What struck me is that the user experience ended up being the same. So was it worth the effort? And if they hadn't put the extra effort in, would the default React version actually have been worse for users. Are you monitoring metrics like First Interactive to make sure your users don't also suffer?