Når en bruger åbner en side, kan HTML’en være bygget færdig på serveren, før den sendes til browseren. Det kaldes server-side rendering, ofte forkortet SSR. Browseren modtager altså en side, der allerede indeholder indholdet, i stedet for først at skulle samle det med JavaScript.
Det gør server-side rendering relevant i webudvikling, fordi siden ofte kan vises hurtigere og mere stabilt på forskellige enheder. Samtidig kan søgemaskiner lettere læse indholdet, fordi teksten ligger direkte i den HTML, de henter.
I teknisk SEO er SSR derfor vigtigt, når man vil sikre god indeksering og en mere pålidelig gengivelse af sider og elementer. Det bruges især på websites og webapps, hvor både brugeroplevelse og synlighed i søgemaskiner betyder meget.
Når en bruger åbner en side, sender browseren først en forespørgsel til webserveren. I en løsning med rendering på serversiden bliver siden ikke bygget færdig i browseren, men på serveren. Serveren modtager forespørgslen, finder den relevante skabelon og henter de nødvendige data, for eksempel fra en database, et CMS eller et eksternt system. Derefter samler serveren indhold og struktur til færdig HTML, som sendes tilbage til browseren.
Browseren kan nu vise indholdet med det samme, fordi overskrifter, tekst, billeder og andre elementer allerede ligger i HTML-koden. Det gør siden hurtigere at læse for både brugere og søgemaskiner. I JavaScript-baserede løsninger stopper processen dog ikke her. Når HTML er vist, henter browseren også JavaScript-filer, som knytter funktioner til den viste side. Denne proces kaldes hydrering. Det betyder kort sagt, at den statiske HTML bliver gjort interaktiv, så knapper, formularer og filtre virker som forventet.
Et konkret forløb kan være en produktside i en webshop. En bruger åbner siden for en bestemt vare. Serveren henter produktnavn, pris, lagerstatus og anmeldelser, bygger HTML’en og sender den til browseren. Brugeren ser straks indholdet. Kort efter hydreres siden, så valg af størrelse, læg-i-kurv-knap og andre dynamiske funktioner bliver aktive.
De tre renderingsmodeller leverer i praksis den samme type webside, men de gør det på forskellige tidspunkter og med forskellige konsekvenser. Ved server-side rendering (SSR) bliver HTML genereret på serveren, hver gang en side bliver anmodet. Det betyder, at både brugere og søgemaskiner hurtigt får adgang til indholdet. Ved client-side rendering (CSR) sendes der derimod ofte først en mere tom skal, hvorefter browseren henter data og bygger siden. Statisk generering (SSG) ligger et tredje sted: Her bliver siden bygget på forhånd og serveret som færdig HTML.
For SEO er forskellene især tydelige ved indeksering. SSR og SSG gør det som regel lettere for søgemaskiner at læse indholdet med det samme, fordi den færdige HTML allerede findes ved indlæsning. CSR kan også blive indekseret, men det kræver i højere grad, at søgemaskinen udfører JavaScript korrekt. Det kan give større usikkerhed, især på store websites eller sider med vigtigt indhold langt nede i den dynamiske indlæsning.
Når det gælder hastighed og drift, har hver model sine typiske styrker. SSG er ofte hurtigst og mest stabil, fordi siderne er færdigbyggede. SSR er fleksibel og velegnet til sider med dynamisk eller personaliseret indhold, men den belaster serveren mere. CSR bruges ofte i webapps med mange brugerinteraktioner, men kan give en langsommere oplevet start. Til gengæld kan den være praktisk i løsninger, hvor meget indhold først vises efter brugerens handlinger. Vedligeholdelse afhænger derfor af både indholdstype, teknisk setup og krav til synlighed i søgemaskiner.
En af de største gevinster ved server-side rendering er, at søgemaskiner som regel modtager færdig HTML med det vigtigste indhold med det samme. Det kan gøre crawlbarhed og indeksering mere stabile, især på sider hvor meget indhold ellers først bliver indsat med JavaScript i browseren. For brugeren kan løsningen også give en hurtigere oplevelse af, at siden er klar, fordi tekst og centrale elementer vises tidligt. Det kan understøtte Core Web Vitals, men det er ikke en garanti for gode målinger. Resultatet afhænger stadig af blandt andet serverens svartid, mængden af kode, billeder, skrifttyper og efterfølgende JavaScript.
Der er også driftsmæssige fordele. Server-side rendering kan give bedre kontrol over metadata, statuskoder og kanoniske tags, hvilket er vigtigt i SEO-arbejdet. Samtidig bliver det ofte lettere at sikre, at bots og brugere ser samme grundlæggende indhold. På komplekse websites kan det reducere risikoen for, at væsentlige tekster eller interne links ikke bliver opdaget korrekt.
Ulemperne ligger især i belastning og kompleksitet. Når serveren skal generere HTML for hver forespørgsel, kan svartiden stige under høj trafik, og infrastrukturen skal dimensioneres derefter. Det kan øge kravene til cache, overvågning og fejlhåndtering. Hvis implementeringen er tung eller dårlig optimeret, kan Time to First Byte blive høj, og så forsvinder en del af hastighedsgevinsten.
Derudover bliver udvikling og drift ofte mere avanceret. Teams skal håndtere rendering på serveren, hydration i browseren og potentielle forskelle mellem det, serveren sender, og det brugeren ender med at se. Fejl i denne kæde kan påvirke både brugeroplevelse, målinger og indeksering. Server-side rendering er derfor sjældent et universalmiddel, men et teknisk valg, der skal vurderes ud fra site, ressourcer og mål.
I mange projekter er det vigtigt, at brugeren møder færdigt indhold med det samme. Her kan server-side rendering være relevant, fordi siden leveres som HTML fra serveren, før browseren bygger resten af oplevelsen. Det kan være en fordel på indholdstunge websites, hvor artikler, kategorisider og landingssider skal være lette at læse og forstå hurtigt.
Metoden giver ofte mening på nyhedssider og i større e-handelsløsninger. Nyhedssites lever af hastighed, synlighed i søgemaskiner og stabil første visning, også når mange brugere kommer ind samtidig. I webshops kan produktsider, kategorier og kampagnesider have gavn af, at vigtigt indhold og centrale elementer er tilgængelige tidligt i indlæsningen.
Den kan også være et godt valg i webapps, især når første skærmbillede skal vises hurtigt, eller når løsningen bruges på langsomme forbindelser og ældre enheder. Omvendt afhænger det konkrete valg altid af arkitektur, driftsmiljø og hvor dynamisk indholdet er. Server-side rendering er derfor sjældent et universelt svar, men i projekter med høje SEO-krav og fokus på en stabil første oplevelse er det ofte værd at overveje.
I praksis møder mange server-side rendering gennem de store JavaScript-frameworks. Next.js gør det muligt at rendere React-sider på serveren, så HTML er klar, når browseren modtager siden. Det giver ofte hurtigere første visning og bedre forudsætninger for, at søgemaskiner kan læse indholdet. Frameworket kombinerer typisk servergenereret HTML med efterfølgende hydrering, så siden også bliver interaktiv i browseren.
Nuxt spiller en tilsvarende rolle i Vue-økosystemet. Her kan sider også genereres på serveren, før de sendes til brugeren. For læseren er pointen ikke de konkrete funktioner, men mønstret: indholdet bliver gjort klar centralt, og klienten overtager derefter de dynamiske dele. Det samme princip gør SSR relevant for både indholdstunge websites og mere avancerede webapplikationer.
I Angular bruges server-side rendering typisk via Angular Universal. Løsningen gør det muligt at sende færdigrenderede sider fra serveren i stedet for at lade browseren bygge hele visningen fra bunden. På tværs af Next.js, Nuxt og Angular går de samme grundidéer igen: hurtigere første indlæsning, bedre adgang til indhold for søgemaskiner og en kombination af servergenereret markup og klientbaseret interaktivitet.
Mange tror, at server-side rendering altid giver hurtigere sider. Det er ikke nødvendigvis rigtigt. SSR kan forbedre den oplevede hastighed, fordi brugeren ser indhold tidligere, men serverarbejde, netværk og tunge forespørgsler kan også gøre svartiden længere.
En anden fejlantagelse er, at SSR automatisk løser alle SEO-problemer med JavaScript. Google kan ofte behandle JavaScript, men det sker ikke altid lige hurtigt eller problemfrit. SSR kan derfor stadig have klare fordele, især når vigtigt indhold skal være tilgængeligt med det samme for både søgemaskiner og brugere.
Det er også forkert at sidestille SSR med statisk generering eller dynamisk rendering. Statisk generering laver HTML på forhånd, mens SSR typisk genererer HTML ved hver forespørgsel. Dynamisk rendering er en særskilt løsning, hvor søgemaskiner og brugere kan få forskelligt output. Begreberne overlapper, men de er ikke det samme.
Server-side rendering er en metode, hvor serveren bygger den færdige HTML for en side, før den sendes til browseren. Brugeren modtager derfor indholdet i en form, der kan vises med det samme, i stedet for at browseren først skal samle siden med JavaScript.
Det bruges ofte for at gøre indhold hurtigere tilgængeligt og for at gøre siden lettere at læse for søgemaskiner.
Ved server-side rendering bliver HTML genereret på serveren og sendt færdig til browseren. Ved client-side rendering modtager browseren typisk en mere tom grundside og bygger derefter indholdet med JavaScript.
Den praktiske forskel er, at SSR ofte gør første visning og indeksering mere stabil, mens CSR ofte passer godt til meget interaktive webapps.
SSR kan styrke teknisk SEO, fordi søgemaskiner hurtigt får adgang til færdig HTML med tekst, links og metadata. Det gør crawlbarhed og indeksering mere forudsigelig, især når vigtigt indhold ellers ville blive indlæst sent med JavaScript.
Det er dog ikke i sig selv en garanti for gode placeringer. Indholdskvalitet, intern linkstruktur, hastighed og den øvrige tekniske opsætning har stadig stor betydning.
Det kan den gøre, men ikke altid. SSR forbedrer ofte den oplevede hastighed, fordi brugeren ser indhold tidligere i forløbet.
Hvis serveren er langsom, datahentning er tung, eller løsningen er dårligt optimeret, kan svartiden stadig blive høj. Derfor afhænger resultatet af både arkitektur, cache og den samlede mængde kode.
SSR er ofte et godt valg, når det er vigtigt, at brugere og søgemaskiner hurtigt kan se sidens vigtigste indhold. Det gælder typisk indholdstunge websites, landingssider, kategorisider, produktsider og nyhedssider.
Det kan også være relevant i webapps, hvor første skærmbillede skal vises hurtigt, eller hvor man vil mindske afhængigheden af, at browseren først udfører meget JavaScript.
Den største ulempe er ofte højere teknisk kompleksitet. Serveren skal generere HTML løbende, og det stiller større krav til drift, cache, overvågning og fejlretning.
Derudover kan serverbelastningen stige ved høj trafik. Hvis implementeringen ikke er effektiv, kan gevinsten ved SSR blive mindre end forventet.
Ved SSR vises siden først som færdig HTML fra serveren. Derefter henter browseren JavaScript, som gør siden interaktiv. Den proces kaldes hydrering.
Hydrering betyder altså, at en allerede vist side får tilknyttet funktioner som knapper, filtre, formularer og anden dynamik, så den ikke kun er synlig, men også kan bruges fuldt ud.
Nej. Ved server-side rendering bliver HTML typisk genereret, når brugeren anmoder om siden. Ved statisk generering bliver HTML bygget på forhånd, for eksempel ved publicering eller deploy.
Begge metoder kan give færdig HTML til browseren, men de adskiller sig i, hvornår siden bliver genereret, og hvor godt de passer til dynamisk indhold.
I Next.js kan en side rendere på serveren, så browseren modtager færdig HTML ved indlæsning. Derefter overtager JavaScript i browseren og gør siden interaktiv.
Det gør Next.js velegnet til løsninger, hvor man vil kombinere React med bedre første visning og mere stabil adgang til indhold for søgemaskiner.
Ja, Google kan i mange tilfælde crawle og behandle sider med client-side rendering. Det kræver dog, at Google også kan udføre det nødvendige JavaScript korrekt.
Det kan gøre indekseringen mere usikker eller langsommere end ved SSR, især hvis vigtigt indhold, links eller metadata først bliver tilgængelige sent i renderingsforløbet.