Webkrauts Logo

Webkrauts Webkrauts Schriftzug

- für mehr Qualität im Web

Over<head>

Was heutzutage alles in den head muss – Teil I

Over<head>

René Descartes sagte einmal »Denn es ist nicht genug einen guten Kopf zu haben; die Hauptsache ist ihn richtig anzuwenden«. Auch wenn Descartes nicht viel mit dem Internet anfangen konnte, gilt diese Weisheit auch für Websites. Was gehört also wirklich in einen guten Kopf einer Website?

Die Ausgangslage bei typischen Meta-Tag-Angaben sah vor zehn Jahren noch recht überschaubar aus:

  1. <head>
  2.      <title>Over&lt;head&gt; | Webkrauts</title>
  3.      <meta name="keywords" content="meta-tags, meta-attribute, head, html, suchmaschinen, seo, favicon" />
  4.      <meta name="description" content="Welche Meta-Tags gehören in den Head-Bereich einer Website?" />
  5.      <link rel="shortcut icon" href="/favicon.ico" type="image/x-icon" />
  6. </head>

Fast Forward nach 2013: Mittlerweile ist das »keywords«-Meta-Tag obsolet, es wird von keiner großen Suchmaschine mehr unterstützt, da zur Verschlagwortung der eigentliche Inhalt der Seite herangezogen wird. Bei der Description hat sich hingegen nicht viel geändert: Sie wird weiterhin von den Suchmaschinen als Beschreibung des Links genutzt. Einzig in der maximalen Länge unterscheiden sich die verschiedenen Anbieter. Hier wird eine Länge von 160 bis 200 Zeichen empfohlen.

Das Favicon

Früher genügte eine einzige Datei im ICO-Format von Windows, die ein 16×16px großes Icon enthielt, das der Browser dann bei Bookmarks zusätzlich anzeigte. Alle waren glücklich.

Heute empfiehlt es sich, ein paar Größen mehr zu unterstützen: Für die verschiedenen Systeme, Auflösungen und Funktionen werden die Seitenlängen 16, 24, 32 und 64 Pixel benötigt, die als weitere Bilder innerhalb der Favicon-Datei selbst gespeichert werden (etwa für die unten beschriebenen »Pinned Sites«).

Ein freier und guter Favicon-Generator dafür ist der X-Icon Editor. Dort kann man PNGs hochladen und sich eine ICO-Datei mit mehreren Auflösungen generieren lassen.
Moderne Browser unterstützen neben dem ICO-Format auch PNG oder GIF, allerdings macht uns hier der Internet Explorer einen Strich durch die Rechnung, der diese Formate erst ab Version 11 unterstützt. Daher empfiehlt es sich, beim ICO-Format zu bleiben.

Wird im head-Bereich der Seite kein Metatag für die favicon.ico-Datei angegeben, wird vom Browser nach einer Datei dieses Namens im Root-Verzeichnis der Website gesucht. Diese Angabe wird also nur benötigt, wenn das Favicon an einem anderen Ort liegt.

Touch-Icons für iOS & Android

Mit dem iPhone wurde zusätzlich zum Favicon ein neues Bild-Element als Meta-Angabe hinzugefügt: Das »apple-touch-icon« mit einer Bildgröße von 57×57px. Es wird angezeigt, sobald der Benutzer den Link zu einer Website auf seinem iPhone-Homescreen speichert. Trotz des Namens haben kurz darauf Android-Handys dieses Verhalten übernommen.

  1. <link rel="apple-touch-icon" href="/apple-touch-icon.png">

Bei diesem Icon wurde bis einschließlich iOS6 automatisch ein typischer Glanzeffekt hinzugefügt, wie er auch bei den Apple-eigenen Applikationen vorgesehen war. Wenn dies bewusst nicht gewünscht ist, muss die Icon-Datei stattdessen »apple-touch-icon-precomposed.png« benannt werden.

Im Laufe der Zeit ist durch Tablet- und Retina-Versionen der Geräte die Anzahl zunächst auf 4 quadratische Größen gewachsen: 57px, 72px, 114px und 144px, mit der Einführung von iOS7 sind bei Apple auch noch die Größen 60px, 76px, 120px und 152px hinzugekommen. Mit der Umstellung auf »Flat Design« allerorten, sollte für ein einheitliches Erscheinungsbild auf unterschiedlichen Geräten die precomposed-Variante verwendet werden. Ab iOS7 wird auch der Glanzeffekt immer weggelassen.

Um sämtlichen Varianten Rechnung zu tragen, muss der folgende Block in den head einfügt werden:

  1. <!-- iPad, Retina, iOS ≥ 7: -->
  2. <link rel="apple-touch-icon-precomposed" sizes="152x152" href="apple-touch-icon-152x152-precomposed.png">
  3. <!-- iPad, Retina, iOS ≤ 6: -->
  4. <link rel="apple-touch-icon-precomposed" sizes="144x144" href="apple-touch-icon-144x144-precomposed.png">
  5. <!-- iPhone, Retina, iOS ≥ 7: -->
  6. <link rel="apple-touch-icon-precomposed" sizes="120x120" href="apple-touch-icon-120x120-precomposed.png">
  7. <!-- iPhone, Retina,  iOS ≤ 6: -->
  8. <link rel="apple-touch-icon-precomposed" sizes="114x114" href="apple-touch-icon-114x114-precomposed.png">
  9. <!-- iPad mini, iPad 1. und 2. Generation, iOS ≥ 7: -->
  10. <link rel="apple-touch-icon-precomposed" sizes="76x76" href="apple-touch-icon-76x76-precomposed.png">
  11. <!-- iPad mini, iPad 1. und 2. Generation, iOS ≤ 6: -->
  12. <link rel="apple-touch-icon-precomposed" sizes="72x72" href="apple-touch-icon-72x72-precomposed.png">
  13. <!-- Non-Retina iPhone, iPod Touch und Android 2.1+: -->
  14. <link rel="apple-touch-icon-precomposed" href="apple-touch-icon-precomposed.png">

Sind keine Touch-Icons in der Seite enthalten, sucht zumindest iOS im Root der Website nach den Dateien in der Reihenfolge apple-touch-icon.png und apple-touch-icon-precomposed.png, ignoriert aber weitere Dateinamen mit Größenangaben. Der empfehlenswerte Artikel von Mathias Bynens geht dabei ausführlich auf die Entstehung und Entwicklung der Touch-Icons ein.

Viewport

Um eine Website auch fit für die mobilen Geräte zu machen, benötigen diese den Viewport-Meta-Tag. Diese Anweisung beschreibt, wie ein Gerät mit geringerer Bildschirmgröße – meist ein Handy – mit der Seite umgehen soll. Um eine Seite mit einer Breite von 1200px auf ein 480px breites Handy-Display zu bringen, gibt es verschiedene Ansätze: Man zoomt auf eine bestimmte Auflösung, lässt den User selber skalieren oder gibt einen bestimmten Zoom-Faktor an.

Folgendes Beispiel gehört zu einer Website, die bereits »responsive« ist, und somit mit allen Auflösungen funktioniert.

  1. <meta name="viewport" content="width=device-width, initial-scale=1">

Eine genaue Beschreibung des Viewport-Meta-Tags und den Hintergründen findet sich im Webkrauts-Archiv: Ein Blick durch den Viewport.

Funktionen für Windows 7 und 8 im Internet Explorer

Microsoft hat seinen Betriebssystemen ab Version 7 in Verbindung mit dem Internet Explorer als Standardbrowser ein paar weitere Funktionen spendiert:

Pinned Sites

Webseiten können nicht nur in den Bookmarks gespeichert, sondern auch in der Windows-Taskbar abgelegt werden. Dazu wird ein 32×32px großes Favicon benötigt, das mit einem Icon-Editor schon im favicon.ico gespeichert wurde. Um etwas mehr Einfluss auf den Link zu haben, hat Microsoft noch folgende Meta-Tags definiert:

  1. <meta name="application-name" content="Der Name der Website">
  2. <meta name="msapplication-tooltip" content="Ein kleiner Erklärungstext wie er beim Hover erscheinen soll.">

Jump Lists

In Windows 7 waren auch sogenannte »Jump Lists« möglich. Diese wurden in das Rechts-Klick-Menü eingefügt, wenn der Nutzer auf die Seite in der Taskbar klickt. Für jeden Eintrag in das Menü kann ein Meta-Tag definiert werden, der wie folgt aussieht:

  1. <meta name="msapplication-task" content="name=Zur Startseite; action-uri=./; icon-uri=logo.ico">

Für die Icons kann z.B. der oben schon erwähnte X-Icon-Editor verwendet werden.

Tiles-Infos

Unter Windows 8 kann eine Website auch im Startmenü als Kachel hinterlegt werden. Dazu werden die Farbe, die Kachel-Grafik (144×144px, einfarbig, transparent) und folgende Meta-Tags benötigt:

  1. <meta name="msapplication-TileColor" content="#D83434">
  2. <meta name="msapplication-TileImage" content="path/to/tileicon.png">

Hier empfiehlt es sich, Kontrastfarben zu setzen. Um das Aussehen der Kacheln vorab zu testen, stellt Microsoft ein Tool zur Verfügung: Build my pinned site.
Optional kann auch ein RSS-Feed eingebunden werden, dann wird die Kachel regelmäßig mit neuem Inhalt befüllt.

Eine kleine Übersicht mit noch mehr Spielereien und Beispielen von Microsoft gibt es hier: Build my pinned Site for Windows 7.

Sonstiges

In älteren Versionen des Internet Explorers kann es noch bisweilen Darstellungsprobleme auf Webseiten geben, wenn der sogenannte »Kompatibilitätsmodus« aktiviert ist. Das hat zur Folge, dass versucht wird, das Verhalten älterer Browser (z.B. des IE7 oder IE6) zu imitieren. Das führt bei standardkonformem HTML meist zu sehr unschönen Ergebnissen. Mit dieser Metatag-Angabe kann der IE dazu gezwungen werden, stets die aktuellste Version seiner Rendering-Engine einzusetzen:

  1. <meta http-equiv="X-UA-Compatible" content="IE=edge">

Detaillierte Informationen zu weiteren Einstellungsmöglichkeiten gibt es direkt bei Microsofts Developer Network. Durch die deutlich verbesserte Unterstützung in aktuellen Versionen des Internet Explorers, verliert dieser Meta-Tag allerdings zusehend an Bedeutung.

SEO

Um die Qualität der Suchergebnisse zu verbessern, haben einige Suchmaschinen-Anbieter – allen voran Google – beschlossen, sogenannten »Duplicate Content« abzuwerten. Dieser entsteht zum Beispiel, wenn eine Webseite sowohl unter domainname.de als auch www.domainname.de erreichbar ist (Suchmaschinen werten dies als zwei unterschiedliche Adressen). Duplicate Content liegt ebenso vor, wenn der gleiche oder fast der gleiche Inhalt etwa in mehreren Kategorien einer Website (und damit unter mehreren URLs) zu finden ist.
In diesen Fällen wird den Suchmaschinen mitgeteilt, wo der Original-Text liegt, der für die eigentliche Indizierung verwendet werden soll, und ihr umgeht eine Abstrafung durch den Suchmaschinen-Betreiber:

  1. <link rel="canonical" href="http://www.example.com/original/">

Die großen Content-Management- bzw. Blog-Systeme wie WordPress, Drupal oder Joomla setzen die Tags meist automatisch – oder es gibt Module dafür. Um sicher zu gehen sollten aber unbedingt die Einstellungen und der ausgegebene Quelltext überprüft werden. Auf statischen Seiten hingegen kann auf diesen Tag verzichtet werden, wenn dort Inhalte nicht über mehrere URLs aufrufbar sind.

DNS-Prefetching

Bevor eine Ressource auf einer Website (z.B. JavaScript, CSS, Bilder) geladen werden kann, muss der Browser erst den DNS-Eintrag auflösen. Das dauert in der Regel nur wenige Millisekunden. Lädt der Browser nun viele Inhalte von anderen Domains, etwa über ein Content-Delivery-Network oder verwendete Werbung oder Zählpixel, kann es besonders bei mobiler Internetnutzung mit hohen Latenzen zu Verzögerungen kommen. Ihr könnt allerdings den Browser anweisen, die DNS-Informationen vorab zu laden, wenn sich ein freies Zeitfenster dafür ergibt:

  1. <link rel="dns-prefetch" href="//www.example.com">

Wird etwa der jQuery-CDN und Google Analytics im Projekt verwendet, sähe ein passender Eintrag so aus:

  1. <link rel="dns-prefetch" href="//code.jquery.com">
  2. <link rel="dns-prefetch" href="//google-analytics.com">

Eine ausführliche Beschreibung zu DNS-Prefetching gibt es im Mozilla Developer Network.

Weitere Meta-Tags

Generell sollte das Zeichen-Encoding einer Website bereits dem Browser vom Web-Server im HTTP-Header mitgeteilt werden, zusätzlich sollte diese Einstellung als Meta-Tag mitgegeben werden. Wichtig ist, dass die Deklaration des Zeichensatzes innerhalb der ersten 1024 Bytes der HTML-Datei erfolgen muss, daher sollte sie ganz zu Anfang stehen:

  1. <meta charset="utf-8">

Nach dieser grundlegenden Übersicht der aktuell geläufigsten Meta-Angaben geht es im morgigen zweiten Teil um weitere Möglichkeiten speziell für Social Media und Tracking-Dienste.

Kommentare

Gunnar Bittersmann
am 19.12.2013 - 09:45

Was heutzutage alles in den Header muss

Ähm, nö. Man sollte in Artikeln schon auf die richtige Benennung der Dinge achten. Hier ist nicht Header gemeint, sondern head.

header ist in HTML etwas völlig anderes. Und dann gibt es noch den HTTP-Header.

Und dann gibt es noch headings – Überschriften; das h in h1h6.

Permanenter Link
Nicolai Schwarz

Nicolai Schwarz (Webkraut)
am 19.12.2013 - 12:12

Völlig richtig. Das kommt davon, wenn wir ständig versuchen, Dachzeile, Titel und Teaser zu verbessern – und darüber den Kopf verlieren ;)
Ist korrigiert.

Permanenter Link

Gunnar Bittersmann
am 19.12.2013 - 10:09

Ich dachte schon, Ihr hättet das Wichtigste vergessen, aber nein, es kommt ganz zum Schluss, unter „Weitere Meta-Tags“.

Die Angabe der Zeichencodierung gehört IMHO nicht unter Weiteres, sondern ganz an den Anfang des Artikels, ist sie doch die so ziemlich wichtigste Angabe, die in den head gehört, zusammen mit title, dessen Bedeutung hier auch nirgends erwähnt ist.

Für HTML5 wird dabei UTF-8 als Standard angenommen, so dass auf diese Auszeichnung auch verzichtet werden kann

Den Verzicht auf die Angabe der Zeichencodierung würde ich nicht empfehlen. Zum einen war vor HTML5 ISO 8859-1 die Default-Codierung, so dass alte Browser ohne HTML5-Parser eine UTF-8-codierte Ressource ohne Angabe der Zeichencodierung (d.h. auch nicht per HTTP-Header) falsch decodieren dürften. Und wie mir unlängst zu verstehen gegeben wurde, legen die Webkrauts doch großen Wert auf die bedingungslose Unterstützung des IE8.

Zum anderen ist die Angabe im Dokument möglicherweise die einzige Angabe, nämlich dann, wenn es lokal gespeichert und nicht über HTTP aufgerufen wird.

Die Zeichencodierung sollte als erstes im head stehen, damit sie auf jeden Fall innerhalb der ersten 1024 Bytes der HTML-Ressource steht, wie von der HTML5-Spezifikation gefordert.

Zum Weiterlesen: W3C-i18n-Artikel Angabe der Zeichencodierung in HTML

Permanenter Link
Frederic Hemberger

Frederic Hemberger (Autor)
am 20.12.2013 - 08:23

Danke Gunnar für den richtigen Hinweis, ich habe die Stelle entsprechend angepasst.

Permanenter Link

Gunnar Bittersmann
am 20.12.2013 - 17:00

Gegenwärtig läuft auf der W3C-Mailingliste www-international eine Diskussion Guessing the fallback encoding from the top-level domain name before trying to guess from the browser localization. Sieht danach aus, dass das Weglassen der Zeichencodierungsangabe wirklich keine gute Idee ist, insbesondere nicht bei UTF-8.

Permanenter Link
Frederic Hemberger

Frederic Hemberger (Autor)
am 21.12.2013 - 17:00

Wie gesagt: Die beste Methode ist ohnehin, das Charset als HTTP-Header mitzusenden und das selbe ebenso als Meta-Tag mitzusenden. Gibt man in der HTTP-Antwort kein Charset mit, geht der Browser erst mal von der Standardeinstellung aus (wobei ich mir grad nicht sicher bin, ob das bei HTML5 immer UTF-8 ist, oder sich am eingestellten Default-Charset im Browser orientiert). Wird der Meta-Tag verwendet und dort ein abweichendes Encoding verwendet, verwirft der Browser auch das bis dahin geparste HTML wieder und beginnt wieder von vorne. Also in jedem Falle ungünstig.
Permanenter Link

p4shr
am 19.12.2013 - 11:13

Vielen Dank für diese Auflistung, hat mich gut unterstützt bei einem aktuellen Projekt. Dieser Blog scheint einen echten Mehrwert zu haben, werde ich nun regelmäßig verfolgen :)

Permanenter Link
Michael Kühnel

Michael Kühnel (Webkraut)
am 19.12.2013 - 13:02

»dns-prefetch« kannte ich noch nicht. Habe gleich mal nach Browser Support geschaut. Hier die Infos die ich gefunden habe falls es jemand interessiert: HTML5 Boilerplate Doku

Anbei noch eine Ergänzung zum Thema favicon bzw. fav-/touch-/tile-icons. Das hier ist da perfekte Tool um einen jede Menge Arbeit zu sparen: realfavicongenerator.net. Warum das Ding »real« im Namen beinhaltet wird einem klar, sobald man schaut was es kann, bzw. spätestens nach einem ersten Test.

Kurze Zusammenfassung: Man benötigt nur eine Quelle. Für optimale Ergebnisse sollte es ein PNG mit Transparenz und einer Auflösung von 260x260 Pixeln. Der Generator erstellt dann neben sämtlichen Bild-Ressourcen auch den benötigen Quelltext inklusive browserconfig.xml für den IE11.

In den FAQ des Tools steht auch noch mal genau beschrieben, warum man auf <link rel="shortcut icon" href="/favicon.ico" type="image/x-icon" /> verzichten sollte.

Permanenter Link

Die Kommentare sind geschlossen.