Very rough notes from the event that just ended a few minutes ago
======== 1 ========
Tony Gentilcore (google) and Anderson Quach (MSFT) talked about the W3C working group and the specs for measuring performance:
- Navigation timing spec - HTML document: DNS, handshakes, load events
- Resource timing - how long JS, CSS, audio, video... take
- User timing - interactions, such as clicking a link
Challenges: user security, privacy. Small overhead for browsers. Useful actionable data out.
Navigation timing:
window.performance
- IE9 has no vendor prefix- otherwise
window.webkitPerformance
- FF4 probably shipping it too
Properties:
window.performance.timing .domainLookup .connect .domContentLoaded .loadEvent ....etc
Specs: http://test.w3.org/webperf/specs/NavigationTiming/
Resource Timing spec - upcoming
foreach resource redirect fetchStart fetchEnd ...
User Timing - upcoming
mark('pagelet') mark('something-else') ... >>> getMarks(); { 'pagelet': 123456767 }
Stretch goals:
- painting times
- CPUs
- visibility (is the page in a background tab)
- allow real yealding setTimeout(0)
- don't animate faster than the browser paints
mailto: public-web-perf@w3c.org
======== 2 ========
Above the Fold Time: Measuring Web Page Performance Visually
Speaker: Jake Brutlag
Help from: Zoe Abrams, Pat Meenan (webpagetest) Google
What the user perception of page load timing is.
AFT (Above the Fold Timing) algo
AFT: When content above the fold stops changing and reaches its final state
Integrated in WebPageTest.org
Motivation
- AFT more representative than
DOMContentLoaded
oronload
onload
- different in IE and FF, e.g. async scripts block onload or not
Method:
- video capture
- AFT cutoff time - upper bound, e.g. 45 sec for DSL
- split pixels into static and dymanic (ads)
- AFT = latest change of a static pixel
Magic number - 5 determined empirically
static pixels are those that change less than 5 times
Application - validate other metrics, cross-browser, visual
Limitation - lab only
{I ran webpagetest.org on facebook.com with AFT on.
The results are very close to onload, as expected.
It's a simple page. Results:
http://www.webpagetest.org/result/110315_P9_5MDJ/
}
== break ==
Note from the sponsor StrangeLoop: a downloadable "State of the Union"
A study of top 2000 Alexa retail sites. Findings:
- 11.2 sec onload avg
- top 100 sites slower than the lower ranked
- those using CDNs are not faster
- failed to implement the basics - YSlow stuff
======== 3 ========
Next-gen YSlow
Betty Tso and Marcel Duran, Yahoo!
YSlow for Chrome last week
Not as accurate as Firefox cause headers, timing come from:
1. Crawl DOM
2. x-domain requests
Announcing YSlow bookmarklet version
for mobile and all other browsers to be released early april
YSlow now on Git?
Lots coming up, e.g:
- Multi-language support
- HAR-to-YSlow
- YSlow export to JDrop
Bookmarket works like:
1. crawl DOM
2. Use YQL to get headers
SELECT * FROM data.headers WHERE url IN ('http://...', 'http://...')
======== 4 ========
Visibility into Mobile Performance
Steve Souders, Google
Demo #1: http://blaze.io/mobile/
WebPageTest.org framework connected to iPhone and Android apps
Mobile waterfalls
Demo #2: pcapperf
1. setup wifi hotspot on a pc/mac
2. tcpdump to capture .pcap file
3. upload .pcap to http://pcapperf.appspot.com app
4. observe waterfall via pcap2har and harviewer
5. run pagespeed on the har
Demo #3: JDrop
http://jdrop.org
Upload JSON so you can run something on mobile and view/analyze results in desktop's large screen
Works with the bookmarklet tools part of Steve's package of mobile meta-tool
Comments? Find me on BlueSky, Mastodon, LinkedIn, Threads, Twitter