Cache-Warmup und wichtigste Seiten nach dem Release automatisiert aufrufen

1. Warum Cache-Warmup nach dem Deployment nötig ist

Ein Magento Full-Page-Cache (FPC) wird durch cache:clean full_page oder cache:flush vollständig geleert. Nach dem Deployment ist der Cache leer, und jede Seite muss beim ersten Aufruf von PHP und Datenbank vollständig gerendert werden. Bei einem gut optimierten Magento-Shop kann ein gecachter Seitenaufruf 50–200 ms dauern, ein ungecachter 2–10 Sekunden. Der Unterschied ist für Besucher direkt spürbar und hat messbare Auswirkungen auf Conversion-Rate und Bounce-Rate.

Das Problem verschärft sich bei Deployments zu Verkehrszeiten oder nach umfangreichen Cache-Leeren-Aktionen: Wenn viele Nutzer gleichzeitig auf leere Cache-Einträge treffen, entsteht ein Cache-Stampede – alle PHP-Prozesse generieren dieselben Seiten parallel, was zu erheblicher Last und verlängerten Response-Zeiten für alle führt. Ein Warmup-Job, der die wichtigsten Seiten vor dem ersten echten Besucher aufruft, verhindert dieses Szenario vollständig.

2. Welche Seiten priorisiert aufgewärmt werden sollten

Nicht alle Seiten sind gleich wichtig. Die Priorisierung sollte nach Traffic-Volumen, Conversion-Relevanz und Cache-Effizienz erfolgen. An erster Stelle stehen die Startseite und die wichtigsten Kategorie-Seiten – diese erhalten den höchsten Traffic und haben den größten Effekt auf die wahrgenommene Shop-Performance. An zweiter Stelle kommen die Top-Produkt-Seiten nach Verkaufsvolumen oder Seitenaufrufen aus dem Analytics-System. Drittens folgen Standard-Seiten wie die Suchergebnisseite, Kontaktseite, Impressum und Datenschutzerklärung.

Was nicht prioritär ist: Checkout-Seiten (sind personalisierten Content und werden fast nie gecacht), Kunden-Account-Seiten (ebenfalls nicht cacheable), Seiten mit sehr wenig Traffic. Der Warmup konzentriert sich auf öffentlich zugängliche, cacheable Seiten – genau die, die Magento standardmäßig in den FPC aufnimmt. Eine erste Strategie: Die Top 20 Seiten nach Google Analytics oder dem Magento-eigenen Besucherprotokoll als Warmup-URL-Liste verwenden.

3. URL-Liste aufbauen: statisch vs. dynamisch

Es gibt zwei Ansätze für die Warmup-URL-Liste: eine statisch gepflegte Datei und eine dynamisch aus Magento generierte Liste. Die statische Datei ist einfach – eine Textdatei im Repository mit einer URL pro Zeile, die manuell gepflegt wird. Das ist ausreichend für kleine Shops mit stabiler Seitenstruktur, hat aber den Nachteil, dass neue Produkte und Kategorien nicht automatisch hinzukommen.

Die dynamische Variante liest Kategorien und Top-Produkte direkt aus Magento: bin/magento sitemap:generate erzeugt eine XML-Sitemap, die alle öffentlichen Seiten enthält. Diese Sitemap kann geparst werden, um die wichtigsten URLs zu extrahieren. Eine pragmatische Kombination: Die statische Liste für kritische Seiten (Startseite, Top-Kategorien), ergänzt durch die Sitemap-basierten Top-Produkte nach alphabetischer oder ID-basierter Sortierung. So ist der Warmup deterministisch und reproduzierbar, ohne komplett manuell gepflegt werden zu müssen.

warmup:cache:
  stage: warmup
  script:
    # Download priority URL list from repository
    - |
      cat > /tmp/priority-urls.txt << 'URLS'
      https://${SHOP_HOST}/
      https://${SHOP_HOST}/sale.html
      https://${SHOP_HOST}/new-arrivals.html
      https://${SHOP_HOST}/men.html
      https://${SHOP_HOST}/women.html
      https://${SHOP_HOST}/accessories.html
      URLS

    # Add top product URLs from sitemap (first 50 product URLs)
    - |
      curl -sf "https://${SHOP_HOST}/sitemap.xml" \
        | grep -oP '(?<=<loc>)[^<]+(?=</loc>)' \
        | grep '/p/' \
        | head -50 >> /tmp/priority-urls.txt

    # Execute warmup with rate limiting (max 4 parallel requests)
    - |
      xargs -P 4 -I {} \
        curl -sf -o /dev/null -w "%{http_code} %{time_total}s %{url_effective}\n" \
        -H "User-Agent: GitLab-Warmup/1.0" \
        {} < /tmp/priority-urls.txt

  when: on_success
  dependencies:
    - deploy:production
  allow_failure: true

4. curl-basierter Warmup: einfach und zuverlässig

Ein einfacher, effektiver Warmup-Mechanismus ist curl mit den richtigen Optionen. Das Grundprinzip: Jede URL aus der Liste wird mit einer HTTP-GET-Anfrage aufgerufen. Magento rendert die Seite, speichert sie im FPC, und liefert sie beim nächsten Aufruf direkt aus dem Cache. Der Warmup-Aufruf selbst bekommt keine gecachte Response – er ist der Trigger, der die Seite generiert und in den Cache legt.

Wichtige curl-Optionen für den Warmup: -sf für silent-mode mit Fehler-Exit-Code, -o /dev/null um den Body nicht zu speichern, -w für ein strukturiertes Ausgabeformat mit HTTP-Status-Code und Ladezeit, --max-time 30 für ein Request-Timeout, damit langsame Seiten den Warmup nicht blockieren. Ein User-Agent-Header identifiziert Warmup-Requests in den Logs und ermöglicht Monitoring der Warmup-Aktivität.

5. Parallelisierung für schnelleren Warmup

Sequentielle Warmup-Aufrufe sind für kleine URL-Listen ausreichend, aber bei 50–200 URLs dauert es mehrere Minuten. Mit Parallelisierung lässt sich der Warmup auf Sekunden reduzieren. Das Tool xargs -P N startet N parallele Prozesse, die jeweils eine URL abrufen. Die optimale Parallelität hängt vom Server ab: Mehr als die Anzahl der PHP-FPM-Worker als parallele Requests kann den Server in den Rückstau treiben und ist kontraproduktiv.

Für Shops mit Varnish oder einem CDN-Cache sollte die Parallelisierung moderat sein, weil Varnish selbst bereits eine Coalescing-Funktion hat: Mehrere gleichzeitige Requests für dieselbe URL werden zu einem einzigen Backend-Request zusammengefasst. Zu viele parallele Warmup-Requests für unterschiedliche URLs können jedoch den PHP-FPM-Worker-Pool erschöpfen. Ein Wert von 4–8 parallelen Requests ist ein guter Ausgangspunkt für einen einzelnen Magento-Server.

6. Warmup-Job in GitLab CI integrieren

Der Warmup-Job gehört in eine warmup-Stage, die nach deploy und vor oder gleichzeitig mit verify ausgeführt wird. Die Stage-Reihenfolge: build → test → package → deploy → warmup → verify. Der Warmup-Job hängt explizit vom Deploy-Job ab und läuft nur, wenn der Deploy erfolgreich war. Mit allow_failure: true verhindert man, dass ein fehlgeschlagener Warmup den gesamten Pipeline-Zustand auf Failed setzt – ein Warmup-Fehler ist ärgerlich, aber kein Deployment-Fehler.

Ein wichtiges Detail: Der Warmup-Job sollte when: on_success und allow_failure: true kombinieren. Damit läuft er nur bei erfolgreichem Deploy, aber ein Warmup-Fehler blockiert den Verify-Job nicht. Das Warmup-Ergebnis – Ladezeiten und Cache-Hit-Raten – wird als Artefakt gespeichert und dient als Post-Deploy-Monitoring-Datenpunkt. Über mehrere Deployments hinweg zeigt diese Aufzeichnung, ob die Performance nach Releases stabil bleibt oder sich verschlechtert.

7. Warmup mit Varnish und ESI-Blöcken

Bei Magento mit Varnish als Full-Page-Cache ist das Warmup-Prinzip dasselbe, aber die Implementierung unterscheidet sich leicht. Varnish reagiert auf einen leeren Cache mit einem Backend-Request an Magento, der das Rendering auslöst. Der Warmup-Aufruf trifft also zunächst Varnish, der dann an Magento weiterleitet. Der X-Cache-Response-Header von Varnish zeigt an, ob der Request ein Cache-Miss (MISS) oder Cache-Hit (HIT) war.

ESI-Blöcke (Edge Side Includes) in Magento mit Varnish sind ein besonderer Fall: Seiten mit ESI-Blöcken werden in mehrere Cache-Einheiten aufgeteilt. Der Warmup einer Seite mit ESI löst mehrere Backend-Requests aus – einen für die Hauptseite und je einen für jeden ESI-Block. Das bedeutet, der Warmup-Effekt einer URL ist bei ESI größer als bei einer einfachen gecachten Seite, weil mehrere Cache-Einträge gefüllt werden. Wer Varnish mit ESI verwendet, sollte den Warmup mit etwas niedrigerer Parallelität starten, um den Backend nicht zu überlasten.

warmup:varnish:
  stage: warmup
  script:
    # Warm up pages and verify Varnish cache status
    - |
      while IFS= read -r url; do
        # First request: cache MISS — triggers Magento rendering
        response=$(curl -sf -o /dev/null \
          -w "%{http_code}|%{time_total}|%{size_download}" \
          -H "User-Agent: Warmup-Bot/1.0" \
          --max-time 30 "${url}")

        http_code="${response%%|*}"
        rest="${response#*|}"
        load_time="${rest%%|*}"

        # Second request: should be cache HIT from Varnish
        cache_header=$(curl -sf -I \
          -H "User-Agent: Warmup-Bot/1.0" \
          --max-time 5 "${url}" 2>/dev/null \
          | grep -i "x-cache:" || echo "x-cache: UNKNOWN")

        echo "[${http_code}] ${load_time}s ${cache_header##*: } ${url}"
      done < /tmp/warmup-urls.txt | tee warmup-results.log

  artifacts:
    paths:
      - warmup-results.log
    expire_in: 7 days
  when: on_success
  allow_failure: true

8. Ergebnisse validieren: Cache-Hit prüfen

Ein Warmup-Job, der keine Ergebnisse validiert, ist kaum besser als kein Warmup. Die Validierung erfolgt in zwei Schritten: Erstens wird der HTTP-Status-Code des Warmup-Requests geprüft – 200 bedeutet Erfolg, 4xx oder 5xx bedeuten ein Problem, das untersucht werden muss. Zweitens wird nach dem Warmup-Request ein zweiter Request an dieselbe URL gesendet, um den X-Cache-Header zu lesen. Ein HIT bestätigt, dass die Seite jetzt im Cache liegt.

Die Warmup-Ergebnisse werden als CSV oder Log-Datei als GitLab-Artefakt gespeichert. Über das GitLab-Interface kann das Team nach dem Deployment die Warmup-Ergebnisse einsehen: Welche Seiten wurden erfolgreich gecacht, welche hatten unerwartete Ladezeiten, welche sind mit Fehlern zurückgekommen. Ein Warmup-Fehler bei einer bestimmten URL deutet auf ein Problem mit dieser Seite hin, das unabhängig vom Warmup untersucht werden sollte.

9. Vergleich: kein Warmup vs. priorisierter Warmup

Die Tabelle zeigt: Ein priorisierter Warmup-Job erfordert minimalen Aufwand (20–30 Zeilen YAML und eine URL-Liste) und liefert erhebliche Verbesserungen in mehreren Dimensionen. Die erste Ladezeit für echte Besucher sinkt von mehreren Sekunden auf Millisekunden, der Cache-Stampede wird verhindert, und der Warmup-Job dient gleichzeitig als früher Fehlerindikator für Seiten, die nach dem Deployment nicht korrekt antworten.

10. Zusammenfassung

Ein automatisierter Cache-Warmup-Job in der GitLab-Pipeline ist eine der einfachsten und wirkungsvollsten Maßnahmen nach einem Magento-Deployment. Die Implementierung erfordert eine priorisierte URL-Liste, einen curl-basierten Warmup-Mechanismus mit kontrollierter Parallelisierung und einen Verify-Schritt, der Cache-Hits bestätigt. Das Ergebnis: Besucher erleben den Shop nach dem Deployment direkt mit voller Cache-Performance, kein Cache-Stampede, kein Post-Deploy-Performance-Dip.

Der Warmup-Job läuft als allow_failure: true-Job nach dem Deploy, sodass Warmup-Probleme den Pipeline-Status nicht beeinflussen. Die Warmup-Ergebnisse werden als Artefakt gespeichert und ermöglichen Post-Deploy-Monitoring über mehrere Deployments hinweg. Wer diesen Job einmal implementiert hat, wird sich fragen, wie er ohne ihn deployt hat.

11. FAQ: Cache-Warmup nach Magento-Release