Web Developer Toolbar's View Document Size
Eine perfekte Übersicht über die Zusammensetzung der Dokumentengröße bietet die Web Developer Toolbar (für Firefox). Sie zeigt nicht nur auf, wie groß das einzelne HTML-Dokument ist, sondern auch die Größen der eingebundenen CSS- und Javascript-Dateien, sowie die (durch CSS und HTML) verwendeten Bilder. Zu finden ist das Werkzeug unter Information.
Web Developer Toolbar's View Speed Report
Eine Ergänzung der zuvor genannten Funktion ist (Tools) View Speed Report. Hier wird auf den Dienst von WebSiteOptimization.com zurückgegriffen. Dort wirden HTTP-Request und geschätzte Ladezeiten verschiedener Internet-Verbindungen aufgezeigt.
Optimierungsmethoden der Website-Ladegeschwindigkeit
1. gZIP-Komprimierung der von PHP ausgelieferten HTML-Dokumente
Bei der gZIP-Komprimierung werden alle Ausgaben von PHP dem Empfänger gezipped angeboten. Moderne User-Agents (Browser) unterstützen diese Technologie. Falls die gezippten Ausgaben angenommen werden, können Traffic-Ersparnisse von bis zu 50% erreicht werden.
Die komprimierten Dokumente werden erst nach dem Empfang vom Browser extrahiert und gerendert. Das Extrahieren kann bei älteren Rechnern zu kurzen Verzögerungen führen. Wenn der alte Rechner aber eh mit einem Browser ohne gZIP-Support fährt, kriegt er die HTML-Dokumente sowieso direkt und ungepackt.
-
Über .htaccess oder httpdspezial
Ein kleiner Eintrag sorgt dafür, dass der Webserver PHP's Ausgaben als gZIP an den Client schickt. Hier kann aus 9 unterschiedlich starken Komprimierungsstufen gewählt werden. Meine Tests haben aber gezeigt, dass nur die 2. Komprimierungsstufe von den Browsern unterstützt wird.
php_flag zlib.output_compression on
php_value zlib.output_compression_level 2 -
Als PHP-Funktion
Man kann die gZIP Komprimierung auch mit einer PHP-Funktion aktivieren. Diese muss aber entweder in jeder einzelnen PHP-Datei aufgerufen werden oder in der Datei, die ggf. alle anderen Dateien über
require()oderinclude()inkludiert.ob_start('ob_gzhandler');
2. Komprimierung der CSS-Dateien
Es gibt viele CSS Optimizer, die eine CSS-Datei auf ihr Minimum reduzieren können. Es werden unter anderem das letzte Semikolon einer Regel und Zeilenumbrüche gelöscht und Anweisungen wie padding-top und padding-bottom zusammengefasst. Folgende Optimizer sind empfehlenswert:
Der große Nachteil der CSS-Komprimierung ist der Verlust der Leserlichkeit. Einmal komprimierte CSS-Dateien sind schwer zu warten/erweitern. Daher empfehle ich ausdrücklich, CSS-Dateien erst nach ausgiebigen Tests und "Reifezeit" zu komprimieren.
3. Komprimierung der JS-Dateien
Die Komprimierung von Javascript-Dateien verläuft bei den meisten Kompressoren folgendermaßen: Ausdrücke, wie Funktionsnamen, Werte oder Variablen erhalten eine ID, die bei jedem Aufruf/bei jeder Verwendung wiederholt wird. Am Ende der Datei werden die Zahlen wieder mit den Ausdrücken verbunden. Da (meist nur 2-3 stellige) Zahlen weniger Speicher beanspruchen als lange Variablen- oder Funktionsnamen wird die Datei zwangläufig kleiner, ist aber nach der Komprimierung kaum noch für das menschliche Auge lesbar.
Ein Vergleich verschiedener CSS-Optimizer: http://mathiasbynens.be/archive/2005/09/css-compressors
Und Du hast ja gestern schon darauf hingewiesen - aber nur, um Deine Liste zu komplettieren noch einmal der Hinweis auf den exzellenten Vortrag von Steve Souders:
http://www.skrenta.com/2007/05/14_rules_for_fast_web_pages_by_1.html
Die Gesamtladezeit ist eine Sache. Die Zeit, bis eine Seite nutzbar ist, ist eine andere Sache. Wenn eine html-Datei keine inline-Styles und kein inline-Javascript hat, sondern externe Dateien nutzt, und auch schon ohne css und ohne Bilder und ohne Javascript nutzbare Resultate liefert, dann ist die Restladezeit nicht mehr ganz so erheblich. Ein sehr beliebter Fehler hier ist, daß man Text graphisch hinterlegt, aber vergisst, dem Text auch eine geeignete Hintergrundfarbe zu verpassen. So wird der Text erst lesbar, wenn die Hintergrundgrafik geladen und angezeigt ist. Solche Schwächen lassen sich mit einfachen Mitteln vermeiden, wodurch die wirklich relevante Ladezeit drastisch schrumpft.
Ein weiteres gutes Mittel zur Ladezeitoptimierung ist Cacheing. Dazu müssen a)so viele Bestandteile wie möglich statisch sein, diese Bestandteile b)per .htaccess eine geeignete expires Zeit bekommen, und c)müssen solche Bestandteile so weitgehend wie möglich wiederverwendet werden. Durch sorgfältiges Design lassen sich so beinahe Wunder bewirken.
Expires und Caching sind interessante Themen. Ich werde es in einem der folgenden Artikel einmal aufgriefen. Danke für den Artikel-Tipp!
Bitte, gern geschehen :) Ich bin schon gespannt auf den Artikel. Ich habe zwar schon etwa 7 bis 8 Jahre Erfahrung mit Caching, aber man kann eigentlich immer noch was dazu lernen.
Danke für die drei Schritte, ich werde es unserem Kollegen sagen. Er möge das bei der neuen Seite dringend beachten.
Danke!
Heinz :-)
gZIP über htaccess war mir noch nicht bekannt. Verstehe ich das richtig: Bots fordern gzip an, normale Browser eine ungezippte Variante?
Wenn der Server selbst nicht der schnellste ist, kannst du mit gzip zwar Traffic sparen, es kommt aber nicht zu Performancesteigerungen. Ich habe sehr viel Geschwindigkeit durch ein wenig Apache-Tuning rausgeholen können. Kleine Änderungen an den richtigen Stellen der httpd.conf können Wunder bewirken. Leider ist es nicht einfach diese Stellen zu finden...
Ich bekomme von Google Webmastertools die Gzuip Komprimierung vorgeschlagen.
Hat jemaand mehr Erfahrung damit ob das wirklich was bringt?
Danke
Christian
13.05.2007
Guter Artikel, wo ich jedoch die meisten Fehler bei den Kollegen finde ist meist das Bildmaterial. Hier werden gerne die unpassenden Formate gewählt oder nicht richtig komprimiert. Worauf man auch schon beim schneiden des Layouts achten sollte ist, das Layout in so wenige Einzelbilder wie nur möglich zu zerlegen, das ist meist sogar flexibler und schon die HTTP-Requests.
WebSiteOptimization.com finde ich persönlich nicht mehr als Zeitgemäß, für einen ungefähren Ladezeitcheck sicherlich ok, allerdings finde ich das Feedback unten doch sehr hart, wird hier doch eine absolute Datenmenge von 30Kb angepeilt...wie ich finde bei 95% aller heutigen Seiten unschaffbar.