Ytelsespåvirkning fra gjengivelse på serversiden (SSR)
Vurder ytelsesavveiningene mellom gjengivelse på serversiden (SSR) og gjengivelse på klientsiden (CSR), samt innvirkningen på TTI.
Ytelsespåvirkning fra gjengivelse på serversiden (SSR) er en gratis leksjon i Optimalisering av webytelse og Lighthouse på CoddyKit. Dette er leksjon 3 av 4. Du kan lese hele leksjonen gratis nedenfor – og deretter øve praktisk i nettleseren med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt. Den er en del av læringsløpet i Optimalisering av webytelse og Lighthouse, og fremdriften din synkroniseres mellom nettet og CoddyKit-appen. Kurset i Optimalisering av webytelse og Lighthouse inneholder totalt 4 leksjoner.
SSR kontra CSR: Hovedideen
Velkommen til en gjennomgang av hvordan websider bygges! I dag skal vi se på to grunnleggende måter webinnhold når nettleseren din på: Client-Side Rendering (CSR) og Server-Side Rendering (SSR).
Begge har en egen innvirkning på ytelsen, særlig på hvor raskt brukeren kan se og samhandle med siden.
Slik fungerer rendering på klientsiden
Med CSR mottar nettleseren en minimal HTML-fil, ofte bare en tom side med en lenke til en JavaScript-pakke. Det er som et tomt lerret.
- Nettleseren laster ned HTML: Svært lite og raskt.
- Nettleseren laster ned JavaScript: Dette er hoveddelen og er ofte stor.
- JavaScript henter data og bygger brukergrensesnittet: Etter innlastingen kjører JS, kaller API-er og setter dynamisk innhold inn på siden.
Brukeren ser først innhold når disse trinnene er fullført.
CSR-ytelse og første innlasting
CSR kan oppleves som tregt i starten. Brukeren kan se en tom skjerm eller en lastespinner i en merkbar periode. Dette påvirker målinger som First Contentful Paint (FCP) og Largest Contentful Paint (LCP).
Når applikasjonen først er lastet inn, kan videre navigering i den være svært rask, siden det bare er data (ikke hele sider) som må hentes.
Prøv dette enkle CSR-eksempelet:
<!DOCTYPE html>
<html>
<head>
<title>CSR Demo</title>
<style>
body { font-family: sans-serif; text-align: center; }
#app { border: 1px solid #ccc; padding: 20px; margin: 20px auto; max-width: 300px; min-height: 50px; }
</style>
</head>
<body>
<div id="app"><p>Loading content...</p></div>
<script>
document.addEventListener('DOMContentLoaded', () => {
setTimeout(() => {
document.getElementById('app').innerHTML = '<h2>Welcome!</h2><p>Content rendered by JS.</p><button>Click Me</button>';
}, 1000); // Simulate network/processing delay
});
</script>
</body>
</html>Slik fungerer rendering på serversiden
Med SSR gjør serveren det meste av arbeidet. Når en bruker ber om en side, behandler serveren forespørselen, henter nødvendige data og bygger hele HTML-svaret.
- Nettleseren ber om siden: Sender en forespørsel til serveren.
- Serveren bygger HTML: Henter data og rendrer hele siden på serveren.
- Nettleseren mottar full HTML: Får en side som er klar til å vises.
Brukeren ser innholdet nesten umiddelbart etter hvert som HTML-en kommer frem.
SSR-ytelse og første innlasting
SSR gir vanligvis mye raskere First Contentful Paint (FCP) og Largest Contentful Paint (LCP). Brukerne ser meningsfylt innhold svært raskt, noe som forbedrer den opplevde ytelsen og SEO.
Serveren må imidlertid generere HTML for hver forespørsel, noe som kan legge til forsinkelse på serversiden hvis dette ikke er optimalisert. La oss se på et SSR-lignende resultat:
<!DOCTYPE html>
<html>
<head>
<title>SSR Demo</title>
<style>
body { font-family: sans-serif; text-align: center; }
.content { border: 1px solid #ccc; padding: 20px; margin: 20px auto; max-width: 300px; }
</style>
</head>
<body>
<div class="content">
<h2>Welcome!</h2>
<p>Content rendered directly by the server.</p>
<button onclick="alert('Hello from SSR!')">Click Me</button>
</div>
</body>
</html>Forstå Time To Interactive (TTI)
Time To Interactive (TTI) måler hvor lang tid det tar før en side blir fullt interaktiv. Det innebærer at:
- Siden har vist nyttig innhold (FCP/LCP).
- Hendelsesbehandlere er registrert for de fleste synlige elementene i brukergrensesnittet.
- Siden svarer på brukerinteraksjoner innen 50 millisekunder.
TTI er avgjørende fordi brukeren kan se innhold, men likevel ikke kunne klikke på knapper eller skrive i felt hvis siden ikke er interaktiv.
SSRs TTI-utfordring: Hydrering
Selv om SSR leverer innhold raskt, sender det ofte statisk HTML. For å gjøre denne HTML-en dynamisk og interaktiv må JavaScript på klientsiden fortsatt lastes inn og «ta over» DOM-en. Denne prosessen kalles hydration.
Under hydration kobler JavaScript til hendelseslyttere og bygger den virtuelle DOM-en. Hvis denne JS-pakken er stor eller tar lang tid å kjøre, kan den forsinke TTI selv etter at innholdet er synlig.
Sammenligning av TTI: SSR kontra CSR
Påvirkningen på TTI er forskjellig:
- CSR: TTI samsvarer ofte godt med FCP/LCP, siden alt innhold og all interaktivitet lastes inn samtidig. Hvis JS-pakken er liten, kan TTI være rask.
- SSR: FCP/LCP er rask, men TTI kan bli forsinket hvis hydration går sakte. Brukere kan se innholdet, men oppleve en frustrerende «død sone» der ingenting reagerer.
Målet er å minimere dette gapet mellom synlig og interaktivt innhold.
Velg riktig tilnærming
Valget mellom SSR og CSR avhenger av behovene i prosjektet:
- SSR passer godt for: innholdstunge nettsteder (blogger, netthandel), god SEO og rask innledende lasting for brukere med langsomme forbindelser.
- CSR passer godt for: svært interaktive webapplikasjoner (dashbord, strømmer i sosiale medier), der innlastingstiden i starten er mindre viktig enn en rik brukeropplevelse etter innlasting.
Det finnes også hybride tilnærminger, som Static Site Generation (SSG) og Progressive Hydration, som kombinerer fordelene.
Kort sjekk: strategier for gjengivelse
Basert på det vi har lært, hvilke påstander beskriver riktig avveiningene mellom Server-Side Rendering (SSR) og Client-Side Rendering (CSR)?
Oppsummering: SSR, CSR og TTI
I denne leksjonen utforsket vi Server-Side Rendering (SSR) og Client-Side Rendering (CSR). Du har lært:
- CSR utsetter gjengivelsen til nettleseren, noe som potensielt kan forsinke visningen av det første innholdet, men gir dynamiske opplevelser.
- SSR gjengir HTML på serveren, noe som gir raskt innledende innhold (FCP/LCP), men kan forsinke interaktiviteten (TTI) på grunn av hydration.
- Time To Interactive (TTI) er avgjørende og måler når en side er fullt brukbar.
Valget mellom dem innebærer å balansere innlastingshastighet i starten, behovet for interaktivitet og hvilken innvirkning hydration har på TTI.
Lær deg Optimalisering av webytelse og Lighthouse med en AI-veileder – gratis
Skriv og kjør ekte kode i nettleseren, få umiddelbar hjelp fra en AI-veileder som er tilgjengelig døgnet rundt, og fortsett der du slapp – på nettet eller i appen.
- Kurs
- 12
- Leksjoner
- 48
Ofte stilte spørsmål
Er leksjonen «Ytelsespåvirkning fra gjengivelse på serversiden (SSR)» gratis?
Ja – hele teksten i «Ytelsespåvirkning fra gjengivelse på serversiden (SSR)» er gratis å lese her på nettet. For å øve interaktivt med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt, og for å låse opp resten av Optimalisering av webytelse og Lighthouse-kurset, kan du oppgradere til CoddyKit PRO. Kurset i Optimalisering av webytelse og Lighthouse inneholder totalt 4 leksjoner.
Hva lærer jeg i «Ytelsespåvirkning fra gjengivelse på serversiden (SSR)»?
Vurder ytelsesavveiningene mellom gjengivelse på serversiden (SSR) og gjengivelse på klientsiden (CSR), samt innvirkningen på TTI. Du øver på Optimalisering av webytelse og Lighthouse med praktisk kode som du kjører direkte i nettleseren, mens en AI-veileder som er tilgjengelig døgnet rundt, svarer på spørsmålene dine mens du jobber deg gjennom leksjonen.
Trenger jeg erfaring for å begynne med Optimalisering av webytelse og Lighthouse?
Ingen tidligere erfaring er nødvendig. Optimalisering av webytelse og Lighthouse på CoddyKit er lagt opp for både nybegynnere og viderekomne, så De kan begynne her eller helt fra start og lære i Deres eget tempo. Dette er leksjon 3 av 4.
Hvor lang tid tar leksjonen «Ytelsespåvirkning fra gjengivelse på serversiden (SSR)»?
De fleste CoddyKit-leksjoner tar omtrent 5–10 minutter. Hver leksjon er kort og interaktiv, slik at De gjør jevne fremskritt og kan fortsette akkurat der De slapp – både på nettet og i appen.
Kan jeg skrive og kjøre kode i denne Optimalisering av webytelse og Lighthouse-leksjonen?
Ja. Alle Optimalisering av webytelse og Lighthouse-leksjoner har en innebygd kodeeditor, slik at De kan skrive og kjøre ekte kode direkte i nettleseren og få umiddelbar tilbakemelding fra AI – uten lokal konfigurering.
Alle leksjonene i dette kurset
- Ytelsesflaskehalser i backend
- Optimalisering av databasespørringer
- Ytelsespåvirkning fra gjengivelse på serversiden (SSR)
- Bufring og komprimering av API-svar