Unsere Datenschutzrichtlinie wird in Kürze aktualisiert. Bitte sehen Sie sich die Vorschau an.

Webseiten restaurieren und optimieren: Jede Woche neu

Was gehört in den Head-Bereich und was nicht (mehr)?

Testen Sie unsere 2016 Kurse

10 Tage kostenlos!

Jetzt testen Alle Abonnements anzeigen
Webseiten sind heute einfach zu erstellen und auch schnell live gestellt - doch bereits zum Start sollten Sie als Betreiber für die Zukunft gewappnet sein: Wie können Sie Ihre Inhalte über einen längeren Zeitraum "frisch" halten? Wie lassen sich Zugriffszeiten optimieren? Wie reagiere ich auf aktuelle Designtrends und bessere Bandbreiten? Wie schütze ich mich vor Datenverlust und Hacker-Angriffen? Antworten und Hilfe zu diesen und vielen ähnlichen Fragen finden sie zuhauf in dieser praktischen Tipp-Serie.
05:59
  Lesezeichen setzen

Transkript

Alle Informationen im Head-Bereich einer Webseite, ausgenommen dem Titel, der ja im Browser oben in den Reitern erscheint, sind nicht für den Klienten beziehungsweise den Seitenbesucher gedacht, sondern einerseits für den Browser, damit er weiß, wie er die Seite darstellen soll, andererseits zum Beispiel für Suchmaschinen, damit diese die nötigen Information kriegen, um die Seite korrekt indexieren zu können. Und alles andere, was also nicht zum tatsächlichen ersten Aufrufen der Seite notwendig ist beziehungsweise nicht zwingend für Suchmaschinen geeignet ist, darf in der Zwischenzeit den Head-Bereich auch wieder verlassen. Sehen wir uns also an, wie wir diese Aufrufe in der Zwischenzeit gestalten können. Ich möchte Ihnen nun das Beispiel einer Seite zeigen, bei der es noch sehr viel Verbesserungspotenzial im Head-Bereich gibt. Diese Seite hat zwei Schwachstellen. Das eine sind die CSS-Aufrufe, die hier stattfinde. Hier sollen vier CSS-Dateien geladen werden, das heißt, es gibt vier Aufrufe an den Webserver, um diese Dateien dann abzuliefern und das lässt sich ziemlich einfach auf eine Datei reduzieren. Der Weg dorthin besteht aus mehreren Möglichkeiten. Falls es kleine CSS-Dateien sind, die nur aufgrund ihrer Geschichte gesondert dargestellt werden, dann lassen die sich in eine Haupt-CSS-Datei zusammenführen. Sollten Sie mit Präprozessoren arbeiten, dann haben Sie die Möglichkeit, zum Beispiel in einer SASS-Datei, in einer übergeordneten, alle mitverantwortlichen Dateien einzubinden. Oder Sie verwenden PHP und verwenden ein PHP-Skript dafür, dass alle CSS-Dateien aufgerufen werden. Dann haben Sie dem Server gegenüber nur diesen einen Aufruf der PHP-Datei und die kümmert sich dann um den Aufruf der CSS-Dateien. Eine zweite Schwachstelle bei diesem Beispiel ist der Aufruf der JavaScript-Dateien. Auch die werde ich jetzt schnell noch ein bisschen hervorheben. Bei JavaScript ist es so, dass wir in der Zwischenzeit darauf achten, ob sich beim JavaScript um etwas handelt, was tatsächlich schon zum Beginn des Ladens der Seite notwendig ist oder nicht. Ich entnehme den Namen dieser Dateien, dass es sich um eine Lightbox handelt, und normalerweise ist es so, dass eine Lightbox erst mal einen Link braucht, auf den ich klicken kann, bevor nachher diese Lightbox zum Einsatz kommt. Da wäre es doch praktischer, wenn ich dafür sorge, dass dieser Link zügig geladen wird, damit ich dann die Lightbox zum Einsatz bringen kann. Das heißt, diese drei JavaScript-Dateien sind wunderbar auch am Ende dieses HTML-Dokuments unterzubringen. Ein anderes Beispiel betrifft die Seite getbootstrap.com, eine sehr große Seite, die sich um sehr viele unterschiedliche Teilbereiche kümmern muss und die schafft es jetzt mit sehr reduzierten Mitteln und sehr reduzierten Aufrufen zu arbeiten. Einerseits haben wir hier zwei CSS-Dateien, die aufgerufen werden. Die markiere ich mal schnell und Sie sehen, dass diese Dateien aus unterschiedlichen Verzeichnissen stammen, das heißt, sie haben einen unterschiedlichen Ursprung und sind deswegen getrennt dargestellt, aber dafür sind sie minimiert, was die Ladezeit auch beschleunigt. Und dann habe ich hier JavaScript-Dateien. Bei dem ersten Skript ist es völlig klar, warum es am Anfang geladen werden sollte. Hier geht es darum, dass dem Browser Internet Explorer 9 eine spezielle Weiche zur Verfügung gestellt wird, damit auch dieser Browser die Seite korrekt darstellen kann. Und diese beiden Verlinkungen, die hier folgen, die betreffen die sogenannten Favicons. Favicons befinden sich hier oben beim Titelaufruf der Seite und sollten vielleicht auch schon von Anfang an zur Verfügung stehen, weil sie beim Identifizieren der Seite helfen. Dann kommt ein Skript von Google Analytics, die hier ebenfalls am Werk sind, und auch dieses muss am Anfang aufgerufen werden, um seine Arbeit tun zu können. Aber alle anderen JavaScript-Dateien, die noch weiter zum Einsatz kommen, weil natürlich auch eine Bootstrap-Seite mit Bootstrap gemacht wird, finden Sie am Ende der HTML-Datei. Und hier haben die Dateien ein gutes Zuhause, weil das heißt, die Seite wird erst mal geladen und erst dann kommen diese zusätzlichen JavaScript-Dateien zum Einsatz und können das bewirken, wofür sie auch zuständig sind, ohne dabei das prinzipielle Laden der Seite zu stören. Mein letztes Beispiel eines Head-Bereiches ist natürlich ein sehr unfairer Sparring-Partner, weil dies ist eine sehr kleine Testseite, das ist eine Testseite namens Bergwelten, und diese besteht nur aus minimalen Elementen. Das heißt, der Head-Bereich ist auch sehr schön aufgeräumt. Ich habe den Titel drin, ich habe den Zeichensatz drinnen, den Viewport und als einzigen Aufruf an einen Webserver den Aufruf der einzigen CSS-Datei. Hiermit haben Sie drei Beispiele gesehen, wie Head-Bereiche ausschauen können, und versuchen Sie bei Ihren eigenen Projekten darauf zu achten, dass alles, was im Head-Bereich untergebracht ist, nicht zu einer Verzögerung des Ladens der Seite führen, sondern eher unterstützend für das Laden eingesetzt werden.