Comments for High Performance Web Sites Essential knowledge for making your web pages faster. Thu, 27 Nov 2014 21:49:55 +0000 hourly 1 Comment on SERIOUS CONFUSION with Resource Timing by Aaron Peters Thu, 27 Nov 2014 21:49:55 +0000 +1

I said it in May 2013 at WebPerfDays in Amsterdam: duration is useless, exactly because “…since there’s no way to know how much is blocking and how much is network delays”
Slide 15 in

Ilya also said something in Barcelona about something you propose coming to Resource Timing, but I think he said this would be for same origin responses and responses with TAO header only

Comment on SERIOUS CONFUSION with Resource Timing by Steve Souders Wed, 26 Nov 2014 18:54:22 +0000 Eric: I totally agree that both are valuable. I’m definitely not suggesting we remove “duration”; just that we should add “networkDuration”. I’m not so sure I would find a lot of value in “duration” by itself since there’s no way to know how much is blocking and how much is network delays. I am DEFINITELY excited to start gathering blocking time metrics. I’ll only be able to do this for same-origin resources, but that’s okay. I expect that if the median blocking time goes from 300 to 350 ms, there’s probably a big degradation in user experience (and page load and rendering times).

Comment on SERIOUS CONFUSION with Resource Timing by Eric Wed, 26 Nov 2014 18:47:03 +0000 Hm… I think both are valuable. Including the total time (including time blocked) is actually really important because it’s the thing that actually can prevent rendering in the case of CSS/JS. In the example you give it could help you make different decisions about how to concatenate your files given the TCP restrictions.

Comment on Request Timeout by Steve Souders Fri, 14 Nov 2014 18:05:42 +0000 Hi, Ilya. I agree that it’s fairly common to have intermediaries that can make it more complicated, but I think the most common case is connecting directly to the main (hung) server. We can look at Mehdi’s post about yesterday’s DFP outage as an example. They (Catchpoint) do their testing from Windows. Consequently, his outage charts show a ~20 second increase.

There are a lot of factors but it’s good to have an idea of the impact for the general case.

It’d be good to get more real user metrics on these outages. Patrick Hamann tweeted some good stats. I’m hoping he can slice it by OS to shed more light.

Comment on Request Timeout by Ilya Grigorik Fri, 14 Nov 2014 17:28:12 +0000 It’s worth highlighting that you’ll get different behaviors based on the state of the TCP connection. AFAIK, Pat’s blackhole server doesn’t even respond to the SYN packet… and on OSX there is, indeed, a 75s timeout for that. However, if handshake completes, that’s a whole different story. Quick example on OSX:

$> sudo sysctl -w net.inet.tcp.keepinit=90000
net.inet.tcp.keepinit: 75000 -> 90000
$> date && time curl -vv
real 1m30.535s (aka, 90s)

However, once the TCP handshake has completed.. say we’re stuck waiting on the HTTP server, the timeout is controlled by net.inet.tcp.keepidle:

$> sysctl net.inet.tcp.keepidle
net.inet.tcp.keepidle: 7200000

Needless to say, 7200000 is a large number (months). So, OS timeouts are not the limiting factor in this case. And, I think this case is fairly common: edge router / proxy terminates TLS and then hangs waiting for a response from a dead server.

Comment on Resource Timing practical tips by Michael Mrowetz Wed, 29 Oct 2014 12:31:39 +0000 Inspired by this article I’ve setup a bookmarklet to read visuallize the Resource and Navigation API as well as User Timing:

Comment on Onload in Onload by Saikat Tue, 21 Oct 2014 11:41:32 +0000 I don’t know how good it is but can’t we fire another onload event i.e so that the second window onload function gets fired by the fake load event. like this


var evt = document.createEvent(‘Event’);
evt.initEvent(‘load’, false, false);
//so both alerts are shown

Comment on do u webview? by Daniel Fri, 17 Oct 2014 07:36:57 +0000 A lot of this is pretty relevant to a project we’re on the edge of completing now.

We’ve discovered and overcome a lot of nuances and quirks with webviews on both iOS and Android so this is a great reference to start writing up some of the lessons we learned.

I’m especially excited about the V8 going in there for the new webviews!

Thanks for this post!

Comment on Onload in Onload by Laurens van Hees Mon, 13 Oct 2014 06:34:57 +0000 Another tip, when the Navigation Timing API is available you can do something like this as well:

var isLoadFired = window.performance.timing.loadEventStart > 0;

Comment on Resource Timing practical tips by Radko Dinev Fri, 03 Oct 2014 10:13:20 +0000 Firefox supports the Resource Timing API since version 31 behind the `dom.enable_resource_timing` preference flag which is `false` by default.