- From: Jonas Sicking <jonas@sicking.cc>
- Date: Wed, 27 Jan 2010 17:57:52 -0800
- To: Zhiheng Wang <zhihengw@google.com>
- Cc: public-webapps@w3.org
On Wed, Jan 27, 2010 at 5:30 PM, Zhiheng Wang <zhihengw@google.com> wrote:
> Hi, Jonas,
> Thanks for the comments. pls find comments inline.
> On Wed, Jan 27, 2010 at 12:12 AM, Jonas Sicking <jonas@sicking.cc> wrote:
>>
>> On Tue, Jan 26, 2010 at 11:39 PM, Zhiheng Wang <zhihengw@google.com>
>> wrote:
>> > Folks,
>> > Thanks to the much feedback from various developers, the WebTiming
>> > specs has undergone some
>> > major revision. Timing info has now been extended to page elements and a
>> > couple more interesting timing
>> > data points are added. The draft is up
>> > on http://dev.w3.org/2006/webapi/WebTiming/
>> > Feedback and comments are highly appreciated.
>>
>> I take it the idea is that you can get when we for an <img> element
>> start fetching the image, when image data starts arriving etc. I'd
>> prefer if the spec had a comprehensive list of elements that this is
>> expected to be implemented on.
>
> Right now only embedded content elements require these info. An explicit
> list
> might be better though, e.g., <script> is not classified as embedded
> content.
What do these properties measure on a <figure>? And why would you care
to measure downloading performance on <link rel=icon>? And why
wouldn't you care about <script>? That one seems more performance
critical than any other external resource.
>> Extending this to elements introduces *significantly* more
>> implementation cost. Is it really worth it? My concern is that this
>> spec already had fairly high cost/benefit ratio since it doesn't add
>> any "new" functionality to the web platform, it "just" lets devs do
>> more accurate performance measurements. And it's far from easy to
>> implement since much of the information isn't available outside of the
>> networking code (and many times there only available on a different
>> thread).
>
> Certainly the overhead of implementing the specs should be evaluated. It
> should be
> done while we are looking into more browser-specific implementations. Right
> now I want
> to be as specific as possible in the specs. But much implementation overhead
> can be
> avoided if we can tune the specs to accept some slight "inaccuracy", say,
> taking the time
> of the first callback from the data socket instead of the actual first
> byte time as responseStart.
I'm not sure what you mean by "more browser-specific implementations"?
Implementation complexity vs. value should be looked at all the time
IMHO.
>> Also, what is the use case for the "Ticks" interface?
>
> The Ticks interface is a convenient way to store time measurements and
> retrieve it later on a page.
> I will have some example there.
Why not just do:
myTimings = {};
myTimings.fooStart = new Date();
etc? Javascript has perfectly good ways to store values already.
>> I would really encourage that this spec be reduced to the most
>> important parts first and wait for browsers to catch up before adding
>> "nice to have" features.
>
> Agree and we do keep that in mind. Most of the the properties specified
> right now are
> on the critical path of user perceived latency though.
That surprises me. See my first answer above.
>> If implementations implement progress events on the various elements
>> it would seem like you would get most of the advantages from this
>> spec.
>
> The progress events are great, except that they mostly focus on
> downloading the content but
> not much about everything else, say, parseStart.
Specs can be changed, nothing is set in stone :)
/ Jonas
Received on Thursday, 28 January 2010 01:58:46 UTC