I’ve tested from various locations an URL that returns a 301 to a new URL. The server response is fast enough, however WPT keeps indicating me a very very long download time.
See the first request on this result : http://www.webpagetest.org/result/131021_0K_CKT/2/details/
I’ve taken the longest download time I’ve noticed so far (1500 ms), but other location also show more than 500 ms download time.
How can the download of a redirect be so long ?
Can it be an error of the tool itself ?
I mean : the browser correctly redirects immediately to the ending URL and is downloading the assets of the final page, why would it keep downloading something from the first query ?
The browser will not terminate TCP connections when it gets a redirect so even though it moves on for navigation it will still process the full response. If you look at a tcpdump you can see that the server is still generating at least part of an HTML body (probably as a side effect of the 301 being generated in the application layer): CS Personal on cloudshark.org
btw, it looks like the server is using chunked encoding and the html body and close comes back at the same time as the 301 header but there is an additional chunk that comes 1.5 seconds later that is dragging out the overall response.
Ok, seen that, I was just not getting why Chrome was already downloading the next page whereas it was waiting for the first request to end.
It seems to be an optimization made in Chrome itself, as IE8 is really waiting for the first request to end before executing the 301 !
So yeah, it’s definitely not a tool problem, just a chrome optimization that I havent heard of before + a real server side problem