HTML und Performance: Über das Auslassen optionaler Tags und Anführungszeichen

Artikel vom 31. August 2019. ISSN 1614-3124, #61. Schwerpunkt: Webentwicklung (RSS-Feed für alle Themen).

Beginnen wir sofort mit dem vereinfachten Hauptargument.

P.1: Je kleiner die HTML-Last einer Website, desto schneller wird die Website dargestellt.
P.2: Je schneller eine Website dargestellt wird, desto schneller ist sie (erscheint sie).
P.3: Das Auslassen optionaler Tags und Anführungszeichen verringert die HTML-Last.
C: Also: Das Auslassen optionaler Tags und Anführungszeichen macht eine Website schneller.

Dies ist ein altes Argument (persönlich habe ich so seit 2008 argumentiert).

Das Argument anzweifeln

Das Argument wird manchmal über Prämisse P.1 angefechtet:

P.1: Je kleiner die HTML-Last einer Website, desto schneller wird die Website dargestellt wenn etwaige Komprimierung (wie GZIP oder Brotli) nicht effektiver mit der größeren Last funktioniert.

Es kann auch über den Schluss C (eigentlich auch P.1, aber der Einfachheit halber formulieren wir es so) angegriffen werden:

C: Das Auslassen optionaler Tags und Anführungszeichen macht eine Website schneller, es sei denn, das Einfügen der DOM-Nodes der ausgelassenen Tags kostet mehr Zeit, als durch die verringerte Last eingespart wird.

Ich selbst habe die Bedenken um P.1 gerne ignoriert, weil ich schon in verschiedenen Tests bei Google konsistent etwa 10–20% Markup-Einsparungen gemessen hatte, und nichts im Bereich Komprimierung, was diese aufwog. Ich habe bisher niemand wie dargestellt C anzweifeln hören, aber auch wenn der Node-Einfügungseffekt minimal sein wird, scheint der Einwand per se legitim.

Das Argument retten

Es gibt zwei und interessanterweise dieselben Probleme mit beiden Angriffen:

Sie sind konditional und gelten nicht immer: wenn Komprimierung effektiver mit der größeren Last funktioniert, und wenn das Einfügen der DOM-Nodes der ausgelassenen Tags mehr Zeit kostet, als durch die Lastverringerungen eingespart wird.
Es fehlen Daten: Beide Fälle wurden meines Wissens nach noch wenig erforscht.

Das zweite Problem und der effektive Umgang mit ihm liegt nun bei dem, der den Fall vorbringt, hier also mir selbst. Wir, die wir HTML-Performance analysieren und erforschen, müssen weitere Daten sammeln, um die Folgen der verschiedenen Arten, wie man HTML schreiben kann, noch klarer zu beurteilen.

Das erste Problem mit den Angriffen ist schwerwiegend, weil es Websites gibt, die gar keine Komprimierung einsetzen (tatsächlich viele Websites: im August 2019 noch 20,6% aller erfassten Seiten), und natürlich auch Websites (These: die meisten), die durch Node-Wiedereinführung nicht langsamer werden.

Obwohl wir immer noch einem Mangel von Daten gegenüberstehen, scheint das Argument deshalb stichhaltig zu sein. (Meine Ansicht, die gerne auseinandergenommen werden darf.)

Optionale Tags und Anführungszeichen auslassen

Nachdem dies gesagt ist, schlägt das Argument einen Kurs vor: Zumindest in unserem Produktionsmarkup sollten wir alle optionalen Tags und Anführungszeichen auslassen, um den Payload zu verkleinern und die entsprechenden Seiten zu beschleunigen.

Welche HTML-Tags optional sind ist gut dokumentiert und im »lebenden« HTML-Standard auch bei jedem Element beschrieben (siehe zum Beispiel das html- oder p-Element).

Bei Anführungszeichen ist die HTML-Spezifikation klar: Als Daumenregel gilt, dass solange ein Attributswert kein Leerzeichen oder Gleichheitszeichen (»=«) beinhaltet, die Anführungszeichen weggelassen werden können.

Optionales Markup auslassen in der Praxis

Manch einer hat die Neigung, das Auslassen optionaler Tags und Anführungszeichen sofort und direkt abzulehnen. Ich will das nicht bewerten, aber dies ist aus zwei Gründen interessant (wenn nicht ironisch):

Das Auslassen optionaler Tags macht Markup lesbarer. Es gibt kein kürzeres valides Dokument als <!DOCTYPE html><title>␣</title> (Gist), und nichts lesbareres und verständlicheres, sobald die ersten Inhalte folgen. (Ich würde gerne ein stichhaltiges Argument sehen, wie das Einschließen von allem optionalen Code HTML lesbarer und verständlicher machen soll. Wir lassen aus und vereinfachen aus guten Gründen in vielen anderen Sprachen – obwohl ein etwas anderer Fall, scheint der ternäre Operator in JavaScript ein gutes Beispiel zu sein. Er ist völlig obskur und repräsentiert dennoch ein absolutes Minimum an Code – ähnlich wie Markup, das von allen optionalen Tags und Anführungszeichen befreit wurde.)
Optionale Tags werden bereits konsistent aus Tabellen ausgelassen, wie das tbody-Element am besten veranschaulicht: Es wird fast immer weggelassen, obwohl es vom Browser wieder eingehängt wird, genauso wie es jene optionalen html- und body- und andere Start- und End-Tags würden.

Auch wenn ich persönlich ein Fan davon bin, dass Webentwickler in der Lage sind, (nahezu) produktionsfertigen Code von Hand schreiben zu können, will ich hier nicht so aufdringlich sein, zu erwarten, dass wir alle unsere individuellen Entwicklungspraktiken anpassen.

Unsere beste Option ist etwas anderes: Wenn wir es bevorzugen, effizienten und schnellen Code nicht selbst per Hand zu schreiben, wie es beim Auslassen optionalen Codes möglich wäre, sollten wir diesen Code generieren. Da dies bisher von kaum Tooling gemacht wird (irgendetwas robustes außer HTMLMinifier?), müssen wir die Verbesserung unseres Toolings priorisieren und vorantreiben.

Anders ausgedrückt: Solange es keinen guten Grund gibt, es anders zu machen, denke ich, dass wir als Fachleute wissen sollten, welcher Code optional ist, und diesen auch auslassen. Gleichzeitig sollten unsere Produktionssysteme bessere Arbeit leisten, uns dabei zu unterstützen. Nach all den Jahren der Vernachlässigung einfachster HTML-Optimierung sollten wir endlich den nächsten Schritt gehen und kein optionales HTML mehr ausliefern.

Eisenherz reißt sich zusammen und kümmert sich um seine Pflichten.

Abbildung: Welcher Teil eines Handwerks ist Pflicht? (Copyright King Features Syndicate, Inc., vertrieben durch Bulls.)

Bestimmt habe ich Daten und Werkzeuge übersehen – wenn ja, lassen Sie es mich bitte wissen. Wenn es darum geht, ob ich meinen eigenen Worten Taten folgen lasse, so mache ich mir nicht nur bewusst mein Entwicklerleben schwer, sondern betreibe mehrere Projekte, die von den hier empfohlenen Praktiken Gebrauch machen: unter anderem das statische UITest.com und das statisch generierte HH Kaffee mitsamt offenem Quelltext. Genauso wie Deklarationen nur einmal zu verwenden in CSS: Es funktioniert.

Über mich

Jens Oliver Meiert, am 9. November 2024.

Ich bin Jens (lang: Jens Oliver Meiert), und ich bin ein Frontend-Engineering-Leiter und technischer Autor/Verleger. Ich habe als technischer Leiter für Firmen wie Google und als Engineering Manager für Firmen wie Miro gearbeitet, bin Mitwirkender an verschiedenen Webstandards und schreibe und prüfe Fachbücher für O’Reilly und Frontend Dogma.

Ich experimentiere gerne, nicht nur in der Webentwicklung (und im Engineering Management), sondern auch in anderen Bereichen wie der Philosophie. Hier auf meiert.com teile ich einige meiner Erfahrungen und Ansichten. (Bitte sei kritisch, interpretiere wohlwollend und gib Feedback.)