Sie sind hier : sebastian1012.bplaced.net/ homepage-neu / ineresantes / Html-optimieren.php

HTML optimieren

  1. Warum sauberes Markup?
  2. Markup riecht
  3. Zusätzliche Optimierungen
  4. Aggressive Optimierungen
  5. Wenn Dinge schief laufen
  6. Antimuster
  7. Werkzeuge
  8. Zukünftige Überlegungen

Warum sauberes Markup?

Die clientseitige Optimierung erhält in letzter Zeit viel Aufmerksamkeit, aber einige ihrer grundlegenden Aspekte scheinen unbemerkt zu bleiben. Wenn Sie sich die Seiten im Web genau ansehen (auch diejenigen, die hoch optimiert sein sollen ), können Sie leicht eine große Anzahl von Redundanzen und ineffiziente oder archaische Strukturen in ihrem Markup erkennen. All dieses Gepäck erhöht das Gewicht von Seiten, die so leicht wie möglich sein sollen.

Der Grund, Dokumente sauber zu halten, liegt nicht in kürzeren Ladezeiten, sondern in einer soliden und robusten Grundlage, auf der man aufbauen kann. Sauberes Markup bedeutet bessere Zugänglichkeit, einfachere Wartung und gute Sichtbarkeit in Suchmaschinen. Kleinere Formate sind nur eine Eigenschaft von sauberen Dokumenten und ein weiterer Grund, sie auf diese Weise aufzubewahren.

In diesem Beitrag werden wir uns mit der HTML-Optimierung befassen: Entfernen einiger üblicher Markup-Gerüche; Reduzierung der Dokumentengröße durch Beseitigung redundanter Strukturen und Einsatz von Minimierungstechniken. Wir werden uns die derzeit verfügbaren Minimierungstools ansehen und analysieren, was sie falsch und richtig machen. Wir werden auch darüber sprechen, was in Zukunft getan werden kann.

Markup riecht

Also, was sind die häufigsten Täter?

1. HTML-Kommentare in Skripten

Eine der größten Redundanzen ist heutzutage die Einbeziehung von HTML-Kommentaren <!-- -->in Skriptblöcke. Es gibt hier nicht viel zu sagen, außer dass Browser, die tatsächlich diese Fehlervermeidungsmaßnahme benötigen (wie '95 Netscape 1.0 ), so gut wie ausgestorben sind. Kommentare in Skripten sind nur unnötiges Gepäck und sollten mit Gewalt entfernt werden.

2. <! [CDATA […]> Abschnitte

Eine weitere oft unnötige Fehlervermeidungsmaßnahme ist die Einbeziehung von CDATA-Blöcken in SCRIPT-Elemente:


  <script type="text/javascript">
    //<![CDATA[
      ...
    //]]>
  </script>

Es ist ein nobles Ziel, das in der Realität verfehlt wird. Während CDATA-Blöcke ein perfekter Weg sind, um zu verhindern, dass der XML-Prozessor <und & als Start des Markups erkennt, ist dies nur bei echten XHTML-Dokumenten der Fall - solchen, die mit dem Inhaltstyp "application / xhtml + xml" geliefert werden. Der Großteil des Webs wird weiterhin als "Text / HTML" bereitgestellt (da der IE beispielsweise bis jetzt kein XHTML versteht) und daher von den Browsern als HTML und nicht als XML analysiert .

Sofern Sie Dokumente nicht als "application / xhtml + xml" bereitstellen, gibt es wenig Grund, CDATA-Abschnitte herumzuhängen. Auch wenn Sie in Zukunft xhtml verwenden möchten, ist es möglicherweise sinnvoll, unnötiges Gewicht aus dem Dokument zu entfernen und es erst später hinzuzufügen, wenn es tatsächlich benötigt wird.

Und natürlich besteht eine ultimative Lösung darin, Inline-Skripte vollständig zu vermeiden (um die Vorteile des Zwischenspeicherns externer Skripte zu nutzen).

3. onclick = "...", onmouseover = "", etc.

Es gibt einige gültige Anwendungsfälle für intrinsische Ereignisattribute, z. B. aus Gründen der Leistung oder um auf alte Browser abzielen zu können (obwohl mir keine Umgebung bekannt ist, die Ereignisattribute - onclick="..."und keine eigenschaftsbasierten Zuweisungen - versteht element.onclick = ...). Neben bekannten Gründen zur Vermeidung, wie Trennung von Bedenken und Wiederverwendbarkeit, gibt es auch eine Frage der Aufschlagverschmutzung. Indem wir die Ereignislogik in ein externes Skript verschieben, können wir das Caching dieses Skripts nutzen . Die Ereignishandlerlogik muss nicht jedes Mal, wenn ein Dokument angefordert wird, auf den Client übertragen werden.

4. onclick = "Javascript: ..."

Eine interessante Verwechslung von Javascript: Pseudoprotokoll und intrinsischen Ereignishandlern führt zu dieser redundanten Mischung ( mit 106.000 (!) Vorkommen ). Die Wahrheit ist, dass der gesamte Inhalt des Ereignishandlerattributs zum Hauptteil einer Funktion wird. Diese Funktion dient dann als Ereignisbehandlungsroutine (normalerweise, nachdem der Gültigkeitsbereich erweitert wurde , um einige oder alle Vorfahren und Elemente selbst einzuschließen). "Javascript:" - Zusatz wird lediglich zu einem unnötigen Etikett und dient selten einem Zweck .

5. href = "Javascript: nichtig (0)"

In Fortsetzung des Pseudoprotokolls „Javascript:“ gibt es ein berüchtigtes href="javascript:void(0)"Snippet, um das Standardverhalten von Ankern zu verhindern. Diese schreckliche Praxis macht den Anker natürlich völlig unzugänglich, wenn Javascript deaktiviert / nicht verfügbar / fehlerfrei ist. Es versteht sich von selbst, dass die ideale Lösung darin besteht, die richtige URL in href aufzunehmen und das standardmäßige Ankerverhalten in der Ereignisbehandlungsroutine zu stoppen. Wenn das Ankerelement dagegen dynamisch erstellt und dann in ein Dokument eingefügt wird (oder zunächst ausgeblendet und dann über Javascript angezeigt wird), ist plain href="#"eine schlankere und schnellere Alternative zur Version "javascript:".

6. style = ”…”

Das Stilattribut ist von Natur aus nichts Falsches, außer dass wir durch das Verschieben seines Inhalts in ein externes Stylesheet die Vorteile des Ressourcen-Cachings nutzen können. Dies ähnelt dem Vermeiden von Ereignisattributen, die bereits erwähnt wurden. Auch wenn Sie nur ein bestimmtes Element stylen müssen und nicht vorhaben, seine Stile wiederzuverwenden, sollten Sie berücksichtigen, dass die Stilinformationen jedes Mal übertragen werden müssen, wenn ein Dokument angefordert wird. Das Verschieben des Stils in eine externe Quelle verhindert dies, da das Stylesheet einmal übertragen und dann auf einem Client zwischengespeichert wird.

7. <script language = ”Javascript”…>

Wahrscheinlich ist eine der am meisten missverstandenen Eigenschaften die "Sprache" von SCRIPT. Dieses Attribut ist so archaisch, dass es bereits 1999 (!) Vor 10 Jahren veraltet war , als HTML 4.01 zu einer offiziellen Empfehlung wurde. Es gibt absolut keinen Grund, dieses Attribut zu verwenden , außer in den seltenen Fällen, in denen eine Sprachversion angegeben werden muss (und selbst das ist etwas unzuverlässig und sollte wahrscheinlich nach Möglichkeit vermieden werden).

8. <script charset = ”…”…>

Ein weiteres Missverständnis des Elements SCRIPT ist das mit dem Attribut charset. Manchmal sehe ich Dokumente, die diese Art von Markup enthalten:


  <script type="text/javascript" charset="UTF-8">
    ...
  </script>

Die Sache ist, dass das charset-Attribut nur für "externe" SCRIPT-Elemente wirklich Sinn macht - für diejenigen, die das Attribut "src" haben. HTML 4.01 sagt sogar:

Beachten Sie, dass sich das charset-Attribut auf die Zeichencodierung des durch das src-Attribut angegebenen Skripts bezieht. es betrifft nicht den Inhalt des SCRIPT-Elements.

Tests haben ergeben, dass das tatsächliche Verhalten des Browsers auch in dieser Hinsicht mit den Spezifikationen übereinstimmt.

Wenn Sie nach diesem Muster suchen, sehen Sie ungefähr 2000 Vorkommen . Kein Wunder, denn selbst beliebte Apps wie Textmate verwenden Zeichensätze falsch .

Zusätzliche Optimierungen

Wir haben einige der schlechten Praktiken behandelt, die fast immer vermieden werden müssen. Aber es liegt noch mehr vor uns, und dieses „Mehr“ bedeutet , überflüssige Teile zu entfernen . Die im Folgenden erläuterten Optimierungen sind häufig fragwürdig, da sie die Übersichtlichkeit in Bezug auf die Größe beeinträchtigen . Deshalb füge ich sie hier nicht als Empfehlung, sondern nur als Option hinzu. Mit sorgfältiger Überlegung beschäftigen.

1. <style media = ”all”…>

HTML 4.01 definiert das Medienattribut für STYLE-Elemente, um bestimmte Medien (Bildschirm, Druck, Handheld usw.) anzuvisieren. Einer der möglichen Werte für Medien ist "all", was auch ein De-facto-Standard unter modernen (und nicht so modernen) Browsern ist. Wenn Sie feststellen, dass Sie es verwenden media="all", sollte es sicher sein, es einfach wegzulassen und den Browser implizit auf einen Wert setzen zu lassen.

Interessanterweise gibt HTML 4.01 an, dass der Standardwert für Medien "Bildschirm" ist . Keiner der von mir getesteten Browser implementiert es jedoch gemäß Spezifikation und verwendet stattdessen standardmäßig "all". Dies ist wahrscheinlich der Grund, warum in HTML 5 draft der Standardwert "all" angegeben wird , um dem tatsächlichen Verhalten des Browsers zu entsprechen.

2. <form method = ”get”…>

Ein anderer Standardwert - GET - für das Attribut "method" des FORM-Elements wird häufig explizit angegeben . Es schadet nicht, es fallen zu lassen, außer bei geringerer Klarheit. Beachten Sie, dass HTML 5-Entwurf dieses Verhalten unberührt lässt .

3. <input type = ”text”…>

Der "Typ" des INPUT-Elements ist in HTML 4.01 und HTML 5 Draft standardmäßig "Text" . Das Löschen dieses Attributs kann zu erheblichen Größeneinsparungen bei Seiten mit vielen Textfeldern führen.

4. <meta http-equiv = ”Inhaltstyp”…>

Die Angabe der Zeichenkodierung des Dokuments hat immer große Verwirrung gestiftet. Entgegen der allgemeinen Meinung hat das META-Element, das den Inhaltstyp angibt, keine höhere Priorität als der HTTP-Header „Inhaltstyp“, mit dem das Dokument geliefert wird. Wenn sowohl - header als auch META-Element angegeben werden, hat der Header Vorrang.

Wenn Sie die Serverantwort steuern und den Content-Type-Header ordnungsgemäß einrichten können, ist es sicher, das META-Element wegzulassen. Der einzige Grund, es beizubehalten, ist die Angabe der Codierung, wenn das Dokument offline angezeigt wird .

5. <a id= "..." name= "..." ...>

Der Hauptgrund, warum das Attribut "name" zusammen mit "id" verwendet wird, ist die Kompatibilität mit alten Browsern (z. B. Netscape 4). Diese konnten nicht durch "id" mit Ankern verknüpft werden, daher musste "name" verwendet werden. Wenn Sie Elemente mit übereinstimmenden Namen / IDs haben und sich nicht für alte Browser interessieren, können Sie dieses archaische Muster loswerden.

Achten Sie auf mögliche Nebenwirkungen. Wenn Sie Referenzierung Elemente namentlich in Skripten ( document.getElementsByName, document.evaluate, document.querySelectorAll, usw.), ersetzt Namen mit ids könnte Dinge brechen. Denken Sie auch daran, dass document.anchors nur Elemente mit Namensattributen zurückgegeben werden .

6. <! Doctype html>

Vor etwas mehr als einem Jahr schlug Dustin Diaz vor, HTML 5-Doctype zu verwenden , um die Dokumentgröße zu reduzieren. Dies ist keine große Optimierung, aber wenn Sie sich nicht um die Validierung kümmern und jedes einzelne Byte auf der Seite ausdrücken müssen, ist die Verwendung <!doctype html>eine praktikable Option. Tests haben ergeben, dass dieser ausgefallene Doctype den Standardmodus in einer Vielzahl von Browsern auslöst.

Aggressive Optimierungen

Wenn Sie immer noch Lust auf mehr haben, finden Sie hier einige extreme Ideen. Einige davon (z. B. das Weglassen optionaler Tags) kursieren schon seit einiger Zeit. Andere habe ich nicht erwähnt gehört. Auch wenn dies zu aufdringlich erscheint, beachten Sie, dass keines von ihnen ein Dokument wirklich ungültig macht . Das heißt, wenn das Dokument in HTML ist, nicht in XHTML. Aber Sie stellen Dokumente trotzdem als HTML bereit, nicht wahr? ;)

  1. HTML-Kommentare entfernen
  2. Leerzeichen entfernen / reduzieren
  3. Optionale schließende Tags entfernen ( <p>foo</p><p>foo)
  4. Entfernen Sie Anführungszeichen um Attributwerte, wenn dies zulässig ist ( <p class="foo"><p class=foo>)
  5. Optionale Werte aus booleschen Attributen entfernen ( <option selected="selected"><option selected>)
  6. Munge-Inline-Stile, Inline-Skripte und Ereignisattribute (wenn es nicht möglich ist, sie zu entfernen)
  7. Munge-Klassen und IDs (müssen mit Skripten und Style-Deklarationen synchronisiert sein)
  8. Schemanamen von URLs entfernen ( http://example.com//example.com)

Aber wir haben Komprimierung!

Sind all diese Optimierungen auch dann von Bedeutung, wenn das Dokument komprimiert wird? Beseitigt gzip nicht den größten Teil des Markup-Overheads? Immerhin handelt es sich um ein Textformat, über das wir sprechen!

Es ist immer noch wichtig.

Zuallererst ist es gut sich daran zu erinnern, dass nicht jeder gzip bekommt . Das ist sehr traurig, aber das Gute ist, dass in solchen Fällen die HTML-Optimierung eine noch wichtigere Rolle spielt.

Zweitens, auch wenn das Dokument komprimiert geliefert wird, sind nach der Komprimierung (bei einem durchschnittlichen Dokument) noch Einsparungen von 5 bis 10 KB möglich . Bei großen Dokumenten sind die Einsparungen sogar noch größer. Dies scheint nicht viel zu sein, aber in Wirklichkeit zählt jedes Byte .

Als Beispiel für das Komprimieren eines großen Dokuments habe ich die inoffizielle HTML-Version von ECMA-262, 3. Auflage , die ursprünglich etwa 750 KB (131 KB mit ZIP) wog, auf 606 KB (115 KB mit ZIP) verschoben. Dies entspricht einer Einsparung von 16 KB nach dem Gzippen , indem Leerzeichen, Kommentare, Attribut-Anführungszeichen und optionale Tags entfernt werden. Die optimierte Version sieht genauso aus wie die alte.

Optimierungen wie das Entfernen von Leerzeichen und Kommentaren machen den resultierenden Dokumentbaum leichter und verbessern möglicherweise die Leistung beim Rendern von Seiten.

Wenn Dinge schief laufen

Wie bei jeder Optimierung ist es sehr einfach, sich mitreißen zu lassen. HTML Compact ist ein gutes Beispiel für eine zu weit gehende HTML-Komprimierung. Diese wundervolle Windows-App bietet einen „einzigartigen“ Ansatz zum Komprimieren von HTML-Code, indem sie über Javascript in ein Dokument geschrieben wird.

Drehen Sie dieses perfekt saubere Dokument:


  <html>
    <head>
      <title></title>
    </head>
    <body>
      <div>
        <ul>
          <li>foo</li><li>bar</li><li>baz</li>
          <!-- few more dozens of list elements ... -->
        </ul>
      </div>
    </body>
  </html>

in dieses Chaos:


<!--hcpage status="compressed"-->
<html>
  <head>
    <SCRIPT LANGUAGE="JavaScript" SRC="hc_decoder.js"></SCRIPT>
    <title></title>
  </head>
  <BODY>
    <NOSCRIPT>To display this page you need a browser with JavaScript support.</NOSCRIPT>
    <SCRIPT LANGUAGE="JavaScript">
      <!--
        hc_d0("Mv#d|\x3C:,&c@w4YFAtD1 [... and so on, another couple hundreds of characters ...]");
      //-->
    </SCRIPT>
  </BODY>
</html>

Selbstverständlich sollte diese Art der „Optimierung“ niemals im öffentlichen Internet durchgeführt werden. Es sei denn, die Absicht besteht darin, Dokumente für Benutzer und Suchmaschinen unzugänglich zu machen. Und es tut mir weh, diese NOSCRIPT-Elemente zu sehen, die bei Clients hinter JavaScript-blockierenden Firewalls zu kurz kommen . Schlechte Idee, schlechte Ausführung.

Antimuster

Das vorherige Snippet war ein gutes Beispiel für die Optimierung von Anti-Patterns. Es gibt jedoch nur wenige, die Sie beachten sollten:

1. doctype entfernen

HTML Compresor bietet standardmäßig die Option, Doctype zu entfernen. Ich kann mir keinen Fall vorstellen, in dem das Abisolieren von Vorteil wäre. Im Gegenteil, ein fehlender Doctype löst den Quirks-Modus aus und führt infolgedessen zu Chaos in Bezug auf Seitenlayout und -verhalten. Doctypes sollten alleine gelassen oder durch eine kürzere - HTML 5 - Version ersetzt werden.

2. Ersetzen Sie STRONG durch B und EM durch I

Eine weitere schädliche Option im selben HTML-Kompressor ist das Ersetzen von Elementen durch kürzere "Alternativen". Das Problem hierbei ist, dass B keine echte Alternative zu STRONG ist. Ich bin auch kein Ersatz für EM. STRONG- und EM-Elemente haben eine semantische Bedeutung - Betonung , während B und ich einfach Elemente im Schriftstil sind; Sie wirken sich auf die Textwiedergabe aus, haben jedoch keine semantische Bedeutung.

Obwohl Browser diese Elemente normalerweise identisch anzeigen, verstehen Screenreader und Suchmaschinen den Unterschied sehr gut.

3. Entfernen von title-, alt-Attributen und LABEL-Elementen.

Eine gute Faustregel ist, niemals im Austausch der Zugänglichkeit zu optimieren . Sie könnten versucht sein, dieses optionale „Alt“ -Attribut für IMG-Elemente oder „Titel“ für Anker zu entfernen, aber das Speichern von wenigen Dutzend Bytes ist einen oft kritischen Verlust an Barrierefreiheit nicht wert.

Werkzeuge

Es ist mehr oder weniger trivial, die meisten Änderungen aus dem Abschnitt "Zusätzliche Optimierungen" zu automatisieren . Es gibt bereits Tools, mit denen Kommentare, Leerzeichen und Anführungszeichen um Attributwerte entfernt werden können. Diese stecken jedoch noch in den Kinderschuhen und führen nur sehr wenige Optimierungen durch. Wir können es definitiv besser machen.

Vor ein paar Monaten haben Hakunin und ich angefangen, an einem ähnlichen, auf Ruby basierenden Kompressor zu arbeiten , hatten aber nie die Chance, ihn zu beenden.

Was haben wir bisher?

  1. Absoluter HTML-Kompressor (Desktop, Windows)

    Tut großartige Arbeit, aber erst, nachdem Optionen wie das Entfernen von doctype und das Ersetzen von STRONG durch I deaktiviert wurden.

  2. HTML Compact (Desktop, Windows)

    Macht das Dokument unzugänglich. Vermeiden .

  3. HTML-Kompressor (Desktop, Windows)

    Entfernt nur Leerzeichen und auch in für Leerzeichen sensiblen Elementen wie PRE. Nicht sehr nützlich .

  4. Pretty Diff (webbasiert)

    Keine Option, um Leerzeichen vollständig zu entfernen (sie werden nur minimiert). Führt keine Optimierungen durch, außer das Ausblenden von Leerzeichen und das Entfernen von Zeilenumbrüchen. Respektiert keine Whitespace-sensitiven Elemente. Nicht sehr nützlich .

  5. htmlcompressor (Java-basiert)

    Führt die meisten der hier beschriebenen Optimierungen durch (entfernt jedoch keine optionalen Tags oder verkürzt die booleschen Attribute). Respektiert Whitespace-sensitive Elemente. Es ist im Moment mehr oder weniger die beste Option .

Wie Sie sehen, ist der aktuelle Stand der Dinge ziemlich enttäuschend. Es scheint keine Komprimierungswerkzeuge für Mac / Linux zu geben, und solche für Windows sind kaum nützlich.

Zukünftige Überlegungen

Während Mungieren und Strippen während der Produktion durchgeführt werden kann (und sollte), sollten Markup-Gerüche niemals auftreten . Weder in der Produktion noch in der Entwicklung. Nur, wenn sie aus irgendeinem Grund unbedingt erforderlich sind.

Es ist nicht überraschend, dass die beste Optimierung häufig manuell durchgeführt werden kann: Ändern der Dokumentstruktur, um zu vermeiden, dass Klassen für mehrere Elemente wiederholt werden (und stattdessen in das übergeordnete Element verschoben werden), oder Eliminieren von Teilen, die nicht sofort benötigt werden, und stattdessen dynamisches Laden. Das Ersetzen von Miriaden von <br>oder &nbsp;, die für Präsentationszwecke ineffizient verwendet werden, oder dieses alte tabellenbasierte Layout sind weitere gute Beispiele für die manuelle Reinigung.

Was all die anderen kleinen Verbesserungen angeht, erwarte ich, dass in naher Zukunft weitere Komprimierungswerkzeuge auftauchen werden, die die Grenzen der Größenreduzierung noch weiter verschieben.

Wenn Sie weitere Möglichkeiten zur Optimierung von HTML kennen, teilen Sie diese bitte mit. Über Fragen, Anregungen oder Korrekturen würde ich mich freuen.

  1. Getestete Browser waren:
    Firefox 1, 1.5, 2, 3, 3.5;
    Opera 7,54, 8,54, 9,27, 9,64, 10,10;
    Safari 2.0.4, 3.0.4, 4;
    Chrome 4 - unter Mac OS X 10.6.2.
    Internet Explorer 6, 7, 8 unter Windows XP Pro SP2 und
    Konqueror 4.3.2 unter Ubuntu 9.10.