ESI forklaret: cache siden, personliggør bits
Det klassiske cache dilemma: siden er 99% identisk for alle, men at 1% - brugernavnet, vognen tæller - gør det hele uoverskueligt. ESI er en af to måder at komme ud på, og det er ikke altid den rigtige.
Edge Side Inkluderer, at du kan cache en side i sin helhed, mens du markerer små områder som separate fragmenter kanten udfylder pr. besøgende - en vogn tæller, en hilsen, en personlig banner. Hvert fragment får sine egne cacheregler, så en side kan kombinere indhold, der er cachelagret for en dag, indhold, der er cachelagret i et minut, og indhold, der aldrig er cachelagret overhovedet. Det primære alternativ er at hente disse fragmenter på klientsiden, og hvilken en der vinder afhænger af, om fragmentet påvirker layoutet.
Her er en frustration, som alle, der cacher dynamiske websteder, kender godt. En side er stort set identisk for alle besøgende – samme layout, samme produkter, samme kopi – bortset fra et lille personligt hjørne. Vognen tæller i overskriften. Hej, Sara. Og på grund af det ene hjørne bliver hele siden markeret uoverskuelig og genopbygget fra bunden for hver anmodning.
Det er en dårlig handel, og der er to etablerede veje ud af det. ESI er den ældste, og den er stadig den bedste under særlige omstændigheder, som er værd at vide præcist.
Sådan fungerer ESI
Din oprindelse returnerer en side, der indeholder pladsholdermærker i stedet for de dynamiske dele:
<header>
<esi:include src="/fragments/cart-summary" />
</header>Denne side - pladsholder og alt - cachelagres ved kanten som et normalt cachevenligt svar. Når en besøgende anmoder om det, serverer kanten den cachelagrede skal og henter hvert fragment og erstatter det, før det sendes. Denne anmodning indeholder besøgendes cookies, så den kan tilpasses personligt, og den har sine egne cacheregler, som er uafhængige af siden.
Den vigtige konsekvens er, at én side nu kan indeholde flere forskellige cachestrategier på samme tid. Skalen gemmer sig i en dag. En "løbende lige nu" blokerer cachen i 60 sekunder og deles af alle. Vognens fragment er personligt og aldrig cachelagret. Alt sammen samlet på kanten, alt sammen leveret som ét HTML-dokument.
ESI versus hentning i browseren
Det indlysende alternativ er at efterlade et hul i HTML-koden og udfylde den med JavaScript, efter siden er blevet indlæst. Det virker, det er nemmere at bygge, og for mange tilfælde er det det rigtige svar.
Den skelnen, der afgør, om fragmentet er i HTML-koden, når det når frem til browseren.
| ESI | Hent på klientsiden | |
|---|---|---|
| Tilstedeværelse i indledende HTML | Ja, ja | Nr |
| Årsager til layoutskift | Nr | Ja, medmindre pladsen er reserveret |
| Ekstra browser tur/retur | Ingen | Én pr. fragment |
| Virker uden JavaScript | Ja, ja | Nr |
| Synlig for krybdyr | Ja, ja | Nogle gange, upålideligt |
| Kompleks gennemførelse | Kantkonfiguration påkrævet | Almindeligt frontarbejde |
| Langsomt stykke forsinker siden | Ja – det blokerer svaret | Ingen side gengives først |
Læs de to sidste rækker sammen, fordi de er handelen. ESI giver dig et komplet dokument uden layoutskift og ingen ekstra rundtur, på bekostning af at siden kun er så hurtig som dens langsomste fragment. Hentning på klientsiden giver dig en side, der gengives med det samme uanset prisen for indhold, der kommer for sent, og som flytter ting.
Så hHvis fragmentet påvirker layoutet eller sagen for en crawler, skal du bruge ESI. Et personligt heltebanner, der ændrer sidens højde, bør ikke ankomme 400 millisekunder for sent – det er et kumulativt Layout Shift-problem, du bevidst har oprettet. Hvis det er en lille detalje i et hjørne, skal du hente den på klientsiden. Et vogntællingsmærke i overskriften retfærdiggør ikke kantkonfiguration.
Fejltilstanden, der skal designes imod, er et fragment, der hænger. Fordi ESI samles, før du svarer, får et fragmentendepunkt, der tager tre sekunder, hele siden til at tage tre sekunder - selvom skallen var et cache-hit. Sæt en aggressiv timeout på hvert fragment og definere, hvad der gør, hvis det ikke er opfyldt, så en kæmper fragment tjeneste nedbrydes til en manglende vogn tæller snarere end en ubrugelig site.
Hvor den fortjener sin plads
God pasform
- Sider med høj trafik med et eller to personlige elementer
- Fragmenter, der påvirker layoutet over folden
- Sektioner med virkelig forskellige friskhedsbehov på én side
- Websteder, der skal fungere uden JavaScript
Ikke det værd
- Sider, der er personlige overalt
- Små mærker og tællere i hjørner
- Sider med lav trafik, hvor caching sparer meget lidt
- Alt, hvad der er nemt at hente, håndterer det godt
ESI er et specialiseret værktøj, og det bør føles som et sådant. Hvis du rækker ud efter den på en side, hvor tre fjerdedele af indholdet er pr. besøgende, bekæmper du mekanismen - den side er virkelig dynamisk og bør behandles som sådan.
Almindelige spørgsmål
Hvad er ESI (Edge Side Includes)?
ESI er et opmærkningssprog, der lader en cachelagret side indeholde pladsholder-tags til dynamiske fragmenter, som CDN-kanten henter og erstatter, før svaret returneres. Dette gør det muligt for en side at blive cachelagret fuldt ud, mens små personlige regioner - en vogntælling, en brugerhilsen - samles pr. besøgende, hver med sine egne uafhængige cacheregler.
Hvornår skal jeg bruge ESI i stedet for en klienthentning?
Brug ESI, når fragmentet påvirker layout eller skal være synligt for crawlere, da ESI-indhold er til stede i HTML, der når frem til browseren og ikke forårsager layoutskift eller yderligere rundtur. Brug en klientsidehentning til små detaljer, der ikke påvirker layoutet, hvor enkelheden i almindelig frontend-kode opvejer fordelen, og en sen ankomst er harmløs.
Sætter ESI tempoet ned for sideleveringen?
Det kan den, fordi fragmenter samles før svaret sendes, så siden kun er så hurtig som dens langsomste fragment. Et fragmentendepunkt, der hænger, forsinker en side, der ellers var et cachehit. Konfigurer altid en kort timeout pr. fragment sammen med tilbagefaldsindhold, så et svigtende fragment forringes yndefuldt i stedet for at blokere hele svaret.
Kan forskellige dele af en side have forskellige cachetider med ESI?
Ja, og det er dens største fordel. Sideskallen kan være cachelagret i en dag, et trending-produktfragment i tres sekunder og delt mellem alle besøgende, og et vognfragment ikke cachelagret overhovedet. Kanten samler dem i et enkelt HTML-svar, så ét dokument kombinerer flere cachestrategier.
Rammen værd at holde: ESI er ikke en caching teknologi så meget som en samling en. Det giver dig mulighed for at stoppe med at behandle en side som en enkelt cachebar enhed og begynde at behandle den som flere - hvilket normalt er en meget mere præcis beskrivelse af, hvad siden faktisk er.
Se, hvordan NordicCDN gør dette for dit websted:
Mads har arbejdet med IT – mest som vært – siden han var 16. Han tog tidligt ejerskab i en SaaS-virksomhed og var med til at udvide den til Visma, har opbygget og drevet datacenternetværk og fungeret som CTO for et dansk datacenter. Han startede NordicCDN for at gøre hurtig og sikker infrastruktur enkel at bruge.
