Indvirkning af serverside-rendering (SSR)
Vurdér performanceafvejningerne mellem Server-Side Rendering (SSR) og Client-Side Rendering (CSR) samt deres indvirkning på TTI.
Indvirkning af serverside-rendering (SSR) er en gratis Optimering af webydeevne og Lighthouse-lektion på CoddyKit. Dette er lektion 3 af 4. Du kan læse hele lektionen gratis nedenfor — og derefter øve dig praktisk i browseren med en indbygget kodeeditor og en AI-vejleder, der er tilgængelig døgnet rundt. Den er en del af læringsforløbet i Optimering af webydeevne og Lighthouse, og dine fremskridt synkroniseres på tværs af nettet og CoddyKit-appen. Optimering af webydeevne og Lighthouse-kurset indeholder 4 lektioner i alt.
SSR kontra CSR: Grundidéen
Velkommen til en gennemgang af, hvordan websider bliver opbygget! I dag ser vi på to grundlæggende måder, webindhold når frem til din browser på: Client-Side Rendering (CSR) og Server-Side Rendering (SSR).
De har hver deres indvirkning på ydeevnen, især på hvor hurtigt en bruger kan se og interagere med din side.
Sådan fungerer rendering på klientsiden
Ved CSR modtager din browser en minimal HTML-fil, ofte blot en tom side med et link til en JavaScript-pakke. Det er som et tomt lærred.
- Browseren henter HTML: Meget lidt og hurtigt.
- Browseren henter JavaScript: Dette er den største del og er ofte omfattende.
- JavaScript henter data og opbygger brugergrænsefladen: Efter indlæsningen udfører JS koden, kalder API'er og indsætter dynamisk indhold på siden.
Brugeren ser først indholdet, når disse trin er gennemført.
CSR-ydeevne og indledende indlæsning
CSR kan føles langsomt i begyndelsen. Brugeren kan i en mærkbar periode se en tom skærm eller en indlæsningsindikator. Det påvirker målinger som First Contentful Paint (FCP) og Largest Contentful Paint (LCP).
Når applikationen først er indlæst, kan efterfølgende navigation være meget hurtig, fordi der kun skal hentes data og ikke hele sider.
Prøv dette enkle CSR-eksempel:
<!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>Sådan fungerer rendering på serversiden
Ved SSR udfører serveren det tunge arbejde. Når en bruger anmoder om en side, behandler serveren forespørgslen, henter de nødvendige data og opbygger det komplette HTML-svar.
- Browseren anmoder om siden: Sender en forespørgsel til serveren.
- Serveren opbygger HTML: Henter data og renderer den komplette side på serveren.
- Browseren modtager komplet HTML: Modtager en side, der er klar til visning.
Brugeren ser næsten med det samme indholdet, efterhånden som HTML'en ankommer.
SSR-ydeevne og indledende indlæsning
SSR giver generelt en meget hurtigere First Contentful Paint (FCP) og Largest Contentful Paint (LCP). Brugerne ser meningsfuldt indhold meget hurtigt, hvilket forbedrer den oplevede ydeevne og SEO.
Serveren skal dog generere HTML for hver forespørgsel, hvilket kan øge forsinkelsen på serversiden, hvis det ikke er optimeret. Lad os se et SSR-lignende output:
<!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 tager, før en side bliver fuldt interaktiv. Det betyder:
- Siden har vist nyttigt indhold (FCP/LCP).
- Hændelseshandlere er registreret for de fleste synlige elementer i brugergrænsefladen.
- Siden reagerer på brugerinteraktioner inden for 50 millisekunder.
TTI er afgørende, fordi en bruger godt kan se indholdet, men stadig ikke være i stand til at klikke på knapper eller skrive i felter, hvis siden ikke er interaktiv.
SSR's TTI-udfordring: Hydrering
Selvom SSR leverer indhold hurtigt, sender det ofte statisk HTML. For at gøre denne HTML dynamisk og interaktiv skal JavaScript på klientsiden stadig indlæses og "overtage" DOM'en. Denne proces kaldes hydrering.
Under hydreringen tilknytter JavaScript hændelseslyttere og opbygger den virtuelle DOM. Hvis denne JS-pakke er stor eller tager lang tid at køre, kan den forsinke TTI, selv efter at indholdet er blevet synligt.
Sammenligning af TTI: SSR og CSR
Påvirkningen af TTI er forskellig:
- CSR: TTI ligger ofte tæt på FCP/LCP, fordi alt indhold og al interaktivitet indlæses samlet. Hvis JS-pakken er lille, kan TTI være hurtig.
- SSR: FCP/LCP er hurtige, men TTI kan blive forsinket, hvis hydreringen er langsom. Brugere kan se indholdet, men opleve en frustrerende "død zone", hvor intet reagerer.
Målet er at minimere dette mellemrum mellem synligt indhold og interaktivt indhold.
Vælg den rigtige tilgang
Valget mellem SSR og CSR afhænger af projektets behov:
- SSR er velegnet til: Indholdstunge websteder (blogs, e-handel), god SEO og hurtig indledende indlæsning for brugere med langsomme forbindelser.
- CSR er velegnet til: Meget interaktive webapplikationer (dashboards, feeds på sociale medier), hvor den indledende indlæsningstid er mindre vigtig end en omfattende brugeroplevelse efter indlæsningen.
Der findes også hybride tilgange som Static Site Generation (SSG) og Progressive Hydration, der kombinerer fordelene.
Hurtigt tjek: Renderingsstrategier
Ud fra det, vi har lært, hvilke udsagn beskriver korrekt kompromiserne mellem Server-Side Rendering (SSR) og Client-Side Rendering (CSR)?
Opsummering: SSR, CSR og TTI
I denne lektion undersøgte vi Server-Side Rendering (SSR) og Client-Side Rendering (CSR). Du lærte:
- CSR overlader renderingen til browseren, hvilket potentielt kan forsinke visningen af det indledende indhold, men samtidig giver dynamiske oplevelser.
- SSR renderer HTML på serveren og giver hurtigt indledende indhold (FCP/LCP), men kan forsinke interaktiviteten (TTI) på grund af hydrering.
- Time To Interactive (TTI) er afgørende, fordi målingen viser, hvornår en side er fuldt brugbar.
Valget mellem dem handler om at afveje den indledende indlæsningshastighed, behovet for interaktivitet og hydreringens påvirkning af TTI.
Lær Optimering af webydeevne og Lighthouse med en AI-underviser — gratis
Skriv og kør rigtig kode i din browser, få øjeblikkelig hjælp fra en AI-underviser døgnet rundt, og fortsæt, hvor du slap, på web eller i appen.
- Kurser
- 12
- Lektioner
- 48
Ofte stillede spørgsmål
Er lektionen “Indvirkning af serverside-rendering (SSR)” gratis?
Ja — hele teksten til “Indvirkning af serverside-rendering (SSR)” kan læses gratis her på nettet. Hvis du vil øve dig interaktivt med en indbygget kodeeditor og en AI-vejleder døgnet rundt og få adgang til resten af Optimering af webydeevne og Lighthouse-kurset, skal du opgradere til CoddyKit PRO. Optimering af webydeevne og Lighthouse-kurset indeholder 4 lektioner i alt.
Hvad lærer jeg i “Indvirkning af serverside-rendering (SSR)”?
Vurdér performanceafvejningerne mellem Server-Side Rendering (SSR) og Client-Side Rendering (CSR) samt deres indvirkning på TTI. Du øver dig i Optimering af webydeevne og Lighthouse med praktisk kode, som du kører direkte i browseren, og en AI-vejleder døgnet rundt besvarer dine spørgsmål, mens du arbejder dig gennem lektionen.
Skal jeg have erfaring for at begynde på Optimering af webydeevne og Lighthouse?
Der kræves ingen tidligere erfaring. Optimering af webydeevne og Lighthouse på CoddyKit er tilrettelagt for både begyndere og øvede, så du kan starte her eller fra begyndelsen og lære i dit eget tempo. Dette er lektion 3 af 4.
Hvor lang tid tager lektionen “Indvirkning af serverside-rendering (SSR)”?
De fleste CoddyKit-lektioner tager cirka 5–10 minutter. Hver lektion er kort og interaktiv, så du gør løbende fremskridt og kan fortsætte, hvor du slap – på både web og app.
Kan jeg skrive og køre kode i denne Optimering af webydeevne og Lighthouse-lektion?
Ja. Alle Optimering af webydeevne og Lighthouse-lektioner har en indbygget kodeeditor, så du kan skrive og køre rigtig kode direkte i din browser og få øjeblikkelig feedback fra AI – uden lokal opsætning.
Alle lektioner i dette kursus
- Performanceflaskehalse i backend
- Optimering af databaseforespørgsler
- Indvirkning af serverside-rendering (SSR)
- Caching og komprimering af API-svar