Yesterday I discussed code bloat by looking at how we can move style sheets and JavaScripts off the page in order to clean the coding up quite a bit. I this third post about cleaning up bloated code I wanted to address Tables and other typical causes of bloated HTML.

Bloated Tables

The most typical code bloat I find in sites I work with is created from an excessive use of tables on the page. Personally, I like working with tables over CSS. They are easy to understand and manipulate. I'm not a coder so once tables are moved to CSS it all becomes a bit more difficult to manipulate everything they way I want.

But even while I like tables, I understand the distinct value in creating a tableless website design. Tables create a significant amount of excess code that can slow down page download times significantly. Below is an image of a very simple web page built using tables.

Snapshot of simple website that uses tables

On the surface this looks like a very simple design which shouldn't require a lot of code. But if we look at it with images off and the tables outlined, we see quite a different picture:

Snapshot of simple website outlining 13 tables

While this is a very simple design, the amount of tables used here is quite incredible. This small design has 13 separate tables and 45 table cells. Even if you were not to reformat this using all CSS for a tableless layout, an experience developer could re-create this with one table and five cells. That's a lot of excess code for an itty-bitty web page.

Another drawback about using tables is that your most important content isn't always read first. Within your code, the table content is displayed not top to bottom, but left to right, one cell at a time. The top cell, if there is one, is read first then the rest of the cells are read in order.

How tables are read in code

Most websites contain the header in the top cell and then the navigation in the far left cell. This means that all the items in your navigation are essentially given more prominence than your main body content which often comes next. Let's place the above layout over the design we already looked at, to get an idea of what the search engines will see first:

Table overlayed on top of website illustrating how it is read

Assuming that this was just a four cell page (not including the footer) the content is pretty much near the bottom of the code. Will the search engines find it down there? Sure. Will it make a difference in ranking to move it up? Probably not much. But it could make a difference in getting the page spidered. Pages with a large amount of code bloat, with content pushed down pretty far, can often get bypassed or the search engines will stop spidering the page before getting to all the content.

Now here is the great thing about using CSS and div positioning. You can rearrange your content in the code without rearranging it's appearance on the page. With this method you can put your content first while pushing your navigation, which is non-essential-for-rankings, further down the page.

How CSS can rearrange how a page is read

Not every site can go completely tableless. But even if you don't have the CSS skills to create the table-less design, eliminating unnecessary table code bloat can improve page performance quite a bit. Especially if you've got a considerable excess number of tables going on. But take that a step further and position your content via CSS to get your important content as high up in the code as possible.

Other HTML Bloat

If you're like me then you use a WYSIWYG (what you see is what you get) HTML editor for editing web pages. Now I can write code, but I find WYSIWYG editors to make things a whole lot easier, since I'm more of a visual person. But I love programs like Dreamweaver that allow me to have both the visual view and the code view open at the same time.

Usually, I'll use the visual view just as an assist while I edit the code by hand. Editing in code view, rather than visual view, ensures that you get cleaner code. Over the years I found that when you edit in the visual view it can often add excessive garbage to the code. Do this enough and over time you can get yourself some considerable code bloat.

One example of this is when you copy text from Microsoft Word. Word creates a lot of excess junk when you past it into a visual editor. Just the other day I copied some bullet points from Word into an editor. Each bullet was a line long. But upon importing, Word carried over an additional four lines of junk code--per bulleted item--that I had to go in and edit out.

Deleting things from the visual view can also leave behind excess code. An number of times we've run broken link checks for our clients to find a broken link on the page. Looking at the page in the browser you could not find the link anywhere. It wasn't until we got into the code that we found an empty link tag, like this:

<a href="site.com/broken-page.html></a>

The linked pae is still referenced, there just isn't anything actually linking to it. So the search engines see this, but the human visitor doesn't. It's just garbage code which can also be interpreted as a hidden link!

You can get these kinds of problems when you're formatting text as well:

<strong> </strong>
<em> </em>
<font> </font>
<div> </div>
<span> </span>

All of these elements are empty, yet can still reside in the code. Since they have no purpose they are just junking up the page. My recommendation is that if you use a visual editor, pay particular attention to the code. Make sure you don't get any of these remnants that are just cluttering things up.

Minor code bloat, whether it be from remnants or tables won't have a significant effect on search engine rankings. But when you make frequent edits and let the code bloat build up, or create an excessive amount of tables, then you're decreasing the download speed of your pages. If the spiders find your pages particularly burdensome then they'll leave without properly spidering all of your content. Without the content in their index, it won't matter how well optimized your content is, you won't be able to rank for it if it's not getting downloaded.


July 2, 2008





Stoney deGeyter is the President of Pole Position Marketing, a leading search engine optimization and marketing firm helping businesses grow since 1998. Stoney is a frequent speaker at website marketing conferences and has published hundreds of helpful SEO, SEM and small business articles.

If you'd like Stoney deGeyter to speak at your conference, seminar, workshop or provide in-house training to your team, contact him via his site or by phone at 866-685-3374.

Stoney pioneered the concept of Destination Search Engine Marketing which is the driving philosophy of how Pole Position Marketing helps clients expand their online presence and grow their businesses. Stoney is Associate Editor at Search Engine Guide and has written several SEO and SEM e-books including E-Marketing Performance; The Best Damn Web Marketing Checklist, Period!; Keyword Research and Selection, Destination Search Engine Marketing, and more.

Stoney has five wonderful children and spends his free time reviewing restaurants and other things to do in Canton, Ohio.





Comments(12)

Thanks for the great article and visual examples.

Question - how can I tell if the spiders are having trouble spidering all of the content on my site?

I understand you are trying to keep this article focused on the SEO aspect of html coding and css implementation, but I think your view here is short sighted. Everyone that is using tables for website layout is abusing the true purpose of tables. Tables are meant to be used for data, not for layout. Tableless layouts take a different mentality to construct but I have yet to come across a table layout that I could not recreate using css and structural markup. I think you could have pushed this article a lot further by showing the difference between the table (even the "optimized" table) and a css layout.

Not too long ago using tableless layouts was the "new" thing, now it's the standard and the good news is there's inherent SEO benefits from structural markup. If you're not coding this way, you are behind the eight ball.

Thanks for your comment Chris. You may be right about "abusing the purpose of tables", but I'm not sure how much you can fault anybody since that was the only way to create a decent layout pre-CSS. Even still I've seen some very good developers stumped about how to achieve certain layouts without at least one table. But you're right, a completely tabeless design is ideal for all kinds of reasons.

Keep in mind that not all of our audience here has thier own in-house developer or even one on-call. This means that many still are using tables for layout and will continue to so so indefinitely. CSS is much more complicated and the typical site owner that uses a WYSIWYG editor isn't going to take the time to learn it. My goal is to simply help people as best I can from where they are and hopefully, do a bit to push them to where thye need to be!

@ Amy

The easiest way is to check your pages to see if they are cached in Google or not. you can do this by typing in cache:www.site.com/page.html into the google search.

Complicated is a relative term. I find table layouts more complicated than CSS layouts, but that's because I've been doing tableless layouts for close to 6 years now.

I believe we can fault those using table layouts because now we know better. That's what we should do - learn from past mistakes and push forward.

Regardless of anyone's knowledge or experience with html it is up to all of us to push forward for the betterment of the industry and the web as a whole. In that regard I believe we are on the same page.

As I have told all the people (developers as well as site owners) I have taught web standards and css - start small. Replace one font call with a paragraph tag, write one css declaration. When you're comfortable with the basics, keep pushing forward.

Great article Stoney. I come across this issue on a daily bases evaluating sites. The majority of time, they've got tables within tables, within tables...

I said "WYSIWYG" to one of my developers and he about choked the life out of me.

There is some controversy over how representative Alexa’s user base is of typical Internet behavior. If http://www.alexa.com/data/details/main?url=www.fortunehotels.in Alexa’s user base is a fair statistical sample of the internet user population, Alexa’s ranking should be quite accurate.

I am trying to shift all my newest web work over to CSS, but it's definitely a whole lot tougher than table-based, especially since it's really hard to see what you're doing if you are more of a visual person (which I am). I did find a tool called Eric Meyer's CSS Sculptor which greatly simplifies the process and is reported to make good compliant CSS. It works as a plugin for Dreamweaver.

Also, after all these years, we all know the browser tweaks and workarounds for table-based design, but CSS is a whole new animal, and most web designers haven't had the time to figure out all the weirdnesses of all the browsers.

I will definitely do all future sites in CSS and I hope that CSS Sculptor will help cut down development time while I figure out all the ins and outs of CSS.

@ Amy,

Yeah, I'm a visual person too so I'm still getting the hang of it. I'll have to check out the CSS sculptor.

Nice work Stoney. I think the home run came at the end, with respect to page loads... and let's be mindful of the fact that there can be a pretty tangible dollar cost to slow page loads in SEM -- now that Google is working page load times into the quality score! Effectively, it's much like the gas guzzler tax on SUVs... chew up bandwidth and you get smacked with a fine. So yeah -- well times, this post...

Now begins the decline of heavy flash websites. Every ones been to a flash site that seems to never stop loading.

Comments closed after 30 days to combat spam.


Search Engine Guide > Stoney deGeyter > How to Fix the Bloated (Tables and HTML) Code that is Jacking Up Your SEO