[minutes] Web Performance WG Teleconference #122 2013-12-11

Meeting Summary:



1.       User Timing and Performance Timeline to Recommendation

We are on track to publish User Timing and Performance Timeline as W3C Recommendations tomorrow.



2.       Timing API

Considering the discussion on the mailing list regarding connection speeds, the working group would like to see byte size information added for both Navigation Timing Level 2 and Resource Timing Level 2. In the discussion we considered adding both byte size and compressed byte size information; I will share a proposal on the mailing list. Mark Nottingham is also working on a proposal to include protocol information for both specs and will share that on the mailing list as well.



3.       High Resolution Time

We have made updates to the High Resolution Time L2 based on last call feedback to remove the [NoInterface] keyword. We are investigating if we should change the name of the WorkerPerformance interface to Performance. Otherwise, we haven't received any additional feedback from the Last Call period, as was expected.



4.       Beacon API

We spent quite a bit of time discussing the Beacon limits in today's call. The reason we are even considering limits is the fear that large data uploads may compete for resources with the next page navigation resulting in a potential load time regression. However, this concern may be theoretical and not real, as we haven't yet seen a real world example of XHR being abused in a similar way; XHR has no limits on uploads. To avoid this type of scenario the user agent can be smarter about sending small beacons immediately and waiting to send larger beacons when there is less resource contention. To protect against the extremely large beacon case, we would expect all user agents will internally have a very large limit. Finally, every limit size we have so far considered seems to always break someone's scenario (E.g., we have considered 8K, 10K, 24K, and 30K limits only to find that would break someone's scenario). A limit may not future proof this API from trends where larger beacons may be sent in the future.



5.       Resource Priorities

There is a discussion in the WHATWG around loading and executing scripts, http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Aug/0277.html. As this proposal may have an impact on Resource Priorities, we should review it. Additionally, Ian can help provide hooks into the HTML processing models for the lazyload and postpone behavior around the load event. This will help use better specify that behavior in the spec. We are hoping to continue working on the Resource Priorities spec as is and eventually can consider either leaving the spec separate or integrating the details back into HTML, SVG, and CSS.

Ilya also raised a concern that postpone should be able to be set on container elements that aren't visible, like the div element. This way users can set postpone on the container instead of setting it on each individual element. Seeing that using CSS won't work as formatting occurs much later in the pipeline, this seems like a reasonable request.



6.       Error Logging

We discussed an issue Aaron raised on the mailing list regarding reporting retry logic causing a DDOS. We wanted to make sure everyone was okay with the suggestion to not retry sending the error data: http://lists.w3.org/Archives/Public/public-web-perf/2013Dec/0063.html.



7.       Conference Calls during Holidays

To accommodate the holidays, we are cancelling the conference calls for the rest of the month. Our next conference call is scheduled for January 8th, 2014. Happy Holidays!




W3C Web Performance WG Teleconference #122 2013-12-11





IRC log: http://www.w3.org/2013/12/11-webperf-irc



Meeting Minutes: http://www.w3.org/2013/12/11-webperf-minutes.html



Attendees

Philippe Le Hegaret, Jatinder Mann, Ilya Grigorik, Mark Nottingham, Chase Douglas


Scribe

Jatinder Mann



Agenda
1. Discuss Timing APIs
2. Discuss High Resolution Time L2
3. Discuss Beacon
4. Discuss Resource Priorities
5. Discuss Error Logging



--------------------------------------------------------------------------------



Minutes:
Timing APIs

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.
High Resolution Time L2

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.
Beacon

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.
Resource Priorities

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].
Error Logging

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.