Web Performance: Leveraging the Metrics That Most Affect User Experience — Google I/O 2017 Live Blogs

Google has long evangelized the importance of increasing performance of your website, especially when it comes to mobile users. On the second day of Google I/O 2017, we live blogged a session about understanding the metrics you need to measure to understand what most affects users.

Google has long evangelized the importance of increasing performance of your website, especially when it comes to mobile users.   Both the AMP Project, and the Progressive Web App initiative are all about increasing performance for mobile users and had heavy presence at I/O this year.  But Google’s interest in performance stretches beyond these projects, and on the second day of I/O, there was a session about understanding the metrics you need to measure to understand what most affects users.

Session Summary

When asked the question “How fast is your web app?” most people answer the question with what is best described as “lab performance” as opposed to real world performance.  In order to get an accurate measurement of your site’s performance you need to go beyond a measurement of how many seconds your page loads.

There are 4 questions your users are asking as your page is loading, and each question is associated with a different metric or group of metrics you should measure.

Is it happening? This question is asked if nothing appears to be loading on the page at all.  This question is answered by the time your page has the “First Paint” (or the first time anything on the screen is rendered) and more so by “First Contentful Paint” (or the first time any actual content is rendered on the screen).

Is it useful? Having some content on the page is not particularly useful, only when there is enough content on the screen that you can actually start consuming your content.  This is often referred to as “First Meaningful Paint” or the first time real consumable content is rendered on the screen.  Google recommends you identify “Hero Elements” or the most important pieces of content on your page and make sure they render first.

Is it usable? Once content starts rendering, people can still become frustrated if they are unable to interact with your site.  This is referred to as “Time to Interactive” or the time that the user can actually start working with the content on the site.

Is it delightful? Often times even after the site is interactive, other things continue to be brought in.  These “Long Tasks” should still be fast, but as long as they don’t prevent the page from being useful and usable (that is to say deferred to happen after the page is usable) it is ok for them to take longer.

After explaining what you are looking for, Shubhie Panicker (@shubhie) and Philip Walton (@philwalton) spent some time to explain how you can measure these particular metrics.  They discussed some upcoming new native features in browsers (in particular Chrome since it is one they control) that allow you to measure these particular metrics.

They explained that they’ve decided to measure “Time to Interactive,” which they consider the most important metric to measure, as “the last long task completion before a gap of 5 seconds after DOM content loaded.”

The new browser native tools keep track of whenever there is a gap of 5 seconds after the content of the page is loaded, at which point they look back and find the last long task (a task that takes longer than 50 ms to take place) and they mark the end of that time as the Time to Interactive.

After this, they spent some time describing specific things you can do to improve your performance.

Get to FP and FCP fast.  To ensure that your users don’t ask the “Is it happening?” question, prioritize getting some content rendered on the screen as fast as possible.  You can accomplish this by Inlining critical CSS and ensuring that there are no external javascript files that block rendering before they can load.

Reduce Long Tasks.  In order to bring the time to interactive down, split up any long running tasks, try to get as many tasks under 50 milliseconds as possible, break javascript files into smaller files and load them progressively.  And use asynchronous features built into the Javascript engine such as requestIdleCallback().

Hold Third Parties Accountable.  When Google studied where the long tasks are coming from, they discovered on most sites the overwhelming majority of long tasks come from Advertisements and Social Widgets.  Webmasters need to hold these third parties (including Google with Adsense and Google+) accountable for their widgets causing long tasks.

Prevent Regression.  Before you add anything new to your site, make sure that the new feature you are adding aren’t going to cause your performance to get worse.  If you spend your time to make things better, don’t undo your progress just to add something new.

While a lot of this session dealt in generals, I thought it was a particularly good session and I highly recommend that everyone who works on web development watch it (video below) and take note of the suggestions given.

Session Video

Live Blog Transcript

• 14:29: Ready for the next session
• 14:30: This session on web Performance is helmed by Shubhie Panicker (@shubhie) and Philip Walton (@philwalton)
• 14:32: How fast is your web app?
• 14:34: Testing the performance of your web app needs to be more than just saying your app loaded in x seconds, you need to test the performance over the entire web app for real users.
• 14:35: Performance in the lab vs Performance in the real world
• 14:35: When is “load”?
• 14:39: Don’t measure “load” with a single metric. Sometimes starting to render early is a good user experience, sometimes it is not
• 14:40: Myth: Bad performance is all about load. Reality: Bad user experiences can happen at any time. Users associate performance with their overall experience
• 14:41: User-centric metrics: The reality is most traditional performance metrics have almost nothing to do with user experience. We need to rethink our metrics and focus on what matters
• 14:42: 4 Questions
  • Is it happening?
  • Is it useful?
  • Is it usable?
  • Is it delightful?
• 14:44: Key questions
  • What metrics most accurately reflect user-perceived performance?
  • How do we measure these metrics on real users?
  • How do we interpret our measurements to see how we’re doing?
  • How do we optimize and prevent regressions in the future?
• 14:44: Terms used in rest (in order)
  • FP: First Paint
  • FCP: First Contentful Paint
  • FMP: First Meaningful Paint
  • TTI: Time to Interactive
• 14:45: Hero Elements: Your most important pieces of content
• 14:46: Queue Time: When you wait in a long line (like often at #io17 🙂) the user can become impatient
• 14:47: For the web, use small tasks in 50 ms chunks
• 14:48: one size cannot fit all
• 14:50: Metrics for the questions before
  • Is it happening? First Paint (FP) / First Contentful Paint (FCP)
  • Is it useful? First Meaningful Paint (FMP) Hero Element Timing
  • Is it usable? Time to Interactive (TTI)
  • Is it delightful? Long Tasks
• 14:50: how do you measure real world performance in javascript?  Very hard, we traditionally use things like window.load because it is easy to get, but the whole experience is important to measure
• 14:52: New performance APIs in the browser
  • Performance Observer
  • High Resolution Time
  • Performance Entity
• 14:53: RUM with PerformanceObserver: you can create an observer and assign it to watch a long task to keep tabs on things that take longer than 50ms
• 14:55: @shubhie and @philwalton are giving a pretty great session
• 14:58: Measure “Time to Interactive” the last long task completion before a gap of 5 seconds after dom content loaded
• 14:58: you can send this data back to Analytics as an event
• 15:00: Interpreting the Results. Do performance metrics correlate with business metrics?
• 15:01: What about users who leave my app before it’s loaded. you can’t measure how long the tti would have happened, but you can measure how often it happens.
• 15:02: Get to FP (First Paint) and FCP (First Content Paint) fast
  • Inline critical CSS
  • Remove render blocking scripts from the <head>
  • App Shell Pattern
• 15:02: Minimize the time from FMP (First Meaningful Paint) and TTI (Time to Interactive)
  • Ship less JS
  • Break up existing JS with Code Splitting
  • PRPL Pattern
• 15:04: Reduce Long Tasks
  • Break up JS
  • 50ms upper bound
  • use requestIdleCallback()
• 15:05: Hold Third Parties Accountable
  Ads and Social Widgets account for a LOT of Long Tasks
  Nick: YES! They Do!!!
• 15:06: Preventing regression: Have a plan to make sure new features don’t make things worse again.
• 15:07: How fast is your web app? Hopefully the tools and information can help you answer that question and make things better
• 15:08: Looking ahead: we need ways to measure hero element load in the browser
• 15:09: Google wants to hear from you to find out what your frustrations are with performance, file bugs on the spec repos on github
• 15:09: If you are working with Analytics, push on your Analytics to adopt these new metrics
• 15:10: Article will be published shortly along with the video on this talk