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?
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.
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?
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.
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.
Ladezeit Beispiel in den Google Webmaster Tools
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).
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.
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).
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.
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.
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.
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.
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.
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.
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.
Im Blog schreibt Robert Hartl über CMS, SEO & Webdesign. Kontakt →
Trackback-URL: https://www.netprofit.de/blog/ladezeit-webseite-messen-verbessern.html/trackback
Danke für die „Checkliste“ 😉
Hab zunächst meine Seite mit Pingdom getestet, aber bei drei Tests drei verschiedene Ergebnisse bekommen. Demnach lag die Ladezeit zwischen 0,4 und 1,3 Sekunden. Beides zwar recht gute Werte, aber irgendwie gefällt mir das nicht.
Lade gerade Firebug runter und werde dann mal die anderen beiden Tools ausprobieren 🙂
R. Böhme
Kommentar 2
17. September 2010 um 19:55 Uhr
Also irgendwie komme ich hier immer auf die Zahlen, die mir auch Google Webmaster Tools anzeigt. Vielleicht schwankt es ja irgendwann mal, aber gestern wars bei Pingdom und Google gleich.
[Anm. Admin: wer so heißt, hat keine Webseite, Link entfernt]
Gebäudereinigung Frankfurt
Kommentar 3
22. September 2010 um 16:25 Uhr
Danke für das kleine Manual,
ich hab das ma alles ordentlich durchgeackert und siehe da. Da kann man schon noch einiges finden um die Seiten schneller und besser zu machen.
Ganz wichtig ist meiner Meinung nach die Geschichte mit den CSS-Sprites.
TX
Daniel
Daniel →
Kommentar 4
19. Juni 2011 um 17:30 Uhr
Ich nutze auch das JQuery von Google. Da es aber 185kB groß ist, wird die Ladezeit von allen Analyse-Tools immer als „mangelhaft“ erachtet. Was kann man da tun?!
Admin →
Kommentar 5
21. Juli 2011 um 17:46 Uhr
Hallo,
wen die Ladezeit seiner Webseite interessiert, sollte hier einmal vorbeischauen.
https://www.uptrends.com/de/tools/website-ladezeit-check
Dort könnt Ihr die Ladezeit von unterschiedlichen Standorten aus messen und erhaltet eine Wasserfall Grafik mit Details zum Ladeprozess der gesamten Seite und jedes einzelnen Elements. Damit lässt sich im Detail analysieren, wenn es Probleme gibt.
Gruß
Ralf
Ralf →
Kommentar 6
19. November 2014 um 17:58 Uhr
Für Joomla User empfehle ich das Plugin „JCH Optimizer“. Es kombiniert CSS und Javascripte, minifiziert den Quellcode, bietet lazy loading für Bilder usw. Macht die Seite spürbar flotter.
Maximusweb →
Kommentar 7
17. Juli 2020 um 17:48 Uhr
Kommentare werden erst nach manueller Freischaltung sichtbar. Die übermittelten Daten werden entsprechend der Datenschutzerklärung zur Verarbeitung des Kommentars gespeichert.
Nibelungenplatz 2
D-94032 Passau
Tel.: +49 (0)851/ 966 31-31
Fax: +49 (0)851/ 966 31-41
E-Mail: kontakt@netprofit.de
Sehr guter Artikel, werde demnächst auch die Ladezeit messen, um die Website zu verbessern. Danke für die wertvollen Tipps dazu!
Kommentar 1
17. August 2010 um 10:05 Uhr