SvelteKit of Next.js: geen vaste winnaar bij Core Web Vitals

SvelteKit en Next.js hebben geen vaste prestatiewinnaar. Gepubliceerde meetresultaten verschillen per metriek en testopzet. Voor een nieuw project begint de keuze daarom bij de pagina’s die je bouwt, de serverfuncties die ze nodig hebben en het platform waarop ze draaien.

Een statische pagina, een servergerenderde pagina en een API-route leggen ander werk bij de browser en de server. Een benchmark van de ene applicatievorm voorspelt de uitkomst voor de andere niet. Ook het bestaande React- of Svelte-ecosysteem telt mee wanneer beide frameworks aan de technische eisen voldoen.

Wat de gepubliceerde meting wel laat zien

Dezelfde hotelreviewinhoud maakt zichtbaar dat laadsnelheid en visuele stabiliteit afzonderlijk worden beoordeeld.

In een SSR-proef met vier frameworks behaalde Next.js bij PageSpeed Insights in 12 van 21 scenario’s de beste LCP-waarde, terwijl SvelteKit in 18 scenario’s de beste CLS-waarde behaalde. In de afzonderlijke Lighthouse-reeks stond Next.js juist vaker bovenaan voor CLS. De rangorde hing dus zowel van de gemeten eigenschap als van de meetreeks af.

De onderzoekers bouwden applicaties met dezelfde interface en hotelreviewgegevens. Ze varieerden tekst, afbeeldingen en video en lieten de applicaties per scenario veel elementen serverrenderen. Dat maakt de vergelijking concreter dan een test met vier verschillende websites, maar het blijft een proef met één soort applicatie, een gekozen infrastructuur en specifieke frameworkversies. De resultaten beschrijven die volledige opstellingen; ze isoleren niet wat alleen het framework veroorzaakt.

Dezelfde publicatie bevat ook belastingproeven met JMeter. De bespreking van afzonderlijke proeven noemt Next.js geregeld als sterkste deelnemer, terwijl de overkoepelende analyse Nuxt en daarna SvelteKit gunstiger beoordeelt. Omdat die passages uiteenlopen, is een algemene rangorde onder belasting hier niet verantwoord. Een responstijd of verwerkingscapaciteit onder gesimuleerde verzoeken beantwoordt bovendien een andere vraag dan hoe snel een bezoeker de inhoud ziet.

Googles omschrijving van Core Web Vitals onderscheidt LCP voor laden, INP voor interacties en CLS voor visuele stabiliteit. De genoemde proef rapporteert LCP en CLS, maar geen INP uit gebruik in de praktijk. Ook FCP, TBT, Speed Index en een algemene Lighthouse-score mogen daarom niet worden behandeld als een volledig oordeel over de Core Web Vitals van een productieapplicatie.

Statische pagina’s: vergelijk wat er werkelijk wordt geleverd

Een hotelreviewpagina laat het verschil zien tussen vooraf gebouwde statische uitvoer en levering via een server.

Voor documentatie, artikelen of andere pagina’s waarvan de inhoud bij het bouwen vaststaat, kunnen beide frameworks HTML vooraf genereren. De server hoeft die pagina dan niet bij elk bezoek opnieuw op te bouwen. De waarneembare snelheid hangt vervolgens sterk samen met de geleverde afbeeldingen, browsercode, caching en de afstand tussen bezoeker en hosting. Een SSR-proef met dynamische hotelreviews zegt over deze vorm van levering weinig.

Bij SvelteKit zet een adapter de gebouwde applicatie om voor het gekozen doelplatform. De SvelteKit-documentatie over adapters noemt onder meer statische uitvoer, Node-servers en platformdiensten. De adapter is daarmee meer dan een laatste instelling voor publicatie: hij bepaalt welk soort uitvoer de hosting ontvangt. Een statische site heeft een andere verzoekroute en andere mogelijkheden dan een applicatie met servercode.

Ook Next.js kan vooraf gebouwde bestanden leveren. De implementatieopties van Next.js omvatten een Node-server, Docker, statische uitvoer en platformadapters. Volgens die documentatie ondersteunt een statische export slechts een deel van de functies; de mogelijkheden van adapters verschillen eveneens per platform. Een pagina die bij ieder verzoek persoonlijke gegevens op de server nodig heeft, past dus niet zonder aanpassing in een volledig statische export.

SSR: serverwerk en browserwerk tellen allebei

Bij server-side rendering ontstaat de pagina tijdens een verzoek. De tijd tot zichtbare inhoud wordt dan mede bepaald door gegevensbronnen, serverlocatie en caching. Twee vergelijkbare pagina’s kunnen anders presteren als de ene dichtbij de database draait en de andere voor ieder verzoek een externe dienst aanspreekt. Dat verschil aan het framework toeschrijven zou de rol van de infrastructuur verbergen.

Next.js heeft in de App Router bovendien een grens tussen Server Components en Client Components. Volgens de uitleg over beide componenttypen zijn pagina’s en layouts standaard Server Components en worden Client Components ingezet voor interactiviteit en browserfuncties. Waar die grens ligt, beïnvloedt hoeveel JavaScript de browser moet ontvangen en uitvoeren. Een pagina met één interactieve knop is daardoor een andere prestatieproef dan dezelfde pagina wanneer een groot deel van de interface clientcode wordt.

Bij SvelteKit spelen vergelijkbare vragen over gegevensverzoeken, geleverde code en interactie na de eerste weergave. Voor een zinvolle vergelijking van SSR moeten de pagina-inhoud, gegevensbron, caching en hostingcondities op elkaar lijken. Meet daarnaast de eerste paginalading apart van latere interacties: een snelle serverreactie zegt op zichzelf niets over de tijd die de browser daarna nodig heeft.

API-routes maken hosting een functionele eis

Een formulierverwerking of route met actuele, verzoekgebonden gegevens vraagt om code die tijdens een verzoek kan draaien. Een volledig statische site kan die taak alleen via een aparte dienst uitvoeren. Daarmee verandert niet slechts de reactietijd, maar ook de architectuur: browser, paginahost en API kunnen elk op een andere plek staan en afzonderlijk worden gecachet.

Vergelijk een API-route daarom als complete verzoekketen. De uitvoering van de handler, een eventuele databaseaanroep en de verwerking van het antwoord in de browser dragen ieder bij aan wat de gebruiker merkt. LCP meet niet hoeveel gelijktijdige verzoeken een route aankan; een snelle route garandeert evenmin een snelle pagina als daarna veel clientcode draait. De juiste hostingkeuze moet eerst de benodigde serverfuncties ondersteunen en daarna de prestatie-eisen kunnen halen.

Welke keuze past bij het project?

Voor een overwegend statische site kunnen SvelteKit en Next.js allebei passen. Vergelijk dan dezelfde vooraf gebouwde pagina’s op de beoogde hosting, inclusief afbeeldingen en browsercode. Voor een dynamische applicatie wegen de beschikbare serverfuncties, caching en de afstand tot gegevensbronnen zwaarder. Daar hoort een vergelijking van representatieve SSR-pagina’s en routes bij, onder dezelfde belasting en op vergelijkbare infrastructuur.

Als die randvoorwaarden beide opties toelaten, wordt het bestaande ecosysteem een praktisch onderscheid. Een team met React-componenten en ervaring met de App Router kan daarop voortbouwen in Next.js; een team dat al met Svelte werkt, kan die componenten en werkwijze in SvelteKit aanhouden. De gepubliceerde benchmark geeft aandachtspunten voor laden, stabiliteit en belasting, maar de relevante winnaar kan pas worden vastgesteld voor de applicatievorm en hosting die het project werkelijk gebruikt.