Website-Tuning Stage 1: Code validieren und optimieren

Das WWW – wie wir es heute kennen – hat eine gewisse Entwicklung hinter sich. Durch diese ist letztlich auch HTML bzw. HTML5 entstanden, da es vorher keine Standards für die strukturierte Übertragung von digitalen Informationen zwischen mehreren Personen gab.

Zur Historie von HTML: Die Hypertext Markup Language gehört zur Klasse der sog. Auszeichnungssprachen, die einen Text semantisch strukturiert und es erstmals Ende 1992 ermöglichte Informationen spezifiziert über Ländergrenzen hinweg zu übertragen. Heutzutage wird HTML vom W3C und der WHATWG weiterentwickelt. Die derzeitige aktuellste Spezifikation ist HTML5, die bereits von den meisten Webbrowsern unterstützt wird.

Wenn nun entsprechend dieser Spezifikation der Quellcode geschrieben wird, so besteht auch eine größere Chance, dass dieser dann auf allen Endgeräten gleichartig interpretiert und angezeigt wird.

HTML5 validieren

Damit der Quellcode einer Webseite entsprechend der Spezifikation des W3C geschrieben wird, bzw. das Ergebnis sich prüfen lässt, gibt es vom W3C einen sog. Validatior. Werden hier Fehler oder Warnungen ausgegeben, so können diese korrigiert werden. Ein bekannter Validator ist unter folgender Domain zu finden:

html5.validator.nu

CSS validieren

Weiter verhält es sich mit dem CSS genauso wie mit dem HTML, hier wird auch ein Validator von W3C bereitgestellt:

jigsaw.w3.org/css-validator

Es fällt auf, dass hier etliche Fehler gefunden werden und der Quellcode angeblich alles aber eben nicht valide ist. Das liegt daran, dass CSS3 noch nicht spezifiziert ist (und damit kein Standard, der sich prüfen ließe) und bisher nur ein Entwurf ist, der permanent erweitert wird und dann durch die Browser-Engines implementiert wird. Dadurch gibt es auch die verschiedenen Browser-Präfixe (wie bspw. „-webkit“).

Nichtsdestotrotz lassen sich so einige Fehler im Stylesheet erkennen und bereinigen.

HTML5 und CSS optimieren

Damit das CSS und HTML so schnell wie möglich angezeigt werden, ist es wichtig, dass dieser Quellcode so schnell wie möglich geladen wird. Daraus folgt, dass zum einen der HTML und CSS-Code immer so klein wie möglich sein sollten und zum zweiten, dass auch nur das übertragen wird, was auch wirklich gebraucht wird.


Folgendes ist empfehlenswert:

  • Kommentare Entfernen
  • Kommentare aus Scripts und Styles entfernen
  • Entfernen von CDATA-Sektionen von Skripten und Styles
  • Überflüssige Leerzeichen und Zeilenumbrüche entfernen
  • Entfernen von leeren Attributen (class=„“)
  • Entfernen von leeren Elementen
  • URLs relativ angeben (URLs minifizieren)

Texte per HTTP-Kompression verkleinern

HTTP-Kompression, die von Servern und Webbrowsern unterstützt wird, dient der Verkürzung der Übertragungsgeschwindigkeit und der Optimierung der Bandbreitenausnutzung.

Komprimierbare Ressourcen (wie Textdateien also vor allem HTML, CSS und Javascript) auf einer Webseite, die mittels HTTP-Komprimierung bereitgestellt werden, sorgen dafür, dass sich bis zu 90% des benötigten Datenvolumens bei der Übertragung einsparen lassen. Viele Webserver können Dateien vor dem Senden mittels gzip komprimieren. Dies geschieht durch Aufrufen eines Drittanbietermoduls oder mithilfe integrierter Routinen. Dadurch können für das Rendern Ihrer Website erforderliche Ressourcen signifikant schneller heruntergeladen werden.

Bei anderen Ressourcen wie z.B. JPEG-Bildern lohnt diese Vorgehensweise nicht, da das Bild selber schon komprimiert ist.

HTTP-Kompression (gzip) im nginx-Webserver aktivieren

Aus allgemeinen Performancegründen arbeiten wir mit dem Webserver nginx. Dieser liefert die statischen Dateien deutlich schneller als ein Apache Webserver aus, sodass dieser hierhingehend konfiguriert werden muss. Die folgende Konfiguration beinhaltet die gesamte nginx-Konfiguration für das MODX-CMS:


location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg)$ {<br>
    expires 30d;<br>
    add_header Pragma public;<br>
    add_header Cache-Control "public, must-revalidate, proxy-revalidate";<br>
    try_files $uri = @fallback;<br>
<br>
    if (!-e $request_filename) {<br>
        rewrite ^/(.*)$ /index.php?q=$1 last;<br>
    }<br>
}<br>
<br>
gzip on;<br>
gzip_proxied any;<br>
gzip_types  application/javascript application/json application/xml application/xml+rss application/x-javascript text/css text/javascript text/plain text/xml;<br>
gzip_vary on;

Fazit

Alleine durch diese kleinen Optimierungen konnte der Textanteil der übertragenen Daten von ca. 250 kB auf rund 70 kB, also um über 70% gesenkt werden. Diese läppischen 180 kB sind zwar in Zeiten von VDSL, Glasfaser und LTE kaum der Rede wert, entlasten aber dennoch gerade in Lastzeiten den Server enorm und auch einen geneigten Interessenten, der eben doch nur über EDGE oder GPRS mit dem Internet verbunden ist.