Astro vs Next.js voor MKB.

De twee in één paragraaf

Astro (2021) is een static-site generator met "islands"-architectuur. Default: zero JavaScript op de client. Voor stukken die interactiviteit nodig hebben (carousel, search, form-validation) "hydrateer" je een React/Vue/Svelte-component als geïsoleerde island. Bouw-time-output: pure HTML/CSS, JS alleen waar nodig.

Next.js (2016, Vercel) is een React-meta-framework. Sinds versie 13 met App Router en React Server Components: hybride server/client rendering. Statisch, SSR (server-side rendering), of ISR (incremental static regeneration) — alles kan. Sterk in apps die data-fetching, auth en real-time nodig hebben.

Bundle-size benchmark

Een identieke MKB-landingspagina (hero, 3 features, testimonial, contact-form, footer) gebouwd in beide:

Astro is ~5x kleiner voor identieke content. Voor performance puristen het verschil tussen "snel" en "extreem snel". Voor de meeste eindgebruikers niet merkbaar — beide laden in <2s op een 4G-verbinding.

Wanneer Astro wint

Astro is gemaakt voor content-sites. Het wint als:

• Marketing-site, MKB-bedrijfssite, agency-portfolio, blog
• Maximale Lighthouse-score belangrijk (SEO, Core Web Vitals)
• Content uit Markdown, Sanity, Contentful, Payload of headless WordPress
• Lage hosting-kosten (Vercel/Netlify/Cloudflare Pages free tiers werken vaak)
• Geen complexe auth, state, of real-time features

Wanneer Next.js wint

Next.js is gemaakt voor app-achtige sites. Het wint als:

• SaaS-dashboard, klantportaal, member-area
• Complexe interactiviteit: configurator, multi-step booking, real-time chat
• Server-side data-fetching met auth (Stripe, Supabase, NextAuth)
• ISR nodig: content vernieuwt elke X minuten zonder rebuild
• Team werkt al in React, bestaande componenten herbruikbaar

Leercurve

Astro is dramatisch makkelijker. Wie HTML+CSS+vanilla-JS kent kan na een dag Astro-sites bouwen. Componenten lijken op .vue of .svelte-bestanden met frontmatter. Geen state-management, geen lifecycle-hooks, geen "use client"-grenzen.

Next.js vereist React-mastery + begrip van Server Components vs Client Components + data-fetching patterns. Junior developer reken op 6-8 weken tot productiviteit. Senior React-dev: 1-2 weken.

Voor MKB-onderhoud: Astro maakt het makkelijker om een externe developer te vinden die je site kan beheren. Markt voor "junior Astro dev" is breder en goedkoper dan "senior Next.js dev".

Hosting + kosten

Astro is goedkoper te hosten omdat het pure static output kan zijn. Voor een MKB-marketing-site met <50k bezoekers/maand: gratis op alle providers. Next.js wordt duurder bij SSR/ISR-gebruik door function-invocaties.

Use-cases die we bouwen bij DesignCheck

Bij DesignCheck Mijdrecht:

• Astro: 6 MKB-marketing-sites in laatste 12 maanden — hovenier, advocaat, tandarts, klusbedrijf, fotograaf, restaurant.
• Next.js: 1 klantportaal voor een transportbedrijf (login + ritplanning + facturen). Hier kon Astro niet.

De 6:1 ratio is geen Astro-bias — het is wat Nederlandse MKB-sites typisch nodig hebben. Content + contact + portfolio. Geen dashboard, geen real-time, geen complex.

Wanneer geen van beide

Als de site beheerd moet worden door iemand zonder code-skills: Webflow. Astro/Next.js vereisen een ontwikkelaar voor elke content-update tenzij je een headless CMS koppelt (Payload, Sanity, Decap).

Lees: Payload vs Sanity als je dit wel wil.

Architectuur in detail: islands vs server-components

Het concept "island" bij Astro is letterlijk: een component die alleen op die plek interactief is, omringd door statische HTML. Je import bijvoorbeeld een React-zoekbalk in een Astro-pagina en zet er client:visible op. Astro genereert dan een paar honderd bytes loader-script dat de React-bundle pas downloadt als de zoekbalk in beeld komt. De rest van de pagina is pure HTML.

Next.js werkt met server-components als default in de App Router. Server-components renderen op de server, sturen HTML én een serialized React-payload mee, en hydrateren stukjes die interactief moeten zijn. Voor een complexe app is dat krachtig — voor een MKB-marketing-site is het overkill. De serialized payload is groot, ook bij content die nooit verandert.

Concreet voorbeeld. Een productpagina met 8 features, drie testimonials en een FAQ-accordeon. In Astro: één Astro-component met statische content, de accordeon als island met client:idle (laadt zodra de browser idle is). Output: 18kb totaal. In Next.js App Router: dezelfde pagina als server-component met "use client"-onderdelen voor de accordeon. Output: ~95kb, waarvan 80kb React-runtime.

Voor MKB-sites met traffic uit Google is dat verschil meetbaar. Lighthouse Total Blocking Time (TBT) bij Astro: typisch <30ms. Bij Next.js: 80-200ms. Beide passeren het "goed"-criterium van Google (<200ms), maar Astro heeft meer marge bij oudere telefoons.

Tooling, plugins en ecosysteem

Next.js heeft het volwassenere ecosysteem. Authentication (NextAuth, Clerk, Supabase Auth), payments (Stripe SDK met server-actions), CMS (alles), images (next/image, het beste image-component dat er is), middleware (edge runtime voor A/B-tests en geo-redirects). Wie een SaaS bouwt vindt voor elk probleem een kant-en-klare library.

Astro heeft een kleinere maar gerichte set. Astro Image is goed (Sharp onder de motorkap), Astro Content Collections is uitstekend voor type-veilige markdown, integraties voor alle grote frameworks (React, Vue, Svelte, Solid, Preact) zodat je per island kan kiezen. Voor MKB-sites dekt dit 95% van de behoefte.

Waar Astro tekortschiet: complexe authenticatie en sessie-state. Voor login-flows met magic-links, OAuth-providers en role-based access is Next.js sneller te bouwen. Astro kan het — het ecosysteem is alleen kleiner, dus je schrijft meer custom-code.

Waar Next.js tekortschiet voor MKB: simpelweg dat alles dubbel zo veel werk is voor een marketing-site. Een Astro-bouwer levert dezelfde site in 60-70% van de tijd. Dat scheelt €1.000-€2.000 op een rebuild-budget.

Inhoudelijk vergelijken: 10 use-cases naast elkaar

De boodschap is consistent. Statische content + lichte interactiviteit: Astro. App-functionaliteit met state, auth en server-data: Next.js.

Kosten over 3 jaar — totale cost of ownership

Een Astro-marketingsite kost gemiddeld €0-€20/maand aan hosting (Vercel of Netlify free tier dekt <100GB-traffic), nul aan licenties, en €40-€90 per kleine update bij een externe ontwikkelaar. Over drie jaar: €0-€720 hosting plus eventuele update-uren.

Een Next.js-site op Vercel met SSR-pagina's loopt sneller op tegen function-invocations. Bij 10k page-views per maand: nog free tier. Bij 100k: typisch €20-€40/maand. Bij 500k+: €100-€300/maand. Over drie jaar voor een groeiende MKB-site: €1.000-€10.000.

Voor de meeste MKB-sites verandert dat de keuze niet — het verschil is niet dramatisch. Maar als je site groeit naar grotere traffic-niveaus betaalt Astro zichzelf consistenter terug.

Stappenplan: zo kies je in 30 minuten

1. Schrijf in één zin op wat je site doet. Marketing met portfolio? Astro. Klanten logen in en doen iets? Next.js.
2. Tel het aantal pagina's dat dynamisch is (verandert per user). Onder de 3: Astro. Boven de 10: Next.js.
3. Inventariseer welke libraries je écht nodig hebt. Auth-provider met OAuth? Stripe-checkout met server-actions? Realtime chat? > Next.js.
4. Check wie de site over een jaar gaat onderhouden. Iemand zonder veel React-ervaring? Astro. React-team al aanwezig? Next.js.
5. Test Lighthouse-eisen. Moet je 95+ scoren voor SEO-doelen? Astro is veiliger.
6. Bereken hosting-kosten op basis van verwachte traffic. Onder 50k bezoekers/maand: maakt nauwelijks uit. Boven 200k: Astro voordeliger.
7. Vraag drie ontwikkelaars uit je netwerk wat ze zouden kiezen. Als 2 of meer Astro zeggen voor jouw use-case: ga ermee verder.
8. Bouw een prototype van één pagina in beide. Een dag werk. Welke voelt natuurlijker voor je content-type?
9. Schrijf het maintenance-scenario op. Wie typt een nieuwe blog-post? Astro Content Collections of CMS? Next.js + headless CMS? Beide werken, maar de keuze beïnvloedt het CMS.
10. Beslis. Twijfel langer dan een week = waarschijnlijk Astro (90% van MKB-sites past beter daar). Bij twijfel kiezen voor de optie met de laagste lock-in.

Veelvoorkomende migratie-scenario's

Van WordPress naar Astro. De meest voorkomende migratie bij Nederlandse MKB-sites. Reden: trage WordPress-installaties met te veel plugins, Lighthouse onder de 40, beheerlast die uit de hand loopt. Astro-rebuild met content uit een export of headless WordPress: typisch 2-3 weken. Lighthouse na de migratie: 95-100. Bij grote content-archieven (1.000+ posts) gebruik je Astro Content Collections of een headless CMS.

Van Wix of Squarespace naar Next.js. Komt voor als de site groeit naar een soort web-app met klantlogins en custom features. De export uit Wix is beperkt (HTML zonder structuur). De rebuild is dus eerder een redesign vanaf nul. Tijd: 3-5 weken. Voordeel: vendor-lock-in weg, ranking-controle terug.

Van Next.js Pages Router naar App Router. Geen platform-wissel, wel een grote upgrade. Next.js team raadt het sterk aan. Migratie duurt 1-3 weken afhankelijk van project-grootte. Voordelen: server-components, betere data-fetching, kleinere client-bundles. Risico: oudere libraries werken soms niet met App Router (Drizzle, sommige auth-providers vereisen aanpassingen).

Van Gatsby naar Astro. Voor wie Gatsby al jaren gebruikt en de build-tijden te lang vindt. Astro lijkt qua filosofie op Gatsby maar produceert kleinere bundles en heeft een actievere community. Veel Gatsby-gebruikers stappen sinds 2024 over.

Performance-cijfers uit live klantsites

We meten elke maand de Core Web Vitals van klantsites. De Astro-sites uit de portfolio scoren consistent:

• Largest Contentful Paint: gemiddeld 0.9s (Google-target <2.5s)
• Interaction to Next Paint: gemiddeld 64ms (target <200ms)
• Cumulative Layout Shift: gemiddeld 0.02 (target <0.1)
• Total Blocking Time: gemiddeld 18ms (target <200ms)
• Speed Index: gemiddeld 1.1s

De Next.js-build van Keurmeesters — onze live klant met BAG-API-integratie en energielabel-zoekopdrachten — scoort iets lager omdat de API-integratie real-time data ophaalt: LCP 1.4s, INP 96ms. Nog steeds ruim binnen Google's "goed"-grenzen, maar duidelijk in lijn met het verwachte verschil van ~30-50% trager dan een statisch alternatief.

Voor jouw site geldt: een statische Astro-build is overkill voor een doorsnee MKB-bedrijfssite. Het verschil tussen 0.9s en 1.4s LCP merkt vrijwel niemand. Het verschil tussen 4.5s (een trage WordPress-site) en 0.9s merkt iederéén — dat is de echte hefboom van een rebuild.

Veelgemaakte fouten bij de stack-keuze

Fout 1: Next.js kiezen omdat het populairder is. Populariteit is geen criterium. Voor een marketing-site verlies je twee dingen met Next.js: snelheid en eenvoud. Beide raken je SEO en je onderhoudskosten. Kies op basis van use-case, niet op basis van wat je netwerk gebruikt.

Fout 2: Astro kiezen voor een site die in feite een web-app is. Spiegelbeeld van fout 1. Een ledenportaal met inlogfunctionaliteit, persoonlijke dashboards en real-time updates kun je in Astro forceren, maar je vecht tegen het framework. Next.js (of een SaaS-platform zoals Supabase met React) is dan beter.

Fout 3: Een framework laten kiezen door wat je hosting-provider promoot. Vercel duwt Next.js, Netlify duwt Astro, Cloudflare promoot Pages. Alle drie hosten beide stacks. Hosting is een infrastructure-keuze, niet een framework-keuze. Kies framework eerst.

Fout 4: Server-componenten van Next.js overslaan. Veel Next.js-projecten gebruiken alleen Client Components ("use client" overal). Resultaat: alle nadelen van Next.js zonder de voordelen. Als je toch alleen client-side rendert, gebruik dan een lichtere stack zoals Vite + React.

Fout 5: Geen CMS plannen. Beide frameworks vereisen een content-strategie. Schrijf je zelf alle content in code? Prima voor 5 pagina's. Voor 30+ pagina's of frequente updates: koppel een headless CMS. Zonder plan verandert de "wij doen het zelf"-belofte snel in maandelijkse facturen voor je ontwikkelaar.

Snelheid-test: wat Google echt meet

Google Search Console rapporteert Core Web Vitals per pagina, gegroepeerd in "Goed", "Verbetering nodig" en "Slecht". De drempels:

• Largest Contentful Paint: <2.5s = goed, 2.5-4s = verbetering, >4s = slecht
• Interaction to Next Paint: <200ms = goed, 200-500ms = verbetering, >500ms = slecht
• Cumulative Layout Shift: <0.1 = goed, 0.1-0.25 = verbetering, >0.25 = slecht

Bij een Astro-site zit je vrijwel automatisch in alle drie groene zones. Bij Next.js moet je goed letten op INP — interactieve elementen die zwaar JavaScript laden kunnen je INP boven 200ms krijgen, vooral op midrange Android-telefoons. De fix: dynamische imports, code-splitting, en serieus nadenken over welke componenten écht client-side moeten.

Google neemt sinds maart 2024 INP mee als ranking-signaal (was eerst First Input Delay). Voor Next.js-builds betekent dat: serieus tijd investeren in performance-budget, anders ranken concurrenten met snellere sites boven jou.

Astro of Next.js bij DesignCheck

DesignCheck is een webdesign-bureau dat de beste, snelste websites bouwt — wereldwijd beschikbaar, met basis in Mijdrecht. Voor 90% van onze klantbouwen wij in Astro, voor de overige 10% in Next.js. De keuze maken we per project, op basis van de drie vragen hierboven (use-case, dynamiek, ecosysteem). Je betaalt geen toeslag voor stack-keuze — het uurloon is identiek.

De Refresh (€1.995) en Rebuild (€3.995) pakketten gebruiken default Astro. De Premium (€6.995) optie kan beide, afhankelijk van wat de site moet kunnen. Voor Keurmeesters — onze live klant met BAG-API en EP-Online-koppeling — gebruikten we Astro voor de marketing-pagina's en een Next.js-portaal voor de adviseur-tool. Dat soort hybride aanpak is normaal bij grotere projecten.

Wat doe je vandaag?

Open je huidige site op pagespeed.web.dev en kijk wat de Mobile Performance-score is. Onder de 70 betekent dat de stack-keuze ertoe doet voor je toekomstige bezoekers. Wij doen die analyse gratis binnen 48 uur en geven een aanbeveling — Astro of Next.js, geen jargon, gewoon wat past bij jouw site. Vraag aan via de gratis DesignCheck Audit.

Gerelateerde artikelen

FAQ — Astro vs Next.js voor MKB

Door Lorenzo Ruisi — DesignCheck. Laatst bijgewerkt 16 mei 2026.