1 of 15

Time to Interactive

tdresser@chromium.org, TPAC 2017

2 of 15

What we’re hoping for

  • Rough consensus that this a reasonable direction to pursue
  • Initial feedback on our current implementation
  • We don’t expect to get consensus on precise behavior today

3 of 15

Objective

  • Many sites optimize content visibility at the expense of interactivity.
  • We often see multi-second delays between paint metrics and interactivity.
  • Motivate developers to ensure their sites are interactive quickly.
  • Incentivize developers to eliminate, break up, or front-load their long tasks.

4 of 15

The Problem

5 of 15

The Problem: Example from airbnb

TTI Polyfill

6 of 15

Where we left off

7 of 15

Current Implementation

  • Pick a lower bound
    • currently use First Meaningful Paint.
  • Find the first quiescent window after the lower bound
    • contains no tasks processed on the browsing context event loop > 50ms long.
    • contains 5 seconds with a maximum of two simultaneous resource requests.
  • Report the start time of the window
    • if DOMContentLoadedEnd occurs after the start of the window, report it.

8 of 15

Current Implementation

9 of 15

Required Changes

  • Find an alternative lower bound, as we can’t use First Meaningful Paint
    • Other contenders include:
      • First Contentful Paint
      • DOM Content Loaded
      • Developer’s instrumenting when they’re done adding event listeners
  • Update the network idle heuristic
    • Pay attention to request contents, not just number of simultaneous network requests.
    • We currently allow two simultaneous network requests, to allow video / long polling.

10 of 15

Why a loading metric?

  • Could we just measure page interactivity?
  • Need a clear lab equivalent.
  • Want a guarantee that once a page is loaded, it feels great.
  • Require developers to eliminate, break up, or front-load their long tasks.
  • TTI is the best metric we’ve found for incentivizing this behavior.

11 of 15

Arbitrary Thresholds

  • There are many reasonable thresholds for interactivity we could use.
  • There’s a tradeoff between latency in reporting and accuracy.
  • If you ask two people when a page is fully loaded, they’ll give different answers: some of this ambiguity is unavoidable.
  • Perhaps we should make all parameters configurable?
    • Lower bound, maximum task length, minimum quiet window length

12 of 15

Custom Thresholds

13 of 15

Polyfill

  • Polyfill hosted on GoogleChromeLabs github here.
  • Primary implementation issues:
    • Can’t observe active resource requests.
    • First Contentful Paint isn’t quite good enough.
  • Over to Yoav to talk about polyfill results.

14 of 15

Open Questions

  • Is this approach reasonable?
    • TTI appears to be working pretty well from our perspective.
  • What should the network idle heuristic be?
    • Will a better network idle heuristic enable First Contentful Paint as the lower bound?
    • Do we need a better network idle heuristic if we have a developer annotated lower bound?
  • How should we handle user input?
  • How flexible should the API be?

15 of 15

Possible Next Steps

  • Iterate on definition — make the required changes.
  • Improve TTI JS library quality by exposing in flight resource requests
    • Either based on ResourceTiming, or Fetch.
  • Create a TTI web perf API?