Headless WordPress, ISR eller SSR: velg renderingsmodus etter hvor ofte innholdet endres

#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 kan levere begge gjennom rammeverkets adapter; en side fra cachen 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.

#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-originen 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. Et intervall på 60 sekunder betyr ikke at hver side bygges om 60 ganger i timen: Next.js regenererer en side først når det kommer en forespørsel etter at vinduet er utløpt. Den reelle kostnaden er at hver populær side kan regenereres i bakgrunnen opptil én gang i minuttet, og på plattformer som fakturerer per forespørsel teller dette bakgrunnsarbeidet som ekstra regnekraft.

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

Astro når Workers gjennom sin offisielle Cloudflare-adapter. Next.js dokumenterer ISR for Node.js-kjøremiljøet og beskriver støtte via adaptere som plattformavhengig, så sjekk adapteren før du planlegger ISR på 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. På Workers avhenger dette av adapterens cache, ikke av rammeverket alene.
• 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.

#Hvordan revalidate i Next.js fungerer for WordPress-sider

En rute med export const revalidate = 3600 serverer sin bufrede HTML til hver forespørsel innenfor vinduet. Den gjeldende ISR-guiden fra Next.js beskriver hva som skjer deretter: den første forespørselen etter at vinduet er utløpt får fortsatt den utdaterte siden, denne forespørselen starter en regenerering i bakgrunnen, og når den lykkes får neste forespørsel den nye versjonen. Et innlegg ingen besøker blir aldri regenerert. Intervallet setter et tak på hvor ofte en side kan bygges om; det planlegger ingen ombygginger.

Fire detaljer fra den samme guiden avgjør om dette fungerer på en WordPress-front:

• Når en rute gjør flere fetch-kall med ulike revalidate-verdier, bestemmer den laveste ISR-intervallet for siden. En sidekolonne som henter de nyeste innleggene med et vindu på 60 sekunder, trekker hele artikkelen ned til 60 sekunder.
• Ett fetch-kall med revalidate: 0 eller cache: 'no-store' gjør ruten dynamisk. Ett enkelt kall uten cache mot et WordPress-endepunkt, for eksempel en visningsteller, flytter siden i det stille fra ISR til SSR.
• Hvis regenereringen feiler, for eksempel fordi WordPress-originen svarer med en feil, fortsetter Next.js å servere den siste fungerende versjonen og prøver igjen ved neste forespørsel. Et brudd på originen tømmer ikke fronten.
• Guiden anbefaler et langt intervall, heller en time enn ett sekund, og revalidering ved behov når du trenger presisjon. Det er webhook-først-regelen fra avsnittet over.

Svarhodet x-nextjs-cache rapporterer tilstanden til hver forespørsel som HIT, STALE, MISS eller REVALIDATED. Å lese det rett etter en publisering er den raskeste måten å bekrefte at en webhook nådde fronten.

#Hvordan revalidere Next.js-sider med en webhook fra WordPress

Mottakeren er en Route Handler, for eksempel app/api/revalidate/route.ts, som sjekker en delt hemmelighet og kaller én av to funksjoner fra next/cache.

revalidateTag(tag, 'max') merker hvert bufrede fetch-kall med denne taggen som utdatert, på alle sider som bruker det (referanse for revalidateTag). Med profilen 'max' får besøkende fortsatt den gamle kopien mens den ferske lastes. For en publisering i WordPress er det som regel riktig avveining: tagg fetch-kallene med post-8421 og posts, så oppdaterer én webhook innlegget, arkivet og forsiden. Når den gamle kopien aldri må vises igjen, for eksempel for en tilbaketrukket artikkel, ber referansen webhook-kallere sende { expire: 0 }, fordi updateTag bare fungerer i Server Actions. Formen med ett argument, revalidateTag(tag), er foreldet. Tagger skiller mellom store og små bokstaver og er begrenset til 256 tegn.

revalidatePath(path) virker på ruter i stedet for data (referanse for revalidatePath). En bokstavelig sti som /blog/my-post oppdaterer én side; et mønster som /blog/[slug] krever det andre argumentet, 'page' eller 'layout'. To feller er vanlige i headless WordPress. Med rewrites i next.config.js sender du målstien, ikke adressen den besøkende ser. Og Proxy kjører ikke for ISR-forespørsler ved behov, så en sti som er omskrevet der må revalideres i sin endelige form.

Begge funksjonene merker bare oppføringer; regenereringen skjer ved neste besøk. Når appen kjører på flere instanser med standard filsystemcache, invaliderer en webhook bare instansen som tok imot den. Revalidering ved behov trenger da en delt cache handler før du kan stole på den.

#Hvordan route caching i Astro 7 erstatter ISR

Astro forhåndsrenderer hver side som standard. En rute går over til rendering ved forespørsel med export const prerender = false, noe som krever en serveradapter. output: 'server' snur standarden, og dokumentasjonen råder deg til å bli på 'static' til de fleste sidene virkelig trenger en server (rendering ved forespørsel i Astro). En side som renderes ved forespørsel kan sette sitt eget Cache-Control-hode via Astro.response.headers.

Astro 7 legger til route caching, som lukker det meste av gapet til ISR i Next.js (route caching i Astro). En side som renderes ved forespørsel kaller Astro.cache.set({ maxAge: 3600, swr: 60, tags: ['post-8421'] }). Endepunktet som tar imot webhooken fra WordPress kaller context.cache.invalidate({ tags: ['post-8421'] }) eller invalidate({ path: '/blog/my-post' }). Invalidering per sti treffer bare ved eksakt samsvar, uten jokertegn. routeRules i astro.config.mjs setter standardverdier for grupper av ruter, for eksempel en maxAge for /blog/[...slug], og en side kan overstyre dem eller melde seg ut med Astro.cache.set(false) når svaret er personlig tilpasset.

Selve cachen kommer fra en leverandør. Den innebygde memoryCache() passer for én enkelt Node-server. Adapterne for Netlify, Vercel og Cloudflare har CDN-leverandører som fortsatt er eksperimentelle og må slås på manuelt. Cloudflare-leverandøren, fra @astrojs/cloudflare 14, setter hodene Cloudflare-CDN-Cache-Control og Cache-Tag og slår på Workers-cachen. Under utvikling gjør cache-API-et ingenting, så test det med et bygg og en forhåndsvisning.

#Hvordan blande statiske og dynamiske deler på én WordPress-side

Mange ruter er stabile bortsett fra ett levende element: en produktside med lagerstatus, en artikkel med avataren til den innloggede leseren. Å rendere hele siden ved hver forespørsel for dette ene elementet er den dyre løsningen. Server islands i Astro er den billigere (server islands i Astro). Legg server:defer på komponenten som trenger ferske data. Resten av siden forblir forhåndsrendret eller bufret, og øya hentes fra sitt eget endepunkt etter at siden er lastet. Et barneelement med slot="fallback" vises på plassen dens frem til da, og hver øy lastes uavhengig, så et tregt oppslag i lagerstatus holder ikke igjen noe annet.

To begrensninger gjelder. Server islands krever en adapter, og propsene deres må kunne serialiseres: enkle objekter, strenger, tall, arrays, datoer og noen få andre typer, men ikke funksjoner. For en produktside i WooCommerce betyr det å sende produkt-ID-en, ikke en API-klient.

Dette presiserer tabellen over. Ruten forblir statisk eller ISR, og bare øya renderes per forespørsel.

#Hvordan hente WordPress-innhold til statiske bygg og ISR-bygg

Hvert forhåndsrenderingssteg starter med en liste over slugs, og REST API-et i WordPress returnerer den i sider. per_page godtar verdier fra 1 til 100, og hvert svar har hodene X-WP-Total og X-WP-TotalPages, så et byggeskript leser første side og går videre til sideantallet fra hodet (paginering i REST API-et). Next.js sender denne listen til generateStaticParams. Innlegg publisert etter bygget renderes ved første forespørsel, med mindre dynamicParams er satt til false, og generateStaticParams kalles ikke på nytt under revalidering (referanse for generateStaticParams).

Parameteren _fields kutter svaret ned til det steget trenger, for eksempel ?_fields=slug,modified_gmt for slug-listen, og WordPress hopper over beregningen av feltene som er utelatt. Fra WordPress 5.3 godtar den også nestede metanøkler, og fra 5.4 kan _embed begrenses til navngitte relasjoner som author,wp:term (globale parametere i REST API-et).

For å oppdage endringer godtar posts-endepunktet modified_after med en dato i ISO 8601 og returnerer modified_gmt for hvert innlegg (referanse for posts-endepunktet). En planlagt jobb som spør etter innlegg endret siden forrige kjøring, er en fornuftig reserve for tapte webhooks og billigere enn et kort revalidate-vindu på hver rute.

#Hvordan forhåndsvise WordPress-utkast på en ISR-front

Redaktører forventer at forhåndsvisningen viser utkastet, mens en bufret front serverer den publiserte versjonen. Draft Mode i Next.js løser dette per besøkende (guide for Draft Mode). En Route Handler sjekker en delt hemmelighet, kaller draftMode().enable(), som setter informasjonskapselen __prerender_bypass, og videresender til siden. Forespørsler med denne informasjonskapselen hopper over fetch-cachen og ISR-svarcachen og sendes med Cache-Control: private, no-cache, no-store, max-age=0, must-revalidate. Alle andre besøkende får fortsatt den bufrede siden.

På WordPress-siden returnerer posts-endepunktet publisert innhold med mindre noe annet er angitt, fordi status som standard er publish. Utkast leses derfor med autentiserte forespørsler. Applikasjonspassord, innebygd i WordPress siden 5.6 og sendt som Basic Auth over HTTPS, er metoden håndboken dokumenterer (autentisering i REST API-et). Hold denne påloggingsinformasjonen på serveren, i Route Handler eller i et fetch-kall som bare kjører på serveren, og aldri i klientkoden.

#Relaterte guider om headless WordPress

Denne artikkelen hører til tjenesten headless WordPress. Valget på rammeverksnivå finner du i beslutningsmatrisen Next.js eller Astro. Risikoene ved migrering er samlet i sjekklisten med SEO-mønstre, det som gjelder nettbutikker står i headless WordPress til WooCommerce, og kostnadssiden i artikkelen om økonomien i headless WordPress. En sammenligning av rammeverkene versjon for versjon, også av hvordan hvert av dem henter WordPress-data, finner du i Astro 5 vs Next.js 15.

Leveransesiden av dette temaet håndterer vi under Core Web Vitals-revisjon.