Die 10 wichtigsten Stellschrauben deiner WordPress-Performance

Torben Simon Meier Zuletzt aktualisiert am 21.10.2020
10 Min.
WordPress Performance: Die 10 wichtigsten Stellschrauben
Zuletzt aktualisiert am 21.10.2020

Im Netz wimmelt es von Tipps und Tricks, wie du deine WordPress-Performance optimieren kannst. Leider fallen dabei Erklärungen und Bewertungen der Relevanz der verschiedenen Stellschrauben schnell mal unter den Tisch. Wir zeigen dir die wichtigen Ansatzpunkte und Stellschrauben – in sinnvoller Reihenfolge und mit Kontext. So kannst du besonders schnell Erfolge erzielen.

Mittlerweile haben wir bereits an die 15.000 WordPress-Projekte gehostet. Dabei ist eine ganze Menge an Daten angefallen. Und wir werden immer wieder von Kunden gefragt, wie sie denn die Seitenladezeit ihrer WordPress-Projekte weiter reduzieren können. Also haben wir unsere Erkenntnisse aus der Analyse unserer Kundenseiten aus den vergangenen Jahren systematisch aufbereitet. Das Ergebnis: 10 Maßnahmen, mit denen du schnell und einfach deine WordPress-Performance optimieren kannst.

Eine Sache ist dabei besonders wichtig: Einige Nutzer lassen sich schnell von den Optimierungsvorschlägen von Tools wie Google PageSpeed Insights abschrecken. Lass dir gesagt sein: Den meisten Ladezeitgewinn machst du nicht mit komplizierten Optimierungsmaßnahmen, sondern mit Methoden, die ganz leicht umzusetzen sind.

WordPress-Performance optimization suggestions by Google
Nur wenige Seitenbetreiber können mit dieser Nachricht konkret etwas anfangen. Daher ist es besonders wichtig, dass du dich zunächst auf die einfachen Optimierungsschritte konzentrierst und erst im zweiten Schritt die komplizierteren Maßnahmen angehst.

Natürlich ist Ladezeitoptimierung kein Selbstzweck. Neben einem besseren Erlebnis für deine Nutzer, bringt eine kürzere Ladezeit nämlich auch Vorteile bei der Sichtbarkeit deines Angebots bei Google. Daher werde ich bei jedem Punkt auch kurz anreißen, worum es bei den einzelnen Optimierungsschritten eigentlich geht, um den entsprechenden Kontext zu schaffen.

Du kannst dich also theoretisch von oben nach unten durcharbeiten und so die Ladezeit deiner Seite Schritt für Schritt verbessern. Die ersten sieben Punkte beziehen sich übrigens auch auf die typischen Verbesserungsvorschläge von Google PageSpeed Insights, auf die wir zum Beispiel in diesem Artikel noch detaillierter eingehen.

#1 Caching – der wichtigste Performance-Faktor überhaupt

Caching bedeutet, dass deine Seite nicht erst vom Browser beim Webserver angefragt und danach Schritt für Schritt aufgebaut werden muss. Stattdessen wird deine Seite – fertig gerendert – aus einem Zwischenspeicher geladen.

Der Vorteil dieses Zwischenspeicherns liegt auf der Hand: WordPress muss nicht bei jedem Seitenaufruf deine Seite neu berechnen. Da WordPress auf dem sehr langsamen PHP basiert, ist gerade hier ein Cache elementar. Denn er verhindert unter anderem, dass PHP ausgelesen werden muss.

Prinzipiell gibt es zwei Umsetzungsvarianten für Caches:

  • Über Caching-Plugins: Die Mehrzahl der User nutzt ein Caching-Plugin, wie W3 Total Cache oder WP Super Cache. Diese sind mal einfacher, mal etwas komplizierter einzurichten. In jedem Fall ist hier ein gewisser Anteil an Handarbeit gefragt.
  • Über den Hoster: Einige Hoster – so auch RAIDBOXES – bieten serverseitiges Caching an. Das bedeutet, dass du fast immer auf Caching-Plugins verzichten kannst. Denn dein Hostinganbieter hat die Konfiguration des Zwischenspeichers bereits für dich übernommen.

Hast du ein performantes Caching eingerichtet, hast du den wichtigsten Schritt in Richtung mehr WordPress-Performance bereits gemacht. Für mehr Details schau dir gerne unseren Artikel zu den Caching Grundlagen an.

#2 WordPress aufräumen – Ordnung muss sein

Eine der häufigsten Ursachen für lange Ladezeiten ist – unserer Erfahrung nach – eine überladene WordPress-Installation. Und weil dieser Verbesserungspunkt nicht von Google PageSpeed Insights erwähnt wird, kommt er in meinen Top 10 direkt an zweiter Stelle.

Eine überladene WordPress-Installation heißt in den allermeisten Fällen: es sind zu viele Plugins installiert. Grundsätzlich gilt: Je weniger Plugins, desto schneller die Seite. Natürlich sind Plugins wichtig und ohne geht es nicht, allerdings solltest du immer mal wieder nachsehen, welche Plugins du wirklich benötigst.

Und: Du solltest darauf achten Plugins nicht einfach nur zu deaktivieren, sondern sie tatsächlich komplett zu löschen.

WordPress Performance verbessern: In deiner Pluginübersicht wird dir genau angezeigt, wie viele Plugins du installiert, aktiviert und noch zu aktualisieren hast.
Deine Plugin-Übersicht zeigt dir genau an, wie viele Plugins derzeit deaktiviert sind. Im Prinzip sollte bei “Inaktiv” immer eine Null stehen. Wenn nicht, frage dich genau: Brauche ich das deaktivierte Plugin überhaupt?

Gleiches gilt für Themes: Mehr als eines brauchst du nicht.

Der Hintergrund ist folgender: Jedes Plugin und jedes Theme fügt deiner Seite PHP-Code hinzu. Das gilt auch für deaktivierte Plugins. Somit wird deine Seite insgesamt sperriger und damit langsamer (und anfälliger für Angriffe). Denn PHP ist eine sehr langsame Skriptsprache. Je weniger hiervon vorhanden ist, desto besser.

Häufig sind nicht mehr benötigte Plugins und Themes Überbleibsel von Funktions- und Designtests. Daher bietet es sich zum einen an, deine WordPress-Seiten regelmäßig aufzuräumen und zum anderen solltest du neue Funktionen und Designs in einer Testumgebung testen und nicht auf der Live-Seite. So kannst du erst gar nicht zu viele Plugin-Überreste anhäufen.

#3 Bilder: die unterschätzte Ladezeitbremse

Eine der effektivsten und einfachsten Maßnahmen zum Verringern der Seitenladezeit ist das Verkleinern von Bildern. Denn hier kannst du teils große Datenmengen einsparen. Bei der sogenannten „lossless image compression” wird die Dateigröße deiner Bilder verringert, ohne dass dabei sichtbare Qualitätsverluste entstehen. Deine Seite verändert sich also kaum, gleichzeitig kannst durch Bildoptimierung ihre Größe deutlich verringern.

Schätzungen von HTTP Archive zufolge machen Bilder regelmäßig den größten Anteil der Datenmenge einer Website aus. Das Verkleinern deiner Bilder sollte also einer der ersten Optimierungsschritte sein. Eine Bildoptimierung kannst du entweder manuell machen, oder aber du nutzt hierfür ein Compression Plugin.

Ein Plugin zu verwenden ist sicherlich die komfortablere Lösung. Denn Plugins erlauben es dir nicht nur, neue Bilder und deren Thumbnails zu komprimieren, sie knöpfen sich teils auch automatisch alle bestehenden Bilder deiner Seite vor. Dieser Dienst ist allerdings häufig kostenpflichtig.

#4 CSS und JavaScript – klingt sperrig, ist aber leicht zu optimieren

Die zweitgrößte Datenmenge deiner Seite sind in der Regel JavaScript- und CSS-Dateien. Hier zeigen besonders viele Nutzer Berührungsängste. Doch auch ohne Code-Kompetenz kannst du ganz leicht verstehen, worum es bei der Optimierung von CSS und JavaScript geht. Denn im Prinzip gibt es hier erst einmal drei Dinge zu tun:

  • Zusammenfassen: CSS und JavaScript verbergen sich in vielen kleinen Einzeldateien. Normalerweise muss jede dieser Dateien vom Browser einzeln beim Webserver angefragt werden. Das erzeugt HTTP-Requests, die die Ladezeit deiner Seite tendenziell verlängern. Wenn jedoch Skripte zusammengefasst werden, dann verringert sich die Anzahl der zu ladenden Dateien und damit die Zahl der Requests. So werden bspw. aus 53 Einzelabrufen nur noch gut ein Dutzend. Natürlich können auch das entsprechende Plugins für dich erledigen.
  • Reduzieren: CSS- und JavaScript-Dateien sind Codezeilen, die auf deiner Seite bestimmte Funktionen und Designs ermöglichen. Geschrieben wird dieser Code von Menschen. Ausgelesen wird er aber von Maschinen. Warum ist das relevant? Vieles von dem, was ein Mensch benötigt, um Code korrekt verstehen zu können, braucht der Computer nicht. Leerzeichen, Kommentare usw. werden also nicht benötigt, damit deine Seite korrekt aufgebaut werden kann. Genau hier setzen Plugins wie Autoptimize an. Sie konvertieren CSS und JavaScript von menschen- in maschinenlesbaren Code. Das macht die einzelnen Datenpakete kleiner und deren Übertragung damit schneller.
  • Komprimieren: Nach dem Zusammenfassen und Reduzieren ist der letzte Schritt dann die Komprimierung der Datenpakete, die vom Webserver an den Browser geschickt werden. Das heißt, dass der Server die Dateigröße der einzelnen Request minimiert und der Browser diese entpackt und berechnet. Das geht schneller, als unkomprimierte Datenpakete zu versenden. Einrichten kannst du so eine GZIP-Komprimierung zum Beispiel über Caching-Plugins, über manuelle Einstellungen in der .htaccess oder aber dein Hoster hat eine Komprimierung schon serverseitig aktiviert.

Auch ohne Kenntnis der Skripte ist also leicht verständlich, was die einzelnen Maßnahmen bringen. Und für alle drei Arbeitsschritte gibt es Plugins, die es auch Laien ermöglichen CSS und JavaScript zu optimieren. In unserem Artikel zur CSS und JavaScript-Optimierung, erklären wir dir weitere Details und stellen verschiedene Plugins vor.

Vier gewinnt!

Das waren die vier Bereiche, in denen unsere Kunden besonders viel Ladezeit einsparen konnten. Mit verhältnismäßig wenig Aufwand kannst du deine WordPress-Performance also schon durch Caching, Bildoptimierung, das Optimieren von CSS & JavaScript sowie das Aufräumen von WordPress deutlich verbessern.

#5 Ohne Hosting ist alles nichts

Die ersten vier Optimierungsfelder versprechen zwar besonders viel Ladezeitverkürzung, können jedoch im Sande verlaufen, wenn dich dein Hosting ausbremst. Damit sind weniger die Hardware-Voraussetzungen für WordPress gemeint, sondern vielmehr bestimmte Technologien, die dir zeigen, dass ein Hoster es dir überhaupt ermöglicht,WordPress entsprechend zu optimieren.

Als Daumenregel kannst du dir merken, dass performantes WordPress-Hosting diese Eckdaten haben solle:

  • SSD-Festplatte
  • PHP Memory-Limit von mindestens 64MB, besser 128MB
  • Rechenzentrum in Deutschland
  • Aktuelle PHP-Version (7.4)
  • HTTP/2 und kostenloses SSL-Zertifikat

Dann gibt es noch den Unterschied zwischen Shared Hosting und einem eigenen (virtuellen) Server.

Beim Shared Hosting teilst du dir den Server und dessen Rechenleistung mit anderen Seiten. Meist wenige dutzend bis einige hundert. Bei einem eigenen Server musst dir die Rechenleistung mit niemandem teilen. Er bietet also vor allem den Vorteil der Leistungssicherheit.

Zwar ist ein eigener Server nicht gleichbedeutend mit mehr Performance, die Erfahrung zeigt aber: Besonders die billigen Hostingtarife, die nur wenige Euro im Monat kosten, können performancetechnisch nicht mit virtuellen Servern mithalten.

Die Feinheiten – weniger Durchschlagskraft, mehr Aufwand

Alle performancerelevanten Bereiche, die ich bisher genannt habe, lassen sich quasi von jedem WordPress-Nutzer optimieren. Entweder über Plugins, einfaches Ausprobieren oder den Kauf entsprechender Produkte. Komplizierter wird es da schon, wenn du diese Bereiche bereits optimiert hast. Denn dann musst du tiefer in die Seitenstruktur eindringen. Und einzelne Optimierungsmaßnahmen haben nicht mehr dieselbe Durchschlagskraft.

#6 Renderblocking – falsche Reihenfolge beim Laden

Ein Punkt, der von Tools wie Google PageSpeed Insights immer wieder moniert wird, ist eine Ladereihenfolge, die das Rendering blockiert.

An einem Beispiel wird das Problem deutlich: Ein Slider besteht aus Bildern und dem Animationsbefehl, der diese Bilder rotieren lässt. Wird nun der JavaScript-Befehl zuerst geladen und die Bilder zum Schluss, dann verfügt deine Seite zwar schon über die Funktion des Sliders, nicht aber über Bilder, die angezeigt werden sollen. Das Laden der Seite dauert also länger. Dieser Zustand kann durch die richtige Ladereihenfolge verhindert werden.

Zwar gibt es für die Optimierung der Ladereihenfolge Plugins, doch unsere Erfahrung zeigt, dass diese nicht immer in der Lage sind, deine Seite vollständig zu optimieren. Die besten Ergebnisse erreicht in einem solchen Fall tatsächlich meist ein Webdesigner, der sich mit der Seite und deren Funktionen gut auskennt.

#7 Above the Fold – den sichtbaren Bereich der Seite optimieren

Neben der Gesamtladezeit deiner Seite ist vor allem die gefühlte Ladezeit entscheidend. Also die Zeit, die ein Besucher deiner Seite als Ladezeit wahrnimmt. Diese gefühlte Ladezeit kann mit einigen Tricks verkürzt werden. So bekommt ein User den Eindruck, die Seite sei schon komplett aufgebaut, obwohl im Hintergrund noch gerechnet wird.

Besonders wichtig für die Optimierung dieses als Above the Fold bezeichneten Bereichs ist die Optimierung der Ladereihenfolge. Das heißt, dass Inhalte und Funktionen priorisiert werden, die deine Besucher auf der ersten Bildschirmgröße dargestellt bekommen sollen.

WordPress Performance: Abbildung des Above the Fold von raidboxes.de
Der obere Bereich wird dem Besucher von raidboxes.de ohne Scrollen angezeigt. Das ist der sogenannte Above the Fold. Für alle weiteren Informationen muss der Besucher mit der Seite interagieren und scrollen.

Das erreichst du zum Beispiel durch eine Optimierung der Ladereihenfolge. Es gibt aber auch Plugins, die dafür sorgen, dass deine Seite effizienter lädt. Und zwar nur den jeweils sichtbaren Bereich. Lazy Load oder a3 Lazy Load sind Beispiele solcher Plugins. So bekommt der Nutzer zwar immer alle Inhalte angezeigt, die er oder sie braucht, die Seitenladezeit kann davon aber trotzdem profitieren, gerade wenn es sich um eine bildlastige Seite handelt.

#8 Datenbank aufräumen

Neben Bildern und Skripten, kann auch deine Datenbank zu groß werden. Auch hierfür gibt es praktische Tools, die deine Datenbank schön schlank halten. Beispielsweise das Plugin WP-Optimize.

#9 Pingbacks und Trackbacks

Standardmäßig interagiert WordPress mit anderen Seiten, die Pingbacks und Trackbacks erlauben. Jedes Mal, wenn deine Seite oder einer deiner Blogposts auf einer solchen Seite erwähnt wird, wird deine Seite automatisch benachrichtigt – und damit die Datenbank zusätzlich belastet.

Wenn du dieses Feature nicht benötigst (der Mehrwert ist aus meiner Sicht verschwindend gering) sollte Pingbacks und Trackbacks deaktivieren. Auch hier hilft wieder das Plugin WP-Optimize. Der Vollständigkeit halber muss an dieser Stelle aber erwähnt werden, dass es sich hierbei eher um ein theoretisches Problem handelt. Ernsthafte Performance-Einbußen hatte dadurch bisher keiner unserer Kunden.

#10 Hotlinking verhindern

Hotlinking bedeutet, dass jemand direkt auf ein Bild auf deinem Server verlinkt – im Endeffekt also deine Bandbreite „klaut“. Bei einem Apache-Webserver kannst du Hotlinking verhindern, indem du folgenden Code in die .htaccess Datei einfügst:

RewriteEngine on

RewriteCond %{HTTP_REFERER} !^$

RewriteCond %{HTTP_REFERER} !^http(s)?://(www.)?deineseite.de [NC]

RewriteCond %{HTTP_REFERER} !^http(s)?://(www.)?google.de [NC]

RewriteCond %{HTTP_REFERER} !^http(s)?://(www.)?google.com [NC]

RewriteRule .(jpg|jpeg|png|gif)$ – [NC,F,L]

Um Hotlinking auf einem NGINX-Server zu verhindern, füge diese Codezeilen in deiner NGINX wp-config Datei hinzu:

location ~ .(gif|png|jpeg|jpg|svg|webp)$ {
     valid_referers none blocked server_names
	 *.example.com example.* www.example.org/galleries/ ~\.google\.;
     if ($invalid_referer) {
        return 403;
    }
}

Aufschlüsselung des Codes:
location ~ .(gif|png|jpeg|jpg|svg|webp)$ {
gibt die Dateiendungen an, welche du vor Hotlinking schützen willst, wenn du zum Beispiel noch pdf-Dateien schützen willst, sähe die Codezeile so aus:
location ~ .(gif|png|jpeg|jpg|svg|webp|pdf)$

{valid_referers none blocked server_names
*.deineseite.dedeineseite.de ~.google. ~.bing. ~.yahoo.;
Diese Zeilen sind etwas umfangreich, aber es hilft dir besser zu verstehen, was man alles mit dieser Regel machen kann. Diese Zeilen geben quasi an, welche Domains deine Dateien trotzdem hotlinken dürfen. In diesem Beispiel deineseite.de mit allen Subdomains, sowie Google, Bing und Yahoo.

if ($invalid_referer) {
return 403;
}
Wenn nun ein Request herein kommt, und die anfrage Ressource NICHT in deiner Whitelist oben steht, gibt der Server einen 403 (Forbidden) zurück.

Du hast keinen Zugriff auf die wp-config?

Du fragst dich, was du tun kannst, wenn Veränderungen der wpconfig bei deinem Hoster (wie zum Beispiel bei RAIDBOXES) nicht möglich sind? Für diesen Fall gibt es zahlreiche Security-Plugins im offiziellen WordPress Pluginverzeichnis, die Hotlinking verhindern. Ein Plugin, welches diese Funktion anbietet, ist zum Beispiel All In One WP Security & Firewall. Das Plugin ist auf über 800.000 WordPress-Seiten aktiv und hat eine durchschnittliche Bewertung von 4,8 von 5 Sternen (bei fast 1.000 Reviews).

“Und was ist mit CDN?”

Eine der am häufigsten gestellten Fragen ist die nach einem CDN. Zum Beispiel: “Macht ein CDN meine Seite schneller für Besucher in Deutschland?”, “Wozu brauche ich eigentlich ein CDN?”, “Würdet ihr mir empfehlen, ein CDN für meinen Blog oder Shop zu nutzen?”. In den meisten Fällen war die Antwort aber: Nein.

Um es kurz zu machen: Ein CDN macht am meisten Sinn, wenn deine Nutzer geografisch weit verteilt sind. Wenn du also beispielsweise Kunden in Mitteleuropa, Südamerika und Australien hast. Wenn sich deine Kernzielgruppe auf ein Land beschränkt, kannst du ein CDN zur Optimierung deiner WordPress-Performance direkt ad acta legen.

Zu der Problematik hat der WordPress-Entwickler Ernesto Ruge übrigens einen sehr schönen Artikel geschrieben, den ich dir nur ans Herz legen kann.

Fazit: Hab keine Angst vor kompliziert wirkenden Optimierungsschritten

Häufig haben Nutzer Berührungsängste mit solchen Bereichen, in denen sich besonders leicht Ladezeit einsparen lässt. Oder sie vernachlässigen diese Bereiche. Andere hingegen, wie CDN, kommen bei Beratungsgesprächen immer wieder auf, obwohl sie meist gar keine Auswirkung auf die Seitenladezeit haben.

Daher kann ich nur dazu raten, dass du dich zunächst auf die “low hanging fruits” der Optimierung konzentrieren solltest. Denn mit verhältnismäßig wenig Aufwand kannst du hier schon große Fortschritte bei der Verringerung deiner Ladezeit machen. Und das auch, wenn du Laie bist.

Lasse dich daher nicht von den Ratschlägen von Tools wie Google PageSpeed Insights verunsichern.

Denn im Kern geht es bei der Ladezeitoptimierung um nur wenige Bereiche:

  • Reduzierung der Größe deiner Seite
  • Reduzierung der HTTP-Requests
  • Komprimierung der einzelnen Datenpakete
  • Optimierung des Nutzererlebnisses

Wenn du das verstanden hast, dann kannst du auch sinnvoll an den 10 wichtigsten Stellschrauben der WordPress-Performance drehen. Und für komplexere Optimierungsschritte gibt es auch Experten, die deine Seite auf Vordermann bringen können.

Ähnliche Artikel

Kommentare zu diesem Artikel

J
Jan Hornung

Danke für die Blumen! Vom Marcel kommen wie gesagt auch noch zwei Artikel die zeigen, wie die einzelnen Punkte dann richtig optimiert werden können und welche Vorschläge (bspw. von PageSpeed Insights) wirklich wichtig sind.

Schaut also wieder rein. Und wir freuen uns natürlich über jeden Kommentar und jede Anregung 🙂

B
Bernhard

Hallo Marcel,

schöner Artikel. Was ist aber bei Punkt 1 nicht verstehe, sind die Säulen “WP Backend” und vor allem “WP-Seite”, die noch nach dem PHP kommen sollen. Außerdem fehlt in dem Schaubild die Datenbank.

Den 9. Punkt kann ich gar nicht nachvollziehen. Pingspacks als ein Performance-Problem zu sehen, halte ich für übertrieben. Oder habt ihr etwa hunderte Pingpacks pro Minute? Wäre ja schön, wenn es so wäre, da ihr dann so häufig verlinkt werdet. Aber ich würde mal sagen jeder normale Seitenaufruf verursacht um einiges mehr Datenbank-Traffic also ein simpler Pingback 🙂

P.S. Die Post-Navigation (“vorheriger Beitrag”) verdeckt du unteren 2/3 des “Kommentar abschicken” Buttons.

Jan
Jan

Hi Bernhard,

sorry erstmal für die verspätete Antwort! Wir ziehen gerade ins neue Büro um und haben etwas Urlaub zu kompensieren. Um keine weitere Verwirrung zu stiften, habe ich das Schaubild mal vorläufig entfernt. Wir stellen es dann wieder rein, wenn es überarbeitet ist. Dann herrscht hierzu auch mehr Klarheit 🙂

Zu Punkt 9: Pingbacks/Trackbacks erzeugen Schreibzugriffe auf die Datenbank und lassen sich deshalb nicht durch einen serverseitigen Seiten-Cache cachen (der auf unseren Servern eingerichtet ist). Ich gebe dir vollkommen recht: das ist nur bei sehr vielen Schreibzugriffen ein Problem. Bei einigen unserer Kunden kam es hierdurch zu Problemen, da sehr viele (Spam-)Anfragen gesendet wurden. Deswegen haben wir den Punkt in diese Übersicht mit aufgenommen.

Und natürlich vergessen wir auch die Navigation nicht 😉

Danke für deinen Input!

s
smallboy

Hallo und lieben Dank für den Artikel!

Sehr wertvolle und wichtige Insights die es auf den Punkt bringen. Nur bei Punkt 1 habe ich eine kritische Anmerkung: Wie löst ihr beim serverseitigen Caching das Problem von z.B. nginx cache, varnish etc., dass der erste User der die aktualisierte Seite aufruft nicht über den Cache aufruft, sondern direkt aus der Datenbank und damit eine schlechtere Ladezeit erlebt als User die nach ihm folgen und in den Genuss des Caching kommen.

Danke und liebe Grüße
smallboy

Marcel
Marcel

Hi smallboy,

das ist eine gute Frage. Tatsächlich bieten wir aktuell keine Lösung für den von dir beschriebenen Fall. In der Praxis wird das allerdings nur für spezielle Webseiten zum Problem, z.B. bei stark frequentierten Webseiten oder bei Webseiten, die extrem hohen Rechenaufwand für die Generierung der Seiten benötigen (dann sollte man allerdings über ein Redesign nachdenken).

Im technischen Jargon nennt man dieses Feature “Cache Warming”. Das sorgt dafür, dass der Cache möglichst nicht leer ist und damit “teure” Cache Misses erzeugt.

Die simpelste Lösung dafür ist übrigens, dass man z.B. 1x täglich einen “Broken Link Checker” über die gesamte Webseite laufen lässt. Dadurch landen alle Seiten automatisch im Cache und zusätzlich erhält man noch wichtige Fehlermeldungen, falls tatsächlich Links defekt sind.

Beste Grüße,
Marcel

G
G. S.

Hi,

ich suche eine gute Möglichkeit um den Quellcode zu formatieren. Es würde mir schon reichen, wenn man überflüssige Zeilen und Leeräume entfernen könnte (Mit einem Plugin oder einem Codeschnipsel).
Der Hintergrund ist das ich auch Minify-Plugins einsetzte und nach dem Komprimieren bleiben große weiße Leeräume übrig da, wo vorher die Javascripte (z.B. Head-Bereich) untereinander aufgeführt waren. Das sieht unschön aus und wirkt auf nicht so professionell. Ich hätte es nicht gedacht aber Kunden schauen da auch gerne mal im Quellcode nach.
Gibt es da eine Möglichkeit? Würde mich freuen, wenn Ihr da ein Tipp für mich hättet.

Jan
Jan

Hi 🙂

Mit welchem Plugin hast du denn bisher gearbeitet? Von diesem Verhalten höre ich tatsächlich auch zum ersten Mal. Rein aus der Komprimierungsperspektive ist ja aber eigentlich egal, wie genau ein Header nach der Komprimierung aussieht, solange er natürlich lesbar ist und eben komprimiert. Die Frage wäre jetzt: Hat diese, sagen wir mal: unelegante, Form auch die Funktion beeinflusst?

Viele Grüße aus Münster!

M
Marie

Hi,

ich habe unlängst Punkt 10 Eures Blogbeitrages umgesetzt, aber zuerst einmal den Code irrtümlich fehlerhaft in die .htaccess-Datei eingegeben (- was natürlich längst behoben ist -).

Das Interessante dabei war, dass sich der Fehler auf meiner Website, die bei einem anderen Hoster liegt, derart fatal auswirkte, dass in der Mediendatei die Ansicht der Bilder verschwand, aber auf meiner Website, die von Euch gehostet wird, meine Fehleingabe keine Wirkung zeigte.

Schließe ich daraus richtig, dass der Fehler deshalb im Fall der Website bei Raidboxes nicht auftrat, weil bereits serverseitig Hot Linking unterbunden wird, sodass meine eigene Eingabe völlig wirkungslos blieb – und auch völlig unnötig war?

Und Zusatzfrage: Machen bei von Raidboxes gehosteten Websites grundsätzlich Eingaben in die .htaccess-Datei Sinn wie

order allow,deny
deny from xx.xx.xx.xx
allow from all

zur Aussperrung von fremden IP-Adresse, die sich vielfach einloggen wollen etc., oder sind solche Einträge für bei Euch liegende Websites unnötig?

Herzlich fragende Grüße aus Dortmund!

Jan
Jan

Grüß dich Marie,

der Jan hier 🙂 Korrekt: Die .htaccess-Datei hat auf unseren Servern keinerlei Effekt, daher kann hier auch kein Fehler im Zusammenhang mit der .htaccess-Datei auftreten. D.h. aber auch, dass bei uns grundsätzlich Eingaben in die .htaccess keinen Sinn machen. Wir stellen aber natürlich für die jeweiligen Mechanismen eigene Tools zur Verfügung. In deinem konkreten Fall könntest du z.B. unser Listing-Tool verwenden. Wie du konkret eine Black- oder Whitelist einrichtest, haben wir hier einmal ausführlich erklärt: https://helpcenter.raidboxes.de/performance-und-sicherheit/sicherheit/ip-blacklists-und-whitelisting

Allerdings haben wir den Login-Bereich von WordPress noch einmal zusätzlich abgesichert, sodass IP-Adressen, die sich mehr als dreimal mit falschen Logindaten einzuloggen versuchen, automatisch ausgesperrt werden. Eine Blacklist für den Schutz des Login-Bereichs musst du also nicht extra einrichten 😉

Viele Grüße aus Münster!

M
Marie

Hi,

jetzt noch eine Frage zu 7) Above the Fold:
Für das von Euch empfohlene Plugin zur Optimierung der Ladereihenfolge, “Lazy Load”, gab es schon seit 2 Jahren kein Update mehr und wurde vom Entwickler nur bis zu WordPress 4.6.12 getestet.
Ist Lazy Load nach wie vor Eure 1. Empfehlung, da es sich offenbar um ein sehr schlankes Plugin handelt, sodass kein Update nötig ist?

Nochmals herzliche Grüße aus Dortmund!

Leefke
Leefke

Hi Marie, du hast natürlich Recht, dass das letzte Update und die getestete Version ein Indiz für die Qualität eines Plugins sein können. Dass es kein Update gab, könnte allerdings – wie von dir vermutet – ebenfalls bedeuten, dass es nichts zu updaten gab und das Plugin einwandfrei läuft. Wenn du ein schlechtes Gefühl damit hast, könnte z.B. a3 Lazy Load eine Alternative für dich sein. Das Plugin ist auf über 100.000 Seiten aktiv, wurde vor 3 Monaten aktualisiert und bis 4.9.8 getestet.
Besten Gruß aus Münster,
Leefke

Holger
Holger

Das Plugin verbessert den PageSpeed Score und unter Umständen auch die Ladezeit beim minimieren von CSS und JS Code.
Das Zusammenfügen von CSS und JS Dateien bringt aber bei HTTP/2 Verbindungen – also alle SSL Verbindungen die mittlerweile ja Standard sind – keine Geschwindigkeitsverbesserungen.
HTTP/2 erlaubt das parallele Laden von Dateien.
Leider ist das kaum bekannt und selbst Google Insights vergibt einen höheren Score.
Maßgebend ist die tatsächliche Ladezeit.

Diese zu optimieren gibt es viele Punkte. Z.B. setze ich als Bildformat WebP ein, was wesentlich kleiner ist als JPG ohne Qualitätsverluste.

Noch mehr Tipps habe ich in meinem umfangreichen WordPress PageSpeed Guide:
https://holgerfreier.de/wordpress-pagespeed-guide/

Leefke
Leefke

Danke für deinen Input und deinen Guide, Holger. Über WebP haben wir übrigens gerade einen Artikel in Arbeit, das ist ein spannendes Thema!
LG aus Münster
Leefke

Udo
Udo

Hallo!

Wie verhindere ich denn bei Raidboxes das Hotlinking? Hab Tino vor einiger Zeit schon mal im Chat drauf angesprochen und den Tipp bekommen, dass das über die CSP Settings gehen soll. Hab jetzt schon ein paar mal angefangen mich mit dem Thema zu beschäftigen, konnte aber nichts konkretes dazu im Internet finden. Könnt ihr das Snippet nicht einfach hier zur Verfügung stellen? Erspart sicherlich auch ein paar Supportanfragen 😉

Viele Grüße,
Udo

Jan
Jan

Hi Udo,

der Jan hier 🙂 Da hat der Tino dir schon genau den richtigen Tipp gegeben. Denn den einen vollständigen Hotlinking-Schutz gibt es so eigentlich nicht. Die meisten Nutzer (und davongeht auch der Artikel aus) verstehen darunter den Zugriffsschutz für Bilder aus allen externen Quellen. Aber der Bereich der CORS Header bzw. Security Header, die den Zugriff auf Ressourcen auf deiner Seite regeln, umfasst natürlich deutlich mehr als nur Grafiken und Co.

Das klingt jetzt etwas schwammig 😉 Um es also präziser zu machen: Dadurch, dass wir keinen Button anbieten, der ein Default-Script einbindet und per se alle externen Server daran hindert Ressourcen deiner Seite zu nutzen, bieten wir den Nutzern die Möglichkeit viel besser und feiner aussteuern zu können welche Externen auf welche Teile der eigenen Seite Zugriff haben.

Ein Beispiel: Wenn du einen Shop und einen Blog auf zwei unterschiedlichen BOXEN betreibst, die beiden aber jeweils Ressourcen des anderen verwenden, ist es nötig hier eine fallspezifische Header Policy zu erstellen.

In der Umsetzung heißt das für dich, dass du dich zunächst fragen musst: Was möchte ich eigentlich erreichen? Diese Anforderung kannst du dann in die Security Header übersetzen, z.b. in CORS oder CSP Header.

Die Syntax für diese Header ist dann immer die Herausforderung. Denn dazu gehört auch das Testing. Das klappt z.B. über einen curl -I oder auch über den Network-View im Browser. Du merkst schon: Es gibt hier nicht die eine Lösung, wenn du aber weißt, was du brauchst, lässt sich das meist recht fix umsetzen. Schick uns gerne auch mal deine Header Config im Support zu, dann können wir diese nochmal von uns aus prüfen 🙂

R
Rüdiger

Hallo zusammen,

immer noch ein Super Artikel hier, ganz klar, super Arbeit!
Was mir fehlt ist das Thema DNS: Es gibt hier durchaus Unterschiede von 1 – 1,5 Sekunden in der Antwortzeit. Das verzögert das Aufrufen der Startseite auch entsprechend.
Sicherlich kein Weltuntergang: Aber in Zeiten, in denen auf dem Smartphone nach 2 Sekunden schon weggeklickt wird, ein wichtiger Faktor.

Gruß
Rüdiger

Leefke
Leefke

Hallo Rüdiger,
vielen Dank für das Lob und dein Feedback, das ist in der Tat ein guter Punkt, den man noch berücksichtigen könnte.
LG aus Münster
Leefke

Schreibe einen Kommentar

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