Well you did ask at the BOF session if anyone had any suggestions 
Here are some (in no particular order) that occurred to me as a result of the talks at Velocity:
-
Repaints & Reflows: Is it possible to analyse JS/CSS for patterns that will cause a repaint or a reflow? Rather than instrumenting to capture the repaints and reflows would pattern matching, similar to the jquery select by ID test, provide a decent enough indicator of the number of repaints/reflows that might occur.
-
Include time to first byte weighting in the single number overall score thing. I appreciate that you were getting pushed to provide a single number as a performance indicator at the BOF somewhat grudgingly. But if such a number is going to be provided it would be good to take the website backend performance into account to give an indicator of overall performance. Yslow/Pagespeed etc only focus on the frontend with respects to their score so a 7 second page that has a 5 second backend response time can get a really high score if it just optimises the frontend bit leaving you with say a 6 second overall load time for the page…which is hardly optimal. If there is a large backend response time then suggest early flushing.
-
Detect early flushing. Progressive rendering was a big thing this year and it builds on the previous best practice of just flushing the head of the html document. So there are really 2 parts. First off detecting if the html document head is flushed early as this can help jumpstart the TCP slowstart issue as well as providing early download of external resources, and if you include the banner of the page early visual feedback as well. Secondly if the whole html body is wrapped in a root div and of certain size/complexity suggest breaking the page into sections and flushing each section, giving you progressive rendering of the page providing early visual feedback for end user, since the root div will block rendering of the body until complete.
-
Nested DNS CNAME hack. Check DNS requests and if 2 or more records point to the same IP suggest the nested DNS CNAME hack which would collapse the multiple DNS requests into one.
-
Check for a complete SSL certificate chain. if a complete chain is not provided then the browser has to go off and fetch the intermediaries causing delays.
-
Check for SSL OSCP stapling. This relates to the length of time that a certificate can be trusted (mostly 7 days). Usually the browser has to go and fetch this from the CA however it is possible for the server to prefetch this and provide this information to the browser with the certifcate preventing a delay. you need the OSCP for each cert in the chain.
-
Check SSL certificate chain size. It should be small enough to fit in the initial TCP congestion window. If it is bigger then an extra RTT will be required before the SSL handshake can complete. This is bad for sites with high latency.
-
On the note of latency is it worth calculating the latency and following that the max effective bandwidth between the various domains of a webpage and webpagetest.org. This will give an idea of poorly located domains, give strength to arguments for CDNs, etc.
-
Support for grabbing a timing event created by JS on the webpage to show Time To Interactivity. It was another recurring theme that people are looking at the Time To Interactivity (other names were also used) as a marker for when the page was usable by the end user. Building on the principles of Steve Souder’s episodes it would be good to have various performance metric libraries create an industry standard metric event on the webpage that would capture the website defined Time To Interactivity (pie in the sky anyone :-)), Time to Interactivity (or whatever you want to call it) seems like a good candidate for the first metric that everyone can agree on. Support could be added on webpagetest.org for a defined JS event that people could then include in their metric package if they wanted to see the information displayed on webpagetest.org when doing their testing.
thoughts?
Cal
