Confused about a 404 error on test results

Hi. I’ve developed a WordPress site which is using the WooCommerce plugin as the shopfront. I’m keen to keep the site as fast as possible, hence the use of this site.

However, when I read the test results for my site, one of the longest load times results in a 404 error. I’ve tried numerous tools to try and find the cause of the 404 error including using Google Webmaster and Saving the Response Bodies on WebPageTest, but can’t seem to track it down anywhere. My site is thekitchenshelf.co.uk and the 404 goes to the URL thekitchenshelf.co.uk/not_found but I can’t see where the link or failed page is originating from. Could this be an error in the test results? Is someone here able to help… I am new to website speed analysis and optimisation so this has me really confused. Many thanks.

Site: thekitchenshelf.co.uk
Test result: Kitchenshelf.co.uk/test-result

OK. That was painful and looks like you may have exposed a bug that WebPagetest isn’t catching :slight_smile:

protip: If you use Chrome as a test browser then you will get information on what triggered each request to load. Capturing response bodies and a timeline also help.

http://www.webpagetest.org/result/140206_W2_K2M/1/details/#request76 - shows Initiated By: http://thekitchenshelf.co.uk/ line 545

Looking at the page source: http://www.webpagetest.org/response_body.php?test=140206_W2_K2M&run=1&cached=0&request=1 it looks like that’s a “add to wishlist button” with a few classes attached as well as the start of an inline script tag.

Unfortunately that was a bit of a dead-end but it does tell us around what element the request is being triggered.

My guess is that there is some js code that lazy-loads or does something with images that isn’t dealing with error handling.

You can fetch all of the bodies as a zip file if you tweak the screenshot path and change it to bodies.zip: http://www.webpagetest.org/results/14/02/06/W2/K2M/1_bodies.zip

Next step is to just grep through all of the bodies looking for not_found. It wasn’t in any of the captured response bodies. Time to step up the game and capture a full tcpdump.

Eureka! Searching the raw packets it looks like the request for:

http://thekitchenshelf.co.uk/wp-admin/images/wpspin_light.gif

returned a redirect to not_found:

HTTP/1.1 302 Found
Location: http://thekitchenshelf.co.uk/not_found

Now off to figure out why WebPagetest didn’t capture the redirect request/response…

Wow… thanks for the insight and all the help. I would never have been able to figure all that out - and sorry for potentially exposing a bug with site. I can’t tell you how much your help is appreciated.