- From: Ben Maurer <ben.maurer@gmail.com>
- Date: Thu, 28 Aug 2014 12:50:50 -0700
- To: public-web-perf <public-web-perf@w3.org>
- Message-ID: <CABgOVaJ3oiGZuQroH6XDZV-2e1D5ecU5YmfNDL_kFXT09Cn4Kw@mail.gmail.com>
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?
Received on Thursday, 28 August 2014 19:51:17 UTC