WordPress schneller machen lassen

Google bewertet eine Seite als schnell, wenn ihr größtes Element nach spätestens 2,5 Sekunden sichtbar ist. Für die Antwort des Servers nennt Google 0,8 Sekunden als groben Richtwert (Stand Oktober 2026). Maßgeblich ist das 75. Perzentil der Seitenaufrufe, getrennt nach Smartphone und Desktop: Mindestens drei von vier Aufrufen sollen unter der Schwelle bleiben. Einen ersten Eindruck von Ihrer Startseite gibt Ihnen PageSpeed Insights.

Der erste Wert heißt Largest Contentful Paint (LCP). Der zweite Wert, die Time to First Byte (TTFB), misst, wann das erste Byte der Antwort ankommt. Beide Schwellen nennt Google auf web.dev, die für die TTFB in einem eigenen Beitrag. Zu den Core Web Vitals gehören neben dem LCP auch die Interaction to Next Paint (INP, gut bis 200 Millisekunden) und der Cumulative Layout Shift (CLS, gut bis 0,1); die TTFB zählt dagegen nicht dazu. Was die Werte im Einzelnen messen, erklärt mein Ratgeber zu den Core Web Vitals.

Eine Messung lohnt sich, wenn Ihnen eines dieser Anzeichen auffällt:

Zuerst kläre ich, ob der Server zu langsam antwortet oder der Browser zu lange lädt. Dafür sehe ich mir auf dem Server die TTFB, die PHP-Version, die Plugins und die Datenbank an, im Browser das größte Element, die Skripte, die Stylesheets und die Bilder. Davon hängt ab, was hilft, und damit auch, ob ein Caching-Plugin überhaupt etwas bringt.

Wie groß der Unterschied sein kann, zeigen drei WordPress-Seiten mit Page Builder, deren Ladezeit ich 2026 im Labor gemessen habe. Der Server antwortete jeweils nach höchstens rund einer Sekunde, das größte Element der Startseite stand im mobilen Test aber erst nach mindestens sechs Sekunden. Jede der drei Startseiten lud mehr als 20 Stylesheets und mehr als 20 Skriptdateien, bei zwei war das größte Element ein Bild-Slider im Seitenkopf. Gemessen habe ich dabei mit Lighthouse im Mobilprofil, die Server-Antwort zusätzlich mit einzelnen Abrufen ohne Drosselung. Drei Seiten sind wenig und waren keine Zufallsauswahl, und der LCP ist ein hochgerechneter Laborwert: Die Messungen zeigen die Größenordnung und wo ich zuerst nachsehe, nicht, wie es bei jeder WordPress-Seite aussieht.

Ein Seiten-Cache hätte bei diesen drei Seiten also höchstens rund eine Sekunde eingespart, denn die übrigen Sekunden gingen im Browser verloren.

Ich sage keine PageSpeed-Punktzahl und keine Ladezeit zu, denn Inhalte, Erweiterungen, Hosting und Netz bestimmen die Werte mit und ändern sich nach der Übergabe. Stattdessen messe ich dieselben Seiten mit demselben Werkzeug vorher und nachher und vergleiche die Sekunden. Die Punktzahl selbst ist nur ein gewichteter Mittelwert aus mehreren Labormesswerten.

Laut der Lighthouse-Dokumentation zählt der LCP in Lighthouse 10 mit 25 Prozent, den Rest teilen sich vier andere Messwerte (Stand Oktober 2026). Dazu schwanken Labormesswerte von Lauf zu Lauf, wie Google zu PageSpeed Insights erklärt.

Wie wenig die Punktzahl über den Erfolg sagen kann, zeigt eine WordPress-Seite mit Page Builder, die ich 2026 beschleunigt habe. Der Server antwortete schon vorher nach weniger als einer halben Sekunde, die Zeit ging also im Browser verloren: Stylesheets und Skripte kamen unkomprimiert, mehrere Dutzend davon blockierten den Aufbau, und die Bilder waren nicht fürs Web aufbereitet. Nach Komprimierung, WebP-Bildern, einem Seiten-Cache und verzögert geladenen Skripten war der LCP der Startseite im mobilen Lighthouse-Test auf weniger als die Hälfte gesunken. Die Leistungspunktzahl stieg über die ganze Messreihe aber nur um einen Punkt. Das ist ein einzelner Fall mit je einem Messlauf pro Schritt, und den Anteil des Seiten-Caches habe ich nicht getrennt gemessen.

Solange die Werte weit über dem Ziel liegen, taugt die Punktzahl deshalb schlecht als Erfolgsmaß. Was ich Ihnen zusage, ist die Messung: dieselben Seiten, dasselbe Werkzeug, mobil und Desktop, vorher und nachher in Sekunden, bei knappen Unterschieden mit mehreren Läufen. Das Ergebnis bekommen Sie in einem kurzen Bericht, zusammen mit den Maßnahmen, die ich umgesetzt habe.

Die Beschleunigung passt zu WordPress-Websites, bei denen ich Zugang zum Hosting und zur Datenbank bekomme, auch zu WooCommerce-Shops und Seiten mit Page Builder, denn dort sitzen die Stellschrauben, an denen ich ansetze: PHP-Version, Plugins, Datenbank, Bilder, Skripte und der Cache. In diesen Fällen ist dagegen eine andere Leistung der bessere Anfang: