ESI erklärt: Zwischenspeicher der Seite, personalisieren Sie die Bits
Das klassische Caching-Dilemma: Die Seite ist für jeden 99% identisch, aber dass 1% – der Benutzername, der Warenkorb zählt – das Ganze unerreichbar macht. Der ESI ist einer von zwei Auswegen, und er ist nicht immer der richtige.
Edge Side Includes ermöglicht es Ihnen, eine Seite vollständig zu verbergen, während kleine Regionen als separate Fragmente markiert werden, die der Rand pro Besucher füllt — ein Warenkorbzählen, ein Gruß, ein personalisiertes Banner. Jedes Fragment erhält seine eigenen Cache-Regeln, so dass eine Seite Inhalte, die für einen Tag zwischengespeichert wurden, eine Minute lang zwischengespeichert und Inhalte, die nie zwischengespeichert wurden, kombinieren kann. Die Hauptalternative ist das Abrufen dieser Fragmente auf der Client-Seite, und welche gewinnt, hängt davon ab, ob das Fragment das Layout beeinflusst.
Hier ist eine Frustration, die jeder, der dynamische Seiten speichert weiß gut. Eine Seite ist im Wesentlichen für jeden Besucher identisch — gleiches Layout, gleiche Produkte, gleiche Kopie — mit Ausnahme einer kleinen persönlichen Ecke. Der Warenkorb zählt im Header. Das "Hi, Sara". Und wegen dieser eine Ecke, die ganze Seite wird markiert uncacheable und von Grund auf neu für jede Anfrage.
Es ist ein schlechter Handel, und es gibt zwei etablierte Wege aus ihm heraus. Der ESI ist der ältere, und er ist unter bestimmten Umständen immer noch der bessere, der es wert ist, genau zu wissen.
Wie wirkt ESI?
Ihr Ursprung gibt eine Seite zurück, die Platzhalter-Tags anstelle der dynamischen Teile enthält:
<header>
<esi:include src="/fragments/cart-summary" />
</header>Diese Seite — Platzhalter und alles — wird als normale zwischengespeicherte Antwort am Rand zwischengespeichert. Wenn ein Besucher es verlangt, dient die Kante der zwischengespeicherten Shell und holt vor dem Senden jedes Fragment und ersetzt es. Die Fragmentanfrage trägt die Cookies des Besuchers, so dass sie personalisiert werden kann, und es hat seine eigenen Cache-Regeln unabhängig von der Seite.
Die wichtige Folge ist, dass eine Seite nun mehrere unterschiedliche Caching-Strategien gleichzeitig tragen kann. Die Shell zwischenspeichert für einen Tag. Ein "trending right now" Blockcaches für sechzig Sekunden und wird von allen geteilt. Das Warenkorbfragment ist persönlich und nie zwischengespeichert. Alle am Rand zusammengebaut, alle als ein HTML-Dokument geliefert.
ESI versus Abrufen im Browser
Die offensichtliche Alternative ist, eine Lücke im HTML zu lassen und es nach dem Laden der Seite mit JavaScript zu füllen. Das funktioniert, es ist einfacher zu bauen, und für viele Fälle ist es die richtige Antwort.
Dob sich das Fragment im HTML befindet, wenn es den Browser erreicht.
| ESI | Kundenseitiges Abrufen | |
|---|---|---|
| Im ursprünglichen HTML-Format vorhanden | Nein | Nein |
| Ursache für Layoutverlagerung | Nein | Ja, es sei denn, der Platz ist reserviert |
| Extra Browser Rundreise | Keine | Eins pro Fragment |
| Funktioniert ohne JavaScript | Nein | Nein |
| Sichtbar für Raupen | Nein | Manchmal, unzuverlässig |
| Komplexität der Umsetzung | Edge-Konfiguration erforderlich | Gewöhnliche Front-Endarbeiten |
| Langsames Fragment verzögert die Seite | Ja — es blockiert die Antwort | Nein — Seite rendert zuerst |
Lies die letzten zwei Reihen zusammen, denn sie sind der Handel. ESI gibt Ihnen ein komplettes Dokument ohne Layout-Shift und keine zusätzliche Rundreise, auf Kosten der Seite nur so schnell wie sein langsamstes Fragment. Client-Seite holen gibt Ihnen eine Seite, die sofort rendern unabhängig, auf Kosten von Inhalten, die spät ankommen und Dinge bewegen.
Also: Wwenn das Fragment das Layout beeinflusst oder für einen Raupen von Bedeutung ist, verwenden Sie ESI. Ein personalisiertes Heldenbanner, das die Höhe der Seite ändert, sollte nicht 400 Millisekunden später ankommen – das ist ein kumulatives Layout-Shift-Problem, das Sie absichtlich erstellt haben. Wenn es ein kleines Detail in einer Ecke ist, holen Sie es client-side. Ein cart Count-Badge im Header rechtfertigt keine Kantenkonfiguration.
Der Fehler-Modus, gegen den zu entwerfen ist ein Fragment, das hängt. Da ESI vor dem Ansprechen zusammengebaut wird, dauert ein Fragmentendpunkt, der drei Sekunden dauert, drei Sekunden – obwohl die Shell ein Cache-Hit war. Stellen Sie einen aggressiven Timeout auf jedem Fragment und definieren, was rendern, wenn es nicht erfüllt wird, so dass ein kämpfender Fragment-Service degradiert zu einem fehlenden Warenkorb zählen anstatt eine unbrauchbare Website.
Wo er seinen Platz verdient
Guter Sitz
- Hochverkehrsseiten mit einem oder zwei persönlichen Elementen
- Fragmente, die das Layout über der Falte beeinflussen
- Abschnitte mit wirklich unterschiedlichen Frischebedürfnissen auf einer Seite
- Websites, die ohne JavaScript funktionieren müssen
Nicht wert
- Seiten, die überall persönlich sind
- Kleine Abzeichen und Zähler in Ecken
- Low-traffic Seiten, auf denen Caching wenig spart
- Alles, was ein einfaches holen Griffe angemessen
Der ESI ist ein spezialisiertes Instrument und sollte sich wie eins fühlen. Wenn Sie es auf einer Seite erreichen, auf der drei Viertel des Inhalts pro Besucher sind, dann kämpfen Sie gegen den Mechanismus — diese Seite ist wirklich dynamisch und sollte als solche behandelt werden.
Gemeinsame Fragen
Was ist ESI (Edge Side Includes)?
ESI ist eine Markup-Sprache, die eine zwischengespeicherte Seite Platzhalter-Tags für dynamische Fragmente enthalten lässt, die der CDN-Kante vor der Rückgabe der Antwort holt und ersetzt. Dadurch kann eine Seite vollständig zwischengespeichert werden, während kleine personalisierte Regionen – ein Warenkorbzählen, eine Benutzerbegrüssung – pro Besucher zusammengestellt werden, jeweils mit eigenen unabhängigen Cache-Regeln.
Wann sollte ich ESI anstelle eines Client-Seiten-Hotchs verwenden?
Verwenden Sie ESI, wenn das Fragment das Layout beeinflusst oder für Suchmaschinen sichtbar sein muss, da ESI-Inhalte im HTML vorhanden sind, das den Browser erreicht und keine Layoutverschiebung oder zusätzliche Rundreise verursacht. Verwenden Sie eine Client-Seite holen für kleine Details, die nicht das Layout beeinflussen, wo die Einfachheit der gewöhnlichen Front-End-Code überwiegt den Nutzen und eine späte Ankunft ist harmlos.
Verlangt ESI die Bereitstellung von Seiten?
Es kann, weil Fragmente vor dem Senden der Antwort zusammengefügt werden, so dass die Seite nur so schnell ist wie ihr langsamstes Fragment. Ein Fragment-Endpunkt, der hängt, verzögert eine Seite, die sonst ein Cache-Hit war. Konfigurieren Sie immer einen kurzen Timeout pro Fragment zusammen mit Fallback-Inhalt, so dass ein scheiterndes Fragment anmutig degradiert, anstatt die gesamte Antwort zu blockieren.
Können verschiedene Teile einer Seite unterschiedliche Cache-Zeiten mit ESI haben?
Ja, und das ist sein Hauptvorteil. Die Seitenshell kann für einen Tag zwischengespeichert werden, ein Fragment für Trending-Products für sechzig Sekunden und geteilt zwischen allen Besuchern, und ein Cart Fragment, das überhaupt nicht zwischengespeichert wurde. Die Kante montiert sie in eine einzige HTML-Antwort, so dass ein Dokument mehrere Caching-Strategien kombiniert.
Der Rahmen lohnt sich zu halten: ESI ist nicht eine Caching-Technologie, sondern eine Montage. Mit ihm können Sie aufhören, eine Seite als eine einzige zwischenspeicherbare Einheit zu behandeln, und beginnen, sie als mehrere zu behandeln — was in der Regel eine viel genauere Beschreibung dessen ist, was die Seite tatsächlich ist.
Sehen Sie, wie NordicCDN dies für Ihre Website tut:
Mads hat seit seinem 16. Lebensjahr in der IT gearbeitet — hauptsächlich als Hosting. Er beteiligte sich früh an einer SaaS-Firma und half, sie bis zur Übernahme durch Visma weiterzuentwickeln, hat Data-Center-Netzwerke aufgebaut und betrieben und diente als CTO eines dänischen Rechenzentrums. Er hat NordicCDN gestartet, um eine schnelle, sichere Infrastruktur einfach zu bedienen.
