See also: IRC log
<trackbot> Date: 11 December 2013
Sometimes even Zakim messes up.
Jatinder: Based on conversation with plh, looks like User Timing and Performance Timeline will be published as recommendations tomorrow.
Plh: We are on track.
Jatinder: I have updated the re-defined the performance interface in Navigation Timing L2 per Action 119. I'll upload the changes later today.
Thread: http://lists.w3.org/Archives/Public/public-web-perf/2013Dec/0076.html
Jatinder: Lots of discussion and seems like we are landing on the Timing specs should implement byte size information.
Plh: Would byte size data help in the Timing specs?
Jatinder: Giving connection
information to sites so they can make better quality vs.
performance tradeoff sounds interesting. However, I worry that
there are so many complexities here to consider: variation in
network speeds during a single session (if I have gone through
LTE, 3G, Wifi in a single session, which data to report?),
every site will make a speed vs. quality decision instead of
making that decision at an OS level, some users may
wan[CUT]
... and other examples given below and in the threads. It may
be interesting to have the UA tally up the data over time and
give an appropriate hint but looks like Opera did that and was
hit with many false positives, e.g. parallel network activity
made it appear that they were on a slow connection, resulting
in a generally poorer experience for some users. Getting a
stripped down version of the site I was hoping to see when I
have the connectio[CUT]
Ilya: I think the byte size data in the Timing APIs would be a step in the right direction.
Jatinder: Should we include byte size for both Navigation and Resource Timing?
Ilya: We can't see any reason why we shouldn't include it for Navigation and Resource Timing for both byte size and procotol information.
Plh: Mark, when do you expect to have the proposal for protocol information for us?
Mark: I should have it soon.
Jatinder: I can add the byte size information. Ilya, any information you want to include?
Ilya: We may want to include the byte size and compressed information as well.
Jatinder: Anne had feedback that we should name the worker interface, WorkerPerformance, to just Performance, http://lists.w3.org/Archives/Public/public-web-perf/2013Dec/0035.html. Seeing that we already have a partial for Performance, does this make sense?
Spec: https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/HighResolutionTime2/Overview.html#sec-now-method
plh: I'm not sure we need to make a change. But this may impact prototyping.
Jatinder: I'll talk to Travis to see what changes need to make.
Jatinder: Based on latest thread,
http://lists.w3.org/Archives/Public/public-web-perf/2013Dec/0066.html,
seems like most are in agreement to continue working on Beacon
spec prior and then talk about whether to bring this into XHR.
It also seems like we are in agreement that we should stick
with a non-normative limit now during implementation and work
on changing that as needed.
... Regarding determining whether the beacon was queued. I
agree with Jonas that returning a true/false value is a safer
syntax for developers than raising an exception, if we want
developers to take action on the beacon. I worry that
developers will check if the beacon was queued and if not, will
hold the unload and try again. Though not as bad as the current
methods to see if the entire beacon got sent, this will cause
some delay. Do we[CUT]
Ilya: If the browser does the retry, then we probably don't need to allow the developers retry. We talked about error logging being used as a mechanism, but the other thread mentioned that possibly error logging won't retry. I think we should just say best effort.
Chase: If we return a boolean, we are implying that they should wait and check that value. I rather not even give the boolean for queued values. If we do provide a boolean, it might be useful to return a false if the beacon didn't get queued because of the size.
Ilya: Looking at the XHR spec, looks like they also raise the exceptions. I don't think its unreasonable to do the same.
Chase: I wanted to query what
size limits were we considering?
... We are reporting back up to 30K data up to minute for
consumer systems.
Ilya: One of the main concern here is that you're uploading 50k or 100k data while you're competing for the next request. What if the UA does some smart moves like it sends the small data immeidately and waits to send the larger data when it can including during the next page.
Chase: That is what the beacon API seems to want to do.
Ilya: I'm starting to think we shouldn't have a limit as I hear more data. Seems like whatever limit we have breaks someones beacon size, it causes us to do synchronous checks. I think we should just stick with something simpler.
Jatinder: Seeing that XHR can send as much data as possible, I'm not sure we need to protect against that case. I wonder if we're adding complexities for a theoritical problem.
Ilya: Yeah, seems like we're adding complexities.
Chase: If someones going to send MBs and MBs, UAs should set a limit internally.
Jatinder: Okay, I think we should push back on limits unless we have an real world example of abuse today with limits.
Jatinder: Ian pointed out a discussion that’s taking place in the WHATWG over how to provide more control to authors around loading and executing scripts, http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Aug/0277.html. Essentially looks like they are trying to solve issues that script loading libraries are trying to solve today. There are more use cases in the thread. We need to determine how that proposal works with Resource Pri[CUT]
Also, do we have an opinion on that proposal? Main thread is here: http://lists.w3.org/Archives/Public/public-web-perf/2013Dec/0061.html
Jatinder: Ian mentioned that we should either have Resource Priorities changes be made in the HTML spec or have hooks in the HTML spec that Resource Priorities can point to. Since we wanted to start by defining this feature end to end in a separate spec, I'd love to get the hooks put in. If later on we think it makes sense to pull this back into HTML, SVG, CSS, we can integrate those changes back.
Ilya: I had a question about postpone. For the postpone attribute its only defined visibile elements. Have we concerned making it available on a container element? Many times on the mobile web, we will have entire content inside a div. E.g., I may display:none the entire div. It would be great if I could display:none the entire element.
Jatinder: There were issues with CSS properties setting on a div because formatting doesn't come until later. We could consider doing this on a container level.
ACTION Jatinder to add postpone to container elements that visible elements can inherit
<trackbot> Created ACTION-126 - Add postpone to container elements that visible elements can inherit [on Jatinder Mann - due 2013-12-18].
Spec: https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/NavigationErrorLogging/Overview.html
Jatinder: Aaron raised the issue
with the reporting retry logic causing a DDOS. There was a
suggestion that no retrying will solve the DDOS problem:
http://lists.w3.org/Archives/Public/public-web-perf/2013Dec/0063.html.
Is this okay by our customers? Should we limit the no retrying
to the same origin (origin with the error)? Likelihood of an
error on a navigation on one domain and an error on a posting
to another at the same time seems low.
... Seems like we're okay, since another user will probably hit
the site anyway.
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) No ScribeNick specified. Guessing ScribeNick: JatinderMann Inferring Scribes: JatinderMann Default Present: [Microsoft], +61.2.900.8.aaaa, +1.971.270.aabb, +1.650.214.aacc, Plh, mnot Present: [Microsoft] +61.2.900.8.aaaa +1.971.270.aabb +1.650.214.aacc Plh mnot Chase Douglas MNot JatinderMann Ilya plh WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 11 Dec 2013 Guessing minutes URL: http://www.w3.org/2013/12/11-webperf-minutes.html People with action items:[End of scribe.perl diagnostic output]