2010 website speed and google SERPS

[sonnas]

Ive read that from this year on, google will take into consideration the speed of your website and SERPS. Apparently its not going to be a major factor but a facotr nether the less. what are peoples views, and also, what speed is considered slow?

and how accurate is the site performance on webmaster tools?


http://econsultancy.com/blog/5728-it-s-official-google-incorporates-website-speed-into-your-ranking

 

[fisicx]

There is a trick you can use to beat the search engines: send less data.

Strip out all the styling and css and load into an external file. Use divs rather than tables and put all your layout imagery in the css. Optimise images, don't use flash and delete anything animated.

In other words, do what competent programmers and coders have been doing for years.

 

[awebapart.com]

and how accurate is the site performance on webmaster tools?

Google's site performance metrics are dodgy, to say the least.

By all means speed up your site for your users, but personally I wouldn't go much on google's metrics. For ecommerce stores, possibly the main speed factor is the database. How many times the database gets hit and for what during a page load.

Some ecommerce sites are very database heavy. Not just making multiple reads to the database (categories, specials, related products, etc), but also saving data (page read stats) to the database during a page load. Some general CMS's are database heavy too.

 

[weareable]

Your page speed only only factors about 1% of googles consideration.
I would recommend doing all that fisicx suggests but I wouldn't alter my layout or designs for it. Its all about what converts.

Does that make sense? I'm ill and out of it today..

 

[sonnas]

Google's site performance metrics are dodgy, to say the least.

and how accurate do you reckon the websites that do speed tests are when i google "website speed test"?

 

[awebapart.com]

and how accurate do you reckon the websites that do speed tests are when i google "website speed test"?

It depends how they perform the test, whether they do it client side (in the user's browser) or server side (server to server test), and what tests they perform. For server side tests, the server location might affect accuracy too.

The most accurate speed testing you can do for your website, is to mimic your real users. Test your site on various browsers, on various PC configurations, on various broadband connections. This real life testing is important not just for identifying speed issues, but for identifying other functionality issues too (i.e. does your website actually work on certain people's PCs).

 

[Simply Business]

If possible, try to cache your pages overnight.
Only when your customers do a live search, the page cache is lost and live results will be shown.

You should cache at least your index page + some "hub" pages. Fast loading pages are great for customer experience. Use cached pages for your most important keywords.
Site speed optimisation for SEO reasons is only interesting when the competition for the keywords is severe.

I've seen another tip in this discussion: get rid of all the excess code and application on your page and "outsource" them to external files. By all means, do!

 

[An Oasis]

Interesting chat about it here http://www2.webmasterradio.fm/strike-point/2010/page-speed-ranking-factor-in-google-algorithm/

 

[sonnas]

Interesting chat about it here http://www2.webmasterradio.fm/strike-point/2010/page-speed-ranking-factor-in-google-algorithm/

thanks for that, that was good and informative

 

[MartCactus]

Some ecommerce sites are very database heavy. Not just making multiple reads to the database (categories, specials, related products, etc), but also saving data (page read stats) to the database during a page load. Some general CMS's are database heavy too.

Any modern ecommerce or CMS software should be caching content automatically to prevent this.

In ASP.net for example this functionality is built in at the level of user controls. So if we have a page on our ecommerce software that features (eg) a basket, multilevel menu of products (which might have hundreds of entries), images of products etc we can control how often new data is fetched from the database for each control. Clearly the basket needs to update each time, but the product menu can be cached indefinitely until product data is updated. This massively reduces the calls to the database (might cut them by 90% or more - and usually the most complex calls) and therefore speeds up page response as well as requiring less hosting horsepower for the same amount of traffic.

If your CMS or ecommerce software isn't doing that, look for one that does - it will not only speed up your site, but lesson the cost of the hosting you need to have behind it. As Google itself appears to say, site speed isn't going to a be a massive factor, but having spent the money to get a punter to your site, you don't want to lose them with a slow site experience - users like fast sites.

 

[awebapart.com]

Some ecommerce sites are very database heavy. Not just making multiple reads to the database (categories, specials, related products, etc), but also saving data (page read stats) to the database during a page load. Some general CMS's are database heavy too.

Any modern ecommerce or CMS software should be caching content automatically to prevent this.

This certainly isn't the case with osCommerce, Zencart, Magento or Wordpress in their default states. You have to do things like enable caching or install caching modules to get this functionality. With some systems, like osCommerce, only certain areas are cached if caching is enabled, not everything (there are still a lot of database hits going on).

I would also question some speed aspects of even one the most modern popular open source ecommerce systems, Magento. Point in case is Magento's zoomable product picture, which displays a "small" picture you can zoom in on if you want. That original picture might look "small" but it is in fact loading the large picture into the browser right from the start, which is a bad performance hit.

osCommerce and Zencart, don't even have image shrinking by default either, another speed issue. This browser shrinking of images isn't just an issue for default Magento, osCommerce or Zencart, it is an issue I see from users on this forum quite a lot.

 

[MartCactus]

This certainly isn't the case with osCommerce, Zencart, Magento or Wordpress in their default states. You have to do things like enable caching or install caching modules to get this functionality. With some systems, like osCommerce, only certain areas are cached if caching is enabled, not everything (there are still a lot of database hits going on).

Sure - I'm aware many *don't* do this. The point is that they should now.

We developed our original software in "classic ASP" back in 1998 which (along with most platforms of the time) had very little support for caching other than at a page level... we developed our own support for caching some data where it was causing bottlenecks.

But now with platforms like ASP.net there is no reason not to highly optimize such software during development to ensure data is only requested from the database when necessary, and to cache menus and other page elements, only refreshing when that data is changed. I'm not so familiar with non-microsoft technologies but I imagine any modern system would offer similar support to control caching of user controls at the time of development to optimize performance and scalability?

You mention image scaling. We enable users to upload an image (or multiple) for a product and then reduce it to the size of the biggest image they want supported on their site (so we don't store it bigger than necessary). Thumb nails are then created on the fly, but importantly we use the caching here. So if I upload an image that is 1000x800 pixels but the largest I want images to appear on my size is 500 width, then it resizes it to 500x400 and stores that. If thumbnails are then eg 100px width, it will create that on the fly from the larger image, but then cache it. Each time someone sees a thumbnail of that image, it will be a cached one - we don't have to reprocess the resize.

If the image was changed, or the site operator decided he wanted to change the size of the thumbnails, the cache would be reset.

This would have been all very complex with classic ASP (but still possible) but with ASP.net much of this ability is built in - its just a case of designing software properly from the outset to take advantage of this.

 

[awebapart.com]

Interesting chat about it here... webmasterradio

The Danish guy says quite a few sensible things in that chat, but I don't agree with everything David Naylor is saying. David has placed all of his website images on a different website domain.

Now whilst I'm all for a bit of load balancing, I think that is taking it a bit too far. I'm not sure that having a website that just uses images from other websites is giving the right message to google, in terms of saying my site has good unique content.

I don't know whether this change has adversely affected David's rankings (a drop in rankings), but from what I can see his site is currently page 3 of google for one of his main targeted terms (search marketing), page 7 for one of his other main targeted terms (SEO blog), and page 8 for one of his other main targeted terms (SEO agency) - although perhaps it has been like that for a while.

 

[An Oasis]

I don't know whether this change has adversely affected David's rankings (a drop in rankings), but from what I can see his site is currently page 3 of google for one of his main targeted terms (search marketing), page 7 for one of his other main targeted terms (SEO blog), and page 8 for one of his other main targeted terms (SEO agency) - although perhaps it has been like that for a while.

LOL good points but I doubt old DaveN cares, maybe he'll pop by and tell.

 

[awebapart.com]

You mention image scaling. We enable users to upload an image (or multiple) for a product and then reduce it to the size of the biggest image they want supported on their site (so we don't store it bigger than necessary). Thumb nails are then created on the fly, but importantly we use the caching here. So if I upload an image that is 1000x800 pixels but the largest I want images to appear on my size is 500 width, then it resizes it to 500x400 and stores that. If thumbnails are then eg 100px width, it will create that on the fly from the larger image, but then cache it. Each time someone sees a thumbnail of that image, it will be a cached one - we don't have to reprocess the resize.

Yes we do something similar with our sitebuilder CMS. We also had to do some custom development with our custom version of osCommerce (which we sometimes use as the shop section of our sites). With osCommerce you have to be very careful implementing auto-thumbnailing, if you go for one of their modules and don't improve it at all, all it does is real-time server-side shrinking with no caching, a server-side shrink everytime an image is requested! Quite a server hog!

This would have been all very complex with classic ASP (but still possible) but with ASP.net much of this ability is built in

I used to develop in classic ASP and VB, and doing it in classic ASP alone would be very difficult, without getting some ActiveX component installed, or writing one yourself in say VB.

I think one of the reasons this functionality isn't included by default in osCommerce and Zencart is because it relies on a PHP image module (e.g. GD library) being installed, which isn't always guaranteed in a hosting environment.

I'm not so familiar with non-microsoft technologies but I imagine any modern system would offer similar support to control caching of user controls at the time of development to optimize performance and scalability?

PHP doesn't really have a user control metaphor, although some frameworks built on top of PHP might. But even if a system isn't designed to cache controls, caching in other areas like pages, parts of pages, database results etc can improve performance, but that is usually an application or database specific design issue when developing in PHP. For instance Magento's design and caching architecture was discussed here a while ago.