Mei en sûnder Durable Cache

[asikurrahmanshuvo]

Fansels, kommunikaasje tusken de râne knooppunt en dat oarsprong incurs wat tafoege latency, mar dy latency wurdt goed kontrolearre en kontrolearre troch ús. Wat bart der lykwols as dy oarsprongsoprop eins in serverless funksje opropt om in side te werjaan of in API-antwurd werom te jaan?

Yn dat gefal binne d'r folle mear faktoaren dy't bydrage oan tafoege latency: kâlde starts, rendering fan prestaasjes fan 'e eigen koade fan' e side, API-oproppen fan tredden (dy't har eigen latency, quota's, ensfh.) bringe. Allinich in subset fan dizze faktoaren is ûnder Netlify's kontrôle.

As elk râneknooppunt serverleaze funksjes soe winkel oproppe foar elke dynamyske ynhâld dy't it net lokaal yn 'e cache hat, betsjut dat potensjeel in protte funksje-oanroppen - elk hat syn eigen latency plus mooglik fertraging fan oare tagelyk fersiken. De measte fan dizze oproppen soene oerstallich wêze en koenen wurde optimalisearre fuort mei in tuskenlizzende cachingfunksje.

Duorsume Cache is krekt dat meganisme.

It hâldt cacheable antwurden fan serverless funksjes op in tuskenlizzende laach, sadat alle râne knopen kinne diele deselde cached ynhâld.

Derneist, as jo in webside mei hege ferkear revalidearje dy't markearre is stale-while-revalidate, soe it meganisme alle tagelyk fersiken deduplikearje nei dy side dy't daliks folgje, en de nije side mar ien kear generearje.


It markearjen fan in opjûne funksje-antwurd om te wurde opslein yn 'e Durable Cache is no opt-in fia in nije rjochtline yn' e cache-controlantwurdkop, passende namme durable( sjoch dokuminten ). De funksje is no beskikber, foar alle plannen, sûnder ekstra kosten.

Jo kinne dizze nije rjochtline hjoed brûke mei kaders lykas Astro en Remix , en wy rôlje stadichoan out-of-the-box gebrûk fan it binnen ús Next.js Runtime v5 .

De folgjende grins
Snelle, personaliseare ynhâld op oanfraach bouwe wurdt ek net allinich oplost troch ferbetterings yn caching op platfoarmnivo.