WordPress PageSpeed Optimierung

Keine Kommentare

Niemand mag eine langsame Webseite

Auch wenn in der heutigen Zeit Internetanbindungen von 100 Mbit/s fast zum Standard gehören, sollte der Betreiber einer Webseite auf die Ladegeschwindigkeit achten. Studien an Webshops haben ergeben, dass eine Sekunde mehr Ladezeit teilweise 25% potenzielle Kunden kostet.

Als Beispiel nehme ich einfach mal Amazon:

Amazon hat im Jahr 2016 einen Jahresumsatz von 43,6 Milliarden US$ erwirtschaftet, 25% weniger Kunden ist dabei ein Verlust von 10,9 Milliarden US$. Ein ziemliche Zahl mit vielen Nullen.

Quelle: https://de.statista.com/statistik/daten/studie/197099/umfrage/nettoumsatz-von-amazoncom-quartalszahlen/

Wenn Du Dir die Statistiken der mobilen Nutzer des letzten Jahres ansiehst, wirst Du feststellen, dass die Anzahl Nutzer mobiler Verbindungen stetig ansteigt. In Europa haben wir derzeit einen Anteil von 28,14% Handys und 6,88% Tablets. Ein Blick nach Afrika und Asien zeigt auf wohin der Trend geht: Weg vom Festanschluss, hin zu reinen Mobilverbindungen!

Anteil mobiler Endgeräte

Quelle: https://de.statista.com/statistik/daten/studie/217457/umfrage/anteil-mobiler-endgeraete-an-allen-seitenaufrufen-weltweit/

Die Sache hat aber einen Haken: Mobile Anbindungen sind derzeit noch nicht flächendeckend in ausreichender Bandbreite verfügbar. Das bedeutet, dass vor allem in den ländlichen Gegenden die Benutzer über eine eher langsame Verbindung verfügen. Aus Besucher können potenzielle Kunden werden, deshalb sollte man diese auf keinen Fall ausschließen.

Google Ranking und die Ladegeschwindigkeit

Und was Kunden mögen, bewertet auch Google höher. Wenn ein Besucher von der Google Suche auf Deine Webseite kommt und diese braucht zu lange, klickt er ganz schnell zurück zur Suche. Google registriert diese Klicks als Absprungmarke und dass kann durchaus ins Ranking einfließen. Google gibt ja nicht viele Geheimnisse des Rankings frei, sondern immer wieder Hinweise, wie diese hier:

  • Wenn zwei verschiedene Seiten auf demselben Platz ranken würden, rankt die schnellere Seite höher
  • Webseiten laden an verschiedenen Orten der Welt unterschiedlich schnell
  • Google gibt keine Zahl in Sekunden an, in der die Seite geladen sein soll
  • Schau auf Deine Nachbarschaft und Deine Branche / Nische um zu sehen, wie schnell die anderen Seiten laden
  • Wenn Du bedeutend langsamer bist, solltest Du handeln

Quelle:

Dazu kommt, dass Google in Zukunft mehr auf mobile Geräte Rücksicht nehmen will, als auf Desktops. Da diese Geräte in der Regel über eine geringere Bandbreite verfügen, wird der Blick auf die Ladegeschwindigkeit wahrscheinlich weiter zunehmen. Dazu natürlich auch Faktoren wie responsives Design und sichere Verbindungen.

Als Zusammenfassung kann ich sagen: Je schneller eine Webseite lädt, guten Content bereitstellt und auf jedem Gerät gut lesbar ist, freut es den Benutzer und Google bewertet dieses als positives Signal. Natürlich ist die Ladegeschwindigkeit nur ein kleiner Teil einer guten Strategie. Eine schnelle mobile Seite, mit schlechten Content hat wird wohl eher nicht gut ranken.

Grundlagen von HTTP, GET Request

Wie funktioniert HTTP?

HTTP (Hypertext Transfer Protocol) ist ein zustandsloses Protokoll, welches für die
Übertragen zwischen einem Server und einem Clienten eingesetzt wird. Meistens wird es für die Übertragung von Webseiten verwendet, ist aber nicht darauf beschränkt. Eine weitere Verwendung von HTTP ist WebDav. Als Erweiterung von HTTP ist HTTPS (per SSL verschlüsselte Verbindung) verfügbar.

Dabei wird auf dem Server ein HTTP Server installiert, welcher auf Anfragen des Clienten (Dein Browser) reagiert und die entsprechende Anfrage bearbeitet. Der mit Abstand am meisten verbreitete Webserver ist Apache, gefolgt von Nginx und IIS.

Wenn der Client eine Anfrage an http://example.com/file.html sendet, wird eine Anfrage an den Server example.com gesendet und die Datei file.html angefordert. Die Anfrage erfolgt in der Regel über den Port 80 des TCP/IP Protokolls. Sollte der Server die Datei file.html nicht finden, bekommt der Client eine Antwort mit dem Statuscode 404. Bei einer erfolgreichen Übertragen ist der Statuscode 200. So kann der HTTP Server alle Arten von Dateien an den Clienten übertragen und es ist die Aufgabe des Browsers oder einer anderen Software diese entsprechend darzustellen.

Natürlich kannst Du auch per Konsole auf den Webserver zugreifen. Dies ist oft bei der Fehlersuche hilfreich. Als Beispiel lade ich einmal das Logo von Google herunter. Dies geht auf der Konsole mit folgendem Befehl:

wget -cv https://www.google.com.kh/images/branding/googlelogo/2x/googlelogo_color_120x44dp.png

Die Ausgabe ist folgende:

–2017-03-10 14:32:25– https://www.google.com.kh/images/branding/googlelogo/2x/googlelogo_color_120x44dp.png
Resolving www.google.com.kh… 43.252.16.177, 43.252.16.162, 43.252.16.182, …
Connecting to www.google.com.kh|43.252.16.177|:443… connected.
HTTP request sent, awaiting response… 200 OK
Length: 5087 (5.0K) [image/png] Saving to: ‘googlelogo_color_120x44dp.png’
googlelogo_color_120x44dp.png 100%[=================================================>] 4.97K –.-KB/s in 0s
2017-03-10 14:32:25 (14.1 MB/s) – ‘googlelogo_color_120x44dp.png’ saved [5087/5087]

Ganz oben steht der Zeitstempel der Anfrage, gefolgt von der angeforderten Datei.
In der zweiten Zeile wird die Adresse www.google.com.kh aufgelöst, diese gibt verschiedene IP Adressen zurück. Warum verschiedene IP Adressen? Google muss tausende von Anfrage pro Minute bearbeiten und verteilt die HTTP Anfragen auf verschiedene Server. Dieses nennt sich Load Balancing.

In der folgenden Zeile verbindet sich mein Rechner mit der IP Adresse 43.252.16.177 auf dem Port 443. Port 443 anstelle von Port 80, weil dort das HTTPS Protokoll verwendet wird. Die Länge der Datei und der Dateityp wird durch den Header im Protokoll angegeben, damit der Client diese richtig speichern kann.

Nun wird der sogenannte Request durchgeführt, also die Datei angefordert, alles ist in Ordnung wir haben den Status 200, die Datei wird übertragen und mit demselben Namen gespeichert. Die gesamte Übertragung hat nur den Bruchteil einer Sekunde gedauert und die Datei ist verfügbar.

Die ganze Prozedur kann man auch mit GET, Telnet oder mit einer selbst implementierten Lösung durchspielen. Bibliotheken für einen HTTP-Request gibt es für jede Programmiersprache.
Quelle: https://de.wikipedia.org/wiki/Hypertext_Transfer_Protocol

Methoden zum Testen

Jetzt geht es an die Tests der Ladegeschwindigkeit Deiner Webseite. Da viele Faktoren die Reaktion und Übertragung der angeforderten Seite beeinflussen, gibt es natürlich auch einige Methoden zum testen.

Google Pagespeed Insights

URL: https://developers.google.com/speed/pagespeed/insights/?hl=de

Die Analyse von Google gibt Dir einen groben Überblick, wo es mit Deiner Seite Probleme gibt. Anders als der Name Pagespeed vermuten lässt, liegt nicht die Geschwindigkeit im Vordergrund sondern die Benutzbarkeit. Ergebnisse und Hinweise von Google Pagespeed sind eher im Theme oder im Style der Webseite zu beheben, als auf dem Server.

Pagespeed Insights gibt Dir aber Hinweise welche Dateien nicht gecacht werden oder eine geringe Lebensdauer haben. Auch wird auf die übermäßige Verwendung von CSS und JavaScript Code hingewiesen. An der Antwortzeit des Servers kannst Du in der Regel nicht viel ändern, es sei denn Du hast einen Root oder einen managed Server. Wichtig sind die Hinweise auf:

  • Bilder optimieren (so klein wie möglich und so gross wie nötig)
  • Browser Caching nutzen (es werden alle Dateien angezeigt, die keinen Cache nutzen oder eine zu kurze Lebensdauer haben)
  • CSS Reduzieren (keine aufgeblähten CSS Dateien, mit Wiederholungen und Kommentaren etc. verwenden)
  • HTML Reduzieren (Kommentare und unnötige Leerzeichen entfernen)
  • Javascript Reduzieren (dasselbe wie bei HTML)
  • Komprimierung aktivieren (das bringt sehr viel, mehr dazu weiter unten im Artikel)
  • Zielseiten-Weiterleitung vermeiden (nicht von http://www.example.com -> http://example.com -> https://example.com oder http://example.com -> http://example.com/startseite.html springen, sinnlose Weiterleitungen vermeiden)

Was Du meiner Meinung nach vernachlässigen kannst, ist das “Above the fold”. Dies kommt aus der Urzeit der Printmedien, welche gefaltet in den Kiosken lagen und die Hauptschlagzeile musste über der Faltung liegen. Also direkt sichtbar für den potenziellen Käufer. Wenn man dieses auf eine moderne Webseite übertragen würde, darf man keinerlei Slider oder Headerbilder verwenden. Mobile Nutzer sind es heutzutage gewohnt zu scrollen, deshalb ist es meiner Meinung nach nicht so wild.

Eine oft vorkommende Fehlermeldung ist das mangelnde Caching den Google Analytics Codes. Dieser wird per Javascript im unteren Bereich einer Webseite eingebunden und holt sich eine Datei von den Google Servern. Dummerweise hat diese Datei eine sehr kurze Lebensdauer, was Pagespeed Insights bemängelt. Es soll ja auch vegetarische Metzger geben, aber damit haut sich Google doch etwas in die Pfanne. Einerseits soll Analytics verwendet werden, auf der anderen Seite wird es bemängelt… Es gibt einige Methode den Code lokal auf dem Webserver zu lagern und einzubinden, doch ändert sich der Code ohne Vorwarnung und es kann die Ergebnisse verfälschen. Ich halte 95% bei Google Pagespeed Insights für einen recht guten Wert und eine gute Balance zwischen Aufwand und Ergebnis.

Pagespeed mit Pingdom messen

URL: https://tools.pingdom.com/

Pingdom ist ein gutes Tool um Anhaltspunkt zu Problemen mit Deiner Webseite zu finden. Es bietet neben dem Speedtest eine gute Analyse, sowie ein Tool um Probleme mit dem DNS (https://de.wikipedia.org/wiki/Domain_Name_System) aufzuspüren. Vor allem hast Du dort die Ausgabe der realen Ladezeit.

Dazu gibst Du einfach die URL Deiner Seite und und wählst einen Standort, von wo die Seite getestet werden soll. Wenn Deine Zielgruppe eher im deutschen Raum ist, solltest Du Stockholm nutzen. Damit hast Du eine gute Chance realistische Daten zu erhalten.

Mit ein wenig Zeitaufwand und diesem Tutorial solltest Du auf ein ähnliches Ergebnis wie im Screenshot kommen:

Pingdom Beispiel

Kommen wir zu den einzelnen Punkten, welche bei Pingdom gewertet werden.

  • Oben links hast Du einen Screenshot Deiner Seite
  • Rechts daneben den Performance Grad in Prozent, die Ladezeit der Seite und einen Vergleich mit anderen getesteten Webseiten
  • Darunter die Seitengröße, die benötigten Requests und den Standort des Testservers

Die Section Performance Insights zeigt dir detaillierte Hinweise zur Verbesserung der Performance an. Auch hast Du immer einen Link zur Beschreibung von Google Developers, diese kannst Du als Hilfestellung nutzen um das Problem zu lösen.
Zu den einzelnen Punkten:

Meldung Beschreibung
Avoid bad request Entferne oder reparieren alle nicht funktionierenden Links
Leverage browser caching Dort sind alle Dateien mit einer geringen oder keinen Cache-Dauer gelistet
Minimize redirects Vermeide Weiterleitungen von http://example.com auf http://example.de
Minimize request size minimiere die Größe der einzelnen Anforderungen, durch kleinere Bilder zum Beispiel
Remove query strings from static source Damit sind eingebundene Dateien mit einer Version gemeint, wie z.B. main.min.css?ver=1.2.4.1.0.6.1
Serve static content from cookieless domain versuche Bilder aus einer Domain zu laden, die keine Cookies setzt
Specify a cache validato Ein Hinweis auf das Alter der Datei fehlt, z.B. durch ETag oder Last-modified
Specify a Vary: Accept-Encoding header Alle öffentlichen Dateien die im Cache liegen sollten diesen Header aufweisen

Weiter unten findest Du die Response Codes, die sollten alle auf 200 stehen.
Im unteren Bereich kannst Du die Seite noch weiter analysieren um zum Beispiel Bilder von fremden Domains zu finden oder auch die Wartezeit der Server ermitteln. Wenn Du alle Punkte, welche Pingdom bemängelt behoben hast, bist Du schon auf einen sehr guten Stand.

Mit GTmetrix die Ladegeschwindigkeit der Seite prüfen

URL: https://gtmetrix.com/

Auch GTmetrix gibt Auskunft über die Verbesserung der Geschwindigkeit einer Webseite und konkrete Hinweise auf Probleme. Du kannst Dich bei dem Service anmelden und dann auch den Standort des Testservers bestimmen, sowie andere Einstellungen tätigen. Im Grunde reicht aber der Test als nicht angemeldeter Benutzer aus, um Probleme zu identifizieren.

Wie auch bei Pingdom, siehst Du links einen Screenshot der Seite und darunter deine erreichte Punktzahl. Als Performance Score kommt PageSpeed (nicht zu verwechseln mit Google Pagespeed) und YSlow Score zum Einsatz. Rechts siehst Du die Zeit in der Deine Seite vollständig geladen wurde, die Größe und die Anzahl der Request.

Darunter wieder die üblichen Hinweise zur Verbesserung.

Ohne die Verwendung einen CDN’s (Content Delivery Network) hast Du wenig Chancen bei YSlow auf 100% zu kommen.

Auch hier hast Du wieder eine kurze Erklärung zu den einzelnen Punkten, die meisten sind identisch mit der Ausgabe von Pingdom. Wenn Du bei Pingdom ein gutes Ergebnis hattest, wird es bei GTmetrix auch nicht schlecht werden.

Teilweise werden noch zusätzliche Hinweise gegeben, wie zum Beispiel die Bildgrößen fix zu skalieren. Ich gebe den Bildern aber lieber Angaben in Prozent mit und habe in der mobilen Ansicht keine Probleme.

Komme ich zu den etwas kleineren und speziellen Werkzeugen zur Fehlersuche, die bei der Diagnose aber wertvolle Hinweise liefern:

Ist meine Webseite komprimiert?

Eine einfache Prüfung auf der Seite https://checkgzipcompression.com/ zeigt Dir unverzüglich an, ob dein Webserver die HTML Ausgabe komprimiert. Kurz und bündig, wenn der Check erfolgreich ist, kannst Du den Cache checken.

Haben meine CSS, JS und Bilddateien ein Ablaufdatum?

Gehe auf deine Konsole und fordere eine Datei mit curl -I von Deiner Webseite an

curl -I –verbose https://www.google.com.kh/images/branding/googlelogo/2x/googlelogo_color_120x44dp.png

Im Fall des Google Logos kommt folgende Ausgabe:

* Trying 43.252.16.167…
* TCP_NODELAY set
* Connected to www.google.com.kh (43.252.16.167) port 443 (#0)
* TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* Server certificate: *.google.com.kh
* Server certificate: Google Internet Authority G2
* Server certificate: GeoTrust Global CA
> HEAD /images/branding/googlelogo/2x/googlelogo_color_120x44dp.png HTTP/1.1
> Host: www.google.com.kh
> User-Agent: curl/7.51.0
> Accept: */*
>
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
< Content-Type: image/png
Content-Type: image/png
< Content-Length: 5087
Content-Length: 5087
< Date: Fri, 10 Mar 2017 09:31:09 GMT
Date: Fri, 10 Mar 2017 09:31:09 GMT
< Expires: Fri, 10 Mar 2017 09:31:09 GMT
Expires: Fri, 10 Mar 2017 09:31:09 GMT
< Cache-Control: private, max-age=31536000
Cache-Control: private, max-age=31536000
< Last-Modified: Thu, 08 Dec 2016 01:00:57 GMT
Last-Modified: Thu, 08 Dec 2016 01:00:57 GMT
< X-Content-Type-Options: nosniff
X-Content-Type-Options: nosniff
< Server: sffe
Server: sffe
< X-XSS-Protection: 1; mode=block
X-XSS-Protection: 1; mode=block
< Alt-Svc: quic=”:443″; ma=2592000; v=”36,35,34″
Alt-Svc: quic=”:443″; ma=2592000; v=”36,35,34″
<
* Curl_http_done: called premature == 0
* Connection #0 to host www.google.com.kh left intact

Auch curl ist eine HTTP Client, deshalb ähnelt sich die Ausgabe des Request etwas mit wget, get oder telnet. Die Basis dahinter ist dieselbe, nur das mit dem Parameter “-I” die Informationen eingeschaltet werden.

Expires: Fri, 10 Mar 2017 09:31:09 GMT

Die Ausgabe von Google ist schon sehr gut, wichtig ist die Zeile mit Expires: Diese sagt das ein Ablaufdatum gesetzt ist, da sich das Google Logo sich in diesem Fall je nach Tag ändern kann, ist die Lebensdauer relativ gering.

Manuelle Methoden

Es gibt einige Methode wie Du die Ladegeschwindigkeit einer Webseite erhöhen kannst. Dazu ist beim Apache Webserver mindestens Zugriff per FTP auf Deinem Server notwendig und beim Nginx Server SSH, da dort einige Konfigurationsdateien geändert werden müssen.

Bevor Du nun aber zur Konsole greifst und den Editor Deiner Wahl startest, mache immer eine Sicherheitskopie von der Datei! Es kann schnell passieren, dass der Webserver nicht mehr gestartet werden kann oder Du einen Fehler 500 bekommst. So hast Du eine Chance innerhalb kurzer Zeit wieder auf den alten Zustand zu wechseln.

Allgemeine Methoden

Eine sehr effiziente Methode die Ladegeschwindigkeit einer Webseite zu erhöhen, ist das minimieren der erforderlichen Request. Für jede Datei die im HTML Code geladen wird, sei es ein Bild, eine CSS oder eine Javascript Datei wird ein Request benötigt. Diese sollte meiner Erfahrung nach unter 50 bleiben. Wenn Du nun aber ein umfangreiches WordPress-Theme erworben hast, kommen bei einigen Seiten rund 120 Dateien alleine nur für Javascript und CSS zusammen, wenn dann noch einige Bilder dazu kommen… da muss sich der Browser oft mit dem Server verbinden, also wird jedes Mal eine kurze Zeitspanne verschwendet.

Wenn Du eine Webseite hast Du nicht auf WordPress basiert, sondern reines HTML, CSS, PHP und JS ist, kannst Du die Dateien manuell oder per Grunt zusammenfassen. Mit etwas Aufwand ist dieses auch manuell für WordPress zu erledigen.

Es wird aus allen CSS Dateien eine einzige Datei erstellt, die dann mit einem einzigen Request geladen werden kann. WICHTIG: Die Reihenfolge in der diese Dateien im bestehenden Code eingefügt waren, muss eingehalten werden. Wenn Du als Beispiel die normalize.css als letztes einfügst, werden diese Anweisungen auch als letzter Befehl ausgeführt. Über das Aussehen der Webseite wirst Du dich sicher nicht freuen, da alle Änderungen am Design rückgängig gemacht worden sind. Als Beispiel nehmen ich einmal diese Dateien:

normalize.css
bootstrap.css
style.css

Die Datei normalize.css setzt alle Einstellungen auf den Standard, bootstrap.css ist das beliebte Framework Bootstrap und in der Datei style.css stehen Deine eigenen Anweisungen.
Nun kannst Du einfach die Dateien zu einer zusammenfassen:

more nomalize.css > template.css
more bootstrap.css >> template.css
more style.css >> template.css

In der ersten Zeile wird der Inhalt der Datei normalize.css in die Datei template.css geschrieben. Diese Datei wird dabei neu erstellt und das Zeichen “>” sagt, fange am Anfang der Datei an.
Die beiden anderen Zeilen kopieren den Code jeweils an das Ende der Datei. Die macht die Anweisung “>>”.

Auf dieselbe Weise kannst Du auch alle Deine Javascript Dateien zusammenfassen.

Jetzt hast Du alle CSS und Javascript Dateien zusammengefasst und es sind für den Style und die Scripte nur noch jeweils ein einziger Request nötig. Das spart schon einiges an Zeit und Serverleistung. Nun ist aber die Größe der Datei template.css ziemlich identisch mit der Summe alle CSS Dateien. Auch dort gibt es Potenzial zur Optimierung. Du kannst alle Leerzeichen, Kommentare und doppelte Anweisungen entfernen. Das kannst Du innerhalb einiger Stunden manuell machen oder mit wenigen Mausklicks online: http://www.freeformatter.com/css-minifier.html

Dort musst Du nur die CSS Datei hochladen und auch minify klicken. Dann kannst Du diese in das Projekt einbinden und dasselbe mit den Javascript machen. Nutze dafür aber bitte dieses Tool auf derselben Seite: http://www.freeformatter.com/javascript-minifier.html

Da dies ein ziemlicher Aufwand ist und ich gerne die Seiten von Anfang an Geschwindigkeit optimieren und nicht erst am Ende, kann man diese Aufgabe natürlich automatisieren.

Du kannst Dir auf der Shell ein Script schreiben oder einfach das hervorragende Tool Grunt dazu nutzen. Eine Anleitung findest Du hier: http://gruntjs.com/getting-started

Es erfordert am Anfang etwas Zeit zur Einarbeitung, kann dann aber durch das Anpassen der Pfade in jedem Projekt verwendet werden. Ein einfacher Aufruf von “grunt” auf der Konsole reicht aus und alle Dateien sind zusammengefasst und optimiert.

Ein passendes WordPress Plugin gibt es auch, dieses arbeitet aber auf Basis von PHP und birgt einige Gefahren, mehr dazu im Artikel weiter unten.

Bilder kannst Du leider nicht zusammenfassen, es sei denn als CSS Sprites. Diese Methode wird häufig bei Social Media Icons und ähnlichen Bildern verwendet.

Apache

Der Apache2 Webserver ist mit Abstand der am meisten verbreitete Webserver. Er wird bei fast allen normalen Hostern verwendet und stellt, schon mit den Standardeinstellungen eine sicherer Konfiguration bereit.

Je nachdem, wie weit der Webserver durch den Benutzer weiter konfiguriert werden kann, sind vielfältige Modifikationen möglich. Die am meisten benutzten Dateien zur Konfiguration durch den Benutzer sind die php.ini sowie die .htaccess.

In der php.ini werden die grundlegenden Einstellungen zum Verhalten des Sprache PHP, wie als Beispiel die max_execution_time eingestellt. In der .htaccess dagegen, werden Funktionen wie Cache, Kompression oder auch der Schutz von einzelnen Verzeichnissen konfiguriert.

Die einzelnen Funktionen werden durch Module regelt, welche vom Hoster aktiviert werden müssen. Das wohl mit Abstand am meisten benutzte Modul ist “Rewrite” welches das Umschreiben der URL’s und damit “sprechende Links” ermöglicht.

Die .htaccess liegt im Wurzelverzeichnis der Webseite und kann durch einen beliebigen Texteditor bearbeitet werden. Dabei sollte immer zuerst ein Backup der Datei erstellt werden. Durch kleine Fehler in der .htaccess kommt es sehr schnell zum bekanntet “ERROR 500”. Dies kann durch fehlende Module vorkommen, welche aufgerufen werden aber nicht geladen bzw. aktiviert sind.

Hier folgen einen Bespiele zur Konfiguration:

Umleitung von example.com auf www.example.com:

RewriteEngine On
RewriteCond %{HTTP_HOST} !^www\.
RewriteRule ^(.*)$ http://www.%{HTTP_HOST}/$1 [R=301,L]

Entfernen von ETag:

<IfModule mod_headers.c>
Header unset ETag
</IfModule>

Komprimierte Dateien erlauben:

<IfModule mod_headers.c>
<FilesMatch “.(js|min.css|min.jscss|xml|gz|html|css.gzip|js.gzip)$”>
Header append Vary: Accept-Encoding
</FilesMatch>
</IfModule>

GZIP Kompression einschalten:

SetOutputFilter DEFLATE
AddOutputFilterByType DEFLATE text/html text/css text/plain text/xml application/x-javascript application/x-httpd-php
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
BrowserMatch \bMSI[E] !no-gzip !gzip-only-text/html
SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-gzip

Caching einschalten:

<IfModule mod_expires.c>
ExpiresActive on
ExpiresDefault “access plus 1 month”
ExpiresByType text/css “access plus 1 year”
ExpiresByType application/json “access plus 0 seconds”
ExpiresByType application/ld+json “access plus 0 seconds”
ExpiresByType application/schema+json “access plus 0 seconds”
ExpiresByType application/vnd.geo+json “access plus 0 seconds”
ExpiresByType application/xml “access plus 0 seconds”
ExpiresByType text/xml “access plus 0 seconds”
ExpiresByType image/vnd.microsoft.icon “access plus 1 week”
ExpiresByType image/x-icon “access plus 1 week”
ExpiresByType text/x-component “access plus 1 month”
ExpiresByType text/html “access plus 0 seconds”
ExpiresByType application/javascript “access plus 1 year”
ExpiresByType application/x-javascript “access plus 1 year”
ExpiresByType text/javascript “access plus 1 year”
ExpiresByType application/manifest+json “access plus 1 week”
ExpiresByType application/x-web-app-manifest+json “access plus 0 seconds”
ExpiresByType text/cache-manifest “access plus 0 seconds”
ExpiresByType audio/ogg “access plus 1 month”
ExpiresByType image/bmp “access plus 1 month”
ExpiresByType image/gif “access plus 1 month”
ExpiresByType image/jpeg “access plus 1 month”
ExpiresByType image/png “access plus 1 month”
ExpiresByType image/svg+xml “access plus 1 month”
ExpiresByType image/webp “access plus 1 month”
ExpiresByType video/mp4 “access plus 1 month”
ExpiresByType video/ogg “access plus 1 month”
ExpiresByType video/webm “access plus 1 month”
ExpiresByType application/atom+xml “access plus 1 hour”
ExpiresByType application/rdf+xml “access plus 1 hour”
ExpiresByType application/rss+xml “access plus 1 hour”
ExpiresByType application/vnd.ms-fontobject “access plus 1 month”
ExpiresByType font/eot “access plus 1 month”
ExpiresByType font/opentype “access plus 1 month”
ExpiresByType application/x-font-ttf “access plus 1 month”
ExpiresByType application/font-woff “access plus 1 month”
ExpiresByType application/x-font-woff “access plus 1 month”
ExpiresByType font/woff “access plus 1 month”
ExpiresByType application/font-woff2 “access plus 1 month”
ExpiresByType text/x-cross-domain-policy “access plus 1 week”
</IfModule>

Verfügbare WordPress Plugins

Es gibt auch einige WordPress Plugins, welche Dir einiges an Konfiguration abnehmen. Dazu gehören unter anderem:

Autoptimize:

Diese Plugin fügt Dateien wie CSS und Javascript zusammen und kann diese auch direkt als “inline” im HTML Header einbinden. Dabei kann es vorkommen, dass die Dateien in der falschen Reihenfolge geladen werden und die Webseite nicht korrekt angezeigt wird. Dann sollte man die einzelnen Optionen, wie “Javascript verbinden” abschalten und nacheinander wieder einschalten um zu testen, welche Option den Fehler verursacht.

W3 Total Cache:
Als eines der besten Plugins für den Cache hat sich W3 Total erwiesen. Die Konfiguration ist einfach gehalten auch wenn sehr viele Optionen für erfahrene Benutzer zur Verfügung stehen. Die meisten Optionen werden direkt in die .htaccess eingetragen. Bei der Verwendung des Plugins auf einem Nginx Webserver sind einige Anpassungen notwendig.

Fehlersuche
Übersicht der HTTP Statuscodes:
1xx – Information (Zwischenantwort um eine Zeitüberschreitung zu vermeiden)
2xx – Erfolgreiche Operation (Datei wird an den Clienten gesendet)
3xx – Umleitung (Die Datei oder der Host wurden umgeleitet)
4xx – Client Fehler (Meistens wird eine Datei / Seite angefordert die nicht existiert)
5xx- Server Fehler (Meistens ein Fehler in der Serverkonfiguration)

Ivo ist unser Mann für Linux, Bashscripte und Optimierung von Servern. Des weiteren ist er bei uns für Umzüge von Wordpress Webseiten, technische Dokumentation und Fehlersuche verantwortlich.

Über uns und diesen Blog

Wir sind eine SEO und Webdesign Agentur aus Koblenz und helfen Klein- und Mittelständigen Unternehmen online gefunden zu werden und neue Kunden zu gewinnen.

Gratis Beratung

Du möchtest erfahren wie du bei Google auf die erste Seite kommst? Dann fordere jetzt die kostenlose SEO-Webseiten Beratung und Analyse an. 

Mehr aus unseren Blog

Keine Kommentare
 

Hinterlasse ein Kommentar