Dette er de tre hovedstrategier for hvornår en sides HTML genereres. At vælge den rigtige for hver side balancerer ferskhed, ydeevne og serveromkostninger.
() {
posts = (, { : }).( r.());
;
}
Siden pre-renderes til statisk HTML ved build og caches på et CDN. Hurtigst mulig levering, men indholdet er frossen indtil næste build. Bedst til indhold, der sjældent ændres: marketingsider, dokumentation, blogindlæg.
// HTML generated FRESH on every request
export default async function Page() {
const data = await fetch("...", { cache: "no-store" }).then(r => r.json());
return <Dashboard data={data} />;
}
Serveren renderer siden per anmodning, så data er altid aktuelle — på bekostning af langsommere svar og serverbelastning ved hvert besøg. Bedst til personaliserede eller altid-friske data: dashboards, kontosider, søgeresultater.
// Static, but automatically rebuilt in the background every N seconds
export const revalidate = 60; // regenerate at most once per 60s
export default async function Page() {
const products = await fetch("...", { next: { revalidate: 60 } }).then(r => r.json());
return <Products items={products} />;
}
ISR serverer statisk HTML (hurtigt, CDN-cachet) men revaliderer det i baggrunden på et skema — så du får statisk ydeevne med periodisk friske data uden at gjenopbygge hele webstedet. Bedst til indhold, der ændres lejlighedsvis: produktlister, nyheder, ranglister.
Speed Freshness Server cost Use for
SSG fastest build-time only none docs, marketing
SSR slower always fresh every request dashboards, personalized
ISR fast every N seconds occasional catalogs, news
I App Router vælger du disse per-fetch via cache-muligheder (force-cache = SSG, no-store = SSR, revalidate = ISR) snarere end specielle funktioner.
At forstå afvejningen — statisk er hurtigst men forældet, SSR er frisk men dyrt, ISR balancerer begge — lader dig optimere hver side for det rigtige forhold mellem ydeevne og data-ferskhed.