Ordlista

Statisk sajtgenerering

Statisk sajtgenerering är en renderingsstrategi där varje sida byggs till en vanlig HTML-fil vid bygge-tid och serveras direkt från ett CDN. Det finns inget per-request-serverarbete. Varje besökare får samma förbyggda fil.

Statisk sajtgenerering, ofta förkortat SSG, är en renderingsstrategi där varje sida på en webbplats byggs till en vanlig HTML-fil vid bygge-tid. Filen laddas upp till ett CDN eller en filserver och serveras direkt till varje webbläsare som frågar efter den. Det finns ingen serverprocess på den kritiska vägen. Detta gör statiska sajter snabba, billiga att drifta och enkla att resonera om, men begränsar hur ofta data kan ändras utan att utlösa ett ombygge.

Statisk sajtgenerering är en renderingsstrategi där varje sida på en webbplats byggs till en vanlig HTML-fil vid bygge-tid. Filen laddas sedan upp till ett CDN eller en filserver och serveras direkt till varje webbläsare som frågar efter den. Det finns ingen serverprocess på den kritiska vägen. Varje besökare får samma förbyggda fil. ## Hur SSG fungerar En statisk sajtgenerator tar källfiler (Markdown, MDX, JSON, ett databasfrågeresultat) och mallar, och producerar en HTML-fil per sida i sajten. Bygget körs en gång, antingen lokalt eller i CI. Utdatan är en mapp med HTML, CSS, JavaScript och bilder. Den mappen driftsätts till en host som serverar statiska filer. Vid runtime gör hosten inget mer än att servera rätt fil. Ingen databasfråga, ingen mall-rendering, ingen applikationslogik. Webbläsaren laddar ner filen, kör eventuellt JavaScript som ingår och visar sidan. ## SSG vs SSR Statisk generering och server-side rendering producerar båda HTML på servern, men vid olika tidpunkter. SSG producerar HTML en gång vid bygge-tid. SSR producerar HTML vid varje request. SSG är billigare och snabbare vid runtime eftersom det inte finns något per-request-arbete. SSR är mer flexibelt eftersom det kan inkludera data som ändras mellan bygg. Den praktiska skillnaden syns när data ändras. En statisk sajt med en produktkatalog behöver ett ombygge varje gång en produkt ändras. En server-renderad sajt hämtar färsk data vid varje request. För en marknadssajt eller blogg är det ombygget okej. För en tungt trafikerad e-handelskatalog är det opraktiskt att bygga om tusentals sidor varje gång en lagerräkning ändras. ## Incremental static regeneration Moderna ramverk suddar ut gränsen mellan SSG och SSR. Next.js har incremental static regeneration (ISR). Nuxt har liknande mönster genom hybrid rendering. Frontenden renderar en sida statiskt och renderar sedan om den i bakgrunden när den blir föråldrad. Besökare får statisk-snabba responser oftast och träffar bara enstaka gånger ett live ombygge. Mönstret gör SSG användbart för innehåll som ändras men inte varje minut. ## SSG i e-handel Ren statisk generering används sällan för hela e-handelssajter. Produktsidor, kundvagn och checkout behöver live-data. Men SSG fungerar bra för de delar av sajten som ändras sällan: kategoriskal som renderas ovanpå live produktdata, marknadslandningssidor, kampanjsidor, bloggposter, hjälpartiklar och juridiska sidor. En väldesignad e-handelsfrontend använder SSG för de och sparar SSR för sidor som behöver per-request-data. ## Hur Frntkey passar in Frntkey använder en hybrid av SSR, statisk generering och edge-cache. Sidor som ändras hela tiden (produktlistningar, produktdetalj, kundvagn, checkout) server-renderas på Vercel. Marknadssidor skrivna i Storyblok genereras statiskt och revalideras vid innehållsförändringar. Cachade responser serveras från Vercels edge, så de flesta besökare får statisk-snabba responser utan att offra färskhet. Mixen håller Core Web Vitals gröna och driftkostnaderna förutsägbara. ## Relaterade termer Server-side rendering · Jamstack · Core Web Vitals · Ecommerce frontend

Vanliga frågor

Vill du prata?

Se hur Frntkey passar din stack. Boka 30 minuter.

Boka demo