Comments for High Performance Web Sites http://www.stevesouders.com/blog Essential knowledge for making your web pages faster. Thu, 27 Nov 2014 21:49:55 +0000 hourly 1 http://wordpress.org/?v=3.7.5 Comment on SERIOUS CONFUSION with Resource Timing by Aaron Peters http://www.stevesouders.com/blog/2014/11/25/serious-confusion-with-resource-timing/#comment-61073 Thu, 27 Nov 2014 21:49:55 +0000 http://www.stevesouders.com/blog/?p=4215#comment-61073 +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 http://www.slideshare.net/turbobytes/state-of-the-resource-timing-api

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 http://www.stevesouders.com/blog/2014/11/25/serious-confusion-with-resource-timing/#comment-61072 Wed, 26 Nov 2014 18:54:22 +0000 http://www.stevesouders.com/blog/?p=4215#comment-61072 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 http://www.stevesouders.com/blog/2014/11/25/serious-confusion-with-resource-timing/#comment-61071 Wed, 26 Nov 2014 18:47:03 +0000 http://www.stevesouders.com/blog/?p=4215#comment-61071 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 http://www.stevesouders.com/blog/2014/11/14/request-timeout/#comment-61065 Fri, 14 Nov 2014 18:05:42 +0000 http://www.stevesouders.com/blog/?p=4205#comment-61065 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 http://www.stevesouders.com/blog/2014/11/14/request-timeout/#comment-61064 Fri, 14 Nov 2014 17:28:12 +0000 http://www.stevesouders.com/blog/?p=4205#comment-61064 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 blackhole.webpagetest.org
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 http://www.stevesouders.com/blog/2014/08/21/resource-timing-practical-tips/#comment-61063 Wed, 29 Oct 2014 12:31:39 +0000 http://www.stevesouders.com/blog/?p=4099#comment-61063 Inspired by this article I’ve setup a bookmarklet to read visuallize the Resource and Navigation API as well as User Timing: https://github.com/nurun/performance-bookmarklet

]]>
Comment on Onload in Onload by Saikat http://www.stevesouders.com/blog/2014/09/12/onload-in-onload/#comment-61059 Tue, 21 Oct 2014 11:41:32 +0000 http://www.stevesouders.com/blog/?p=4157#comment-61059 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

window.onload=function()
{
alert(“onload1″);
window.onload=function(){
alert(“onload2″);
}

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

]]>
Comment on do u webview? by Daniel http://www.stevesouders.com/blog/2014/10/09/do-u-webview/#comment-61058 Fri, 17 Oct 2014 07:36:57 +0000 http://www.stevesouders.com/blog/?p=4179#comment-61058 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 http://www.stevesouders.com/blog/2014/09/12/onload-in-onload/#comment-61057 Mon, 13 Oct 2014 06:34:57 +0000 http://www.stevesouders.com/blog/?p=4157#comment-61057 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 http://www.stevesouders.com/blog/2014/08/21/resource-timing-practical-tips/#comment-61054 Fri, 03 Oct 2014 10:13:20 +0000 http://www.stevesouders.com/blog/?p=4099#comment-61054 Firefox supports the Resource Timing API since version 31 behind the `dom.enable_resource_timing` preference flag which is `false` by default.

]]>