I have gathered all the issues raised in the workshop survey results. We will spend this thirty minute session discussing these feedback points together.
Define a Chunk Transfer Encoding (CTE) timing
Chunked transfer encoding is a data transfer mechanism in version 1.1 of the Hypertext Transfer Protocol (HTTP) in which data is sent in a series of "chunks". It uses the Transfer-Encoding HTTP header in place of the Content-Length header, which the protocol would otherwise require. Because the Content-Length header is not used, the sender does not need to know the length of the content before it starts transmitting a response to the receiver. Senders can begin transmitting dynamically-generated content before knowing the total size of that content.
Define a networkType: Radio, Wired
Define a radioType: Edge, 3G, LTW, Wifi
Define a bandwidth value
Define a roundTripTime value
round-trip time (RTT) is the length of time it takes for a signal to be sent plus the length of time it takes for an acknowledgment of that signal to be received. This time delay therefore consists of the transmission times between the two points of a signal.
Define a networkSpeed value: running average for last N web requests
Define a firstPaint attribute that describes the timing of when the browser first renders to the display (Above the fold time).
IE and Chrome have an experimental API that reports firstPaint
Different pages paint to the screen in different ways; a first paint is not an indication when the page is fully rendered above the fold
Difficult to design a cross-browser interoperable API
Measure instantaneous frame rate
Ways to measure basic repaint framerate (there’s a developer tool in Safari for this but it’s hard to use without a deep understanding of how rendering is split between CPU & GPU)
Per Object Render Latency: When specific DOM objects have been rendered, e.g. images.
One way to do this is to inject DOM based performance markers in addition to existing Javascript API: msWriteProfilerMark. This would help us find out when exactly parts of the page are being rendered. Essentially this will enable us to build a waterfall view for every one of our impressions showing latency per object. Today the only recourse we have is to get a waterfall view from a lab tool for a test impression that may not be representative in debugging real users perf problems
Post loaded content / Time To Render All Visible Content
PLT is almost irrelevant for infinite scroll type scenarios (Bing Images, Facebook news feed, etc.) where a lot of content is loaded after the onload event. Even our SERP page today has a lot of content like the Social Pane that is post loaded. We need a standard way to capture total time spent loading and rendering all visible elements on the page
Interactive content latency.
As we have sites move to AJAX/HTML5 / interactive experiences / animations, measuring PageLoadTime (PLT) is fuzzier. We need W3C to standardize how we measure page load for these scenarios.
Consistency for Mobile
There’s a difference between the behavior of various browsers onLoad on Mobile vs. Desktop. OnLoad event is a good proxy for page-rendering most-complete on desktop, but this is not true for many mobile browsers. Consistency would be very useful here.
Internal Browser Subsystem Timing (DOM, formatting, layout, rendering)
Timing information about the DOM and how/when elements are constructed and made visible.
This concept can be expanded to all of the internal browser subsystems (HTML parser, CSS parser, collections, JavaScript, marshaling, DOM, Formatting, Block Building, Layout, Rendering)
When browser decides to repaint?
GPU Timing
Why wasn’t a DOM node rendered as a GPU texture?
Graphics Timing
Timing data on loading HTML5 video, streaming the bytes
Timing data on long it takes to paint my SVG elements?
Error reporting
Metrics to report on the count, stack-traces and other info about Script/object/page errors encountered in the rendering of a page.