We are committed to making the web faster and more reliable, and we really enjoyed attending the W3C web performance workshop a couple of weeks ago, together with representatives from Akamai, Google, Microsoft, and many others. This was a day packed with information, often very detailed and technical, about all different kinds of aspects of web performance.
There is an official summaryof the workshop, including links to the presentations, but we felt we should give you some of the highlights.
Beacon API might reduce need for JavaScript
One of the most interesting topics covered at the workshop, especially as it relates to RUM (Real User Monitoring), was the Beacon API (and, by the way, you can join our RUM beta program if you like). The working group is discussing the API, which would allow transfer of loading and performance data from the web browser back to the server without affecting page load.
If implemented, the Beacon API would essentially open up the possibility to get RUM measurements without having to involve JavaScript at all, and without the need to modify the site content or affect the user’s perceived website loading speed.
Mike McCall of Akamai presented a proposalentitled “An HTTP Extension to provide Timing Data for Performance Measurement”. It seems to be the closest thing to a realization of the Beacon API that exists at the moment.
The proposal would allow servers to provide a URL to which the browser can post performance data without the need for adding JavaScript code to the site. This would be based on new client request headers: X-Accept-Measurement, X-Send-Measurement, and X-Timing-Measures.
Delta only delivers what has changed
Beginning by revealing that users spend a combined total of 61 years every single day watching the Gmail loading bar, Robert Hundt presented how using delta delivery on Gmail has the potential to reduce the amount of data transferred when loading the site quite significantly. The idea is to speed up page load by only sending the difference between the version of a resource the browser has in the cache and the latest version.
Client Hints header
Finally, one other thing that was discussed at the workshop, which we found very interesting and promising for the future was the proposed Client Hints header.
It’s clear that we browse the web with an increasing array of devices, ranging from smartphones, to tablets, computers, and more. Each one has its specific set of hardware and capabilities, usually reported today through the detection of a User-Agent setting before page load, or via JavaScript after page load.
Presented by Ilya Grigorik at Google, the HTTP Client Hints for Content Adaption would allow the server to read the capabilities of the device (as presented by the User Agent) through the HTTP header. The server can then send the content appropriate for those capabilities to the client, reducing the amount of data sent and the time spent.
A group of web performance lovers
We should also point out that Resource Timing, User Timing and Performance Timeline APIs have been implemented in IE10, and are coming soon to Google Chrome, as well. But that’s a topic we’ll have the opportunity to come back to another day.
Overall, this was a very interesting trip and taking part in the workshop was useful in many different ways. We got to meet colleagues and friends in the business, we learned of some of the future plans for the W3C’s Web Performance Working Group, and we got a better sense of where we need to go in the future in terms of our own products.
