[minutes] W3C Web Performance F2F Meeting 11/14/2013 - 11/15/2013

W3C Web Performance F2F Meeting 11/14/2013 – 11/15/2013

These are the meeting minutes from the Web Performance Working Group face to face meeting during TPAC 2013 in Shenzhen, China.


IRC log:

http://www.w3.org/2013/11/14-webperf-irc


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




Attendees

Jatinder Mann (Microsoft), Jason Weber (Microsoft), Arvind James (Google), Alois Reitbauer (Compuware), Philippe Le Hegaret (W3C), Mark Nottingham (Akamai), Anne van Kesteren (TAG), Simon Stewart (Facebook), David Burns (Mozilla), KKubota (NTT), Pan Deng (Intel), Lei Xue, Sam (Foxconn), PMSangal, Thinker, Ted O’Connor (Apple), Ryosuke Niwa (Apple)



Chairs
Jason Weber, Arvind Jain



Scribe

Jatinder Mann, Philippe Le Hegaret



Agenda

1.     Prerender

2.     Beacon

3.     Resource Priorities

4.     Page Visibility

5.     High Resolution Time

6.     Navigation and Resource Error Logging

7.     Resource Timing

8.     Performance Mini-Workshop

9.     JavaScript Pre-Flight

10.   HAR

11.   New Specifications

12.   Next Meeting





Meeting Summary
-------------------------------------------



1.    Prerender

The Working Group agreed that the HTML5.1 spec should defined the ‘prerender’ and ‘dns-prefetch’ link rel types, as the HTML5 spec has already defined ‘prefetch’. Currently, these two types are defined in the registry: http://microformats.org/wiki/existing-rel-values. The WG would prefer if these values are defined in the HTML5, however, the feedback from the HTML5 WG has been that we can only do that if we define this feature in a separate extension specification, show two interoperable solutions via test cases, and move that extension spec to CR by Spring 2014. The WG is considering whether to consider writing an extension spec or just keep this definition in the HTML5.1 spec.



Ilya had proposed that we also standardize preconnect, subresource, and dns-prefetch, along with specifying additional details on prerender. The WG felt that we should leave many of the prerender specifics to the user agent, and also didn’t feel there was strong value in defining a preconnect or subresource phase. Seeing that most browser vendors already support dns-prefetch, the WG would like to see this feature standardized.



2.    Beacon

The WG spent some time discussing the goals of this specification. Eventually, we decided that the beacon spec should focus on solving the problem of sending data synchronously during page unload and other times in the page’s lifetime. To that end, we opened ACTION-113 - Update beacon use cases to just be the asynchronous data sending case to update the use cases to only include asynchronous data sending.



The WG discussed whether we should apply a limit to the number of beacons that can be sent or the size of the beacons sent. While we had initially considered a limit of 10KBs, after some discussion, we saw real world examples of much larger data being sent. We eventually decided to not limit the size of the beacons, as limits set now may not feel rational years from now. We opened ACTION-114 - Update beacon spec to have no limits, no retry logic, no batching, post is the only method to track this.



In line with the new goals, the WG also decided to limit the HTTP methods to only POST. We also did not want to include any logic on retrying or batching, as we felt that it will be hard to get that right and interoperable. We will instead leave these details to the quality of implementation. We also wanted to allow the beacon to set a cookie. We opened 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.



3.    Resource Priorities

The WG decided that having a CSS property for Resource Priorities doesn’t make sense as most browsers will don’t even download resources from CSS until the formatting step is completed. Additionally, there were concerns with postpone. The WG agreed to scope the spec back to lazyload and work from there.



The Web Perf WG also presented the Resource Priorities topic to the HTML5 WG to increase awareness of this work. Members of the SVG WG did ask to be included in future Resource Priorities discussions that impact SVG elements.



4.    Page Visibility

Folks from the Web Driver WG have been trying to solve the problem of determining when an element is display/visible and were interested in using an Element Visibility API if the Web Perf WG develop it. We spent quite of a bit of time discussing that true visibility on the display is not easy to determine even for the user agent, though, layout visibility may be something more easily determined and a reasonable substitute. The WG agreed to continue this discussion on the mailing list and future conference calls.



5.    High Resolution Time

There was feedback that the spec didn’t need to use the [NoInterfaceObject] keyword. Otherwise, the WG has agreed to move the High Resolution Time Level 2 specification to Last Call.



6.    Navigation and Resource Error Logging

The WG received feedback that we should make sure to do a review with different security teams to make sure this proposed API does not create new security or privacy attack vectors. Particularly, we need to check if sharing detailed error codes or even general error codes will be a problem. The WG agrees that this API is most useful when giving detailed error codes, but we felt that given general error codes at least lets you know a problem is happening. We have opened ACTION-116 - Do review to see if sharing these network errors is a security or privacy concern and plan to share this specification with a number of security teams, including those that may be present in the W3C.



We also received feedback that the Error Logging specifications should be able to send data to a third party URLs, using a CSP method. The error in the document navigation may reflect same origin server issues, so sending data to a third party URL makes sense. See ACTION-117 - Add method to allow ability to send to a third party url using csp



We have asked Mark Nottingham to review the error list and reduce it down, ACTION-118 - Review the error list and reduce it down.



7.    Resource Timing

The WG reviewed and resolved all issues listed in our CR issues list: http://www.w3.org/2013/11/cr-resource-timing.html. The spec had already been updated to fix some of these issues. We agreed that the test suite should include a 404 error test case.



On the issue of defining an EventTarget for the Performance object, to support the onresourcebufferfull event, we decided that Navigation Timing L2 will redefine the Performance object and extend EventTarget and Resource Timing will reference Navigation Timing L2. When Navigation Timing L2 reaches Recommendation, we will deprecate Navigation Timing L1. As the L2 spec was designed to replace the L1 spec, we feel this course of action makes sense. See ACTION-119 - Update resource timing to use navigation timing l2.



For Resource Timing L2, we want to include web workers support, protocol information, and potentially more interesting data like byte size. We will continue discussions on the mailing list and conference calls on these L2 features. We have opened ACTION-125 – Come up with a HTTP2 Proposal for RT L2 on Mark Nottingham to investigate what the protocol information should look like in Resource Timing L2.



8.    Performance Mini-Workshop

At the Performance Mini-Workshop, we had four presentations:



-       Web power measurement, Pan Deng (Intel)

Pan covered how Intel currently measures power and the benefits of sharing this data with developers. Slides: https://docs.google.com/presentation/d/1lpOlTtq93XtPCtZNsX00zmSJ6idO79I6SHkzMJKLUzU/edit?usp=sharing




-       Power Improvements in OSX Mavericks, Ted O’Connor (Apple), Ryosuke Niwa (Apple)

Ted and Ryosuke spoke about some of the power improvements made in the OSX Mavericks operating system as well as the latest Safari browser.



-       Benchmark for SPDY and HTTPS, Kensaku Komatsu, Sho Yamamura (NTT Communications)

NTT Communications shared data on their analysis of SPDY and HTTPS performance. In their research, performance for SPDY and HTTPS are reversed when NW conditions (e.g. latency, loss late) and resource size changes.



-       What can browsers do for JS game developers?, Kang-Hao (Kenny) Lu (Opera)

Kenny covered some interesting performance improvements JavaScript game developers should consider, http://lists.w3.org/Archives/Public/public-web-perf/2013Nov/0052.




9.    JavaScript Pre-Flight

The WG generally felt that the JavaScript pre-flight injection idea holds promise. Jason, Arvind, Mark, and I will all follow up and provide deeper feedback to inform the spec. We have opened ACTION-120:  Get preflight feedback from google on Arvind Jain, ACTION-121:  Talk about preflight to mnot on Alois Reitbauer, ACTION-122:  Get preflight feedback from ms on Jatinder Mann to track this.



10.  HAR

A new version of the HAR spec is expected soon, with the HAR format more closely tied to Navigation and Resource Timing. Arvind will work on determining the licensing and IP considerations related to HAR, ACTION-123: Look into the licensing/ip situation related to har.



11.  New Specifications

Based on the workshop and other feedback, the WG discussed a few potential new spec ideas to consider going forward, which may already be covered in our current Charter:



-       Power API

Considering the interest in power, both Intel and Apple presented on power during the workshop, the WG wants to consider an API that can provide power information to the developer that is both actionable and accurate. We need the ability to track power on a per site basis or at the very least per process basis. Just providing system Joules usage isn’t actionable or useful, as different users will have different machine capabilities and applications running at a given time. The WG will investigate this area further in our conference calls and mailing list.



-       Background Tabs

Based on the WG discussion, it appears that most browsers and systems, including IE, Firefox, Windows, OSX, Android, are doing activities to minimize power impact when a page is in the background. These activities include throttling timers, coalescing timers, serializing data to disk and suspending pages. While these are good activities to preserve power and improve battery life, from a developer’s perspective these activities aren’t always predictable or expected. The WG is considering standardizing guidance for user agents on the expected behavior when the page is in the background. This includes potentially providing a JavaScript event or notification to inform the site that they will be going into a “suspended” state. The WG will continue this discussion in our conference calls and mailing lists.


-       Data Compression JavaScript API

Today bytes sent from the server to the user agent are gzipped to minimize the number of bytes sent on the wire. However, data that the user agent sends to the server isn’t. The WG would like to investigate if the power benefit of sending fewer bytes outweighs the CPU cost of compressing data through a JavaScript API. Theoretically, it seems like there are many cases where the CPU cost will be too high. However, the WG would like to carry out experiment to understand if there is a window where compressing data makes sense. If that window is large enough, the WG may consider a JavaScript API to Gzip content. This will definitely be 100x faster than if a library tried to carry out that operation in JavaScript.



12.  Next Meeting and Conference Call Times

In order to better accommodate all of our members, the WG has decided that it will now hold a conference call every alternating Wednesday (or on a weekly basis depending on the number of agenda items we have) at 3PM EST, Philippe will follow up with ACTION-124: Change the teleconf time for 3pm EST.



The WG has also decided to hold its next Face to Face meeting in the Bay Area next June. Google has offered to host the meeting again.





Action Items

--------------------------------------------------------------------------------
ACTION-112: Include prerender, dns-prefetch in html5 spec and consider preconnect as well on Jatinder Mann, https://www.w3.org/2010/webperf/track/actions/112

ACTION-113:  Update beacon use cases to just be the asynchronous data sending case on Jatinder Mann https://www.w3.org/2010/webperf/track/actions/113

ACTION-114:  Update beacon spec to have no limits, no retry logic, no batching, post is the only method on Jatinder Mann, https://www.w3.org/2010/webperf/track/actions/114

ACTION-115:  Can beacon response set a cookie and if so, is it treated as a first or third party cookie write on Arvind Jain, https://www.w3.org/2010/webperf/track/actions/115

ACTION-116:  Do review to see if sharing these network errors is a security or privacy concern on Jatinder Mann, https://www.w3.org/2010/webperf/track/actions/116

ACTION-117:  Add method to allow ability to send to a third party url using csp on Arvind Jain, https://www.w3.org/2010/webperf/track/actions/117

ACTION-118:  Review the error list and reduce it down on Mark Nottingham, https://www.w3.org/2010/webperf/track/actions/118

ACTION-119:  Update resource timing to use navigation timing l2 on Jatinder Mann, https://www.w3.org/2010/webperf/track/actions/119

ACTION-120:  Get preflight feedback from google on Arvind Jain, https://www.w3.org/2010/webperf/track/actions/120

ACTION-121:  Talk about preflight to mnot on Alois Reitbauer, https://www.w3.org/2010/webperf/track/actions/121

ACTION-122:  Get preflight feedback from MS on Jatinder Mann, https://www.w3.org/2010/webperf/track/actions/122

ACTION-123:  Look into the licensing/ip situation related to har on Arvind Jain, https://www.w3.org/2010/webperf/track/actions/123

ACTION-124:  Change the teleconf time for 3pm et on Philippe Le Hégaret, https://www.w3.org/2010/webperf/track/actions/124

ACTION-125:  Come up with a HTTP2 Proposal for RT L2 on Mark Nottingham, https://www.w3.org/2010/webperf/track/actions/125






Meeting Minutes

--------------------------------------------------------------------------------
Prerender
Jatinder: should HTML5 include prerender?
... feedback is that we should just consider doing it on microformats
... but it seems worthwhile to have it part of the spec
... one feedback
... around if you replace the current browsing context
... if you lose "replace" you lose such constraint
Jatinder: Based on the bug, this was accepted to be added to HTML5.1. Are we okay with moving to HTML5 or leave it HTML5.1
Plh: We will need to give test cases if we want this put in. Are we okay with just leaving this?
Arvind: Ilya raised a resource hints proposal on preconnect, preload, prerender

<JatinderMann_>  http://lists.w3.org/Archives/Public/public-web-perf/2013Nov/0043.html

Arvind: As we had discussed in the past, we may want to keep some of this as browser optimizations
Jason: Some of these are environment specific optimizations. I'm not sure we want to require browsers to explain all the details.
Arvind: What's preload and preconnect? Are these new?
Jatinder: It's unclear if some of these are just renaming prefetch or something new.
Plh: It might be worthwhile to specify this in the spec so developers know what to expect
Jason: Depending on environment, like if you're on 3G, you may not want to do these optimizations.
Arvind: Ilya just asked questions here, there weren't any recommendations on the number. As Jason mentioned, the number of connections is hard to specify depending on device and environment. I recommend we just leave it as is, but if someone can justify having a specific number then we can add it to the them.
Jatinder: Prefetch is already defined and so is prerender. Are we really trying to define a preconnect
Jason: IE already has an internal database where its checking when to do a preconnect. It doesn't make sense to have a developer give this hint.
Arvind: in some cases the browser may not get to a resource fast enough, with a hint we can do something sooner. If you take an example of search engine, it can potentially benefit by specifying a preconnect.
Jatinder: But at parse time the browser will encounter the preconnect attribute at the same time as it encounters the URL.
Jason: this may be more useful for the second page.
Arvind: This might be a very light weight version of prerender.
Arvind: We should make sure this that the spec includes this. The registry includes prerender and the spec includes prefetch.
Jason: IE supports preconnect on a heuristics base. I believe it’s some 80% hit rate of determining which one is going to be preconnected
Jatinder: Are we leaning towards defining preconnect?
Jason: I would caution because the developer may shoot themselves on the foot.

<JatinderMann_> dns-prefetch
<Arvind> https://docs.google.com/presentation/d/18zlAdKAxnc51y_kj-6sWLmnjl6TLnaru_WH0LJTjP-o/present#slide=id.g33211238_0_2

Arvind: Based on Ilya's slides, there is "dns-prefetch", "prefetch", "prerender", "subresource". At least "prerender" and "prefetch" are supported everyone. "subresource" is unnecessary
Jatinder: I don't think there is any web developer value in giving the specifics on when the browser prerenders. The goal is to have the developer give the web browser a hint.
Arvind: I think we should wait and see if others have more concrete requirements.
Arvind: We should decide on whether or not we should define more states.
Arvind: Looks like some of us aren't happy in defining too many more.
Jason: As of IE11, we support the dns-prefetch tag.

<Arvind> values
<Arvind> http://microformats.org/wiki/existing-rel-values

Arvind: Looks like we currently have prefetch in the HTML5 spec, prerender and dns-prefetch is in the registry.
...I think it makes sense to bring in preconnect if dns-prefetch is there. dns-prefetch is the lowest cost, preconnect is a bit more work where we're opening the connection, prefetch will download the resource end to end, and prerender navigates to the page. Seems like it makes sense.
Jatinder: We should discuss with HTML5 WG to include dns-prefetch and prerender.
Arvind: We should discuss all four with the HTML WG.
Jatinder: ACTION Jatinder include prerender, dns-prefetch in HTML5 spec and consider preconnect as well

<trackbot> Created ACTION-112 - Include prerender, dns-prefetch in html5 spec and consider preconnect as well [on Jatinder Mann - due 2013-11-21].
Jatinder: That's all of our open items. Does anyone else have any other questions?
thinker: I worry if prerender can be used for denial of service type attacks
Arvind: The page can always do a DoS attack. You can always just add the second frame as an iframe already. That will accomplish the same thing.
thinker: I think we should put same origin restrictions.
Arvind: Most of the current use cases are for cross-origins, e.g., a search engine would use the cross-origin prerenders. Both Microsoft and Google are using this in their search engines. I don't think this creates any new surface area because you can already do this.
Jason: There are two parts of this privacy and security. There isn't a new attack vector here just as Arvind mentions. The second problem is using up user's resources by prerendering excessively. I think that's up to the User Agent to be smart
...about how it prerenders. Chrome and IE both limit the prerenders.
Beacon
Arvind: We should probably start by talking about the goals of beacon and what isn't already solved by XHR.
Jason: What I'm most excited about beacon is asynchronously sending data when its convenient. Today sites are using XHR by blocking the site's unload to send the data.
...This is super ugly because it destroys power and perf. The browser internally can try to do optimizations, but it has to do continue doing work in the background.
Jatinder: I would also mention that it really slows down the navigation of the next page. And there is nothing the next page can do.
Alois: What many people are doing is abusing the img element to send the data, or a sync XHR to really guarantee sending the data. The problem that beacon should solve is sending the data reliably without blocking the page.
Arvind: I agree that XHR doesn't solve this problem and beacon can solve this and is sufficiently different.
Arvind: I agree with the use case of reporting statistics without blocking the page. The use cases that I don't agree with are the battery usage or getting data.
...There was some suggestion that if you want to batch sending data, we may want to develop a resource batching mechanism that XHR can benefit from.
Alois: I feel like a lot was brought into the spec, like the battery case and sending a lot of background data. I think we should scope.
Jatinder: Philippe raised that some people were interested in abusing to use this send large amounts of data.
Arvind: Let's start by talking about the size limitations.
Arvind: Fixed values may look silly in the future.
Jatinder: Does XHR have a limit?
Arvind: No.
Jatinder: But XHR doesn't live after the page has gone away. But beacon can survive.
Arvind: 10K is too small.
Arvind: Uploading 10GBs will cost you money on your mobile page. So I see a point here.
Arvind: The current solution of spinning is the worst case, as it blocks the unload and you can send as much data as you want.
Alois: We can also not include this in the spec, but the browser fails silently.
Plh: I don't think we should put a limit in the spec, but should be allow the ability to query data.
Daniel: The upload speeds are slower than download speed. PayPal are a serial XHR abuser. What we've found is that the omniture data is lost. The third point is that we've seen in the past serious abuse where we did not specify limits. Initially there weren't any limits on cookie data and people were sending 65K data. UAs started adding arbitrary limits on cookies. We have lost a lot of money as this, because some of our users weren't able to send.
...I think we should specify a limit. I just checked how much 25K with 6 different XHRs. Let's set a limit but keep it a rational limit.
Arvind: Should the limit be applied at a page level or function level?
Daniel: It should be on a page level. We make multiple calls to omniture. Maybe some of the service worker framework some of this can be used.
Arvind: What about a way to query?
Plh: I don't think it was a good idea after all.
Jason: Agreed.
Daniel: Agreed.
Alois: What about single page applications? After 20 minutes you can't send any more data.
Daniel: We should set the limit to kilobytes rather than megabytes, especially from a mobile operator point of view.
Jason: We are developing a general purpose platform. We should be careful to set limits.
Jatinder: We have to keep in mind that we want to keep adoption of this API and have people move away from XHR.
Arvind: Practical example. In Google we track clicks using ping when people are clicking on links. Even minor amounts of data loss, you may not use it.
Daniel: I want my developers to use good practices, but real large scale companies can easily abuse this. I can commonly see marketing folks add yet another analytics data they want to send up. If managing bandwidth should be up to us.
Jatinder: Arvind mentioned whether this should be limited to unload or else. I think this should be a general purpose async method that can be called at any time in the page.
Alois: We have found that data is sent at many times in the page, though unload is most common. I think we should be sent at any time.
Arvind: I agree as well.
Arvind: I don't think we should add any batching details in the spec about battery life.
Jason: I think when you send the beacon, the UA adds the beacon to a queue to send as soon as it can asynchronously send. It should be lower priority than other items.
Arvind: I agree with that. I think the spec should remove the battery life use cases.
ACTION Jatinder update beacon use cases to just be the asynchronous data sending case

<trackbot> Created ACTION-113 - Update beacon use cases to just be the asynchronous data sending case [on Jatinder Mann - due 2013-11-21].
Arvind: Let's talk about retry. XHRs don't retry right?
Alois: Yep, they just return a failure code, doesn't retry.
Arvind: I think we all agree that we shouldn't return a return code.
Arvind: What are the retry semantics?
Jason: We should leave this to the quality of implementation.
Arvind: The mechanism has to be robust to actually use it.
Alois: The browser may crash not an issue, the server may not be able to accept that's okay too. What about when there is no internet connection.
Alois: I think after 10 minutes the data is useless anyway. Some marketing folks may want to hold data longer.
Jason: I recommend we leave the text quite general and let the user agent may try best effort while maintaining privacy and security.
Arvind: We may want to add examples in the notes.
Daniel: I just checked what our PayPal beacon does on my mobile device. It is 26K. It's using Google Analytics and Omniture.
Daniel: We will just not use beacon if it has 10K limit.
Jason: Let me give an example of data URI. Initially it has a 32k limit. We were spec compliant it was great. But developers were sending larger data URI and IE was failing. Now we have a larger limit and sites work. I don't think we should add any limits. Let the browser set the limit.
Arvind: We have closed on a few issues. The beacon should have no limit. The spec shouldn't specify retry logic, but we may consider adding a note in the future. The spec should remove batching logic.
Arvind: I also don't think we should include get. This adds complexity. It’s not the common use case.
Arvind: I think POST should be the only method.
Alois: I think we should limit to POST as well.
Jatinder: Let's solve the problem we intended to solve. Let's only stick with POST.
ACTION Jatinder Update beacon spec to have no limits, no retry logic, no batching, POST is the only method.

<trackbot> Created ACTION-114 - Update beacon spec to have no limits, no retry logic, no batching, post is the only method. [on Jatinder Mann - due 2013-11-21].
Daniel: I just checked, and Microsoft.com uses 22KB beacon.
Daniel: Best effort felt like the best security and privacy method.

<renoirb> Suggestion: How about allowing HEAD too, backend might not want to have to create a full document.
Arvind: There can be DNS failure, connect failure, server failure. What should you try for these?

<renoirb> Forget about it, sending state update using only URL would not be sufficient.
Arvind: For server busy, I may want to try once or twice right away. We have done some data analysis on this where we found that a single retry significantly increases reliability (e.g., if you have a 1% failure rate and you retry once, you'll have a 0.5% impact).
Arvind: I think a random retry for all of these failures may be worthwhile.
Daniel: I know some data carriers block uploads while you're on the call. So it blocks that.
ACTION Arvind Can beacon response set a cookie and if so, is it treated as a first or third party cookie write

<trackbot> Created ACTION-115 - Can beacon response set a cookie and if so, is it treated as a first or third party cookie write [on Arvind Jain - due 2013-11-21].

Resource Priorities



<myakura> https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourcePriorities/Overview.html


<Daniel_Austin> adding a link to the Serviceworker proposal to the notes - of possible interest for the beacon discussion: https://github.com/slightlyoff/ServiceWorker/blob/master/explainer.md


Alois: If you have a postpone on the background image, we don't know that the element is visible yet until we do styling.

Jason: IE doesn't even download the resources from CSS until the formatting is done.

Jason: I think we should remove the postpone CSS property as the browser will already do this work.

Anne: In many cases, it’s hard to know when the image will be in the page.

Jason: Seems like there is agreement that there is a need for lazyload / postpone, but there may be some confusion in the spec.

Anne: I think I agree with that.

Jatinder: Looks like we need to remove the CSS property.

<Alois> preload none on video http://www.w3schools.com/tags/att_video_preload.asp


Jason: I think we should scope this to lazyload and then consider adding postpone later on in an Level 2 based on feedback.

Anne: I think we should consider starting with lazyload. For example, the user agent could interpret lazyload to mean postpone based on data.

<masatakayakura> https://github.com/slightlyoff/ServiceWorker/blob/master/explainer.md


<slightlyoff> I can be summoned by meme...

<slightlyoff> ;-)

Jatinder: Off to lunch break.

<simonste_> Hello

<annevk> \o/

<annevk> wb
Page Visibility

Simon: The WebDriver spec had a bash at attempting to define visibility: http://www.w3.org/TR/webdriver/#determining-visibility


Jatinder: We need to define visibility in Level 2 spec. Is it fine to tie visibility to the viewport or the users agent's interpretation of the viewport.

Jason: We should tie it to the viewport, which is what the user sees. Tying it to the user agent's internal interpretation just seems to add complexity.

Arvind: I think we need to cover give more details on the definition, including display:none.

<pmsangal> Hi. Is there a phone bridge, for TPAC, that I can dial into?

Simon: We need to define element visibility for Web Driver.

<Arvind> http://lists.w3.org/Archives/Public/public-web-perf/2013Oct/0031.html


<plh> pmsangal, yes, there is

<plh> pmsangal, we're on the bridge now

<pmsangal> thanks, I'll dial in

Simon: We should really call our spec as displayability, instead of visibility.

Jason: From the advertising point of view, they want proper element visibility that gives them with high confidence that the ad is on or off screen.

<pmsangal> ok I'm in, but I don't hear anything. Is the line muted?

<plh> nope, it's not muted :(

Simon: I'm finding this flash discussion really interesting.

<plh> oops

<plh> we got dropped

Jason: Today, advertisers use many techniques to determine visibility, including flash.

Jason: We can probably define it as a layout level displayable, but I don't know if I'd call it visibility.

<plh> pmsangal, I muted you since we were able to hear you

<pmsangal> Sorry about that. I'm in now, thx

<plh> it's a big room and not everybody is sitting next to the polycom :(

Arvind: I think element visibility is harder. I rather think about iframe visibility.

Anne: Isn't it the same issue as element visibility?

<pmsangal> plh: np, I'll try for some time. If I can't make out what's happening, over the phone, I'll drop off and attend the next TPAC in person :)

Jason: From a display point of view, it's the same problem.

Simon: One other thing to keep in mind: http://dev.w3.org/csswg/cssom-view/#extensions-to-the-document-interface


Simon: The intention here is that "getElementFromPoint" would return the top-most "visible" element. With a slightly better nuancing.

<AutomatedTester> simonstewart: it returns the hittable element

<simonstewart> Right

<simonstewart> s/"visbible" element/"hittable" element/

Jatinder: For Page Visibility L1, when we say you are hidden, we are certain that you are hidden. When we say that you are visible, you may or may not be visible.

 Jatinder: Should we apply the same principal to the L2 spec?

Simon: that definition might well work for WebDriver. We already have a fairly loose definition of visibility.

Jason: You can give layout information like your width and display, but that's not necessarily what the display sees

Anne: We should follow up with CSS folks and see if they want to support this.

Jason: We can possibly provide the layout properties and let them know if there is a transform applied.

Jason: If you have an Ad in the center of the page. If you have the CSS transform to 1px, there is no way to make sure that the Ad is no visible, because that's happening on the GPU. So we can give layout coordinates and a Boolean api that lets them know if there are css transforms or other graphics techniques. This could be enough solution to solve the advertiser scenario.

Simon: The Web Driver could also use that potentially.

Jatinder: Is there a scenario where we want the current Page Visibility L2 spec where visibility is tied to the document and not the top level document.
High Resolution Time

<JatinderMann_>  https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/HighResolutionTime2/Overview.html


Anne: Can we remove the NoInterfaceObject?

Jatinder: Yes, I can remove.

Plh: Can we move to Last Call?

Jatinder: Yes.

<pmsangal> plh: np, I'll try for some time. If I can't make out what's happening, over the phone, I'll drop off and attend the next TPAC in person :)


Navigation Error Logging

Daniel: I prefer having detailed errors, not just the general errors.

Daniel: Today, we have to have many tools to determine error cases, I'm still going to be stuck with getting those errors. I don't think general errors are good enough, we need explicit errors.

...There were a number of proposals to solve this. We had looked at a bunch of different lists of errors, including POSIX.

...The POSIX spec doesn't define any of the errors in very specific ways, so different machines give different error numbers. I don't feel these lists are useful.

Jatinder: Does it make sense for us to define a list of errors we want to support in our spec?

<plh> http://lists.w3.org/Archives/Public/public-web-perf/2013Apr/0007.html


Anne: That's why we don't want to share errors in XHR. This topic has come up before many times before, and it's always been shot down.

<Daniel_Austin> http://lists.w3.org/Archives/Public/public-web-perf/2013May/0053.html


Anne: You may want to do a security review.

Alois: We may want to ask the security team both whether it’s a problem to share the detailed and not detailed security information.

<Daniel_Austin> http://lists.w3.org/Archives/Public/public-web-perf/2013Apr/0007.html


ACTION Jatinder Do review to see if sharing these network errors is a security or privacy concern

<trackbot> Created ACTION-116 - Do review to see if sharing these network errors is a security or privacy concern [on Jatinder Mann - due 2013-11-21].

Mark: There are issues that we need to consider about standardizing a list. How do we handle new errors that have been created. We may want to consider black or whitelisting errors in the registry.

Mark: Instead of having one field, we may have two fields to make it easier.

Jatinder: We are very open to API surface.

Jatinder: Which one of these errors are we not concerned with?

<JatinderMann_> http://lists.w3.org/Archives/Public/public-web-perf/2013Apr/att-0007/WebRequestStatusCodes4.html


Mark: 200s are fine, a lot of these are fine. Some of these that give more information on the user should be a problem.

Arvind: Some folks are Google are interested in reporting the errors to a different URL.

Alois: This makes a lot more sense. Because if you're going to see the problem after its fixed, then this API is useful.

Anne: Coordinate with the CSP guys.

Arvind: This would just be like report URI.

ACTION Arvind add method to allow ability to send to a third party URL using CSP

<trackbot> Created ACTION-117 - Add method to allow ability to send to a third party url using csp [on Arvind Jain - due 2013-11-21].

ACTION Mark to review the error list and reduce it down

<trackbot> Created ACTION-118 - Review the error list and reduce it down [on Mark Nottingham - due 2013-11-21].
Resource Timing

<JatinderMann_> http://www.w3.org/2013/11/cr-resource-timing.html


Arvind: We closed "A resource request without a network connection" feedback from James Simonsen.

Jatinder: Resource Timing doesn't include resources that have errors. So closing "Resource request: failure and success? (Andy Davies)"

Plh: We should include a 404 error code test to see if it is included in the resource timing

ACTION" mnot to come up with an HTTP2 proposal for RT

<trackbot> Created ACTION-125 – Come up with a HTTP2 Proposal for RT L2 [on Mark Nottingham - due 2013-11-21].

Jatinder: We will define Performance in Navigation Timing L2 and extend EventTarget. Resource Timing should reference Navigation Timing L2.

ACTION Jatinder update Resource Timing to use Navigation Timing L2

<trackbot> Created ACTION-119 - Update resource timing to use navigation timing l2 [on Jatinder Mann - due 2013-11-21].
Resource Timing L2

Jatinder: Should we define the JSON.stringify(performance) in a spec?

<JatinderMann_> http://lists.w3.org/Archives/Public/public-web-perf/2013Aug/0109.html


Anne: WE should define a JSON method.

<plh> http://w3c-test.org/webperf/specs/ResourceTiming2/


Plh: In the Performance Timeline L2 spec.

Jatinder: What about web workers support? Should be able to use performance.getEntries in web workers? Resources downloaded by web workers should be included? Should initiator type be web worker? Shared worker resources should be put in which timeline? The shared worker's timeline?

Anne: I think you should include workers as a separate iframe context. Email WebAppsSec to make sure they're on board.

Jatinder: I like the feedback. I'll share a proposal.

<plh> https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/PerformanceTimeline/Overview.html#terminology


Jatinder: What about protocol information?

Mark: We should just return the ALP protocols in the registry.

<mnot> http://tools.ietf.org/html/draft-ietf-tls-applayerprotoneg-03


Jatinder: Should we include byte size information?

Anne: Typically with Data URI we're worried about the size, because you have to go collect it.

Mark: There are so many interesting numbers with so many warnings.

Anne: Sites like Facebook may be interested in seeing what kind of content your different users are seeing.

Alois: especially for mobile cases, they maybe change the content.

<kennyluck> sangwhan, yeah. Is the mini-workshop starting?

<kennyluck> sangwhan, my slides is online ☞ http://dev.oupeng.com/wp-content/uploads/20131109-kennyluck-optimizing-js-games.html#namespace-object

JavaScript Pre-Flight

Alois: [explains the use case]

... we break pages by injecting JS in it

[Alois will give pointers to Jason about IE issue]

Alois: we do runtime injection

... script tag in HTTP header, ...

Jason: it fits into our charter

... this would help sites

.... help with cacheability

... a man in the middle attack can do this today

Alois: it would have to be sent with every request

... ie not cached

Jason: on the surface, it seems a good idea

... pretty trivial in most user agents

Alois:: header would only go for the root HTML

Jason: proposed next step: I'll talk to the SharePoint team

... we need to do research on our side

... and Arvind will see at Google

... Alois should talk to Mark Nottingham

ACTION: Jason to get preflight feedback from MS [recorded in http://www.w3.org/2013/11/14-webperf-minutes.html#action01]

<trackbot> Error finding 'Jason'. You can review and register nicknames at <http://www.w3.org/2010/webperf/track/users>.<http://www.w3.org/2010/webperf/track/users%3E.>

ACTION: Arvind to get preflight feedback from Google [recorded in http://www.w3.org/2013/11/14-webperf-minutes.html#action02]

<trackbot> Created ACTION-120 - Get preflight feedback from google [on Arvind Jain - due 2013-11-22].

ACTION: Alois to talk about preflight to mnot [recorded in http://www.w3.org/2013/11/14-webperf-minutes.html#action03]

<trackbot> Created ACTION-121 - Talk about preflight to mnot [on Alois Reitbauer - due 2013-11-22].

plh: if feedback positive, we'll contact public-script-coord

ACTION: Jatinder to get preflight feedback from MS [recorded in http://www.w3.org/2013/11/14-webperf-minutes.html#action04]

<trackbot> Created ACTION-122 - Get preflight feedback from ms [on Jatinder Mann - due 2013-11-22].

ACTION-122: Jatinder to get Jason to get preflight feedback from MS

<trackbot> Notes added to ACTION-122 Get preflight feedback from ms.

Alois: running it into a separate worker wouldn't cut it, since we want DOM access

... not just timing information

Jason: finding a proper name would be good

... let's stick with preflight for now
HAR

Arvind: there is a new revision of the draft coming by end of the month

Jason: having the spec documented, as a tool at least.

... we always talk about cutting "Web Archive" formats

Arvind: I wonder if it makes to have JSON in the saveAs

Jason: it's a dev tool option

plh: it's a waterfall

Arvind: HAR has more info that the Web performance object

... so toJSON isn't enough for HAR

... Andy will make the HAR format closely tied to nav timing and resource timing

Jason: chrome dev and HTTP archive supports HAR

Alois: and a few other tools

<Alois> HAR Spec: http://www.softwareishard.com/blog/har-12-spec/


Arvind: we're working with Ian

Arvind: let's see if it works out this time

ACTION: Arvind to look into the licensing/IP situation related to HAR [recorded in http://www.w3.org/2013/11/14-webperf-minutes.html#action05]

<trackbot> Created ACTION-123 - Look into the licensing/ip situation related to har [on Arvind Jain - due 2013-11-22].
f2f, workshop

Jason: I'd like to do in the bay area next year

... we socialize and reach out to companies

Alois: would make to get feedback on implementations

Jason: I'd like the format we used in November

... let's do it the day before or after

... I recommend a full day workshop

... then do a debrief

... 9-3 for the workshop, 3-5 for the webperf

Jatinder: if it doesn't fit, we'll do more

[Google will be hosting]

frequency of teleconferences

Arvind: making decisions on the phone are problematic

Jatinder: we can be async

Arvind: we're missing the history

Jatinder: I like to talk things out

... but yes, involved others would be good

... no one read minutes

... but we need to separate decisions

... let's meet, make good minutes, and have separate emails for decisions

[teleconference time]

ACTION: plh to change the teleconf time for 3pm ET [recorded in http://www.w3.org/2013/11/14-webperf-minutes.html#action06]

<trackbot> Created ACTION-124 - Change the teleconf time for 3pm et [on Philippe Le Hégaret - due 2013-11-22].
New specs

Jason: two things: power

... what can we do to provide an API for power info?

... no good way to track power per process, per website basis

... I don't know what it is yet however

... an API for joules doesn't seem effective

.... since don't know what to do with the data

... second one is what happen when the TAB is in the background

... appnap

... or when the tab is suspended

... browsers and user agents are doing things to improve by altering runtime patterns

... we're solving it in inconsistent ways

... we could be more predictable

... a JS API/event/notification seems needed

... with a time limit to respond

... RAF isn't called if it's background

... but not great for other things like sync emails, Facebook update, etc.

... some potential here

Alois: profiling power usage, and how to help devs to write more power efficient apps

Jason: Boris mentioned that they increase the timeout duration between callbacks in background

Alois: setTimeout getting slower seems problematic

Jatinder: setTimeout isn't reliable anyway

Jason: the HTML5 spec doesn’t specify a time

... but maybe we can progressive throlling timers frequency

... don't know if it's a new API

... or standardize agreement what the user agent should do

... we're all doing different things right now

plh: can we find a pattern in what user agents do right now?

Arvind: what does Windows do for background tabs?

Jason: you wake up as occasionally as possible

... you proceed by burst

... i.e. do as much as possible when you're awake

... then back to sleep

... for IE, when launched without page, no power will be consumed. no timers, no anything, besides one case

... (besides a hang in flash :)

... others have a polling based model

... it's mapped to HTML5, setTimeout, RAF, etc.

... all interrupts are aligned to the hardware

... i.e. vlbank for the display

... if no pending work, we bail out

... if work, we'll guarantee the callbacks

... the number of callbacks per second, but not the frequency

... ex: 4ms callbacks, so expect 250 callbacks for that

... but we'll map than to the display interrupt, i.e. 60ms

... we'll have 4 callbacks instead

... we'll nest them

... make the callbacks not looking consistent for benchmarks

Arvind: on windows phone, if I look at another app, not the browser, but there are tabs

... what happen to them?

Jason: if it's windows phone 8, phone or surface, the TAB is in back stack

... most recently used app

... so IE goes into the back stack

... it will run for 8s there

... not painting, lower priority, ...

... but still running

... after 8s, it is suspended

... ie stop executing

... the further it goes into the back stack

... the process will be serialized

... we send the visibility event

... but don't know they are going to be suspended

... but you can register for an windows RT event with an app

... email client

... we use techniques to flush the memory

... if the user doesn't go back to the app for long time, we'll terminate the process

... apple model is very similar

Arvind: what kind of event is sent?

Jason: "onsuspend"

... (something like that)

... we sent an event if we wake up again

Arvind: what about tabs?

Jason: ok, so that was for foreground tab

... for background tab, we reduce frequency

Arvind: Is there a scenario where a tab hasn't been used for a few days, do you kill the JavaScript.

Jason: The desktop browser doesn't do anything special here because it’s trying to maintain compatibility with line of business apps.

...The immersive browser will suspend tabs on an individual basis.

Arvind: Thanks for the info.

Jason: Everything shared is public. You can check our build talks for details.

...Seems like iOS has a similar model here.

Arvind: I'm guessing the OSX's app nap is something similar.

Jason: Based on yesterday’s discussion, looks like they are slowing down the background tabs, but not necessarily shut down.

...We have seen cases where some US banks have security built into the onload handlers. So shutting down may have a compat issue for some users.

Arvind: What about android and ios? do they serialize?

Jason: I'm not very familiar with android.

Arvind: Seems like most apps consume a ton of RAM these days.

Jason: Have you heard of super fetch in windows? The ability to suspend on a page level.

Jason: Everyone's doing these little optimizations, which are great. but developers aren't aware of them, so it just seems like a bit random. Seeing that apple and Microsoft both have a similar suspend models, it may make sense to bring such a suspend event to ten web platform.

Arvind: You also mentioned throttling down timers based on how long the tab hasn't been used.

Jason: I think that’s something id fine interesting.

Arvind: I think there’s definitely interest in the community around power consumption. I think it’s a good area. Ilya has done some research in this area

Alois: the mailing list had an idea on gzipping on the network. today there’s no opportunity in JavaScript to gzip.

Alois: it may be interesting to have a function to gzip.

Jason: I’m not sure it makes sense compress from client to server

Arvind: it'll help to save battery

Jason: I think the compressing process may actually burn in more cpu trying to compress

Jatinder: there definitely a curve here. we may want to prototype this and check what the data look like

Arvind: Jonas mentioned we should try to find out if a JS compression is comparable to a native function

... seems like there are libraries that do compress and that's why we don’t have a native function

Jason: I bet the JS implementation in a library will be 100x more expensive than doing it natively

... there are definitely wire costs but I think the power loss will be higher due to cpu cost

Jatinder: prototyping will help us determine the cost / benefit analysis. if we find that there’s really just a small window of improvement, this may not be something we want to pursue. but if the data shows that the window is much larger, we may want to pursue

Alois: I also want to talk about single page applications and measuring performance. a lot of timing apis are built on normal documents, but single page applications user timing is not as useful

Alois: I think we should invest in new ideas here

Jatinder: I know single page apps are becoming the rage. do we have data on how many single page apps there are?

Alois: I don’t have great numbers, but we should include these guys at our next workshop.

...we currently don't get good information on that area today

Arvind: thanks everyone for joining us these last two days. great discussions!