Maximierung Ihrer Cache-Trefferrate

Wenn Sie Ihre Cache-Trefferrate maximieren, kann dies die Leistung Ihrer Storefront signifikant verbessern. Jede Anfrage, die vom Managed Runtime CDN-Cache erfüllt werden kann, zählt als Cache-Treffer. Die Aufbauzeit von Benutzerseiten wird mit jedem Cache-Treffer beschleunigt, da die Kosten für das serverseitige Rendering dieser Seiten und die Anfragen an Backend-Systeme und APIs wegfallen.

Diese Anleitung geht auf die drei verschiedenen Techniken für die Maximierung Ihrer Cache-Treffer ein: Einrichtung der optimalen Cache-Lebensdauer, bedingtes Rendering und Filtern von Abfrage-Strings. Sehen wir uns die einzelnen Techniken im Detail an.

Die optimale Zeitdauer für die Zwischenspeicherung einer HTTP-Anfrage ist abhängig davon, worum es bei der Anfrage geht. Die Anfrage, eine sich selten ändernde Content-Seite zu laden, kann risikolos über eine längere Zeit zwischengespeichert werden. Für eine häufig mit neuen Produkten aktualisierte Produktlistenseite ist jedoch möglicherweise eine kurze Cache-Lebensdauer von 15 Minuten erforderlich. Wann immer möglich sollten Sie eine lange Cache-Lebensdauer auswählen, um die Cache-Trefferrate zu maximieren.

Ein Cache-Steuerungsheader in der HTTP-Antwort bestimmt, wie lange eine Antwort auf eine Seitenabfrage im CDN-Cache zwischengespeichert wird. Die Cache-Lebensdauer von Seitenantworten in einem PWA Kit-Projekt beträgt 600 Sekunden (bzw. 10 Minuten). Sie können die Cache-Lebensdauer für jede Seite einzeln oder für alle Seiten auf einmal anpassen.

Wenn Sie mehr über Caching im Allgemeinen erfahren möchten, empfehlen wir diesen Google-Artikel: Prevent unnecessary network requests with the HTTP Cache (Unnötige Netzwerkanfragen mit HTTP-Cache verhindern).

Die getProps-Funktion einer jeden Seitenkomponente ermöglich Ihnen, die HTTP-Antwort mithilfe eines übergebenen res-Objekts anzupassen. Um die Cache-Lebensdauer einer Seite vorzugeben, legen Sie mit der set-Methode des res-Objekts einen Cache-Control-Header fest und geben Sie für die max-age-Anweisung einen Wert in Sekunden ein.

Beispiel: Diese ProductList-Komponente verlängert die Cache-Lebensdauer von 600 Sekunden (Standard) auf 900 Sekunden:

Wir raten davon ab, den Cache-Control-Header innerhalb der getProps-Funktion festzulegen, die zur in app/components/_app/index.jsx definierten App-Sonderkomponente gehört. Die getProps-Funktionen der App-Komponente und der aktuellen Seitenkomponente werden gleichzeitig ausgeführt. Wenn Sie in beiden Funktionen den gleichen Antwort-Header festlegen, kommt es durch diese parallele Ausführung zu unvorhersehbaren Ergebnissen.

In app/ssr.js können Sie die Cache-Lebensdauer für alle Seiten festlegen. Indem Sie für defaultCacheTimeSeconds einen neuen Wert eingeben, ändern Sie die Standard-Cache-Lebensdauer. Wenn eine genauere Steuerung über den HTTP-Header erforderlich ist, fügen Sie einen Express-Handler hinzu, der einen benutzerdefinierten Header setzt. Beispiel:

Sie können testen, ob Ihre Cache-Controls in den Antwort-Headern vorhanden sind, indem Sie Ihre Netzwerkanfragen mit den DevTools von Chrome auf der Registerkarte Network (Netzwerk) überprüfen. Alternativ können Sie in Ihrem Terminal den folgenden curl-Befehl ausführen, durch den alle Antwort-Header zurückgegeben werden. Ersetzen Sie <URL> im Beispielbefehl mit der vollständigen URL, die Sie überprüfen möchten, einschließlich aller erforderlichen Abfrage-Strings.

Um zu gewährleisten, dass eine Seite für das Caching durch das CDN geeignet ist, müssen Sie das serverseitige Rendering der folgenden Content-Typen durch Hinzufügen von Bedingungscode verhindern:

  • Personalisierter Content wie Benutzername, die Anzahl der Artikel im Warenkorb und bevorzugte Zahlungsmethode. Personalisierter Content ist ausschließlich für den betreffenden Benutzer bestimmt und relevant. Durch das Caching von Antworten für einen Einzelbenutzer können Sie Ihre Cache-Treffer nicht erhöhen.
  • Sich häufig ändernder Content wie Produktpreise, verbleibender Bestand oder Werbeaktionen. Dieser Content eignet sich nicht für das Caching, da die Anzeige bereits veralteter Informationen auf der Seite die Benutzer verwirren kann.

Sie können sich die serverseitig gerenderte Seite als eine generische Grundlage vorstellen, auf der der Client aufbaut. Nach dem schnellen Laden der serverseitigen Version der Seite im Gerät des Benutzers übernimmt der Browser und rendert den personalisierten und sich häufig ändernden Content.

Anhand des window-Objekts, das nur auf der Client-Seite vorhanden ist, können Sie feststellen, ob das Rendering auf Client- oder Serverseite erfolgt. Im folgenden Beispiel wird diese Methode angewendet, um einen Preis nur auf der Client-Seite zu rendern:

Um die serverseitig gerenderte Version der Seite in Ihrem Browser als Vorschau anzuzeigen, hängen Sie der URL ?__server_only an. Dieser Abfrageparameter stoppt den Prozess der Hydration, sodass der Browser die Rendering-Aufgabe nicht übernimmt und die Seite nach dem serverseitigen Rendering unverändert bleibt.

Die meisten Storefront-Apps benutzen zum Speichern von Parametern und Werten, die Aspekte des App-Zustands repräsentieren, die Abfrage-String einer URL. Beispiel: Wenn ein Benutzer den Suchbegriff "Sweaters" benutzt, können Sie diesen Begriff wie folgt in die Abfrage-String einschließen: ?search=sweaters Abfrage-Strings werden häufig auch zum Tracking von Benutzeraktionen eingesetzt. So können wir beispielsweise jedem in einer E-Mail eingebetteten Link einen eindeutigen Abfrage-String anhängen, um die Interaktionen mit diesem Link zu verfolgen: user=juanita&source=email

Nicht alle Abfrage-Strings sind relevant für das Caching. Managed Runtime enthält eine Edge-Funktion namens Request Processor (Abfragen-Verarbeitung), mit der Sie den Abfrage-String einer Anfrage modifizieren können, bevor sie nach zwischengespeicherten Antworten sucht. Indem Sie mit dem Request Processor ähnliche URLs derselben zwischengespeicherten Antwort zuordnen, können Sie Ihre Cache-Treffer erhöhen.

Um den Request Processor anzupassen, bearbeiten Sie die in app/request-processor.js definierte processRequest-Funktion.

Das folgenden Beispiel definiert einen Request Processor, der die Parameter gclid und utm_campaign aus dem Abfrage-String herausfiltert. Diese Parameter sind oftmals mit Google-Marketingkampagnen assoziiert und sind deshalb nur für die Client-Seite relevant. Zur Vereinfachung der Arbeit mit Abfrage-Strings wird die QueryParameters-Klasse aus dem PWA Kit React SDK importiert.

Die vollständige URL, die für die Suche nach dem entsprechenden Objekt im Cache verwendet wird, enthält die Version des Abfrage-String, die vom Request Processor zurückgegeben wird. Wird für diese URL keine Antwort zwischengespeichert, wird die gleiche modifizierte Version der URL an die Express App übergeben.

Bei diesem Ansatz sind zwei Fallstricke zu vermeiden:

  1. Vergewissern Sie sich, dass Ihre App für das Rendering nicht auf gefilterte Parameter angewiesen ist! Wenn Sie beispielsweise den search-Parameter aus dem obigen Beispiel als Filter benutzen, können Sie keine korrekten Suchergebnisse anzeigen.

  2. Seien Sie vorsichtig, wenn Sie Parameter aus Anfragen herausfiltern, die für die Umleitung benötigt werden. Wenn Ihr Code nicht mehr auf einen herausgefilterten Parameter zugreifen kann, kann dieser natürlich auch nicht mehr für die Umleitung verwendet werden. Beispiel: Eine Komponente, die eine Startseite anfordert, leitet die Anfrage www.example.com?lang=en zu einem für ein bestimmtes Gebietsschema spezifischen Pfad wie www.example.com/en um. Wenn Sie den lang-Parameter herausfiltern, können Sie die Anfrage nicht zum richtigen Gebietsschema umleiten.

Beispielsequenz:

  1. Der Request Processor bearbeitet die Anfrage www.example.com/?gclid=123.
  2. Er filtert den Abfrage-String-Parameter gclid heraus.
  3. Die Anfrage wird mit der vollständigen URL www.example.com an die Anwendung weitergeleitet.
  4. Die Anwendung gibt eine Umleitung an www.example.com/en zurück.

Wie Sie sehen können, wurde im letzten Schritt der ursprüngliche gclid-Parameter entfernt. Dieser ist daher nach der Umleitung des Benutzers für den Browser nicht mehr verfügbar. Sie sollten daher vermeiden, Abfrage-Strings aus Anfragen herauszufiltern, die umgeleitet werden.

Sie haben nun eine Reihe von Methoden kennengelernt, mit denen Sie Ihre Cache-Trefferrate für Seitenabfragen erhöhen können.

In unserer Anleitung zu Proxy-Anfragen erfahren Sie mehr über das Caching von API-Anfragen und andere Vorteile von Proxy-Vorgängen.