In a recent video interview, Matt Cutts, the public face of Google search technology, talked about upcoming changes to the Google ranking algorithm (see related column). When Matt Cutts starts talking about Google and how it does search ranking, it’s sort of like when a Federal Reserve chairman starts talking: People get a little anxious.
This interview is no different. Half of the interview is spent talking about site speed — how fast Web sites load. Here are the tidbits that matter most: "Historically, we haven’t had to use it in our search rankings, but a lot of people within Google think that the Web should be fast. It should be a good experience, and so it’s sort of fair to say that if you’re a fast site, maybe you should get a little bit of a bonus."
And: "I think a lot of people in 2010 are going to be thinking more about ‘how do I have my site be fast?’ "
Anxious yet?
It’s important to note what wasn’t said here. No one said, "Google is going to start using site load time as a ranking factor tomorrow." However, I think the writing is on the wall. This could be especially tricky for data-heavy real estate sites.
Luckily, as Matt Cutts points out in the interview when he says, "If you really have an awfully slow site, then maybe users don’t want that as much," making your site load a little faster is probably good no matter what Google does with its ranking formula.
What can you do about site load time?
Site load time can be affected by many factors. But the factors most within your control are size of the content and use of the server’s computer processing power. Size of your content includes the size of images, the amount of text and the quality of the code used to deliver your site to your audience’s Web browser. The server’s computer processing power is used to serve up the files and to process special code called "server side scripts." It takes time for the computer to process the code, and then it serves it up to the browser.
There are generally two parties that can have a dramatic increase in the site load time of your Web site: you and your code vendor. This means that if your site is running slow, it isn’t all your code vendor’s fault. But your code vendor does have a part to play.
Things you should be able to do to make your Web site faster, without calling your code vendor:
1. Think about designing for speed from the very outset of your Web-building process. Ultimately, whoever builds your Web site will end up building what you tell them to build. So if you’re a site owner, you’ll serve yourself better by thinking about speed from the very beginning. Instead of trying to make a page on your Web site communicate 15-20 different ideas and offers and so on, break it down so each page has one primary focus. If you do this then the rest of the tasks involved in making your Web site load faster will be much, much easier. This advice is doubly applicable to your home page.
2. Consider the value of every widget you add to your site. Anything you add to any page on your site that includes some sort of interactivity adds to your load time: mortgage calculator, super slide show magnification widget, Twitter thingy and so on. Sometimes these bits of content will have strategic value — you can measure their influence on your business performance. Sometimes they don’t — someone told you that you won’t be cool if you don’t put it on your site. If a widget lacks strategic value, remove it. If you’re not sure whether it has strategic value, test and find out.
3. If you add images to your site, optimize them. Everything on your site that isn’t Web text takes time to download. This includes uploading images to your multiple listing service because those same images will end up getting pulled into your site via IDX (Internet Data Exchange, a data-sharing system for real estate brokers) feed later on. In these days of broadband it seems that image optimization is a forgotten art. But frankly, it isn’t very hard and much of it can be automated. …CONTINUED
Real estate is a business that makes heavy use of images. Understanding and automating image optimization is probably a worthwhile thing for you or someone in your organization to be on top of.
4. Insist on clean code from your vendor. The phrase to use is "XHTML/CSS W3C compliant." While a site built with this spec isn’t guaranteed to load faster than others, it is far more likely to load faster because it means the vendor cares about the quality of the underlying code as much as the vendor cares about making it look good. You can test whether your site is compliant by going to the W3C validation site. When your site comes up with all sorts of errors and warnings, don’t sharpen your pitchforks right away but do ask your code vendor to explain to you why those errors exist (sorry code vendors — you can throw pies at me at the Inman Connect NYC conference).
Chances are that some of them are there because of specific requests made (maybe by you) in the design phase (see item one above). Another thing to do is use your browser’s "view source" option and see if you notice a bunch of code related to <table> or <tr> or <td>. If you don’t have table data (like bus schedules or price sheets, for example) then you shouldn’t be seeing that stuff on your page — it’s slowing down your load time.
5. Be careful with WordPress. I don’t want anyone to take this the wrong way. I love WordPress. I love building sites with it. I love using it. I love how easy it is for people to figure out how to use it. It’s awesome. That said, WordPress makes very heavy use of server-side scripting languages that can slow down a Web site. So be careful with it, understand that every little feature and widget and plugin you add may be increasing your site load time.
Code vendors can make their clients rock
Most code vendors have one or more people who live, eat and breathe server speed. So hopefully nothing here will be amazingly new. But just to make sure the basics are covered, here are three things you can do that don’t involve buying new servers (warning for non-code vendors — this could get geeky):
1. Serve assets from different hostnames. Most browsers allow only up to two connections to a hostname (a hostname is an identifier for a device connected to a network) at the same time. So if, for example, you serve all the HTML, CSS and image assets from the same hostname, then everything will download two at time. You can increase the number of assets loading into a page by putting some of those assets at different hostnames.
For example, if the CSS is at one hostname and the HTML is at another hostname and the images are at a third hostname, then six things can be downloading at once. At some point you’ll run into the upper limit of the client-side bandwidth. Bonus points if you do it with separate IP addresses instead of hostnames (saving the time of a DNS lookup).
2. Cache responsibly. Make sure that all those no-cache meta tags are really on pages where the strategic content changes every single time you visit them. Also, doublecheck to make sure that your JavaScript and CSS are external files, allowing visitors to cache them.
3. Fancy navigation design? Use sprite-based CSS. Using sprite-based CSS for main navigation rollovers that require graphics will take fewer server calls (one call for the main navigation vs. separate calls for normal and hover states, multiplied by the number of navigation items).
So I hope you all go out and make your Web sites faster. Google has been making noise about adding page-load times to the ranking factors for some time. It’s going to happen. But more importantly, your site visitors will have a better experience. If you undertake a site-speed initiative, be sure to measure before/after on your bounce-rates and number of pageviews for a comparison.
Gahlord Dewald is the president and janitor of Thoughtfaucet, a strategic creative services company in Burlington, Vt. He’s a frequent speaker on applying analytics and data to creative marketing endeavors.
***
What’s your opinion? Leave your comments below or send a letter to the editor.
