Forum Moderators: Robert Charlton & goodroi
[webpronews.com...]
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?
Sort of like asking whether your food should taste good or be nutritious, isn't it?
Perhaps, but I don't quite agree with the analogy. Do you want fast food or to wait for something to be prepared and cooked?
My analogy is flawed also, but the internet is not made up of good, fast cooks. To my mind, technical proficiency is not a good measure of the quality of a website's content, although, of course, I've been exploiting that advantage wherever I can ;)
Indeed, it doesn't matter that much. Most people are happy with a second or two wait: in my experience that is commonplace anyway. So google gets upset if it takes a few hundred milliseconds: that's THEIR problem not ours. The REAL visitors are quite content.
That's not what the numbers Google shared say:
At Google, we've gathered hard data to reinforce our intuition that "speed matters" on the Internet. Google runs experiments on the search results page to understand and improve the search experience....
Our experiments demonstrate that slowing down the search results page by 100 to 400 milliseconds has a measurable impact on the number of searches per user of -0.2% to -0.6% (averaged over four or six weeks depending on the experiment).
...
Similarly, users exposed to a 400 ms delay since the beginning of the experiment did 0.44% fewer searches during the first three weeks, but 0.76% fewer searches during the second three weeks.
They slowed result delivery time down by less than half a second and at the end of 3 weeks lost nearly one percent of the searches regularly conducted... I'm in the speed matters crowd personally.
1. He mentioned that page speed is already used as a metric for ads on the AdWords side of things, but said that it is not yet a factor in search.
2. He said he would not rule out that it might become one of the 200 factors used in determining ranking in the future.
3. He made some comment like "2010 is the year to speed up your site".
I have a site that is overloaded and slow and needs a tuning. I'm thinking that if nothing else, a slow site looks bad to Google in two ways
a. if they are taking bounce rate and page views per visitor into account based on toolbar data, GA data and logged in users, a slow site would tend to fair worse in those respects.
b. I imagine that a slow site is harder to crawl, and therefore to index properly.
I'm sure other people here can think of other consequences of slow sites that lead to them being indirectly hurt in the SERPs without speed being a first-order factor in determining ranking.
Call a company offline, or email them. How fast do they answer the phone / respond? Do they sound alert and interested or half asleep?
I think it's rare for there to be a 'best' provider of any service. There's just the one that suits you best.
Whenever I'm shopping around and making enquiries, the companies that get back to me quickly or deal with my enquiries promptly and efficiently make an impression.
On some sites I use a core css file that is loaded by the home page and is cached by the browser. This contains some rules not used by the home page but that are used by inner pages. I guess as a result the home page loads marginally slower and inner pages laod marginally faster. The overall burden on bandwidth is lower especially where background images are reused on inner pages. My point is that analysing individual pages is not necessarily indicative of the performance of the site as a whole in either bandwidth or user experience (speed) terms.
Cheers
Sid
I think it's about time Google stopped thinking that they rule the internet.
It is the one eyed man in the land of the blind.
I think it's about time Google stopped thinking that they rule the internet.
They indeed do.
I took Matt's comments at Pubcon as a call to action to all of us who've gotten lazy.
Whether they do it or not, what's the betting the negative SEOs are going to play around with near-DOS as a way of harming their clients' competitors?
I think it's already a factor. We recently had this happen to us ... first in spurts, then two days ago a full blown DOS attack against not only us, but our entire ISP.
it has affected our rankings.... nothing else has changed significantly.
Whether or not it was a competitor or a ticked off customer .. who knows... but it happened just the same.
small two page site over a comprehesive Wikipedia article
Boost that to 5000 words. That takes your page to 25k download.
Add in background noise of say 50K and the difference between a small 300 word page and a monster 5000 word article is 50k and 75k. Add in gzip and the noticeable difference in speed of loading of those two pages is quite simply nonexistent.
Speed of your webpages is dependent on two things (and neither of them is the amount of content): server response time, and how much graphics crap you've got on your page. Those are the two things you need to address. And both of those, while they seem like small things to me, are 'fair enough' reasons to spank or reward (though I'm not sure if they're indicative of content quality. We'll take Google's word for it).
I can say that I'm one data point on this - my main sites rock speedwise. My crap sites are on $5 a year hosting plans which frequently are slow loading.
I've been accused of having very fast-loading sites. Here are my tips:
If you are doing complex data manipulation at runtime, stop it. Precompute and denormalize your data.
Benchmark.
Simplify your code.
Look for places where redundant or repetitive file I/O or SQL commands are happening. Kill them.
Using an external 3rd party API to get content for the page? Don't. Find another way.
Apply caching liberally.
If you have to, remove features.
If you can't remove a slow-loading feature, pull it out of the initial page response and load it asynchronously with AJAX.
It doesn't matter what we think is important, what matters for Google ranking is what Google thinks is important. Could this tool be an indicator of what they think is important I wonder.
I usually check WMT to see that load times are ok, they usually are around 1/2 second (~500ms). What is an acceptable value?
I understand the user experience issue. I just don't want to have to "compete" on speed, since honestly, it's something where the competition is won with money.
But there are so many things you CAN do to speed up a site, even on el-cheapo hosting. They really don't take money, they just take the desire and caring to do it.
So don't do it for Google if that doesn't float your boat. But do it for your visitors. I can tell you, your business will do better because of the extra speed.
I just think this is one more factor to check against the competition. If you have more keyword density, more prominence, more relevant backlinks, more PR and a faster site than the current #1 then you ought to be able to take that top slot. Or perhaps if you are only matching the #1 for most SEO factors speed could be the thing that gives you a slight edge.
Cheers
Sid
Take two sites, both targeting the same local demographic, for argument's sake let's say Tasmania, Australia.
Site 1 is hosted in Hobart, Tasmania
Site 2 is hosted in San Francisco, California.
Which site is more responsive for Tasmanian residents? (1)
Which site appears faster to googlebot? (2)
It would be a pitty if 1 got a rankings boost over 2 based on it being faster, when in reality it's slower for the majority of its users.
Or perhaps the speed will be measured in other ways... Crome, etc.
Is that right?
And would it help in relation to this thread?
That's my trick, and it works because you can force a browser to open more connections than it normally would to a single site (domain), but don't tell anyone alright? Thanks! (It might or might not help in relation to GBot, but I build sites for the real visitors and if GBot doesn't pick up on it, then I couldn't care less, because IMO load speed matters.)
Split Components Across Domainstag: content
Splitting components allows you to maximize parallel downloads. Make sure you're using not more than 2-4 domains because of the DNS lookup penalty. For example, you can host your HTML and dynamic content on www.example.org and split static components between static1.example.org and static2.example.org
If you (or your host) has domain wildcards set to on all you have to do is link to the subdomain and not canonicalize your images.
They still sit on the same server in the same directory as they do now, but the browser opens extra connections to the 'other' domain...
* Make sure you if you do this you exclude your images from any canonicalization first (at the top of your file) if you use a negative-match, otherwise you'll be redirecting the browser back to your domain and adding time to the process.
I usually only serve from two total 'domains', because when I tested with 3 my browser visibly slowed down on cable and a high-end host, but test for yourself, because your results may vary...
You'll have to test for yourself, but depending on how many images (items) you have to load, you can speed up actual page load time by using less larger images rather than more smaller images, because contrary to what seems to be popular belief, browsers usually stall out on upstream requests because service providers allow for a much faster download rate than upload rate to make their connections appear faster for a given amount of bandwidth.
The average browser only opens 2 requests to a given domain (unless the user knows how and adjusts the settings), so if you have 12 images (slices) and can decrease the number your actual time to display will decrease, because with only 2 connections a browser finishes the first download, then makes another request, finishes the second download, then makes another request, and so on, so your 3rd and 4th images don't even begin to download until another upstream request has been made after the first and second downloads (respectively) are complete...
The overall image size is going to be about the same, so all you really do by slicing is force the browser to make more upstream requests, wait for a response from your server and the delivery of the next file, then complete the download and repeat the process until all the image (or whatever) requests are complete.
I personally won't slice images, because they may appear, on paper, to 'load faster' overall individually, but most of the time making a single request for the same amount of data is faster because you eliminate steps from the process and the overall amount of data transferred is generally the same.
IMO and in agreement with the others who have posted something similar, there is usually something you can do to decrease your page load time without changing hosts or paying more or doing anything more than a bit of research into the best way to structure things WRT speed.
I actually don't remember where I read the information I just posted, but there's a link here at WebmasterWorld to the original source, because a few years ago I followed it... Happy hunting. :) I honestly think it might have been in the supporters forum, but really don't remember or I would post it to back up my statements.
EDITED: I just plain can't type sometimes. LOL. You'd think someone who works with a keyboard would figure out how at some point in time, but it's still a struggle for me on certain days of the week! LOL.
