Next.js papildomoji statinė regeneracija: dinamiškos statinės svetainės pasaulinei auditorijai

Nuolat besikeičiančiame interneto svetainių kūrimo pasaulyje, užtikrinti žaibišką vartotojo patirtį, išlaikant turinį naują ir dinamišką, yra pagrindinis iššūkis. Tradicinis statinis svetainių generavimas (SSG) siūlo neįtikėtiną našumą, tačiau dažnai susiduria su sunkumais, kai reikia pritaikyti dažnai atnaujinamą turinį. Priešingai, atvaizdavimas serverio pusėje (SSR) suteikia dinamiškumo, tačiau gali sukelti delsą. Next.js, pirmaujanti React karkaso sistema, elegantiškai užpildo šią spragą su savo inovatyvia funkcija: papildomąja statine regeneracija (ISR). Šis galingas mechanizmas leidžia kūrėjams kurti statines svetaines, kurios atrodo dinamiškos, suteikdamos geriausias abiejų pasaulių savybes pasaulinei auditorijai.

Dinamiškų statinių svetainių poreikio supratimas

Dešimtmečius svetainės veikė spektre tarp visiškai statinių ir visiškai dinamiškų. Statinis svetainių generavimas (SSG) iš anksto sugeneruoja kiekvieną puslapį kūrimo metu (build time), todėl pasiekiamas neįtikėtinai greitas įkėlimo laikas ir puikus SEO. Tačiau turiniui, kuris dažnai keičiasi – pavyzdžiui, naujienų straipsniams, elektroninės komercijos produktų atnaujinimams ar socialinių tinklų srautams – SSG reikalauja pilno svetainės perrinkimo ir pakartotinio įdiegimo kiekvieną kartą, kai atnaujinamas turinys, o tai dažnai yra nepraktiška ir atima daug laiko. Šis apribojimas daro SSG netinkamu daugeliui realaus pasaulio programų, kurioms reikalingas turinys realiuoju arba beveik realiuoju laiku.

Kita vertus, atvaizdavimas serverio pusėje (SSR) atvaizduoja puslapius serveryje kiekvienai užklausai. Nors tai užtikrina, kad turinys visada yra naujausias, tai padidina serverio apkrovą ir gali lemti lėtesnį pradinį puslapių įkėlimą, kol serveris apdoroja užklausą. Pasaulinei auditorijai, išsidėsčiusiai įvairiose geografinėse vietovėse ir su skirtingomis tinklo sąlygomis, SSR gali padidinti našumo skirtumus.

Idealus scenarijus daugeliui šiuolaikinių interneto programų yra svetainė, kuri išnaudoja statinių failų našumo pranašumus, bet taip pat gali atspindėti naujausią informaciją, kai tik ji atsiranda. Būtent čia ir atsiskleidžia Next.js papildomoji statinė regeneracija.

Kas yra papildomoji statinė regeneracija (ISR)?

Papildomoji statinė regeneracija (ISR) yra Next.js funkcija, leidžianti atnaujinti statinius puslapius po to, kai svetainė buvo sukurta ir įdiegta. Skirtingai nuo tradicinio SSG, kuris reikalauja pilno perrinkimo, kad atspindėtų turinio pakeitimus, ISR leidžia fone regeneruoti atskirus puslapius, netrikdant vartotojo patirties ar nereikalaujant visiško svetainės pakartotinio įdiegimo. Tai pasiekiama naudojant galingą pakartotinio patvirtinimo (revalidation) mechanizmą.

Kai puslapis generuojamas su ISR, Next.js pateikia statinį HTML failą. Kai vartotojas paprašo to puslapio po tam tikro laiko, Next.js gali tyliai fone regeneruoti puslapį. Pirmasis vartotojas, paprašęs puslapio po pakartotinio patvirtinimo laikotarpio, gali gauti seną, podėlyje esančią (cached) versiją, o vėlesni vartotojai gaus naujai sugeneruotą, atnaujintą versiją. Šis procesas užtikrina, kad jūsų svetainė išliks našia daugumai vartotojų, palaipsniui atnaujinant turinį.

Kaip veikia ISR: pakartotinio patvirtinimo (revalidation) mechanizmas

ISR esmė slypi jo pakartotinio patvirtinimo (revalidation) funkcijoje. Kai apibrėžiate puslapį su ISR, nurodote revalidate laiką (sekundėmis). Šis laikas nustato, kaip dažnai Next.js turėtų bandyti fone regeneruoti tą konkretų puslapį.

Išnagrinėkime procesą žingsnis po žingsnio:

1. Kūrimo laikas (Build Time): Puslapis yra statiškai sugeneruojamas kūrimo metu, kaip ir įprasto SSG atveju.
2. Pirmoji užklausa: Vartotojas paprašo puslapio. Next.js pateikia statiškai sugeneruotą HTML failą.
3. Podėlio galiojimo pabaiga: Praėjus nurodytam revalidate laikotarpiui, puslapio podėlis laikomas pasenusiu.
4. Sekanti užklausa (pasenęs podėlis): Kitas vartotojas, kuris paprašo puslapio pasibaigus podėlio galiojimui, gauna *pasenusią*, bet vis dar podėlyje esančią puslapio versiją. Tai yra svarbu siekiant išlaikyti našumą.
5. Foninis pakartotinis patvirtinimas: Tuo pačiu metu Next.js inicijuoja foninę puslapio regeneraciją. Tai apima naujausių duomenų gavimą ir puslapio pergeneravimą.
6. Podėlio atnaujinimas: Kai foninė regeneracija baigta, nauja, atnaujinta puslapio versija pakeičia pasenusią podėlyje.
7. Kita užklausa: Kitas vartotojas, paprašęs puslapio, gaus naujai sugeneruotą, atnaujintą versiją.

Šis laipsniškas atnaujinimo procesas užtikrina, kad jūsų svetainė išliks labai prieinama ir našia, net kai turinys yra atnaujinamas.

Pagrindinės sąvokos:

• revalidate: Tai pagrindinis parametras, naudojamas getStaticProps funkcijoje, norint įjungti ISR. Jis priima skaičių, reiškiantį sekundes.
• Stale-While-Revalidate: Tai pagrindinė podėlio strategija. Vartotojas nedelsiant gauna pasenusį (podėlyje esantį) turinį, kol fone generuojamas naujas turinys.

ISR diegimas Next.js

ISR diegimas jūsų Next.js programoje yra paprastas. Paprastai jį konfigūruojate savo getStaticProps funkcijoje.

Pavyzdys: tinklaraščio įrašas su dažnais atnaujinimais

Įsivaizduokite tinklaraštį, kuriame įrašai gali būti atnaujinami su nedidelėmis pataisomis ar nauja informacija. Norite, kad šie atnaujinimai atsispindėtų santykinai greitai, bet nebūtinai akimirksniu kiekvienam vartotojui.

Štai kaip konfigūruotumėte ISR tinklaraščio įrašo puslapiui:

// pages/posts/[slug].js

import { useRouter } from 'next/router'

export async function getStaticPaths() {
  // Gaunami visi įrašų „slug“ (url dalys), kad juos iš anksto sugeneruoti kūrimo metu
  const posts = await fetch('https://your-api.com/posts').then(res => res.json());

  const paths = posts.map((post) => ({
    params: { slug: post.slug },
  }));

  return {
    paths,
    fallback: 'blocking', // arba true, arba false, priklausomai nuo jūsų poreikių
  };
}

export async function getStaticProps({ params }) {
  // Gaunami konkretaus įrašo duomenys pagal esamą „slug“
  const post = await fetch(`https://your-api.com/posts/${params.slug}`).then(res => res.json());

  return {
    props: {
      post,
    },
    // Įjungiamas ISR: pakartotinai patvirtinti šį puslapį kas 60 sekundžių
    revalidate: 60, // Sekundėmis
  };
}

function PostPage({ post }) {
  const router = useRouter();

  // Jei puslapis dar nesugeneruotas, bus rodoma tai
  if (router.isFallback) {
    return 
Kraunasi...
;
  }

  return (
    

      
{post.title}
      
{post.content}
      {/* Kitos įrašo detalės */}
    
  );
}

export default PostPage;

Šiame pavyzdyje:

• getStaticPaths naudojama iš anksto sugeneruoti kelių rinkinį (tinklaraščio įrašų „slug“) kūrimo metu.
• getStaticProps gauna duomenis konkrečiam įrašui ir, svarbiausia, nustato revalidate: 60 savybę. Tai nurodo Next.js regeneruoti šį puslapį fone kas 60 sekundžių.
• fallback: 'blocking' užtikrina, kad jei vartotojas paprašys kelio, kuris nebuvo iš anksto sugeneruotas kūrimo metu, serveris palauks, kol sugeneruos puslapį (serveryje), ir tada jį pateiks. Tai dažnai naudojama su ISR.

`fallback` supratimas su ISR

fallback parinktis getStaticPaths funkcijoje atlieka lemiamą vaidmenį naudojant ISR:

• fallback: false: Keliai, negrąžinti iš getStaticPaths, parodys 404 klaidą. Tai naudinga svetainėms, kuriose visi dinaminiai maršrutai yra žinomi kūrimo metu.
• fallback: true: Keliai, negrąžinti iš getStaticPaths, pirmiausia bus bandomi generuoti kliento pusėje (rodant įkėlimo būseną). Po generavimo puslapis yra išsaugomas podėlyje. Tai gali būti gerai našumui, jei turite daug dinaminių maršrutų.
• fallback: 'blocking': Keliai, negrąžinti iš getStaticPaths, bus atvaizduojami serveryje per pirmąją užklausą. Tai reiškia, kad vartotojas lauks, kol puslapis bus sugeneruotas. Vėlesnės užklausos pateiks podėlyje esantį statinį puslapį, kol jis bus pakartotinai patvirtintas. Tai dažnai yra pageidaujama parinktis su ISR, nes ji užtikrina, kad po pirmosios užklausos visada bus pateikiamas statinis failas, išlaikant našumą.

Naudojant ISR, fallback: 'blocking' arba fallback: true paprastai yra tinkamesni, leidžiantys pagal poreikį generuoti naujus dinamiškus maršrutus, kurie vėliau gali pasinaudoti ISR privalumais.

ISR privalumai pasaulinei auditorijai

ISR privalumai ypač išryškėja dirbant su pasauline auditorija:

1. Pagerintas našumas visuose geografiniuose regionuose

Pateikdama iš anksto sugeneruotus statinius failus, ISR užtikrina, kad vartotojai, nepriklausomai nuo jų buvimo vietos, patirtų greitą įkėlimo laiką. „Stale-while-revalidate“ strategija reiškia, kad net ir turinio atnaujinimo metu dauguma vartotojų vis tiek gaus podėlyje esančius, greitai įkeliamus puslapius, sumažinant tinklo delsos ir serverio apdorojimo laiko poveikį. Tai yra labai svarbu siekiant išlaikyti vartotojų įsitraukimą regionuose su mažiau patikima interneto infrastruktūra.

2. Beveik realaus laiko turinys be SSR pridėtinių išlaidų

Turiniui, kurį reikia dažnai atnaujinti, bet nereikia absoliutaus realaus laiko tikslumo (pvz., akcijų kainos, naujienų srautai, produktų prieinamumas), ISR siūlo puikų kompromisą. Galite nustatyti trumpą pakartotinio patvirtinimo laikotarpį (pvz., 30-60 sekundžių), kad pasiektumėte beveik realaus laiko atnaujinimus be mastelio keitimo ir našumo problemų, susijusių su nuolatiniu SSR.

3. Sumažinta serverio apkrova ir išlaidos

Kadangi puslapiai pirmiausia pateikiami iš CDN (turinio pristatymo tinklo) arba statinių failų talpyklos, jūsų pagrindinių serverių apkrova yra žymiai sumažinama. ISR inicijuoja regeneraciją serverio pusėje tik pakartotinio patvirtinimo laikotarpiu, todėl sumažėja prieglobos išlaidos ir pagerėja mastelio keitimas. Tai yra didelis privalumas programoms, kurios patiria didelį srautą iš įvairių pasaulio vietų.

4. Pagerintos SEO pozicijos

Paieškos sistemų robotai teikia pirmenybę greitai įkeliamoms svetainėms. ISR gebėjimas greitai ir efektyviai pateikti statinius išteklius teigiamai prisideda prie SEO. Be to, išlaikydama turinį naują, ISR padeda paieškos sistemoms indeksuoti jūsų naujausią informaciją, pagerindama jūsų matomumą pasaulinei auditorijai.

5. Supaprastintas turinio valdymas

Turinio kūrėjai ir administratoriai gali atnaujinti turinį, nereikalaujant pilno svetainės perrinkimo. Kai turinys atnaujinamas jūsų TVS (turinio valdymo sistemoje) ir jį gauna ISR procesas, pakeitimai atsispindės svetainėje po kito pakartotinio patvirtinimo ciklo. Tai supaprastina turinio publikavimo darbo eigą.

Kada naudoti ISR (ir kada ne)

ISR yra galingas įrankis, tačiau, kaip ir bet kurią technologiją, geriausia jį naudoti tinkamame kontekste.

Idealūs ISR naudojimo atvejai:

• Elektroninės komercijos produktų puslapiai: Rodoma produktų informacija, kainos ir prieinamumas, kurie gali keistis per dieną.
• Naujienų ir straipsnių svetainės: Straipsnių atnaujinimas su naujausiomis žiniomis ar nedideliais redagavimais.
• Tinklaraščio įrašai: Leidžia atnaujinti turinį ir taisyti klaidas be pilno pakartotinio įdiegimo.
• Renginių sąrašai: Renginių tvarkaraščių, vietų ar prieinamumo atnaujinimas.
• Komandos puslapiai ar katalogai: Naujausių personalo pokyčių atspindėjimas.
• Prietaisų skydelio valdikliai: Dažnai atnaujinamų duomenų rodymas, kuriems nereikia milisekundžių tikslumo.
• Dokumentacijos svetainės: Dokumentacijos atnaujinimas, kai išleidžiamos naujos funkcijos ar pataisymai.

Kada ISR gali būti ne pats geriausias pasirinkimas:

• Labai personalizuotas turinys: Jei kiekvienas vartotojas mato unikalų turinį pagal savo profilį ar sesiją, SSR arba duomenų gavimas kliento pusėje gali būti tinkamesnis. ISR geriausiai tinka turiniui, kuris iš esmės yra vienodas visiems vartotojams, bet reikalauja periodinių atnaujinimų.
• Milisekundžių tikslumo duomenys: Programoms, kurioms reikalingi absoliutūs realaus laiko duomenys (pvz., gyvos akcijų biržos diagramos, realaus laiko kainų siūlymo sistemos), ISR pakartotinio patvirtinimo laikotarpis gali sukelti nepriimtiną delsą. Tokiais atvejais „WebSockets“ arba „Server-Sent Events“ (SSE) gali būti tinkamesni.
• Turinys, kuris niekada nesikeičia: Jei jūsų turinys yra statinis ir niekada nereikalauja atnaujinimų po kūrimo laiko, tradicinis SSG yra pakankamas ir paprastesnis.

Pažangios ISR strategijos ir aspektai

Nors pagrindinis ISR diegimas yra paprastas, yra pažangių strategijų ir aspektų, kaip optimizuoti jo naudojimą, ypač pasaulinei auditorijai.

1. Podėlio anuliavimo strategijos (ne tik laiku pagrįstos)

Nors laiku pagrįstas pakartotinis patvirtinimas yra numatytasis ir labiausiai paplitęs metodas, Next.js siūlo būdus, kaip programiškai inicijuoti pakartotinį patvirtinimą. Tai yra neįkainojama, kai norite, kad turinys būtų atnaujintas iškart, kai įvyksta tam tikras įvykis (pvz., TVS „webhook“ inicijuoja atnaujinimą).

Galite naudoti res.revalidate(path) funkciją be-serverinėje funkcijoje (serverless function) ar API maršrute, kad rankiniu būdu pakartotinai patvirtintumėte konkretų puslapį.

// pages/api/revalidate.js

export default async function handler(req, res) {
  // Patikrinkite slaptą prieigos raktą, kad užtikrintumėte, jog tik autorizuotos užklausos gali pakartotinai patvirtinti
  if (req.query.secret !== process.env.REVALIDATE_SECRET) {
    return res.status(401).json({ message: 'Neteisingas prieigos raktas' });
  }

  try {
    // Pakartotinai patvirtinkite konkretų įrašo puslapį
    await res.revalidate('/posts/my-updated-post');
    return res.json({ revalidated: true });
  } catch (err) {
    // Jei įvyko klaida, Next.js ir toliau teiks pasenusį puslapį
    return res.status(500).send('Klaida pakartotinai tvirtinant');
  }
}

Šį API maršrutą gali iškviesti jūsų TVS ar kita tarnyba, kai tik pasikeičia turinys, susijęs su /posts/my-updated-post.

2. Dinaminiai maršrutai ir `fallback` praktikoje

Pasirinkti tinkamą fallback parinktį yra labai svarbu:

• Tinklaraščiams su nuspėjamu įrašų skaičiumi, paskelbtu kūrimo metu, fallback: false gali pakakti, bet tada nauji įrašai nebus pasiekiami iki kito perrinkimo.
• Jei tikitės, kad reguliariai bus pridedama daug naujų įrašų ar produktų, su ISR paprastai pageidautina naudoti fallback: 'blocking'. Tai užtikrina, kad nauji puslapiai būtų generuojami pagal poreikį, būtų visiškai statiški po pirmosios užklausos, o vėliau pasinaudotų ISR privalumais vėlesniems atnaujinimams.

3. Tinkamo pakartotinio patvirtinimo laiko pasirinkimas

revalidate laikas turėtų būti balansas:

• Trumpesni laikai (pvz., 10-60 sekundžių): Tinka turiniui, kuris keičiasi labai dažnai, pavyzdžiui, gyviems rezultatams ar produktų atsargų lygiams. Būkite atidūs dėl padidėjusios serverio apkrovos ir API užklausų išlaidų.
• Ilgesni laikai (pvz., 300-3600 sekundžių, arba 5-60 minučių): Idealus turiniui, kuris atnaujinamas rečiau, pavyzdžiui, tinklaraščio įrašams ar naujienų straipsniams. Tai maksimaliai išnaudoja statinio podėlio privalumus.

Nustatydami šią reikšmę, atsižvelkite į savo auditorijos toleranciją pasenusiam turiniui ir jūsų duomenų atnaujinimo dažnumą.

4. Integracija su „Headless“ TVS

ISR puikiai veikia su „headless“ turinio valdymo sistemomis (TVS), tokiomis kaip Contentful, Strapi, Sanity ar WordPress (su jo REST API). Jūsų „headless“ TVS gali inicijuoti „webhook'us“, kai turinys yra publikuojamas ar atnaujinamas, kurie tada gali iškviesti jūsų Next.js API maršrutą (kaip parodyta aukščiau), kad pakartotinai patvirtintų paveiktus puslapius. Tai sukuria tvirtą, automatizuotą darbo eigą dinamiškam statiniam turiniui.

5. CDN podėlio elgsena

Next.js ISR veikia kartu su jūsų CDN. Kai puslapis yra sugeneruotas, jis paprastai pateikiamas iš CDN. revalidate laikas įtakoja, kada CDN krašto serveriai laiko podėlį pasenusiu. Jei naudojate valdomą platformą, tokią kaip Vercel ar Netlify, jos didžiąja dalimi sklandžiai tvarko šią integraciją. Individualiems CDN nustatymams užtikrinkite, kad jūsų CDN yra sukonfigūruotas atsižvelgti į Next.js podėlio antraštes.

Pasauliniai pavyzdžiai ir geriausios praktikos

Pažvelkime, kaip ISR gali būti taikomas pasauliniame kontekste:

• Pasaulinis naujienų agregatorius: Įsivaizduokite svetainę, kuri agreguoja naujienas iš įvairių tarptautinių šaltinių. ISR gali užtikrinti, kad antraštės ir straipsnių santraukos būtų atnaujinamos kas kelias minutes, suteikiant vartotojams visame pasaulyje naujausią informaciją, neperkraunant serverių. revalidate laikas galėtų būti nustatytas į 300 sekundžių.
• Tarptautinė elektroninės komercijos platforma: Internetinė parduotuvė, parduodanti produktus visame pasaulyje, galėtų naudoti ISR produktų puslapiams. Kai produkto atsargų lygis ar kaina atnaujinama (galbūt paveikta regioninio prieinamumo ar valiutų svyravimų), ISR gali užtikrinti, kad šie pakeitimai atsispindėtų visoje svetainėje per kelias minutes, su revalidate nustatytu į 60 sekundžių.
• Daugiakalbės turinio svetainės: Svetainėms, kurios siūlo turinį keliomis kalbomis, kiekviena išversta versija gali pasinaudoti ISR. Jei atnaujinama pagrindinė turinio dalis, visos lokalizuotos versijos gali būti pakartotinai patvirtintos asinchroniškai.
• Bilietų pardavimas pasauliniams renginiams: Dideliems tarptautiniams renginiams vietų prieinamumas ar renginių tvarkaraščiai gali dažnai keistis. ISR gali išlaikyti šiuos puslapius atnaujintus, pateikdamas statinį, greitą turinį vartotojams, perkantiems bilietus iš skirtingų laiko juostų.

Pagrindinės pasaulinės geriausios praktikos:

• Atsižvelkite į laiko juostas pakartotinai tvirtinant: Nors revalidate yra fiksuota trukmė, atsižvelkite į tai, kada vyksta jūsų pagrindiniai turinio atnaujinimai. Pakartotinio patvirtinimo derinimas su didžiausio turinio atnaujinimo laikais gali būti naudingas.
• Testuokite našumą iš įvairių regionų: Naudokite įrankius, tokius kaip Google PageSpeed Insights ar WebPageTest, kad patikrintumėte savo svetainės našumą iš skirtingų geografinių vietovių.
• Stebėkite API naudojimą ir išlaidas: Jei jūsų ISR priklauso nuo išorinių API, stebėkite jų naudojimą ir užtikrinkite, kad neviršijate užklausų limitų ar nepatiriate netikėtų išlaidų dėl dažno pakartotinio patvirtinimo.
• Naudokite pasaulinį CDN: Išnaudokite turinio pristatymo tinklą su plačiu pasauliniu buvimu, kad užtikrintumėte, jog jūsų statiniai ištekliai būtų pateikiami iš vietų, esančių arti jūsų vartotojų.

Dažniausios klaidos ir kaip jų išvengti

Nors ISR yra galingas, jis gali sukelti netikėtą elgesį, jei nebus įdiegtas atsargiai:

• Per daug agresyvus pakartotinis patvirtinimas: Nustačius revalidate į labai mažas reikšmes (pvz., 1 sekundę), galima panaikinti statinio generavimo privalumus ir per daug apkrauti jūsų duomenų šaltinius bei serverius, iš esmės veikiant kaip SSR, bet su galimai mažiau nuspėjamu pateikimo mechanizmu.
• `fallback` būsenų ignoravimas: Netinkamai tvarkant `router.isFallback` būseną, gali sugesti vartotojo patirtis, kai generuojami nauji dinaminiai maršrutai.
• Podėlio anuliavimo logikos klaidos: Jei jūsų programinė podėlio anuliavimo logika yra klaidinga, jūsų turinys gali pasenti ir niekada neatsinaujinti, arba jis gali atsinaujinti neteisingai. Kruopščiai testuokite savo pakartotinio patvirtinimo API maršrutus.
• Duomenų gavimo klaidos: Jei getStaticProps nepavyksta gauti duomenų pakartotinio patvirtinimo metu, ir toliau bus pateikiami seni duomenys. Įdiekite patikimą klaidų tvarkymą ir registravimą savo duomenų gavimo funkcijose.
• `getStaticPaths` pamiršimas: Jei naudojate dinaminius maršrutus su ISR, jūs *privalote* eksportuoti `getStaticPaths`, kad nurodytumėte Next.js, kuriuos kelius iš anksto sugeneruoti ir kaip tvarkyti nežinomus kelius.

Išvada: dinamiško statinio turinio ateitis

Next.js papildomoji statinė regeneracija yra reikšmingas žingsnis kuriant modernias, našias interneto programas. Ji suteikia kūrėjams galimybę pateikti dinamišką, naujausią turinį su statinių svetainių greičiu ir masteliu, todėl tai yra idealus sprendimas pasaulinei auditorijai, turinčiai įvairių poreikių ir lūkesčių.

Suprasdami, kaip veikia ISR ir kokie yra jo privalumai, galite kurti svetaines, kurios yra ne tik greitos, bet ir protingai reaguoja į besikeičiančią informaciją. Nesvarbu, ar kuriate elektroninės komercijos platformą, naujienų portalą, ar bet kokią svetainę su dažnai atnaujinamu turiniu, ISR pritaikymas leis jums išlikti priekyje, džiuginti savo vartotojus visame pasaulyje ir optimizuoti savo kūrimo bei prieglobos išteklius.

Kadangi internetas ir toliau reikalauja greitesnio įkėlimo laiko ir dinamiškesnio turinio, papildomoji statinė regeneracija išsiskiria kaip pagrindinė strategija kuriant naujos kartos svetaines. Ištirkite jos galimybes, eksperimentuokite su skirtingais pakartotinio patvirtinimo laikais ir atskleiskite tikrąjį dinamiškų statinių svetainių potencialą savo pasauliniams projektams.