SSR eller CSR: Hvor skal siden rendres?

SSR og CSR er begreper dere kan ha støtt på i et tilbud uten å få dem forklart. Bak forkortelsene skjuler det seg et enkelt spørsmål: Hvor skal siden settes sammen, på serveren før den sendes, eller i nettleseren til den besøkende etterpå? Valget høres teknisk ut, men får direkte følger for SEO, for hvor rask siden føles og for hva den koster å drifte. Her er forklaringen, sett fra kundens side.

Hva valget betyr for SEO og synlighet

Den mest forretningskritiske forskjellen gjelder synlighet. Med server-side rendering (SSR) bygges siden ferdig på serveren og sendes komplett. En søkemotor som besøker siden, får alt innholdet direkte og kan lese og indeksere det uten omvei. Det gir et stabilt utgangspunkt for organisk trafikk.

Med client-side rendering (CSR) sendes det i stedet et i prinsippet tomt skall pluss kode, og innholdet på siden skapes først når nettleseren har kjørt koden. En robot som leser siden maskinelt, kan da gå glipp av innholdet eller få det forsinket, noe som i verste fall skader rangeringen. Problemet lar seg dempe, men det er en risiko dere tar på dere.

Her kommer et argument som først har vokst frem de siste årene. Stadig flere brukere finner svar via AI-drevne søketjenester, og mange av dem leser den rå HTML-koden på siden snarere enn å kjøre tung kode. Innhold som er rendret på serveren, er derfor lettere for dem å oppfatte riktig. Vil dere være synlige også i denne nye kanalen, taler det ytterligere for SSR. Det er et tydelig 2026-argument.

Ytelse og Core Web Vitals

Opplevd ytelse henger sammen med renderingsvalget. SSR gir gjerne et raskere førsteinntrykk: Fordi ferdig innhold leveres direkte, ser brukeren noe meningsfullt tidlig. Det slår positivt ut på Core Web Vitals, målene Google bruker for å vurdere sideopplevelsen.

CSR kan i stedet vise en tom flate eller en lasteindikator først mens nettleseren bygger siden ferdig. På en rask enhet med god nettilkobling merkes det knapt, men på en svakere mobil eller et dårligere nett kan ventetiden bli merkbar. Gode verdier lar seg oppnå med begge teknikkene, men SSR gir ofte et enklere utgangspunkt for åpne sider der hvert sekund teller.

Samtidig har CSR sin styrke når nettsiden først er lastet: Navigasjon mellom visninger kan føles svært rask fordi mye allerede ligger i nettleseren. Det gjør teknikken egnet for applignende, interaktive deler.

Serverkostnad mot belastning hos klienten

Renderingsvalget flytter også arbeid mellom serveren og den besøkende, og det har en kostnadsside. Med SSR gjør serveren jobben med å bygge hver side. Det belaster serveren mer og kan gi noe høyere driftskostnader, særlig ved mye trafikk.

Med CSR overlates den tyngste delen av arbeidet til den besøkendes enhet. Serveren sender bare skallet og koden, noe som kan gjøre ren drift billigere og lettere å skalere. Baksiden er at belastningen havner hos brukeren, og brukerens enhet er ikke alltid kraftig.

For en nettside av vanlig størrelse er kostnadsforskjellen sjelden avgjørende, og gevinsten ved SSR for SEO og opplevelse veier som oftest tyngre. Det viktige er å ta valget bevisst i stedet for å la det avgjøres av bekvemmelighet.

Slik velger dere

Ta utgangspunkt i hva nettsiden skal brukes til. Er det en åpen nettside der organisk synlighet og førsteinntrykk er viktige, noe som gjelder de fleste nettsider for bedrifter, blogger og nettbutikker, er SSR som oftest riktig i 2026, ikke minst med tanke på AI-søketjenestene. Er det et innlogget, interaktivt verktøy der søkbarhet ikke betyr noe, kan CSR være både enklere og billigere.

En vanlig feil er å behandle spørsmålet som et hardt veivalg for hele nettsiden. Moderne rammeverk lar dere blande: Det åpne og søkbare rendres på serveren, og de tunge, innloggede delene rendres i nettleseren. Tjenestene våre omfatter begge tilnærmingene, og vi hjelper dere med å velge rendering ut fra hvor synlighet og hastighet faktisk betyr noe. Ta kontakt med en beskrivelse av nettsiden deres, så ser vi sammen på hvilket opplegg som passer.