Fastly CDN-Fallstudie: Storytel

Storytel – Deep Dive zu einer blitzschnellen Caching Performance

Die Krux: stale-while-revalidate

Die ursprüngliche Storytel Homepage wurde durch einen sehr alten Technologie-Stack gestützt. Die auf einer Java Anwendung und Apache Struts (in den 90er Jahren weit verbreitet) basierende Website war technisch völlig veraltet.

Um ein besseres Kundenerlebnis und eine höhere Conversion-Rate zu erreichen, musste dringend ein leistungsstarker, sorgfältig optimierter Ersatz her.

Und um blitzschnelle Ladezeiten zu erreichen, musste die Cache-Steuerung mit der Option „stale-while-revalidate“ genutzt werden. Entwickler wissen, dass neue Anfragen vom Browser zunächst zwischengespeichert werden. Wird eine Anfrage erneut gesendet, wird zuerst der Cache durchsucht. Bei einem Treffer wird die Antwort direkt an den Nutzer zurückgegeben. Anschließend wird der Cache nach veralteten Inhalten durchsucht und gegebenenfalls aktualisiert.

Dadurch ergeben sich für die Kunden extrem schnelle Ladezeiten, da sie sofort eine Antwort erhalten und gleichzeitig eine Aktualisierung vom Origin-Server erfolgt.

Der Erfolg des Projekts beruhte letztlich auf dieser Funktionsweise. Außerdem entwickelte Storytel eine sehr kurze Caching-Strategie (mit Caches mit einer Länge von 30-40 Sekunden), da neue Änderungen über das CMS schnell umgesetzt werden sollten.

Beim Dogfooding wurden jedoch Seitenladezeiten von über einer Sekunde festgestellt, was für ein hochkarätiges Projekt mit monatelanger Planungszeit eine Katastrophe bedeutete.

Das CDN eines anderen großen Anbieters erwies sich als riesiger Stolperstein

Die Dokumentation (RFC) zur „stale-while-revalidate“-Anweisung ist relativ nachsichtig. Dort heißt es nicht, dass ein HTTP-Server diesen Prozess bei jeder Anfrage auslösen muss, sondern nur, dass er dies tun kann. Er kann aber auch den Client blockieren, während er Daten vom Origin-Server abruft, und das Storytel Team erkannte schnell, dass dies der Grund für die schrecklich langen Seitenladezeiten war.

Die neue Caching-Strategie funktionierte einfach nicht in Verbindung mit dem bestehenden CDN. Weitere Nachforschungen ergaben, dass es für dieses CDN-Produkt keine Lösung gab: laut Internetrecherchen handelte es sich hier um ein häufiges Problem, und der Anbieter hatte wiederholt erklärt, dass er nicht plane, die Funktionsweise der „stale-while-revalidate“-Anweisung zu ändern.

Weitere Nachforschungen ergaben, dass es für dieses CDN-Produkt keine Lösung gab: laut Internetrecherchen handelte es sich hier um ein häufiges Problem, und der Anbieter hatte wiederholt erklärt, dass er nicht plane, die Funktionsweise der „stale-while-revalidate“-Anweisung zu ändern.

Fastly sorgt für die nötige Geschwindigkeit

Als Storytel sich auf dem Markt umsah, wurde schnell klar, dass Fastly stale-while-revalidate auf genau die gewünschte Weise unterstützt.

Der Origin-Server ist (von Natur aus) eher langsam. Er ist überhaupt nicht optimiert, sodass es durchaus eine Sekunden dauern kann, bis eine Seite im laufenden Betrieb vollständig geladen ist. Wenn eine Anfrage für eine Seite eingeht, holt sich der Origin-Server große Mengen an Daten aus dem CMS, erstellt Vorlagen und generiert eine statische HTML-Seite (die im Cache gespeichert ist).

Mit Fastly lässt sich allerdings ganz leicht eine veraltete Version der Seite ausliefern. Auf diese Weise erhalten Kunden sehr schnell Antworten und müssen nicht auf den Origin-Server warten.

Aber die Möglichkeit, dieses konkrete Problem zu lösen, war nicht das Einzige, was das Storytel Team an Fastlys CDN beeindruckt hat, sondern auch die Tatsache, dass das Projekt so schnell gerettet werden konnte. Die Homepage war innerhalb von ein paar Stunden wieder online, obwohl man kurz davor noch befürchtet hatte, dass es Monate dauern würde, sie zu reparieren. Erstaunlicherweise dauerte die Auflösung von DNS-Namen, um sicherzustellen, dass nichts kaputt geht, am längsten.

Ergebnisse (und überraschende Erkenntnisse)

Fastly sorgte für schnellere Seitenladezeiten und der gesamte Prozess verlief erstaunlich reibungslos und einfach:

• Cache Hits werden innerhalb von Millisekunden an Kunden ausgeliefert. Die Seiten werden mindestens 100x schneller geladen als direkt vom Origin-Server.


• Die Dokumentation und der Support von Fastly waren einwandfrei. Da das Unternehmen mit Varnish vertraut ist, ließ sich der Service in Verbindung mit dem neuen Origin-Server ganz leicht einrichten.


• Storytel musste keinerlei Änderungen am Origin-Server vornehmen. Die Einrichtung des Service genügte, da die Cache Header, die der Origin-Server zurückgibt (einschließlich stale-while-revalidate) beachtet werden.

Die Problemlösungskompetenz von Fastly auf granularer Ebene ist sogar noch beeindruckender.

Jetzt muss kein Storytel Kunde mehr lange warten, um sich in sein Lieblingsmärchen zu flüchten.