[minutes] Web Performance WG Teleconference #121 2013-12-04

Meeting Summary:



1.       User Timing and Performance Timeline to Recommendation

Philippe mentioned that these two specifications are expected to be published as Recommendations next week. Awesome!



2.       Beacon API

We had a good discussion on some of the open issues on the Beacon spec, including beacon failures, limits, and retrying. We have received feedback that developers are interested in knowing whether the beacon attempt has succeeded or failed to be sent. As it's hard to provide that information if this API is asynchronous and being called during the unload, we discussed potentially providing beacon error data in the Error Logging specification. We also noticed that the spec has to be adjusted to synchronously check the data package and fire limit size, quota size, and other errors before scheduling an asynchronous task to send the data.



As for limits, the working group still needs to determine what kind of limits we want to set on the beacons. We need to make sure that whatever limits we set are able to accommodate our use case. We will continue that discussion on the mailing list.



For retrying beacons, we feel that it's reasonable to have an interoperable retrying logic such that analytics data isn't skewed in favor of the implementations that retry more than others, however, obtaining appropriate retrying logic may need to wait until we have implementations. E.g., answering questions like is retrying 5 times really much better than retrying 3 times may have to wait until we have implementations.



3.       Networking Hints

We also discussed some of the new concepts raised in the networking hints proposal. There are some concerns that we may have too many options and users may not adopt some of the hints. Ilya will provide use cases for each of the hints to help make the expected usage more clear. There were also concerns that preload may allow developers to shoot themselves in the foot (e.g., a developer may try to download images before CSS). We will work through the issues on the mailing list.



4.       Progress on TPAC Action Items

Arvind helped close Actions 114 and 115 on the Beacon spec, ACTION-114: Update beacon spec to have no limits, no retry logic, no batching, post is the only method and ACTION-115: Can beacon response set a cookie and if so, is it treated as a first or third party cookie write. Philippe closed ACTION-124: Change the teleconf time for 3pm est. We will continue working on closing our remaining action items.



5.       Conference Calls during Holidays

To accommodate the holidays, we will schedule a conference call for December 11, 2013 next week and will resume scheduling our conference calls next year.




W3C Web Performance WG Teleconference #121 2013-12-04





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



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



Attendees

Philippe Le Hegaret, Jatinder Mann, Arvind Jain, Ilya Grigorik


Scribe

Jatinder Mann



Agenda
1. Discuss Beacon API open issues
2. Discuss Networking Hints
3. Discuss Page Visibility
4. Conference Calls during Holidays



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



Minutes:
Beacon

Jatinder: Personally, I like having a separate beacon API compared to just extending XHR. XHR is very complex. E.g., what if I set the sync flag and beacon flag on a XHR? Seems like having a separate method may just be much easier.
... I'm okay with limits if they are relatively large enough to cover our use cases and are a should clause. That way the User Agent has flexibility in increasing if needed, but good developers may try to stick with the suggested limits. From TPAC, seemed like 24K was still necessary.

Ilya: We still need to determine what the actual limits should be, and what about about rate limiting?
... What about just using the XHR?

Plh: What about using our error logging spec?

Arvind: I was thinking about that as well. Navigation Error Logging could potentially show the beacon loss data.
... I had a question about what we mean by synchronous vs. asychronous in terms of beacon?

Jatinder: Synchronous we would actually send the data and then return the call. Async means we create an async task and return immediately.

Arvind: The processing model actually queues the task async, but it throws exceptions. That seems wrong. IT should either throw the exceptions synchronously first or not throw exceptions.

Jatinder: Right.

Ilya: Right.

Arvind: Jonas wanted to know if the browser sent the beacon.

Ilya: I think he wanted to know if it was eventually sent.

Arvind: I think we should be able to synchronously check the size and throw an error if its exceeded.

Jatinder: I think thats a reasonable suggestion.
... Do XHRs have a limit?

Ilya: No.

Arvind: I think we should keep talking about the size limit on the thread.
... I generally like the idea of keeping the beacon api seperate from xhr, but i don't think we need to close on this now.

Jatinder: We still have an issue of specifying retrying?

Ilya: There are a lot of issues with retrying, many cases to consider. E.g., connection error may occur, and the UA could retry. The error logging may help here.

Arvind: No matter what you do will be a best effort.
... We just want to make sure the browser is making a reasonable effort.
... Even with a synchronous method, data can fail to reach the server.

https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/Beacon/Overview.html

"This method does not provide any information whether the data transfer has succeeded or not, as the data transfer may occur after the page has unloaded. To be still an effective mechanism for developers, the User Agent should make the best effort to transmit the data including making multiple attempts to transmit the data in presence of transient network or server errors, even though it uses POST to transmit the data. "

Arvind: We should determine if there is a problem with retrying.

Ilya: I don't have good data to quantify the data today. Like if we didn't retry what would be the success rate.

Arvind: I think Jonas point was why would we perclude retrying?

Jatinder: I dont think we say do not retry. I think that depends on quality of implementations. Whats not clear is how many times should we retry?

Ilya: We may want to prototype this and see what's a good limit.
... But that may need to wait until we have implementations.

Jatinder: Seems like we should have best effort now, and then when we implement we'll have better data on what's a good level of retrying. I think we need to have an interoperable retrying behavior so that users get the same success level across browsers.

Ilya: I think that works.

Jatinder: We should continue our discussion on the mailing list.
Networking Hints

Jatinder: Preload sounds like "high priority". I worry that by allowing developers to specify which resources are high priority, we may infact get a slower page load. E.g., browsers already order have an order in which they attempt to download resources. E.g., what if the developer wants to download an image before their CSS? We went with lazyload/defer in Resource Priorities as the very reason to stay away from giving the high priority hint, a[CUT]
... suggestion is trying to do exactly that.

Ilya: Some developers can shoot themselves in the foot, but they can already do that today using script tag to download images. We had implemented subresource and found that there were issues were folks were putting images to higher pri than css as an example. We were thinking of providing the element type to the link.

Jatinder: We really want to make sure that developers don't shoot themselves in the foot. It'd love to see use cases.
Page Visibility

Jatinder: What changes did you make to the L2 spec?

Arvind: I removed the offscreen state, I added some examples, and cleaned up some of the text.
Holidays

Jatinder: When should we schedule the next conference call?

Arvind: Considering there is interest, let's meet next week and cancel the rest of the year.

Jatinder: Works for me.
User Timing and Performance Timeline to Recommendation

plh: I'm planning on publishing these two specs to Recommendation next week.

Jatinder: Great!