Server-Side Rendering vs Static Generation voor productpaginas

Server-Side Rendering vs Static Generation voor productpaginas

Bij een catalogus van 50.000 producten kost een volledige SSG-build al gauw 45 minuten. Ondertussen veranderen prijzen meerdere keren per dag. Dat is het kernprobleem van Server-Side Rendering vs Static Generation voor productpaginas: versheid versus snelheid, met SEO als derde factor die alles compliceerder maakt.

Dit artikel legt uit welke render-strategie werkt voor welk type catalogus — en wanneer je juist een hybride aanpak kiest.

Wat is het verschil eigenlijk?

De keuze heeft directe impact op conversie, crawl-budget en infrastructuurkosten.

Het probleem met productpaginas: data-versheid

Productpaginas zijn niet statisch van aard. Ze bevatten:

• Prijs — kan meerdere keren per dag wijzigen (promoties, B2B-segmentatie, valutakoers)
• Voorraadstatus — realtime relevant voor koopbeslissing en Google Merchant Center
• Varianten — een kleur of maat kan plotseling uitverkopen

Bij SSG is de HTML zo oud als de laatste build. Een klant ziet "Op voorraad", klikt door, en de voorraad is al uren geleden uitverkocht. Dat kost conversie en schaadt de gebruikerservaring.

Wij zien bij klanten met dynamische prijsregels — kortingen per klantsegment, bundelprijzen, inkoopprijzen — dat SSG in de praktijk onhoudbaar wordt. De build-frequentie die je nodig hebt om data actueel te houden, ondermijnt precies het voordeel van SSG. Een build elke 15 minuten is niet hetzelfde als realtime: in die tijd kan een flash sale starten of een variant uitverkopen.

SEO en crawlability: de nuance

Google kan JavaScript renderen, maar doet dat vertraagd. Statische HTML wordt direct geïndexeerd. Dat maakt SSG en SSR allebei beter dan client-side rendering voor productpaginas.

Het verschil tussen SSR en SSG voor SEO is kleiner dan veel mensen denken. Beide leveren pre-rendered HTML. Het voordeel van SSG is consistente response-tijden op CDN-niveau (Time to First Byte onder 50ms). SSR-variatie zit doorgaans tussen 100–400ms TTFB, afhankelijk van caching.

Praktisch advies: zorg altijd voor een goed ingerichte Cache-Control-header, zelfs bij SSR. Een s-maxage=300 op productpaginas betekent dat een reverse proxy of CDN die pagina 5 minuten cachet. Zo profiteer je van SSR-versheid zonder per request de backend te belasten. Combineer dat met stale-while-revalidate=60 voor een extra buffer tijdens piekverkeer.

Build-tijden bij grote catalogi

Dit is waar SSG de muur raakt. Buildtijd is geen abstracte metriek — het bepaalt hoe snel je een prijsfout kunt herstellen, een uitverkocht product kunt markeren, of een nieuw artikel live kunt zetten.

Bij Next.js zijn buildtijden sterk afhankelijk van je dataprovider, parallelisatie en of je afbeeldingen ook in de build verwerkt. Reken op ruwweg 1–3 seconden per pagina voor een eenvoudige productpagina zonder zware beeldoptimalisatie.

Bovendien: bij elk nieuw product moet je opnieuw bouwen. Bij een dagelijkse catalogusaanvulling van 100+ producten leidt dat tot een vrijwel continue build-pipeline — wat het operationele voordeel van SSG wegneemt.

Wij zien bij klanten met Magento-catalogi van 50.000+ producten dat SSG simpelweg niet werkbaar is voor de volledige productcatalogus. Je bouwt dan liever category-paginas statisch (stabiele structuur, minder dynamisch) en producten via SSR of ISR.

Caching: het echte schaakspel

SSR wordt pas schaalbaar met een goede cache-strategie. De lagen:

Cloudflare, Fastly of Vercel Edge cachen de HTML dichter bij de gebruiker. Stel per pagina-type een TTL in die past bij de data-versheid. Voor een productpagina: 1–5 minuten is doorgaans acceptabel.

Bij eigen hosting op DigitalOcean of een dedicated server: Varnish of Nginx als caching-proxy voor de Node.js/PHP-applicatie. Hiermee absorbeer je piekverkeer zonder de origin-server te belasten.

Sla externe API-responses (bijv. Magento REST, Shopify Storefront API) op in Redis of Memcached. Typische TTL: 30–120 seconden voor prijs en voorraad. Dit geeft SSR de snelheid van SSG zonder de stale-data-problemen.

Een eenvoudig patroon in een Next.js API-route met Redis:

// lib/cache.ts
import { createClient } from 'redis';

const client = createClient({ url: process.env.REDIS_URL });

export async function getCachedProduct(sku: string) {
  const cached = await client.get(`product:${sku}`);
  if (cached) return JSON.parse(cached);

  const product = await fetchFromMagento(sku);
  await client.setEx(`product:${sku}`, 60, JSON.stringify(product)); // 60s TTL

  return product;
}

Met dit patroon serveert SSR productdata die maximaal 60 seconden oud is — acceptabel voor de meeste webshops — en is de daadwerkelijke response-tijd vergelijkbaar met SSG.

ISR: de middenweg die niet altijd werkt

ISR klinkt als de perfecte oplossing. In de praktijk heeft het beperkingen:

• Statische HTML bij eerste request (snel)
• Automatisch regenereren op interval
• Geen volledige rebuild bij cataloguswijzigingen

• Eerste bezoeker na revalidatie krijgt nog de oude pagina (stale-while-revalidate)
• Geen on-demand invalidatie zonder extra implementatie
• Bij grote catalogi: ook ISR heeft cold-start bij nieuwe producten
• Niet beschikbaar buiten Next.js-ecosysteem (hoewel vergelijkbare patronen bestaan in Nuxt/Astro)
• Monitoring is complexer: je hebt tooling nodig om te verifiëren dat revalidaties daadwerkelijk slagen

Voor productpaginas met realtime-vereisten (B2B, flash sales, schaars aanbod) is ISR niet toereikend. De stale-while-revalidate-aanpak betekent dat iemand een prijs ziet die al gewijzigd is. Dat geeft problemen bij checkout — en frustreert klanten. Een klant die een product in zijn winkelmandje stopt op basis van een verkeerde prijs, en die prijs bij checkout gecorrigeerd ziet, haakt af.

Welke strategie past bij welk catalogustype?

De keuze is geen technisch dogma, maar een businessbeslissing.

• Catalogus is klein (< 5.000 producten) en stabiel
• Prijzen en voorraad veranderen zelden (1x per dag of minder)
• Maximale performance zonder infrastructuurcomplexiteit is de prioriteit
• Budget voor hosting is beperkt

• Catalogus is groot (50.000+) of groeit snel
• Dynamische prijsstelling (B2B, segmenten, real-time)
• Voorraad is kritisch en wisselt snel (mode, limited editions)
• Gepersonaliseerde productpaginas nodig zijn

• Middelgrote catalogus (1.000–20.000 producten)
• Prijzen en voorraad mogen tot 1–5 minuten achterlopen
• Je al in het Next.js-ecosysteem zit

• Categorie- en CMS-paginas via SSG, productpaginas via SSR
• Productlijsten statisch, price/stock-fragment client-side geladen via API
• Edge-cache voor het gros, on-demand revalidatie via webhook bij cataloguswijziging

Headless Magento en Shopify: praktijk

Bij Magento headless-trajecten zien wij meestal een hybride aanpak. De productcatalogus is te groot voor volledige SSG. Wij bouwen category-paginas statisch en regenereren die via Magento-webhooks bij categorie-updates. Productpaginas draaien op SSR met Redis-caching voor prijs en voorraad.

Bij Shopify is de situatie anders. De Storefront API heeft rate-limits (doorgaans 2 requests/seconde voor onbetaalde tier). Bouwtijden bij SSG met grote catalogi worden dan bepaald door API-throttling, niet door rekenkracht. ISR of SSR met agressieve Redis-caching is hier praktischer.

Bij maatwerk in Laravel bouwen wij backend-API's die cache-aware zijn. De API exposed een Cache-Control-header per resource, zodat de frontend weet hoe agressief hij mag cachen. Een inventory-endpoint geeft s-maxage=30, een statische productbeschrijving s-maxage=3600.

De kosten kant

SSG heeft lage infrastructure-kosten: statische bestanden op een CDN zijn goedkoop. SSR vereist compute — een server die requests verwerkt. Reken bij schaling op Node.js-containers of serverless functions.

Maar vergeet de verborgen kosten van stale data. Een onjuiste prijs op een productpagina kan leiden tot chargebacks, retourzendingen of reputatieschade. Bij B2B met klantspecifieke prijsafspraken is stale SSG-data simpelweg onacceptabel.

De ROI-afweging: hogere hostingkosten bij SSR versus conversieverlies en handmatig werk bij SSG-beheer. Voor de meeste serieuze webshops wint SSR met goede caching op de lange termijn. Een Node.js container op DigitalOcean kost ruwweg €10–40 per maand — dat weegt niet op tegen één gemiste order door een stale prijs of een klacht over onjuiste voorraadinfo.

Veelgestelde vragen

Beide leveren pre-rendered HTML, wat Google direct kan indexeren. SSG scoort iets beter op TTFB door CDN-delivery. Voor SEO maakt het verschil in de praktijk weinig uit, zolang je HTML server-side gerenderd is en de pagina snel laadt. Zorg voor correcte canonical-tags, structured data en goede Core Web Vitals — dat heeft meer impact.

Ja. Dit is een veelgebruikte hybride: de productpagina is statisch, maar prijs en voorraadstatus worden client-side opgehaald via een lichtgewicht API-call. Nadeel: korte flicker bij laden, en de getoonde prijs is niet direct zichtbaar voor crawlers. Voor Google Shopping-feeds heb je dan een aparte data-pipeline nodig.

Bij een goed geconfigureerde setup serveert ISR statische paginas in 20–50ms TTFB via Vercel Edge. De revalidatie gebeurt op de achtergrond. Zorg voor on-demand revalidation via res.revalidate() als je directe invalidatie bij cataloguswijzigingen nodig hebt — het polling-interval alleen is dan niet voldoende.

Als je build-pipeline langer dan 30 minuten duurt voor routinewijzigingen, als deployment-frequentie lager is dan nodig door buildtijden, of als klachten over stale data structureel binnenkomen. Dan is het tijd voor SSR met edge-caching, of een hybride per pagina-type. Wil je sparren over de beste aanpak voor jouw catalogus? Neem contact op.