Re: Measuring the arrival times of parts of a page

Hey,

Yeah, I think that would be pretty helpful. I think you'd really need a #
of bytes field to make good sense of this (what if a proxy decides to
rechunk the document).

One advantage I could see to the declarative performance mark method is the
ease of use. It takes quite a bit of sophistication to record the mapping
of #of bytes => part of page. One other thing you could imagine a
declarative interface doing is exposing more than just the networking time
("here's how long it took to execute all the JS before this point", "here's
how long it took until this point would have been painted on the screen").
For our purposes, we can easily implement these features, but I think it
might be hard for the masses to use. I also realize that it's a very weird
layering.

-b


On Tue, Sep 2, 2014 at 2:29 PM, Ilya Grigorik <igrigorik@google.com> wrote:

> Ben, this is a tricky one. It sounds like what you're actually asking for
> is timing data for "named chunks"...
>
> Even if we had a declarative performance mark, it seems odd to record it
> as part of the preload-scan. Instead, I would expect it to be processed by
> the doc parser - i.e. this chunk of markup was processed at this point.
> Then again, while that has some benefits (don't need to inline JS and block
> parsing on it; wait for stylesheets), it doesn't actually address your
> specific problem.
>
> As a thought experiment: what if we had chunk timings as part of Nav /
> Resource Timing? For example:
>
> var r = performance.getEntriesByName('http://somesite.com/resource');
> >> {
>   responseEnd: 160263.62900000095,
>   ... (snip) ...
>   startTime: 158183.55500000325,
>   entryType: "resource",
>   name: "http://somesite.com/resource"
>   chunks: [
>      {
>       responseStart: 158681.0310000000000000,
>       responseEnd: 159071.0310000000000000
>     },
>     ...
>     {
>       responseStart: 159867.9795000000000000,
>       responseEnd: 160257.9795000000000000
>     }
>   ]
> }
>
> Granted, you can't peek inside the chunk and see its contents (or assign a
> label to it), but this would nonetheless give you a direct view into how
> the HTML (or any other resource) was streamed from the server. It seems
> like a generally useful thing, and I know that YouTube folks have asked for
> exactly this in the past... Would something like that help answer what
> you're after?
>
> ig
>
>
>
>
>
> On Thu, Aug 28, 2014 at 12:50 PM, Ben Maurer <ben.maurer@gmail.com> wrote:
>
>> Hey,
>>
>> One problem I've seen people face recently is measuring the arrival times
>> of an incrementally rendered page. I wanted to get people's thoughts on (1)
>> if there's some easy way to do this that I'm missing and (2) if not, would
>> it be worth creating a way.
>>
>> Imagine the following page:
>>
>>
>> <script>
>>   window.performance.mark("header_arrived");
>>   requireStylesheet("header.css");
>>   renderHeader();
>>   window.performance.mark("header_loaded");
>> </script>
>>
>> <!-- the server flushes the content up to this point.
>>       it takes 500 ms to generate the following content -->
>> <script>
>>   window.performance.mark("feed_arrived");
>>   requireStylesheet("feed.css");
>>   renderFeed();
>>   window.performance.mark("feed_arrived");
>> </script>
>>
>> The {header|feed}_arrived event is intended to measure how long it took
>> to get the bytes of data to the client. But in reality, it also measures
>> the time it takes to load CSS stylesheets (because if you add a CSS
>> stylesheet it blocks the execution of future script tags) and the amount of
>> time it takes to execute the javascript functions renderXXX (because those
>> also block future script tags).
>>
>> I've seen a number of incidents where somebody thought that there was a
>> regression in getting data to the browser when what was actually happening
>> is that they were blocked on JS/CSS.
>>
>> To solve this, it seems like one would need some kind of declarative
>> performance mark that was scanned by the preload scanner and was not
>> subject to being delayed by javascript and CSS on the main thread.
>>
>> Any thoughts?
>>
>
>