CloudFront Cache-Warming für DAM Bilder für schnellere Ladezeiten in CMS TYPO3 und Wordpress
Moderne Websites leben von hochwertigen Bildern. Gerade bei Produktdatenbanken, Kategorieseiten und digitalen Katalogen werden oft viele Bilddaten aus einem Digital Asset Management System, kurz DAM, eingebunden. In vielen Projekten kommen dabei DAM, PIM und CMS Systeme wie Bynder, Akeneo und TYPO3 oder Wordpress zusammen: Die Bilder werden im DAM verwaltet, in Akeneo als Produktdaten hinterlegt und anschließend auf der Website ausgespielt.
Technisch ist das eine sehr saubere Lösung. In der Praxis kann aber ein Problem entstehen, das man erst bei größeren Datenmengen oder stark bebilderten Produktlisten wirklich bemerkt: Der erste Aufruf eines Bildes kann deutlich länger dauern als alle weiteren Aufrufe.
Der Grund liegt meist nicht in TYPO3, Wordpress oder Akeneo selbst, sondern in der Art, wie Bilddaten über ein CDN wie Amazon CloudFront ausgeliefert werden.
Warum der erste Bildaufruf langsam sein kann
CloudFront arbeitet mit sogenannten Edge Locations. Das sind weltweit verteilte Serverstandorte, die Inhalte möglichst nah am jeweiligen Website-Besucher ausliefern. Ruft ein Besucher ein Bild auf, prüft CloudFront zuerst, ob dieses Bild an der zuständigen Edge Location bereits im Cache vorhanden ist.
Ist das Bild dort bereits gespeichert, wird es sehr schnell ausgeliefert.
Ist es dort nicht vorhanden, muss CloudFront das Bild zunächst vom Ursprungssystem abrufen. Bei DAM-Systemen kann dabei zusätzlich noch eine Bildverarbeitung stattfinden: Das Bild wird für Web optimiert, in die richtige Größe gebracht, komprimiert oder in ein geeignetes Format umgewandelt.
Genau dieser Vorgang kann pro Bild ein bis zwei Sekunden dauern. Bei einem einzelnen Bild fällt das kaum auf. Auf einer Produktübersichtsseite mit vielen Bildern kann daraus aber schnell eine spürbar langsame Seite werden.
Das Problem: CDN-Cache ist nicht überall gleich
Ein häufiger Denkfehler ist: „Wir rufen das Bild einmal auf, dann ist es im CloudFront-Cache.“
Das stimmt nur teilweise.
CloudFront speichert Inhalte nicht automatisch gleichzeitig an allen Standorten weltweit. Der Cache wird üblicherweise an der Edge Location gefüllt, über die der jeweilige Request tatsächlich läuft. Je nach Standort des Besuchers, DNS-Resolver, Netzwerkroute und CloudFront-Routing kann also eine andere Edge Location angesprochen werden.
Hier kommen Fachbegriffe wie GeoDNS, DNS Load Balancing, latency-based routing, Edge Caching und CDN Cache-Warming ins Spiel.
Eine DNS-Abfrage auf dieselbe Asset-Domain kann unterschiedliche IP-Adressen zurückliefern. Das ist kein Fehler, sondern Teil des CDN-Prinzips. Je nach Resolver und Standort kann der Nutzer zu einer anderen CloudFront-Infrastruktur geleitet werden. Für die Performance ist das grundsätzlich sehr gut. Für gezieltes Cache-Warming wird es aber anspruchsvoller.
Die Idee: Cache-Warming über mehrere CDN-Zieladressen
Um die Ladezeiten zu verbessern, haben wir eine Lösung entwickelt, die Bild-URLs aus der Produktdatenbank ausliest und gezielt vorab aufruft. Ziel ist es, CloudFront dazu zu bringen, die Bilder bereits im Cache zu haben, bevor echte Website-Besucher die Produktseiten öffnen.
Dabei reicht es aber nicht, jede Bild-URL nur einmal aufzurufen. Denn dieser eine Request landet möglicherweise nur bei einer einzigen CloudFront-IP beziehungsweise einer bestimmten Edge Location.
Deshalb geht der entwickelte Ansatz einen Schritt weiter:
Die Asset-Domain wird mehrfach aufgelöst, also per DNS abgefragt. Dabei wird nicht nur die normale System-DNS-Auflösung des Servers verwendet, sondern zusätzlich mehrere öffentliche Nameserver. Die zurückgelieferten IPv4-Adressen werden gesammelt, bereinigt und doppelte Einträge werden entfernt.
Anschließend wird jede Bild-URL gezielt über die gefundenen IP-Adressen aufgerufen. So lässt sich die Wahrscheinlichkeit erhöhen, dass mehrere CDN-Knoten beziehungsweise CloudFront-Zielsysteme die Bilder bereits im Cache haben.
Warum SSL dabei eine besondere Rolle spielt
Bei HTTPS kann man nicht einfach eine Bild-URL über eine IP-Adresse aufrufen. Das SSL-Zertifikat ist auf den Domainnamen ausgestellt, nicht auf die einzelne IP-Adresse.
Würde man also statt der Domain direkt die IP-Adresse verwenden, könnte die TLS-Prüfung fehlschlagen. Der Browser oder HTTP-Client würde melden, dass das Zertifikat nicht zur aufgerufenen Adresse passt.
Die Lösung besteht darin, die URL weiterhin mit dem korrekten Hostnamen aufzurufen, die DNS-Auflösung aber technisch zu überschreiben. Der Request geht also an eine bestimmte IP-Adresse, während der Hostname für HTTPS, SNI und Zertifikatsprüfung erhalten bleibt.
Das ist ein wichtiger Punkt: Die Verbindung bleibt SSL-validiert und sauber, trotzdem kann gezielt gesteuert werden, welche IP-Adresse für den Request verwendet wird.
Wie die entwickelte Lösung arbeitet
Die Lösung wurde als eigenständiges CLI-Script umgesetzt und ist unabhängig vom Wordpress oder TYPO3-Bootstrap lauffähig. Das macht sie besonders geeignet für Cronjobs, Wartungsläufe oder geplante Cache-Warming-Prozesse.
Der Ablauf ist vereinfacht folgender:
- Die Datenbankverbindung wird aus der TYPO3 oder Wordpress Konfiguration gelesen.
- Aus der Produktdatenbank werden sichtbare und nicht gelöschte Produkte geladen.
- Die in Akeneo gepflegten Bild-URLs werden aus dem entsprechenden JSON-Feld ausgelesen.
- Für jede Asset-Domain werden IPv4-Adressen über System-DNS und zusätzliche Nameserver ermittelt.
- Doppelte IP-Adressen werden entfernt.
- Jede Bild-URL wird gezielt über die gefundenen IP-Adressen abgerufen.
- Der Response-Body wird verworfen, weil es nur darum geht, den CDN-Cache zu füllen.
- Am Ende werden Statuscodes, Laufzeiten und mögliche Fehler zusammengefasst.
Dadurch entsteht ein kontrollierter Preload-Prozess, der nicht blind alle Daten abruft, sondern nachvollziehbar protokolliert, welche Hosts, IP-Adressen und HTTP-Statuscodes beteiligt waren.
Warum das besonders bei TYPO3, Wordpress, Akeneo und DAM-Systemen wichtig ist
In einem klassischen TYPO3 oder Wordpress Projekt liegen Bilder oft direkt im Dateisystem oder werden über TYPO3 FAL verwaltet. Dann sind Caching und Bildverarbeitung vergleichsweise gut kontrollierbar.
Bei einer Systemlandschaft mit DAM, PIM und CMS sieht das anders aus:
Das DAM verwaltet die Originalassets.
Akeneo verwaltet die Produktinformationen und Bildreferenzen.
TYPO3 oder Wordpress geben die Daten auf der Website aus.
CloudFront übernimmt die globale Auslieferung.
Diese Architektur ist leistungsfähig und skalierbar. Gleichzeitig entstehen mehrere technische Übergabepunkte. Wenn ein Bild nicht im CDN-Cache liegt, kann der erste Request mehrere Systeme berühren: CDN, DAM, Bildtransformation, Optimierung und schließlich die Auslieferung an den Besucher.
Gerade bei Produktlisten, Kategorieübersichten, Suchergebnisseiten oder Landingpages mit vielen Produktbildern kann das die Core Web Vitals und die wahrgenommene Geschwindigkeit beeinflussen.
Vorteile eines gezielten CloudFront Cache-Warmings
Ein sauber umgesetztes Cache-Warming kann mehrere Vorteile bringen:
Schnellere erste Seitenaufrufe
Bilder sind im Idealfall bereits im CDN-Cache vorhanden, bevor Besucher sie benötigen.
Bessere User Experience
Produktlisten laden gleichmäßiger und wirken deutlich reaktionsschneller.
Entlastung des Ursprungssystems
Das DAM und die dahinterliegende Bildverarbeitung müssen weniger spontane Erstabrufe verarbeiten.
Bessere Performance bei Kampagnen oder Relaunches
Vor Produktlaunches, Newsletter-Kampagnen oder saisonalen Aktionen können relevante Bilder gezielt vorbereitet werden.
Mehr Kontrolle und Transparenz
Durch Logging, HTTP-Statusauswertung und Laufzeitmessung lässt sich prüfen, welche Assets erreichbar sind und wo Probleme auftreten.
Was man dabei beachten muss
Cache-Warming ist kein Ersatz für eine saubere CDN-Konfiguration. TTL-Werte, Cache-Control-Header, Bildgrößen, Formatstrategie, Origin-Performance und CDN-Regeln bleiben weiterhin entscheidend.
Außerdem sollte ein Preload-Script kontrolliert laufen. Es sollte nicht unnötig viele Requests erzeugen und nicht ungebremst alle Assets gleichzeitig anfragen. Sinnvoll sind Limits, Timeouts, Pausen zwischen Requests und ein Dry-Run-Modus zur Prüfung.
Auch wichtig: DNS-Antworten sind dynamisch. Es gibt keine Garantie, dass man damit wirklich jede weltweite CloudFront Edge Location erreicht. Aber man kann die Abdeckung verbessern und typische Erstaufruf-Probleme deutlich reduzieren.
Unser Fazit
Bei komplexen Webplattformen mit DAM, PIM und CMS reicht klassisches Caching oft nicht aus. Besonders dann, wenn Bilder extern verarbeitet und über ein CDN ausgespielt werden, lohnt sich ein genauer Blick auf den ersten Request.
Durch gezieltes CloudFront Cache-Warming über mehrere DNS-Auflösungen und kontrollierte HTTPS-Requests lässt sich die Performance spürbar verbessern. Die technische Besonderheit liegt darin, die DNS-Auflösung für einzelne Requests gezielt zu steuern, ohne die SSL-Prüfung und den korrekten Hostnamen zu verlieren.
Für Website-Besucher bedeutet das: weniger Wartezeit, schnellere Produktseiten und ein stabileres Nutzungserlebnis.
Für Unternehmen bedeutet es: bessere Performance, weniger Last auf Ursprungssystemen und eine professionellere technische Basis für digitale Produktkommunikation.
Genau solche Schnittstellen zwischen TYPO3, Wordpress, Akeneo, DAM-Systemen, CDN, DNS und Performance-Optimierung sind typische Aufgaben, bei denen technische Erfahrung den Unterschied macht. Bei comvos betrachten wir nicht nur das sichtbare Frontend, sondern auch die Prozesse dahinter — denn oft entsteht echte Performance genau dort, wo CMS, Produktdaten, Medienverwaltung und Infrastruktur sauber zusammenspielen.
Ist auch Ihre Website zu langsam? Lassen Sie uns gerne in einem kurzen Meet darüber sprechen, wie wir Ihren Online-Auftritt präzise und wirkungsvoll optimieren.
