Colin Cochrane

Colin Cochrane is a Software Developer based in Victoria, BC specializing in C#, PowerShell, Web Development and DevOps.

How Being An SEO Analyst Made Me A Better Web Developer

Being a successful web developer requires constant effort to refine your existing abilities while expanding your skill-set to include the new technologies that are continually released, so when I first started my job as a search engine optimization analyst I was fully expecting my web development skills to dull.  I could not have been more wrong.

Before I get to the list of reasons why being an SEO analyst made me a better web developer I'm going to give a quick overview of how I got into search engine optimization in the first place. Search engine optimization first captured my interest when I wanted to start driving more search traffic for a website I developed for the BCDA (and continue to volunteer my services as webmaster). Due to some dissatisfaction with our hosting provider I decided that we would switch hosting providers as soon as our existing contract expired and go with one of my preferred hosts. However, as a not-for-profit organization the budget for the website was limited and the new hosting was going cost a little more, so I decided to set up an AdSense account to bring in some added income. 

The expectations weren't high; I was hoping to bring in enough revenue through the website to cover hosting costs.  At that point I did not have much experience with SEO so I started researching and looking for strategies I could use on the site.  As I read more and more articles, blogs and whitepapers I became increasingly fascinated with the industry while I would apply all of the newfound knowledge to the site.  Soon after I responded to a job posting at an SEO firm, applied, and was shortly thereafter starting my new career as an SEO analyst. 

My first few weeks at the job were spent learning procedures, familiarizing myself with the various tools that we use, and, most importantly, honing my SEO skills.  I spent the majority of my time auditing and reporting on client sites, which exposed me to a lot of different websites, programming and scripting languages, and tens of thousands of lines of code.  During this process I realized that my web development skills weren't getting worse, they were actually getting better.   The following list examines the reasons for this improvement.

1) Coding Diversity

To properly analyze a site, identify problems, and be able to offer the right solutions I often have to go deeper than just HTML on a website.  This meant that I had to be proficient at coding in a variety of different languages, because I don't believe in pointing out problems with a site unless I can recommend how to best fix them.  Learning the different languages came quickly from the sheer volume of code I was faced with every day, and got easier with each language I learned.

2) Web Standards and Semantic Markup

In a recent post, Reducing Code Bloat Part Two: Semantic HTML, I discussed the importance of semantic HTML to lean, tidy markup for your web documents.  While I have always been a proponent of web standards and semantic markup my experience in SEO has served to solidify my beliefs.  After you have pored through 12,000 lines of markup that should have been 1000, or spent two hours implementing style modifications that should have taken five minutes, the appreciation for semantic markup and web standards is quickly realized.

3) Usability and Accessibility

Once I've optimized a site to draw more search traffic I need to help make sure that that traffic actually sticks around.  A big part of this is the usability and accessibility of a site.  There are a lot of other websites out there for people to visit and they are not going to waste time trying to figure out how to navigate through a meandering quagmire of a design.  This aspect of my job forces me to step into the shoes of the average user, which is something that a lot of developers need to do more often.  It has also made me more considerate when utilizing features and technologies, such as AJAX, in respect to accessibility, such that I ensure that the site is still accessible when that feature is disabled or is not supported.

4) The Value of Content

Before getting into SEO, I was among the many web developers guilty of thinking that a website's success can be ensured by implementing enough features, and that enough cool features could make up for a lack of simple, quality content.  Search engine optimization taught me the value of content, and that the right balance of innovative features and content will greatly enhance the effectiveness of both.

That covers some of the bigger reasons that working as an SEO analyst made me a better web developer.  Chances are that I will follow up on this post in the future with more reasons that I am sure to realize as I continue my career in SEO.  In fact one of the biggest reasons I love working in search engine optimization and marketing is that it is an industry that is constantly changing and evolving, and there is always sometime new to learn.

Reducing Code Bloat Part Two - Semantic HTML

In my first post on this subject, Reducing Code Bloat - Or How To Cut Your HTML Size In Half, I demonstrated how you can significantly reduce the size of a web document by simply moving style definitions externally and getting rid of a table-based layout.  In this installment I will look at the practice of semantic HTML and how effective it can be at keeping your markup tidy and lean.

What is Semantic HTML?

Semantic HTML, in a nutshell, is the practice of creating HTML documents that only contain the author's "meaning" and not how that meaning is presented.  This boils down to using only structural elements and not presentational elements.  A common issue with semantic HTML is identifying the often subtle differences between elements that represent the author's meaning versus a presentational element.  Consider the following examples:

<p>
I really felt the need to <i>emphasize</i> the point.
</p>

 

<p>
I really felt the need to <em>emphasize</em> the point.
</p>

Many people would consider these two snips of code to be essentially the same; a paragraph, with the word "emphasize" in italics.  When considering the semantic value of the elements, however, there is one significant difference.  The element <i> is a purely presentational (or visual), and it has no meaning to the semantic structure of the document.  The <em> element, on the other hand, has a meaningful semantic value in the document's structure because it defining its contents as being emphasized.  Visually we usually see the contents both <i> and <em> elements rendered as italicized text which is why the difference often seems like nitpicking, but the standard italicizing for <em> elements is simply the choice made by most web browsers, it has no inherent visual style.

Making Your Markup Work for You

Some of you might be thinking to yourself "some HTML tags have a different meaning than others? So what?".  Certainly a reasonable response, because when it comes down to it, HTML semantics can seem like pointless nitpicking.  That being said, this nitpicking drives home what HTML is really supposed to do: define markup.  Think of it like being a writer for a magazine.  You write your article, including paragraphs and indicating words or sentences that should be emphasized, or considered more strongly, in relation to the rest, and submit it.  You don't decide what font is used, the colour of the text, or how much space should be between each line, that's the editor's job.  It is exactly the same concept with semantic HTML: the structure and meaning of the content is the job of HTML, and the presentation is the job of the browser and CSS.

Without the burden of presentational elements you only have to worry about a core group of elements with meaningful structure value.  For instance...

<p>
This is a chunk of text <span class="red14pxitalic">where</span> random words 
are <span class="green16pxbold">styled</span> differently,
<span class="red14pxitalic">with</span> some words 
<span class="green16pxbold">being</span> red, italicized and at 14px, and others
being green, bold, and 16px.
</p>
 
with an external style-sheet definition...
span.red14pxitalic{color:red;font-size:14px;font-style:italic;}
span.green16pxbold{color:green;font-size:16px;font-weight:bold;}

...turns into this...

<p>
This is a chunk of text <em>where</em> random words 
are <strong>styled</strong> differently, <em>with</em> some words 
<strong>being</strong> red, italicized and at 14px, and others being green, 
bold, and 16px.
</p>

with an external style-sheet definition...

p em{color:red;font-size:14px;font-style:italic;}
p strong{color:green;font-size:16px;font-weight:bold;}

The second example accomplishes the same visual result as the first, but contains actual semantic worth in the document's structure.  It also illustrates how much simpler it is to create a new document because you don't have to worry about style.  You create the document and use meaningful semantic elements to identify whatever parts of the content are necessary, and let the style-sheet take care of the rest (assuming of course that the style-sheet was properly defined with the necessary styles).  By using a more complete range of HTML elements you will find yourself needing <span class="whatever"> tags less and less and find your markup becoming cleaner, easier to read, and smaller.

 

Code Size Comparison

 

  HTML Characters (Including Spaces) CSS Characters (Including Spaces)
Example One 302 127
Example Two 216 103

 

Part Three will continue looking at semantic HTML, as well as strategies you can use when defining your style framework.

Is There Added Value In XHTML To Search Engine Spiders?

The use of XHTML in the context of SEO is a matter of debate.  The consensus tends to be that using XHTML falls into the category of optimization efforts that provide certain benefits for the site as a whole (extensibility, ability to use XSL transforms) but offers little or no added value in the eyes of the search engines.  That being said, as the number of pages that search engine spiders have to crawl continues to increase every day, the limits to how much the spiders can crawl are being tested.  This has been recognized by SEOs and is reflected in efforts to trim page sizes down to make a site more appealing to the spiders.  Now it is time to start considering the significant benefits that a well-formed XHTML document can potentially offer to search engine spiders.

Parsing XML is faster than parsing HTML for one simple reason: XML documents are expected to be well-formed.  This saves the parser from having to spend the extra overhead involved in "filling in the blanks" with a non-valid document.  Dealing with XML also opens the door to the use of speedy languages like XPath that provide fast and straightforward access to any given part of an XML document.  For instance, consider the following XHTML document:

<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
  <head>
    <title>My XHTML Document</title>
    <meta name="description" content="This is my XHTML document."/>
  </head>
  <body>
    <div>
      <h1>This is my XHTML document!</h1>
      <p>Here is some content.</p>
    </div>
  </body>
</html>

Now let's say we wanted to grab the contents of the title element from this document.  If we were to parse it as straight HTML we'd probably use a regular expression such as "<title>([^<]*)</title>" (As a quick aside, I want to clarify that HTML parsers are quite advanced and don't simply use regular expressions to read a document).  In Visual Basic the code to accomplish this would look like:

Imports System.Text.RegularExpressions

Class MyParser

  Function GetTitle(ByRef html As String) As String 
    Return RegEx.Match(html,"<title>([^<]*)</title>").Groups(1).Value 
  End Function 

End Class 

If we were to use XPath, on the other hand, we would get something like this:

Imports System.Xml 

Class MyParser 

  Function GetTitle(ByRef reader As XmlReader) As String 
    Dim doc As New XPath.XPathDocument(reader) 
    Dim navigator As XPath.XPathNavigator = doc.CreateNavigator
    Return navigator.SelectSingleNode(&quot;/head/title&quot;).Value 
  End Function 

End Class

Don't let the amount of code fool you.  While the first example uses 1 line of code to accomplish what takes the second example 3 lines, the real value comes when dealing with a non-trivial document.  The first method would need enumerate the elements in the document, which would involve either very complex regular expressions with added logic (because regular expressions are not best suited for parsing HTML), or the added overhead necessary for an existing HTML parser to accurately determine how the document "intended" to be structured.  Using XPath is a simple matter of using a different XPath expression for the "navigator.SelectSingleNode" method.

With that in mind, I constructed a very basic test to see what kind of speed differences we'd be looking at between HTML parsing and XML (using XPath) parsing.  The test was simple: I created a well-formed XHTML document consisting of a title element, meta description and keywords elements, 150 paragraphs of Lorum Ipsum, 1 <h1> element, 5 <h2> elements, 10 <h3> elements and 10 anchor elements scattered throughout the document.

The test consisted of two methods, one using XPath, and one using Regular Expressions.  The task of each method was to simply iterate through every element in the document once, and repeat this task 10000 times while being timed.  Once completed it would spit out the elapsed time in milliseconds that it took to complete.  The test was kept deliberately simple because the results are only meant to very roughly illustrate the performance differences between the two methods.  It was by no means an exhaustive performance analysis and should not be considered as such.

That being said, I ran the test 10 times and averaged the results for each method, resulting in the following:

XML Parsing (Using XPATH) - 13ms

HTML Parsing (Using RegEx) - 1852ms

As I said, these results are very rough, and meant to illustrate the difference between the two methods rather than the exact times. 

These results should, however, give you something to consider in respect to the potential benefits of XHTML to a search engine spider.  We don't know how search engine spiders are parsing web documents, and that will likely never change.  We do know that search engines are constantly refining their internal processes, including spider logic, and with the substantial performance beneifts of XML parsing, it doesn't seem too far-fetched to think that the search engines might have their spiders capitilizing on well-formed XHTML documents with faster XML parsing, or are at least taking a very serious look at implementing that functionality in the near future.  If you consider even a performance improvement of only 10ms, when you multiply that against the tens of thousands of pages being spidered every day, those milliseconds add up very quickly.

Using CSS To Create Two Common HTML Border Effects

Seperating the style from the markup of a web document is generally a painless, if sometimes time-consuming, task.  In many cases however, the process can have some added speed-bumps; most notably when the original HTML is using an infamous table-based layout.  The two most common speedbumps when dealing with table-based layouts and styling are recreating the classic borderless table and keeping the default table border appearance.

The appearance of these two kinds of table are as follows 

Default Border

1 2
3 4

Borderless

1 2
3 4

The markup for these two tables looks like:

[code:html]

<!--Default Border -->
<table border="1">
<tbody>
<tr>
<td>1</td>
<td>2</td>
</tr>
<tr>
<td>3</td>
<td>4</td>
</tr>
</tbody>
</table>
<!-- Borderless -->
<table border="0" cellspacing="0" cellpadding="0">
<tbody>
<tr>
<td>1</td>
<td>2</td>
</tr>
<tr>
<td>3</td>
<td>4</td>
</tr>
</tbody>
</table>

[/code]

If you want to get the same effects while losing the HTML attributes you can use the folllow CSS:

Default Border

[code:html]

table{border-spacing:0px;border:solid 1px #8D8D8D;width:130px;}
table td{
border:solid 1px #C0C0C0;
border-bottom:solid 1px #8D8D8D;
border-left:solid 1px #8D8D8D;
display:table-cell;
margin:0;
padding:0;}

[/code]


Borderless

[code:html]

table{border:none;border-collapse:collapse;}
table td{padding:0;margin:0;}

[/code]

Duplicating the default table border look requires extra rules in its style definition because the default border contains two shades so the border-color values must be set accordingly. 

That is the basic method to replicating HTML table effects with CSS that are usually created with HTML attributes.

A Code Snippet That Speaks For Itself

While working on a client's site today I came across this gem that I thought you might enjoy.  I'll let the snippet speak for itself.

[code:html]

<script type="text/javascript">
document.write('<');
document.write('!--  ');
</script>
&lt;!--   
<noscript> 
(Removed to protect anonymity of client)
</noscript> 
<!--//-->  

[/code]

*Smacks Forehead*

7 Firefox Add Ons For Web Developers

Firefox add-ons can be one of the best set of tools a web developer can have but with so many out there it can be hard to decide on which ones are the best for you.  I was reluctant to post this at first, given the countless other blogs out their who have posted their own add-on lists, but felt this would be of value for those looking for recommendations that weren't posted 2-3 years ago.  I avoided going for the "Top 841 Add Ons Every Web Developer Must Have!!!!" angle, as this isn't a top list.  It's simply a list of my personal favourites because, as a guy who's known around the office for having too many add-ons installed for Firefox, I've definitely used a lot of add-ons, some which were fanstastic, and some which left something to be desired.  Over time I managed to pare down my pile of add-ons in to a core set that all save me a considerable amount of time, and also share the same basic qualities:

  1. Easy to Use
  2. Not Obtrusive
  3. Light-Weight
  4. Accurate

Ease of use is important to saving time (an add-on isn't going to increase productivity if it takes just as long to figure out how to use it, configure it, or even just to use it).  Not being obtrusive is important because I want my add-ons to be un-noticable other than a toolbar or icon unless I actively want to utlilize it, and this ties in with being light-weight, as a light-weight add-on is not going to cause any decreases in performance.  Finally, accuracy is imperitive because I have to be able to trust what information the add-on is providing me with.

With those qualities explained, I'll get on to the list.

1) Firebug

For web development and/or design if you are going to install one add-on, this is the one.  Firebug lets you view, edit, debug and monitor HTML, CSS and JavaScript live on any web page.  I use Firebug extensively every day to test layout changes before I make them, to debug script errors, navigate through a page's markup with ease, monitor all the HTTP requests made for a given page, and more.  It also has some incredibly useful features like a diagram that shows all the measurements for dimension, margin, padding, border, etc... for a selected element, a list of applied styles for a selected element, and the "inspect" feature that lets you simply click on the part of a web page you want to analyze and have Firebug automatically get all the details on it for you.

 



2) Web Developer

Web Developer is an add-on that provides a toolbar and menu that gives you access to a host of different development tools.  Just one of the 12 toolbar buttons gives you the following options:



There are tons of other useful tools included with Web Developer, including some of my personal favourites:

  • Outline different HTML elements (with ability to display element type and custom outline colour)
  • Show/hide/outline images with oversized dimensions, missing alt attributes, adjusted dimensions, missing dimensions, etc
  • Show image paths, alt and title attributes, sizes
  • Disable javascript
  • Disable CSS styles (external, interal, inline, etc..) 

3) Greasemonkey

One of the most popular add-ons out there, Greasemonkey simply lets you run custom JavaScript against any page you want.  There are thousands of Greasemonkey scripts out there for those who don't want to create their own, offering enhancements such as numbering search results in Google, MSN and Yahoo, killing pop-up ads, and pretty much anything else you could think of.

4) HTML Validator

A must have if you care about W3C validation.  HTML Validator displays an icon in the bottom of your browser indicating if the current page validates against its DOCTYPE, as well as the number of errors and warnings.  You can configure the validation method it uses (HTML Tidy, or SGML which is used by the W3C Markup Validation Service), and it also displays a list of errors and highlights them in when you view the page's source.

5) MeasureIt

Simple and easy-to use, MeasureIt is an add-on that, when activated, displays an overlay where you can drag and position a dynamic ruler so you can measure dimensions on a web page.



6) Session Manager

Session Manager is an incredibly useful add-on that tracks your Firefox sessions and allows you reload older sessions or recover a crashed session.  If you're like me and usually have the same websites opened in different tabs, this add-on will make your life a lot easier.

7) QuickRestart

QuickRestart is a simple and convenient add-on that simply adds a button to your toolbar that restarts Firefox, just like when you install an add-on or upgrade.

Hopefully you will find these add-ons as useful as I have.  I'll also be posting a list of useful add-ons for Internet Explorer later this week as well.  I encourage everyone to comment with your own recommendations for Firefox add-ons that you find useful for web development.

 

Visual Studio 2008 Initial Impressions - Part One

The release of Visual Studio 2008 and the .NET Framework 3.5 this past Monday has created a considerable buzz in the .NET community.  With language enhancements such as LINQ (Language Integrated Query) and lambda expressions as well as a plethora of refinements to the IDE itself there are a lot of new tools available at our disposal now.  I was very eager to get acquainted with these new tools so I installed a copy of Team Edition and spent almost every free moment this week familiarizing myself with them.  Here are some of my initial impressions.

1) LINQ To SQL Classes

I work with a lot of applications that depend heavily on a backend database, so I've coded my fair share of business logic layers which can be quite tedious.  LINQ To SQL Classes take a lot of the grunt work out of that process by providing a convenient visual designer that performs automatic object-relational mapping.  All you have to do is drag a table or stored procedure from the Server Explorer to the design window and the designer automatically creates a strongly-typed object or method that is ready for use in your application.




2) Intellisense Enhancements

There were a couple of really nice usability enhancements to Intellisense in Visual Studio 2008.  Now, as you type, the Intellisense list automatically filters the list down based on what you've entered in so far.  For instance, if you have entered "MyObject.ToS" the list would be filtered to only show the items that start with "ToS", which does a nice job of speeding things up.  The other enhancement addresses the issue that many people had with previous versions of Visual Studio and the way that the Intellisense list would often obscure chunks of your code, forcing you to close the window if you had to check something that was underneath it.  Now you just have to hit "Ctrl" while the list is open and it will become semi-transparant, allowing you to see the code underneath.

 



3) Improved IDE Performance

Not a "feature", necessarily, but a welcome improvement to Visual Studio.  You'll notice this as soon as you load the environment for the first time and discover how quickly the environment loads.  The performance improvements don't stop there either, as the IDE is a lot faster and responsive throughout.


Stay tuned for Part Two where I'll go in to some more features of LINQ as well as some of the language upgrades given to Visual Basic.

Reducing Code Bloat - Or How To Cut Your HTML Size In Half

When it comes to designing and developing a web site the load time is one consideration that is often ignored, or is an afterthought once the majority of the design and structure is in place.  While high-speed internet connections are becoming increasingly common there are still a significant portion of web users out there with 56k connections, and even those with broadband connections aren't guaranteed to have a fast connection to your particular server.  Every second that a user has to wait to download your content is increasing the chance of that user deciding to move on.

Attempting to reduce the size of a web page is usually restricted to compressing larger images and optimizing them for web use.  This is a necessary step to managing page size, but there is another important factor that can significantly reduce the size of a page to improve download times: code bloat, or more specifically, (x)HTML code bloat.  Getting rid of that code bloat means less actual bytes to be downloaded by clients, as well as captilizing on what the client has already downloaded.  Unfortunately this is an option that tends to be ignored due to the perceived loss of time spent combing through markup to cut out the chaff, despite the fact that clean, efficient markup with well-planned style definitions will save countless hours when it comes to upkeep and maintenance.

To demonstrate the difference between a bloated page and one with efficient markup I created two basic pages.  One uses tables, font tags, HTML style attributes and so forth to control the structure and look of the page, while the other uses minimal markup with an external stylesheet.

1) Bloated Page

[code:html]

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>This Tag Soup Is Really Thick</title>
<meta name="description" content="The end result of lazy web page design resulting in a bloated mess of HTML.">
<meta name="keywords" content="tag soup, messy html, bloated html">
</head>
<body>
<center>
  <table width=700 height=800 bgcolor="gainsboro" border=0 cellpadding=0 cellspacing=0>
    <tr>
      <td valign=top width=150><table align=center border=0 cellpadding=0 cellspacing=0>
          <tr>
            <td align="left"><a href="#home" title="Not a real link"><font color="#4FB322" size="3" face="Geneva, Arial, Helvetica, sans-serif">Home Page</font></a></td>
          </tr>
          <tr>
            <td align="left"><a href="#about" title="Not a real link"><font color="#4FB322" size="3" face="Geneva, Arial, Helvetica, sans-serif">About Me</font></a></td>
          </tr>
          <tr>
            <td align="left"><a href="#links" title="Not a real link"><font color="#4FB322" size="3" face="Geneva, Arial, Helvetica, sans-serif">Links</font></a></td>
          </tr>
        </table></td>
      <td valign=top><table>
          <tr>
            <td align="center" height=64><h1><font color="red" face="Geneva, Arial, Helvetica, sans-serif">Welcome to My Site!</font></h1></td>
          </tr>
          <tr>
            <td align="left"><font color="#FFFFFF" size="3" face="Geneva, Arial, Helvetica, sans-serif">Isn&acute;t it surprisingly ugly and bland?</font></td>
          </tr>
          <tr>
            <td align="left"><font color="#FFFFFF" size="3" face="Geneva, Arial, Helvetica, sans-serif">Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Fusce est. Maecenas pharetra nibh vel turpis molestie gravida. Integer convallis odio eu nulla. Vivamus eget turpis eu neque dignissim dignissim. Fusce vel erat ut turpis pharetra molestie. Cras sollicitudin consequat sem. Vestibulum ante ipsum primis in faucibus orci luctus et ultrices posuere cubilia Curae; Maecenas augue diam, sagittis eget, cursus at, vulputate at, nisl. Etiam scelerisque molestie nibh. Suspendisse ornare dignissim enim. Sed posuere nunc a lectus. Vestibulum luctus, nibh feugiat convallis ornare, lorem neque volutpat risus, a dapibus odio justo at erat. Donec vel lacus id urna luctus tincidunt. Morbi nunc. Donec fringilla sapien nec lectus. Duis at felis a leo porta tempor.</font></td>
          </tr>
          <tr>
            <td align="left"><font color="#FFFFFF" size="3" face="Geneva, Arial, Helvetica, sans-serif">Maecenas malesuada felis id mauris. Ut nibh eros, vestibulum nec, ornare sollicitudin, hendrerit et, ligula. Suspendisse tellus elit, rutrum ut, tempor eget, porta bibendum, magna. Nunc sem dolor, pharetra ut, fermentum in, consequat vitae, velit. Vestibulum in ipsum. Phasellus erat. Sed eget turpis tristique eros cursus gravida. Vestibulum quis pede a libero elementum varius. Nullam feugiat accumsan enim. Aenean nec mi. Vestibulum ante ipsum primis in faucibus orci luctus et ultrices posuere cubilia Curae;</font></td>
          </tr>
          <tr>
            <td align="left"><font color="#FFFFFF" size="3" face="Geneva, Arial, Helvetica, sans-serif">Aenean vel neque ac orci sagittis tristique. Phasellus cursus quam a mauris. Donec posuere pede a nisl. Curabitur nec ligula eu nibh accumsan sagittis. Integer lacinia. Class aptent taciti sociosqu ad litora torquent per conubia nostra, per inceptos hymenaeos. Praesent tortor dolor, pellentesque eget, fermentum vel, mollis ut, erat. Nullam mollis. Cras rhoncus tellus ut neque. Pellentesque sed ante.</font></td>
          </tr>
          <tr align="left">
            <td><font color="#FFFFFF" size="3" face="Geneva, Arial, Helvetica, sans-serif">Donec at nunc. Nulla elementum porta elit. Donec bibendum. Fusce elit ligula, gravida et, tincidunt et, aliquam sit amet, metus. Nulla id magna. Fusce quis eros. Sed eget justo. Vivamus dictum interdum quam. Curabitur malesuada. Proin id metus. Curabitur feugiat. Nunc in turpis. Cras lobortis lobortis felis. Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas. Mauris imperdiet aliquet ante. Lorem ipsum dolor sit amet, consectetuer adipiscing elit.</font></td>
          </tr>
          <tr align="left">
            <td><font color="#FFFFFF" size="3" face="Geneva, Arial, Helvetica, sans-serif">Etiam tristique mauris at nibh sodales pretium. In lorem eros, laoreet eget, rhoncus et, lacinia nec, pede. Fusce a quam. Pellentesque vitae lacus. Vivamus commodo. Morbi euismod, ipsum id consectetuer ornare, nisi sem suscipit pede, vel dictum purus mauris eu leo. Proin sodales. Aliquam in pede nec eros aliquet adipiscing. Nulla a purus sed risus ullamcorper tempus. Nunc neque magna, fringilla quis, ullamcorper vitae, placerat sed, orci. Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas. Vestibulum ante ipsum primis in faucibus orci luctus et ultrices posuere cubilia Curae;</font></td>
          </tr>
        </table></td>
    </tr>
  </table>
</center>
</body>
</html>

[/code]

2) Cleaned Page

[code:html]

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
    <title>Less Markup, More Content</title>
    <meta name="description" content="The end result of lazy web page design resulting in a bloated mess of HTML.">
    <meta name="keywords" content="tag soup, messy html, bloated html">
    <link href="style.css" rel="stylesheet" type="text/css">
  </head>
  <body>
    <div class="content">
      <ul class="menu">
        <li><a href="#home" title="Not a real link">Home Page</a></li>
        <li><a href="#home" title="Not a real link">About Me</a></li>
        <li><a href="#home" title="Not a real link">Links</a></li>
      </ul>
      <h1>Welcome To My Site!</h1>
      <p>Isn&acute;t it suprisingly ugly and bland?</p>
      <p>Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Fusce est.  Maecenas pharetra nibh vel turpis molestie gravida. Integer convallis  odio eu nulla. Vivamus eget turpis eu neque dignissim dignissim. Fusce  vel erat ut turpis pharetra molestie. Cras sollicitudin consequat sem.  Vestibulum ante ipsum primis in faucibus orci luctus et ultrices  posuere cubiliaCurae; Maecenas augue diam, sagittis eget, cursus at,  vulputate at, nisl. Etiam scelerisque molestie nibh. Suspendisse ornare  dignissim enim. Sed posuere nunc a lectus. Vestibulum luctus, nibh  feugiat convallis ornare, lorem neque volutpat risus, a dapibus odio  justo at erat. Donec vel lacus id urna luctus tincidunt. Morbi nunc.  Donec fringilla sapien nec lectus. Duis at felis a leo porta tempor. </p>
      <p>Maecenas malesuada felis id mauris. Ut nibh eros, vestibulum nec,  ornare sollicitudin, hendrerit et, ligula. Suspendisse tellus elit,  rutrum ut, tempor eget, porta bibendum, magna. Nunc sem dolor, pharetra  ut, fermentum in, consequat vitae, velit. Vestibulum in ipsum.  Phasellus erat. Sed eget turpis tristique eros cursus gravida.  Vestibulum quis pede a libero elementum varius. Nullam feugiat accumsan  enim. Aenean nec mi. Vestibulum ante ipsum primis in faucibus orci  luctus et ultrices posuere cubilia Curae; </p>
      <p>Aenean vel neque ac orci sagittis tristique. Phasellus cursus quam a  mauris. Donec posuere pede a nisl. Curabitur nec ligula eu nibh  accumsan sagittis. Integer lacinia. Class aptent taciti sociosqu ad  litora torquent per conubia nostra, per inceptos hymenaeos. Praesent  tortor dolor, pellentesque eget, fermentum vel, mollis ut, erat. Nullam  mollis. Cras rhoncus tellus ut neque. Pellentesque sed ante. </p>
      <p>Donec at nunc. Nulla elementum porta elit. Donec bibendum. Fusce  elit ligula, gravida et, tincidunt et, aliquam sit amet, metus. Nulla  id magna. Fusce quis eros. Sed eget justo. Vivamus dictum interdum  quam. Curabitur malesuada. Proin id metus. Curabitur feugiat. Nunc in  turpis. Cras lobortis lobortis felis. Pellentesque habitant morbi  tristique senectus et netus et malesuada fames ac turpis egestas.  Mauris imperdiet aliquet ante. Lorem ipsum dolor sit amet, consectetuer  adipiscing elit. </p>
      <p>Etiam tristique mauris at nibh sodales pretium. In lorem eros,  laoreet eget, rhoncus et, lacinia nec, pede. Fusce a quam. Pellentesque  vitae lacus. Vivamus commodo. Morbi euismod, ipsum id consectetuer  ornare, nisi sem suscipit pede, vel dictum purus mauris eu leo. Proin  sodales. Aliquam in pede nec eros aliquet adipiscing. Nulla a purus sed  risus ullamcorper tempus. Nunc neque magna, fringilla quis, ullamcorper  vitae, placerat sed, orci. Pellentesque habitant morbi tristique  senectus et netus et malesuada fames ac turpis egestas. Vestibulum ante  ipsum primis in faucibus orci luctus et ultrices posuere cubilia Curae; </p>
    </div>
  </body>
</html>

[/code]

External Style Sheet

[code:html]

@charset "utf-8";
body{font:13pt Geneva, Arial, Helvetica, sans-serif;}
.menu{float:left;height:800px;list-style-type:none;width:150px;}
.menu a, .menu a:visited{color:#4FB322;}
.content{background:gainsboro;color:white;margin:auto;position:relative;width:700px;}
h1{color:red;line-height:64px;text-align:center;}
p{margin:4px;}

[/code]

Even in this basic example you can see a fairly dramatic improvement when the excess HTML is trimmed and CSS is used to control style.  The original page is 51 lines, where the cleaned page is only 26 lines, plus 7 lines in the style sheet.  The cleaned page is a third the size of the original (counting the style sheet), and more realistically is actually half the size because the style sheet would be cached by most client browsers and wouldn't be downloaded for every page request.  As far as raw kilobytes it's a difference of 6KB to 4KB, which isn't a particularly exciting difference in this case, but one that is quickly magnified as the length of the page increases.  This is especially true with dynamic applications that pull content from a database, most importantly content such as product listings that utilize the same markup and are repeated multiple times. Fortunately in the case of dynamic pages involving looping procedures that output the same markup with different content, cutting down the bloat can be as easy as a few modifications to those procedures.

Furthermore if you wanted to change, for instance, the font color or the line-height in the original, you would have to modify every font tag and table cell to accomplish that.  Implementing those changes in the second example requires a single modification to the style-sheet.  The time-saved here is once again significantly amplified when considered in a situation with multiple pages (in many cases this can be hundreds or even thousands).

When all is said and done, this isn't meant to be a be-all end-all guide for optimizing your markup because I could write a book and still not cover it all.  Rather it was meant to highlight an aspect of web page performance and optimization that is usually swept under the rug in favour of those that are more directly appreciable such as eye-candy and new features.  While clean markup might not be as "glamourous" as other aspects of web development, it is an important aspect to keeping load time in check and a crucial factor in reducing them amount of time spent maintaining and updating.

Disabling Configuration Inheritance For ASP.NET Child Applications

Configuration inheritance is a very robust feature of ASP.NET that allows you to set configuration settings in the Web.Config of a parent application and have it automatically be applied to all of its child applications.  There are certain situations, however, when there are configuration settings that you don't want to apply to a child application.  The usual course of action is to override the setting in question in the child application's web.config file, which is ideal if there are only a handful of settings to deal with.  This is less than ideal when there are a significant number of settings that need to be overridden, or when you simply want the child application to be largely independent of its parent. 

There solution is Configuration <location> Settings which allows you to selectively exclude portions of an application's web.config from being inherited by child applications.  This made my job a heck of a lot easier yesterday in the installation of BlogEngine.NET for a client that had a CMS.  Naturally the CMS had a rather lengthy web.config packed with a significant amount of settings that were specific to the CMS application, and would generally break any child application that someone would install. Naturally the installation of the blog application was no exception, as I quickly found out there were at least 20 various settings that were preventing it from running.  I had the blog application configured as a seperate application through a virtual directory that was a subdirectory of the main website application (which included the CMS), so by default ASP.NET was applying all the settings the the main application to the blog application.  

The prospect of digging through the large web.config of the CMS and identifying every setting that I would need to override was not a prospect I was particularly thrilled about, so I turned to the <location> element to save me some time.  Since the blog application was essentially independent of the main application there were no inherited settings that it would depend on, so I modified the parent web application's web.config to the following (edited to protect client).

[code:xml]

<location path="." inheritInChildApplications="false"> 
  <system.web>
  ...
  </system.web>
</location> 

[/code]

By wrapping the <system.web> element with the <location> element and setting the path attribute to "." and inheritInChildApplications attribute to "false" I prevented every child application of the main web application from inheriting the settings in the <system.web> element.  After making this modification I tried accessing the blog and just like that there were no more errors and it loaded perfectly.  I could have also set the <location> element to apply specifically for the blog by way of the path attribute if I didn't want to disable inheritance across every child application.  

Aside from the convenience that configuration <location> settings provided in this case, it is also a tremendously powerful way to manage configuration inheritance in your ASP.NET applications.  If you haven't read the MSDN Documentation on this topic, I really encourage you to do so, because there are so many scenarios that configuration <location> settings can be used that you will quickly discover that it is a incredibly valuable tool to have at your disposal. 

Google Cracks Down On Sites That Are Losing Importance

There has been a lot of controversy in the world of SEO as of late, mostly centering around the PageRank penalties that Google has been handing out to enforce their paid-link policies.  The members of the SEO community, who do enjoy to voice their opinion from time to time, increased the size of Google's index by about 2.3% blogging about it (just kidding! I love the SEO community).  As more updates to the Toolbar PageRank happened over the weeks, more disgruntled SEOs, webmasters and site owner's came out of the woodwork to express their outrage at Google for decreasing the Toolbar PageRank of their site. 

This outrage was in the form of more blogging which, inevitably, a lot of people were reading.  For a while you would be hard-pressed to find someone who wasn't writing about the latest Google PageRank Massacre.  PageRank was on everyone's mind. 

Those of us, such as myself, who pay little attention to the little green bar sat back and watched, interested in the developments regarding Google's policies and the paid-link debate.  We would sift through post after post of someone denouncing Google because their Toolbar PageRank dropped from a 3 to a 2, loudly proclaiming that they shouldn't be penalized for the 2 paid links they have when the site around the corner has nothing but paid links and cloaked text.  

As more and more people shared their tragic stories of their little green bar shrinking I started to notice that something was missing in the SEO blog community.  No-one was complaining about their ranking positions anymore, wondering how their site could not possibly be in the top then when they had a 900 characters in their meta keywords tag and was positioning a div full of keywords at -9999px to the left.  Suddenly it appeared that everyone had a perfectly optimized site with an abundance of high-value, relevant backlinks with content so useful and compelling that bounce rate was a thing of the past.  But these sites were losing Toolbar PageRank, and since they were shining beacons of optimized perfection the only explanation is that they were casualties of the PageRank Massacre.

Give me a break.

I'm going to kill the sarcasm now and get to the point now.  Here are some things that you might want to consider if you are thinking you got slapped by the latest Google crackdown:

1) Does Your Site Actually Have Paid Links?

Surprisingly there are people out there who are complaining about Google penalizing them in a PageRank Massacre when their sites don't actually have any paid links, or anything that even looks like a paid link.  Whether its a cheap ploy to draw some worthless traffic or just a desire to be part of the group, it make you look foolish.

2)  PageRank Can In Fact Decrease

Take a deep breath on this one and repeat after me: "My PageRank is not guaranteed to go up on every update".  PageRank is a relative value and if your site is not keeping up with the rest of the herd your PageRank will decrease.  This is growing more prominent every day as the level of competition continues to increase with more sites actually making an effort in SEO.

3) Stop Making Excuses

Unless you are in minority of sites that were actually penalized without cause, step back and take a good, honest look at the state of your website.  Do you have quality content, user-friendly navigation, optimized titles and descriptions?  Is it really so perfectly optimized that the only possible explanation is Google's ire?

My point here, if somewhat longwinded, is that it is easy to hop on the "Google screwed me" bandwagon when your site doesn't perform to your expectations.  It takes a little more honesty and willingess to improve yourself, and your site, to recognize areas that need improvement and work on those.  When it comes down to it, whether you got smacked with a PageRank penalty or simply fell behind the rest of the pack the best thing you can do is roll up your sleeves and get back to work.  The time will always be much better spent and your site and your site's visitors will benefit because of it.