Ladezeit einer Webseite messen und verbessern

Seitdem Google die Ladezeit einer Webseite offiziell als Rankingkriterium angibt, fragen sich viele Webseitenbetreiber, wie kann ich überhaupt die Ladezeit meiner Webseite messen und ggf. verbessern? Wie schnell ist eine gute Ladezeit und welchen Einfluss hat die Ladezeit einer Webseite wirklich auf das Ranking? Dieser Beitrag beantwortet diese Fragen und zeigt Schritt für Schritt, wie man die Ladezeit (s)einer ganz normalen Webseite verbessern kann, ohne gleich ein CDN (dazu gleich mehr) einzusetzen?

Ladezeit einer Webseite messen

Bevor man an die Ladezeit einer Webseite herangeht, muss man die Ladezeit natürlich erstmal messen (können). Wichtig zu wissen ist, dass die Ladezeit variiert, je nachdem wie schnell der ausliefernde Server, die Internet-Leitung, der abfragende Computer, usw. gerade sind. Daher wird es nie einen absoluten Wert für die Ladezeit geben. Um die erreichten Verbesserungen aber zu werten, brauchen wir zumindest gleichbleibende Bedingungen. Es gibt zahlreiche Online-Tools zur Ladezeitmessung, von denen ich eigentlich nur Google Page Speed Insights und Pingdom empfehlen kann. Dennoch sollte man Einflussgrößen reduzieren, so dass ich empfehle lokal zu messen. Denn letztlich zählt die reale Ladezeit und nicht die Note eines Tools.

Wieso überhaupt die Ladezeit verbessern?

Kein Internetsurfer wartet. Die Geduld dürfte je nach Thema und zu erwartendem Inhalt bei wenigen Sekunden liegen. Es ist einfach benutzerfreundlich, eine schnell ladende Webseite anzubieten. Es gibt einige Studien größerer Websites und Shops, die zeigen, dass mit jeder Millisekunde weniger, die Käufe usw. deutlich steigen.
Zweitens schont es den Webserver, der weniger ausliefern muss und besser, schneller ausliefern kann. Das wird zwar meistens egal sein, schaden kann es aber keinesfalls.
Drittens könnte es für’s Google-Ranking etwas bringen, oder?

Ladezeit ein Ranking-Faktor?!

Seit 2010 ist die Ladezeit einer Webseite offizieller Ranking-Faktor bei Google (Quelle). Allerdings ist das nur ein Faktor von über 200 und laut Matt Cutts von Google nur bei 1% der Suchanfragen für eine Ergebnisänderung verantwortlich.
In einigen Videos sagen Matt Cutts und Johannes Müller auch, dass lediglich die Sensibilität der Webmaster durch Aufnahme als Kriterium auf die Ladezeit gelenkt werden soll und nur wirklich lahme Seite einen Dämpfer bekommen.

Wie schnell ist eine schnelle Ladezeit?

Folglich zeigt Google in den Webmaster Tools (unter Google Labs, Website-Leistung) auch die Ladezeit der einzelnen Seiten an. Laut Google lädt eine Webseite dann schnell, wenn die Ladezeit unter 1,5 Sekunden liegt.

Schritt für Schritt die Ladezeit einer Webseite verbessern

Es gibt für Seiten mit sehr hohem Traffic eine gute Anleitung bei Yahoo. Für „normale“ Webseiten dürften die wichtigsten Punkte bei überschaubarem Aufwand bereits wesentliche Verbesserungen erzielen (80/20 Prinzip).

1. HTTP-Zugriffe reduzieren

Jede Datei, die der Browser zur Anzeige laden muss, kostet Zeit. Dies ist der größte Einfluss-Faktor (dürfte über 80% der Ladezeit ausmachen). Jede CSS-Datei, jede JS-Datei, jede Grafik usw. kosten allein durch den zusätzlichen Aufruf Zeit, messbar und spürbar Zeit.

Alle überflüssigen Zugriffe raus

Schaut einfach in den Quelltext und fragt Euch, ob man wirklich jede Datei benötigt. Vielleicht macht irgendeine Toolbar gar keinen Sinn etc. – raus damit (vgl. einfacheres Blog-Design).

Dateien zu einer zusammenfassen

Gerade in Templates, Themes oder Webseitenbaukästen werden viele einzelne CSS und JS-Dateien geladen. Das sind alles einzelne Anfragen.
Man sollte zumindest alle CSS-Dateien und alle JS-Dateien in jeweils eine einzige CSS- und JS-Datei zusammenfassen. Die CSS-Datei lädt man im head der Webseite und die JS-Datei im footer. JavaScript-Dateien gehören ans Ende, da diese meist zur korrekten Anzeige nicht erforderlich sind und der Besucher die Seite schon im oberen Bereich sieht, wenn noch die JS-Datei lädt.
Das kann bei schlechten WordPress-Plugins oder Frameworks wie jQuery etc. ordentlich Zugriffe und Zeit sparen.

Wer noch einen Schritt weiter gehen möchte (Stichwort: blockierende Ressourcen, kritischer Renderingpfad), der sollte die Teile der CSS-Datei inline im head ausgeben, die für den sichtbaren, oberen Bereich der Seite erforderlich sind. Der Rest der CSS-Anweisungen sollte als Dateilink in den footer.
Weiter sollte man JavaScript asynchron laden, so dass es erst nach komplettem Laden der Seite selbst geladen wird. Das gilt auch beispielsweise für den Google Analytics-Code.

CSS-Sprites

Manche Aufrufe sind indirekt und im Quelltext daher so nicht direkt zu sehen. So werden beispielseise in den CSS-Anweisungen auch Grafiken geladen. Jede solche Grafik verursacht einen HTTP-Zugriff und damit Ladezeit. Daher versucht man, solche Grafiken zu möglichst wenigen zusammenzufassen und jeweils nur den passenden Ausschnitt im Hintergrund anzuzeigen (CSS Sprites). Bei sehr hoch frequentierten Seiten kann man das gut sehen, da diese das natürlich bis zum Extrem betreiben (müssen).

Der Einfachheit halber könnte man drei Grafiken machen: horizontale, vertikale und statische Hintergründe. Je nach Sichtbarkeit wird dann eine der drei eingesetzt. Ein neuer, recht kreativer Ansatz schlägt diagonale Sprites vor.

Gerade bei beliebten typischen Icons kann man auch mit einer individuellen Icon-Schriftart arbeiten, was ebenfalls Zugriffe einspart und neue gestalterische Möglichkeiten eröffnet.

Content-Delivery-Networks (CDN)

Da Browser nur eine begrenzte Anzahl von Dateien vom selben Host parallel laden, kann man beispielsweise alle Inhaltsbilder auf einen anderen, schnellen Server oder eine Subdomain (CDN) auslagern und so mehrfach parallel die Seitenbestandteile laden, also mehr Zugriffe zur geichen Zeit erreichen. Aus meiner Sicht ist das aber für normale Seiten wegen des Aufwands und der meist zusätzlichen Kosten übertrieben. Einzig die Subdomain für statische Inhalte kann im Üblichen Rahmen andenken, diese sollte dann aber keine Cookies ausliefern. Da Cookies meist domainweit gelten, muss man da aktiv werden. So kann man beispielsweise Google Analytics mit _gaq.push(['_setDomainName', 'blog.netprofit.de']); auf eine (Sub)Domain begrenzen oder WordPress in der wp-config.php per define('COOKIE_DOMAIN', 'blog.netprofit.de'); einschränken.
So oder so kann man beispielsweise sehr einfach jQuery und andere Standardbibliotheken über Google (in komprimierter Form) laden. Dies ist schnell, ein externer Host und vielleicht schon im Browser-Cache des Besuchers. Also durchaus clever.

2. Komprimieren

Bilder lassen sich meist in geringerer Auflösung ohne sichtbaren Qualitätsverlust anzeigen. Das spart richtig ordentlich Dateigröße und damit Ladevolumen. Nur wo liegt die Grenze? Hier helfen Tools wie Y!Slow, das via Smush It einem die Arbeit ganz ordentlich abnimmt. Das kann man auch isoliert online nutzen: www.smushit.com
So kann man ganz einfach nochmal richtig Dateigröße sparen, ohne sichtbare Einschränkungen für den Besucher. Daher Bilder auch nicht per CSS oder HTML skalieren, sondern gleich in passenden Dimensionen speichern. Das können mittlerweile alle besseren CMS ganz gut.

Auch HTML, CSS, JS, … sind komprimierbar. Kompression spart durchschnittlich 70%. So kann man die Klartext-Dateien schon reduzieren, indem man Kommentare, Leerzeilen etc. entfernt. Im CSS kann man Shorthand verwenden und beispielsweise die abschließenden ; entfernen. Zusätzlich kann man diese Dateien komprimiert an den Browser ausliefern, was die Übertragunsgröße enorm mindert. Das Entpacken und Anzeigen kostet dann zwar Rechnerleistung beim Anzeigenden, an der es aber ja meist nicht mangelt.
Diese Dateien kann sollte man mit gzip komprmieren und abspeichern. Per .htaccess kann man dann je nach Dateiformat die .gz-Versionen ansteuern lassen. Hat der Apache-Server das Modul mod_deflate geladen, kann man auch einfach per .htaccess ein AddOutputFilterByType DEFLATE erreichen.

3. Cache erlauben

Viele Dateien einer Webseite ändern sich sehr selten. Ein Teil der Besucher dürfte also bei weiteren Besuchen theoretisch die identischen Dateien sehen, die sein Browser schon einmal (in den Zwischenspeicher) geladen hatte. Wieso also idese Dateien nochmal vom Server holen, wenn der Besucher die schon auf dem Rechner hat?
Dazu muss man serverseitig den Expires-Header (und Cache-Control) jeder Datei übertragen, damit der Browser das auch erkennt. Dazu muss der Apache Server das Modul mod_expires aktiviert haben. Dann lässt sich per .htaccess je nach Dateityp ein Gültigkeitszeitraum einfach festlegen.
Ändert man aber die CSS-Datei muss man auch deren Namen ändern, um ein Laden der alten CSS-Datei bei diesen Besuchern zu vermeiden.

4. Sonstige Bremsen vermeiden

• Sehr viele Redirect-Anweisungen in der .htaccess beeinträchtigen die Ladezeit extrem. Also versucht man diese soweit wie möglich zu vermeiden.
• Weiter sind oftmals externe Zugriffe auf Twitter-Buttons, Bookmark-Buttons, Statistik-Codes, Feedleser sehr, sehr ladezeitintensiv. Da diese Dienste sehr viele Anfragen beantworten müssen, reagieren diese oftmals sehr, sehr langsam. Daher sollte man solche Grafiken (in Sprites) lokal speichern und die Werte ggf. lokal zwischenspeichern und nur alle paar Stunden aktualisieren.
• 404-Fehler vermeiden. Werden zu ladende Dateien nicht gefunden, kann das die Ladezeit etxrem verlängern. Selbst wenn nur irgendein kleines Icon fehlt, das dauert! Also prüfen, da sich das sehr leicht beheben lässt.

Wenn selbst dann die Ladezeit der Webseite wegen zu vieler Besucher zu langsam ist, erst dann kommt die Tim Taylor-Methode als Lösung in Betracht: More Power! Für den Großteil der Webseiten dürfte es bei Ladezeitproblemen aber reichen, die obigen Schritte abzuarbeiten. Dann muss auch kein stärkerer Server her.

Weiterlesen

Empfehlenswert ist die Serie High Performance von Netways, Details zur Dateikomprmimierung bei Bildern von Webstandards, Möglichkeiten bei WordPress von Frank und Diskussion zum Rankingfaktor bei SEO United.