- Comparing In-Browser Methods of Measuring Resource Load Times
- HTTP Extension to provide Timing Data for Performance Measurements
- Extending HTTP and HTML to enable Automatic Collection of Performance Data
- Discussion: Expanding and Improving on Performance Timing Interfaces
- HTTP Client Hints for Content Adaption without increased Client Latency
- Browser Enhancements to Help Improve Page Load Performance using Delta Delivery
- Improving Performance Diagnostics Capabilities in Browsers
- Improving Web Performance on Mobile Web Browsers
- Improving Mobile Power Consumption with HTML5 Connectivity Methods
- Preserving Frame Rate on Television and Web Browsing
- Use-case of smart network utilization for better user experience
- Open Discussion
Comparing In-Browser Methods of Measuring Resource Load Times
Eric presented a study on comparing in-browser methods of measuring resource load times that he and his colleagues had conducted at the University of North Carolina. In this study, they used various methods of measuring how long it takes to load a resource, using the DOM, XHR and Navigation Timing APIs, and compared those results with the ground truth. They found that though these interfaces did a reasonable job of measuring the timing information, there were differences in measurements amongst the browsers due to internal implementation differences.
- Browsers have internal implementation differences on when they are finished loading, which may result in differences in timing information when comparing this data cross-browser.
- Resource Timing API, now available in IE10 and shortly will be available in Chrome, is a better API for measuring resource loading information.
HTTP Extension to provide Timing Data for Performance Measurements
- Pro: The benefit of this proposal is that one does not need to run client side script to gather the Timing data.
- Pro: Hosting services can provide the ability to gather Timing analytics for the sites they host, purely from the server side without any change to client code. One can imagine a portal on the hosting service that enables timing information gathering.
- Con: This proposal does "bloat" the size of the HTTP headers and moves filtering logic from the client side to the server side.
- Con: It's unlikely that current analytics script would go away even with this feature, reducing some of the performance benefits.
- Con: The proposal does not currently address the case where the server for processing Timing data is not the same server as the one serving the data.
Extending HTTP and HTML to enable Automatic Collection of Performance Data
Philippe presented a proposal, on behalf of Radware, for extending the HTTP and HTML standards for enabling automatic collection of web page timing data; a concept similar to the previous presentation by Mike McCall. In this proposal, Radware suggest a few options in how to gather this data: (A) a new HTTP header, Performance_Reporting_Target: <URL for reporting>\r\n, or (B) a new Boolean Element attribute called perfcollect. The data would be sent back to the server in a HTTP POST and would include entries from the PerfromanceResourceTiming object.
- This proposal has similar pros and cons as the previous proposal by Mike McCall.
- Con: Parsing the entire document for Element attributes may have a performance impact.
- Con: Setting Element attributes may not be easy for elements that are added dynamically.
Discussion: Expanding and Improving on Performance Timing Interfaces
This session consisted of a discussion on the ideas raised in the survey results. There were three areas that were most raised in the survey: expanding Navigation Timing, new performance metrics, and error logging interfaces.
- Though there was interest in a networkType (e.g., radio, wired), radioType (e.g., edge, 3G, LTE, wifi), and networkSpeed (running average for last N web requests), these seemed more appropriate in the Network Information API<http://dvcs.w3.org/hg/dap/raw-file/tip/network-api/Overview.html>, which already attempts to answer some of these questions. Additionally, Radio type can change frequently for mobile devices and may not be as useful for post-processing.
- There was interest in expanding the timing APIs to include the chunk transfer encoding (CTE) timing.
- Though web developers like the concept of a firstPaint attribute (time to paint page above the fold), this is a very difficult question to answer from a browser perspective. It's not easy to specify in the standard at what point is the page painting above the fold (e.g., pages will paint a number of times before they are fully rendered above the fold).
- There were asks on an API that returns the true frame rate of painting to the screen. Today we can get the rate of script callbacks to determine frame rate, but this isn't the same thing as the rate of painting. Getting the true rate of painting may be another data pointing to when the application performance needs improvement, but it may not be as useful to developers as script call back rate, which can be calculated today. Also, some browsers always paint on the display paint beat, meaning they will always return 60FPS.
HTTP Client Hints for Content Adaption without increased Client Latency
- Pro: As only the appropriate resources need to be downloaded, time spent in the networking subsystem should decrease.
- Pro: UA detection, which is a poor model, can be significantly reduced.
- Con: Potentially can bloat the HTTP headers and forces there to be more server side computation
- Con: The client hints will make fingerprinting much more easier
- Con: Proposal needs to address dynamic switching where UA changes its capabilities (e.g., landscape mode to portrait mode).
Browser Enhancements to Help Improve Page Load Performance using Delta Delivery
- Attendees seemed to really like the idea, however, there are significant changes that would need to be made in many places to enable this feature.
- Pro: Delta delivery can significantly improve resource download times in places with poor bandwidth.
- Con: This feature would require changes to the HTTP standard. Changing HTTP is something that should be considered in the HTTP2.0 (or next version) discussions.
- Con: Antivirus vendors may not be able to determine if the delta is malicious, as they won't have access to the entire script.
- Con: How UAs use their In memory cache will need adjustments to take the delta delivery into consideration.
Improving Performance Diagnostics Capabilities in Browsers
- The goal of this API to provide more browser diagnostic information to web developers. However, there were concerns that capturing this data may have a performance impact (will need to be turned on by a flag and not always on), can be a lot of data to put on the wire (profiling tools like Windows Performance Toolkit save MBs of data per second), and what developers are going to do with this information (e.g., if developers need to be worrying about which of their code paths are being JITed, script engines aren't doing their jobs). Understanding which data points can web developers use to make actionable changes and providing a more scoped API may be the solution here.
Improving Web Performance on Mobile Web Browsers
In this session, Ben gives details on the state of web performance on mobile web browsers. Today, desktop browsing is relatively fast, whereas mobile web performance is bad; pages don't usually load in under a second (average mobile page load is 9 seconds). He found that mobile web performance is highly variable, available bandwidth has a wide distribution, small changes to location affect bandwidth, time of day affect bandwidth, and performance is variable based on carriers. He also found that gzip is off for 20% of the Alexa-1000 sites, 57% of resources don't have cache-control headers, and in many cases resources are much larger than they need to be. The ask in this presentation was that we provide better tools to measure page loads, inform origins of expected performance to get different content sent, and help developers diagnose problems.
Improving Mobile Power Consumption with HTML5 Connectivity Methods
In this session, Giridhar presented on HTML5 connectivity APIs, like Web Sockets and WebRTC, and their impact on mobile power consumption, which is potentially significant. This session gave best practices on how to use Web Sockets and WebRTC to both connect and manage power consumption. The ask of this presentation was that this working group work to provide better best practices on using HTML5 APIs in a power-efficient way, ensure performance for implementations of new W3C battery API, indicate to web developers whether cellular QoS is being leveraged in a persistent connection session, and explicit metrics regarding the state of the connection.
- Most web developers today do not seem concerned with battery life implications of their application. More education is needed.
- Today, Internet Explorer coalesces timers to improve power consumption and implements setImmediate to improve CPU efficiency; the ask is that other browser vendors consider similar techniques to improve power- and CPU-efficiency.
- Most web developers will find manual garbage collection scary and may not chose the most optimal path.
- Potentially, the application can give hints to the browser, and the browser can use those hints to make better GC decisions.
- Most memory information is not really useful to developers, as it may include total system memory (and developers don't know what other applications are running at that time) and different machines have different characteristics. We may want to better understand what the problem we are trying to solve and then work towards solutions.
Preserving Frame Rate on Television Web Browsing
In this session, Yosuke gave a presentation on the importance of preserving frame rate on television web browsing. Traditionally, television viewing has not resulted in dropped frames for users. However, with the web browser runtime working in televisions today, users are experiences scenarios where frames are being dropped. The ask is that the Web Perf working group, Web and TV interest group, and Web and Broadcasting business group work together to consider ways to ensure frame rates are not dropped during television web browsing.
Use Case of Smart Network Utilization for Better User Experience
In this session, Chihiro discusses ways in browsers and servers can use network information (e.g., Wifi or 3G or LAN), and provide content that is best suited for those user environment. For example, on a LAN network, high quality video/audio/images can be sent down, however, on a 3G network, lower quality video/audio/images can be sent to improve the performance and user experience. Some of the suggestions in this session are to provide APIs that give more detailed information on the network usage and control network interfaces for fine-grained network selection.
In the last session of the day, we opened up the floor for discussion on any of the topics presented today or topics that had not been brought up.
- Beacon API. In last year's TPAC meeting, the working group had discussed the scenario where scripts will block the current page from unloading by running in a loop in order to send analytics data to a web server. This behavior causes the perception of poor performance, as it appears the navigation is delayed. We discussed a beacon API that would send data back to a server without waiting for a response that the data has been sent. It would be a fire and forget model; the browser makes the promise that there data will be sent to the server. This concept was well received by the attendees.
- Memory Leaks. There was discussion on providing more information on heap memory and other memory data points. However, while looking at the reason for having this information, the ask is really for web developers to understand when they are leaking objects. A memory leak API or developer tooling would help developers minimize object leaks.
- Other. There were additional discussions on "above the fold" measurements, profiling tools, and other discussions. Please see the minutes for more information.