Re: speed index in Nav Timing API

There are a couple of things that would help make the RUM implementation
better and less controversial (hopefully):

- Standardize first-paint in Navigation Timing.  IE already has it as
msFirstPaint and Chrome has it's version.  It doesn't need to be perfect,
something like the first paint event after the first layout of a non-empty
DOM (that alone would improve the current first paint events which
sometimes fire before the render tree has started being built).

- Provide a way for a parent page to get the start of navigation and onload
time for frames (exposing the navigation start and load times from
navigation timing relative to the parent's clock would be perfect).  It's
nothing that you couldn't get if you instrumented the frame directly so it
should be safe.

I'm pretty sure that those two tweaks would close the gap between the JS
version and what we get from video capture.  Still won't be perfect but it
should be a low-friction way to make progress (and hopefully the additions
have broader usefulness).

On Wed, Oct 15, 2014 at 7:31 PM, Ilya Grigorik <igrigorik@google.com> wrote:

>
> On Wed, Oct 15, 2014 at 12:27 PM, <bizzbyster@gmail.com> wrote:
>
>> Has there been any effort to put something similar to WPT’s speed index (
>> https://sites.google.com/a/webpagetest.org/docs/using-webpagetest/metrics/speed-index)
>> into the Nav Timing API?
>>
>
> First step would be to land a working native implementation, which has
> been a tough nut to crack... pmeenan@ has made several attempts to
> implement SpeedIndex in Chrome, but so far that hasn't been successful due
> to security + architecture concerns. I'll defer to Pat for details.
>
> That said, worth checking out:
> - https://twitter.com/patmeenan/status/517375534821830656
> - https://github.com/WPO-Foundation/RUM-SpeedIndex
>
> ig
>
>
>