Web Performance Working Group Teleconference

14 Nov 2013

See also: IRC log


Wuzhou_middle, +1.617.294.aaaa, +1.617.294.aabb, pmsangal, JatinderMann, PanDeng, thinker, plh3, AutomatedTester, kkubota2, Sam_, Arvind, Anne
Jason, Arvind


<trackbot> Date: 14 November 2013

<plh> hi Jatinder

<plh> I'm on the podium at the AC right

<plh> let me know when you're ready to start

<JatinderMann_> Hi Philippe

<JatinderMann_> Okay, sound's good

<plh> and I'll come in the room

<JatinderMann_> We're just waiting for more people to join. So far it's Pan and I.

<plh3> join #webperf

<plh> Jatinder Mann

<plh> Pan Deng

<plh> Lei Xue

<plh> ?, Tencent

<plh> kkubota2, NTT

<plh> Mark Nottingham, Akamai

<plh> Renoir Boulanger, W3C

<plh> David Burns, Mozilla

<plh> Alois Reitbauer

<plh> Jason Weber

<plh> Sam ?, Foxconn

<plh> Arvind Jain


<plh> Jatinder: should HTML5 include prerender?

<plh> ... feedback is that we should just consider doing it on microformats

<plh> ... but it seems worthwhile to have it part of the spec

<plh> ... one feedback

<plh> ... around if you replace the current browsing context

<plh> ... if you loose "replace" you loose such constraint

<JatinderMann_> 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

<JatinderMann_> Plh: We will need to give test cases if we want this put in. Are we okay with just leaving this?

<JatinderMann_> Arvind: Ilya raised a resource hints proposal on preconnect, preload, prerender

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

<JatinderMann_> Arvind: As we had discussed in the past, we may want to keep some of this as browser optimizations

<JatinderMann_> Jason: Some of these are environment specific optimizations. I'm not sure we want to require browsers to explain all the details.

<JatinderMann_> Arvind: What's preload and preconnect? Are these new?

<JatinderMann_> Jatinder: It's unclear if some of these are just renaming prefetch or something new.

<JatinderMann_> Plh: It might be worthwhile to specify this in the spec so developers know what to expect

<JatinderMann_> Jason: Depending on environment, like if you're on 3G, you may not want to do these optimizations.

<JatinderMann_> 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 enviroment. 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.

<JatinderMann_> Jatinder: Prefetch is already defined and so is prerender. Are we really trying to define a preconnect

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

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

<JatinderMann_> Jatinder: But at parse time the browser will encounter the preconnect attribute at the same time as it encounters the URL.

<JatinderMann_> Jason: this may be more useful for the second page.

<JatinderMann_> Arvind: This might be a very light weight version of prerender.

<JatinderMann_> Arvind: We should make sure this that the spec includes this. The registry includes prerender and the spec includes prefetch.

<JatinderMann_> Jason: IE supports preconnect on a heuristics base. I believe its some 80% hit rate of determining which one is going to be preconnected

<JatinderMann_> Jatinder: Are we leaning towards defining preconnect?

<JatinderMann_> Jason: I would caution beucase the developer may shoot themselves on the foot.

<JatinderMann_> dns-pretetch

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

<JatinderMann_> Arvind: Based on Ilya's slides, there is "dns-prefetch", "prefetch", "prerender", "subresource". At least "prerender" and "prefetch" are supported everyone. "subresource" is unnecessary

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

<JatinderMann_> Arvind: I think we should wait and see if others have more concrete requirements.

<JatinderMann_> Arvind: We should decide on whether or not we should define more states.

<JatinderMann_> Arvind: Looks like some of us aren't happy in defining too many more.

<JatinderMann_> Jason: As of IE11, we support the dns-prefetch tag.

<arvind> values

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

<JatinderMann_> Arvind: Looks like we currently have prefetch in the HTML5 spec, prerender and dns-prefetch is in the registry.

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

<JatinderMann_> Jatinder: We should discuss with HTML5 WG to include dns-prefetch and prerender.

<JatinderMann_> Arvind: We should discuss all four with the HTML WG.

<JatinderMann_> 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].

<JatinderMann_> Jatinder: That's all of our open items. Does anyone else have any other questions?

<JatinderMann_> thinker: I worry if prerender can be used for denial of service type attacks

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

<JatinderMann_> thinker: I think we should put same origin restrictions.

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

<JatinderMann_> 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

<JatinderMann_> ...about how it prerenders. Chrome and IE both limit the prerenders.


<JatinderMann_> Arvind: We should probably start by talking about the goals of beacon and what isn't already solved by XHR.

<JatinderMann_> Jason: What I'm most excited about beacon is asynchronously sending data when its convienent. Today sites are using XHR by blocking the site's unload to send the data.

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

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

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

<JatinderMann_> Arvind: I agree that XHR doesn't solve this problem and beacon can solve this and is sufficiently different.

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

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

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

<JatinderMann_> Jatinder: Phillipe raised that some people were interested in abusing to use this send large amounts of data.

<JatinderMann_> Arvind: Let's start by talking about the size limitations.

<JatinderMann_> Arvind: Fixed values may look silly in the future.

<JatinderMann_> Jatinder: Does XHR have a limit?

<JatinderMann_> Arvind: No.

<JatinderMann_> Jatinder: But XHR doesn't live after the page has gone away. But beacon can survive.

<JatinderMann_> Arvind: 10K is too small.

<JatinderMann_> Arvind: Uploading 10GBs will cost you money on your mobile page. So I see a point here.

<JatinderMann_> Arvind: The current solution of spinning is the worse case, as it blocks the unload and you can send as much data as you want.

<JatinderMann_> Alois: We can also not include this in the spec, but the browser fails silently.

<JatinderMann_> Plh: I don't think we should put a limit in the spec, but should be allow the ability to query data.

<JatinderMann_> 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. Iniitally there weren't any limits on cookie data and people were sending 65K data. UAs started adding arbirtary limits on cookies. We have lost a lot of money as this, because some of our users weren't able to send.

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

<JatinderMann_> Arvind: Should the limit be applied at a page level or function level?

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

<JatinderMann_> Arvind: What about a way to query?

<JatinderMann_> Plh: I don't think it was a good idea afterall.

<JatinderMann_> Jason: Agreed.

<JatinderMann_> Daniel: Agreed.

<JatinderMann_> Alois: What about single page applications? After 20 minutes you can't send any more data.

<JatinderMann_> Daniel: We should set the limit to kilobytes rather than megabytes, especially from a mobile operator point of view.

<JatinderMann_> Jason: We are developing a general purpose platform. We should be careful to set limits.

<JatinderMann_> Jatinder: We have to keep in mind that we want to keep adoption of this API and have people move away from XHR.

<JatinderMann_> Arvind: Partical 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.

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

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

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

<JatinderMann_> Arvind: I agree as well.

<JatinderMann_> Arvind: I don't think we should add any batching details in the spec about battery life.

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

<JatinderMann_> Arvind: I agree with that. I think the spec should remove the battery life use cases.

<JatinderMann_> 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].

<JatinderMann_> Arvind: Let's talk about retry. XHRs don't retry right?

<JatinderMann_> Alois: Yep, they just return a failure code, doesn't retry.

<JatinderMann_> Arvind: I think we all agree that we shouldn't return a return code.

<JatinderMann_> Arvind: What are the retry semantics?

<JatinderMann_> Jason: We should leave this to the quality of implementation.

<JatinderMann_> Arvind: The mechanism has to be robust to actually use it.

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

<JatinderMann_> Alois: I think after 10 minutes the data is useless anyway. Some marketing folks may want to hold data longer.

<JatinderMann_> Jason: I recommend we leave the text quite general and let the user agent may try best effort while maintaining privacy and security.

<JatinderMann_> Arvind: We may want to add examples in the notes.

<JatinderMann_> Daniel: I just checked what our paypal beacon does on my mobile device. It is 26K. It's using Google Analytics and Omniture.

<JatinderMann_> Daniel: We will just not use beacon if it has 10K limit.

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

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

<JatinderMann_> Arvind: I also don't think we should include get. This adds complexity. Its not the common use case.

<JatinderMann_> Arvind: I think POST should be the only method.

<JatinderMann_> Alois: I think we should limit to POST as well.

<JatinderMann_> Jatinder: Let's solve the problem we intended to solve. Let's only stick with POST.

<JatinderMann_> 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].

<JatinderMann_> Daniel: I just checked, and Microsoft.com uses 22KB beacon.

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

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

<JatinderMann_> 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 incraeses reliability (e.g., if you have a 1% failure rate and you retry once, you'll have a 0.5% impact).

<JatinderMann_> Arvind: I think a random retry for all of these failures may be worthwhile.

<JatinderMann_> Daniel: I know some data carriers block uploads while you're on the call. So it blocks that.

<JatinderMann_> 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

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

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

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

<JatinderMann_> Anne: In many cases, its hard to know when the image will be in the page.

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

<JatinderMann_> Anne: I think I agree with that.

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

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

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

<JatinderMann_> 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> ;-)

<JatinderMann_> Off to lunch break.

<simonste_> Hello

<annevk> \o/

<annevk> wb

Page Visibility

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

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

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

<JatinderMann_> 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?

<JatinderMann_> 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

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

<JatinderMann_> Jason: From the advertising point of view, they want proper element visibilty 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 :(

<simonstewart> I'm finding this flash discussion really interesting.

<plh> oops

<plh> we got dropped

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

<JatinderMann_> 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 :(

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

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

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

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

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

<simonstewart> 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/

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

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

<simonstewart> JatinderMann_: that definition might well work for WebDriver. We already have a fairly loose definition of visibility.

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

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

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

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

<JatinderMann_> Simon: The Web Driver could also use that potentially.

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

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

High Resolution Time

<JatinderMann_> Anne: Can we remove the NoInterfaceObject

<JatinderMann_> ?

<JatinderMann_> Jatinder: Yes, I can remove.

<JatinderMann_> Plh: Can we move to Last CAll?

<JatinderMann_> Jatinder: Yes.

<plh> Resolved: HRT 2 to Last Call

Navigation Error Logging

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

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

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

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

<JatinderMann_> 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

<JatinderMann_> 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

<JatinderMann_> Anne: You may want to do a security review.

<JatinderMann_> Alois: We may want to ask the security team both whether its 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

<JatinderMann_> 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].

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

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

<JatinderMann_> Jatinder: We are very open to API surface.

<JatinderMann_> 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

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

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

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

<JatinderMann_> Anne: Coordinate with the CSP guys.

<JatinderMann_> Arvind: This would just be like report URI.

<JatinderMann_> 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].

<JatinderMann_> 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

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

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

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

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

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

<JatinderMann_> 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

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

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

<JatinderMann_> Anne: WE should define a JSON method.

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

<JatinderMann_> Plh: In the Performance Timeline L2 spec.

<JatinderMann_> 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 initator type be web worker? Shared worker resources should be put in which timeline? The shared worker's timeline?

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

<JatinderMann_> 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

<JatinderMann_> jatinder: What about protocol information?

<JatinderMann_> Mark: We should just return the ALP procotols in the registry.

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

<JatinderMann_> Jatinder: Should we include byte size information?

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

<JatinderMann_> Mark: There are so many interesting numbers with so many warnings.

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

<JatinderMann_> 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

<plh> Alois: [explains the use case]

<plh> ... we break pages by injecting JS in it

<plh> [Alois will give poiners to Jason about IE issue]

<plh> Alois: we do runtime injection

<plh> ... script tag in HTTP header, ...

<plh> Jason: it fits into our charter

<plh> ... this would help sites

<plh> .... help with cacheability

<plh> ... a man in the middle attack can do this today

<plh> Alois: it would have to be sent with every request

<plh> ... ie not cached

<plh> Jason: on the surface, it seems a good idea

<plh> ... pretty trivial in most user agents

<plh> Alois:: header would only go for the root HTML

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

<plh> ... we need to do research on our side

<plh> ... and Arvind will see at Google

<plh> ... Alois should talk to Mark Nottingham

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

<plh> 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].

<plh> 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> plh: if feedback positive, we'll contact public-script-coord

<plh> 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].

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

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

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

<plh> ... not just timing information

<plh> Jason: finding a proper name would be good

<plh> ... let's stick with preflight for now


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

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

<plh> ... we always talk about cutting "Web Archive" formats

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

<plh> Jason: it's a dev tool option

<plh> plh: it's a waterfall

<plh> Arvind: HAR has more info that the Web performance object

<plh> ... so toJSON isn't enough for HAR

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

<plh> Jason: chrome dev and HTTP archive supports HAR

<plh> Alois: and a few other tools

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

<plh> Arvind: we're working with Ian

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

<plh> 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

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

<plh> ... we socialize and reach out to companies

<plh> Alois: would make to get feedback on implementations

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

<plh> ... let's do it the day before or after

<plh> ... I recommend a full day workshop

<plh> ... then do a debrief

<plh> ... 9-3 for the workshop, 3-5 for the webperf

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

<plh> [Google will be hosting]

<plh> frequence of teleconferences

<plh> Arvind: making decisions on the phone are problematic

<plh> Jatinder: we can be async

<plh> Arvind: we're missing the history

<plh> Jatinder: I like to talk things out

<plh> ... but yes, involved others would be good

<plh> ... no one read minutes

<plh> ... but we need to separate decisions

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

<plh> [teleconference time]

<plh> 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

<plh> Jason: two things: power

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

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

<plh> ... I don't know what it is yet however

<plh> ... an API for joules doesn't seem effective

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

<plh> ... second one is what happen when the TAB is in the background

<plh> ... appnap

<plh> ... or when the tab is suspended

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

<plh> ... we're solving it in inconsistent ways

<plh> ... we could be more predictible

<plh> ... a JS API/event/notification seems needed

<plh> ... with a time limit to respond

<plh> ... RAF isn't called if it's background

<plh> ... but not great for other things like sync emails, facebook update, etc.

<plh> ... some potential here

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

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

<plh> Aois: setTimeout getting slower seems problematic

<plh> Jatinder: setTimeout isn't reliable anyway

<plh> Jason: the HTML5 spec doesn specify a time

<plh> ... but maybe we can progressive throlling timers frequency

<plh> ... don't kow if it's a new API

<plh> ... or standardize agreement what the user agent should do

<plh> ... we're all doing different things right now

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

<plh> Arvind: what does Windows do for background tabs?

<plh> Jason: you wakeup as occasoinally as possible

<plh> ... you proceed by burst

<plh> ... ie do as uch as possible when you're awake

<plh> ... then back to sleep

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

<plh> ... (besides a hang in flash :)

<plh> ... others have a polling based model

<plh> ... it's mapped to HTML5, setTimeout, RAF, etc.

<plh> ... all interrupts are aligned to the hardware

<plh> ... ie vlbank for the display

<plh> ... if no pending work, we bail out

<plh> ... if work, we'll guarantee the callbacks

<plh> ... the number of callbacks per second, but not the frequency

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

<plh> ... but we'll map than to the display interrupt, ie 60ms

<plh> ... we'll have 4 callbacks instead

<plh> ... we'll nest them

<plh> ... make the callbacks not looking consistent for benchmarks

<plh> Arvind: on windows phone, if I look at an other app, not the browser, but there are tabs

<plh> ... what happen to them?

<plh> Jason: if it's windows phone 8, phone or surface, the TAB is in backstack

<plh> ... most recently used app

<plh> ... so IE goes into the backstack

<plh> ... it will run for 8s there

<plh> ... not painting, lower priority, ...

<plh> ... but still running

<plh> ... after 8s, it is suspended

<plh> ... ie stop executing

<plh> ... the further it goes into the backstack

<plh> ... the process will be serialized

<plh> ... we send the visisiliby event

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

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

<plh> ... email client

<plh> ... we use techniques to flush the memory

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

<plh> ... apple model is very similar

<plh> Arvind: what kind of event is sent?

<plh> Jason: "onsuspend"

<plh> ... (something like that)

<plh> ... we sent an event if we wake up again

<plh> Arvind: what about tabs?

<plh> Jason: ok, so that was for foreground tab

<plh> ... for background tab, we reduce frequency

<JatinderMann_> scribe: JatinderMann

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

<JatinderMann_> Jason: The desktop browser doesn't do anything special here becaus its trying to maintain compatibility with line of business apps.

<JatinderMann_> ...The immersive browser will suspend tabs on an individual basis.

<JatinderMann_> Arvind: Thanks for the info.

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

<JatinderMann_> ...Seems like iOS has a similar model here.

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

<JatinderMann_> Jason: Based on yesterdays discusson, looks like they are slowing down the background tabs, but not necessarily shut down.

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

<JatinderMann_> Arvind: Wht about andriod and ios? do they serialize?

<JatinderMann_> Jason: I'm not very famaliar with andriod.

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

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

<JatinderMann_> 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 tne web platform.

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

<JatinderMann_> Jason: I think thats something id fine interesting.

<JatinderMann_> Arvind: I think theres definitely interest in the community around power consumption. i think its a good area. ilya has done some research in tbis area

<JatinderMann_> alois: the maling list had an idea on gzipping on the network. today theres no opportunkty in javascript to gzip.

<JatinderMann_> alois: it may be interesting to have a functon to gzip.

<JatinderMann_> jason: i'm not sure it makes sense compress from client to server

<JatinderMann_> arvind: it'll help to save battery

<JatinderMann_> jason: i think the compressing process may actually burn in more cpu trying to compress

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

<JatinderMann_> arvind: jonas mentioned we should try to find out if a JS compression is comparable to a native functon

<JatinderMann_> ... seems like there are libraries that do compressand that's why we dont have a native functon

<JatinderMann_> jason: i bet the JS implementtio in a library wll be 100x more expensive than doing it natively

<JatinderMann_> ... there are definitly wire costs but i think the power loss will be higher due to cpu cost

<JatinderMann_> 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

<JatinderMann_> alois: i also want to talk about single page applications and measuring performance. a lot of timing apis are built on normal docunents, but single page appications user timing is not as useful

<JatinderMann_> alois: i think we should invest in new ideas here

<JatinderMann_> jatinder: i know single page apps are becoming the rage. do we have data on how many single page apps there are?

<JatinderMann_> alois: i dnt have great numbers, but we should include these guys at our next workshop.

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

<JatinderMann_> arvind: thanks eveyone for joining us these last two days. great discussions!

Summary of Action Items

[NEW] ACTION: Alois to talk about preflight to mnot [recorded in http://www.w3.org/2013/11/14-webperf-minutes.html#action03]
[NEW] ACTION: Arvind to get preflight feedback from Google [recorded in http://www.w3.org/2013/11/14-webperf-minutes.html#action02]
[NEW] 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]
[NEW] ACTION: Jason to get preflight feedback from MS [recorded in http://www.w3.org/2013/11/14-webperf-minutes.html#action01]
[NEW] ACTION: Jatinder to get preflight feedback from MS [recorded in http://www.w3.org/2013/11/14-webperf-minutes.html#action04]
[NEW] ACTION: plh to change the teleconf time for 3pm ET [recorded in http://www.w3.org/2013/11/14-webperf-minutes.html#action06]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.138 (CVS log)
$Date: 2013-11-15 03:23:09 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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)

Succeeded: s/ais/ai/
Succeeded: s/Anna/Anne/
FAILED: s/"visbible" element/"hittable" element/
Succeeded: s/R/RT/
Succeeded: s/Arvind: Alois/Alois:/
Succeeded: s/woul/would/
Succeeded: s/keep/stick/
Found Scribe: JatinderMann

WARNING: 1 scribe lines found (out of 731 total lines.)
Are you sure you specified a correct ScribeNick?

Default Present: Wuzhou_middle, +1.617.294.aaaa, +1.617.294.aabb, pmsangal
Present: Wuzhou_middle +1.617.294.aaaa +1.617.294.aabb pmsangal JatinderMann PanDeng thinker plh3 AutomatedTester kkubota2 Sam_ Arvind Anne
Regrets: James
Found Date: 14 Nov 2013
Guessing minutes URL: http://www.w3.org/2013/11/14-webperf-minutes.html
People with action items: alois arvind jason jatinder plh

[End of scribe.perl diagnostic output]