Optimizing the Head of Your HTML Document

I don’t know if it goes without saying, or if it simply remains unsaid, because it is automated, but orderly HTML is still important even in this CMS age that we live. I am going to re-consider the order of a well-formed document here. I intend for this to be a somewhat ‘opinionated’ document. It may not be a perfectly standards-based approach, but my version of an optimal solution with some assumptions and likely caveats (one among them is that our purpose is to optimize for speed with a mind to ‘organic SEO’¹). And it is likely to be a work in progress. So, here goes nothing….

A funny thing happened on the way to writing this article. I had meant to do some research to make sure that I was writing the head of my html documents optimally. However, along the way I found many questions too. So on the Webmaster Stack Exchange site, I answered my own question (or a fair approximation of it). And what follows is an embellished version of the same.


First things first, while the focus of the document is the head, I am still going to address the foregoing doctype declaration and the opening of the html tag. Here is the new highly-effective, and equally brief doctype declaration:

<!doctype html>

Next, the HTML tag. It is important to declare the language (and I personally prefer to further declare the region). English and Spanish are both regions with a number of variants.

<html lang="en-US">

It is a good idea to order your page’s head roughly thus (presuming HTML5 for syntax):

    <head>

So far in the document, you should have only used ASCII² characters, so character encoding is not an issue yet. But the likelihood of using non-ASCII characters goes up markedly once you open that head tag. Accordingly, you should make the next statement your character-encoding declaration³. This also satisfies parsers/browsers/agents that would be sniffing for character encoding statements:

      <meta charset=“utf-8”>

For those of you that may be reasonably concerned that that doesn’t look like the tried and true meta tag of yore (e.g. <meta http-equiv=”Content-Type” content=”text/html; charset=iso-8859-1″> shudder), it is both correct in accordance with the HTML5 specification, and thoroughly-tested and proven cross-browser for some time now to be effective, notwithstanding its off-putting brevity.

I am not going to spell the following out in this document, because I lack the credentials. At this point, I will let it suffice to say that it is the assertion of the good folks in Bootstrap land (as recently as version 3.3.4) that we put those two meta declarations before the title also. I will assume at this point that they are relatively easy to process, and are unlikely to inhibit a browsers ability to rapidly display a title element, while simultaneously offering some very important information that the waiting user agent (usually a browser) would like to get its grubby little mitts on in short order.

      <meta http-equiv=“X-UA-Compatible” content=“IE=edge”>

If you are thinking about device-agnostic design/development (inclusive of smaller, non-desktop user agents), you should include the following:

      <meta name=“viewport” content=“width=device-width, initial-scale=1”>

Finally, the title. But first some unsolicited advice, because, why else would you be reading my blog? Given all the things that a title can be used for, places that it may be stored, and modes through which it may be transmitted, it may be wise to avoid the use of non-ASCII characters in the title. For instance if you use a Gmail extension or bookmarklet to pass a page (and content) to another page, the receiving page may not handle those decoded characters well. Similarly, if you use a Twitter-y add-on to send a tweet of a link to a page where the page’s title is passed, those tweets may be consumed by a device that doesn’t like right [double] angle quotes (i.e. “»”) or maybe (for all of its style) those em dashes or middle dots (“—” and “·” respectively) cause your well-intentioned browser to go klunk. You get the idea. Like I tell my kids, “Do what you can afford”:

      <title>Ingenious Page Title</title>

Next, you offer the CSS as soon after the title as possible (no ‘daylight’ between them):

      <link rel=“stylesheet” href=“stylesheet-1.css”>
      <link rel=“stylesheet” href=“stylesheet-2.css”>

If you are using page-level styles, they would go here. This is largely because of the ‘cascading’ nature of CSS: namely the last style declaration of identical levels of specificity (such as two statements that target a paragraph p). In order to make overriding external styles easier (i.e. without using greater specificity, or !important), you should put page-level styles after external styles (<link>s). Also, it is generally inadvisable to use the @import directive in page-level styles, because it will impede the concurrent downloading of other style assets:

      <style>body{color:black;}</style>

This is the point where it seems most appropriate to put meta tags, favicons, and other cruft. It is arguable that favicons or similar assets (e.g. iOS app images) would be loaded before most meta tags, because it gets the downloading of those assets started marginally sooner.

      <link rel=“shortcut icon” href=“favicon.ico”>
      <link rel=“apple-touch-icon” href=“apple-icon.png”>
      <meta name=“description” content=“Some information that is descriptive of the content”>
      <meta name=“generator” content=“Microsoft FrontPage 2002”>

Because it blocks/delays rendering, if you intend to require scripts, load them as late as is reasonable. If they must be in the head, you might load them before the close of the head (</head>). If you can load them later, put them before the close of the body tag (</body>).

      <script src=“script-1.js”></script>
      <script src=“script-2.js”></script>
    </head>

It seems unimportant in most cases to order your meta tags for SEO purposes, given that they are going to consume the whole page. Otherwise, how would they index a page’s content, or update that index later?

Lastly, it is notable to me that for all that we think we know, and all the recommendations that we find on the web (even from places like Google and Bing Webmaster Tools, etc.), sites like Amazon, Google and other folks who clearly care about such minuscule performance gains don’t follow these rules.


Footnotes:

¹Organic SEO – that ‘search engine optimization’ that grows naturally out of good content and the reasonable application of best practices, rather than the stilted and purposeful implementation of strange non-intuitive, measures whose only end is to “bubble up” in a search engine’s ranking.

²ASCII is the 7-bit/128-character set which includes all Roman/Latin/English letter characters in the upper-case (A-Z) and lower-case (a-z), Arabic numerals (0-9), special characters (˽!”#$%&'()*,-./:;<=>?@[\]^_`{|}~), and some special non-printing characters which include things like NULL, DEL, TAB, etc.

³This of course assumes that you have not declared the character set in a ‘header’ or using your server, similar to any of the following Apache httpd directives …

  • AddDefaultCharset UTF-8
  • AddCharset UTF-8 .js
  • AddType 'application/javascript; charset=UTF-8' js*

Some Thoughts on “How Google Works”

I have been reading “How Google works” by Eric Schmidt (CEO) and Jonathan Rosenberg (SVP Products). Working in a tech company, I find many of the insights valuable. It is (as the title may suggest) written for managers more than in-the-trench developers, etc. Notwithstanding that, it is a valuable book for most anyone in the field. This is not a review. It is a gleaning of thoughts from the book. These are some of the things that seemed important enough to me that I should take notes on it. So, what follows are some highlights.

As a quick note, you can find this book on Audible. And here is a link to get two free books on Audible. I am not getting a commission for either of those. But when I found the two book deal, I almost kicked myself, because I had just started using Audible in the previous month. Anyway, … Continue reading Some Thoughts on “How Google Works”

Nothing to Hide? Why Encrypt?

My daughter asked me earlier this year, “Papa, if you aren’t doing anything wrong, why do you want to obfuscate your email traffic?”

Actually, I am sure that she did not say obfuscate, but her point is the same: If you are not doing anything wrong, why would you want to hide the contents of your online interactions? So, I did what any good dad would do, I answered her question with a question:

Continue reading Nothing to Hide? Why Encrypt?

Sublime Text Preferences

~/Library/Application Support/Sublime Text 2/Packages/User/Plain Text.sublime-settings

{
  "tab_size": 5,
  "translate_tabs_to_spaces": false
}

~/Library/Application Support/Sublime Text 2/Packages/User/Preferences.sublime-settings

{
  "color_scheme": "Packages/Color Scheme - Default/Monokai.tmTheme",
  "default_line_ending": "unix",
  "font_size": 12.0,
  "ignored_packages":
  [
    "Vintage",
  ],
  "rulers":
  [
    80
  ],
  "show_full_path": true,
  "tab_size": 2,
  "word_wrap": true,
  "translate_tabs_to_spaces": true,
  "draw_white_space": "all"
}

Mac Screenshot Destination Changed

A co-worker showed me that (on the Mac) you can move the destination of screenshots (e.g. ⇧+⌘+4) from the desktop to another location. I am going to touch on a number of things all at once in pursuit of doing this very thing:

  1. make some assumptions
  2. create a new screenshots directory in a hosted storage solution
  3. link to that directory using a symlink (symbolic link [ln -s])
  4. change the default OS behavior to push the files out to that hosted storage directory
  5. follow up with housekeeping and related information

1. We will first assume that you are using a hosted storage solution like Google Drive. Some other options might include OwnCloud, DropBox, Copy, or Cubby.

2. Let’s create a new directory in Google Drive for your images (~/Google\ Drive/Pictures/screenshots). In terminal, enter the following:

cd ~/Google\ Drive
mkdir Pictures
cd Pictures
mkdir screenshots

3. At this point, let’s create a symlink (symbolic link) to screenshots:

ln -s ~/Google\ Drive/Pictures/screenshots ~/Pictures/screenshots

4. Now, let’s change the behavior of Mac OS X to write those screenshots to that new location in your hosted storage (or wherever else you determined to do it):

defaults write com.apple.screencapture location ~/Google\ Drive/Pictures/screenshots/

4.1. And in order to get the behavior to kick in, kill the SystemUIServer:

killall SystemUIServer

5.1. ⇧+⌘+4 or ⇧+⌘+⌃+4 will do a selective/partial capture. But pushing the space bar afterward (⇧+⌘+4,˽ or ⇧+⌘+⌃+4,˽) will allow you to select a single window (like alt+PrtScrn in Windows).

Additionally, there is much more about screenshot capture tweaking on TekRevue. It includes things like disabling the default drop shadow, renaming the files and changing the file format.

Vintage Mode in Sublime Text

While using Sublime a co-worker and I were talking about using ‘vintage’ mode in Sublime and its shortcomings on Mac. Namely two: it starts in edit mode, and it does not support key repeat (e.g. kdoesn’t move your cursor up the page more than once per key depress).

So, in case you aren’t there already, you can get into vintage mode thus: modify your User Preferences file (⌘+,) commenting out the “Vintage” line in the ignored_packages object:

"ignored_packages":
  [
    // "Vintage"
  ],

While I haven’t solved the first problem, I found a solution for the second. In terminal, enter:

defaults write com.sublimetext.2 ApplePressAndHoldEnabled -bool false

That cat is half-skinned. I may come back to this later.