metric: Time to Interactive

[paulirish]

Time 'To Interactive (or TTI) is a classic success metric across the web, games and application development. We're attempting to provide a robust version of it for the web platform.

Key goals for the metric:

• User should feel like the page is done enough to start interacting -- they may scroll, tap on notification icons, start reading and expect the page to be not move around any longer.
• The page should be ready for the user. It's not enough to present the appearance of done-ness. The user shouldn't have problems once they start engaging with the page, because it's either still busy or uninitialized. In other words, the page is not ready if main thread contention is preventing user interaction from being successful.

A working definition for Time To Interactive

Updated: April 6, 2016

There are two major timestamps, composed of smaller ones:

Timestamp: Visually ready for interaction

Visually ready is the Math.max() of these timestamps:

1. domContentLoadedEventEnd has fired
   • Definition: HTML parsing has finished, all DOMContentLoaded handlers have run
2. User-agent loading indicator is done
   • Current definition: Top frame and all iframes have fired window load event
   • Proposed definition (from cl/1860743002): top frame only: DCL ended and all layout-blocking resources, plus images that begun their request before DCL ended have finished.
   • Alternative definition (from Chrome on Android Progress Bar Enhancements - google-only, sry): top frame's DOMContentLoaded + top frame's images (who started before DCL) are loaded (IMO, we should use this one)
     • Perhaps only include we only include above-the-fold-ish images.
3. Above-the-fold layout has stabilized
   • Could use WebMeaningfulLayout.h
   • Could use ksakamoto's "largest layout"?
4. What about fonts?
   • They are not necessarily addressed by above items.
   • Do we wait for inflight fonts requests? Only if the text remains invisible (if the user allows a fallback font, then we don't wait for inflight)
   • Can we ignore icon-fonts like font-awesome?
   • We should at least collect the font-painted timestamps for all webfonts
   • The Time to First Meaningful Paint: a layout-based approach algorithm considers in-flight font requests that layout more than 200 characters.
5. Viewport and above-the-fold
   • None of the above considers what is in the viewport, and waits for resources that may be offscreen or 10,000px away.
   • Should we only consider images that are above-the-fold?

Timestamp: Main thread ready for interaction

Once visually ready has hit, we begin considering thread availability.

1. Main thread is available
   • Definition TBD.
   • Approximate: 90% percentile main thread task duration ~ under 300ms. Maximum main thread task duration is < 400ms
   • Perhaps: System Health "input readiness" Metric by @benshayden
   • Perhaps: Ask requestIdleCallback for deadlines
     • "You call rIC until you get at least 20ms. Treat it as a proxy for page being settled. Seemed to correlate pretty well" ~@paullewis & jochen

@skyostil added: "it's super hard to congest the compositor, but a fair indicator will be availability of time on main thread because a) a lot of work will be main-thread bound and b) CPU contention (he thinks) can sometimes block the compositor from allowing scroll."

@paullewis added: "some of this may be in our wording where we explain that we're treating main thread as a proxy for interactivity"

Main-thread dependent input events

• Question: Do we treat pages with slow-scrolling-regions (global touchstart, etc) the same as ones without?
• Verdict: yes, until there is a CSP-like policy that makes it impossible to add these handlers

Key Data, Goals, and Scoring

• milliseconds: navigationStart ─⇥ visually ready
• milliseconds: navigationStart ─⇥ thread ready
• milliseconds: visually ready ─⇥ thread ready
  • if the delta between "looks done" and "is ready" is bigger and bigger.. then you're tanking the UX and the score should represent that.

---

- Goal: `max(visReady,threadReady)`should be < 5000ms - Scoring TBD

[danbeam]

1. Main thread is ~available
   • Calculation TBD.

Maybe this is when there's enough yielding that the UI can change or interact or show progress every 16.7ms (i.e. 60 FPS)?

5. Any other ideas?

Maybe mention that deferred work may be scheduled and run while not affecting TTI (as long as it's not clogging things up)?

/cc @natduca @esprehn

[paulirish]

I've updated the definition of the TTI above metric based on latest discussions with @benshayden, @skyostil, japhet@, @pbakaus and others.

[bryanmcquade]

Are we sure TTI should block on domContentLoadedEventEnd? I find that many pages start to become interactable before parsing is complete. If for instance there's a script in the footer inserted via doc.write, this can delay DCL firing when the CPU will be idle and the page interactive.

That said, I think it's also reasonable to discourage pages from running the parser a long time after their content is usable - we can message to devs that they shouldn't do this and if they do so, our loading indicators may stay visible longer than they would like. But that also means that some existing content will continue to show a loading indicator / not be considered interactive until after it has reached the interactive state.

[paulirish]

Are we sure TTI should block on domContentLoadedEventEnd?

Hah. Pat pretty much the same comment yesterday on the Progressive page Load Metrics doc yesterday(https://docs.google.com/document/d/1oiy0_ych1v2ADhyG_QW7Ps4BNER2ShlJjx2zCbVzVyY/edit#)

Quoting him, then me..

This isn't necessarily tied to anything visual. A site can have a lot of js at the end of the body that needs to get loaded/parsed/executed that will delay DCL but may not cause any visual change to the page, though by-definition if you are waiting for the progress indicator this may be included anyway as part of that logic.

Fair. This isn't directly a visual dependency, so I'll adjust that.

---

I agree that DCL be a direct dependency here as its not visual. Main thread availability will tackle CPU contention, and layout stability for the rest of the blocking script impact.