| 8:56 am on Feb 23, 2006 (gmt 0)|
It definitely makes sense that if your pages load faster then you should get people staying on your site longer and even visiting on a more regular basis if there is interesting content etc.
The obvious question is when did you change servers? In other words over what period of time are you looking at the changes to your CTR etc.
| 10:57 am on Feb 23, 2006 (gmt 0)|
Yes, I just made a significant reduction in page load time and saw my pages-per-visit number jump too. I've yet to see if that really translates into increased revenues, but I'm pretty sure that it will.
| 11:16 am on Feb 23, 2006 (gmt 0)|
We've improved site speed twice, and on both occasions pages-per-visit, clicks and earnings have all gone up (and eCPM has gone down, but that is to be expected with more ppv).
| 11:48 am on Feb 23, 2006 (gmt 0)|
I have the same experience. I moved my site from shared environment to dedicated resources and observed increase in ctr and income.
| 12:18 pm on Feb 23, 2006 (gmt 0)|
Thanks for sharing david_uk, an important point that many forget to revisit: Page optimization & Load speed.
Does your stats program report "Partial Content" numbers that you can follow & compare, I use awstats and it does.
My inner pages are between 30 to 40k each with no graphics, I wish I can serve below 10k pages but its just impossible!
Also when your uniques and impressions are in millions per month for years, you run into a level of high predictability and consistency, where even major changes give minor effects, economy of scale I guess!
| 12:56 pm on Feb 23, 2006 (gmt 0)|
I totally agree. If you snooze you lose ;)
| 1:20 pm on Feb 23, 2006 (gmt 0)|
when you say that I saw my pages per visit to increase, how much was it and how much is it now?
How many pages do you have now per visitor?
| 1:22 pm on Feb 23, 2006 (gmt 0)|
Just wondering if your ads became more targetted after you moved? Just curious if maybe Google was assuming you were a UK outfit with your old server and perhaps doled you out UK biased ads that really would not have done anything for your users?
| 1:23 pm on Feb 23, 2006 (gmt 0)|
I would like to point out a problem I was having that was hurting my Adsense earnings as well. I run TribalFusion banner ads on the same pages as my Adsense ads. Well for months now I would consistently notice that my pages would take sometimes 10-15 seconds to load (normal load time is 1 second). I realized the problem was not my server or my content, but the TribalFusion banner ads! They were taking forever to load since they had to connect to whatever remote server it required and it was holding up the rest of the page! I ended up embedding the Tribal code in IFRAMES... now my pages always load fast and the Tribal ads load in their own frame taking as long as they like. Faster loads means better visitor retention, which means higher Adsense earnings.
| 1:23 pm on Feb 23, 2006 (gmt 0)|
I've experienced the same thing -- not to mention the money you save with your hosting provider with the bandwidth reduction.
| 2:03 pm on Feb 23, 2006 (gmt 0)|
<<<Just wondering if your ads became more targetted after you moved? >>>
Very interesting question. Can you answer, david?
| 2:11 pm on Feb 23, 2006 (gmt 0)|
Targetting of AS ads should probably only be influenced by the location of the user, not the server.
| 4:11 pm on Feb 23, 2006 (gmt 0)|
At the Meet the Google Engineers event in New Orleans last year, one of the engineers said several times that his general advice was to "invest in faster servers and more bandwidth".
We took his advice seriously and dropped some cash on doubling our bandwidth and buying a few new servers. In hindsight we can see that the money we spent was insignificant compared to the growth we've had in business since then. I can't say for certain that the two things are linked, but an argument could certainly be made to support this.
| 4:16 pm on Feb 23, 2006 (gmt 0)|
very interesting thread - food for thought. I picked up an interesting tip on another thread re Photoshop and its "optimize for the web" image function. That too reduces load time.
| 4:41 pm on Feb 23, 2006 (gmt 0)|
Could another reason for increased hits from the USA be that search engines seem to weight sites based on geographical location? I noticed that when a UK hosted site was moved over to servers in the US, its ranking went down on Google UK. I don't know how long this takes, but would assume that it wasn't instant though.
| 4:50 pm on Feb 23, 2006 (gmt 0)|
I wondered how many of who have posted are using GZIP compression on their webhost? If not your missing a 3 to 4X performance boost.
All browsers now request GZIP compressed content, but for some reason 3 out 4 webhosts do not support GZIP compression by default. GZIP compression can reduce bandwidth for text by a factor of 3 or 4! The new Googlebot is requesting GZIP compressed content (finally). Google serves GZIP compressed results to all web browsers.
Talk about a page load performance boost, GZIP is it. Brett has tried it at WebmasterWorld but it overloads his servers, but there are many sites out there that could easily support GZIP.
Webhosts almost never support it by default because it cuts bandwidth usage by 3 to 4, costing them income.
56K modem users will actually stop by a website and visit for a while if it supports GZIP compression. That's a 40% traffic boost right there.
My host only supports GZIP through the back door, you ask tech support they say no GZIP, but then they also say; do you know about PHP? Hint, hint, hint.
It's possible your new host does provide GZIP and your old host didn't, therefore you get quite a boost in performance just by switching hosts.
I do believe host location may be affecting ranking in the Google SERPs based upon the users location and your server, thereby indirectly affecting many aspects of your websites performance, including Adsense ad content.
So moving a website to a new host has so many variables, who knows what the true impact is? But right now you probably can't beat having your server in the USA, unless you have good locally targetted content.
| 5:06 pm on Feb 23, 2006 (gmt 0)|
If your page design includes a reference to three different .jpg files, then the client will typically have to retransmit a query to see whether they've changed for every page they visit on your site. If you study your logs, you'll see that as a visitor traverses your pages, his client browser is repeatedly asking "Did logo.gif change since 2 seconds ago when I downloaded it?" and your server is replying "Ummm, no!".
Not only does an intelligent caching design speed up all but the first page fetch for an individual, your stuff may get cached by a caching server at a big ISP (e.g., AOL), and may therefore speedup the very first visit for many visitors. Saving the client from retransmitting those If-Modified-Since requests can save some time but not much bandwidth. Getting a 40KB graphics file cached by a bunch of major ISPs can save significant bandwidth.
One structured way to handle caching is to arrange to give each cacheable file a "throwaway" name. For example, instead of referring to "logo.gif", refer to "logo0001.gif" and arrange for the headers transmitted with that file to instruct the client that it's OK to cache that file forever (to be standard compliant, "forever" should not be more than 1 year in the future).
Then, if you someday do need to make a change to your logo, you can simply name the new version "logo0002.gif" and change all your HTML references to point to that file (hopefully you're using a CMS that makes that a single change that automatically propagates to all the affected pages).
Besides making your website pages load a little faster for the client, using HTTP 1.1 caching intelligently can help lower the bandwidth demands on your server (or, looked at from the other end, make your server handle bigger loads). It can also decrease clutter in your logs, since most webmasters do nothing useful at all with the information that every time the home page was fetched, the home page .gif was fetched as well.
| 5:19 pm on Feb 23, 2006 (gmt 0)|
I have most "static" graphics and scripts, eg page furniture, cacheable for at least a week.
I can almost unambiguously tell when a really new user arrives because it is almost the ONLY time they have to fetch that stuff (and I also strip down the page for the first visit so there is less to fetch).
(Dynamic content (pages and images) is usually cacheable for between 5 minutes and an hour. I consider choosing appropriate cache times for each class of items to be a very important engineering issue, almost as important as the machines on which the servers run.)
| 5:58 pm on Feb 23, 2006 (gmt 0)|
HTTP Compression baby. It made my wallet a lot fat.
| 6:02 pm on Feb 23, 2006 (gmt 0)|
Similar experience through a friend of mine: he hosted a UK-related site on a UK server, but it turned out that most users were from the US. So he transferred WITHIN the same hosting company (one of the top-players) from a UK to a US account and got not only much cheaper fares, but also faster loading.
I am located in the UK myself, but my sites are hosted in the US. I won't trust British firms - service and other factors clearly point beyond the Atlantic.
With respect to loading times: every second is valuable, as far as I have figured out.
| 7:18 pm on Feb 23, 2006 (gmt 0)|
great topic, I have had the same experiences in ad revenue inproving with faster load times.
| 7:45 pm on Feb 23, 2006 (gmt 0)|
Had the same result when I stopped rogue spiders from getting to my site. Turned out when bad bots overloaded the server at the same time Google/Yahoo/MSN/visitors were tying to use it revenues went down. More importantly, when SEs get a timeout they seem to lower your pages that timeout and it can be a cascade effect on revenues.
Increased accessibility to valid SEs and visitors definitely makes a HUGE difference on my bottom line.
| 8:26 pm on Feb 23, 2006 (gmt 0)|
As the originator of the thread, I really appreciate the interesting responses!
My reason for moving webhost was driven mainly by lack of support from them when trying to implement php. Taking the opportunity to move to the US seems to be a good move!
|The obvious question is when did you change servers? In other words over what period of time are you looking at the changes to your CTR etc. |
Just over a week - hence my caution on pinning the current good fortune on this. But having said that, the average earnings and clicks have nearly doubled since exactly the hour the domain moved. Epc and ctr are pretty much the same. OK - I think it must have loaded like treacle before :( :(
|Does your stats program report "Partial Content" numbers that you can follow & compare, I use awstats and it does. |
I have to say that I've not looked at this. I use the raw log files in my analysis software, and I'm sure it has this option. I am judging mainly on the fact that the page load time is now a lot faster than it used to be. I chose the previous web host on the grounds that it was local - in the same town as me.
|Just wondering if your ads became more targetted after you moved? Just curious if maybe Google was assuming you were a UK outfit with your old server and perhaps doled you out UK biased ads that really would not have done anything for your users? |
I don't have any targetting issues to be honest. Ads have been relevant and well targetted pretty well all the time before, and after the move.
|Could another reason for increased hits from the USA be that search engines seem to weight sites based on geographical location? I noticed that when a UK hosted site was moved over to servers in the US, its ranking went down on Google UK. I don't know how long this takes, but would assume that it wasn't instant though. |
Now if it goes UP in the US rankings I'll be a happy bunny :) In the UK it's at number 1 on a google.co.uk search, and on google.com it's at number 4. I had a brief period in December where it was at number 1 in the US and the earnings were rather nice to have. If I lose some UK placement but gain some US placement I'll be fine with that :)
| 8:27 pm on Feb 23, 2006 (gmt 0)|
I'm not very savvy ot this kind of stuff, but I was wondering if anyone has tried Squid (opensource) Web Proxy Software as a means of improving load time and how it worked out?
| 9:35 pm on Feb 23, 2006 (gmt 0)|
|when SEs get a timeout they seem to lower your pages that timeout and it can be a cascade effect on revenues |
My site once went offline for weeks and my serps position was not affected at all during or after, I was even earning from clicks on ads on cached pages, after coming back online, full earnings resumed from where it stopped.
Only putting things in perspective, still I wouldn't want a bot to timeout on my pages.
| 10:10 pm on Feb 23, 2006 (gmt 0)|
This thread is an amazing one... just thinking about the question I asked in San Jose last year if site speed will help a site's ranking...
no clear answer tough, but I think it's time to really optimize for load speeds also
| 10:46 pm on Feb 23, 2006 (gmt 0)|
|My site once went offline for weeks and my serps position was not affected at all during or after |
How long ago was this?
I've had a couple of incidents with Google lately and the pages that were impacted seemed to show a 1:1 correlation with dropping somewhat until they were crawled again. Note that they didn't vanish, it was more like dropping from #3 to #40 or something like that and it bounced right back next crawl.
One time is a coincidence, maybe, but 2-3 times I'm not sure about.
Sure would be a big bunch of coincidences ;)
| 11:34 pm on Feb 23, 2006 (gmt 0)|
Just a thought - Google crawls all our sites - if Google finds it slow to crawl - perhaps Google won't send much traffic our way? After all - slow sites do reduce the quality of their index, and are likely to be poorly hosted and go down frequently anyway?
| 6:37 am on Feb 24, 2006 (gmt 0)|
We're looking to make a serious upgrade to our servers in the coming weeks, so I'm anxious to see how it affects:
1)pageviews per visitor
2)eCPM and overall revenue
We're looking into Rackspace as our hosting provider...does that sound like a sound choice?
| This 46 message thread spans 2 pages: 46 (  2 ) > > |