Headless WordPress, ISR eller SSR: velg renderingsmodus etter hvor ofte innholdet endres
Spørsmålet “ISR eller SSR” gir bare mening per rute. Det finnes ikke ett svar for hele nettstedet. Astro og Next.js lar deg velge modus på side- eller layoutnivå, og det erfarne valget er å bestemme seg bevisst, rute for rute, ut fra en modell av hvor ofte innholdet endres.
Denne artikkelen hører til tjenesten headless WordPress og hører sammen med beslutningsmatrisen Next.js eller Astro, som tar for seg valget på rammeverksnivå.
Kort fortalt
- ISR (eller statisk med revalidering) vinner når endringstakten er forutsigbar og trafikken høy.
- SSR vinner når siden er personalisert, styrt av økten eller inneholder sanntidsdata.
- Cache-invalidering avgjør om ISR blir riktig; webhooks slår tidsbasert revalidering.
- Cloudflare Workers kjører begge; ISR bruker nesten ingen CPU, SSR betaler hele renderingen.
- Standard er den billigste modusen som gir riktig resultat; gå over til SSR bare når det trengs.
SSG, ISR og SSR forklart for WordPress
Statisk generering (SSG). Siden bygges én gang, ved byggetid, og serveres som ren HTML. Billigst per forespørsel, tregest å oppdatere.
Incremental Static Regeneration (ISR). Siden bygges én gang, men kan regenereres når noe utløser det, vanligvis en webhook ved publisering eller et tidsbasert revalideringsintervall. Billig per forespørsel, endelig konsistens ved oppdatering.
Server-Side Rendering (SSR). Siden rendres ved hver forespørsel. Alltid fersk, men driftskostnaden vokser med trafikken. Personalisering, autentisering og sanntidsdata hører naturlig hjemme her.
I headless WordPress leser alle tre fra WordPress-originen via REST eller GraphQL. Forskjellen er når de leser.
Når bør du bruke ISR og når SSR i headless WordPress
To faktorer teller:
Endringstakt. Hvor ofte endres denne siden? Én gang i kvartalet, én gang om dagen, hvert minutt, i sanntid?
Personaliseringsflate. Er siden forskjellig fra besøkende til besøkende? Innlogget status, priser etter sted, variant i en A/B-test.
Regelen: velg den billigste modusen som gir riktig resultat. Statisk er billigst. SSR er dyrest. Gå mot SSR bare når en billigere modus ikke gir riktig resultat.
| Sidetype | Standardmodus | Hvorfor |
|---|---|---|
| Markedsføringssider, blogginnlegg | Statisk (ombygging ved publisering) | Lav endringstakt, ingen personalisering |
| Kategori- og taggarkiver | ISR med publiseringswebhook | Takten følger publisering av innhold |
| Produktsider, stabil katalog | ISR med lagerwebhook | Forutsigbar invalidering |
| Produktsider, lager i sanntid | SSR med edge-cache | Lageret endres i løpet av sekunder |
| Handlekurv og kasse | SSR | Styrt av økten per definisjon |
| Innlogget dashbord | SSR | Tilstand per bruker |
| Redaksjonell forside | ISR med publiseringswebhook | Takten følger publiseringshendelser |
ISR-cache-invalidering med webhooks fra WordPress
ISR virker gratis helt til det serverer en utdatert kanonisk URL etter en slug-endring. Mønsteret som hindrer det:
Webhook-styrt invalidering. WordPress sender en webhook ved publisering, slug-endring eller sletting av innlegg. Frontend-rammeverket tar imot webhooken og utløser regenerering av sidene som berøres. Kostnaden er én webhook-integrasjon på WordPress-originen, betalt én gang.
Tidsbasert revalidering bare som reserve. Et revalideringsintervall på 60 sekunder dekker tilfeller der webhooken ikke kommer frem, men bør ikke være den viktigste utløseren. En side som revalideres hvert 60. sekund bygges også om 60 ganger i timen; på et nettsted med 5000 sider er det ikke bærekraftig.
Cache-tagger, ikke URL-er. Hver side i cachen tagges med innleggs-ID-en i WordPress, ID-ene til termene den viser til, og tverrgående tagger (forside, sitemap). Når en webhook kommer, tømmer frontenden cachen etter tagg, ikke etter URL. Det er forskjellen mellom “regenerer produktsiden” (skjørt) og “regenerer alt som viser til produkt 8421” (riktig).
Kostnaden for ISR og SSR på Cloudflare Workers
Både Astro og Next.js kompileres til et kjøremiljø som er kompatibelt med Workers. Kostnadsbildet per modus:
- Statisk på edge. Cloudflare Pages serverer ren HTML med nesten ingen CPU per forespørsel. Billigste modus.
- ISR. Første forespørsel etter invalidering betaler hele renderingskostnaden; forespørsler fra cachen nesten ingenting. Workers håndterer begge.
- SSR. Hver forespørsel betaler hele renderingskostnaden på Workers. Forutsigbart per forespørsel, dyrt i stor skala.
Kostnadsforskjellen betyr noe ved høy trafikk. Ved lav trafikk er det korrekthet, ikke kostnad, som avgjør.
Eksempler på ISR og SSR for ekte WordPress-ruter
Forside for markedsføring. Statisk, bygget om via webhook ved hver redaksjonelle publisering. Cache i 24 timer på edge med mulighet for manuell tømming. SSR som reserve bare hvis det legges til et landsspesifikt banner.
Produktside i WooCommerce. ISR med produkt-ID som nøkkel. Webhook fra WooCommerce ved endring i lager, pris eller innhold. Cache-vindu: 1 time som reserve. SSR bare hvis lagerstatus i sanntid er et UX-krav.
Ordrehistorikk for kunden. SSR. Per bruker, styrt av økten, ingen caching på edge.
Samme arkitektur, tre ulike renderingsmoduser, én beslutningsregel.
Relaterte guider om headless WordPress
Denne artikkelen hører til tjenesten headless WordPress. Valget på rammeverksnivå finner du i beslutningsmatrisen Next.js eller Astro.
Leveransesiden av dette temaet håndterer vi under Core Web Vitals-revisjon.
