Viele Tipps für schnelleres WooCommerce klingen nach Blog: Caching-Plugin installieren, alles minifizieren, jedes Bild verzögert laden, CSS zusammenfassen. Der Score steigt. Übernimmst du dieses Paket blind für einen Shop, kann es passieren, dass die Kennzahl besser aussieht und Bestellungen trotzdem scheitern. Warenkorb und Checkout sind dynamisch, an Sessions gebunden und von Skripten anderer Anbieter abhängig, die in einer festen Reihenfolge laden müssen. Auf den übrigen Seiten steckt meist mehr sicherer Spielraum. Dieser Leitfaden zeigt praxistaugliche Optimierungen und fünf Maßnahmen, die Checkouts auffällig oft beschädigen.
Beispielhafte PageSpeed-Scores. Synthetische Tools bewerten die Startseite oft hoch, während Warenkorb und Kasse langsam bleiben, weil sie nicht im Full-Page-Cache liegen dürfen.
Beispielhafte PageSpeed-Performance-Scores für denselben WooCommerce-Shop: Startseite 94, Warenkorb 58, Kasse 31. Das sind Beispielwerte, keine echte Messung.
WooCommerce Performance: Erst messen, dann optimieren
Wer Einstellungen ändert, bevor eine belastbare Ausgangszahl vorliegt, hat schnell vier Caching-Plugins und ein defektes Zahlungsformular. Miss zuerst und miss die richtigen Seiten.
Was Standard-Tools nicht sehen
PageSpeed Insights, Lighthouse, GTmetrix und WebPageTest rufen deine URL wie ein neuer anonymer Besucher auf: ohne Cookies, ohne Session und ohne Warenkorb. Für Produktseiten oder Kategoriearchive ist das genau richtig. Für transaktionale Seiten nicht, denn diese Tools sehen nicht dieselbe Seite wie deine Kunden.
Diese Punkte erfassen Standard-Tools nicht:
Den Checkout mit Produkten im Warenkorb. Ohne Session zeigt /checkout/ einen Hinweis auf den leeren Warenkorb oder leitet weiter. Genau diese Variante bewertet das Tool
AJAX-Aufwand beim Ausfüllen des Formulars. Jede Änderung von Adresse oder Versandart löst eine Neuberechnung aus. Eine einzelne Seitenmessung bildet das nicht ab
Die Zeit von „Bestellung aufgeben“ bis zur Bestellbestätigung. Hier zählen die Serververarbeitung und die Autorisierung beim Zahlungsanbieter. Genau dieser Teil entscheidet über den Abschluss
Das Verhalten für eingeloggte Nutzer. Kunden mit Konto umgehen den Page Cache vollständig und erhalten deshalb ungecachte Antwortzeiten
Die tatsächliche Größe der Datenbank. Ein Staging-Klon mit 200 Bestellungen verhält sich nicht wie ein Live-Shop mit 200.000
Produktseite, Warenkorb und Checkout getrennt testen
Die drei Seitentypen haben unterschiedliche Engpässe, deshalb brauchen sie drei getrennte Messungen:
1Produktseite, anonym, Cache aufgewärmt. Das ist dein Frontend-Score: Bilder, CSS, Schriftarten und Theme-JavaScript. Synthetische Tools liefern hier verlässliche Werte
2Warenkorbseite mit einem echten Produkt. Sie ist per Definition nicht cachebar. Beobachte die Zeit bis zum ersten Byte und die Fragment-Anfrage für den Mini-Warenkorb
3Checkout im privaten Fenster mit echtem Produkt, gedrosselter Mobilverbindung und abgeschlossener Bestellung. Erfasse getrennt, wann die Seite bedienbar ist und wie lange der Bestellabschluss dauert
Die erste Kennzahl zu optimieren, erklären die meisten Guides. Die dritte hängt direkt am Umsatz. Den vollständigen Ablauf für diesen dritten Test findest du in unserem Leitfaden zur Diagnose eines langsamen Checkouts.
Hinweis
Ein 95er-Score auf der Startseite sagt nichts über deinen Checkout aus. Beide Seiten teilen sich zwar das Theme, aber kaum mehr: Die eine ist statisch und cachebar, die andere ein vollständiger PHP-Request mit Session, Live-Summen und Skripten anderer Anbieter. Bewerte sie getrennt, sonst optimierst du eine Seite, die längst schnell genug war.
WooCommerce richtig cachen
Caching kann WooCommerce spürbar entlasten und Checkouts zugleich beschädigen. Beides ist möglich, weil oft dasselbe Plugin beide Bereiche steuert.
Page-Caching für Produkt- und Archivseiten
Full-Page-Caching speichert fertiges HTML und liefert es aus, ohne PHP zu starten. Auf Produktseiten, Kategoriearchiven, der Shop-Seite und Inhaltsseiten ist das der Unterschied zwischen einer datenbankgestützten Antwort und einer statischen Datei. Aktiviere es, lege eine sinnvolle Laufzeit fest und stelle sicher, dass deine Cache-Schicht die folgenden Ausschlüsse kennt. Verkaufst du an eingeloggte Kunden, prüfe, ob dein Cache für sie eine eigene Variante ausliefert oder ihn vollständig umgeht. Ein gemeinsamer Cache und personalisierte Preise passen nicht zusammen.
Was niemals gecacht werden darf
Warenkorb, Checkout, Mein Konto und Bestellbestätigung müssen auf jeder Ebene vom Full-Page-Cache ausgeschlossen sein. Jede dieser Seiten zeigt Daten einer einzelnen Session und Sicherheits-Nonces. Eine gecachte Kopie kann Warenkorb, Summen und Tokens eines Besuchers an den nächsten ausliefern. WooCommerce setzt auf diesen Seiten die Konstante DONOTCACHEPAGE. Die meisten WordPress-Caching-Plugins beachten dieses Signal. Hosting-Caches, Reverse Proxies und CDN-Regeln tun das häufig nicht, weil sie die Anfrage beantworten, bevor WordPress ausgeführt wird. Setze den Ausschluss deshalb in jeder vorhandenen Schicht.
Object-Caching mit Redis oder Memcached
Page-Caching hilft nicht bei Seiten, die nicht cachebar sind. Genau dort zeigt Object-Caching seine Stärke. Ein persistenter Object-Cache hält Ergebnisse wiederholter Datenbankabfragen über mehrere Anfragen hinweg im Speicher. Der nicht cachebare Checkout muss dann nicht bei jedem Aufruf dieselben Options- und Meta-Abfragen ausführen. Das ist die eine Optimierung, die Warenkorb und Checkout beschleunigt, ohne ihr Verhalten zu ändern. Viele Managed-WooCommerce-Hoster bieten Redis oder Memcached an. Unterstützt dein Hoster das, aktiviere es vor anderen Einstellungen auf dieser Seite.
Fragment-Caching für den Mini-Warenkorb
Themes mit einer Warenkorbzahl im Header bringen ein dynamisches Element auf sonst statische Seiten. WooCommerce löst das über ein AJAX-Fragment: Die Seite bleibt gecacht, der Warenkorbwert wird separat geladen. Dabei können zwei Dinge schiefgehen. Manche Caching-Plugins speichern die Fragment-Antwort und frieren die Warenkorbzahl auf dem Stand des ersten Besuchers ein. Andere deaktivieren das Fragment-Skript für ein besseres Tempo. Dann bleibt die Zahl bis zum nächsten Neuladen veraltet. Halte die Fragment-Anfrage ungecacht. Falls dein Theme es zulässt, entferne die Live-Zahl lieber von gecachten Seiten, statt einen personalisierten Wert zu cachen.
Caching-Schicht nach Seitentyp
Seitentyp
Full-Page-Cache
Object Cache
CDN für statische Assets
Hinweise
Startseite, Blog, Inhalte
Ja
Ja
Ja
Für Inhalte gut geeignet
Produkt, Archiv, Shop
Ja
Ja
Ja
Personalisierte Preise beachten
Warenkorb
Nein
Ja
Ja
Auf jeder Ebene ausschließen
Checkout
Nein
Ja
Ja
Auf jeder Ebene ausschließen, Gateway-Assets unangetastet lassen
Mein Konto
Nein
Ja
Ja
Session gebunden
Bestellbestätigung
Nein
Ja
Ja
Enthält Bestelldaten
Warenkorbfragment per AJAX
Nein
Ja
Nicht zutreffend
Caching friert den Warenkorbzähler ein
WooCommerce-Caching-Regeln nach Seitentyp
WooCommerce-Caching-Regeln nach Seitentyp: Cachebare Seiten links, transaktionale Seiten ohne Full-Page-Cache rechts. Ausschlüsse sind auf CDN-, Hosting- und Plugin-Ebene erforderlich.
Datenbank optimieren
WooCommerce schreibt deutlich mehr Daten in die Datenbank als eine reine Content-Seite und räumt nur selten automatisch auf. Die nicht cachebaren Seiten tragen die Folgen dieses Wachstums.
Transients und abgelaufene Sessions bereinigen
WooCommerce speichert Versandkostenberechnungen, Gutscheinabfragen und Plugin-Daten als Transients. Abgelaufene Einträge werden nicht immer nach einem verlässlichen Zeitplan entfernt. Kundensessions liegen in einer eigenen Tabelle und bleiben nach der letzten Aktivität noch eine Weile erhalten. Bei konstantem Traffic können sich so Tausende nicht mehr zuordenbare Zeilen ansammeln. Beides lässt sich in der Regel bereinigen. Prüfe außerdem die automatisch geladenen Optionen: Jede dieser Zeilen wird bei jedem Request geladen, auch im Checkout. Nicht mehr verwendete Plugins hinterlassen dort häufig große serialisierte Werte.
Bestelltabellenwachstum und HPOS
Bei der bisherigen Speicherung ist jede Bestellung eine wp_posts-Zeile plus mehrere wp_postmeta-Zeilen. Bestellabfragen laufen damit gegen dieselben Tabellen wie dein Content und werden mit zunehmender Zahl der Bestellungen umfangreicher. High Performance Order Storage nutzt eigene Bestelltabellen für Bestelldaten. Erweiterungen können weiterhin Metadaten verwenden. Siehe HPOS und Bestelltabellen Performance. Dort erfährst du, was sich ändert und wie du ohne Datenverlust migrierst.
Post-Revisionen und verwaiste Metadaten
Shops mit vielen Produkten sammeln Revisionen. Jede Revision ist eine weitere Post-Zeile mit eigenen Metadaten. Begrenze Revisionen in wp-config.php, statt blind zu löschen, denn Redakteure brauchen manchmal eine alte Fassung. Verwaiste Metadaten können von entfernten Plugins stammen und auf Posts verweisen, die nicht mehr existieren. Führe die Wartung in dieser Reihenfolge durch:
1Zuerst die Datenbank sichern und prüfen, ob sich das Backup wiederherstellen lässt
2Abgelaufene Transients löschen und veraltete Kundensessions
3Automatisch geladene Optionen prüfen und Reste nicht mehr genutzter Plugins entfernen
4Post-Revisionen kürzen und danach verwaiste Post- und Bestell-Metadaten löschen
5Tabellen optimieren und danach die Antwortzeiten von Warenkorb und Checkout neu messen
Schritt 5 ist wichtig: Datenbankarbeiten sind schnell erledigt, ihr Effekt wird aber leicht überschätzt. Haben sich die Zahlen nicht bewegt, lag der Engpass woanders.
Bilder und Medien
Bilder machen auf Produktseiten oft einen großen Teil der übertragenen Daten aus und sind ein vergleichsweise risikoarmer Ansatzpunkt. Nichts im Zahlungsweg hängt von ihnen ab. Komprimiere beim Upload, liefere moderne Formate aus und schicke keine 3.000 Pixel breiten Dateien in 600 Pixel breite Container.
Die Arbeit, die sich auszahlt, in Reihenfolge:
Jedes Bild beim Upload komprimieren und bestehende Medien einmal neu verarbeiten. Die Originale bleiben erhalten
WebP oder AVIF ausliefern mit einer Ausweichlösung für Browser, die das Format nicht unterstützen
Abmessungen an Anzeigegröße anpassen damit der Browser keine übergroßen Dateien herunterskalieren muss
Breite und Höhe explizit setzen damit Produktbilder das Layout nicht nachträglich verschieben
Nur Inhalte unterhalb des sichtbaren Bereichs verzögert laden. Galeriebilder oben auf der Seite und Kategorie-Thumbnails in der ersten sichtbaren Reihe sollten sofort laden
Im Bereich „In den Warenkorb“ oder Zahlung nichts verzögert laden. Die Gründe folgen weiter unten
Alles verzögert zu laden ist ein typischer Fehler. Es bremst genau das Bild aus, das ein Besucher sehen will. Die Seite fühlt sich langsamer an, während das Mess-Tool einen besseren Wert meldet.
Skripte und Styles laden
Bei der Optimierung von Skripten und Styles wird Tempoarbeit schnell riskant. Die Technik ist sinnvoll, doch ihre Nebenwirkungen werden oft unterschätzt.
Plugin-Assets nur dort laden, wo sie gebraucht werden
Die meisten Plugins laden CSS und JavaScript auf jeder Seite, weil das für Entwickler am einfachsten ist. Slider-Bibliothek, Bewertungs-Widget, Page-Builder-Bundle und Chat-Widget laden dann auch im Checkout, obwohl dort nichts davon gebraucht wird. Selektives Dequeuing entfernt sie nur auf einzelnen Seiten und lässt den Rest der Website in Ruhe. Gute Kandidaten für Warenkorb und Checkout sind:
Frontend-Bundles von Page Buildern, wenn der Checkout eine schlichte Shortcode- oder Blockseite ist
Slider, Galerien und Lightbox-Bibliotheken
Skripte für Bewertungen, Wunschlisten und Produktvergleiche
Pop-ups, Exit-Intent- und Live-Chat-Widgets
Skripte für Social Sharing und verwandte Produkte
Entferne niemals Assets von WooCommerce Core, einem Zahlungsgateway oder einer Versand- oder Steuerintegration. Fühlt sich der Checkout nach dem Dequeuing träge an, lies unseren Leitfaden zu Ursachen und Lösungen für einen langsamen Checkout, bevor du Template-Markup änderst oder weitere Skripte hinzufügst.
Warum Gateway-Skripte auf dem Checkout unangetastet bleiben müssen
SDKs von Zahlungsanbietern laden in fester Reihenfolge und erwarten ihre globalen Variablen, wenn das Formular startet. Minifier schreiben sie um, Kombinierer ändern die Reihenfolge und Defer verschiebt sie hinter abhängigen Code. Der Fehler bleibt oft leise: Kartenfelder erscheinen nicht oder der Absende-Handler wird nie gebunden. Dann tut der Button nichts. Füge die Gateway-Handles zur Ausschlussliste deines Optimierungs-Plugins hinzu und schließe die Checkout-Seite auch auf Seitenebene aus.
Hinweis
Ausschlüsse im Optimierungs-Plugin gelten pro Schicht, nicht global. Ein im Caching-Plugin ausgeschlossener Checkout kann trotzdem von einem separaten Optimierungs-Plugin minifiziert, vom Asset-Tool des Themes kombiniert und von einer CDN-Regel gecacht werden. Prüfe alle Schichten. Lade den Checkout danach in einem privaten Fenster und bestätige, dass die Zahlungsfelder noch erscheinen.
Hosting und Infrastruktur
Die Infrastruktur setzt die Obergrenze für alle Maßnahmen. Einen unterdimensionierten Server kompensierst du nicht mit Optimierungen, besonders nicht auf einer Seite, die nicht gecacht werden kann. Im Checkout laufen mehrere dynamische PHP-Schritte zusammen.
Die vier Hebel, die sich lohnen, nach typischer Wirkung:
1PHP-Version. Eine aktuell unterstützte Version einsetzen, die WooCommerce als kompatibel nennt. Aktualisiere bewusst, statt die Entscheidung dem Hoster zu überlassen. Teste den Checkout nach jedem PHP-Wechsel
2Ressourcenlimits. PHP-Worker entscheiden, ob Anfragen unter Last warten. Das Speicherlimit entscheidet, ob große Admin-Vorgänge scheitern. Beides sind Einstellungen beim Hoster, keine Plugin-Einstellungen
3CDN für statische Assets. Bilder, CSS und JavaScript von Standorten nahe bei den Besuchern ausliefern. Die Caching-Regeln müssen transaktionale Seiten ausschließen
4Serverstandort. Latenz ist Geografie. Ein Server auf einem anderen Kontinent als die meisten Kunden fügt jeder Anfrage zusätzliche Wege hinzu. Das gleicht kein Caching-Plugin aus
Stelle WordPress-Cron außerdem auf einen echten System-Cron um. Standardmäßig laufen geplante Aufgaben bei Seitenaufrufen. Dann bezahlt ein unglücklicher Kunde deine Stapelverarbeitung während des Checkouts.
Was du nicht optimieren solltest
Fünf Änderungen, die wie normale Performance-Arbeit aussehen und in einem Shop nicht sicher sind. Jede hat eine konkrete Folge.
Checkout nicht cachen
Ein gecachter Checkout kann Session, Warenkorbinhalt, Summen und Nonces eines Kunden an den nächsten ausliefern. Die Folge sind zeitweise falsche Warenkörbe, abgelaufene Nonces beim Absenden und im schlimmsten Fall eine Bestellbestätigungsseite mit einer fremden Bestellung. Dieser Fehler erzeugt Support-Tickets, die sich kaum reproduzieren lassen. Es hängt davon ab, wer zuerst gecacht wurde und wann.
Skripte von Zahlungsanbietern nicht minifizieren oder verzögern
SDKs von Zahlungsanbietern setzen eine feste Ladereihenfolge voraus und erwarten ihre Variablen beim Start des Formulars. Dann erscheint das Kartenfeld im iframe nicht oder der Button „Bestellung aufgeben“ tut beim Klick still nichts. Kunden lesen das als fehlgeschlagene Zahlung und gehen. Oft betrifft es nur einen Anbieter, während andere weiter funktionieren. Deshalb übersteht der Fehler einen schnellen manuellen Check.
Bereich „In den Warenkorb“ nicht verzögert laden
Verzögertes Laden unterhalb des sichtbaren Bereichs ist sinnvoll. Hier ist es falsch. Die Bereiche „In den Warenkorb“ und Zahlung enthalten versteckte Felder, iframes und Event-Bindings, die beim Absenden vorhanden sein müssen. Sonst tut der erste Klick nichts, die Variantenauswahl aktiviert den Button nicht oder der Zahlungsbereich erscheint erst, nachdem der Kunde weitergescrollt hat.
CSS auf dem Checkout nicht blind kombinieren
Kombinierte Stylesheets brechen die Kaskade, wenn Gateway- oder Plugin-CSS von der Ladereihenfolge abhängt. Sie entfernen auch iframe-spezifische Styles mancher Gateways. Das Kartenfeld ist dann falsch ausgerichtet, nullhoch oder unsichtbar. Die Seite sieht fast richtig aus. Deshalb gelangt dieser Fehler häufiger in die Produktion und wird erst von Kunden entdeckt.
jQuery nicht entfernen, wenn ein Gateway davon abhängt
jQuery zu entfernen ist eine legitime Frontend-Optimierung auf einer schlichten Content-Seite. WooCommerce-Core-Skripte und viele Gateways hängen noch daran, ebenso jQuery BlockUI für das Checkout-Overlay. Dann aktualisiert der Checkout Summen nicht mehr, das Overlay verschwindet nie und die Bestellung scheitert mit einem JavaScript-Fehler, den kaum ein Besucher meldet.
WooCommerce Optimierungen, die Probleme im Checkout verursachen
Fünf Optimierungen, die Probleme im WooCommerce-Checkout verursachen: Checkout cachen, Gateway-Skripte minifizieren oder verzögern, „In den Warenkorb“ verzögert laden, CSS auf dem Checkout kombinieren und jQuery entfernen, jeweils mit einem typischen Symptom
Nach jeder Optimierung verifizieren
Performance-Plugins können Checkout-Ausfälle auslösen und sind deshalb schwer zu prüfen. Der Fehler betrifft oft nur einen Teil des Prozesses: eines von drei Gateways, einen Produkttyp, die Steuerregeln eines Landes oder nur die mobile Ansicht. Du leerst den Cache, öffnest den Checkout, siehst ein Formular und hältst alles für erledigt. Dabei hast du womöglich nicht mit dem betroffenen Gateway getestet.
Der Check muss also eine echte Bestellung sein, kein Seitenaufruf. Gib nach jeder Optimierungsrunde mit jedem angebotenen Gateway eine Testbestellung auf. Nimm mindestens ein variables und ein einfaches Produkt und prüfe, ob die Bestellbestätigungsseite erscheint und die Bestellung die richtige Summe zeigt. Unser Walkthrough Test nach Optimierung zeigt die vollständige manuelle Abfolge. Wenn etwas nicht mehr funktioniert, ist das Änderungsprotokoll deiner Optimierungsrunde der erste Anhaltspunkt. Das ist dieselbe Logik wie bei einem Checkout kaputt nach Update ist.
Eine Optimierung ist nicht fertig, wenn der Score steigt. Sie ist fertig, wenn eine echte Bestellung mit jedem angebotenen Gateway durchgelaufen ist.
Das eigentliche Problem ist die Wiederholung. Manuell wird eine vollständige Testbestellung über alle angebotenen Zahlungs-Gateways meist nur einmal direkt nach einer Änderung durchgeführt. So bleibt eine Regression nach dem nächsten Plugin-Update leicht unbemerkt. ShopMonitor führt planmäßig einen vollständigen Checkout im echten Browser aus und warnt bei einem fehlgeschlagenen Lauf. Künftig kann ShopMonitor zusätzlich die Zustellung transaktionaler E-Mails testen. Aus der einmaligen Prüfung wird so eine dauerhafte Kontrolle. ShopMonitor ist ein Checkout-Monitor, kein Performance-Optimizer: Es macht deinen Shop nicht schneller, zeigt dir aber, wenn eine Optimierung Bestellungen verhindert.
Keinen Umsatz mehr durch kaputte Checkouts verlieren
ShopMonitor testet Checkout und Formulare automatisiert und warnt, sobald etwas bricht. Kein Code. Keine Plugins.
Vier Hebel zahlen sich meist in dieser Reihenfolge aus. Erst Hosting und PHP: eine aktuelle unterstützte PHP-Version, genug PHP-Worker und ein persistenter Object-Cache. Zweitens Caching: Full-Page-Cache für Produkt- und Inhaltsseiten. Warenkorb, Checkout, Mein Konto und Bestellbestätigung bleiben auf jeder Ebene ausgeschlossen. Drittens Bilder: komprimieren, moderne Formate ausliefern, an den Container anpassen und nur unterhalb des sichtbaren Bereichs verzögert laden. Viertens Assets: Plugin-CSS und JavaScript auf Seiten entfernen, die sie nicht nutzen. Die Assets von Zahlungsanbietern bleiben unangetastet. Miss vor und nach jedem Schritt, damit du weißt, was die Zahl wirklich bewegt hat.
Nicht mit Full-Page-Cache. Beide Seiten zeigen Daten eines Besuchers in genau diesem Moment: Warenkorbinhalt, Summen, Versandoptionen, Steuern und Sicherheits-Nonces. Eine gecachte Kopie liefert diese Daten an den nächsten Besucher. Das führt zu falschen Warenkörben, Nonce-Fehlern und fehlgeschlagenen Bestellungen. WooCommerce setzt deshalb auf diesen Seiten die Konstante DONOTCACHEPAGE. Object-Caching und das Warenkorbfragment sind dagegen in Ordnung. Sie beschleunigen die Anfrage, ohne die gerenderte Seite zu speichern.
Ein möglicher Grund sind fehlende Ausschlüsse. Entweder hat das Plugin Warenkorb und Checkout gecacht, weil seine WooCommerce-Erkennung in deinem Setup nicht griff, oder die Asset-Optimierung hat Skripte von Zahlungsanbietern minifiziert, kombiniert oder verzögert. Das sind getrennte Einstellungen. Page-Caching auszuschalten, schaltet die Asset-Optimierung nicht aus. Schließe die vier transaktionalen Seiten vom Page-Caching aus, füge Gateway-Script-Handles zu den Ausschlusslisten für Minify und Combine hinzu und gib mit jedem Gateway eine Testbestellung auf.
Ja, messbar und aus strukturellen Gründen. WooCommerce fügt Datenbanktabellen sowie viele Bestell- und Produkt-Metadaten hinzu, hält eine Session für jeden Besucher mit Warenkorb und markiert vier Seiten als nicht cachebar. Dort läuft immer PHP. Es registriert zudem eigene Skripte und Styles im Frontend. Die Gegenmaßnahmen sind die oben genannten: ein persistenter Object-Cache, damit nicht cachebare Seiten Abfragen nicht wiederholen, regelmäßige Datenbankwartung, HPOS für die Bestellspeicherung und WooCommerce-Assets nur auf Shop-Seiten laden.
Nutze eine Version, die vom PHP-Projekt aktuell unterstützt wird und in den WooCommerce-Systemanforderungen als kompatibel steht. Prüfe diese Seite, statt einer Versionsnummer in einem Artikel zu vertrauen. Die Antwort ändert sich. Faustregel: Keine PHP-Version ohne Sicherheitsupdates einsetzen und nicht auf eine ganz neue Hauptversion wechseln, bevor Gateway-, Versand- und Steuer-Plugins sie als kompatibel nennen. Gib nach jedem Wechsel mit jedem Gateway eine Testbestellung auf.
Über den Autor
Verfasst vom Team von Winning Solutions, der Agentur hinter ShopMonitor. Wir helfen WooCommerce-Shops, Produkt- und Archivseiten zu beschleunigen, ohne Warenkorb und Checkout zu beeinträchtigen. Geplante Browser-Tests fangen Regressionen nach jeder Optimierungsrunde auf.
WooCommerce schneller machen, ohne den Checkout zu gefährden | ShopMonitor
