HTML-Code auf Produktivsites so klein wie möglich

Es ist nicht sonderlich überraschend, wenn ich sage, je weniger Daten vom Server geschickt und vom Client empfangen werden müssen, desto schneller funktioniert der Seitenaufbau. Ich habe bereits im Beitrag zur Komprimierung des Ausgabestroms gezeigt, wie man den an den Client gesendeten Code verkleinern kann. In diesem Beitrag möchte ich aber einmal näher darauf eingehen, wie der an den Browser gesendete HTML-Code selbst verkleinert werden kann.

Zu allerest möchte ich eine wichtige Grundlage festlegen, damit man mit dem Code auch später noch arbeiten kann: Man sollte sich im CVS, SVN oder einfach nur auf der Festplatte 2 Ordner anlegen. Einen Source-Ordner, der die Quellcodes in ihrer ursprünglichen Form enthält, und einen Veröffentlichungsordner, in dem wir alle Dateien ablegen, die wir nach den folgenden Anweisungen verkleinern.
Alle hier aufgelisteten Tipps beziehen sich auf den HTML-Code, der entweder als fertige HTML-Datei vorliegt oder von einer PHP-Datei generiert wird, CSS-Dateien und JavaScript – kurz: alles, was vomClient geladen werden muss.

Zuerst entfernen wir alle unnötigen Leerzeichen und Zeilenumbrüche. Das sind vor allem solche zwischen Tags. Da HTML auf XML basiert, haben Zeilenumbrüche, Leerzeichen und Tabulatoren zwischen Tags sowieso keinen Einfluss. Es ist allerdings darauf zu achten, dass nicht innerhalb von Textareas oder vorformatierten Abschnitten (<pre>) für die Ausgabe bedeutsame Whitespaces entfernt werden.
Auch in CSS-Dateien sowie innerhalb von <style>-Tags können Leerzeichen und Zeilenumbrüche entfernt werden. Für Javascript gilt ähnliches, allerdings ist hier darauf zu achten, dass man keine syntaktisch notwendigen Leerzeichen löscht, aber ganz allgemein gesagt kann jeder Zeilenumbruch in JavaScript gelöscht werden und nach einem Semikolon braucht kein Leerzeichen zu stehen – vorausgesetzt, man hat nach jedem Befehl ordentlicherweise ein Semikolon gemacht.

Anschließend entfernen wir die HTML-Kommentare (<!– … –>), außer dem Kommentar um JavaScript-Angaben. Wichtig und auf jeden Fall beizubehalten sind auch die Doctype-Definition sowie Conditional Comments für den IE.
Das gleiche gilt für JavaScript (// und /* … */) und CSS (/* … */) – auch hier sind Kommentare auf dem Produktivsystem überflüssig.

Bestimmte Farben können in CSS in Kurzschreibweise angegeben werden: Immer dann, wenn sich die Hex-Ziffern der einzelnen Rot-Grün- und Blau-Werte wiederholen, geht das. So wird aus #ff0000 einfach #f00 oder aus #ddeeff #def.

Sinnlose Tags wie leere Absätze <p></p> oder bestimmte Meta-Angaben, welcher Editor benutzt wurde, können gefahrlos entfernt werden.
Wem es nicht auf Suchmaschinenoptimierung ankommt, sondern nur darauf, wie die Seite dargestellt wird, kann auch <i> statt <em> sowie <b> statt <strong> benutzen.

Benutze CSS !!! Mit dem gekonnten Einsatz von CSS-Eigenschaften für bestimmte Tags oder Klassen kann sehr viel Code eingespart werden. Wenn man dazu noch Vererbung von CSS-Klassen gekonnt einsetzt, kann richtig viel Code gespart werden.
Hinzu kommt, dass externe CSS-Dateien nach dem ersten Laden einer Seite (je nach Einstellung) beim Client im Browser-Cache gespeichert werden und somit beim nächsten Aufruf nicht geladen werden müssen. Ähnlich verhält es sich mit externen js-Dateien.

In CSS kann man viele Eigenschaften zusammenfassen. border-color, border-width und border-style beispielsweise können zusammengefasst werden:

/* alte Definition */
div {
  border-color:red;
  border-style:solid;
  border-width:1px;
}
 
/* neue Definition */
div {
  border:solid 1px red;
}

Das gleiche geht mit font-size, font-family, line-height und font-weight.

/* alt */
blockquote {
  font-size:0.9em;
  font-family:Arial,sans-serif;
  line-height:12px;
  font-weight:bold;
}
 
/* neu */
blockquote {
  font:bold 0.9em/12px Arial,sans-serif;
}

Und es gibt weitere Beispiele, die nach diesem Muster funktionieren. Ich empfehle dazu die Beschreibungen auf CSS 4 You

In JavaScript können auch Codeoptimierungen vorgenommen werden: Aus x = x + 1; kann nach dem Umschreiben auf eine Inkrementierung x++; werden. Ebenso müssen auf Produktivsystemen Variablennamen nicht nachvollzogen werden können – aus var gesamtsumme kann per search-and-replace einfach var g1 gemacht werden. Ein automatisches Tool würde darauf achten, dass es nicht zu Variablenüberschneidungen kommt, deshalb die eins. Wenn man diese Optimierung per Hand durchführt, ist peinlichst genau darauf zu achten, dass man wirklich suchen-und-ersetzen benutzt, da man sonst eventuell ein Vorkommen einer Variable nicht umbenennt und das zu Fehlermeldungen und Funktionalitätseinbußen führen kann.

In JavaScript kann man auf die eingebauten Objekte (und Funktionen) wie window eine Referenzvariable legen. Statt

alert(window.navigator.appName); 
alert(window.navigator.appVersion); 
alert(window.navigator.userAgent);

könnte man

w=window;n=w.navigator;a=alert; 
a(n.appName); 
a(n.appVersion); 
a(n.userAgent);

schreiben. Nebenbei erhöht diese Art der Programmierung auch die Ausführungsgeschwindigkeit des JavaScripts, da die Variablen einfacher auf die Objekte zugreifen können.
Ein Nebeneffekt dieses Tipps und dem im vorherigen Absatz ist, dass es Codediebe nicht mehr so leicht haben, den Code nachzuvollziehen und für eigene Aktionen zu verwenden.

JavaScript-Imports können optimiert werden. Man sieht oft Code-Blöcke wie diesen im Head einer Seite:

<script src="scripts/rollovers.js"></script> 
<script src="scripts/validation.js"></script> 
<script src="scripts/tracking.js"></script>

Wenn man die Inhalte der 3 Funktionen in eine große js-Datei kopiert, kann diese sehr viel einfacher geladen werden (nur noch eine HTTP-Anfrage nötig statt drei) und der Markup-Aufwand verringert sich ebenfalls.

Und zum Schluss noch einer der besten Tipps: Divs statt Layout-Tabellen nutzen. Das spart oft sehr viel Code und ist dazu noch wesentlich flexibler.

Ich sage es nochmal deutlich: Der Code, der am Ende nach all diesen Optimierungen herauskommt, ist für die Entwicklung nicht mehr zu gebrauchen, da er kaum noch Struktur enthält. Dem Browser ist das aber völlig egal, denn der verarbeitet die Scripte auch so ohne Probleme, nur müssen somit viel weniger Daten gesendet werden. Und ihre Benutzer interessiert der Quellcode auch nicht – die Hauptsache ist, dass es im Browser keinen Unterschied gibt. Weiterentwicklung wird eh mit dem Originalcode durchgeführt. Wer also sehr häufig Änderungen am Code durchführt, sollte sich den Einsatz eines (kostenpflichtigen) Tools wie dem W3 Compiler überlegen, statt die Optimierungen ständig von Hand durchzuführen.
Einzelne Tipps allein mögen nicht viel bringen. Wenn aber alle konsequent durchgeführt werden, können Ersparnisse von bis zu 30% herausspringen.

Jan hat 152 Beiträge geschrieben

13 Kommentare zu “HTML-Code auf Produktivsites so klein wie möglich

  1. Hasch sagt:

    Schöne Sache, sollte z.T. eigentl. selbstverständlich sein, aber sehr gute Zusammenfassung. Aber sag mal bei Javascript müssen Variablen doch mit einem „var“ initialisiert werden 🙂

  2. Entweder hab ichs überlesen oder du hast folgendes vergessen:

    Lagert CSS und Javascript komplett aus. So muss der Browser die Angaben und Skripte nur einmal bzw. nur bei Änderungen laden.

  3. admin sagt:

    Variablen müssen nicht mir var initialisiert werden. Das ist zwar sauber, jedoch keine Pflicht in JavaScript.

    Zum Auslagern: Das stimmt. Man sollte möglichst alle CSS- und JS-Sachen auslagern, aber darum gings hier eigentlich nich 😉
    Hast aber recht, dann wird die vom Client zu ladende Datenmenge ebenfalls kleiner.

  4. admin sagt:

    @Lars: Korrekt, ich benutze nur noch XHTML, was ja die XML-Prinzipien auf HTML überträgt. Aber du hast recht, ursprünglich war HTML eine Untersprache der SGML.

  5. Quetschke sagt:

    Aber sag mal bei Javascript müssen Variablen doch mit einem “var” initialisiert werden

    Variablen müssen nicht mir var initialisiert werden. Das ist zwar sauber, jedoch keine Pflicht in JavaScript.

    Genauer: „var“ setzt die Variablen global. Ist daher eigentlich nur wichtig, wenn Variablen in jedem Namespace zur Verfügung stehen sollen.

  6. Björn sagt:

    Dazu widerspreche ich etwas, mit Dinge laden alles in einer Javascript-Datei (Beispiel).

    Besucher die sich nicht einloggen gebrauchen manche Funktionen nicht, warum laden eines 50kb-Javascriptes was nur auf einer Seite gebraucht wird (z.B: Galerie-Funktionen) sollte man nur dort laden wo gebraucht wird und nicht auf jeder Seite mit.

    Man sollte nur das Laden was benötigt wird.

  7. admin sagt:

    Stimme ich dir zu, Björn. So war das auch nicht gemeint, sondern eher so: Alles was immer gebraucht wird in eine Datei. Das was nur für angemeldete User gebraucht wird, in eine zweite Datei.

  8. Jo sagt:


    Genauer: “var” setzt die Variablen global. Ist daher eigentlich nur wichtig, wenn Variablen in jedem Namespace zur Verfügung stehen sollen.

    Innerhalb einer Funktion sind mit „var“ deklarierte Variablen lokal, ohne „var“ global.
    Ausserhalb von Funktionen spielt es glaube ich keine Rolle, wobei es mit var natürlich sauberer ist (aber wenn man wie in diesem Artikel erklärt Dateien aufs Minimum reduzieren will, spart das Weglassen von „var “ immerhin ein paar Zeichen 😉 )

  9. tinu sagt:

    Sparsam sein ist gut und recht. Aber nicht übertreiben. Bei der heutigen Bandbreite kommt es auf ein paar Zeilenumbrüche nicht an. Und jeder, der später den Quell-Code wieder anpassen muss ist dankbar wenn eine gewisste strukturierte Schreibweise vorhanden ist…

Eine Antwort schreiben

Ihre E-Mail-Adresse wird nicht veröffentlicht. Benötigte Felder sind markiert mit *

You may use these HTML tags and attributes: <a href=""> <blockquote cite=""> <pre lang=""> <b> <strong> <i> <em>