WebPagetest Forums

Full Version: How to solve "0 ms (Request Canceled)" problem?
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3

Who can tell me what does it mean? Test results are here.

It happens only when testing on IE8 and it drives me crazy. I want my results to be under 0.5s -- what can I tell from graph is that I can gain another 0.02s from this 0 ms (Request Canceled), if it is possible to fix it somehow.

Also, optimization is still not over. Will reduce HTTP requests by about 8 hits (at least I hope so), and will add some additional subdomains for static images. Hard way for under 0.5s goal :)

On a side note -- webpagetest is a very nice and handy site for web optimization. FTW!

Thanks in advance
Here is an another test 0.498 \o/ but still that annoying 0 ms (Request Canceled) problem exists.

I tried to use wireshark and IE8 on my development machine, and I do not see any such requests or whatever it is.

Help :huh:
I'm taking a look to see if I can figure out what may be causing it. I can't reproduce it on my dev machine either but there may be something timing related that is triggering it.

A "request canceled" happens when the browser starts a request but closes it before it completes (in this case it looks like it is closing it really quickly and then re-issuing the same request). It may not even make it far enough to hit the wire.

Shame I haven't implemented the code to do packet captures as an option from test runs (started the code but got distracted by other efforts - will happen at some point though). I'll look some more and see if I can track it down for you. The systems are getting a little crushed today with the Google announcement (performance being part of pagerank now) so I may not be able to make much progress until things calm down or I can get another system to do some remote debugging on.


Thanks for looking into this.
While 0ms issue remains, here we go 0.461s \o/
Sorry, as suspected, the traffic shaping wasn't working so that was for the native FIOS speed. Here is the result on the DSL speed: http://www.webpagetest.org/result/100416_7E3F/

Still VERY good, particularly given that it includes graphics and visual elements.
Did some optimization -- namely, CSS sprites. Results (via Dulles, VA USA): What I have noticed is that while using the same location and ADSL, IE8 is a little bit slower than IE7. Is it the same physical machine, or 2 different? Based on +/- 10 different test runs

Now on topic (0ms issue) -- I'm not alone. Google has the same issue. Most likely some kind of bug exists in your test environment.

Additional issue / question about Repeat View: are you sure you correctly give status FAILED for Cache Static on html files with 304 response? Results here: Google and me. If you are correct, what is your suggestion on how to fix this? Note that both results on first view return Cache-Control: max-age=0, private in response headers.

Huh, wall of text Smile Thanks in advance for your answers.
IE7 and iE8 are on different physical boxes though with identical specs (IE7 actually spans multiple boxes).

I haven't had a chance to look yet but the Request Canceled issue might be an IE8 behavior and an artifact of me logging requests that were set up but not actually initiated. It's odd that I only see it under some circumstances though so I would like to understand it better.

Looks like it's probably worth revisiting the caching to allow 304's for max-age=0/private responses but only for the base page. The css in Google's case should have been cached. I'm working on a release right now, I'll see if I can get the tweak added to the logic and rolled out in the next few days.


Quote:IE7 and iE8 are on different physical boxes though with identical specs (IE7 actually spans multiple boxes).

Huh. I somehow doubt that IE7 is faster than IE8. But maybe in specific cases it is so. Who knows... Or, most likely, boxes are different, wires, switches, load balancing?, drivers, etc.

Quote:I haven't had a chance to look yet but the Request Canceled issue...

Soon™ Smile

Quote:Looks like it's probably worth revisiting the caching to allow 304's for max-age=0/private responses but only for the base page...

Agree. Only base page.
Did some more optimization -- namely, javascript defer / postload. Results (via Dulles, VA USA): Again, IE8 is slower that IE7. hmmm...

0ms issue still exists, but there is only 1 such bad request instead of 2. Most likely because of defered javascript.

Nice to see that Repeat View issue has been fixed. Good work! Green grid is good grid Smile

Also, what is the theoretical best possible page load speed (on ADSL), if document size is 118KB, and there are 8 requests in total (DNS + CSS + etc.)? Under 1s almost impossible? For First View it is possible to inject CSS into base file, and then postload all CSS?
The fastest that 118KB can get delivered (theoretically) is:

50ms DNS lookup (assuming it had a long TTL and was cached at the edge)
+50ms socket connect (Assuming the server was co-located at the FIOS head-end)
+50ms for the request (assuming minimal/no cookies)
+700ms to download the 118k at 1.5Mbps (including TCP overhead)

= 850ms

There are some really big caveats that will prevent that from ever happening, but that's pretty much the floor. The most notable caveat was that I assumed your server was at the other end of the DSL connection and that you were using some form of "TCP acceleration" to bypass slow start.

Realistically, you're delivering that much content as fast as I'd expect it to be possible.

On the CSS note, yes - what you can do on the server side is inject the css if a specific cookie is not set and call it externally if the cookie is set. Then using javascript on the page, some time after the document has loaded create a 1x1 (or hidden) iFrame that references a dummy page whose purpose is to cache any external files you would like to reference. Have the dummy page set a cookie so that your server code can tell if the external files have been cached or not.

You can also use this technique to pre-cache other css or javascript files that will be needed on your other pages so they will get pre-loaded when someone hits your landing page.
Pages: 1 2 3
Reference URL's