Kurz und einfach erklärt
Zum Start einer Aktion ändern sich die Preise. Dabei wird ein Speicher für fertige Seiten geleert. Diesen Speicher nennt man Cache.
Ist der Cache leer, baut der Server jede Seite neu. Kommen dann viele Leute auf einmal, wird der Shop langsam.
Die Lösung: Ein Programm ruft die wichtigen Seiten vorher selbst auf. Dann liegen sie fertig bereit. Das heißt Vorwärmen.
Die Reihenfolge zählt. Erst die Preise ändern. Dann vorwärmen. Dann Werbung und Newsletter starten.
Vorher prüft man, ob die Seiten aus dem Cache kommen. Wir helfen Ihnen gern dabei.
Um 00:00 Uhr beginnt die Black Week, der Newsletter ist eingeplant, die Anzeigen laufen an, und in genau dieser Minute sind die Preise im Shop gerade umgestellt worden. Für den Cache ist das der ungünstigste Moment: Mit dem Preiswechsel fallen Seiten aus dem Zwischenspeicher, und die ersten Besucher der Aktion treffen auf einen Server, der jede Seite neu bauen muss. Der Black Friday fällt 2026 auf den 27. November, den Tag nach Thanksgiving (US Office of Personnel Management). Bis dahin bleibt Zeit, die Aktionsnacht einmal zu proben. Dieser Beitrag zeigt am Beispiel von Shopware, was beim Preiswechsel aus dem Cache fällt, wie eine Vorwärmliste aus Felddaten und Sitemap entsteht, in welcher Reihenfolge Preiswechsel, Vorwärmen und Freigabe laufen und wie Sie die Trefferquote messen, bevor der Newsletter rausgeht.
Das Wichtigste in Kürze
- Shopware hat die eingebauten HTTP-Cache-Warmer mit Version 6.5.8.0 abgekündigt (Shopware-Upgrade-Hinweise 6.5) und empfiehlt einen echten Crawler, der die Seiten über denselben Weg abruft wie die Kundschaft.
- Seit Shopware 6.7 verwirft der Shop geänderte Einträge gesammelt im Takt von 5 Minuten (Shopware-Upgrade-Hinweise 6.7). Ein Preisimport kurz vor Mitternacht kann seine Invalidierung so mitten in den Aktionsstart schieben.
- Suchergebnisse verwirft Shopware bei einer Preisänderung nicht gezielt, sie laufen über ihre Lebensdauer im Cache. Kategorieseiten folgen dem Produkt über ein eigenes Listing-Tag, aber verzögert. Zum Preiswechsel gehört deshalb das Leeren des HTTP-Caches mit erneutem Abruf.
- Die Vorwärmliste hat drei Stufen: Aktionsseiten samt Linkzielen aus Newsletter und Anzeigen, dann Kategorien, dann Topseller nach Aufrufen der letzten Aktion. Die Sitemap liefert die Adressen, die Felddaten die Reihenfolge.
- Newsletter, Push und Anzeigen erst freigeben, wenn die erste Stufe aus dem Cache kommt: Ein Age-Wert über null zeigt den Treffer, eine Antwortzeit bis 0,8 Sekunden (web.dev) gilt als gut.
Warum die erste Minute den Cache leer vorfindet
Ein Aktionsstart bündelt drei Ereignisse auf wenige Sekunden. Die Preise wechseln, Banner und Aktionsseiten gehen online, und Newsletter, Push-Nachrichten und Anzeigen schicken Besucher gleichzeitig auf genau diese Seiten. Rund die Hälfte der Internetnutzerinnen und -nutzer ab 16 Jahren in Deutschland wollte die Black-Friday-Angebote 2025 nutzen, 52 Prozent (Bitkom 2025), die meisten davon online. Für Black Friday und Cyber Monday zusammen rechnete der Handelsverband mit einem Umsatz von 5,8 Milliarden Euro (HDE 2025). Wer eine feste Startzeit ankündigt, bekommt einen Teil dieser Nachfrage genau zu dieser Uhrzeit.
Der Cache arbeitet in dieser Minute gegen Sie. Ein HTTP-Cache beantwortet eine Anfrage nur dann selbst, wenn er für genau diese Adresse und diesen Kontext schon eine gültige Antwort hat. Nach einem Preiswechsel ist das für viele Seiten nicht mehr der Fall: Shopware verschlagwortet jede gespeicherte Antwort mit Cache-Tags und verwirft beim Speichern eines Produkts die Einträge, die dieses Produkt tragen (Shopware-Dokumentation). Jede verworfene Seite holt der nächste Besucher wieder bei PHP und Datenbank ab. Kommen viele Besucher gleichzeitig auf viele verschiedene, gerade verworfene Seiten, landen alle diese Anfragen beim selben PHP-Prozesspool. Wie viele davon parallel laufen, begrenzt die Einstellung pm.max_children (PHP-Handbuch); alle weiteren warten. Nicht ohne Grund nennt die Shopware-Dokumentation den HTTP-Cache ein Muss für jedes Produktivsystem.
Spürbar wird das an der Antwortzeit des Servers. Als gut gilt eine Time to First Byte von 0,8 Sekunden oder weniger, als schlecht alles über 1,8 Sekunden (web.dev). Aus dem Cache liegt eine Shopware-Seite in der Regel deutlich darunter, ohne Cache hängt sie an Datenbank, Regelauswertung und Template-Rendering. Wie viel Last Ihr System insgesamt verträgt, klärt ein Lasttest vor der Hochsaison. Hier geht es darum, die Last zum Aktionsstart gar nicht erst ungebremst auf PHP fallen zu lassen.
Abgrenzung
Was beim Preiswechsel aus dem Cache fällt
Welche Seiten nach dem Preiswechsel kalt sind, hängt davon ab, wie der Wechsel technisch läuft. Shopware behandelt dabei zwei Arten von Seiten verschieden. Produktseiten tragen die Tags der Produkte, die sie zeigen, und werden beim Speichern eines dieser Produkte verworfen. Listen dagegen, also Kategorieseiten, Suchergebnisse und Produktlisten, werden laut Dokumentation nicht mit allen enthaltenen Produkten verschlagwortet. Sie verlassen sich auf ihre Lebensdauer im Cache, und die Dokumentation nimmt ausdrücklich in Kauf, dass sie für eine gewisse Zeit veraltet sind (Shopware-Dokumentation).
These routes instead rely on their TTL as defined by the active HTTP Caching Policy.
Im Quellcode ist das für Kategorieseiten feiner geregelt: Die Produktliste einer Kategorie trägt ein eigenes Listing-Tag, und nach dem Speichern eines Produkts verwirft Shopware dieses Tag für alle Kategorien, denen das Produkt zugeordnet ist, mit derselben Verzögerung wie die Produktseite (Shopware-Quellcode). Suchergebnisse bekommen kein solches Tag. Für den Aktionsstart heißt das: Nach einem Preisimport können Suchergebnisse den alten Preis zeigen, bis ihre Lebensdauer im Cache abläuft. Warenkorb und Kasse kommen nicht aus dem Cache und rechnen bereits mit dem neuen Preis. Für die Kundschaft sieht das wie ein Fehler aus, auch wenn es keiner ist. Wie Cache-Tags und Reverse-Proxy in Shopware grundsätzlich zusammenspielen, fasst der Beitrag Shopware Performance: Ladezeiten im Shop senken zusammen.
Verzögerte Invalidierung seit Shopware 6.7
Seit Shopware 6.7.0.0 verwirft der Shop Einträge nicht mehr sofort. Er sammelt die betroffenen Tags und arbeitet sie in einem festen Takt ab, das Standardintervall liegt bei 5 Minuten (Shopware-Upgrade-Hinweise 6.7). Im Alltag erhöht das die Trefferquote, weil doppelte Invalidierungen entfallen. In der Aktionsnacht verschiebt es das Problem: Ein Preisimport um 23:58 Uhr wird womöglich erst nach Mitternacht im Cache wirksam, also genau dann, wenn die Besucher kommen. Für solche Fälle nennt Shopware zwei Werkzeuge. Der Kopf sw-force-cache-invalidate: 1 an einer Anfrage an die Admin-API invalidiert sofort, und der Befehl cache:clear:delayed führt alle gesammelten Invalidierungen auf einmal aus. Mit cache:watch:delayed sehen Sie vorab, welche Tags noch in der Warteschlange liegen.
Zeitgesteuerte Preise über Regeln
Eine Möglichkeit, den Import in der Nacht zu vermeiden, sind erweiterte Preise, die an eine Regel mit Datumsbereich gebunden sind; der Rule Builder nimmt dafür Datum und Uhrzeit an (Shopware-Handbuch). Das hat für den Cache eine Kehrseite. Um Mitternacht wird kein Datensatz gespeichert, also löst auch nichts eine Invalidierung aus. Anonyme Besucher mit leerem Warenkorb tragen zudem keinen eigenen Cache-Hash, weil Shopware ihn erst setzt, wenn der Zustand vom Standard abweicht (Shopware-Dokumentation). Eine Seite, die um 23:55 Uhr mit dem alten Preis in den Cache gelangt ist, kann deshalb nach Mitternacht weiter ausgeliefert werden, bis ihre Lebensdauer abläuft oder jemand den Cache leert. Ob sich Ihr Shop so verhält, zeigt ein Probelauf im Staging mit einer Regel, die wenige Minuten in der Zukunft beginnt.
Was ein Reverse-Proxy danach noch ausliefert
Steht ein Reverse-Proxy vor dem Shop, kommt eine zweite Frage dazu: Was liefert er aus, nachdem eine Seite abgelaufen oder verworfen ist? Die Beispielkonfiguration, die Shopware für Varnish bereitstellt, liefert abgelaufene Einträge noch drei Tage nach ihrem Ablauf aus, während im Hintergrund neu geladen wird (Shopware-Beispielkonfiguration). Für den Normalbetrieb ist das gewollt. Für den Preiswechsel bedeutet es: Eine Seite, deren Lebensdauer um Mitternacht endet, kommt beim ersten Aufruf danach noch einmal mit dem alten Preis. Ähnlich wirkt das sanfte Verwerfen, das Shopware als Option beschreibt: Es hält die alte Seite vor und erneuert sie im Hintergrund (Shopware-Dokumentation).
Dasselbe Prinzip steckt in der Anweisung stale-while-revalidate im Kopf Cache-Control. Wer sie zusammen mit max-age auf je 600 Sekunden setzt, muss laut RFC damit leben, dass eine Antwort bis zu 20 Minuten aus dem Cache kommt (RFC 5861). Außerhalb der Aktionsnacht ist das ein guter Tausch, zum Preiswechsel nicht. Für den Wechsel gehört deshalb ein hartes Verwerfen in den Ablauf, gefolgt vom Vorwärmen.
| Weg zum Aktionspreis | Was der Cache davon merkt | Was in der Nacht zu tun ist |
|---|---|---|
| Preisimport über die Admin-API | Produkt- und Kategorieseiten werden über ihre Tags verworfen, gesammelt im Takt der verzögerten Invalidierung | Import mit sw-force-cache-invalidate senden oder danach cache:clear:delayed ausführen |
| Erweiterte Preise mit Datumsbereich | Um Mitternacht wird nichts gespeichert, kein Ereignis verwirft Einträge | Zum Wechsel den HTTP-Cache leeren und danach vorwärmen |
| Suchergebnisse | Werden nicht über Produkt-Tags verworfen, sondern laufen über ihre Lebensdauer | Gezielt verwerfen oder den HTTP-Cache leeren |
| Neue Aktionsleiste im Kopfbereich | Betrifft das eigene Fragment des Kopfbereichs, nicht jede Seite einzeln | Die erste Stufe der Vorwärmliste baut es mit auf |
| Abgelaufene Einträge im Reverse-Proxy | Werden je nach Konfiguration noch einmal mit altem Stand ausgeliefert | Zum Wechsel hart verwerfen statt sanft |
Eine Erleichterung bringt der Cache-Umbau von Shopware 6.7.0.0: Kopf- und Fußbereich lädt die Storefront seither per ESI und speichert sie getrennt vom Rest der Seite (Shopware-Upgrade-Hinweise 6.7). Eine neue Aktionsleiste im Kopf betrifft damit ein Fragment, nicht jede Seite einzeln. Wie diese Leiste ohne Layoutsprung eingebaut wird, steht im Beitrag Aktionsbanner zur Black Week ohne Layoutsprung.
Der eingebaute Warmer ist abgekündigt
Früher brachte Shopware einen eigenen Befehl zum Vorwärmen des HTTP-Caches mit. Mit Version 6.5.8.0 hat der Hersteller alle eingebauten HTTP-Cache-Warmer abgekündigt (Shopware-Upgrade-Hinweise 6.5). Die Begründung im selben Abschnitt: Sie passen nicht zum neuen HTTP-Kernel, nicht zum Cache-Umbau und nicht zu Systemen mit Reverse-Proxy oder Lastverteiler davor. Die Empfehlung steht gleich darunter.
You should use instead a real website crawler to warmup your desired sites, which is much more suitable and realistic for your system.
Realistisch heißt: Der Crawler ruft die Seiten über genau den Weg ab, den auch die Kundschaft nimmt. Er spricht den Shop über die öffentliche Domain und HTTPS an, durch Lastverteiler und Reverse-Proxy hindurch, und nicht direkt einen einzelnen Anwendungsserver. Nur dann landet die Antwort in dem Cache, aus dem später die Besucher bedient werden. Er schickt normale GET-Anfragen ohne Cookies, damit die Antworten in der Standardvariante landen, die sich alle anonymen Besucher mit leerem Warenkorb teilen.
Für angemeldete Kundinnen und Kunden, andere Währungen oder Nettopreise legt Shopware eigene Varianten an, unterschieden über den Cache-Hash. Diese Varianten lassen sich nicht mit einem ausgedachten Hash vorwärmen. Seit Shopware 6.7.6.0 mit eingeschaltetem Cache-Umbau und regulär ab Version 6.8 vergleicht der Shop den Hash des Besuchers mit dem selbst berechneten und speichert die Antwort bei Abweichung nicht im Cache (Shopware-Dokumentation). Wer B2B-Preise vorwärmen will, braucht dafür echte Sitzungen mit eigenen Testkonten je Kundengruppe, keine Konten aus dem Echtbetrieb.
Die Vorwärmliste: Aktionsseiten, Kategorien, Topseller
Ein Crawler, der den ganzen Shop abruft, braucht bei großen Sortimenten länger, als die Nacht Zeit lässt, und er belastet den Server ausgerechnet vor dem Start. Sinnvoller ist eine Liste, die nach erwarteter Nachfrage sortiert ist. Drei Quellen tragen sie:
- Sitemap: Sie enthält die Adressen aller indexierbaren Seiten je Verkaufskanal. Eine Sitemap-Datei fasst höchstens 50.000 Adressen, darüber verteilt sich die Liste auf mehrere Dateien unter einem Index (sitemaps.org). Der Crawler muss also dem Index folgen.
- Felddaten: Zugriffsprotokolle des Servers und die Auswertung der letzten Aktion zeigen, welche Seiten in den ersten Stunden tatsächlich aufgerufen wurden. Wie Felddaten belastbar erhoben werden, beschreibt der Beitrag RUM gegen CrUX.
- Aktionsplan: Das Marketing kennt die Linkziele von Newsletter, Push und Anzeigen schon Tage vorher. Diese Adressen gehören vollständig in die Liste, auch wenn sie in keiner Sitemap stehen.
Die Sitemap selbst sollte zu diesem Zeitpunkt längst erzeugt sein. Die Dokumentation beschreibt ihre Erzeugung bei großen Sortimenten als aufwendig und zeigt, wie sie als eigener Cronjob zu einer ruhigen Zeit läuft (Shopware-Dokumentation). In der Aktionsnacht hat sie in der Warteschlange nichts verloren.
Drei Stufen nach Dringlichkeit
- Aktionsseiten: Landingpage der Aktion, Startseite, Aktionskategorie und jede Adresse, auf die Newsletter, Push oder Anzeigen zeigen. Diese Stufe muss vor der Freigabe vollständig aus dem Cache kommen.
- Kategorien: die Hauptkategorien mit ihrer ersten Seite in der Standardsortierung, dazu die Filter- und Sortierkombinationen, die in den Felddaten der letzten Aktion häufig vorkommen.
- Topseller: Produktseiten in der Reihenfolge der Aufrufe und Bestellungen der vergangenen Aktion, ergänzt um die Artikel, die das Marketing in Newsletter und Anzeigen zeigt.
Kampagnenparameter verdienen einen eigenen Blick. Die Beispielkonfiguration von Shopware für Varnish entfernt gängige Parameter wie utm_source oder gclid, bevor sie im Cache nachschlägt, und sortiert die übrigen (Shopware-Beispielkonfiguration). Läuft Ihr Shop mit dem eingebauten Cache oder einer eigenen Proxy-Konfiguration, prüfen Sie vorab, ob ein Newsletter-Link mit Parametern denselben Eintrag trifft wie die vorgewärmte Adresse. Wie sich das messen lässt, zeigt der Beitrag zur Cache-Fragmentierung durch Cookies und Vary.
Die Liste klein halten
Zeitplan für die Nacht: vorziehen, vorwärmen, freigeben
Der wichtigste Hebel ist kein Werkzeug, sondern eine Trennung: Der Moment, in dem die Preise wechseln, und der Moment, in dem Besucher kommen, müssen nicht derselbe sein. Den Besucherstrom lösen Sie selbst aus, mit Newsletter, Push-Nachricht und Anzeigenstart. Dazwischen liegt das Zeitfenster für das Vorwärmen.
Variante A: den Preiswechsel vorziehen
Am robustesten ist es, die Preise vor der angekündigten Startzeit umzustellen, etwa um 23:30 Uhr, wenn wenige Besucher im Shop sind. Der kalte Cache trifft dann auf geringen Verkehr, der Crawler hat eine halbe Stunde Zeit, und um Mitternacht gehen Newsletter und Anzeigen auf einen gefüllten Cache. Ob ein früherer Start zur Aktionskommunikation passt, entscheidet das Marketing. Für die Kundschaft ist ein Angebot, das ein paar Minuten früher gilt, in der Regel kein Nachteil.
Variante B: Wechsel genau um Mitternacht
Muss der Preis exakt um 00:00 Uhr wechseln, etwa weil Marktplätze oder Preisvergleiche den Zeitpunkt erwarten, wird das Fenster kürzer, aber nicht null. Alles Schwere läuft vorher: Aktionspreise als vorbereitete Daten, Indexierung, Sitemap, Trockenlauf des Crawlers. Um Mitternacht folgt nur noch der Wechsel selbst, unmittelbar danach das Verwerfen und der Crawler. Newsletter und Anzeigen gehen erst raus, wenn die erste Stufe aus dem Cache kommt, in der Regel einige Minuten nach Mitternacht.
- Ab 22:00 Uhr Ruhe im System: keine Deployments, keine Massenimporte, der Abgleich mit der Warenwirtschaft pausiert, Indexierung und Sitemap sind abgeschlossen.
cache:watch:delayedzeigt eine leere Warteschlange. - 23:15 Uhr Liste und Crawler prüfen: Vorwärmliste final, Trockenlauf gegen einige Adressen, Statuscodes und Zeiten im Protokoll.
- 23:30 Uhr Preiswechsel (Variante A): Import mit sofortiger Invalidierung oder Start der Regel, danach
cache:clear:http, damit auch Kategorieseiten und Suchergebnisse neu entstehen. - Ab 23:31 Uhr Vorwärmen: Stufe 1, dann Stufe 2, dann Stufe 3, mit begrenzter Parallelität.
- 23:50 Uhr Messen: Anteil der Treffer in Stufe 1, Antwortzeiten, Fehlerquote. Erst wenn die Werte stehen, geht es weiter.
- 00:00 Uhr Freigabe: Newsletter, Push-Nachricht und Anzeigen starten. Ab jetzt beobachten, nicht mehr ändern.
Für das Leeren gibt es seit Shopware 6.6.10 einen eigenen Befehl: cache:clear:http leert den Reverse-Proxy oder, ohne Proxy, den HTTP-Cache des Shops (Shopware-Dokumentation). Der allgemeine cache:clear ist dafür das falsche Werkzeug, er leert und baut den Anwendungs-Cache neu auf und hat in älteren Versionen den HTTP-Cache gleich mitgeleert. Der Crawler selbst braucht keine Spezialsoftware. Ein kurzes Skript mit curl reicht, solange es die Parallelität begrenzt und protokolliert, was zurückkommt:
#!/usr/bin/env bash
# Vorwärmliste abrufen: eine Adresse je Zeile, Stufe 1 zuerst.
# Aufruf: ./warm-cache.sh stage-1.txt
LIST="$1"
LOG="warm-$(date +%H%M%S).log"
PARALLEL=4 # klein halten: PHP braucht Luft für echte Besucher
xargs -P "$PARALLEL" -I{} curl -s -o /dev/null \
-A 'cache-warmer/1.0' \
-w '%{http_code};%header{age};%{time_starttransfer};%{url_effective}\n' \
'{}' < "$LIST" > "$LOG"
# Auswertung: Status, Treffer (Age über 0) und langsamste Antwort.
awk -F';' '$1 != 200 {err++} $2 > 0 {hit++} $3 > max {max = $3}
END {printf "%d Adressen, %d Treffer, %d ohne Status 200, langsamste %.2f s\n", NR, hit, err, max}' "$LOG"
Die Parallelität im Skript ist bewusst niedrig. Der Crawler soll den Cache füllen, nicht selbst zum Lastspitzentest werden. Ein guter Anhaltspunkt ist der Lasttest: Wenn bekannt ist, wie viele gleichzeitige Seitenaufrufe der Server ohne Cache trägt, bleibt der Crawler deutlich darunter. Das Feld %header{age} verstehen neuere curl-Versionen; ältere geben die Kopfzeilen mit -D in eine Datei aus.
Was in der Aktionsnacht nicht passieren sollte
Die Trefferquote messen statt hoffen
Ob der Cache gefüllt ist, zeigt jede einzelne Antwort. Der Kopf Age gibt an, wie viel Zeit seit der Erzeugung oder der letzten Prüfung der Antwort am Ursprungsserver vergangen ist (RFC 9111). Ein Wert über null heißt: Diese Antwort kam aus einem Cache. Sehen Sie ausschließlich 0 als Age, arbeitet der Cache laut Shopware nicht (Shopware-Dokumentation); häufigster Grund ist eine Antwort ohne Cache-Control: public. Für die Aktionsnacht reichen drei Messpunkte:
- Trefferanteil je Stufe: Ein zweiter Durchlauf des Crawlers über Stufe 1 zählt, wie viele Antworten ein Age über null tragen. Vor der Freigabe sollten es alle Adressen der Stufe sein.
- Antwortzeit: die Zeit bis zum ersten Byte aus demselben Protokoll, verglichen mit einem Durchlauf am Vortag. Aus dem Cache liegt sie deutlich unter der Grenze von 0,8 Sekunden, die web.dev als gut einstuft.
- Last und Fehler: belegte PHP-Prozesse, Antworten mit Status 5xx und die Länge der Warteschlange in den Minuten nach der Freigabe.
Wer die Messung dauerhaft im Betrieb verankern will, lässt den Server Treffer und Fehltreffer im Kopf Server-Timing mitschicken; wie das geht, zeigt der Beitrag zu Server-Timing. Die Statistik des Reverse-Proxys zählt Treffer und Fehltreffer zusätzlich über alle Besucher hinweg und zeigt nach der Freigabe, ob die Quote hält. Fällt sie in den ersten Minuten deutlich, ist der häufigste Grund eine Invalidierung, die erst jetzt aus der Warteschlange kommt.
Die Regel für die Aktionsnacht
Probelauf: die Nacht vor der Black Week üben
Ein Ablauf, der nur einmal im Jahr läuft, scheitert gern an Kleinigkeiten: ein fehlendes Recht für einen Befehl, ein Crawler, der am Lastverteiler vorbeigeht, ein Newsletter-Werkzeug mit eigener Zeitzone. Deshalb lohnt ein Probelauf an einem gewöhnlichen Abend in den Wochen davor, mit einer kleinen echten Preisänderung. Dabei messen Sie zwei Dinge: wie lange der Crawler für die erste Stufe braucht und wie lange die Trefferquote nach dem Leeren ohne Crawler unten bleibt. Die Differenz ist Ihr Gewinn, und sie zeigt, ob die Variante mit vorgezogenem Preiswechsel nötig ist.
Hilfreich ist ein festes Protokoll je Schritt: Uhrzeit, Befehl, Ergebnis, Messwert. Es ersetzt in der Aktionsnacht das Gedächtnis und macht den Ablauf im nächsten Jahr wiederholbar. Wo der Shop schon bei normalem Verkehr an seine Grenze kommt, gehört vor den Probelauf ein Blick auf die Server-Optimierung und die Antwortzeit des Servers. Ein warmer Cache verdeckt Engpässe nur für die Seiten, die er kennt; die erste Suche, der Warenkorb und die Kasse laufen weiter über PHP.
Wir begleiten diesen Ablauf für Shopware-Shops: Vorwärmliste aus Ihren Felddaten, Crawler über den echten Weg, Invalidierung passend zu Ihrem Preisimport und ein Probelauf mit Messprotokoll. Mehr zu unserem Vorgehen steht auf den Seiten zu Caching-Strategien und Shopware-Performance; für Online-Shops mit saisonalen Spitzen bündeln wir die Themen unter PageSpeed für E-Commerce. Wie sich der Aufwand für solche Arbeiten einschätzen lässt, ordnet der Beitrag Was kostet PageSpeed-Optimierung? ein.
Quellen und Dokumentation
cache:clear:http zum Preiswechsel, gefolgt vom Vorwärmen.cache:clear:delayed auszuführen.cache:clear:delayed sofort ausführen und danach die Produktseite und die Kategorien, in denen der Artikel steht, gezielt neu abrufen. Ein vollständiges Leeren des HTTP-Caches mitten in der Aktion bringt alle Seiten gleichzeitig zurück auf PHP und ist nur als letzter Schritt sinnvoll. Wie sich ein Shop auf solche Eingriffe vorbereiten lässt, klären wir in einer technischen Analyse.Verwandte Artikel
Shopware Performance: Ladezeiten im Shop senken
Shopware CE schneller machen mit Bordmitteln: integrierter HTTP-Cache und Reverse-Proxy, Cache-Warmup, OpenSearch und der Performance-Gewinn eines 6.x-Updates.
Langsames Shop-Backend: Admin-Tempo für das Team steigern
Wird die Shopware-Verwaltung im Weihnachtsgeschäft zäh, helfen vier Hebel: CLI-Worker statt Browser-Tab, Admin-Suche, schlanke Listen, Indexläufe nachts.
Aktionsbanner zur Black Week ohne Layoutsprung einbauen
Hinweisleiste, Countdown, Pop-up und Badges zur Black Week ohne Sprung einbauen: Platz reservieren, serverseitig ausliefern, CLS bei höchstens 0,1 halten.