Re: Measuring the arrival times of parts of a page

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?
>