W3C home > Mailing lists > Public > public-web-perf@w3.org > May 2013

[minutes] Web Performance WG Teleconference #110 2013-05-29

From: Jatinder Mann <jmann@microsoft.com>
Date: Wed, 29 May 2013 18:18:30 +0000
To: "'public-web-perf@w3.org'" <public-web-perf@w3.org>
Message-ID: <1061117176e4483e97aceafd417d2c1f@BLUPR03MB065.namprd03.prod.outlook.com>
Meeting Summary:



1.     Diagnostics

The working group discussed new diagnostics ideas: Preflight JS Injection, JavaScript profiling, Browser Activity Monitoring, Detailed Networking Diagnostics, and Event Hooking. We encourage working group members to review these ideas and provide more detailed feedback on which of these APIs we should pursue and consider further.



2.     Test Repository

The working group is considering following suite of most other working groups and move our test suite over to https://github.com/w3c/web-platform-tests. Philippe will put together documentation on the process changes prior to moving the test suite.




W3C Web Performance WG Teleconference #110 2013-05-29



IRC log: http://www.w3.org/2013/05/29-webperf-irc



Meeting Minutes: http://www.w3.org/2013/05/29-webperf-minutes.html



Attendees

Philippe Le Hegaret, Jatinder Mann, Daniel Austin, Alois Reitbauer, Rob Dickenson, Aaron Heady


Scribe

Jatinder Mann



Agenda

1.     Discuss Diagnostics

2.     Discuss Test Repository

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



Minutes:


Preflight JS Injection

Alois: We had discussed last week that if you cannot reach the webpage, you can specify JavaScript code that will be called.
... You would have a specific header, e.g., <JSPreflight src="example.js">. The UA would store this page locally, and if in the future the page isn't loaded, then this code is run.
... And this would use the same caching rules as other resources.

Jatinder: What about security issues with this?

Aaron: A malicious could use this to track or execute. My worry is that the script is executing on the client and it can send a lot of errors to the server.
... From Bing's point of view, we're more interested in the capture errors on the next load scenario. We worry that this feature may create new security issues that could increase server load.

Jatinder: I don't believe we have limitations in the web platform today where we can limit script execution based on origin. Today, any script added to a site, regardless of origin, is run the same way.
... If there is a security concern, we should run this by our security folks

Alois: I think there is a real benefit of getting real time error data, but we should follow up with security folks.

Aaron: Alternatively, instead of JavaScript, the browser could send a specific code/header back to the server to indicate an issue.

Alois: JavaScript would provide more information.

Jatinder: Let's follow up with our security teams and get back to this.
JavaScript Profiling

Alois: We could use a Chrome dev tool type JavaScript profiler that would send up the JavaScript calltree.

Jatinder: Would you run this for all users?

<Alois> https://docs.google.com/document/d/1Yw_qNMCnGsWQRsdcrifzh_kzFey-ThQ3yp-DmxuJxvg/edit#heading=h.4n2xf0vts8kq

Alois: The idea would be that if some user has a problem, you can send them a link and the user would click on the link and the browser would gather the JavaScript callstack.

Dan: This would seem like a lot of data to specify in the specification.

Alois: We can use the Chrome and IE dev tools as a start point.

Dan: This will probably be a lot of data.

Alois: You would turn this on by demand. You would turn this on based on after a user passes a certain thershold. This is kind of an extension of User Timing, where there would be more information to help debug.

Dan: Would the user need to give consent to send this data?

Alois: We can talk about the privacy concern, but using JavaScript as is today you can already get 80-90% of data.

Dan: You would want to make sure that we don't track the user through the web, e.g., by looking at the URL.

Jatinder: Is the core usecase the 'support call' scenario where someone calls to state they have an issue and somone uses this API to gather that information.

Alois: Yes, that's main the one.
Browser Activity Monitoring

Alois: An APIs that provides runtime metrics on rendering, layout, garbage collection, CPU utilization, GPU utilization, memory consumption, etc.

Jatinder: Have you used Windows Performance Analyzer? It uses ETW events to gather similar type of data. However, there is a lot of information and data to send up if you tried to do this on the web platform.
... You'd want to put together a minimal list of metrics that develoeprs would find useful. I'd love to understand how much this is necessary compared to just dev tools.
Detailed Networking Diagnostics

Alois: The goal here is to provide more detailed networking information, like IP address, HTTP headers. There are privacy concerns here that would need to be figured out.
Event Hooking

Alois: You can do this using script and user timing, but it would be easier to measure the end to end event timing by using an API to hook into events. This is lower priority compared to the other listed items.
Test Repository
Received on Wednesday, 29 May 2013 18:19:37 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:35 UTC