Uw bureau predikt prestaties, maar uw eigen WordPress site kruipt voort. De onze ook — 3,2 seconden tot Interactive, Lighthouse vast op 58, een plugin stack waar we bang waren om bij te werken. Elke client demo betekende devtools openen op hun razendsnelle static site, hopend dat ze niet om de onze zouden vragen. We zijn socialanimal.dev — we bouwen sub-seconde Next.js en Astro ervaringen voor SaaS merken. Dus we bouwden onze site opnieuw in Astro, verwijderden WordPress volledig, en bereikten perfecte 100s over alle Lighthouse categorieën. Time to Interactive daalde naar 0,4 seconden. Totale bundle grootte: 47 KB. Geen plugins, geen database queries, geen schaamte. Dit is het exacte migration playbook dat we gebruikten — de hosting swap, de content pipeline, het image optimization apparaat, en de ene Astro feature die onze volledige caching layer elimineerde.

Zo hebben we het afgebroken en herbouwd met Astro. Het resultaat: perfecte 100s over alle vier Lighthouse categorieën — Performance, Accessibility, Best Practices, en SEO. Niet op een enkele pagina. Op elke pagina. Dit is het verhaal van hoe we daar kwamen, wat er fout ging onderweg, en wat we anders zouden doen.

Inhoudsopgave

WordPress naar Astro: Hoe We Lighthouse 100 Bereikten op Onze Rebuild

Waarom We WordPress Verlieten

Kijk, WordPress ondersteunt ongeveer 43% van het web. Het is geen slecht platform. We hebben veel WordPress sites voor clients gebouwd en zullen dat blijven doen als het de juiste fit is. Maar voor onze eigen bureau site — een meestal-static marketing site met een blog — was WordPress overkill op de ergste manier.

Hier ziet ons WordPress setup er zo uit:

  • Theme: Custom theme gebouwd op Sage (Roots.io)
  • Plugins: 14 actieve plugins inclusief Yoast SEO, WP Rocket, Advanced Custom Fields Pro, Gravity Forms, en een handvol anderen
  • Hosting: WP Engine Professional plan op $60/maand
  • CDN: Cloudflare Pro op $20/maand
  • Build complexiteit: PHP templating, Webpack voor assets, MySQL database

Self met WP Rocket aggressive caching, waren onze Core Web Vitals matig. De Largest Contentful Paint (LCP) was 2,4 seconden op mobiel. Cumulative Layout Shift (CLS) was 0,12 — niet verschrikkelijk, maar niet goed. En elke keer als we een plugin updaten, was er een kans dat iets zou breken.

De echte schok? We betaalden $80/maand in hosting kosten voor een site die misschien 3.000 bezoeken per maand kreeg. Dat is niet veel traffic, en dat is veel geld voor wat essentieel een brochure site met een blog was.

Het Breekpunt

De laatste druppel kwam in januari 2025. Een WordPress core update brak onze custom Gutenberg blokken. Het repareren vereiste het updaten van ACF Pro, wat het updaten van onze theme PHP versie compatibiliteit vereiste, wat het updaten van de hosting omgeving vereiste. Wat een routine update zou moeten zijn, werd een volledige dag werk.

Ik keek naar ons team en zei: "We vertellen clients om headless te gaan. Waarom eten we onze eigen koken niet?"

Waarom We Voor Astro Kozen

We evalueerden vier opties voor de rebuild:

Framework Voordelen Nadelen Onze Verdict
Next.js We kennen het goed, geweldig ecosysteem Overkill voor een content site, vereist server of edge runtime Te zwaar
Astro Content-gericht, verzend nul JS standaard, island architectuur Kleiner ecosysteem, nieuwer Perfecte fit
Eleventy Eenvoudig, snelle builds, volwassen Beperkt component model, minder moderne DX Dicht tweede
Hugo Razendsnelle builds, enkele binary Go templating is pijnlijk, beperkte flexibiliteit Niet voor ons

We bouwen veel Next.js projecten voor clients, en het is onze standaardkeuze voor alles met dynamische functionaliteit. Maar voor een content-zware marketing site? Next.js verzend een JavaScript runtime of je het nodig hebt of niet. Zelfs met static export, stuurt je React naar de browser.

Astro's filosofie resoneerde met ons: verzend HTML, voeg JavaScript alleen toe waar je het nodig hebt. Hun island architectuur betekent dat je een volledig interactieve React component naast volledig static HTML kunt hebben, en de static delen verzenden nul JavaScript. Dat is precies wat we nodig hadden.

We hadden ook meer Astro development werk voor clients gedaan gedurende recente jaren, dus het team was comfortabel met het framework. Het was geen leeroefening — het was een tool waar we al in vertrouwden.

De Content Layer Vraag

Eén besluit dat we vroeg maakten: we waren niet van plan om een headless CMS voor onze eigen site te gebruiken. Voor client projecten, raden we vaak headless CMS setups aan met Contentful, Sanity, of Storyblok. Maar voor onze blog, waar elke auteur een developer is die comfortabel is met Markdown en Git? Content Collections in Astro met MDX files committed naar de repo was eenvoudiger en sneller.

Geen API calls bij build tijd. Geen content delivery network voor content. Geen extra service om te beheren of voor te betalen. Gewoon bestanden in een map.

De Migration Strategie

We deden geen big-bang migration. Hier is onze gefaseerde benadering:

Fase 1: Content Audit (1 week) We exporteerden alle WordPress content met wp-cli en converteerden posts naar MDX met een custom script gebouwd met turndown (HTML-to-Markdown converter) plus wat regex cleanup. We hadden op dat moment 47 blog posts. Ongeveer 12 ervan waren verouderd of laag-prestererend, dus we redirectten die naar relevante nieuwere content en migreerden ze niet.

Fase 2: Design System in Astro (2 weken) We bouwden onze component library opnieuw als Astro components. Buttons, cards, section layouts, navigatie — alles als .astro bestanden. Geen framework nodig voor een van hen. Pure HTML en CSS met scoped styles.

Fase 3: Page Build (2 weken) Home page, capabilities pagina's, about, contact, blog listing, individuele blog posts, 404. We bouwden ze allemaal als Astro pages met onze component library.

Fase 4: Performance Tuning (1 week) Hier is waar het Lighthouse 100 werk echt gebeurde. Meer hieronder.

Fase 5: Launch en Redirect (2 dagen) We stelden proper 301 redirects in voor elke oude URL, verifiëerden met Screaming Frog dat niets was verbroken, dienen de nieuwe sitemap in bij Google Search Console, en flipten DNS.

Totale tijdlijn: ongeveer 6 weken werk naast client projecten.

WordPress naar Astro: Hoe We Lighthouse 100 Bereikten op Onze Rebuild - architectuur

Architectuur Besluiten Die Het Verschil Maakten

Nul JavaScript Standaard

Onze gehele site verzend met ongeveer 2KB JavaScript totaal. Dat is niet typo. Twee kilobytes. En het meeste daarvan is een klein script voor mobile navigatie toggle en analytics.

Hier is onze mobile nav — geen framework, geen dependencies:

---
// MobileNav.astro
---
<button id="menu-toggle" aria-expanded="false" aria-controls="mobile-menu">
  <span class="sr-only">Toggle menu</span>
  <svg><!-- hamburger icon --></svg>
</button>
<nav id="mobile-menu" hidden>
  <slot />
</nav>

<script>
  const toggle = document.getElementById('menu-toggle');
  const menu = document.getElementById('mobile-menu');
  
  toggle?.addEventListener('click', () => {
    const expanded = toggle.getAttribute('aria-expanded') === 'true';
    toggle.setAttribute('aria-expanded', String(!expanded));
    menu?.toggleAttribute('hidden');
  });
</script>

Dat <script> tag in een Astro component wordt automatisch gebundeld en gededuplicated. Het is tiny, het is vanilla JS, en het werkt overal.

CSS Strategie: Scoped Styles + Een Minimale Globale Laag

We gebruikten Astro's ingebouwde scoped CSS voor component-level styles en een enkele globale stylesheet (ongeveer 8KB geminificeerd) voor typografie, reset, custom properties, en utility classes. Geen Tailwind. Controversiële mening, ik weet het.

We houden van Tailwind voor grotere applicaties en client projecten. Maar voor een site van deze grootte, voegde het build complexiteit en file size toe die we niet nodig hadden. Onze handgeschreven CSS is kleiner dan Tailwind's output zou zijn geweest, zelfs met purging.

/* Global custom properties */
:root {
  --color-text: #1a1a2e;
  --color-bg: #ffffff;
  --color-accent: #e94560;
  --color-accent-dark: #c81e45;
  --font-body: 'Inter', system-ui, sans-serif;
  --font-heading: 'Cal Sans', var(--font-body);
  --max-width: 72rem;
  --space-unit: 0.25rem;
}

Static Generation met Smart Preloading

Elke pagina wordt statisch gegenereerd bij build tijd. We gebruiken Astro's ingebouwde prefetch integratie om links op hover vooraf in te laden, waardoor navigatie instant aanvoelt:

// astro.config.mjs
import { defineConfig } from 'astro/config';
import mdx from '@astrojs/mdx';
import sitemap from '@astrojs/sitemap';

export default defineConfig({
  site: 'https://socialanimal.dev',
  integrations: [mdx(), sitemap()],
  prefetch: {
    prefetchAll: false,
    defaultStrategy: 'hover',
  },
  build: {
    inlineStylesheets: 'auto',
  },
});

Performance Optimalisaties Diepgang

Om naar Lighthouse 100 te gaan is niet alleen over het kiezen van het juiste framework. Astro geeft je een voorsprong, maar de laatste 10-15 punten vereisen opzettelijke moeite. Hier is wat we deden.

Image Optimalisatie

Astro's ingebouwde <Image /> component handelt responsive images af met automatische format conversie (WebP/AVIF), lazy loading, en proper width/height attributen om CLS te voorkomen.

---
import { Image } from 'astro:assets';
import heroImage from '../assets/hero.jpg';
---
<Image 
  src={heroImage} 
  alt="Social Animal development team working on headless architecture"
  widths={[400, 800, 1200]}
  sizes="(max-width: 600px) 400px, (max-width: 900px) 800px, 1200px"
  format="avif"
  fallbackFormat="webp"
  quality={80}
  loading="eager"
/>

Voor de hero image specifiek, gebruiken we loading="eager" omdat het boven de fold is. Alles anders krijgt standaard loading="lazy".

We gingen ook door elke image op de site en vroegen: "Heeft dit een image nodig te zijn?" Verschillende decoratieve elementen werden CSS gradiënten of SVGs in plaats daarvan. Onze hero section background, bijvoorbeeld, is een CSS gradiënt met een subtiele noise texture toegepast via een tiny inline SVG.

Font Loading Strategie

Fonts zijn een Lighthouse killer. Hier is onze benadering:

  1. Self-host alles. Geen Google Fonts CDN. We downloadden Inter en Cal Sans en serven ze van onze eigen domein. Dat elimineert een DNS lookup, TCP connection, en TLS handshake naar fonts.googleapis.com.

  2. Subset aggressief. We gebruikten glyphhanger om te analyseren welke characters we daadwerkelijk gebruiken, dan subset onze fonts met pyftsubset. Onze Inter Regular WOFF2 ging van 96KB naar 18KB.

  3. Gebruik font-display: swap met een zorgvuldig gekozen system font fallback die metrics dicht bij elkaar brengt, minimaliseren layout shift tijdens swap.

  4. Preload de kritieke font bestanden:

<link rel="preload" href="/fonts/inter-latin-400.woff2" as="font" type="font/woff2" crossorigin />
<link rel="preload" href="/fonts/cal-sans-latin-600.woff2" as="font" type="font/woff2" crossorigin />

Hosting: Cloudflare Pages

We verhuisden van WP Engine ($60/maand) naar Cloudflare Pages (gratis tier). Ja, gratis. Onze site valt goed binnen de limieten van Cloudflare's gratis plan — 500 builds per maand, onbeperkte bandbreedte, onbeperkte requests.

Cloudflare Pages deployt van een Git push, serveert van hun globale edge netwerk, en handelt cache headers automatisch af. Build tijden gemiddeld 22 seconden voor onze gehele site. Vergelijk dat met onze WordPress setup waar een cache purge alleen al langer kon duren.

Maandelijkse hosting kosten gingen van $80 naar $0.

Critical CSS Inlining

Astro inlines automatisch kleine stylesheets wanneer je build.inlineStylesheets: 'auto' stelt. Voor onze pagina's, elke kritieke style is inlined in de <head>, wat betekent dat er nul render-blocking CSS requests zijn. De browser kan onmiddellijk beginnen met schilderen.

Third-Party Script Discipline

Hier verliezen de meeste sites hun perfecte scores. Elke third-party script is een mogelijke performance disaster. We limiteerden de onze meedogenloos:

  • Analytics: Schakelde van Google Analytics (70KB+ JavaScript) naar Plausible Analytics (< 1KB script, geladen async). We betalen $9/maand voor Plausible, en de datakwaliteit is eerlijk gezegd beter voor onze behoeften.
  • Forms: Onze contact form op /contact gebruikt een eenvoudig HTML form met server-side handling via Cloudflare Pages Functions. Geen JavaScript form library.
  • Geen chat widgets. Geen social media embeds. Geen cookie consent banners (we gebruiken geen cookies die toestemming vereisen).

Het Lighthouse 100 Scorecard

Hier zijn onze daadwerkelijke Lighthouse scores vanaf mei 2025, gemeten met Chrome DevTools op een throttled connection (Lighthouse standaard mobile simulatie):

Metric Score
Performance 100
Accessibility 100
Best Practices 100
SEO 100
First Contentful Paint 0,6s
Largest Contentful Paint 0,8s
Total Blocking Time 0ms
Cumulative Layout Shift 0
Speed Index 0,8s

De Total Blocking Time van 0ms is mijn favoriete stat. Nul. Er is essentieel geen JavaScript dat de main thread blokkeert. Ever.

Voor en Na: De Nummers

Metric WordPress (Voor) Astro (Na) Verbetering
Lighthouse Performance 58 100 +72%
LCP (mobiel) 2,4s 0,8s 3x sneller
CLS 0,12 0 Geëlimineerd
TBT 380ms 0ms Geëlimineerd
Page weight (home) 1,8MB 142KB 92% kleiner
HTTP requests 47 6 87% minder
JavaScript verzonden 340KB 2KB 99,4% minder
Maandelijkse hosting kosten $80 $9 (Plausible alleen) 89% goedkoper
Build/deploy tijd 3-5 min 22 sec ~10x sneller
Time to first byte 420ms 18ms 23x sneller

De page weight reductie is zelfs voor ons verbijsterend. 1,8MB naar 142KB. Dat is wat gebeurt wanneer je stopt met jQuery, React, WP Rocket's script loader, Yoast's schema markup injector, en veertien plugin stylesheets verzenden.

Wat We Fout Deden Onderweg

Het was niet allemaal vlot zeilend. Eerlijkheidstijd.

Fout 1: We Hadden Bijna Content Management Over-Engineered

Onze eerste instinct was om Sanity in te stellen als een headless CMS voor de blog. We brachten twee dagen door met het configureren van schemas en het opzetten van de Sanity Studio voordat we een stap terugnamen en vroegen: "Wie gaat dit daadwerkelijk gebruiken?" Het antwoord was... ons. Developers. Wie perfect content is met het schrijven van MDX in VS Code. We rukte Sanity eruit en gingen met Astro Content Collections. Spaarde lopende kosten en complexiteit.

Fout 2: Font Subsetting Brak Speciale Karakters

Onze initiële font subset was te aggressief. We streepten karakters uit waarvan we dachten dat we ze nooit zouden gebruiken, daarna publiceerden we een blog post met een em dash en een paar curly quotes die als dozen weergegeven werden. Les: test uw subsets met daadwerkelijke content, niet alleen "ABCDEFG."

Fout 3: We Vergaten Over OpenGraph Beelden

We lanceerden zonder dynamische OG beelden. Wanneer iemand een blog post op Twitter/X of LinkedIn deelde, toonde het een generieke fallback. We moesten teruggaan en een OG image generation pipeline bouwen met @astrojs/og (die Satori onder de motorkap gebruikt). Zou in de originele scope moeten zijn.

Fout 4: De 301 Redirect Map Had Gaten

Ondanks het gebruik van Screaming Frog om oude URLs in kaart te brengen, hebben we een handvol image URLs gemist die externe sites hotlinked waren. We vonden deze in Cloudflare's analytics ongeveer een week na lancering en voegden de ontbrekende redirects toe. Controleer altijd uw server logs na een migration — Google Search Console zal niet alles vangen.

Lessen Voor Uw Eigen Migration

Als u overweegt om van WordPress naar een static-first framework te gaan, hier is wat ik u zou vertellen:

  1. Audit voordat je migreert. Dood content die niet presteert. Een migration is een geweldige gelegenheid om te snoeien.

  2. Match de tool bij de job. Astro was perfect voor ons omdat we meestal content zijn. Als u zware interactiviteit nodig hebt, Next.js of een soortgelijk framework zou beter kunnen zijn.

  3. Voer uw oude architectuur niet na. We probeerden niet onze WordPress setup in Astro na te bootsen. We dachten alles opnieuw na. Hebben we daadwerkelijk een form plugin nodig? Nee, een <form> element met een serverless function werkt prima.

  4. Meet voor, meet na, meet continu. We stelden een Lighthouse CI job in GitHub Actions in die op elke pull request draait. Als een PR een score onder 95 laat vallen, faalt de check.

  5. Budget voor de "laatste 5%". Gaan van Lighthouse 85 naar 95 is straightforward. Gaan van 95 naar 100 vereist font subsetting, critical CSS analyse, image format optimalisatie, en third-party script auditing. Plan tijd voor.

  6. Uw hosting kosten zouden uw oude setup moeten beschamen. Als u static files serveert en nog steeds aanzienlijke hosting fees betaalt, klopt iets niet. Static hosting is nu een commodity.

Als u geïnteresseerd bent in hoe een migration zoals dit voor uw project zou eruit zien, check onze pricing pagina of neem contact op. We hebben deze migration path nu voor verschillende clients gedaan, en de performance gains zijn consistent dramatisch.

FAQ

Hoe lang duurt het om een WordPress site naar Astro te migreren?

Voor onze site (ongeveer 50 pagina's inclusief blog posts) duurde het ongeveer 6 weken werk naast client projecten. Een grotere site met honderden posts en complexe custom post types zou 8-12 weken kunnen duren. De daadwerkelijke development is meestal sneller dan de content audit en redirect mapping.

Kunt u Lighthouse 100 bereiken met Next.js in plaats van Astro?

Het is mogelijk maar aanzienlijk moeilijker. Next.js verzend een JavaScript runtime naar de browser zelfs voor static pagina's (de React hydration laag). Je kunt dicht bij komen — scores van 95-99 zijn bereikbaar met zorgvuldige optimalisatie. Maar Astro's zero-JS-by-default benadering maakt perfecte scores veel meer bereikbaar voor content sites.

Wat zit met WordPress functies zoals contact forms en search?

Contact forms werken prima met gewone HTML forms en een serverless function backend (Cloudflare Pages Functions, Netlify Functions, etc.). Voor search gebruiken we een client-side search met Pagefind, die een search index bouwt bij build tijd en verzend slechts 5KB JavaScript. Het is snel en werkt offline.

Schaadt migratie van WordPress naar Astro SEO?

Niet als je het goed handelt. We stelden 301 redirects in voor elke URL, behielden onze URL structuur waar mogelijk, dienden een nieuwe sitemap in, en behielden al onze structured data. Onze organic traffic steeg eigenlijk 23% in de drie maanden na migration, waarschijnlijk vanwege verbeterde Core Web Vitals.

Hoe handelt u dynamische content af zoals comments op een Astro site?

We hebben geen comments op onze blog — ze waren meestal spam op WordPress toch. Als u comments nodig hebt, services zoals Giscus (GitHub Discussions-gebaseerd) of Hyvor Talk werken goed als embedded components. Ze laden als Astro islands, dus ze beïnvloeden niet de initiële page load.

Is Astro production-ready voor grote sites?

Absoluut. Astro 5.x (uitgebracht eind 2024) is volwassen en stabiel. Bedrijven zoals Porsche, Google, Microsoft, en Netlify gebruiken het in production. De build performance schaalt ook goed — sites met duizenden pagina's bouwen in minder dan een minuut met de juiste configuratie.

Wat is het lopende onderhoud vergelijkbaar met WordPress?

Dramatisch minder. Geen plugin updates, geen database onderhoud, geen security patches voor PHP. We updaten Astro en zijn dependencies misschien eens per maand via Dependabot PRs. Elke update duurt ongeveer 5 minuten om te beoordelen en samen te voegen. Vergelijk dat met de WordPress update treadmill.

Kunnen niet-technische teamleden nog steeds content bewerken op een Astro site?

Met onze setup (MDX bestanden in Git), moet je comfortabel zijn met Markdown en basisGit workflows. Voor teams met niet-technische editors, raden we aan Astro te koppelen met een headless CMS zoals Sanity, Contentful, of Storyblok. De editors krijgen een visuele interface, en je krijgt nog steeds alle performance voordelen van static generation.