Not about performance

Semantic markup isn t about performance, it s about meaning.

Let s imagine two parallel universes.

• In Dumb HTML World, there is only one tag: <thing>. How would you specify where styles should be applied? How would browsers know how to render the page? How would screen readers for the blind differentiate between headlines and text and footnotes and menu items? You d have to add all kinds of awkward attributes.
• Meanwhile, in Detailed HTML World, there are loads of names. You ve got <header> and <footer> and <article> and <caption> and <menu> and <paragraph> and <footnote>, etc. Now a user agent (a browser or screen reader) can make reasonable assumptions about how to style those, or make them interactive, or read them aloud. For example, a browser will make <button>s look clickable and will enable moving between them with the tab key, whereas if you use a <div class="button">, it won t know to do that. A screen reader might give more priority to reading the <p>s than the <aside>s.

If you want to override the user agent s default treatment of an element, or if a user agent is set to do so, it s easier to target specific kinds of content. For example:

• "My site is about jewelry, so I want list bullets to appear as diamonds."
• "My user is blind, so I should announce that there are images, offer to read the associated captions, and not bother downloading the actual image data."
• "My user doesn t care about footnotes and wants to ignore them."

The real world is somewhere between these two scenarios.

Some aspects of semantic HTML are a bit idealistic, but the principle is sound. For example, using <strong> instead of <b> conveys "this text is important" and not necessarily "this text should be bold." Maybe your user wants important text to be highlighted orange. That s up to them.

The point is, HTML is markup, which is about labeling things usefully. Semantic HTML is what all HTML should be: useful, meaningful labels.

Making your site load quickly is a different question altogether.

(See also: my answer here.)

Addendum - evolving towards semantic HTML

I think it s natural for HTML to become more semantic over time.

Back in Dumb HTML world, they d probably end up with crazy markup, like <thing type= list >, and <thing render= image >. Web coders would complain, "hey, we do this all the time. Why not just have an <image> tag? It would make our lives easier."

In the real world, people are constantly coding things like <div id= nav > and <div class= article >. So it makes sense to create new elements, like <nav> and <article> and <section>. Which is what the draft HTML5 specs would do.

Semantic code uses html elements for their given purpose. Well structured HTML will have semantic meaning for a wide range of users and user agents (browsers without style sheets, text browsers, PDAs, search engines etc.)

Benefits

The two points mentioned earlier are the basic benefits of using semantic code. If we use globally known tags, others understand without any additional effort. Any software program that uses the globally known tags will not be able to understand our page.

A working example of this is that search engines weigh keyword importance according to what they are. For example, and article title enclosed in one of the headings (h1 and its hierarchy) would get higher importance and hence visibility than spans. Semantic HTML enables effective Search Engine Optimization (SEO).

The semantic data extractor of W3C is a good demonstration of the possibilities of using Semantic HTML and software automation.

A side effect of excluding presentational information from the semantic markup is that now data and its presentation can be decoupled in implementation. Which means that you can change presentation without touching the data, or apply the presentation to multiple types of data. This is exactly what technologies like CSS and XHTML together achieve. Of course Semantic HTML is not necessary for this decoupling, but provides for by being semantic it enforces exclusion of presentational information.

http://www.seoblogger.co.uk/serps/the-benefits-of-using-semantic-code.html

semantic HTML and performance

Semantic HTML is not only using the right tags for the right purposes which obviously improves SEO, but also the separation of markup (HTML), style (CSS) and scripts (JS). The separation will not only improve maintenance, but certainly also improve download performance as you usually cache CSS/JS files. If you clutter the HTML file with all raw CSS/JS code and/or are using style instead of id or class, it would only make the HTML page unnecessarily bigger and it would take longer time to haul it in.

Clear Code is More Maintainable

Besides benefits to the user, semantic HTML makes more sense to humans: you and your colleagues.

If you were coding JavaScript, would you write functions like this?

dothething(q);
CmtFn(x);

...or like this?

loadUserData(username);
parseComments(language);

If you said #2 is better, well, the same principle applies to HTML. Labeling things clearly, indenting code properly, etc makes your code easier to maintain.

While writing semantically correct mark-up is good for organisation and management of code, and makes separation of style and code easier, I think there s a stronger motivation behind it s use.

• Semantically correct mark-up increases the likelihood of a machine (search engine / bot / screen-scraper or other type of script) being able to parse your content to assess it s purpose.

• Microformats are a logical extension to semantic markup; use of microformat standards can allow a more accurate assessment to be made.

Easier for you and other developers to know whats going on, reads better when CSS et al is not available. "Can" work better when using a screen reader so improves your accessiblity. More importantly I think is it gets you in the habit of writing better mark up which is more likely to validate without having to do too many fixes. Simply put its good practise but I would say don t get too hung up on getting 100% right all the time, brain power is better spend on other problems than arguing over weather a dl is better than a ul for a given problem etc.

Additionally, using semantic HTML will be of benefit to users of assistive technologies such as screen-readers, which may alter the pitch or gender of the reading voice to signify important information or presentational information, or emphasis. For example, if information you want to be really emphasised is marked up as <em> for exmphasis, rather than simply bolded (you can still style an <em> tag to be bolded in your CSS), a screen-reader will alter the inflection of that particular word to emphasise it.

As well as using proper separation of data and formatting making your code more efficient and more readable on-screen, using markup properly will not only signify visually that information is of a certain type, but will again benefit assistive technology users. For example if you have a list of information simply marked up as paragraphs, to someone who couldn t see the page there s no way of signifying that the information is related, whereas if your information is marked up as say and unordered list <ul> or an ordered list <ol>, visually it s easier for someone to read that information because it s clearly indented or has bullet points. For screen-reader users for example, when it comes to a list, the screen-reader will announce that the forthcoming content is a list.

It s like making use of the codeblock styling here on Stack Overflow - if you use the code formatting to highlight any code in your post, it makes it clearer for everyone to read, and shows that highlighted text is infact code. HTML s just the same.

Non-semantic markup risks being inaccessible for those with disabilities, for a start. Read Nicholas C. Zakas s recent article about this topic; I think it s a great introduction to the subject.

And bear in mind that a search engine such as Google sees your site in much the same way as the assistive technology used by a disabled person. The Googlebot neither knows nor cares that something has rounded corners and a pretty blue background, but it makes a great difference if it knows that it s an <h1> and not just any old <div>.

Many people think performance is a measure of the speed of which something executes. In Linus Torvald s presentation on git (on youtube), he argues that performance is more than that. Performance is also about usefulness. I think my car is a performance vehicle because it uses less fuel. A website that is difficult to use may be fast to download but performs its task poorly.

The argument that semantics on the web increases efficiency because CSS and js files are cached isn t a solid one. It s possible to build a website with a very small footprint that is not, at all semantic. But most of the time, if you re thoughtful and you say what you mean (semantics), then you ll probably increase general performance because you re being efficient anyway! Saying what you mean is the best answer most of the time.

A lot people believe you should never deviate from the semantic web. This particular discipline/rule should never be broken and to do so invites severe criticism or ridicule. This is hardly practical, given the wide range of situations and uses in which your application may exist. Sometimes, it is more intelligent to be flexible.

Finally, there are no absolute semantics. I would consider a table cell to be a column in some circumstances. And how different are the terms strong and bold? Can you really argue that "strong" should always be used? "Bold" has an equally clear meaning most of the time. Of course "emphasis" and "italic" are different. "Italic" is the implementation of "emphasis". If you re semantic to the extreme, you may end up spending a lot of time and effort enforcing rules and less time getting things done. Plus, you ll end up being a grump!

Hope that helps!

More predictable outcome over the different devices used to display HTML in.

Your energy can be focused on the different quirks/bugs in each of the (most commonly used for yor app) devices.

You might find that separation of your data from the presentation of your data will help your performance as a programmer. What I mean by this is that eventually you will want to display your data differently. When that day comes, you do not want to have your data mixed in with formatting. You want your data to be pure, so that all you have do do is adjust the formatting, not the data.

In terms of HTML and CSS, you want only to have to adjust the CSS, and leave the HTML alone.

As for performance of, say, whatever is rendering your HTML/CSS, proper separation of data and formatting can make your HTML smaller.

If you write semantic HTML each element of your page contains it s own meaning. It s good for search pages, for screen readers, for desktop & mobile browsers. And for you too. For example you can write styles only for tags. Check this example: awsm.css.

There are clear benefits. For instance, take a look at this piece of code: <article>Bla bla bla</article>

Now take a look the "equivalent" with HTML4: <div class="article">Bla bla bla</div>

For a machine, there is no special difference between <div> or <article>. Two different strings with no special meaning. But if you provide different tags, you can assign a different meaning to each of them, and is what is does in fact.

From the point of view of a search engine bot, a <div> tag is something that is used as a container, with no more special meaning. But if I use <article> the search engine bot can understand that inside it s going to be a piece of text with some interesing to say the people.

You can see it more clear with another tag like <aside>, where you re saying that what is within it doesn t have any relation with the rest of the document. For example, you can put ads within (the ads can be related with the content, but this use to be accidentally :))

In performance terms, I don t know if there is a big difference or if there is a difference at all, but it is not the goal that is want to be reached.

In addition to all of these answers, semantic HTML improves your search ranking (see SEO). Google and other search engines look for certain semantic pieces of your page and use them to do a lot of the ranking.