W3C home > Mailing lists > Public > public-web-perf@w3.org > January 2015

Re: [minutes] 2015-01-14 Web Performance

From: Yoav Weiss <yoav@yoav.ws>
Date: Mon, 19 Jan 2015 07:01:08 -0500
Message-ID: <CACj=BEh9k=HysqRsyNpC_Q_DwaHvoGiSq-NE8RTxx4KD8fbh=A@mail.gmail.com>
To: Philippe Le Hegaret <plh@w3.org>
Cc: public-web-perf <public-web-perf@w3.org>
Hi,

I was also present (albeit slightly late) in the call.

To document the image decoding timing use case:
I believe that a means to estimate the CPU/GPU time that are consumed by
image decoding could provide RUM insight to the cost of using one image
codec over another.
Having real-world data of decoding speeds vs. network download speeds
(provided by Resource Timing) would enable authors and CDNs to asses the
trade-off of using more network-efficient but slower-to-decode image
formats. Getting that data in the lab is hard, because decoding speeds can
vary significantly according to the device, and may change in real-world
conditions (e.g. weak battery).

Ideally, it would be great to have that decoding info provided for the
images embedded in the page without forcing the browser to do more work in
order to gather that data.
Failing that, a JS API that would enable to run such measurements on a
subset of users would be a good first step into understanding image
decoding times.

On Wed, Jan 14, 2015 at 3:54 PM, Philippe Le Hegaret <plh@w3.org> wrote:

> Present: Ilya, Tobin, Michael, plh (late)
>
> Meeting notes (thanks to Michael):
>
> - surfacing redirect timing data in NT/RT:
> http://lists.w3.org/Archives/Public/public-web-perf/2015Jan/0006.html
>
> Tobin will check with the authors of the original spec, see if we can
> figure out why some decisions were made regarding redirects.
>
>  new proposal draft for NEL:
> http://lists.w3.org/Archives/Public/public-web-perf/2015Jan/0021.html
>
> Ilya will check with Mozilla, Chrome is happy with the draft.
>
> frame timing + cost:
> http://lists.w3.org/Archives/Public/public-web-perf/2015Jan/0019.html
>
> "cost" is hard problem to get consensus on. Should probably be a
> separate discussion.
>
> cpuTime is challenging for both IE and Chrome to attribute to a frame.
> IE investigating what would be feasible for them to surface. Feedback on
> Ilya's document?
>
> Separate API to measure/report CPU time in general (arbitrary JS
> measurement)
>
> yoav: cpuTime is really interesting for image decoding time
> useful to compare codecs and RUM for bytes versus decode time..
> not necessarily part of "frame timing" maybe resource timing? javascript
> stopwatch?
>
> Ilya: cpuTime (+gpuTime) measurement - (AI) lets document some use
> cases. Frame Timing, Image Decoding, Memory utilization? etc.
>
> Philippe
>
>
>
>
Received on Monday, 19 January 2015 12:01:40 UTC

This archive was generated by hypermail 2.3.1 : Monday, 19 January 2015 12:01:41 UTC