Don’t get a fat < head >

by Scott O'Hara

While I was in the process of writing a version of this article, Josh Buchea’s HEAD github repo was released. For those that haven’t seen it, it’s an exhaustive list (that’s still growing due to community contribution) of the types of metadata and other elements that might appear within a web document’s <head>.

The list is excellent and you should definitely check it out, but before you start thinking you need to hurry up and check your documents to ensure you’ve included all possible metadata under the sun, you should be aware that the inherit value of many of these elements may range from absolutely nonexistent to situationally useful, depending on an individual project’s needs.

Working with Buchea and another contributor, Lucas, we have started to separate the metadata elements by their usefulness, but there’s only so much detail one can go into in a README document that is largely meant to be a straightforward listing of elements. Such a list is not conducive to longform explanations on what value these elements actually provide your documents (or don’t).

Getting your <head> on straight

To get us going, let’s simply start with the purpose of the <head> element, and define the minimal starting metadata that every document should adhere to (also, I will stop making horrible head puns. sorry, sort of).

The <head> element is meant to be the first of only two children to the <html> element, with the second being <body>. The primary function of a document’s <head> is to provide general information (metadata) about the document, while also establishing links to external resources that may provide additional metadata, or instructions for browsers or other third party tools to render or parse its contents.

The permitted elements allowed inside of the <head> include:

  • <title> – typically provides the document’s page/site title. This is a required element for properly valid HTML documents, and there can be only one title declared per document.
  • <meta> – provides additional information about the document to browsers, 3rd party tools and search engines. These elements are typically distinguished from each other by their name and content attribute values.
  • <link> – used to pull in page resources like style sheets, or to provide connections to external files that expand context about the current document. While <link>s may create additional HTTP requests for your document, they may also be used to prefetch additional assets or entire pages of your site. This may increase the initial page’s load time, but has the potential to significantly help the load time of prefetched pages of your site.
  • <style> – a place to declare CSS within the HTML document. There can be multiple <style> instances in a document’s <head> and should be considered as an extension of an external stylesheet’s cascade. Keep this in mind if using CSS within a <style> element to overwrite selectors in an external stylesheet.  The inline CSS needs to be placed after the <link rel=”stylesheet”>.
  • <base> – used to specify the base URL for all relative URLs contained within the document. There can only be a single <base> declared in a document’s <head> and it should be noted that there are some gotchas to be aware of when using <base>.
  • <script> & <noscript> – serves as a means to include scripts (JavaScripts) and fallback solutions for a document. It’s typically best practice when using scripts in your <head> to do so as short inline scripts to cut down on HTTP requests, or to async load them to help prevent the blocking content further down the DOM from loading.

Setting a standard

Now that we’ve nailed down the types of elements we can expect to see in our document’s <head>, let’s take a look at how many of these elements should actually be used as a baseline for modern web documents using the HTML5 doctype:

<head>
  <meta charset="utf-8">
  <meta http-equiv="x-ua-compatible" content="ie=edge">
  <title>Page Title | Site Title</title>
  <meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no">
  <link rel="stylesheet" href="path-to/stylesheet.css">
</head>

As stated, this is only the bare minimum and 99% of the time (a fabricated percentage for dramatic effect) there will be more elements added. But let’s look at why these are the base elements that should be built upon.

  • <meta http-equiv="x-ua-compatible" content="ie=edge"> – This is important for displaying a document in ‘edge mode’ in Internet Explorer 6 through 11. This will render the document in the highest supported document mode, and help ensure that a document doesn’t get loaded in quirks mode, or a rendering mode lower than the browser’s optimal setting. Alternatively, this element can be removed if it is declared by a custom HTTP header.
  • <meta charset> – The charset metadata sets the character encoding for the page, including the <title>’s content. You need this, or you run the risk of �s popping up in your document. There can only be one meta-based character encoding declaration per document. There is debate whether this element should go before or after the above <meta http-equiv>, regardless, it needs to be declared within the first 1024 bytes of a document.
  • <meta name="viewport"> – Having the viewport meta is required for browsers to render a document appropriately on mobile browsers, based on the values set in the content attribute. While this element is supported by all modern browsers, this is actually a solution proposed by Apple and not actually a W3C standard element. Not to be alarmist, as this element is not going away any time soon, but this will be a recurring theme with a lot of meta elements, though they didn’t fair as well with adoption as viewport.
  • <link rel="stylesheet"> – Link elements are used to pull in external resources for your documents. <link> is most commonly used to pull in external style sheets, but may also be used to link to external sources of metadata, or as a means to pre-fetch pages or resources.

Just beyond the base

The next grouping of metadata elements goes beyond the minimum base that should be used to set up your documents, but you’re really going to want to include these for almost every project.

  • Favicons, Apple Touch Icons, etc. – There are a lot of declarations that can be made to include the full gamut of customized favicons, touch icons and other browser/OS specific metadata. What you should include and how you should include them should be set on a per-project basis. I would recommend you read All about Favicons and Touch icons to get a better idea of what this grouping entails and ways to implement them into your documents.
  • <meta http-equiv="cleartype" content="on"> – This meta element is mainly for Mobile IE font smoothing, and is not a valid W3C element. So, it’ll produce a validation error when this is included in the <head>. However, the inclusion of this element will make your fonts look better in some older instances of IE. So it’s more than worth it if you want to provide a legible experience for legacy users.
  • <meta name="description" content="around 150 chars"> – Descriptions should be set on a per-page basis and are designed to give search engines descriptions of the main topic of a document, so there’s no reason to include them in any document inaccessible by search engines.That said, descriptions are only given any sort of weight if they actually match the content/keywords on a page. Also, they may or may not be used in the actual rendering of search results. Over the years, search engines have given more weight to unique, relevant and authoritative content. It’d behoove you to focus on writing quality content rather than trying to concoct optimal meta descriptions.
  • <style> – Including instances of document specific, or Critical CSS in <style> elements may also have an important place in your <head>. To better understand Critical CSS and the value it can add to better performant websites, please read this Smashing Magazine article about Critical CSS.
  • <link rel="dns-prefetch" href="//exampleSite.com"> – To help reduce DNS request latency to high-latency domain names, especially on mobile browsers, links with rel=”dns-prefetch” may be used to proactively resolve these connections. Doing this can be incredibly helpful when including requests from resources hosted on external services, like Google’s CDN, jQuery, etc.

Next Steps

Now that we have a background on the <head> element and the baseline for elements that should be included within it, in our next article we’ll take a deeper look at situational metadata and how the contents of your <head> may look very different depending on the location and purpose of an individual document.

After that, we’ll take a deeper look into how all of these elements can have an effect on an individual document and overall site performance.

About Scott O'Hara

Scott O'Hara is a UX developer & designer. He loves pushing the limits of CSS, designing usable, accessible experiences for all, and teaching and writing...