Google Site Performance and PHP Redirects
Posted under: The last week or so I’ve been looking at Google’s Webmaster Tools to try and tidy up errors, old pages, meta issues etc, but one thing that really caught my eye was the data on site performance. On one hand one of our subdomains does really well, but on the other our average for the www version of Loquax was incredibly poor. So poor in fact that if site performance became a factor in rankings we’d be somewhere at the bottom.
The cause of this isn’t the fact that our servers are covered in treacle and managed by a bunch of snails who are incredibly relaxed thanks to the benefits of illegal grass type products, but because of our redirect page. We use a redirect link (goto.htm), with php header code, to mask our urls and redirect them. We never used to do this, but after having large swathes of the site “borrowed” on a regular basis it became a necessity.
Clicking on one of our redirects usually results in the outbound link loading in – so why Google was assigning an average over 7 seconds to our redirect goto.htm was a bit of a mystery. Could it be including the time to load the redirect as an indicator of our server response? Or can Google’s site performance data not take into account/identify a php redirect? For the first time I tried the support forum and made a couple of changes including identifying the redirect.
One additional change made since then has involved what happens when the goto.htm id is no longer used. We don’t want our users clicking through to dead sites, so when an id is not in use we redirect to a “sorry not available” holding page. Within that page was some database code that really wasn’t needed. My theory is that if Google is hitting a lot of our old redirects it’s just landing on the “sorry” page multiple times – resulting in multiple database calls and lots of confusion.
So, to counter this, we’ve put a robots.txt exclusion on the “sorry” page (it was already noindex) and, so far, it seems our average speed for goto.htm is now dropping. Hopefully the average will continue to drop and the changes made won’t effect anything else.
According to Blogstorm, site speed is not yet a factor in The UK yet. But, if you do use redirects it might be worth looking at your Site Performance just in case your speed average is being skewed.
And, if you have any ideas/suggestions as to the cause of why Google sees php header redirects as slow then please post below!
they see php redirects as slow because they are slow. Think about the layers the browserrequest has to go through before it recieves a response. mY own php redirects take approx 2 secs from request thro 2 db checks nnd an insert, before th browser does anything. Htaccess however, does it instantly
altho u lose th logging
We have one database call and then the header redirect – and that doesn’t take 7 seconds – don’t think it even takes 1 or 2 in most cases.
We couldn’t use htaccess (we’re masking links out of the site and have quite a few of them)
ive had a look at loquax, now i understand exactly what youre talking about. The goto.htm page 301 redirects to (say) affwin, so until it resolves there, the request doesn’t have a completed response. But (say) affwin 302 redirects again, so you still don’t have a complete response and the clock is still ticking.
The logging at the network script always takes an age, which would definitely account for some seconds in the logged time. It would be interesting to know which networks eat up the most. I suspect aff future to be in the top 3 of slow redirectors
Also, due to the redirects, the loading time of the merchant landing page would count as part of the response to the request on goto.htm, based on what i understand of matt cutts explanation of google’s redirection policies.
I think you’ve done all you can by adding it to robots.txt tbh.
We’ve got this same issue too – the times are abnormally large and I can only attribute it to the loading of the merchant site, not ours.
I don’t think adding it to robots.txt will make any difference though (ours has always been in there) as the page speed data is based on user data gathered via the Google toolbar, not from Google’s own crawl.
Maybe switching to a meta refresh as opposed to a 301 would fix the issue? Are there any issues with using a meta refresh? Other than that I suppose we’ve go to hope Google realise it’s an issue with their beta version of the speed test and sort it out!
After an initial drop, it’s back up to being slow again… back to the drawing board. I’m wondering if switching the .htm to .php would help?
Tom, not sure if meta redirect would be better than php header() – another thing to try I guess?