Hey,
Navigation Timing API[1] is getting critical mass[2], and we've been using[3] it for a while now to gather network information. The timeline one would generate in Chrome Dev Tools, shows this information. But with this API one can measure it out in the wild.
The specification process with W3C has now begun on the <s>Web Smoothness API</s> Frame Timing API (initiated by Google). This will provide similar abilities for other important part in perceived front-end performance: Rendering.
Curious what our thoughts are. How beneficial this would be to improving our ability to research user performance. If others have started looking into this.
Quick introduction from the HTTP 203 podcast: https://www.youtube.com/watch?v=4zoC3eaa9z0#t=1m10s
Call to action: http://updates.html5rocks.com/2014/11/frame-timing-api
Specification and polyfil http://www.w3.org/TR/frame-timing/ https://github.com/w3c/frame-timing https://github.com/GoogleChrome/frame-timing-polyfill
— Timo
[1] https://developer.mozilla.org/en-US/docs/Navigation_timing http://kaaes.github.io/timing/ [2] http://caniuse.com/#feat=nav-timing [3] https://www.mediawiki.org/wiki/Extension:NavigationTiming
Hello,
My 2 cents:
Tracking scrolling issues (jank) down is not easily done and in that case the API "seems" that it might actually help you quantify the performance gains/losses from making the scrolling experience smoother across your user base (just an example). Still, it seems a pretty low level API cause it's not going to point you to the culprit component when problems arise rather it's just reporting on how you are doing fps-wise.
How beneficial this would be to improving our ability to research user
performance. In the case of rendering at wikipedia-like-projects...well, I do not see it will have much effect, our main rendering case is real simple: text (in big amounts)+pictures (in small amounts). Then (correct me if I am wrong) our performance issues for readers probably come mostly from page load/image resolution/image downloads and none of these affect the frame rate.
On Sat, Feb 14, 2015 at 4:19 AM, Timo Tijhof ttijhof@wikimedia.org wrote:
Hey,
Navigation Timing API[1] is getting critical mass[2], and we've been using[3] it for a while now to gather network information. The timeline one would generate in Chrome Dev Tools, shows this information. But with this API one can measure it out in the wild.
The specification process with W3C has now begun on the <s>Web Smoothness API</s> Frame Timing API (initiated by Google). This will provide similar abilities for other important part in perceived front-end performance: Rendering.
Curious what our thoughts are. How beneficial this would be to improving our ability to research user performance. If others have started looking into this.
Quick introduction from the HTTP 203 podcast: https://www.youtube.com/watch?v=4zoC3eaa9z0#t=1m10s
Call to action: http://updates.html5rocks.com/2014/11/frame-timing-api
Specification and polyfil http://www.w3.org/TR/frame-timing/ https://github.com/w3c/frame-timing https://github.com/GoogleChrome/frame-timing-polyfill
— Timo
[1] https://developer.mozilla.org/en-US/docs/Navigation_timing http://kaaes.github.io/timing/ [2] http://caniuse.com/#feat=nav-timing [3] https://www.mediawiki.org/wiki/Extension:NavigationTiming
Analytics mailing list Analytics@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/analytics