Astro of Next.js: renderstrategie bepaalt de prestatie

Voor een contenttoepassing bepaalt de gekozen renderstrategie mede hoe Astro en Next.js presteren; geen van beide frameworks wint op alle meetwaarden. In een vergelijking van gelijkwaardige contentpagina’s bedroeg bij statische generatie (SSG) de gemiddelde Total Blocking Time 173 ms voor Astro en 1137 ms voor Next.js, terwijl de gemiddelde Largest Contentful Paint juist 3939 ms voor Astro en 1938 ms voor Next.js was.

Voor een site met vooral artikelen is Astro aantrekkelijk als je browsercode wilt beperken. Next.js kan bij dezelfde soort pagina de belangrijkste zichtbare inhoud sneller tonen, zoals in deze proef gebeurde. Bepaal daarom eerst welke pagina’s vooraf, op verzoek of in de browser worden opgebouwd, en welke prestatie voor hun bezoekers het zwaarst weegt.

Wat er in de proef gelijk bleef

De SSG-proef met dezelfde contentpagina toont een lagere blokkeringstijd voor Astro en een snellere weergave van het grootste element voor Next.js.

De vergelijking gebruikte twee contenttoepassingen met dezelfde vormgeving, inhoud en functionaliteit. De onderdelen waren waar mogelijk uit dezelfde React-componenten opgebouwd. Beide toepassingen gebruikten dezelfde databron en hetzelfde hostingplatform; per framework waren er pagina’s met SSG, serverrendering (SSR) en clientrendering (CSR). Daarmee werd dezelfde taak onder verschillende combinaties van framework en renderstrategie gemeten.

De pagina had een fotokop en een raster van artikelen met afbeeldingen. Dat maakt de resultaten relevanter voor een publicatiesite dan een test van lege startersprojecten. De afbeeldingen en opmaak waren gelijk, maar de omvang van de JavaScriptpakketten verschilde. Het gemeten resultaat hoort dus bij de volledige implementatie, inclusief de gebruikte componenten en de manier waarop inhoud en beeldmateriaal werden geleverd.

De proef laat zien welke verschillen onder die omstandigheden optraden. Een andere beeldverwerking, caching, hostingomgeving of invulling van interactieve onderdelen kan de verhouding op een productiesite veranderen. Vooral een losse vergelijking van bundelgroottes zou de uitkomst versimpelen: de kleinere clientbundel van Astro ging hier samen met minder blokkeringstijd, maar ook met een later zichtbaar grootste element.

Waarom minder JavaScript vooral browserwerk scheelt

Een interactieve Astro-component staat los van de statische inhoud van een artikelpagina.

Astro is ingericht op pagina’s waarvan veel onderdelen gewone inhoud blijven. De Astro-documentatie over islands beschrijft dat componenten standaard als HTML en CSS worden geleverd; alleen expliciet gemarkeerde interactieve onderdelen krijgen JavaScript voor de browser. Een zoekveld kan daardoor worden geactiveerd zonder de omliggende artikelinhoud als interactieve toepassing te behandelen.

Dat ontwerp past bij de lagere Total Blocking Time in de gemeten Astro-varianten. Die waarde telt perioden waarin langlopende taken de hoofdthread bezet houden. Minder code om te laden en uit te voeren kan daar helpen, vooral wanneer interactie maar een klein deel van de pagina betreft. De maat zegt echter niet wanneer een grote afbeelding of de hoofdinhoud zichtbaar wordt.

Ook Next.js kan serverwerk en browserwerk scheiden. Volgens de Next.js-documentatie over componenten zijn pagina’s en lay-outs standaard Server Components en worden Client Components toegevoegd waar toestand of browserinteractie nodig is. Hoeveel JavaScript uiteindelijk bij de bezoeker terechtkomt, hangt dus ook af van waar ontwikkelaars die grens leggen. Bij veel interactieve onderdelen kan in beide frameworks de hoeveelheid clientcode oplopen.

Welke meetwaarde het verschil zichtbaar maakt

First Contentful Paint (FCP) markeert het eerste zichtbare stukje inhoud; Largest Contentful Paint (LCP) het verschijnen van het grootste zichtbare element. In de proef lag FCP tussen de varianten betrekkelijk dicht bij elkaar, terwijl Next.js bij LCP in elke onderzochte renderstrategie voorlag. Een vroege eerste weergave betekende hier dus niet automatisch dat ook de prominente inhoud snel compleet was.

Total Blocking Time (TBT) beschrijft iets anders: hoeveel tijd de browser tijdens het laden door langlopende taken wordt geblokkeerd. Astro scoorde daarop doorgaans gunstiger. Voor een lezer die vooral een artikel wil zien, kan LCP zwaar wegen; op een pagina die meteen bediening vraagt, verdient TBT extra aandacht. Het zijn verschillende aspecten van dezelfde ervaring, geen onderling uitwisselbare snelheidsscores.

De Speed Index volgt hoe snel de zichtbare pagina zich vult. In deze meting was die bij beide frameworks gunstiger met SSG dan met CSR; Next.js lag binnen de gemeten SSG- en SSR-varianten voor op Astro. Bij Cumulative Layout Shift (CLS), de maat voor verspringende zichtbare elementen, waren de uitkomsten per renderstrategie voor beide frameworks gelijk. Een ranglijst die alleen JavaScript of alleen LCP toont, laat die verschillende patronen weg.

SSG, SSR en CSR verplaatsen het werk

Met SSG wordt de HTML vooraf tijdens de bouw gemaakt. SSR stelt de pagina op verzoek samen op de server, terwijl bij CSR meer opbouw in de browser plaatsvindt. Daardoor veranderen het moment waarop inhoud beschikbaar is en de plek waar verwerking gebeurt. Astro met SSG naast Next.js met CSR zetten zou tegelijk het framework én de renderstrategie wijzigen.

De Speed Index van de onderzochte pagina’s laat zien waarom dat onderscheid ertoe doet: de statische variant was in beide frameworks sneller gevuld dan de clientgerenderde variant. Dat is een resultaat voor deze contentpagina, geen vaste verhouding voor elke website. Grote afbeeldingen, aanvullende scripts en trage gegevensbronnen kunnen het voordeel van vooraf gemaakte HTML beperken; bij SSR bepaalt ook het serverantwoord wanneer de inhoud verschijnt.

De keuze hoeft bovendien niet voor een hele site hetzelfde te zijn. De Astro-uitleg over rendering op verzoek beschrijft hoe afzonderlijke routes, met een serveradapter, per bezoek kunnen worden gemaakt terwijl andere routes statisch blijven. Een openbaar artikel kan zo vooraf worden opgebouwd en een accountpagina actuele persoonlijke gegevens ophalen. Next.js biedt eveneens server- en clientcomponenten per pagina of onderdeel; in beide gevallen bepaalt de route welke combinatie zinvol is.

Welke keuze past bij het project?

Dezelfde contentcollectie levert een statische artikelpagina en een afzonderlijk veranderlijke persoonlijke pagina op.

Een redactionele site of documentatieplatform met hoofdzakelijk openbare pagina’s heeft vaak baat bij vooraf gemaakte HTML en weinig clientcode. Astro geeft dat patroon een duidelijke standaard. Next.js blijft passend wanneer het team dezelfde React-componenten, routes en serverlogica met een bestaande toepassing wil delen. Voor de zichtbare artikelinhoud verdient de LCP-uitkomst uit de proef daarbij evenveel aandacht als Astro’s gunstige TBT.

Een contentplatform met persoonlijke onderdelen vraagt om een keuze per route. Publicatiepagina’s kunnen statisch zijn, terwijl een accountgedeelte inhoud op verzoek krijgt. Beide frameworks ondersteunen die scheiding. De prestatie van de openbare pagina zegt dan weinig over de persoonlijke route: die wacht mogelijk op andere gegevens en bevat andere interactie.

Een sterk interactieve webapplicatie stelt andere eisen dan een artikelraster. Wanneer toestand, bediening en navigatie door veel schermen lopen, kan de volledige React-stack van Next.js de samenhang van de toepassing vereenvoudigen. Astro blijft bruikbaar als de interactieve delen goed af te bakenen zijn. De doorslaggevende vraag is dan hoeveel van de ervaring werkelijk in de browser moet draaien, naast hoe snel de eerste inhoud verschijnt.