17:14:54 <RRSAgent> RRSAgent has joined #webperf
17:14:54 <RRSAgent> logging to http://www.w3.org/2012/11/08-webperf-irc
17:14:56 <trackbot> RRSAgent, make logs world
17:14:56 <Zakim> Zakim has joined #webperf
17:14:58 <trackbot> Zakim, this will be WPWG
17:14:58 <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
17:14:59 <trackbot> Meeting: Web Performance Working Group Teleconference
17:14:59 <trackbot> Date: 08 November 2012
17:15:14 <JatinderMann> Topic: Introduction to the Workshop
17:15:37 <dominich> dominich has joined #webperf
17:16:10 <mjaquish> mjaquish has joined #webperf
17:16:15 <girlie_mac> girlie_mac has joined #webperf
17:16:31 <igrigorik> igrigorik has joined #webperf
17:16:31 <Gautam> Gautam has joined #WebPerf
17:16:40 <igrigorik> morning!
17:17:07 <andreatrasatti> andreatrasatti has joined #webperf
17:18:03 <rhundt> rhundt has joined #webperf
17:18:03 <JatinderMann> present: AaronHeady, Alois, Achicu, Chihiro, dma, filip, gautam, girlie_mac, gmandyam, hiro, igrigorik, JatinderMann, kt, lmclister, mjaguish, pbakaus, pmeenan, tobie, yoav, zoltan
17:18:44 <tobie> regrets+ tobie
17:19:13 <JatinderMann> present+ andreatrasatti
17:19:20 <JatinderMann> present+ rhundt
17:20:33 <tobie> Have fun today and make the web faster.
17:21:28 <pmeenan> pmeenan has left #webperf
17:21:37 <pbakaus> @tobie we will :)
17:21:56 <dma> tobie: 'same thing we do every day, pinky: try to make the web faster'
17:22:07 <pmeenan> pmeenan has joined #webperf
17:23:20 <JatinderMann> Philippe's introduction: http://www.w3.org/2012/Talks/1107-perf-intro/
17:24:18 <seth_lnkd> seth_lnkd has joined #webperf
17:24:34 <jaredw> jaredw has joined #webperf
17:26:09 <achicu_> achicu_ has joined #webperf
17:26:34 <JatinderMann_> JatinderMann_ has joined #webperf
17:26:44 <JatinderMann_> presenter: Eric Gavaletz
17:27:51 <karen> karen has joined #webperf
17:28:21 <JatinderMann_> Eric: Consumers, web developers are interested in finding performance data to make faster applications.If you want a representative data on performance, you will need to use a client that most users are using, like web browsers.
17:28:27 <plh> plh has joined #webperf
17:29:17 <RRSAgent> I have made the request to generate http://www.w3.org/2012/11/08-webperf-minutes.html plh
17:29:46 <JatinderMann_> Eric: There are many third party binaries or add-ons to the browser that people have been using to measure performance within the browser. The problem with all of these approaches is that they have selection bias ("geek bias"), because only a small portion of the population will use these applications.
17:29:52 <plh> Chair: Jason & Arvind
17:30:02 <Michelangelo> Michelangelo has joined #WebPerf
17:31:08 <JatinderMann_> Eric: I am working on creating a net-score which is an IQ scoring for network performance. This would be a generalized performance number that regular individuals, FCCs and others can use to understand their performance impact. This data, again, needs to be representative and not "geek biased'.
17:31:39 <JatinderMann_> Eric: We are using JavaScript to measure real sites, so we can get less geek bias.
17:32:25 <JatinderMann_> Eric: Our lab environment uses a Windows 7 client and runs through a 100 mbs switch and then connects to a Linux server. We use Windows 7, because we need to measure Internet Explorer, which has a large market share.
17:33:27 <JatinderMann_> Eric: We measure response time, round trip time and transfer time (amount of time it takes to transmit bits from the server to the browser.
17:34:29 <JatinderMann_> Eric: First measure we used was that we did a Date.now() prior to adding a image to the document, until the time of the resource load (onload event). However, this doesn't give the time from when the bits left the server.
17:35:04 <plh> i/presenter: Eric Gavaletz/Topic: Comparing In-Browser Methods of Measuring Resource Load Times/
17:35:09 <RRSAgent> I have made the request to generate http://www.w3.org/2012/11/08-webperf-minutes.html plh
17:36:24 <JatinderMann_> Eric: We did this analysis on all modern browsers (Chrome, Firefox, IE9, Opera). When we used this technique, we saw that the data showed that some browsers would show that the time took longer than ground zero (IE and Opera).
17:37:00 <konno> konno has joined #webperf
17:38:20 <JatinderMann_> Eric: Another technique we used was using an XHR to measure the latency of opening and recieving the headers. We saw that all browsers did well on opening the XHR; data was very close to ground zero. When we looked at XHR loading, we saw that there are cross-browser differences here. IE and Opera are closer to ground zero, whereas Chrome and Firefox take longer to fire the xhr load. When we looked at the XHR DONE, we saw that browsers w[CUT]
17:40:04 <JatinderMann_> Eric: The next method we used was looking at Navigation Timing API, which is supported in most modern browsers. We use requestStart as the start time, responseStart as the start of the response and responseEnd as the end of the response. When looking at the navigation timing data, we see that responseStart, most browsers are close in data, though with some differences. When we look at responseEnd, we noticed that there were differences [CUT]
17:40:09 <JatinderMann_> ...with the data.
17:41:47 <JatinderMann_> Eric: We looked at three different cases of placing our measurement code. We put the base case in the head, inline and inline in onload. Looking at the IE data, we see that based on when we measured the data, it looked diferent.
17:43:34 <JatinderMann_> Eric: When we looked at Firefox, we found issues with css visibility. We did a study where we used these different methods across browsers, we saw that there are differences between browsers when gathering this data.
17:44:18 <JatinderMann_> Eric: Why not time the simple cases, of downloading individual objects.
17:44:31 <JatinderMann_> Question: Has someone implemented Resource Timing yet?
17:45:03 <JatinderMann_> Eric: I have not yet found out if Resource Timing is implemented.
17:45:18 <JatinderMann_> Jason: IE10 has resource timing available now publicly.
17:45:25 <JatinderMann_> Arvind: Chrome will have it soon too.
17:46:35 <JatinderMann_> Alois: With the Timing specs, it feels like the specs are very advanced, and the implementations are taking long time.
17:47:28 <JatinderMann_> Philippe: This is probably the only time some has said that the standards group are working too fast.
17:48:27 <JatinderMann_> Eric: I think there is value in having this specification completed before the browsers implement the APIs, that will reduce the cross-browser differences.
17:49:23 <JatinderMann_> Jason: As the browser vendors, we have internal implementation details. I am more than happy to provider more information to you.
17:49:36 <karen> Next Speaker: Mike McCall
17:49:58 <karen> from Akamai Technologies
17:50:07 <karen> ...I work in service performance group
17:50:21 <karen> ...one of my jobs is to look at Akamai's performance, internal and external perspectives
17:50:23 <JatinderMann_> Topic: HTTP Extension to provide Timing Data for Performance Measurements
17:50:28 <karen> ...and from the Edge, Akamai servers to client
17:50:34 <karen> ...have been working on @
17:50:48 <karen> ...Eric gave a good demonstration of what we like to think of in RUM ?
17:50:59 <karen> ...how the page loaded, the end user actual experience, the site they were visiting
17:51:10 <yosuke> yosuke has joined #webperf
17:51:14 <karen> ...Akamai in particular are interested to show the value of our products and see they are getting benefit
17:51:29 <karen> ...Thanks to specs like navigation and resource timing, it makes it easier to show that value
17:51:33 <karen> ...Thanks, eveyone!
17:51:46 <karen> ...During HTTP2.0 process this summer, Akamai is interested in being part of the conversation
17:51:53 <karen> ...We wanted to make sure our needs were met by the spec
17:52:02 <karen> ...We had an internal call for drafts to submit to IETF
17:52:10 <karen> ...Some of my colleagues came up with this HTTP extension
17:52:20 <karen> ...Some of these measuresments are similar to what Eric just descibed
17:52:32 <karen> ...Collect those to the HTTP session...without calling back JavaScript
17:52:43 <karen> ...Right now most of you are familiar with this
17:52:52 <karen> ...We are converned with two types of performanc emeasurement
17:52:59 <karen> ...Many commercial offerings
17:53:04 <karen> ...wide, vast and really great
17:53:17 <karen> ...Synthetics tests allow us to see page level detail for a single transaction,
17:53:23 <karen> ...look at spike times, content times
17:53:29 <karen> ...and give us baseline data points
17:53:33 <karen> ...They do have some problems
17:53:41 <karen> ...tend to be well connected data centers, running fromnice computers
17:53:47 <karen> ...that tend not to have viruses
17:54:00 <karen> ...so they provide a best case scenario for web based performance test
17:54:09 <karen> ...but from measurement perspective, it's not what real pepole are seeing
17:54:13 <karen> ...In the Rum space
17:54:21 <karen> ...some more well known projects are Boomerng
17:54:29 <karen> ...has capabilities to test throughput
17:54:34 <karen> ...test sizes and bandwidth
17:54:39 <karen> ...and what user timing spec from W3C
17:54:47 <karen> ...Episodes doing great
17:54:51 <karen> ...there is commercial support
17:55:03 <karen> ...Rum is well received now and people want to see what end users are seeing
17:55:16 <karen> ..But there is one problem, it mostly requires JS to run
17:55:27 <karen> ...so has somewhat of an observer effect
17:55:43 <karen> ...It's a start, but we thought why not add this collection of data and beaconing into the session
17:55:51 <karen> ...that is basically the draft I have written internally
17:55:56 <karen> ...and what Akamai sent to the IETF
17:56:00 <karen> ...to get people talking and thinking
17:56:09 <karen> ...to couple the gathering and beaconing of the HTTP session
17:56:16 <karen> ...One thing that might be interesting from Akamai's perspective
17:56:27 <karen> ...there are two ways to implement Rum solution...to show value to them
17:56:40 <karen> ...and to do experiments of our own and understand what our end users see and improve our products
17:56:54 <karen> ...Our servers talk to end users so there are some cool opportunities there
17:57:00 <karen> ...Possibly dynamically change the session
17:57:11 <karen> ...If user running on slow browser, give them a different version of the page
17:57:17 <karen> ...We feel this could be a cool possibility
17:57:27 <karen> ...Proposal goes into request response headers
17:57:46 <karen> ...There is negotiation where the user agent sends the header...and be willing to send data
17:57:51 <karen> ...and tell it which metrics it wants
17:57:56 <karen> ...Might be further negotiation
17:58:04 <karen> ...and server is going to send a TTL, a timing interval
17:58:08 <karen> ...Idea is to wait only so long
17:58:15 <karen> ...before timing out or sending data you have
17:58:28 <karen> ...Assuming negotiation is successful we will send that back
17:58:31 <karen> ...
17:58:40 <karen> ...using HTTP is not what most people do with Rum
17:58:46 <karen> ...May embed a chip
17:59:05 <karen> ...POST, as we have noticed in our Rum measurements, you want to collect as much data as we can
17:59:19 <andreatrasatti> q+ to ask about the packaged data to send back to the server, when and how much data
17:59:20 <karen> ...with resource timing you collect as much data on page and that gets out of control
17:59:24 <karen> POS seems like good idea
17:59:27 <karen> s/POST
17:59:38 <AaronHeady> AaronHeady has joined #webperf
17:59:39 <karen> ...On left side of slide is the user agent, right hand side is the server
17:59:46 <karen> ...Header asks for timing measurements
17:59:50 <karen> ...says ok and serves content
17:59:54 <karen> ...get DNS request
18:00:02 <karen> ...May also be a case to use the performance timeline
18:00:09 <karen> ...And also tells where to send those measurements to
18:00:27 <karen> ...Once the ust has collected those measurements...will send that data bacdk to server and HTTP POST
18:00:32 <karen> ...that is a high-level of the use case
18:00:35 <karen> ...Another thing we called out
18:00:40 <karen> ...as the spec is written
18:00:44 <karen> ...Send spec back
18:00:51 <karen> ...may break the business logic
18:00:57 <karen> ...so add this other header and send the data back
18:01:07 <karen> ...If you want to override data, can also add a metatag
18:01:18 <karen> ...especially if you do not have control over your own web server...to send for data processing
18:01:20 <karen> ...That's all
18:01:24 <karen> ...high-level overview
18:01:37 <karen> ack andrea
18:01:37 <Zakim> andreatrasatti, you wanted to ask about the packaged data to send back to the server, when and how much data
18:01:45 <karen> Andrea: about the last slide and previous one
18:01:53 <karen> ...the client would say I'm available to send measurements
18:01:56 <karen> ...what sort of package?
18:02:09 <karen> ...If I'm Yahoo, I want to collect data for my entire site
18:02:13 <karen> ...how is data packaged
18:02:17 <karen> ...for client and server costs
18:02:28 <karen> Mike: great question, but not something we have addressed
18:02:35 <karen> ...to get full client experience would need to address it
18:02:48 <karen> Andrea: How do I know what resources are being used
18:03:02 <karen> ...if @ not being used...or if Edge cache coming from Europe
18:03:09 <karen> Mike: Our Edge server will still serve it
18:03:22 <karen> Andreas: But how woudl the client know...if I have news article with 10 images
18:03:30 <karen> ...9 of 10 are not cached on web server
18:03:42 <karen> ...client says it took ten seconds to analyze
18:03:53 <karen> ...but the article image was slow; how would I know that
18:04:01 <karen> Mike: to get that data we would have to log into servers
18:04:09 <karen> ...this spec is about collection of data from client perspective
18:04:19 <plh> q?
18:04:19 <karen> ...would not know it had to be fetched from client of origin
18:04:39 <karen> Glen: Has this been implemented in any user agent?
18:04:43 <karen> Mike: It has not
18:05:01 <karen> Alois: There is a general problem with beacons getting the data back from the server
18:05:05 <karen> ...people do crazy stuff
18:05:09 <karen> ...beaconing approach per se
18:05:23 <karen> ...as you mentioned, resource timing is there...you run into challenges
18:05:28 <karen> ...content has to be posted there
18:05:35 <karen> ...monitoring data to a different domain
18:05:43 <karen> ...unless you are a big company you are not doing on your own
18:05:52 <karen> ...you are not getting data back; can't get POST back
18:05:55 <karen> ...cannot get Rum back
18:06:01 <karen> ...don't want to go into technical details
18:06:02 <gmandyam> q+
18:06:10 <karen> ...From Compuware perspective, this is a problem
18:06:15 <gmandyam> gmandyam is Giri Mandyam (Qualcomm Innovation Center)
18:06:19 <karen> ...run into serious problems getting data back to service
18:06:30 <karen> ...have to wait before unknown event; have to wait for A B testing
18:06:42 <karen> ...Second that we need something like this without going into technical details
18:06:56 <karen> Armind: The existing JavaScript APIs...can you just use them?
18:07:00 <karen> Mike: which ones?
18:07:05 <karen> Armind: the timing APIs
18:07:10 <karen> Mike: we absolutely do
18:07:18 <karen> ...this is basically a wrapper around that
18:07:22 <karen> ...go back to send measuremetn
18:07:27 <karen> ...used high level things
18:07:35 <karen> ...could be domain lookup N
18:07:40 <karen> ...or request startup
18:07:47 <karen> ...use existing APIs
18:07:52 <karen> Armind: You could use JS code
18:07:59 <karen> ...why use HTTP headers is the question?
18:08:11 <karen> Mike: In addition to observer effect of running...
18:08:19 <karen> developers are reluctant to add new headers
18:08:29 <karen> ...customers are timid about this, especially from a third party perspective
18:08:44 <karen> ...assume we have tested our code, but not sure how much they interact
18:08:47 <karen> ack Giri
18:08:59 <karen> Giri: I had a question as to implementation of this feature
18:09:08 <karen> ...think of streaming technologies such as DASH
18:09:11 <karen> ...media player devices
18:09:20 <karen> ...this may be a good feature, not a full JS engine
18:09:26 <karen> ...if you compare a browser based vs native app
18:09:34 <karen> ...would there be performance issues between the two?
18:09:38 <Ritesh> Ritesh has joined #webperf
18:09:45 <karen> Mike: great question, I don't know answer
18:10:07 <karen> Giri: my guess is that the native media player could provide different measurement data than a browser running on the same device
18:10:19 <karen> ...user agent stream...may show different application running on same device
18:10:28 <karen> Mike: You may be able to figure this out on the negotiation phase
18:10:31 <karen> ...not sure what is supported
18:10:49 <karen> ...you could conceive the browser would ask for this...or part of the orginal request header
18:10:58 <karen> Giri: more like, I am not a browser request
18:11:26 <karen> @: Existing agents will not role out without existing sets of complete data
18:11:27 <MickH> MickH has joined #webperf
18:11:29 <karen> PLH: Last question
18:12:07 <karen> Gautham (sp): hosting header could collect it; possible have a check box
18:12:17 <karen> ...turn check box off...possible instrument to collect data
18:12:23 <karen> ...taht could be useful benefit to this approach
18:12:47 <karen> @: Be nice to aggregate the data to specify
18:12:52 <karen> ...gives an ID to the request
18:13:05 <karen> ...client aggregates...ten objects and sends ID
18:13:19 <karen> Mike: something like that would be an internal implemetation that exists within the larger protocol
18:13:27 <karen> ...request header leverages other API to collect data
18:13:37 <karen> @: Reason I brought up, would be too much for client to send
18:13:40 <karen> ...pages are too large
18:13:47 <karen> ..lots of requests going back and forth
18:13:51 <karen> Mike: once per page, not per image
18:14:06 <karen> ...the way navigation timing works is per page, per the document and noteverything on the document
18:14:12 <karen> @: maybe I misunderstood
18:14:18 <karen> Mike: that would be resource timing
18:14:36 <karen> @: Suppose you had ten objects in the cache and you want to know @ time and connect time
18:14:46 <karen> Mike: look in headers and ask for all the resource timing
18:14:57 <karen> Phil: On the JS side, user can report anything you want
18:15:06 <karen> ...I have App and it gets reported
18:15:11 <karen> ...JS solution has two gaps
18:15:17 <karen> ...beginning and end of page
18:15:20 <karen> ...onload
18:15:28 <karen> ...I want to trigger an event with my analytics vendor
18:15:33 <karen> ...make sure event gets registered
18:15:42 <karen> ...some out of band reporting; browser please fire this; submit
18:15:56 <karen> ...Other end is the end..fire the beacon...but people will abandon page
18:16:05 <karen> ...would be nice to see that user got DNS results and then got cancelled
18:16:08 <karen> ...we have no visibilty into that
18:16:13 <karen> ...an autoband browser support
18:16:15 <karen> Mike: I agree
18:16:23 <pbakaus> Next speaker: Philippe Le Hégaret, on "Automatic Web performance measurement"
18:16:23 <karen> PLH: We will have more discussion after the break
18:16:31 <karen> rrsagent, make minutes
18:16:31 <RRSAgent> I have made the request to generate http://www.w3.org/2012/11/08-webperf-minutes.html karen
18:16:36 <karen> Scribe:
18:17:12 <pbakaus> Philippe: The problems they're facing is that they're a hosting company and navigation and resource timing gives them a lot of visibility into their performance of their sites
18:17:19 <karen> Philippe: I am presenting for Radware because they could not be here
18:17:36 <pbakaus> ...the challenge they had is to inserting code into a page can change the web page functionality and performance of the page
18:17:54 <igrigorik> igrigorik has joined #webperf
18:18:10 <pbakaus> ...the solution they're proposed is similar to the one proposed by Mike. They also proposed a HTTP Header, but also a HTML content attribute.
18:18:43 <pbakaus> ...HTTP header they're proposing is very simple. It shows that when you answer to a get request you get back a response header on where you are going to report the timing information
18:19:07 <pbakaus> ...with the conten attribute, you can say with kind of information you want to listen to
18:19:36 <pbakaus> ...whether it's the navigation timing information, or measuring video performance, individual targets can be linked this way, it's very simple
18:20:33 <pbakaus> ....for each of the resources in the HTTP header you get the URI, start end timestamps and additional properties through the request
18:21:14 <rhundt> rhundt has joined #webperf
18:21:22 <pbakaus> ...It's not the one of only solution, I do have some open questions
18:22:20 <pbakaus> ...I don't like their x-www-form-urlencoded format, maybe JSON format instead
18:22:35 <pbakaus> ...Should it be under same origin policy? What are the security considerations?
18:22:41 <andreatrasatti> q+
18:23:01 <pbakaus> ...does the APM still have to modify the web page, and how to active automaticm easurement to resources like XHR, @import?
18:23:21 <gmandyam> ack gmandyam
18:24:04 <pbakaus> Alois: sometimes you have to parse the whole content, and it would have a significant perf impact. Second thing to put it into elements is that you might not know that you want to measure them as they're created later on, before you know through the request
18:24:58 <pbakaus> ...All additional information that is sent back through the bandwidth needs to be taken into account, especially important for mobile
18:25:28 <pbakaus> ...It would be nice if the page could say I want to post back to a certain backend to report information, not the other way around
18:25:52 <mmccall> mmccall has joined #webperf
18:26:33 <pbakaus> Eric: The same issue that was brought up with the previous proposal. At what point is the page done, at what point is the user navigating away? If I stay on the same page for a long time, the most data is sent with other requests. We've outgrown the abstraction of "page", maybe that term is holding us back from the right implementation, They don't exist as
18:26:33 <pbakaus> they used to.
18:27:35 <pbakaus> Philippe: You shouldn't be hiding a POST within a GET
18:27:45 <pbakaus> aaa: It's really easy to take the access log and pipe it
18:27:55 <pbakaus> Philippe: any other questions?
18:29:47 <pbakaus> Andrea, Nokia: Connecting this with what Mike said earier. One thing you could nearly do now is to build from JS HAR archive and send it back to the server. Chrome dev tools (not sure about IE), you can already generate it from the client. Another option is a spec that creates HAR via JS, have the developer control info to report back. I am not convinced
18:29:47 <pbakaus> about this solution, as HAR already solves the issues.
18:31:01 <karen> rrsagent, make minutes
18:31:01 <RRSAgent> I have made the request to generate http://www.w3.org/2012/11/08-webperf-minutes.html karen
18:56:45 <mmccall> mmccall has joined #webperf
18:59:05 <lmclister> lmclister has joined #webperf
18:59:22 <achicu> achicu has joined #webperf
18:59:56 <Michelangelo> Michelangelo has joined #WebPerf
18:59:59 <MickH> MickH has joined #webperf
19:00:26 <filip> filip has joined #webperf
19:00:40 <gmandyam> gmandyam has joined #webperf
19:00:51 <Zoltan> Zoltan has joined #webperf
19:01:02 <gmandyam> Giri Mandyam will scribe the 11:00 - 11:30 discussion session
19:01:20 <Alois> Alois has joined #webperf
19:01:20 <mjaquish> mjaquish has joined #webperf
19:01:27 <gmandyam> Jatinder:  This part of the program is a discussion.
19:01:30 <AaronHeady> AaronHeady has joined #webperf
19:01:44 <plh> Topic: Discussion: Performance Metrics
19:01:56 <gmandyam> Jatinder: (paraphrasing) We have collected feedback from all members.
19:02:08 <Ritesh> Ritesh has joined #webperf
19:02:36 <gmandyam> Jatinger: Divided into topics.  First topic:  Expand Navigation Timing.  Gautam proposed this.  Is it of interest to anyone else?
19:03:26 <gmandyam> Jatinder:  Next topic:  define a networkType (e.g. radio, wired).  Navigation timing now has an attribute to indicate when the radio is awake.
19:03:38 <plh> http://dvcs.w3.org/hg/dap/raw-file/tip/network-api/Overview.html
19:03:49 <gmandyam> Philippe:  There already exists a spec Network Information.  How is this different?
19:05:33 <gmandyam> Ilya: An older version of Network Info API is in Android, but it is not useful.  Mozilla has a version that returns BW, but the implementation is not verified.
19:05:43 <gmandyam> Ritesh:  This kind of API is useful.
19:06:14 <gmandyam> Eric:  There was a System Information API, but because of security concerns this was never implemented.  Won't there be similar issues with this API.
19:06:36 <gmandyam> Jatinder:  Privacy/security is a concern, in order to prevent device fingerprinting.
19:06:36 <Gautam> Gautam has joined #webperf
19:06:43 <plh> http://www.w3.org/2012/09/sysapps-wg-charter
19:07:10 <gmandyam> Eric:  We should examine what failed in the Sys Info API, e.g. restrict the information being returned.
19:08:03 <gmandyam> Andrea: Sys Info API did not attract a lot of interest, and some features were split off.  Latency is of most importance to developers, not radio type.
19:08:20 <gmandyam> Jatinder:  What do you do with this information?  Is it for real-time decision making or post-processing?
19:08:53 <gmandyam> Andrea:  It can be for both.  e.g. high-latency means that smaller resources can be selected.
19:09:48 <gmandyam> Dominic:  Radio type can change frequently for mobile devices.  It may not be very useful, and for post-processing part of a page could be under one radio type while another radio type could be applicable.
19:10:13 <gmandyam> Mike (Akamai): From a CDN perspective this information is useful.
19:11:49 <gmandyam> Alois:  The better your BW is, the more resources you can consume.  Latecny is also important.  We differentiate between BW and actual connectivity (e.g. high throughput over the link but connectivity to the server does not reflect it).
19:12:52 <gmandyam> Jatinder: Next topic - define a round trip value.  Can't this already be determined from the timing value?  Is there value?
19:13:20 <gmandyam> Alois: RTT is a latency measure, and direct access may not always be possible.
19:13:55 <gmandyam> Next timing:  Next topic:  define chunked timing value (from Gautam).
19:14:16 <gmandyam> Dominic:  Could be used for burst transfer performance as well.
19:15:25 <gmandyam> Jatinder:  Next topic:  define a first paint.  It has been brought up before, but from a browser perspective this is difficult to measure.
19:16:41 <gmandyam> Dominic:  It is useful to measure user experience.  You could make runtime decisions on resource loading, layour and CSS changes.  It would be useful as long as it is not a "race to the bottom."
19:17:10 <gmandyam> plh who is speaking?
19:17:28 <pmeenan> sorry, yes - Pat Meenan
19:17:35 <gmandyam> Patrick:  First paint is not as useful as when an object is first added to the DOM render tree.
19:19:01 <gmandyam> Alois: First paint is useful.  Regarding Pat's point, we need to know when a JS action results in a screen rendering event.  We should nail down the use cases and what kind of measurements we need, but we cannot actually measure when the user sees the page.
19:19:23 <gmandyam> plh, who is speaking
19:20:25 <gmandyam> Jason: From a borwser perspective we'd like to solve it, but it is not possible.  There can be 25 layouts and 4-5 paints during a signle page load.  Also, the event firing and the rendering are no syncrhonized.
19:20:33 <gmandyam> Jason:  We need to start with use cases.
19:21:56 <gmandyam> Jason: There are inconsistent patterns between browsers as to when events are batched.
19:22:24 <gmandyam> Jatinder: There are a lot of profiling tools that can provide this data.
19:22:45 <gmandyam> Jatinder:  Next topic - new performance metrics.  Measuring frame rate.
19:23:31 <gmandyam> Paul:  Very useful, but hard to implement in browser.  There is no single paint event - there are multiple paint events happening in time.  The developer tools are not flawless.  The use of the tools influences the frame rate.
19:24:20 <gmandyam> Dominic:  A game using animation frames has an easily-determined frame rate.  The paint frame rate is not useful.
19:24:55 <gmandyam> James: What motivated this was the scrolling use case and measuring frame rate.
19:25:16 <gmandyam> Jatinder: Next topic - per-object latency.
19:27:10 <gmandyam> Peter:  I have not been able to measure object latency in the tools I have worked on.  You can measure task time in JS, but not when the pixels hit the screen.  We worked with requestAnimationFrame, but ended up using a high-speed camera to get accurate numbers (the error was 270%)
19:28:10 <gmandyam> Jatinder:  Next topic:  graphics and GPU timing.  Timing on loading HTML video.
19:28:22 <gmandyam> Unknown:  This is related to chunk timing.
19:28:36 <pmeenan> Unknown=Pat Meenan
19:28:39 <plh> s/Unknown/Pat/
19:29:11 <gmandyam> Glenn: We should document use cases better.
19:30:28 <gmandyam> Ganesh: You are using UA as a measurement tool.  Measurement tools require calibration.  I recommend that calibration tools be considered as part of the test cases to ensure consistency across browsers.
19:30:48 <gmandyam> Jatinder:  End of discussion.
19:31:20 <Alois> Next: HTTP Client Hints for Content Adaption without increased Client Latency by Grigorik Ilya (Google)
19:31:52 <plh> Topic: HTTP Client Hints for Content Adaption without increased Client Latency
19:33:09 <Alois> Use Case: Mulitple devices and adapt content to device without having multiple sites
19:33:48 <Alois> User Agent and mobile detection not reliable today
19:34:27 <Alois> cannot use it for figuring out device capabilities
19:35:27 <Alois> Media Queries another solutions but browsers will download all css files
19:36:14 <Alois> browser cannot know which it needs: landscape, portrait, print ....
19:37:56 <Alois> Device Databases: sniff UA string and adapt on server. Database needs to be maintained well
19:38:47 <Alois> client-side detection with JavaScript, works but hides resources from browsers and needs JavaScript to execute, however reliable
19:42:57 <Alois> User Equipment categories sometihing similar to browscap
19:43:40 <Alois> Akamai mobile detection mostly for mobile redirects
19:45:27 <Alois> Proposal: client-hint HTTP header
19:47:15 <Alois> Andrea: Maybe just on the first request
19:48:51 <Alois> Mick: maybe add to user agent
19:49:11 <Alois> Ilya UA already overloaded
19:49:30 <Alois> Glenn: use standard media query identfiers
19:50:36 <Alois> Paul: in favour, concern: fingerprinting
19:51:44 <Alois> Ilya: nothing new introduced. so no additional JS
19:52:29 <Alois> Dominic: capabilities for games eg. WebGL
19:53:26 <Alois> Dominic: be careful to use categories, keep as granular as possible
19:53:56 <Alois> Gotam: MS having similar idea.
19:54:15 <Alois> What if resolution changes etc.
19:55:21 <Alois> plh: not make available in incognito mode?
19:56:29 <Alois> Glenn: not individual. use do not track fo not sending
19:56:58 <Alois> Paul: dynamic switching: what about an event => API in JS for change of values
19:57:19 <andreatrasatti> q?
19:58:01 <Alois> Ilya: already works for orientation change
19:58:19 <Alois> Paul: where should this happen? IETC or Web Perf group
19:59:40 <Alois> Jason: hard problem, let's look at use cases first.  pixel not enough, screen size, distance from screen
20:00:49 <Alois> Paul: CSS alone is not enough, different widgets, mark up etc.
20:01:45 <Alois> Andrea: hard to define rules in advance for the browser to know what to do
20:02:59 <Alois> Andrea: vocabulary must be understood by browsers, cdns, servers, what if it changes over time? also have to wait for browsers to implement it
20:03:50 <Alois> Ilya: Responsive Images: How to not download additional immages
20:04:49 <Alois> Ethan: hybrid problem. Cannot be solved on client or server only.
20:05:07 <Alois> Ethan: Control which CSS breakpoints are downloaded?
20:05:55 <Alois> Ilya: Client side will continue to exist. Eliminate UA detection
20:06:17 <Alois> Gotam: How deep to go?
20:07:21 <karen> rrsagent, make minutes
20:07:21 <RRSAgent> I have made the request to generate http://www.w3.org/2012/11/08-webperf-minutes.html karen
20:56:02 <andreatrasatti> andreatrasatti has joined #webperf
20:56:09 <andreatrasatti> q?
20:56:10 <andreatrasatti> ack
20:56:15 <andreatrasatti> q?
20:56:18 <andreatrasatti> ack andrea
20:56:45 <filip> filip has joined #webperf
21:01:09 <AaronHeady> AaronHeady has joined #webperf
21:02:30 <gmandyam> gmandyam has joined #webperf
21:03:28 <andreatrasatti> Robert: I work on the gmail team
21:03:42 <igrigorik> igrigorik has joined #webperf
21:03:57 <andreatrasatti> … Initial load and that blue loading bar is a source of stress for us
21:04:15 <Alois> Alois has joined #webperf
21:04:15 <andreatrasatti> … my goal is how do we bring the initial load down to below 1 sec?
21:04:23 <andreatrasatti> … I am going to share some ideas
21:04:42 <andreatrasatti> … the initial load sequence of gmail is very complicated and we measure every phase
21:04:59 <andreatrasatti> … there are 3 main phases, establish connection, download resources, display on screen
21:05:15 <andreatrasatti> … about 1.8 seconds for the first phase
21:05:23 <andreatrasatti> … we measured it with Navigation Timing API
21:05:31 <Ritesh> Ritesh has joined #webperf
21:05:48 <andreatrasatti> … Phase 2 has 3 major steps
21:06:00 <andreatrasatti> … main page, JS, JSON stylesheets
21:06:12 <andreatrasatti> … So what's the bottleneck?
21:06:39 <andreatrasatti> … fast downloads are 1s, slow are 60s
21:06:57 <andreatrasatti> … for the fast ones the bottleneck is the personal data, for the slow ones it's the JS
21:07:17 <andreatrasatti> … one of the solutions was to reduce the size of JS
21:07:30 <andreatrasatti> … looked at RFC3229, SDCH, other
21:07:34 <andreatrasatti> … none worked for us
21:08:45 <andreatrasatti> … DeltaJS is a proposed solution, send the JS once, store it locally, and on following requests only send the delta based on a version number that the client declares to have locally
21:09:38 <andreatrasatti> … we looked at the size of deltas, over a month, each delta was about 2% of the original size and in total it meant 9% of the original size
21:10:37 <andreatrasatti> … measured, if we managed to reduce the size of 95% of JS and SS, initial load would be reduced by about 50%
21:11:43 <andreatrasatti> … in order for this to be more effective, we are thinking of some enhancements on the browser
21:12:13 <andreatrasatti> … Sha256 is about 30x slower to compute in JS as opposed to C++
21:12:35 <andreatrasatti> … so we propose exposing the Sha265 (Crypto API?) to JS
21:12:44 <andreatrasatti> … second, pre-heating
21:13:28 <andreatrasatti> … meaning pre-load "all" of localStorage, pre-load and pre-parse JS, pre-compile JS
21:13:43 <andreatrasatti> … maybe even pre-pre JS. interesting side effects
21:14:14 <andreatrasatti> … Delta-Application via HTTP, i.e. using HTTP headers
21:14:44 <andreatrasatti> … UA and server exchange version numbers and delta versions
21:15:29 <andreatrasatti> … it would be transparent to the client, but complicated to implement for us (gmail) on the server
21:15:46 <andreatrasatti> … fourth and last idea is Streaming Delta Application
21:16:03 <andreatrasatti> … pipeline parallelism between JS download, VCDIFF and parsing
21:16:13 <andreatrasatti> … add safe points to delta changes
21:16:54 <andreatrasatti> Andrea: when you talk about the protocol change for the delta is it for each resource or for the Web app as a whole?
21:16:59 <andreatrasatti> Robert: each resource
21:18:12 <andreatrasatti> Ritesh: wouldn't a better cache on the edge servers help?
21:18:33 <andreatrasatti> Robert: these numbers I showed already take cache servers into account and us forcing cache refreshes
21:18:49 <andreatrasatti> … and gmail has very frequent updates, so a lot of changes
21:19:36 <andreatrasatti> Anant: how about the memory cache in the client, there is a lot of work to do there
21:19:53 <andreatrasatti> Robert: well, the client could try to be smart, compare where it last downloaded the script from and optimize
21:20:33 <andreatrasatti> Alois: how about using appCache? Isn't this caching of the deltas on edge servers expensive?
21:20:41 <andreatrasatti> s/expensive/resource intensive/
21:21:12 <andreatrasatti> Robert: there are teams in Google that use appCache a lot and others that don't want to have anything to do with it. I am not an expert in this specific area
21:21:23 <andreatrasatti> … you have to be very selective what you do with caching
21:22:08 <andreatrasatti> … we sometimes have very aggressive on pre-fetching and this moves the load very much from client to server and sometimes overloads the server. You have to be careful
21:22:21 <andreatrasatti> Alois: you could have part of JS in appCache
21:22:30 <andreatrasatti> Robert: that's a possibility, I'm not religious
21:23:09 <andreatrasatti> Aaron: what about security of the code that you send, could malicious code be injected with deltas?
21:23:29 <andreatrasatti> Robert: I know MSFT does a lot of smart things in this space, we don't. We use checksums and those should be safe
21:23:43 <andreatrasatti> Aaron: checksums might check, but who knows what's inside?
21:23:52 <andreatrasatti> Robert: it's a possibility, but we are not that concerned
21:25:32 <JatinderMann> JatinderMann has joined #webperf
21:26:03 <mmccall> q?
21:26:10 <MIckH> MIckH has joined #webperf
21:26:30 <Eric> Eric has joined #webperf
21:27:03 <mmccall> Improving Performance Diagnostics Capabilities in Browsers	Error Logging	Alois Reitbauer (Compuware)
21:27:27 <mmccall> Every platform has a management API, Java, .NET, Ruby
21:27:45 <mmccall> None gives you all of the details you need
21:28:16 <Eric> Eric has left #webperf
21:28:35 <mmccall> Analyze perf across browsers.  Today, you need to use multiple tools to get metrics
21:28:46 <mmccall> Not useful for automated testing
21:29:22 <mmccall> Client-side monitoring of a web application - web page might be opened for hours or days
21:29:50 <mmccall> If you have a memory leak, there's no way to get access to the information
21:30:28 <mmccall> resolving user complaints: try to reproduce the bug locally, need to install tools locally.  doesn't work
21:30:46 <mmccall> would like to have a way to remotely debug an application in a browser
21:32:08 <mmccall> looking at resource/nav timing, need to load the page.  no means to get information beyond when the page was initially loaded
21:32:58 <mmccall> don't have access to 3rd party's code - no way to say "I want to see the code" and determine what they're doing on your page
21:33:38 <mmccall> want to see optimize network usage of a web app - hard to get information if a content network is in the mix
21:34:21 <mmccall> finding execution hotspots: how do i know that code takes a long time to execute within the page?
21:34:50 <mmccall> Chrome has a way to profile performance; why can't we automatically trigger it?
21:35:10 <mmccall> No way to send back a heap dump from JavaScript
21:36:03 <mmccall> finding layout and rendering hotspots: modifying DOM has an effect, need to track time it takes to do it
21:37:08 <mmccall> Proposal: an API to gather detailed performance data as other platforms have
21:38:38 <mmccall> privacy and security: hope to provide a diags interface, in doing so, a user would need to accept sending the information
21:39:29 <mmccall> Goal is trying to find execution hotspots
21:40:06 <mmccall> Ethan: doing diagnosis in the content itself, interested in having an outside interface?
21:40:46 <mmccall> Alois: want to be able to remotely enable it.
21:40:55 <mmccall> Philippe: what about web driver API?
21:41:36 <mmccall> Alois: getting an HTTP channel into the user's browser won't be possible.  difficult to make work in a diagnostics use case in production
21:42:05 <achicu> achicu has joined #webperf
21:42:10 <achicu> q+
21:42:16 <mmccall> Profiling APIs already exist in browsers, let's expose them via a JavaScript API
21:42:40 <mmccall> Ethan: thinking about Chrome extension model
21:43:52 <plh> acl achicu
21:43:53 <mmccall> Alois: APIs don't exist at all now today, let's start by getting something
21:43:55 <plh> ack achicu
21:44:43 <mmccall> Alex: debugging the debugging code?
21:45:24 <mmccall> Alois: Heap data could get very large, separate environment for the debugging code
21:45:52 <mmccall> worker processes could be very useful here
21:46:49 <mmccall> Alex: security, don't necessarily want to know about Facebook widget's data
21:47:38 <mmccall> Alois: could be able to request permissions for third-party resources.  make the user aware of this information
21:48:31 <Michelangelo> Michelangelo has joined #WebPerf
21:49:38 <mmccall> Peter: should also include rendering and layout performance.  JS hotspots are important, but layouts are problematic
21:50:14 <mmccall> Alois: agree, covered in the document
21:50:53 <mmccall> Paul: talking about two different things, framework for profiling, on top of that are APIs
21:52:01 <mmccall> Ganesh: local storage option.  data is dense, might prevent you from transmitting it remotely.  might be able to analyze locally
21:52:20 <mmccall> Alois: if the API exists, you can determine which data you want to ship back
21:53:06 <mmccall> Time to start getting information out of the JIT?
21:53:53 <mmccall> If web devs have to worry about whether or not something was JITed, we're doing something wrong.
21:55:08 <igrigorik> -----
21:55:11 <igrigorik> Improving Web Performance on Mobile Web Browsers - Ben Greenstein (Google)
21:57:06 <igrigorik> .. Desktop browsing is fast, relatively speaking. Desktops and laptops are over-provisioned to display pages
21:57:52 <igrigorik> .. Mobile is 10x behind (average PLT ~9s), 10x less processing power, 10x less memory
21:58:15 <igrigorik> .. Why slow? High RTT, slow transfer rates
21:58:56 <igrigorik> .. world averages: 2.4mbps, 280ms RTT, USA avg: 3.2mpbs, 420ms RT -- speeds are disproportionately higher than RTT
22:00:32 <igrigorik> .. PLTs on mobile vary over an order of magnitude (3-15s is typical)
22:02:15 <igrigorik> .. location matters for LTE speeds - wide distribution of speeds; even small changes in location affect available bandwidth (ex, line of sight vs. ...)
22:02:51 <igrigorik> .. time of day affects bandwidth (in same location)
22:03:19 <igrigorik> .. as you would expect, performance varies by carrier
22:04:01 <igrigorik> .. on mobile, characterizing the PLT is very hard due to variability
22:04:36 <igrigorik> .. The CPU on the phone is sometimes the bottleneck - ex, javascript execution
22:05:44 <igrigorik> .. What can we do improve state of art? Need lots of measurements with broad coverage.
22:06:24 <igrigorik> .. need techniques to inform origins of expected performance -- ex, allow the client to notify the server of current link conditions
22:07:27 <gmandyam> q+
22:07:40 <igrigorik> .. we need to help developers diagnose problems with better tooling
22:08:49 <igrigorik> .. Gary (Qualcomm): we already do some bandwidth estimation on modem side.. in practice, need cooperation from lower layers in the stack to do reliable estimation. how do we get a consistent interface?
22:09:22 <igrigorik> Ben: various mobile OS's should be exposing more information about the channel
22:12:02 <plh> ack gma
22:12:32 <igrigorik> Mike: bandwidth estimation through fetchign additional resources.. results in extra power + bandwidth consumption
22:16:28 <igrigorik> Derek (Microsoft): exposing more information to the client about current network conditions would definitely help
22:16:30 <gmandyam> gmandyam has joined #webperf
22:18:20 <JatinderMann> Topic: Improving Mobile Power Consumption with HTML5 Connectivity Methods
22:18:36 <JatinderMann> Presenter: Giridhar Mandyam
22:20:28 <JatinderMann> Giridhar: I am at the Qualcomm innovation center, which is a subsidairy that Qualcomm started so that we can more easily contribute to the open source community, like drivers, WebKit contributors. The parent company is very active in the modem, cell and application side.
22:20:48 <JatinderMann> ... Today, I wanted to talk about mobile web consumption.
22:22:08 <JatinderMann> ... The paper maybe a bit dense, but it provides examples of mobile power consumption. Web performance has had made great strives when it comes to mobile web performance, including JIT, Graphics rendering and hardware based co-optimzations.
22:22:41 <girishr> girishr has joined #webperf
22:22:48 <JatinderMann> ... Mobile device power consumption is not sufficiently studied today. Difficult to assess and web developer don't always have a specific focus on mobile devices or power consumption.
22:23:23 <JatinderMann> ... The developer research by Facebook was that the native battery APIs are only being used by battery makers, and not real world developers.
22:24:27 <JatinderMann> ... If we go back in history, iPhone was the first vendor to measure web network bandwidth, in a similar way to talk time.
22:25:06 <JatinderMann> ... Many new HTML5 features that are potentially battery draining, like video, webGL, and new connectivity methods like websockets, webRTC.
22:25:46 <JatinderMann> ... We now have new persist connectivity features that can impact battery life.
22:28:01 <JatinderMann> ... Websockets and mobile battery life. Websockets are new to html5 as a web communication method between web-based clients and servers. E.g., you can think of chat applications that would use this. All modern browsers (Chrome, Firefox, IE, Opera) support this API.
22:28:56 <JatinderMann> ... IETF defines a similar spec (RFC 6455) to the websocket.
22:31:30 <JatinderMann> ... Bit alarmed with some of the developer guidance that has been made on websockets. Some of the aspects have been difficult to implement (Google disabled the keep-alive in SPDY because of the variability in the network). There are some guidance that says to not rely on underlying mechanisms, but instead check if the connection is active with dummy data.
22:32:27 <JatinderMann> ... There are scenarios where the modem can power down its radio when it detects that no data is coming down. Keep-Alive breaks this model, because the radio is kept alive unnecesary.
22:33:51 <JatinderMann> ... A little test where we are checking the battery connection with a websocket on the page. Keep alive message was sent every 3 seconds, he can see that the rate of power reduce reduced from 0.5% to 0.2%.
22:34:21 <JatinderMann> ... WebRTC also has an implication to battery life. WebRTC is in the process of being standarized, so this is a bit more theoritical.
22:34:40 <JatinderMann> ... WebRTC is web real time communications which includes voip, video, streaming.
22:36:02 <JatinderMann> ... The API basically has two main functionality, the peer connection and the getUserMedia (media capture). Peer connection is currently only available in Chrome, whereas getUserMedia is supported in most browsers.
22:37:22 <JatinderMann> ... Ideally, WebRTC session would leaverage all qoS mechinasms available. The way LTE ("long-term evolution") differs from 4G, which uses OFDM method (orthogonal frequency division multiplexing).
22:38:21 <JatinderMann> ... With LTE, they came up with if you have a real time service, QoS, it gets special scheduling. No QoS is referred to as an "over-the-top" (OTT) service. We found that QoS has implications on battery life.
22:39:48 <JatinderMann> ... The basic idea is that you can basically shut off your transmitter when you're not talking. When you are talking, that is when you power usage is at the highest rate. The way LTE is setup is that you can minimize the number of timeslots when you don't need it. One is dynamic scheduling where you just request a time slot, while the other is semi-persistent which checks at different times.
22:41:00 <JatinderMann> ... What we found is that when we use semi-persistent scheduling, we can see up to 20% power consumption reduction.
22:42:41 <JatinderMann> ... How does this impact the web performance WG? The most vaulable thing the web performance WG can provide is to create the best practice guidelines to share with web developers. Ensure minimum performance for implementations of new battery API so that developers can leverage during runtime.
22:43:55 <JatinderMann> ... Also, indicate to web developers whether cellular QoS is being levered in a persistent connectivity session. Also, add explicit metrics regarding the state of the connection propagated through JavaScript. Extend what we started with Navigation Timing, include things like adding packet loss percentage.
22:45:01 <JatinderMann> Paul: Last week, in the device working group, the thing that came up was that it was very hard to test implementation when it comes to battery. E.g., it is very hard to simulate batteries, like a driver that can create a battery life usage on a particular OS.
22:46:41 <JatinderMann> Giridhar: There is no easy way to do this today. Using the battery API, when I loaded the page, I could get perfect reading. After using websocket, the results of the battery API would change. Reloading the page would reset the socket. I agree, that it would be useful to have a better.
22:47:14 <JatinderMann> Anand: Do we need a finer grade battery API that can point to what the culprit is?
22:47:36 <JatinderMann> Giridhar: The battery API just came out and it's not even been uniformly implemented. That could be nice.
22:48:21 <JatinderMann> Anand: The battery usage is a result of a certain activity., E.g., my screen is too bright. This might be useful to get this data.
22:48:40 <plh> s/Anand/Anant/g
22:48:55 <JatinderMann> Alois: That's kind of indirect way of looking. Typically knowing that you are consuming more resources will have an impact on battery.
22:49:11 <JatinderMann> Paul: Do we know if there is a proposal in the W3C for power consumption?
22:50:12 <JatinderMann> Giridhar: I don't know if there is. I mentioned things like fast dormancy, different mobile vendors have different metrics to determine this.
22:51:25 <JatinderMann> Alois: It's perfectly valid for testing purposes. When you think about a user's phone, they have some much stuff running in the background. The readings you get doesn't have anything to do with your application. It may be representing another application in the background (another app is downloading resources). This sounds interesting just for a testing point of view.
22:52:29 <JatinderMann> Giridhar: There are some things that the web performance WG has done to help here. Like the Page Visibility API, where you can throttle acitivity based on visibility. However, in mobile sites, we expect that few sites will be visible at a given time.
22:53:33 <JatinderMann> Pat: Do you know if there is anything going on the networking side for transmitting data to a mobile device? Like the mobile device is mostly in a listening session.
22:54:45 <JatinderMann> Giridhar: There was a proposal where websites could request a certain type of access, which KDDI will be discussing later on. There is a point of view, where connectivity is better managed in the aggregate. Why send a bunch of packets one at a time, why not batch them up.
22:55:08 <JatinderMann> Pat: I'm thinking about not using TCP over the radio, use something else on the mobile.
22:56:03 <JatinderMann> Giridhar: That's a pretty mature thought. IBM was looking into this in the past, of using mobile proxies to do this. SPDY to some extent can be considered to do something like this, even though it is on the server side.
22:57:52 <JatinderMann> Jason: I was going to pose the a question that what should the browser take in terms of battery consumption, and what should the developers start doing? For example, the aggregation that you have mentioned this, we have been doing this in IE9 through using collaesed timers, where developers get this free. We would love to see other browser vendors to help do some of these things in the background as well. Including things like supporting[CUT]
22:58:16 <JatinderMann> ... efficiently use CPU. URL: https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/setImmediate/Overview.html
22:59:00 <JatinderMann> Igrigorik: I guess from a web developer point of view, there not really concerned with battery.
22:59:59 <JatinderMann> Jason: I agree, but should we have thousands of web developers make the web application more battery efficient or should we have the four browser vendors help solve this problem.
23:00:20 <seth> seth has joined #webperf
23:00:33 <Anant_> Anant_ has joined #webperf
23:00:49 <JatinderMann> Igrigorik: An example from a study that AT&T was looking at Pandora where it was sending a ping every couple of seconds, by changing this they helped save battery life by 40%.
23:01:23 <JatinderMann> Jason: That study was done in Safari, which doesn't do the collaesing of timers. If you checked that study in IE9, you'll not see that battery impact.
23:04:45 <JatinderMann> http://blogs.msdn.com/b/ie/archive/2011/03/28/browser-power-consumption-leading-the-industry-with-internet-explorer-9.aspx
23:15:54 <AaronHeady> AaronHeady has joined #webperf
23:19:28 <Michelangelo> Michelangelo has joined #WebPerf
23:19:52 <simonjam> simonjam has joined #webperf
23:20:11 <rhundt> rhundt has joined #webperf
23:20:32 <rhundt> Paul Bakaus talking on "Measuring Memory"
23:21:20 <rhundt> Realized that on so many devices, especially mobil devices, measuring memory is _the_ most important thing to do
23:22:04 <rhundt> Equally important: Load (makes players play), runtime (makes players come back). Navigation timers help on load, but how about runtime?
23:22:27 <rhundt> Statement: The BIGGEST performance bottleneck on mobile is: MEMORY
23:22:32 <RiteshMaheshwari> RiteshMaheshwari has joined #webperf
23:22:32 <Chihiro> Chihiro has joined #Webperf
23:23:09 <rhundt> Memory is taken by: Static assets (CSS, JS, uncompressed images) - how much memory do they take?
23:23:46 <rhundt> Images and DOM correlation is unclear, when they are unloaded is "unknown"
23:24:06 <rhundt> DOM nodes not representative, what's the underlying memory?
23:24:42 <rhundt> Unloading images appears impossible in many situations.
23:25:11 <rhundt> Apparently, both compressed and uncompressed images are being cached in mem.
23:25:23 <rhundt> No control over that
23:26:33 <rhundt> HW acceleration is unpredictable, we want information when _exactly_ textures are created, destroyed, recomposited.
23:27:09 <rhundt> Optimal: Users shouldn't care about this, for game devs, however, part of the job.
23:29:35 <rhundt> Insight: All modern browsers GPU accelerated canvas
23:30:14 <rhundt> browsers and/or GPU use algorithm to determine when textures are still alive and needed
23:30:35 <rhundt> We want to understand when textures are buffered vs being released.
23:32:05 <rhundt> Statement: If ALL mem is consumed, your page performance goes to hell.
23:32:28 <rhundt> As a matter of fact: Browsers do crash, also on Android, iOS
23:32:52 <rhundt> Developers don't know when apps reach the limit.
23:33:45 <rhundt> Observation: More images on canvas deteriorates Paint.
23:34:23 <rhundt> Turning to GC
23:34:28 <rhundt> Wants:
23:34:34 <rhundt> - trigger GC manually
23:34:47 <rhundt> - GC timings
23:34:51 <rhundt> - disable GC
23:35:00 <rhundt> - understand execution "interval"
23:35:30 <gmandyam> gmandyam has joined #webperf
23:35:34 <gmandyam> q+
23:35:37 <rhundt> Knowing about GC rates and times would allow to throttle a game's FPS
23:36:06 <rhundt> Developers go through pain to easy GC pain:
23:36:12 <rhundt> - reuse array/objects
23:36:17 <rhundt> - object pooling
23:36:30 <rhundt> replace native methods with custom implementation to avoid GC
23:36:40 <rhundt> - Favor Function#call
23:37:22 <rhundt> QUESTIONS
23:38:11 <rhundt> Comment: Manual GC invocation might not "scale"
23:38:25 <plh> s/Comment/Giridhar/
23:38:28 <rhundt> especially across multiple tabs
23:39:52 <rhundt> Alois: This gels with his proposal, being able to push the runtime to the max is desirable. Manual GC triggering could be "scary" for people/devs
23:40:31 <rhundt> Response: It would be nice if GC could be parameterized, e.g., pick 1 of 5 different flavors...
23:41:03 <rhundt> Alois: Probably not workable, as every freaking VM implements different GCs
23:41:57 <rhundt> Microsoft's IE has GC exposed.
23:42:39 <achicu> achicu has joined #webperf
23:42:42 <rhundt> Unknown/question: Why does this have to be exposed to begin with?
23:42:56 <rhundt> There is no real control of GC algorithms anyways
23:43:06 <rhundt> Answer: Still important to know
23:43:52 <rhundt> Suggests sort of an adaptive algorithm, to work around browser's GC behavior?
23:44:02 <rhundt> At least developer has control
23:44:53 <rhundt> Alois: Browsers built for browsing, not for running Apps. Behavior changes for long running Apps (rhundt: couldn't agree more)
23:45:05 <rhundt> THANKS to THE SPEAKER
23:45:20 <karen> rssagent, make minutes
23:45:25 <karen> rrsagent, make minutes
23:45:25 <RRSAgent> I have made the request to generate http://www.w3.org/2012/11/08-webperf-minutes.html karen
23:45:41 <karen> Speaker: Yosuke Funahashi, Tomo-Digi Corp., Japan
23:46:03 <karen> Topic: Preserving Frame Rate on Television and Web Browsing
23:46:17 <karen> ...I am one of the co-chairs of W3C Web and TV Interest Group
23:46:27 <karen> ...and also chair the W3C Business Group for Broadcast TV
23:46:38 <karen> ...I would like to share my viewpoint and if it helps
23:46:43 <karen> ...see how we can do work in W3C
23:46:50 <karen> ...Brief introduction of the two groups
23:47:22 <karen> ...This is from the last TPAC face to face meeting
23:47:30 <karen> ...show you the hot topics in this group
23:47:46 <karen> ...the group is also in the period of rechartering; gathering and studying what to do over the next two years
23:48:05 <karen> ...As you  may have noticed, the IG role is not to develop specification, but rather to gather and develop use cases
23:48:18 <karen> ...then IG provides these use cases and requirements to other Working Groups
23:48:24 <karen> ...some also join to create the specifications
23:48:27 <karen> ...that is how the IG works
23:48:35 <karen> ...We had a Home Networking task force
23:48:48 <karen> ...We also met with Device API WG and collaborating with them
23:49:01 <karen> ...Another example is Media Pipeline task force
23:49:26 <karen> ...they are developing Encrypted extensions and media source extensions as part of HTML5 Working Group
23:49:34 <karen> ...also looking at exposing content
23:49:39 <karen> ...liasing with other groups
23:49:43 <karen> ...following up
23:49:50 <karen> ...stereoscopic 3D web
23:49:58 <karen> ...TTML; ITU
23:50:04 <karen> ...rechartering work
23:50:21 <karen> ...So what is TV perspective on performance issue
23:50:27 <karen> ...important for web browser on tv
23:50:44 <karen> ...but real timeness is more important because tv shows something in real time
23:50:50 <karen> ...that is the tv experience
23:51:08 <karen> ...faster and faster...right frame, right timing
23:51:20 <karen> ...I don't think we should have RT-browser
23:51:23 <RRSAgent> I have made the request to generate http://www.w3.org/2012/11/08-webperf-minutes.html plh
23:51:31 <karen> ...we should have adequate performance APIs
23:51:35 <karen> ...to maximize UX
23:51:53 <karen> ...I would like to see how this working group and the Web TV and Business Group can work together
23:52:03 <karen> ...My motivation
23:52:07 <plh> rrsagent, this meeting spans midnight
23:52:17 <karen> ...A browser is a browser
23:52:25 <karen> ...Focus on other performance issues on tv devices
23:52:39 <karen> ...biggest difference between smart phones and smart tv is showing video continuously
23:52:46 <karen> ...and the spectrum and GPUs
23:52:57 <karen> ...TV can show video screen without drop of frame
23:53:07 <karen> ...if video stream stops frequently
23:53:13 <karen> ...or drops frames frequently
23:53:20 <karen> ...people think it's bad and make complaints
23:53:29 <karen> ...So it's a core value proposition and TV
23:53:32 <karen> ...core difference
23:53:41 <karen> ...Expensive smart phone, your web page
23:53:54 <karen> ...may be slow, but you don't think it's that bad
23:54:02 <karen> ...but people don't think that way with TV
23:54:17 <karen> ...an expensive TV is capable of showing continuous frame video smoothly
23:54:25 <karen> ...Web Apps on TV vary on a wide spectrum
23:55:04 <karen> ...The gap between expensive and inexpensive TVs is big
23:55:14 <karen> ...gap between tv and web apps is key factor
23:55:26 <karen> ...you target devices in very broad spectrum
23:55:31 <karen> ...that is the situation with the TV industry
23:55:51 <karen> ...This is the the performance and interop lab in Tomo-digi
23:55:59 <karen> ...based on XHTML2.1
23:56:02 <karen> ...extend regionally
23:56:09 <karen> ...to synchronize broadcast signals
23:56:19 <karen> ...of course that specification does not have web apis
23:56:25 <karen> ...we have been doing projects
23:56:34 <karen> ...study and investigate the chips
23:56:36 <karen> ...they are using
23:56:39 <karen> ...and in some cases we ask
23:56:48 <karen> ...about the secret performance measure of the devices
23:57:04 <karen> ...and application developer create different user
23:57:12 <karen> ...and check how they work on actual devices
23:57:20 <karen> ...I think this is not a good way
23:57:26 <karen> ...So when we use HTML5 on TV
23:57:33 <karen> ...we call connected tv, smart tv or next tv
23:57:39 <karen> ...we should have some good performance API
23:57:48 <karen> ...and should be able to collect all of the information from these devices
23:57:53 <karen> ...So I picked up some issues
23:58:02 <karen> ...or use cases to clarify how use
23:58:15 <karen> ...Issue one is preserving frame rate of web apps on TV set
23:58:35 <karen> ...MPEG DASH works well for preserving frame rate
23:58:55 <karen> ...DASH is Dynamic Interactive Ad replacemetn over HTTP
23:59:07 <karen> ...client controls which screen they will use according to the information about bandwidth
23:59:17 <karen> ...if bandwidth narrows, they change stream
23:59:23 <karen> ...image may be...get worse
23:59:31 <karen> ...no results for drop of frame
23:59:40 <karen> ...usercan watch video stream...that's DASH
00:00:01 <karen> ...I would like to have similar mechanism to select UI of TV web apps to preserve frame rate
00:00:15 <karen> ...Developers need to know performance information, including frame rate
00:00:29 <karen> ...need to know the characteristics of each devices when they design web applications
00:00:33 <karen> ...when they tune it up
00:00:56 <karen> ...and we can use the same facility to dynamically change the user interface
00:00:58 <karen> ...for example
00:01:13 <karen> ...the fastes scenario is using WebGL to synchronize with tv program
00:01:16 <karen> ...in some situations
00:01:23 <karen> ...for example search of memory or processor
00:01:28 <karen> ...WebGL will not work well
00:01:34 <karen> ...so they fall back to another scenario
00:01:41 <karen> ...to maintain user experience
00:01:53 <karen> ...Potential discussion spaces on this topic with W3C
00:02:25 <karen> ...Web and Broadcasting Business Group is gathering and polishing business use cases
00:02:41 <karen> ...and Web and TV Interest Group is clarifying requirements and gaps
00:02:47 <karen> ...So I would like to hear how we can cooperate
00:02:53 <karen> PLH: Any questions or opinions?
00:03:05 <karen> Paul, Zynga: First, I think this is really important; we need for games as well
00:03:10 <karen> ...we're running on game loop
00:03:15 <karen> ...other side as well
00:03:19 <karen> ...requesting frame rate
00:03:30 <karen> ...if not on tv, but on computer that runs at 60HZ
00:03:41 <karen> ...and video is encoded at 24fps
00:03:47 <karen> ...a good way to request a certain frame rate
00:04:00 <karen> ...but I don't know any browsers that can do that...kind of stupid
00:04:09 <karen> PLH: any other reaction or questions?
00:04:23 <karen> ...Seems to me that the Web & TV IG can continue to narrow the requirements
00:04:29 <karen> ...that will help us to develop the specification
00:04:34 <karen> ...no reason not to include you guys
00:04:48 <karen> Yosuke: thank you
00:04:59 <karen> rrsagent, make minutes
00:04:59 <RRSAgent> I have made the request to generate http://www.w3.org/2012/11/08-webperf-minutes.html karen
00:05:47 <simonjam> "use-case of smart network utilization" for better user experience by chihiro ono of kddi
00:06:23 <simonjam> several use cases for smart networks:
00:06:46 <simonjam> contents flexibly chosen based on user environment
00:07:05 <simonjam> ex: wifi is high quality, 3g is low quality
00:07:29 <simonjam> alternately, choose content type, like text for low bandwidth connections
00:07:36 <simonjam> finally, adjust traffic volume
00:07:56 <simonjam> session at tpac 2012: smarter apps for smarter phone
00:08:30 <simonjam> who should decide smart network? app devs or browsers?
00:08:53 <simonjam> what type of adaption to make? choose content for network or choose network for content?
00:09:25 <simonjam> telecom operators have the ability to provide network condition information
00:09:35 <simonjam> do we need it? and why?
00:10:32 <kt> kt has joined #webperf
00:10:36 <simonjam> usage example: check with policy server and include current status, like wifi quality.
00:10:46 <simonjam> questions:
00:11:08 <simonjam> andrea: talked about headers including information. what if operators did it instead?
00:11:24 <stakagi> stakagi has joined #webperf
00:11:31 <simonjam> ilya: can't inject a header in all situations
00:12:42 <simonjam> ilya: lot of work to plumb the data up and down the network stack
00:13:23 <RiteshMaheshwari> Open Discussion (Jatinder Mann)
00:13:50 <RiteshMaheshwari> Jatinder: any burning question?
00:14:27 <RiteshMaheshwari> Arin, MS: End user monitoring. Used keynote, gomez etc. Still not enough.
00:15:03 <RiteshMaheshwari> Aaron*
00:15:05 <karen> s/Arin/Aaron Heady, Bing, MS
00:15:40 <RiteshMaheshwari> ... availability @ end user? Dns goes down, but for a low percentage. How can we use browser for monitoring agent, esp for failure case
00:16:28 <RiteshMaheshwari> ... Browser should store all these failure event logs. Next time page load, re-execute the JS and poll that data and send it back
00:17:15 <RiteshMaheshwari> ... we don't see intermittent errors (1% failure). Slowly builds up to other datacenters.
00:18:10 <RiteshMaheshwari> ... base error rate goes up. Success load causes browser to send event log to origin
00:18:44 <RiteshMaheshwari> ... Basic proposal: Browsers should become error monitoring infrastructure
00:19:22 <RiteshMaheshwari> ... persist errors. May be send it back Async way
00:20:22 <RiteshMaheshwari> ... Combine failure cases + performance together.
00:20:43 <RiteshMaheshwari> Alios: Agreed.
00:21:10 <RiteshMaheshwari> ... we really want to monitor when it doesn't work
00:22:19 <RiteshMaheshwari> Eric: Hurricane sandy, gizmodo had error page. Can't access this site, other users are facing similar problems
00:22:58 <RiteshMaheshwari> .... have server that tells you which site is down or not
00:23:09 <RiteshMaheshwari> Aaron: That's useful, but we need more
00:23:22 <RiteshMaheshwari> ... especially for low error rate case
00:23:59 <RiteshMaheshwari> ... 10 hrs to detect a HTTP error. Had to take a pcap to debug. Such a low rate, couldn't find issue with normal monitoring
00:24:25 <RiteshMaheshwari> ... It was a proxy issue, only some end-users.
00:25:19 <RiteshMaheshwari> Eric: having service is better, since user may not go to your site again soon
00:26:35 <RiteshMaheshwari> Ritesh: HTTP Post can send this async
00:27:32 <RiteshMaheshwari> Mike: beaconing API is good. Fire and forget
00:27:56 <RiteshMaheshwari> Jatinder: Async is good since it doesn't hold up
00:28:50 <RiteshMaheshwari> Mick: Use a permanent JS per origin in browser
00:29:09 <RiteshMaheshwari> Gautam: Similar to watson service in windows
00:29:34 <RiteshMaheshwari> .... when app fails, dump is saved. Stored locally, batched and queued and sent to MS server
00:30:22 <RiteshMaheshwari> Jatinder: Anything else. Error reporting is cool
00:30:33 <RiteshMaheshwari> Anant: Time to above fold event
00:30:42 <RiteshMaheshwari> Jason: How to define it?
00:31:19 <RiteshMaheshwari> Anant: Templates, async loading etc
00:31:29 <RiteshMaheshwari> Pat: Why not use user-timing?
00:32:02 <RiteshMaheshwari> ... which content do you care about? Gets complicated. Speed index is tacking something like this.
00:32:32 <RiteshMaheshwari> Eric: Developer should decide
00:33:15 <RiteshMaheshwari> Jason: What is loaded time for image?
00:33:27 <RiteshMaheshwari> .. when it is downloaded, loaded in memory etc etc
00:34:06 <RiteshMaheshwari> Jason: would love to have above the fold, but its hard. We don't know how to measure it
00:34:41 <RiteshMaheshwari> ... we have a perf lab. We capture video and sequence to diff ms level. Even there is hard to figure out above the fold
00:35:27 <RiteshMaheshwari> Paul: you do know first paint
00:35:42 <RiteshMaheshwari> Jason: yes, but thats what it is. Not above the fold
00:36:30 <RiteshMaheshwari> Pat: Devs might game system if first paint is imp
00:37:36 <RiteshMaheshwari> Jason: Web devs should control their own assets
00:38:22 <RiteshMaheshwari> ?? : Whats the root case for perf problem? Need to know that.
00:38:57 <RiteshMaheshwari> ... tools are good enough, don't need to be APIs
00:39:33 <RiteshMaheshwari> ... GPU stuff, layout etc.
00:39:49 <RiteshMaheshwari> Ilya: Chrome has some tools
00:40:00 <RiteshMaheshwari> ... not user friendly, but work in progress
00:41:50 <RiteshMaheshwari> ... Chrome tracing is heavy
00:42:15 <RiteshMaheshwari> ?? : after pressing key stroke, when was the first paint after that
00:42:31 <plh> s/??/Alex/
00:42:49 <RiteshMaheshwari> ... better to have an API. Need that for automation
00:43:38 <RiteshMaheshwari> Alois: Having different approaches for different browsers makes it hard to do.
00:44:01 <RiteshMaheshwari> ... testing is not perfect since we need Real user measurements
00:44:35 <RiteshMaheshwari> ... javascript API would be better. End user can approve or not
00:44:42 <RiteshMaheshwari> ... End user can decide to send or not
00:45:06 <RiteshMaheshwari> Jason: Agreed that chrome tools are heavyweight and we have same for windows
00:45:38 <RiteshMaheshwari> ... but that level of tracing collects 2MB/s. Too much data for real users
00:46:03 <RiteshMaheshwari> ... dev tools are OK, but light weight piece for real world is not clear
00:46:24 <RiteshMaheshwari> Alois: Could be somewhere between. Better than nothing.
00:46:52 <RiteshMaheshwari> ... Useful for debugging at the end-user level
00:47:13 <RiteshMaheshwari> Alex: Even in lab is hard if you want to automate
00:47:43 <RiteshMaheshwari> ... for perf testing
00:47:52 <RiteshMaheshwari> Jason: IE has good blogs for that
00:48:34 <RiteshMaheshwari> ... in IE to find DOM change to when it shows up in glass is possible
00:49:28 <RiteshMaheshwari> Alex: Using JS not always going to give right answers
00:50:09 <RiteshMaheshwari> Jason: in production we don't know how many layouts occured
00:50:39 <RiteshMaheshwari> Alois: different data in different browsers
00:50:54 <RiteshMaheshwari> Jason: May be similar to resource timing API, do it for CPU
00:51:29 <RiteshMaheshwari> ... all work we have done is about platform
00:53:57 <RiteshMaheshwari> Arvind?, Intel: What's the use case for these APIs? We started with these use cases... show the roadmap on how we arrive at the solution
00:54:22 <RiteshMaheshwari> Jatinder: I think we should have done that. Let us know if not
00:54:56 <RiteshMaheshwari> Alois: I think the specs are clear about doc. But sometimes they are more powerful that the specs say
00:55:13 <RiteshMaheshwari> ... we need a best practice doc.
00:55:43 <RiteshMaheshwari> PLH: We launched webplatform.org
00:55:56 <RiteshMaheshwari> ... targeted towards developers
00:56:12 <karen> http://docs.webplatform.org/wiki/Main_Page
00:57:03 <RiteshMaheshwari> Derek: Not every developer know understanding of which features are slower etc
00:57:12 <RiteshMaheshwari> ... so it should go to these docs
00:57:44 <RiteshMaheshwari> Arvind: Taling about what's next
00:58:07 <RiteshMaheshwari> ... Good day, good ideas
00:58:27 <RiteshMaheshwari> ... Challenge is that there are good ideas, but very few to work on them
00:58:43 <RiteshMaheshwari> ... write the spec, be editor, group will help
00:58:57 <RiteshMaheshwari> ... we need drivers for all the work we need to do
00:59:13 <RiteshMaheshwari> Jason: excited what we pulled off in 2 yrs or less.
00:59:22 <RiteshMaheshwari> ... we have 8 specs and APIs across browsers
00:59:43 <RiteshMaheshwari> Arvind: Amazing how cooperative browsers vendors have been
00:59:59 <RiteshMaheshwari> ... No pushback.. May be since they were easy and straightforward
01:00:07 <RiteshMaheshwari> .. now more tricky problems are coming up
01:00:23 <RiteshMaheshwari> ... talked about these for a while
01:00:30 <hiro> hiro has joined #webperf
01:00:42 <RiteshMaheshwari> Jason: Lucky, since no one complains about making web faster
01:00:54 <RiteshMaheshwari> .... bite off to scope problems in bite size
01:01:24 <RiteshMaheshwari> Thanks PLH! Nice job!
01:01:33 <RiteshMaheshwari> Participate through email alias
01:01:48 <RiteshMaheshwari> PLH: We need more tests for APIs
01:02:43 <RiteshMaheshwari> Eric: Toby and I are starting perf breakout session
01:02:53 <RiteshMaheshwari> ... Toby from facebook
01:03:19 <RiteshMaheshwari> s/Eric/Paul/g
01:04:27 <RiteshMaheshwari> ... we need automated tests
01:04:32 <RiteshMaheshwari> ... as part of spec may be
01:05:03 <lmclister> s/Toby/Tobie
01:05:19 <RiteshMaheshwari> ... e.g., a browser says it supports audio, but useless if it supports with 1s latency
01:05:47 <RiteshMaheshwari> Jason: Hard since it also involves native hardware
01:06:31 <RiteshMaheshwari> ... audio is interesting, since if we compress audio on wire, then device will spend too much time re encoding
01:07:43 <RiteshMaheshwari> Derek: specify design contraints so that features adhere to them for better perf
01:12:12 <RiteshMaheshwari> Paul: Gyroscope, accelerometer APIs are promoted, but without screen orientation locl
01:12:13 <RiteshMaheshwari> lock*
01:12:59 <RiteshMaheshwari> Alois: Have seen Negative DNS time in nav timings
01:14:27 <RiteshMaheshwari> Paul: Just collect yes/no data (works or not) for developers
01:14:32 <andreatrasatti> Thank you all for a very interesting discussion all day
01:15:42 <RiteshMaheshwari> Thank you all for coming!
01:16:57 <RRSAgent> I have made the request to generate http://www.w3.org/2012/11/08-webperf-minutes.html plh
02:20:23 <girlie_mac> girlie_mac has joined #webperf
04:11:19 <girlie_mac> girlie_mac has joined #webperf
06:31:55 <girlie_mac> girlie_mac has joined #webperf
07:48:58 <Zakim> Zakim has left #webperf
08:15:16 <hiro> hiro has joined #webperf
08:26:08 <jaredw> jaredw has joined #webperf
09:38:24 <hiro> hiro has joined #webperf