Prerendering (förrendering)

Så fungerar det i praktiken

Ett byggskript startar appen i en huvudlös webbläsare, besöker varje sida i en lista, väntar tills vyn har lagt sig och skriver den färdiga DOM:en till dist/<sida>/index.html. Den publicerade webbplatsen innehåller därmed en riktig HTML-fil per sida. Besökaren får läsbart innehåll direkt, och JavaScript-paketet laddas ändå efteråt för att göra sidan interaktiv – det steg som kallas hydrering.

Skälet att göra jobbet är att alla som läser dina sidor inte kör JavaScript. Google gör det, med fördröjning och en renderingsbudget. Bing är ojämn. De flesta språkmodellers crawlers, botar för länkförhandsvisningar och skrapor läser helt enkelt den HTML de får. För dem har en orenderad ensidesapplikation inget innehåll alls.

Prerendering, SSR och SSG är inte samma sak

Orden används slarvigt, så det är värt att hålla isär dem:

• Prerendering sker en gång, vid bygget, och ger statiska filer. Innehållet är lika färskt som din senaste driftsättning.
• Serverrendering (SSR) sker per anrop, på en server, så att HTML:en kan vara personlig eller helt aktuell. Det kostar en server som ständigt är igång.
• Statisk sidgenerering (SSG) är i princip prerendering som grundarkitektur i stället för som ett påhäng på en färdig klientapp.

Det finns dessutom en andra, orelaterad betydelse: webbläsare använder "prerender" för att i förväg ladda en sida användaren troligen går till härnäst. Samma ord, annat ämne – sammanhanget brukar avgöra vilket som menas.

Vad du behöver se upp med

Prerendering täcker bara de sidor du listar, så en ny sida som ingen lagt till levereras som ett tomt skal. Allt personligt får inte hamna i ögonblicksbilden – att förrendera en inloggad vy bakar in en enskild användares data i en publik fil. Och den förrenderade HTML:en måste stämma med det klienten renderar, annars flimrar sidan synligt när appen byter ut markupen.