Hi,
I’m getting 404 errors on images for fancybox images. I can’t find references to these in the source code and from what could find out online it could be something to do with either the tool, specific browsers or a 3rd party resource.
I couldn’t find any definitive solution and was wondering if anyone could shed some light on it?
http://www.webpagetest.org/result/130925_YE_d12894dc8f29cabdc8a57d2d64e7ab44/1/details/
Thanks
Rosh
It appears you’ve fixed these errors by now; forgot to upload them, perhaps?
Hi Rob,
A temporary fix my developer added a new directory and moved the images to that directory so they can actually be found.
He said that there aren’t any references to that location in the code although we are using Fancybox it references the files located in the theme directory under /css.
Although the issue appears fixed for the home page, it still occurs for ever other page.
http://www.webpagetest.org/result/130928_GZ_be597861c53e253fa0e6444a0589487b/1/details/
Not really sure what else to do to fix it.
There are, though: in your (minified) stylesheet. The images are referenced by CSS rules targeted at Internet Explorer 8 and older.
.fancybox-ie #fancybox-bg-se{filter:progid:DXImageTransform.Microsoft.AlphaImageLoader(src='fancybox/fancy_shadow_se.png', sizingMethod='scale')}etc. Since the path is relative (not /fancybox/ but fancybox/), it’ll look for the directory (and the images) within the current path. In your test case that would be /networks/three/fancybox. That also explains why the problem doesn’t exist on the homepage.
Replace all 16 occurrences of src=‘fancybox/ with src=’/fancybox/ and you’re good to go.
It seems to me that your TTFB is a bigger problem. I just waited 5.44 seconds for your homepage to begin downloading.
Hi, sorry for the delay, I thought I had the thread notifications set up.
Anyway, I’ve just implemented the changes to the image paths and the issue does indeed look to be fixed. Thank you so much! 
It baffles me why my developer didn’t pick up on this though.
I actually thought the TTFB had been fixed as we found the CDN was actually slowing down the site and in subsequent tests without it the TTFB passed with A. Now I get varying results each time I test and depending on which page too.
The two most recent tests for the homepage show different results too:
http://www.webpagetest.org/result/131004_DD_12ac98c72a342c1b25e257808ef5af74/
http://www.webpagetest.org/result/131004_M8_6454091ffeb51577096c87ee8228b498/
Does the page tested get cached or is a fresh test each time?
It’s a fresh test every time, there’s no caching done except for the “repeat view” test if you enable it.
The difference in your last two tests is probably due to a caching mechanism on your server. After the first pageview (which I’ve seen take upwards of 3 seconds on your site), it’s cached much of the data, and can serve that from memory on the next page load. So now that you’ve optimized your front-end, you’ll probably want to have a look at your back-end to see what you can improve there. Have you installed an opcode cache like APC or Zend’s OPCache, for example?
My hosting support tried out a few configurations with the caching last month and we arrived at using FastCGI with XCache and found that to be the most stable and what appeared to be quickest.
Previously was set up for APC but apparently this isn’t compatible with suPHP so had to change it. We tried out Varnish but was having issues with that too.
With the green TTFB bar on the waterfall results displaying under the (mydomain) - / Does that suggest it’s a back-end issue and not a front-end one?
I’m using W3TC plugin and believe that I’ve optimised everything that I can in terms of that.
I wouldn’t really know what else to do now as it’s already way out of the scope of my knowledge. The only other things that I thought might be causing the large TTFB is the large amount of scripts we use.
Scripts are loaded as soon as the HTML that references them arrives at the web browser. Roughly speaking, the Time to First Byte (TTFB) metric measures the amount of time it takes from the establishment of the initial connection to the reception of the page contents by the browser. In most cases, a high TTFB indicates that it takes your server a long time to process the request and send the output to the browser for parsing. All of that takes place regardless of the contents of your page, such as your scripts, so they cannot be part of the problem you are experiencing. Since latency does not appear to be an issue, it’s all on the back-end.
Troubleshooting performance issues on the backend does require some technical knowledge. There are a few tools available, such as Xdebug and New Relic’s Application Monitoring service (free), that can help you find the culprit. Wordpress is pretty bloated, and it gets heavier with every plug-in you add. Even so, it shouldn’t take 7 seconds for a simple homepage to be generated, especially since you appear to be running on a virtual server where you probably have some guaranteed resources.
I would probably pass this on to your developer. After all, an end-product with a TTFB like this isn’t really acceptable.
OK, thanks for clarifying that it’s most like to do with the back-end. Just so I’m clear, backend includes PHP, the server and databases?
I actually have New Relic installed so that’s one step closer. I don’t suppose you’d be able to take a look for me? I feel bad asking given you’ve helped me so much already but I don’t feel confident in my developer helping in this instance.
Yes, basically everything that goes into generating a page before it’s sent to the client.
I could have a look, but I’m no expert on Wordpress so I’m not sure I will be of much help.
OK, I’ll PM you. I think if New Relic does show any specific areas that could be the cause I can then take this to the developer.