morefire
MENÜ

Wie Sie die Ladezeit Ihrer Webseite erfolgreich optimieren


Die Ladezeit einer Webseite ist ein wichtiger Aspekt in der Usability sowie ein offizieller Rankingfaktor in der Suchmaschinenoptimierung. In diesem Artikel möchte ich darauf eingehen, welche Methoden und Techniken am besten für eine optimierte Ladezeit geeignet sind und wie man diese umsetzt.

Gute Ladezeiten machen Nutzer glücklich

Läuft eine Webseite schnell und ohne Probleme wird das Ihre Nutzer glücklich machen. Eine gute User Experience führt zu einer besseren Conversion-Rate und senkt die Absprungrate.

Da die Optimierung der Ladezeit etwas umfangreichere technische Skills verlangt sowie in manchen Fällen einiges an Aufwand erfordert, ist es wichtig, dass der Workflow zur Umsetzung sauber gehalten wird. Arbeiten Sie die hier gezeigten Maßnahmen am besten immer Schritt für Schritt ab, überlegen Sie sich, ob Sie einzelne Maßnahmen selbst umsetzen können oder Hilfe dafür benötigen. Wenn Sie nur halbherzig bei der Sache sind, werden Sie nicht viel von der investierten Arbeit haben.

Wenn Sie diese Dinge beachten, sollte einer guten Umsetzung nichts mehr im Wege stehen.

Inhaltsverzeichnis

  • HTML/CSS, Skripte und Bilder optimieren
  • JavaScript am Ende laden
  • Outsourcing von JavaScript-Libraries und Frameworks
  • Das Caching von Inhalten
  • Browser-Caching und Komprimierung aktivieren
  • Content Delivery Network nutzen
  • Die Performance unter WordPress
  • Das Fazit

HTML/CSS, Skripte und Bilder optimieren

Der erste Schritt der Optimierung sollte immer die Reduzierung der Dateigrößen von CSS/HTML und JavaScript-Dateien sein. Dies kann man z.B. mit dem Online-Tool „Refresh-SF“ effizient erledigen. Hier können die entsprechenden CSS-Styles, Quelltexte und Skripte einfach eingefügt und reduziert werden. In 99 % aller Fälle werden die vorgegebenen Standardeinstellungen ausreichen. Es empfiehlt sich auch, daran nichts mehr zu verstellen.

Bilder können ebenfalls mit diversen Online-Tools effektiv komprimiert werden. Hier eignen sich die folgenden Tools am besten:

Ebenfalls eignet sich gängige Grafiksoftware wie z.B. Adobe Photoshop oder Gimp.

Mit dem jQuery-Plugin „Lazyload“ werden Bilder erst dann geladen, wenn Sie den Viewport erreicht haben beziehungsweise dort sichtbar werden. Dies kann die Ladezeit für große Webseiten mit vielen Bildern um einiges verringern.

Weitere Informationen und eine Anleitung zur Integration gibt es auf der Projektseite.

Achten Sie darauf, dass Sie nicht übermäßig viele einzelne Stylesheets einsetzen. Überlegen Sie sich, ob es nicht Sinn macht, diverse unterschiedliche CSS-Dateien zu einer Datei zusammenzufügen.

JavaScript am Ende laden

Ein häufiges Problem, welches die Ladezeit einer Webseite massiv beeinflusst, ist das Laden einzelner JavaScript-Dateien. Das Problem hierbei ist, dass das Laden dieser Skripte das weitere Rendering der Seite so lange blockiert, bis alle Skripte vollständig geladen sind (Progressive Rendering).

Binden Sie Ihre JavaScript-Dateien deswegen immer am Ende beziehungsweise unmittelbar vor dem schließenden Body-Tag ein.

Outsourcing von JavaScript-Libraries und Frameworks

Wenn Sie verschiedene JavaScript-Libraries, CSS-Frameworks und Fonts einsetzen, empfiehlt es sich diese Dateien auszulagern und spezielle CDNs (dazu später noch mehr) zu nutzen, die diese Ressourcen hosten.

Der Vorteil daran liegt, dass viele Skripte, Frameworks und Fonts sehr oft eingesetzt und auf die jeweiligen CDNs ausgelagert werden. Wenn der Nutzer nun zuvor bereits eine Seite besucht hat, die beispielsweise auf die gleiche Librarie setzt und über ein CDN eingebunden ist, dann muss diese Ressource nicht mehr geladen werden, da diese sich bereits im Browsercache befindet.

Die meisten JavaScript-Libraries findet man bei Googles „Hosted Libraries“ und für Frameworks wie z.B. Bootstrap von Twitter eignet sich der „BootstrapCDN“. Für Webfonts eignet sich Google Fonts am besten.

Das Caching von Inhalten

Beim Caching werden Inhalte einer Webseite wie z.B. CSS-Stylesheets, Bilder, Skripte, Texte und auch Audio/Video-Dateien zwischengespeichert und müssen bei einem erneuten Aufruf nicht nochmals geladen werden. Dies beschleunigt die Ladezeit nach dem ersten Aufruf um ein Vielfaches.

Grundsätzlich gibt es zwei Arten von Caching: einmal das Browser-Caching für statische Elemente sowie das separate PHP-Caching für PHP-Seiten. Beim Browser-Caching werden alle Ressourcen beim ersten Besuch einer Webseite initial „heruntergeladen“ und für eine bestimmte eingestellte Zeit vom Browser zwischengespeichert. Das PHP-Caching hingegen sorgt dafür, dass der Quelltext von PHP basierten Seiten oder Skripten nur einmal kompiliert und danach zwischengespeichert wird. Für unsere Zwecke ist erst einmal nur das Browser-Caching relevant.

Während das Browser-Caching ein wichtiger Bestandteil einer performanten Webseite ist und unbedingt genutzt werden sollte, kommt es beim PHP-Caching darauf an, ob man seine Webseite beziehungsweise beim CMS auf PHP setzt oder nicht. Nachfolgend möchte ich erläutern, wie man das Browser-Caching und eine Komprimierung der Inhalte am besten umsetzt.

Browser-Caching und Komprimierung aktivieren

Für das Browser-Caching muss auf dem Server einmalig eine Konfigurationsdatei erstellt werden, in der alle Ressourcen inklusive Ablaufzeiten festgelegt werden, die gecached werden sollen. Empfehlenswert sind Ablaufzeiten zwischen mindestens einer Woche und bis zu einem Jahr. Dieser Zeitraum wird übrigens auch von Google empfohlen.

HTML-Dokumente sollten nicht gecached werden, da dies laut Google keine statischen Elemente sind. Mittels der zusätzlichen gzip-Komprimierung werden alle Inhalte noch einmal zusätzlich im gzip-Format komprimiert, bevor sie im Browser ausgeliefert werden.

In den meisten Fällen wird der Webserver „Apache“ eingesetzt. Hier kann das Browser-Caching wie folgt aktiviert werden:

Als Erstes muss das entsprechende Modul „mod_expires.c“ aktiviert werden. Wenn man Zugriff auf seinen Server hat, dann geschieht dies mit dem folgenden Befehl:

a2enmod expires

/etc/init.d/apache2 restart

Hat man keinen Zugriff auf den Server und ein Hostingpaket bei einem Webhoster gebucht, dann ist dieses Modul in der Regel schon standardmäßig aktiviert. Anschließend muss noch die passende Konfiguration in die HTACCESS-Datei geschrieben werden:

#BROWSER CACHING#
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/jpg "access 1 year"
ExpiresByType image/jpeg "access 1 year"
ExpiresByType image/gif "access 1 year"
ExpiresByType image/png "access 1 year"
ExpiresByType text/css "access 1 year"
ExpiresByType application/pdf "access 1 year"
ExpiresByType text/x-javascript "access 1 year"
ExpiresByType image/x-icon "access 1 year"
</IfModule>
#GZIP-Komprimierung#
<ifModule mod_gzip.c>
mod_gzip_on Yes
mod_gzip_dechunk Yes
mod_gzip_item_include file .(html?|txt|css|js|php|pl)$
mod_gzip_item_include handler ^cgi-script$
mod_gzip_item_include mime ^text/.*
mod_gzip_item_include mime ^application/x-javascript.*
mod_gzip_item_exclude mime ^image/.*
mod_gzip_item_exclude rspheader ^Content-Encoding:.*gzip.*
</ifModule>

Setzt man auf Lighttpd als Webserver statt auf Apache, dann müssen die folgenden Zeilen in die Konfiguration „lighttpd.conf“ eingefügt werden:

# Modules to load
server.modules = (
"mod_expire",
"mod_redirect",
"mod_compress"
)
# Compression
compress.cache-dir = "/tmp/lighttpd/compress/"
compress.filetype = (
"application/atom+xml",
"application/javascript",
"application/json",
"application/ld+json",
"application/manifest+json",
"application/rdf+xml",
"application/rss+xml",
"application/schema+json",
"application/vnd.geo+json",
"application/vnd.ms-fontobject",
"application/x-font-ttf",
"application/x-javascript",
"application/x-web-app-manifest+json",
"application/xhtml+xml",
"application/xml",
"font/eot",
"font/opentype",
"image/bmp",
"image/svg+xml",
"image/vnd.microsoft.icon",
"image/x-icon",
"text/cache-manifest",
"text/css",
"text/html",
"text/javascript",
"text/plain",
"text/vcard",
"text/vnd.rim.location.xloc",
"text/vtt",
"text/x-component",
"text/x-cross-domain-policy",
"text/xml",
)
# Expires headers
# CSS
$HTTP["url"] =~ ".css" {
expire.url = ( "" => "access plus 1 years" )
}
# Favicon
$HTTP["url"] =~ ".ico" {
expire.url = ( "" => "access plus 1 years" )
}
# JavaScript
$HTTP["url"] =~ ".js" {
expire.url = ( "" => "access plus 1 years" )
}
# Media
$HTTP["url"] =~ ".(gif|jpg|jpeg|png|m4a|f4a|f4b|oga|ogg|webm)" {
expire.url = ( "" => "access plus 1 years" )
}

Wer zusätzlich noch ein PHP-Caching einsetzen möchte, der sollte sich einmal die folgende Module beziehungsweise die folgende Software näher anschauen:

Die Technik des PHP-Caching und die Integration der Anwendungen an dieser Stelle näher zu erläutern würde den Rahmen dieses Artikels etwas sprengen und ist vielleicht ein Thema für einen weiteren Artikel.

Ein Content Delivery Network nutzen

Kurz erklärt ist ein Content Delivery Network (CDN) ein spezielles Netz mit vielen verschiedenen, regional verbundenen Servern, welches die schnelle Auslieferung bestimmter Inhalte ermöglicht.

Im Kern besteht ein CDN aus einem Hauptserver, auf dem alle auszulagernden Inhalte abgelegt werden sowie aus vielen verschiedenen „Spiegelservern“, auf denen alle Inhalte „gespiegelt“ werden. Der Vorteil an diesem System liegt darin, dass je näher die zu ladenden Inhalte beim Nutzer liegen, desto schneller können sie ihm ausgeliefert werden. Das CDN-System wählt also immer den aus Sicht des Nutzers besten Server.

Ein CDN eignet sich am besten für sehr große Webseiten / Portale, mit einer entsprechenden Reichweite und einer hohen Last. Hier sollte man abwägen, ob der Einsatz eines CDN tatsächlich einen Nutzen für das eigene Projekt hat.

Bei der Auswahl eines CDN-Anbieters ist auf jeden Fall die Verfügbarkeit (Uptime) zu beachten. Wenn ein Anbieter immer wieder oder relativ viele Schwankungen in seiner Uptime zu verzeichnen hat, sollte man von der Nutzung eher Abstand halten, da sonst eine gute Verfügbarkeit der eigenen Webseite nicht mehr zu 100 % gewährleistet werden kann. Eine daraus resultierende Downtime sollte aus SEO-Sicht natürlich vermieden werden.

Bei der Nutzung eines CDN ist es zudem wichtig, dass mittels der DNS-Funktion „DNS CNAME“ das CDN auf eine eigene URL / Subdomain wie z.B. „cdn.example.com“ statt auf die URL des CDN-Anbieters verwiesen wird. Dies reduziert auch weitere (unnötige) HTTP-Requests.

Wer mit dem Gedanken spielt, ein CDN für seine Webseite einzusetzen, sollte sich am besten mit den folgenden Anbietern auseinandersetzen:

Die Performance unter WordPress

Immer wieder hört man von Performance Problemen unter WordPress, die in der Tat ein größeres Problem sein können. In den meisten Fällen liegt es daran, dass man viel zu viele Plugins im Einsatz hat, die eigentlich nicht wirklich nötig wären, weil deren Funktionen auch direkt im Theme eingebaut werden können. Setzen Sie also alle Features wie z.B. Social Media Buttons, Analytics Trackingcodes, Codes für Werbeanzeigen usw. immer direkt im Theme um und vermeiden Sie es, solche Funktionalitäten nachträglich über ein Plugin hinzuzufügen.

Ein weiterer Aspekt dieser Problematik ist auch, dass viele Plugins automatisch eine große Anzahl an Skripten und weiteren Stylesheets in den Quellcode schreiben, wodurch dieser unnötig aufgebläht wird. Viele Inhalte werden zudem über einen Server des Plugin-Entwicklers gehostet, was zu vielen unnötigen HTTP-Requests führt.

Grundsätzlich sollte für einen optimalen Betrieb der Webseite auch immer ein Caching-System genutzt werden. Hier hat sich W3 Total Cache als ein gutes System bewährt.

Was es bei der Ladezeit-Optimierung zu beachten gilt

Auch die beste Strategie zur Umsetzung einer besseren Ladezeit ist nicht vor einigen Fallstricken geschützt. So kann es z.B. zu Problemen bei der Verwendung von fremd-gehosteten Skripten, Frameworks oder Fonts kommen, wenn deren Server nicht zu erreichen sind und daher die eigene Seite nicht mehr korrekt funktioniert. Hat man am Ende etwas überoptimiert, wird man meist ein Problem mit zu vielen HTTP-Requests auf fremde Server haben.

Zu beachten ist auch, dass wenn Grafiken oder Stylesheets abgeändert werden, kann es bedingt durch das Browser-Caching dazu kommen, dass diese Abänderungen für den Nutzer so lange nicht sichtbar sind, bis er manuell seinen Browsercache leert.

Das Fazit

Eine gute Optimierung der Ladezeit ist wichtiger Bestandteil der Onpage-Maßnahmen und sollte daher auch mit einer entsprechend hohen Priorität angegangen werden. Es gibt zusätzlich zu den hier genannten Möglichkeiten noch einige weitere Wege, um die Performance zu verbessern, wobei vieles dann schon sehr „ausgefallen“ ist, sich mit SEO nicht so sehr verträgt (Stichwort: Ajax) oder in der Umsetzung viel zu komplex ist. In der Zukunft könnte zudem auch das neue AMP-Projekt von Google für das schnelle Laden mobiler Webseiten ein Rankingfaktor werden.

Wenn Sie die wichtigsten Dinge wie das Browser-Caching sauber einstellen, Ihren Quelltext anpassen, schlank halten sowie alle Ihre Grafiken gut komprimieren, dann haben Sie schon einen guten Schritt in die richtige Richtung gemacht. Setzen Sie WordPress ein, dann überlegen Sie sich, ob Sie Ihr Theme anpassen können, um unnötige Plugins zu entfernen.

Wie sieht das denn bei Ihnen aus? Haben Sie die Ladezeit Ihrer Webseite bereits optimiert? Falls ja, auf welche Technik oder Methoden setzen Sie? Falls nicht, was hat Sie bisher von der Optimierung abgehalten?

Florian Wirths war bis 2016 als SEO Consultant bei uns. Er schreibt zu Themen rund um Suchmaschinenoptimierung und Technik. In seiner Freizeit bloggt er auf www.welitso.de, beschäftigt sich mit gutem Journalismus, Social Media, Ruhrpottfußball und ist bei Twitter als @florian_wirths unterwegs.

5 / 5 (7 votes)

Schreibe einen Kommentar

Loading Facebook Comments ...

2 Kommentare

Holger schrieb am 27. März, 2016 @ 22:27

mein WP läuft auf vserver nginx mit SSL u. HTTP/2 mit WP Super Cache im RAM. Rennt wie Schmitz Katze 🙂

Florian Wirths schrieb am 29. März, 2016 @ 9:06

Hey Holger,

ja nginx und auch Lighttpd sind beides ziemlich schlanke und gute Webserver. Sie sind da deshalb auch meine Favoriten. 🙂

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

Loading Disqus Comments ...