ISR — oldindan yaratilgan statik web sahifalarni butun saytni qayta build va deploy qilmasdan, deploymentdan keyin bosqichma-bosqich yangilash usuli. To‘liq nomi Incremental Static Regeneration.
ISR static generationning tez response va CDN afzalliklarini saqlab, content freshness muammosini kamaytirishga qaratilgan.
Asosiy model
Sahifa dastlab static HTML sifatida yaratiladi.
Keyin ma’lum vaqt yoki eventdan so‘ng:
- eski page hali xizmat qiladi;
- background regeneration boshlanadi;
- yangi HTML yaratiladi;
- muvaffaqiyatli bo‘lsa cache almashtiriladi;
- keyingi user yangi versiyani oladi.
Aniq lifecycle frameworkga bog‘liq.
Revalidation interval
Route uchun yangilanish intervali berilishi mumkin.
Masalan:
60 soniyadan keyin qayta tekshirish mumkin
Bu har 60 soniyada majburiy build degani bo‘lmasligi mumkin.
Ko‘p implementationda interval tugagandan keyingi request regenerationni boshlaydi.
Stale-while-revalidate
Userga eski, ammo ishlaydigan sahifa darhol qaytariladi.
Backgroundda yangi page yaratiladi.
Bu latency’ni past saqlaydi.
Evaziga qisqa muddat eskirgan content ko‘rinishi mumkin.
Blocking regeneration
Ba’zi rejimda stale page mavjud bo‘lmasa birinchi request yangi render tugashini kutadi.
Keyingi requestlar cache’dan oladi.
Bu yangi route yoki fallback page uchun qo‘llanishi mumkin.
Timeout va concurrent request boshqaruvi zarur.
On-demand revalidation
CMS yoki backend content o‘zgarganda webhook aniq route’ni yangilashga trigger beradi.
Masalan:
maqola publish
→ /posts/slug revalidate
Bu fixed intervaldan tezroq freshness beradi.
Webhook authenticated va replay’dan himoyalangan bo‘ladi.
Cache key
Regenerated page qaysi variantga tegishli ekanini cache key belgilaydi.
Public page uchun route yetarli bo‘lishi mumkin.
Language, region yoki query bo‘yicha variantlar mavjud bo‘lsa key ularni qamrab oladi.
User-specific cookie’ni static cache bilan aralashtirish data leak yaratishi mumkin.
Regeneration lock
Bir xil page uchun ko‘p request bir vaqtda regeneration boshlamasligi kerak.
Distributed lock yoki platform ichki deduplication ishlatiladi.
Aks holda backendga ko‘p bir xil build requestlari yuboriladi.
Bu thundering herd muammosiga olib kelishi mumkin.
Failure
Yangi page yaratish xato bersa eski static versiya xizmat qilishda davom etishi mumkin.
Bu availabilityni saqlaydi.
Platforma:
bilan ishlaydi.
Eski content cheksiz qolib ketmasligi kerak.
Data dependency
Page bir nechta API yoki CMS queryga bog‘liq bo‘lishi mumkin.
Qaysi data o‘zgarganda qaysi route invalidatsiya qilinishi dependency graphga bog‘liq.
Masalan, product narxi:
- product page;
- category page;
- search page;
- sitemap
ni yangilashi mumkin.
Dynamic route
Build vaqtida mavjud bo‘lmagan yangi slug birinchi requestda yaratilishi mumkin.
Variantlar:
Yangi route enumeration va authorization muammolari hisobga olinadi.
CDN tarqatish
Regenerated output edge cache’larga tarqatiladi.
Barcha region bir vaqtda yangi versiyani olmasligi mumkin.
Short consistency window mavjud.
Content version yoki timestamp debuggingga yordam beradi.
ISR va SSG
SSG barcha static page’larni build yoki deploy vaqtida yaratadi.
ISR ularni keyinchalik selective yangilaydi.
Katta katalogda har o‘zgarish uchun to‘liq rebuild zarurati kamayadi.
ISR va SSR
SSR har requestda yangi render qilishi mumkin.
ISR esa ko‘p requestga bir xil cached static output qaytaradi.
Freshness real-time bo‘lishi shart bo‘lmagan sahifalar uchun ISR server loadini kamaytiradi.
Personalization
ISR output umumiy public content uchun mos.
User nomi, account ma’lumoti yoki maxfiy data static regeneration ichiga kiritilmaydi.
Personalized component client API yoki alohida SSR orqali olinadi.
Preview va draft
Draft content public ISR cache’ga tushmasligi kerak.
Preview route:
- authentication;
- no-store;
- alohida domain;
- SSR
bilan ishlashi mumkin.
Publish webhook public page’ni revalidate qiladi.
Cache invalidation
Content delete qilinganda eski page cache’da qolishi mumkin.
On-demand purge yoki yangi 404 output yaratish zarur.
Redirect va slug o‘zgarishi ham eski URLning lifecycle’ini talab qiladi.
Monitoring
Kuzatiladi:
- cache hit;
- page yoshi;
- regeneration latency;
- error;
- stale davomiyligi;
- webhook failure;
- route soni;
- build resource.
User ko‘rayotgan versionni response header yoki metadata orqali aniqlash mumkin.
Tag-based invalidation
Bir nechta route bir xil data manbasiga bog‘liq bo‘lsa cache entrylarga tag berilishi mumkin. Product o‘zgarganda shu tagga tegishli barcha page’lar invalidatsiya qilinadi. Bu route’larni qo‘lda to‘liq sanashni kamaytiradi.
Cold route
Kam kiriladigan route revalidation intervali tugagan bo‘lsa ham yangi request kelmaguncha eski holatda qolishi mumkin. On-demand trigger yoki scheduled regeneration bunday sahifalarni yangilaydi.
Deployment bilan aloqa
Yangi application release eski generated page’larning formatiga mos bo‘lishi kerak. Schema yoki component markup keskin o‘zgarsa cache versioni almashtiriladi va zarur route’lar qayta yaratiladi.
Content timestamp
Page ichida ma’lumotning oxirgi yangilangan vaqti ko‘rsatilishi mumkin. Bu user va supportga cache’dagi versiya qanchalik yangi ekanini tushunishga yordam beradi. Timestamp render va data source vaqtini adashtirmaydi.
Manual purge
Noto‘g‘ri content chiqsa operator ma’lum route yoki tag cache’ini darhol tozalashi mumkin. Purge hodisasi audit qilinadi.
Bog‘liq tushunchalar
Incremental Static Regeneration, Static Site Generation, Revalidation, Stale-while-revalidate, Cache invalidation, CDN, SSR, Static page, Webhook, Dynamic route