I spent last week at Family Camp in Maine. They had an awesome 1920’s Arts & Crafts style lodge where we could get online after the kids went to bed. Unfortunately, the camp’s Linksys router was fried by a lightning strike. My only other option was Blackberry-modem. Verizon’s NationalAccess plan provides near-broadband speed in most cities, but in Raymond, Maine, it was no better than dial up.
Some websites performed really well on a slow connection, and others were just unusable. Wikipedia was the most functional Web 2.0 site I tried, even with all my JavaScript add-ons. Google AdWords was painful, Yahoo! Marketing Solutions was hellish, and Microsoft adCenter wouldn’t even load. BaseCamp and FreshBooks both worked well.
The big idea here is that you shouldn’t assume website users have the same bandwidth that you do. Lots of people visit websites via mobile phones, public hotspots, and overloaded corporate networks. If your site demands less bandwidth, you’ll have more happy campers.
How does this relate to search? Search is inherently competitive. Users get a search engine results page (SERPs) full of choices. If somebody has a restricted bandwidth situation and your site loads slowly, there’s a huge risk that they’ll hit the back button and try a different site. I did a lot of that last week.
Have you ever wondered what causes users to bounce? Most SEOs think about ways to improve page relevancy to the search query and how to grab the users’ attention. Those are good tactics, but they aren’t the whole story. Some bounces happen even before the users see content. Your server may receive a request and transmit the page, but the user has already hit the back button before the page renders.
Search engines put tracking code on SERP links. They can tell when a user clicks the back button and chooses a different page. Google has even said that they incorporate user behavior data into their ranking algorithms. While they won’t confirm using this particular “signal”, measuring bounce rates seems like an obvious way to judge page quality. When your pages have a high bounce rate, in addition to losing those visitors, your search rankings may suffer.
Here are a few ways to make your website perform on a slow connection, and potentially grab traffic from less savvy competitors:
- Graphics should support your message. Use them sparingly on most sites.
- Optimize graphics to reduce file size. Whether you choose a JPG, GIF or PNG format will affect the file size, as will the quality of the output image. Reducing image quality slightly can make the files much smaller.
- Most browsers cache image files, so run-of-site graphics only need to be downloaded once. If you avoid using different design elements from page to page, your site will probably load faster.
- Use external style sheets to control formatting and layout whenever possible. A style sheet only needs to load once. Inline and page head CSS definitions are repeatedly downloaded with each page view. HTML formatting commands are also repeatedly loaded with each page.
- Keep page length reasonable. Break up large pages by sub-topic, and refrain from overloading pages with excessive detail.
- Keep layouts as simple as possible while getting the job done.
- Eliminate unnecessary features on interactive pages. JavaScript and rich media can tie up lots of bandwidth. Consider using progressive enhancement.
- Move JavaScript to external .js files. These files only need to load once per session. Inline JavaScript loads with every page view.
- Eliminate redirects whenever possible to reduce the number of requests to the server.
- Delete unnecessary code, and clean up code by running it through HTML Tidy.
If you want to see how your site performs, try the SEO Consultants Directory’s free URI Valet service. You can test your pages for speed and see how the different page elements add to bandwidth demands.
Jonathan Hochman has two computer science degrees from Yale. He runs an Internet marketing consultancy and a web development shop.
Opinions expressed in this article are those of the guest author and not necessarily Search Engine Land. Staff authors are listed here.