Wann beginnt der Browser mit dem Parsen des HTML-Codes?

[mgutt]

Hallo,

so könnte ich mir das vorstellen:
1.) HTML-Dokument ungepackt: Parsen beginnt noch während dem Download
2.) HTML-Dokument gepackt: Parsen beginnt erst nach Download und Entpacken der Datei

Wenn ich aber meinen Test richtig ausgewertet habe, wird in beiden Fällen erst nach dem vollständigen Download angefangen. Sehe ich das richtig? Mich wundert das, da ja insbesondere die Kopfdaten wie z.B. externe CSS- und JS-Dateien bereits parallel geladen werden könnten und nicht erst wenn die Datei vollständig zur Verfügung steht.

Gruß

 

[Efchen]

Das ist von Browser zu Browser unterschiedlich. Ältere Browser haben mit dem parsen oft gewartet, bis alles geladen wurde.
Heute ist es aber so, dass geparsed wird, sobald ordentlicher Code gefunden wurde, also definitiv schon bevor alles geladen ist. Das kann man ja beim Besuchen verschiedenster Websites so beobachten.
Richti ist, dass andere Ressourcen, die im Dokument verlinkt sind, parallel vom Server angefordert werden.

Frage: Kann man HTML-Dokumente packen? Das höre ich zum ersten Mal.

 

[skizZ]

Frage: Kann man HTML-Dokumente packen? Das höre ich zum ersten Mal.

Der Unterschied zwischen "gepackt" und "ungepackt" interessiert mich auch

 

[bieder-design]

Ich denke mal er spricht von der sogenannten http-Komprimierung.
Die http-Komprimierung ist auf Apache Servern, sowie auch auf IIS möglich und nahezu jeder heutige Browser ist in der Lage solche komprimierten Dateien zu verwerten (ja, sogar der IE).

Die bekannteste Form der Komprimierung ist das Apache Modul "mod_gzip". Mit diesem Modul lassen sich zwei verschiedene Komprimierungsstrategien umsetzen. Man kann zum einen seine statischen Seiten als gzip-Versionen vorhalten oder man kann "on-the-fly" packen.
Die "pre-compressed" Methode hat natürlich einen Performance-Vorteil gegenüber der "on-the-fly" Methode, da nicht bei jedem Request neu komprimiert werden muß.
"on-the-fly" Komprimierung ist vor allem bei dynamischen Inhalten praktisch(z.B. per Datenbankabfrage erstellte Seiten).

Der größte Positive Effekt der http-Komprimierung ist ein geringerer Banbreiten-/Traffic Bedarf, sowie auch schnellere Ladenzeiten (vor allem für schmalbandig angebundene User).

Sollte kein "mod_gzip" auf dem Server zur Verfügung stehen, kann man auch einfach eine simple Änderung in der .htaccess Datei, oder in der Apache-Config vornehmen (eine Zeile abändern und drei hinzufügen). Dann muß nur noch (falls verwendet) die z-lib Komprimierung abgeschaltet werden und die Komprimierung ist per Voreinstellung aktiviert.

Die http-Komprimierung funktioniert mit allen .php, .html und .htm - Dateien.

Ich hoffe damit ist euer Wissensdurst vorerst befriedigt. Das Komprimieren von Webseiten ist also heutzutage völlig normal um Traffic und Ladezeiten einzusparen.

 

[Efchen]

Wobei man sich fragt, ob das sich bei den paar KiB, die so eine HTML-Seite hat, wirklich lohnt.

Aber danke für die ausführliche, gute Erklärung!

 

[bieder-design]

Nein, das lohnt sich definitiv nicht bei kleinen Otto-Normal Verbraucher Seiten. Aber es gibt durchaus Bereiche, wo es bedeutend größere Seiten gibt. Aus eigener Erfahrung kann ich Dir da zum Beispiel "nicht-öffentliche" Militärprojekte und "Informations-Dienste" (um es mal freundlich auszudrücken) nennen, die ohnehin schon recht große Seiten haben und diese dann noch durch mehrere Kryptierungen künstlich aufblasen. In diesen Bereichen wird es definitiv eingesetzt.

Allerdings muß ich auch zugeben, das ich persönlich es noch nicht erlebt habe, das die http-Komprimierung im zivilien Bereich wirklich sinnvoll eingesetzt wurde.

 

[crash]

Komprimierung lohnt sich meistens erst dann, wenn das HTML gecached wird und somit nicht ständig neu gezip't werden muss.

Ansonsten wird das HTML seit HTTP 1.1 in Chunks (Teilen) übertragen und das Parsen beginnt, wenn der erste Teil wieder geentzip't wird. Danach der nächste Teil usw. Das ging nur bei HTML, bei XHTML war dies über eine lange Zeit nicht möglich. Z.B. ist das partielle Parsen von XHTML-Dateien (die als XHTML gesendet werden) erst seit Firefox 3 drin. Vorher musste die ganze Datei vorhanden sein, um mit dem Rendern zu beginnen. Danach wurde erst die Ressourcen geladen (CSS, Bilder, etc). Das war sozusagen eine Einschränkung in XML, da sonst der XML-Parser Fehler warf.