- Die wirksamsten Tempo-Gewinne kommen nicht aus teuren Redesigns, sondern aus vier Bereichen: gutes Hosting mit aktueller PHP-Version, serverseitiges Caching, optimierte Bilder und schlanke Plugins.
- Google misst drei Core Web Vitals: LCP (Ladezeit des größten Elements, Ziel unter 2,5 s), INP (Reaktionszeit auf Eingaben, Ziel unter 200 ms) und CLS (Layoutstabilität, Ziel unter 0,1).
- Laien können Bilder optimieren, Lazy Loading aktivieren und überflüssige Plugins deinstallieren. Hosting-Wechsel, Caching-Konfiguration und Render-Blocking-Behebung verlangen etwas Technik oder Profi-Hilfe.
- Der kostenlose Einstiegspunkt ist PageSpeed Insights: URL eingeben, Bericht lesen, Maßnahmen priorisieren.
Eine WordPress-Website, die vier Sekunden zum Laden braucht, verliert einen erheblichen Teil der Besucher, bevor die Seite überhaupt erscheint. Google wertet Ladezeit als Rankingfaktor und misst sie über die Core Web Vitals direkt aus echten Nutzerdaten. Dieser Artikel zeigt die zehn wirksamsten Maßnahmen, sortiert nach dem Verhältnis aus Aufwand und Wirkung, damit Sie dort zuerst anfangen, wo am meisten zu holen ist. Am Ende haben Sie eine priorisierte Checkliste, die Laien und Profis gleichzeitig nutzen können.
Warum Ladezeit über Erfolg und Misserfolg entscheidet
Tempo ist kein Komfortmerkmal. Google hat Ladezeit seit 2010 als Rankingfaktor für Desktop und seit 2018 für Mobilgeräte verankert. Seit 2021 fließen die Core Web Vitals als Messgröße für Nutzererfahrung direkt in die Bewertung ein. Eine Seite, die technisch korrekt aufgebaut ist, aber langsam lädt, verliert gegenüber einer schnelleren Konkurrenzseite an Position.
Für Onlineshops kommt der direkte Umsatzeffekt hinzu. Wer auf einem Mobilgerät auf eine Produktseite klickt und drei Sekunden auf den ersten Inhalt wartet, bricht im Zweifelsfall ab. Wie stark dieser Effekt bei Shops konkret ausfällt, zeigt der Artikel WooCommerce beschleunigen.
Core Web Vitals: Was Google wirklich misst
Google fasst unter den Core Web Vitals drei Metriken zusammen, die echte Nutzererfahrung abbilden, nicht synthetische Tests. Sie werden aus dem Chrome User Experience Report erhoben, also aus echten Besuchen echter Nutzer auf Ihrer Seite. Tiefere Details dazu stehen im Ratgeber Core Web Vitals einfach erklärt. Hier die drei Metriken im Überblick:
| Metrik | Was sie misst | Gut | Mangelhaft |
|---|---|---|---|
| LCP (Largest Contentful Paint) | Wann das größte sichtbare Element (Bild, Text, Video) vollständig gerendert ist | ≤ 2,5 s | > 4,0 s |
| INP (Interaction to Next Paint) | Wie schnell die Seite auf Klicks, Taps oder Tastatureingaben visuell reagiert | ≤ 200 ms | > 500 ms |
| CLS (Cumulative Layout Shift) | Wie stark sich Layout-Elemente während des Ladens unerwartet verschieben | ≤ 0,1 | > 0,25 |
Die Schwellenwerte gelten jeweils am 75. Perzentil Ihrer Seitenaufrufe, getrennt für Mobile und Desktop. Das heißt: 75 Prozent Ihrer Besuche sollen den „Gut“-Wert erreichen. Quelle: web.dev: Core Web Vitals, LCP-Dokumentation, INP-Dokumentation, CLS-Dokumentation.
LCP hängt am stärksten von Hosting, Bildoptimierung und Caching ab. INP leidet unter JavaScript-lastigem Code, der den Haupt-Thread blockiert. CLS entsteht, wenn Bilder ohne feste Dimensionen gesetzt sind oder Schriften nach dem ersten Rendern einspringen.
Wie Sie Ihre Seite messen
Der schnellste Einstieg ist PageSpeed Insights: URL eingeben, analysieren. Das Tool liefert sowohl Felddaten aus echten Nutzern als auch Labordaten aus einem simulierten Test. Felddaten zeigen, wie Ihre Seite wirklich performt, Labordaten zeigen, was sich technisch tun lässt.
Wer tiefer einsteigen will, nutzt Lighthouse direkt im Chrome DevTools unter dem Tab „Lighthouse“: Seite öffnen, F12 drücken, „Lighthouse“ auswählen, Bericht generieren. Lighthouse liefert neben den Core Web Vitals auch konkrete Hinweise auf Bilder ohne Dimensionen, Render-blocking-Ressourcen und unnötig großes JavaScript.
Beide Tools sind kostenlos. Für laufendes Monitoring ergänzt die Google Search Console den Bericht mit den echten Felddaten Ihrer Seite über Zeit.
Die 10 Maßnahmen im Aufwand-Nutzen-Vergleich
Die folgende Tabelle sortiert die Maßnahmen nach dem Verhältnis aus Wirkung und Aufwand. Starten Sie oben, auch wenn eine Maßnahme weiter unten technisch klingt, lohnt es sich, sie zumindest zu verstehen, bevor Sie investieren.
| Rang | Maßnahme | Wirkung | Aufwand | Selbst oder Profi? |
|---|---|---|---|---|
| 1 | Gutes Hosting + PHP 8.2 oder neuer | Sehr hoch (alle Metriken) | Mittel (Umzug nötig) | Profi empfohlen |
| 2 | Serverseitiges Caching | Sehr hoch (LCP, TTFB) | Gering bis mittel | Selbst möglich |
| 3 | Bilder komprimieren und WebP/AVIF nutzen | Hoch (LCP, Datenmenge) | Gering | Selbst |
| 4 | Lazy Loading für Bilder | Mittel bis hoch (LCP) | Sehr gering | Selbst |
| 5 | Schriften lokal hosten | Mittel (TTFB, CLS) | Gering | Selbst möglich |
| 6 | Überflüssige Plugins deinstallieren | Mittel (alle Metriken) | Sehr gering | Selbst |
| 7 | CSS und JavaScript minimieren | Mittel (LCP, INP) | Gering (Plugin) | Selbst möglich |
| 8 | Render-blocking Ressourcen entschärfen | Mittel bis hoch (LCP) | Mittel bis hoch | Profi |
| 9 | Datenbank aufräumen | Gering bis mittel (TTFB) | Sehr gering (Plugin) | Selbst |
| 10 | CDN einbinden | Mittel (global, LCP) | Gering bis mittel | Selbst möglich |
1. Gutes Hosting und aktuelle PHP-Version
Der Server ist das Fundament. Kein Caching-Plugin und keine Bildoptimierung holen das auf, was ein langsamer Server täglich kostet. Managed-WordPress-Hosting auf SSD-Basis mit HTTP/2 und PHP 8.2 oder 8.3 liefert messbar kürzere Antwortzeiten als Shared Hosting auf alten Paketen. PHP 8.2 ist gegenüber PHP 7.4 deutlich schneller, weil der Opcode-Cache effizienter arbeitet und der Garbage Collector verbessert wurde. Die WordPress-Dokumentation empfiehlt aktuell PHP 8.1 oder neuer, bevorzugt die jeweils letzte stabile Version.
Welche Hosting-Typen für WordPress-Betreiber in der Praxis sinnvoll sind und worauf beim Wechsel zu achten ist, erklärt der Ratgeber WordPress Hosting: Tempo und Sicherheit.
Was Laien selbst tun können: PHP-Version im Hosting-Panel prüfen und auf 8.2 oder höher stellen, falls der Hoster das erlaubt. Kein Neuaufbau nötig, nur ein Klick im Panel und ein kurzer Funktionstest der Seite danach.
2. Serverseitiges Caching
WordPress baut jede Seite standardmäßig dynamisch aus der Datenbank zusammen. Bei jedem Aufruf wird PHP ausgeführt, die Datenbank abgefragt und HTML generiert. Caching speichert das fertige HTML und liefert es beim nächsten Besuch direkt aus, ohne Datenbankabfrage. Das ist der stärkste Hebel für Time to First Byte (TTFB) und damit direkt für den LCP. Wie Caching genau funktioniert und welche Ebenen es gibt, zeigt der Ratgeber Caching verständlich erklärt.
Gute Optionen sind W3 Total Cache (kostenlos, für technisch Versierte) oder WP Rocket (kostenpflichtig, einfacher konfigurierbar). Wer managed Hosting mit integriertem Caching nutzt, braucht oft kein zusätzliches Plugin.
Was Laien selbst tun können: Ein etabliertes Caching-Plugin installieren und die Grundeinstellungen aktivieren. Vorher im Hosting-Panel prüfen, ob serverseitiges Caching bereits aktiv ist, dann kein Plugin mehr nötig.
3. Bilder komprimieren und moderne Formate nutzen
Unkomprimierte JPEG-Bilder und PNG-Grafiken in voller Auflösung sind der häufigste Einzelfehler auf WordPress-Seiten. Das größte sichtbare Element im Viewport ist fast immer ein Bild, und das Bild bestimmt den LCP. WebP bietet gegenüber JPEG bei vergleichbarer Qualität rund 25 bis 34 Prozent kleinere Dateien, wie Google in seiner WebP-Studie belegt (verlustbehaftetes WebP 25 bis 34 Prozent kleiner als vergleichbares JPEG, verlustfreies WebP rund 26 Prozent kleiner als PNG). AVIF erreicht noch kleinere Dateien, wird aber von älteren Browsern nicht unterstützt. Mehr zur Formatwahl steht im Artikel WebP und AVIF: Moderne Bildformate.
Das Plugin WebP Converter for Media oder Imagify konvertieren und komprimieren Bilder automatisch beim Upload. Wichtig: Bild in der richtigen Anzeigebreite hochladen statt ein 4000-Pixel-Foto für eine 800-Pixel-Spalte zu verwenden.
Was Laien selbst tun können: Alle neuen Bilder vor dem Upload mit einem kostenlosen Tool wie Squoosh komprimieren, ein Konvertierungs-Plugin installieren, Bilder mit korrekter Größe hochladen.
4. Lazy Loading für Bilder
Bilder, die der Nutzer beim ersten Aufruf gar nicht sieht, müssen nicht sofort geladen werden. Lazy Loading verzögert das Laden von Bildern außerhalb des sichtbaren Bereichs, bis der Nutzer hinscrollt. Das reduziert die initiale Datenmenge und entlastet den LCP. Seit WordPress 5.5 wird das loading="lazy"-Attribut automatisch auf Bilder gesetzt, die nicht im Viewport sind. Wer eine ältere WordPress-Version nutzt oder ein Page-Builder-Theme verwendet, das eigene Bild-Tags erzeugt, sollte prüfen, ob das Attribut wirklich gesetzt ist.
loading="lazy" haben. Es sollte stattdessen fetchpriority="high" tragen, damit es priorisiert geladen wird und den LCP verbessert. Diese Kombination kennen die wenigsten Page-Builder von Haus aus.Die Tiefe zu Lazy Loading und wann es die Ladezeit verschlechtern kann, erklärt der Artikel Lazy Loading richtig einsetzen.
Was Laien selbst tun können: WordPress aktuell halten (Lazy Loading ist seit 5.5 automatisch aktiv), im Theme-Editor oder Caching-Plugin prüfen, ob Lazy Loading aktiviert ist.
5. Schriften lokal hosten
Wer Google Fonts per externem Link einbindet, verursacht drei Probleme gleichzeitig: eine DNS-Abfrage zu Googles Servern, einen zusätzlichen HTTP-Request für die CSS-Datei und einen weiteren für die WOFF2-Schriftdatei. Alle drei Schritte kosten Zeit, bevor ein einziges Zeichen auf dem Bildschirm erscheint. Hinzu kommt der datenschutzrechtliche Aspekt: IP-Adressen werden an Google übermittelt, was nach DSGVO ohne ausdrückliche Einwilligung problematisch ist.
Die Lösung ist, Schriftdateien lokal auf den eigenen Server zu legen. Dafür lädt man die WOFF2-Dateien über den Google Webfonts Helper herunter und bindet sie per @font-face in der Theme-CSS ein. Das Plugin Local Google Fonts erledigt das automatisch.
Lokale Schriften helfen auch beim CLS: Wer font-display: swap und passende Fallback-Schriften definiert, vermeidet das sichtbare Einspringen der Schrift beim Laden, das als Layout Shift gewertet wird.
Was Laien selbst tun können: Plugin „Local Google Fonts“ installieren und aktivieren. Fertig.
6. Überflüssige Plugins deinstallieren
Jedes aktive Plugin kann PHP-Code beim Seitenaufbau ausführen, CSS laden, JavaScript einbetten und Datenbankabfragen auslösen, auch auf Seiten, auf denen es gar nichts tut. Zehn schlecht programmierte Plugins wiegen schwerer als dreißig gut optimierte. Wer seinen Plugin-Bestand einmal kritisch durchgeht, findet regelmäßig drei bis fünf Kandidaten: Plugins aus alten Tests, redundante Funktionen, die das Theme oder WordPress selbst längst mitbringt, und Slider-Plugins für eine Startseite, die niemand mehr besucht.
Was Laien selbst tun können: Plugin-Liste im WordPress-Backend öffnen, jeden Eintrag fragen: Brauche ich das wirklich noch? Dann deinstallieren statt nur deaktivieren, denn deaktivierte Plugins hinterlassen oft Datenbanktabellen und Optionen.
7. CSS und JavaScript minimieren
Minimierung entfernt Leerzeichen, Kommentare und unnötige Zeichen aus CSS- und JavaScript-Dateien, ohne die Funktion zu verändern. Eine Theme-CSS-Datei schrumpft dadurch typischerweise spürbar, bei JavaScript-Bundles ist der Effekt oft größer. Caching-Plugins wie W3 Total Cache oder WP Rocket bieten Minification als einschaltbare Option. Zusätzlich lässt sich ungenutztes CSS aus dem kritischen Ladepfad auslagern (CSS-Deferred Loading), was den LCP weiter verbessert.
Was Laien selbst tun können: Im Caching-Plugin die Minification-Option für CSS und JavaScript aktivieren und die Seite danach auf korrekte Darstellung prüfen. Bei Darstellungsfehlern die Minification von JavaScript wieder deaktivieren, oft genug reicht es, nur CSS zu minimieren.
8. Render-blocking Ressourcen entschärfen
Render-blocking bedeutet: Der Browser muss warten, bis eine CSS- oder JavaScript-Datei vollständig geladen und ausgeführt ist, bevor er weiteres HTML rendern kann. Das verzögert direkt den LCP. Typische Täter sind Theme-CSS im <head> ohne Critical CSS und JavaScript ohne defer– oder async-Attribut. Der Artikel Render-blocking CSS und JavaScript auflösen zeigt die konkreten Lösungsschritte.
Dieser Bereich gehört in die Profi-Sektion, weil falsch gesetztes async oder ein schlecht inliniertes Critical CSS die Seite visuell kaputt machen kann. Ein Caching-Plugin mit Defer-JavaScript-Option ist ein guter erster Schritt, aber die Feinarbeit braucht Fachkenntnis.
Was Laien selbst tun können: Im Caching-Plugin die Option „JavaScript deferred“ oder „defer JS“ aktivieren und die Seite vollständig durchtesten. Beim kleinsten Fehler die Einstellung wieder zurücknehmen.
9. Datenbank aufräumen
WordPress speichert Post-Revisionen, Entwürfe, gelöschte Einträge und Transients in der Datenbank. Bei einem gewachsenen WordPress mit mehreren Jahren Betrieb sammeln sich leicht tausende Revisionen und abgelaufene Transients an, die bei jeder Datenbankabfrage als Rauschen mitlaufen. Der Effekt auf den TTFB ist real, aber in den meisten Fällen kleiner als Hosting oder Caching. Es ist trotzdem sinnvoll, diese Last einmal zu bereinigen.
Das Plugin WP-Sweep listet überschüssige Einträge auf und löscht sie auf Wunsch. Alternativ lässt sich in WP Rocket unter „Datenbank“ ein automatisches Aufräumen planen.
Was Laien selbst tun können: WP-Sweep installieren, Bericht lesen, bereinigen. Vorher ein Backup erstellen.
10. CDN einbinden
Ein Content Delivery Network (CDN) speichert statische Dateien (Bilder, CSS, JavaScript, Schriften) auf Servern weltweit und liefert sie vom jeweils nächstgelegenen Server aus. Für eine deutsche Website mit hauptsächlich deutschem Publikum bringt ein CDN weniger Effekt als für international ausgerichtete Seiten, hilft aber trotzdem: Statische Assets kommen schneller, der eigene Server wird entlastet. Mehr zur Kosten-Nutzen-Frage steht im Ratgeber CDN für kleine Unternehmen.
Einsteigerfreundliche Optionen sind Bunny CDN (kostengünstig, einfach einzurichten) oder Cloudflare in der kostenlosen Variante. Viele managed Hoster bieten CDN-Integration bereits in ihrem Paket.
Was Laien selbst tun können: Cloudflare-Konto anlegen, Domain eintragen, CDN mit der kostenlosen Stufe aktivieren. Das dauert etwa 30 Minuten und kostet nichts.
Für Entwickler · überspringbar
Profi-Block: Render-Blocking und Critical Path
Dieser Abschnitt richtet sich an Entwickler und technisch versierte Betreiber. Einsteiger können ihn überspringen.
Wenn Lighthouse unter „Opportunities“ meldet, dass Render-blocking-Ressourcen die Seite um 0,5 Sekunden oder mehr verzögern, lohnt sich die genaue Analyse. Der Browser muss beim Parsen des HTML jede CSS- oder JavaScript-Datei ohne defer, async oder media-Attribut sofort herunterladen und auswerten, bevor er weitermacht. Das ist der kritische Renderpfad.
Die wirksamste Strategie: Critical CSS inline in den <head> schreiben (die Styles, die für den sichtbaren Bereich beim ersten Laden nötig sind), und alle restlichen Stylesheets mit media="print" onload="this.media='all'" laden. JavaScript-Dateien, die nicht für den initialen Render gebraucht werden, erhalten defer. Der Effekt auf den LCP ist messbar, der Aufwand hängt stark vom Theme ab: bei einem gut strukturierten Theme dauert es Stunden, bei einem monolithischen Seiten-Builder wie Divi kann es Tage in Anspruch nehmen und birgt Regressionsgefahr.
INP verbessert man durch JavaScript-Auslagerung in Web Worker oder durch Code-Splitting: Große JavaScript-Bundles werden erst geladen, wenn der Nutzer mit dem entsprechenden Element interagiert. Das ist in WordPress ohne eigenen Build-Prozess kaum zu realisieren, bei Page-Buildern gar nicht. In der Praxis ist bei INP-Problemen der Plugin-Audit (Maßnahme 6) der einfachere erste Schritt.
Aus der Praxis: wie zwei Maßnahmen den LCP halbiert haben
In einem Projekt sahen wir eine WordPress-Seite eines lokalen Dienstleisters mit einem LCP von 5,8 Sekunden auf Mobile, deutlich im roten Bereich. Das Beitragsbild war ein 2,4-MB-JPEG in Originalauflösung, das Hero-Bild war das erste sichtbare Element. Hosting lief auf einem günstigen Shared-Paket ohne serverseitiges Caching, PHP 7.4.
Zwei Maßnahmen: Das Hero-Bild wurde auf WebP konvertiert und auf 1.200 Pixel Breite zugeschnitten, Dateigröße danach 68 KB. PHP wurde auf 8.2 aktualisiert, ein einfaches Caching-Plugin aktiviert. Ergebnis in PageSpeed Insights: LCP auf 2,3 Sekunden. Kosten: eine Stunde Arbeit, null Euro Software. Dritte Maßnahme, die wir noch nicht angefasst hatten, war Render-Blocking durch Theme-CSS, das hätte weiteren Raum geboten.
Konkrete Prozentangaben nennen wir hier bewusst nicht, weil das Ergebnis von der Ausgangslage abhängt und wir andere Projekte nicht vergleichen. Was stimmt: Bild und Caching sind fast immer der erste Ansatzpunkt, und der Effekt ist in der Regel deutlich spürbar.
Sofort-Checkliste
Diese zehn Punkte können Sie heute selbst durchgehen. Beginnen Sie mit Punkt 1 bis 4, die haben den höchsten Aufwand-Nutzen-Quotienten.
- PHP-Version im Hosting-Panel prüfen. Ist sie auf 8.2 oder höher? Falls nicht: jetzt aktualisieren und Seite auf Fehler prüfen.
- Hosting-Typ prüfen: Gibt es serverseitiges Caching (Object-Cache, Full-Page-Cache)? Falls nicht: Caching-Plugin installieren.
- PageSpeed Insights für Startseite, eine Unterseite und eine Produktseite (falls vorhanden) aufrufen. Bericht lesen und LCP-Element identifizieren.
- LCP-Bild in WebP konvertieren und auf korrekte Anzeigebreite zuschneiden.
fetchpriority="high"prüfen, kein Lazy Loading auf dem LCP-Bild. - Alle Bilder auf der Seite: Lazy Loading aktiv? Sind Breite und Höhe im
<img>-Tag gesetzt, damit kein CLS entsteht? - Google Fonts oder andere externe Schriften im Einsatz? Lokal hosten oder Plugin dafür aktivieren.
- Plugin-Liste kritisch durchgehen: Was wird wirklich genutzt? Alles andere deinstallieren.
- CSS und JavaScript Minification im Caching-Plugin aktivieren, Seite auf korrekte Darstellung prüfen.
- Datenbank bereinigen: WP-Sweep ausführen. Vorher Backup erstellen.
- CDN aktiv? Wenn nicht: Cloudflare kostenlos einrichten oder prüfen, ob der Hoster CDN mitliefert.
- Die größten Tempo-Gewinne kommen fast immer aus Hosting-Qualität, Caching und Bildoptimierung. Das sind keine Luxusmaßnahmen, sondern die Grundlage.
- Google misst LCP, INP und CLS aus echten Nutzerdaten. Wer diese drei Metriken im grünen Bereich hat, ist bei der Suchmaschine klar im Vorteil.
- Laien können Bilder optimieren, Lazy Loading prüfen, überflüssige Plugins entfernen und ein Caching-Plugin einrichten. Render-Blocking und Critical-Path-Optimierung verlangen Fachkenntnis oder Profi-Hilfe.
- Prüfen Sie zuerst, dann handeln: PageSpeed Insights zeigt genau, wo das größte Potenzial liegt. Ohne Messung wird blind optimiert.
Häufige Fragen
Wie schnell muss meine WordPress-Website sein?
Google definiert mit den Core Web Vitals konkrete Zielwerte: LCP unter 2,5 Sekunden, INP unter 200 Millisekunden, CLS unter 0,1. Diese Werte gelten am 75. Perzentil Ihrer Seitenaufrufe auf Mobile und Desktop. Das ist die Messlatte für ein „Gut“-Urteil in PageSpeed Insights und der Search Console.
Welche Core Web Vitals sind für WordPress am wichtigsten?
LCP ist für die meisten WordPress-Seiten der kritischste Wert, weil er direkt von Hosting, Bildgröße und Caching abhängt, also von den Bereichen, die auf schlecht konfigurierten WordPress-Installationen am häufigsten vernachlässigt werden. CLS ist typisch für Seiten ohne feste Bild-Dimensionen oder mit spät einspringenden Schriften. INP betrifft vor allem JavaScript-lastige Seiten mit vielen Plugins.
Kann ich WordPress ohne technisches Wissen schneller machen?
Ja, aber nur bis zu einem gewissen Punkt. Bilder komprimieren, überflüssige Plugins deinstallieren, ein Caching-Plugin einrichten und Lazy Loading prüfen sind Aufgaben, die jeder Betreiber ohne Programmierkenntnisse erledigen kann. Render-Blocking entschärfen, Critical CSS schreiben und JavaScript-Optimierungen vornehmen verlangen Technik-Kenntnisse oder Profi-Unterstützung.
Wie viele Plugins sind zu viele?
Es gibt keine feste Zahl. Zehn gut programmierte Plugins können weniger Schaden anrichten als drei schlecht optimierte. Entscheidend ist, ob ein Plugin beim Seitenaufbau tatsächlich Code ausführt, CSS lädt und JavaScript einbettet. Ein Plugin-Audit mit Lighthouse zeigt, welche Ressourcen auf welcher Seite wirklich geladen werden.
Bringt ein CDN für eine lokale Website etwas?
Für eine rein lokale Website mit deutschem Publikum ist der Effekt eines CDN kleiner als für international aufgestellte Seiten. Der Nutzen liegt weniger in der geografischen Verteilung als in der Entlastung des eigenen Servers für statische Assets und in der besseren Cacheability. Cloudflare in der kostenlosen Stufe schadet nicht und kann zumindest einfache DDoS-Angriffe abwehren.
Muss ich meinen Shop auch optimieren?
Ja, bei Onlineshops ist Ladezeit noch wichtiger als bei reinen Informationsseiten, weil ein wartender Kunde den Kauf abbricht. WooCommerce bringt eigene Herausforderungen mit (dynamische Warenkorbseiten, Session-Handling, Zahlungsanbieter-Skripte), die sich nicht mit allgemeinem Page-Caching lösen lassen. Die spezifischen Maßnahmen für WooCommerce erklärt der Ratgeber WooCommerce beschleunigen.
Lohnt sich ein Hosting-Wechsel wirklich?
Wenn eine Seite auf Shared Hosting mit PHP 7.x ohne serverseitiges Caching läuft, ist ein Wechsel auf managed WordPress-Hosting fast immer der größte Einzelhebel, den man ziehen kann. Ein Vergleich konkreter Hosting-Typen steht im Ratgeber WordPress Hosting-Vergleich.
Was kostet eine professionelle WordPress-Optimierung?
Das hängt stark vom Ausgangszustand und vom Ziel ab. Eine Bild- und Caching-Optimierung liegt im unteren dreistelligen Bereich. Render-Blocking-Behebung und Critical-CSS-Implementierung können je nach Theme und Komplexität in den niedrigen vierstelligen Bereich gehen. Ohne vorherige Messung und Analyse ist kein seriöser Preis nennbar. Ein Betreuungsmandat kann solche Optimierungen als laufende Aufgabe sinnvoll abdecken.