Re: Time To Interactive Definition

Hi everyone!

I wanted to share the current Boomerang/mPulse/Akamai thoughts on a RUM-focused TTI metric.  Here's our original pitch:

https://docs.google.com/document/d/1SzfiltTJTx2kfl4p7wGMk588jUegwKi6H3GnWuraYYk


We've built a TTI prototype for Boomerang, and are currently testing it with our customers to gather feedback on its usefulness and reliability.

Our current implementation is pretty similar to Tim's TTI Explainer doc, with a few specific differences.  Our requirements for script-based RUM (that needs to support older browsers) differs from what I'd want in a browser API TTI metric.  Here are the main differences for us:


  1.  We wanted a metric that works decently similar in older browsers
     *   We fall back to idle polling (setTimeout) and/or FPS (requestAnimationFrame) in browsers that don’t support LongTasks to estimate main-thread blocking activity

  2.  For mPulse real-time RUM, we can't afford to always wait 5 seconds for the page to become quiet to declare TTI
     *   We're currently waiting for only 500ms of quiet to declare TTI (though we're playing with this number)
     *   The longer we wait, the more likely the customer will "hard quit" the page and we won't get any beacon sent
     *   We allow the customer to change this threshold if they want


  1.  We don’t pay attention to the network for TTI calculation
     *   Since we don't have a reliable notification mechanism of new network activity (only after-the-fact via ResourceTiming), this was impossible to do reliably from JavaScript
     *   We're also not convinced that network activity has a direct correlation with interactivity (e.g. a dozen images being fetched in the background could still give a fully-interactive + 60fps experience)


  1.  We're calling the "lowed bound" Visually Ready (i.e. TTI can't happen until Visually Ready)
     *   Besides FP/FCP/domContentLoaded, we give the customer the ability to specify Hero Images and Framework Ready
     *   Visually Ready is the maximum of any of those available timestamps
     *   Framework Ready is a "catch-all" for things the customer wants to wait for, i.e. their framework to load and register event handlers (they notify us when this is done via a simple API call)

Would love to discuss this and a browser-based TTI on Monday!

Nic Jansma

From: <njansmaforward@soasta.com> on behalf of Eli Perelman <eperelman@mozilla.com>
Reply-To: "eperelman@mozilla.com" <eperelman@mozilla.com>
Date: Tuesday, October 31, 2017 at 12:17 PM
To: Timothy Dresser <tdresser@chromium.org>
Cc: "public-web-perf@w3.org" <public-web-perf@w3.org>
Subject: Re: Time To Interactive Definition
Resent-From: <public-web-perf@w3.org>
Resent-Date: Tuesday, October 31, 2017 at 12:15 PM

For posterity [1], here is the definition of "contentInteractive" that we adopted within Firefox OS:

"Emit this marker when your application designates that it has bound the events for the minimum set of functionality to allow the user to interact with the "above-the-fold" content made available at visuallyLoaded."
Granted, this mark was implied, not inferred.
Eli Perelman
Mozilla

[1] https://developer.mozilla.org/en-US/docs/Archive/B2G_OS/Developing_Gaia/Raptor/Responsiveness_guidelines<https://urldefense.proofpoint.com/v2/url?u=https-3A__developer.mozilla.org_en-2DUS_docs_Archive_B2G-5FOS_Developing-5FGaia_Raptor_Responsiveness-5Fguidelines&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=iqroqwICB1iopLpz3ZbuVUJWihOwgE1EMld8DwNpPa0&m=zkArnKE7mLtyekhF9ztTehopOdXdEg0tdGDyxOml_xE&s=ezEvI0T5fDIGh4ocbQMRCj9_2wMvORcbAKsfjqqnaVg&e=>

On Tue, Oct 31, 2017 at 11:01 AM Timothy Dresser <tdresser@chromium.org<mailto:tdresser@chromium.org>> wrote:
As discussed in our last meeting, here<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_document_d_1l50v3ljDeUmj9qBsfdPc3wKe-5F1CY5KFYI1baye2NhYk_edit-3Fts-3D59dfaf65-23&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=iqroqwICB1iopLpz3ZbuVUJWihOwgE1EMld8DwNpPa0&m=zkArnKE7mLtyekhF9ztTehopOdXdEg0tdGDyxOml_xE&s=hi78jZtMtBrQ92RrFiOQEiReoZbf48ax3ZLK9yoir8s&e=>'s a description of Chrome's current implementation of Time to Interactive.

Here<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_document_d_1y6NYcI2NyLMh88KVr2NaevdX2e-2De03vL99Wn-2Dgy-5FhVk_edit-23&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=iqroqwICB1iopLpz3ZbuVUJWihOwgE1EMld8DwNpPa0&m=zkArnKE7mLtyekhF9ztTehopOdXdEg0tdGDyxOml_xE&s=KepOtsRR93mkIs-6i7Mg04nB2Ua1BmnUDQISbyeVrfI&e=>'s some rough brainstorming on the next step for Chrome's implementation.

At TPAC, we're hoping to discuss:

  *   The high level objective of TTI.
  *   Chrome's current algorithm for computing TTI.
  *   Enabling TTI measurement in the wild.
Tim