Welcome to WebmasterWorld Guest from 18.104.22.168
How do you think it affects us? I think blindly taking into factor speed might not be appropriate since that would mean giving preference to a small two page site over a comprehesive Wikipedia article. Don't you think?
That said, you still want to avoid delay in delivery of content to the user.
In Webmaster Tools, G is now showing some of their ideas about site speed. I'd like to hear others' ideas about 1.choices that affect page/site speed significantly and 2.possible ranking choices by G.
There are many questions/ideas/choices that the WMT info raises for me...
1. Site speed vs. page speed vs. reload page speed vs. 2nd page of site speed.
2. Comparison with sites I compete with, not comparing with G's 1.5 sec idea about what is a "fast page".
For example, if I have a "widget game" then it is best (for speed ranking) to have a page primarily of text describing the game to try to rank in G. The widget game itself with its sizeable downloads needs to be placed on another page. This is not what I think the average surfer wants. Optimally, G will be able to algorithmically downgrade the speed factor for searches that surfers want/expect/need heavy downloads.
[edited by: tedster at 2:32 pm (utc) on Dec. 3, 2009]
maybe i'm a cynic, but i reckon this has got just as much to do with the fact that it will save google a pile of money.
A part of me agrees with you (the other part always loves Google so much that it cannot think of them being evil).
Could that mean this talk about speed of the site is all in the air and Google just wants people to focus on improving the speed of the site? I mean, while people go about improving the speed of the site, the SERPS might not actually be influenced much by them. I wish that would happen.
There are certain technologies and online applications where a second or two's delay will actually result in more accurate content being delivered, so penalising these sites is assumptive and not necessarily an improvement for the user. Most sites where a delay is necessary would also display "loading" messages too.
It seems logical therefore that as speed does not necessarily reflect quality of content, if there is an effect, it will be minimal.
it might save them a packet in storage costs as well, especially when the web is growing at the rate it is.
Google wins, you win and your users win. I can't find anyone that loses unless you take the decision to remove or degrade real content.
Since this is going to be a ranking factor and ranking is a competitive issue it is up to you to decide if you want to compete on this one factor. If you don't that's fine. If you want to not take simple steps to make your site faster then you can still compete by doing more on the other 199 factors.
I wonder how many of us before seeing Matt's comments knew how to implement gzip on our servers or how easy it is to add a Cache-Control line to our htaccess file. I'm sure some will have but I for one had not even considered these things but they make a massive sitewide difference for very little effort. I didn't realise that http includes a check that the browser can deal with gzip when the request for a page is received and then sends the page components zipped up only if the browser can unzip them.
Basically there is a shed load of easy to implement technology already available to us that the vast majority of us are not using and Google has data that shows this. Google also knows that most of us have made a few stupid errors in our coding or image compression at some time in the lives of our sites that sit their costing bandwidth every day and we are blissfully unaware. On my main $ site I've made one pass with the Firebug speed tool and found enough little inefficiencies and unimplemented speed technologies to make a massive difference to my users and to hopefully help cement that top slot on Google. This is one Google algo change that I applaud loudly. Whoever suggested this deserves a medal. Well done Google!
Problem is webmasters all live in big cities and have 100Mb/second connections. You ask what difference half a second makes?
For me on my 0.5Mb connection it adds 100 seconds to loading time. During a recent limited study I found an on-line news site took 76 seconds to load. Do you really expect me to hang around waiting for that? If I'm interested I'll find a different news site.
I'm fairly sure my connection is average when compared with the rest of the world. For new sites I log on to my 28k dialup, clear my cache, then make sure they load sensibly.
I can understand that other Google searches might get annoyed and click their back button just as often as I do. It's about time they stopped showing me sites I can't get to unless I have a tea break while they are loading.
It's about time they stopped showing me sites I can't get to unless I have a tea break while they are loading.
That's not the point. If a site/page is the best for a particular search then it will get listed no matter what it's speed unless there's one that is almost as good in every way but is also faster then speed may just give it enough of an edge to bump it up one place.
This is not about absolute speed it is about "speed as a ranking factor". ie your speed compared with the speed of your competitors as one of 200 factors.
If personal search develops in a way that suits me I suspect they will start offering me newspaper sites with similar content a little more often than the ones I can't reach. There's still a long way to go.
Shouldn't be a problem for anyone. There's no reason why a couple of kb of words should take anyone more than a second or two to download.
Here's some more info:
Mod_Deflate on Apache [httpd.apache.org]
On a shared server you enable it using your .htaccess file. If you don't have mod_gzip or mod_deflate enabled on your server but have .php you may be able to do gzip using this in your .htaccess
php_value output_handler ob_gzhandler
If you want to know what modules are enabled on your server try makeing an info.php file with this in it
Put the file in your web space and navigate to it with your browser. Once you have finished delete the file.
The .htaccess solutions will work as long as the necessary module(s) are loaded on your server in the httpd.conf by your host if you do not have access... An .htaccess would go in the root directory of your website, not the root directory of your server.
IMO: The best thing for you to do since this is out of your area of expertise is probably to contact your host and ask them what the best practices are for your server configuration and then do exactly what they say, because even the .htaccess file, which you can either create or will have access to is a hidden file on your server, mainly because it's important to not only the basic operation of your site, but the overall efficiency. If you are even a character or two off in the file (even whitespace) you can generate a site-wide 500 Internal Server error, or even worse, could have an error which is unnoticed and has a negative impact on visitors or search engine rankings.
The preceding stated, my advice is to make the necessary changes, but:
1.) Make sure you know the proper configuration for your specific host and server.
2.) Make sure you triple-check the end result on multiple days in multiple browsers on multiple pages in multiple directories to ensure there are no situations where things do not work as expected. (Make sure you empty your browser cache in between checks to ensure you are getting a 'fresh' version of the page, too.)
The .htaccess or httpd.conf MUST be edited in a plain text editor, such as NotePad on a PC or TextWrangler on a Mac. If even just the line breaks are not correct (UNIX) you will generate a 500 Internal Server Error... Compression is good. Knowing what you are doing to make it happen in the files you work with is critical.
HTTP_ACCEPT_ENCODING: gzip, deflate
So can I assume from that line that my hosting account's server handles gzip OK?
If so, what would a person put in their htaccess file to trigger its use?
Here's a bit more info:
Actually, that is the header sent to your server by your browser, so your browser will accept those encodings. To know what is available on your server you will have to check the installed modules...
Your host should be able to tell you if you cannot find out easily.
Those are Perl modules, you are looking for Apache modules. If you use an info.php file with this in it it
There is a section on loaded Apache modules.
The version of perldiver that I use does not show you this.
If you are going to play around with this you will need something to check that it is working as expected. I've been using a Firefox extension "Live HTTP headers" which prints out the http messages between browser and server so you can check if gzip is being used, if your images are cached etc.
BUT, what about speed for users? How much was that affected? And also, given the purported higher costs of the leading CDN's, have any here had any experience with any of the smaller CDN's?
Its a high traffic page, but sends users through in half a second at most, yet Googles new Site Performance feature has been logging it as taking 8.1 seconds on average.
Is this going to be taken into account and push our site down the SERPs, surely Google shouldn't even be looking at that page!
i don't see how they can guage the true speed of a page anyway. if you block your images, for example, and they don't spider those, then that's probably a huge chunk of time they won't ever see.