AMP is dood — wat nu voor mobiele snelheid?

Wat MKB moet weten

AMP was Google's poging tot uniforme mobiele snelheid. Sindsdien is Core Web Vitals de standaard. Voor MKB: vergeet AMP, focus op normale CWV-optimalisatie. Modern hosting (Vercel/Netlify) + lichte CMS (Astro/Webflow) = snelle mobiele site zonder AMP-complexiteit. Lees onze Core Web Vitals-gids.

Waarom AMP nooit deed wat het beloofde

AMP startte in 2015 als antwoord op Facebook Instant Articles. Het idee was simpel. Google host een afgeslankte versie van jouw pagina op een eigen CDN, jij krijgt een bliksembolletje in de zoekresultaten en bezoekers laden sneller. In de praktijk leverde dat een hoop pijn op. Je had een tweede versie van iedere pagina, met een eigen subset van HTML, een vaste set goedgekeurde componenten en een runtime die je niet zelf controleerde. Analytics werkten anders. Formulieren werkten anders. Embeds van YouTube of Vimeo werkten via aparte AMP-componenten. Een eenvoudig contactformulier op een AMP-pagina kostte een halve middag uitzoekwerk.

De grootste pijn was de URL. Bezoekers landden op een google.com/amp/-adres, niet op jouw domein. Voor een MKB-bedrijf in Mijdrecht of Utrecht voelde dat alsof Google jouw merk overnam. Toen Google in 2021 de Page Experience-update aankondigde verdween de eis dat je AMP nodig had voor de Top Stories-carousel. Vanaf 2024 stopte Google met het promoten van AMP als versnellingsoplossing. Wat overbleef is een grote berg legacy-code op honderden duizenden websites die niemand meer onderhoudt.

De les is breder dan AMP zelf. Iedere keer dat een platform een eigen versie van jouw site wil hosten, sta je technisch en commercieel zwakker. Een snelle website bouw je op je eigen domein, met je eigen stack, en je controleert zelf welke scripts er laden. Dat is de aanpak die wij bij DesignCheck hanteren voor klanten als Keurmeesters, het energielabel-bureau dat in mei 2026 live ging met een Lighthouse-score van 98 op mobiel zonder een regel AMP-code.

Wat Core Web Vitals echt meet

Core Web Vitals bestaat uit drie meetwaarden. Largest Contentful Paint meet hoe snel het grootste zichtbare element verschijnt. Voor een MKB-homepage is dat meestal de hero-foto of de H1. Interaction to Next Paint meet de reactietijd op de eerste tik of klik. Cumulative Layout Shift meet hoeveel de pagina nog verspringt nadat hij geladen lijkt. De drempels zijn helder. LCP onder 2,5 seconden, INP onder 200 milliseconden, CLS onder 0,1.

Wat je vaak niet leest is dat Google de werkelijke meting doet op echte bezoekers via het Chrome User Experience Report, niet op een lab-test in Lighthouse. Dat betekent dat een Lighthouse-score van 95 nog geen garantie is voor een groene CWV. Je hebt minimaal 28 dagen veldata nodig voordat Search Console iets zinnigs zegt. Daarom adviseren wij om vanaf dag een Real User Monitoring in te bouwen. Bij DesignCheck gebruiken we daarvoor een lichte tracker van zo'n twee kilobyte die de drie metrics doorgeeft naar een eigen dashboard. Geen Google Analytics, geen cookies, geen consent-banner nodig.

Het andere misverstand is dat snelheid alleen op de homepage telt. Een hovenier die via Google Maps bezoekers krijgt op een dienstpagina heeft daar dezelfde drempels te halen. Een webshop die via Meta-advertenties verkeer naar een productpagina stuurt idem. Behandel iedere landingspagina als een zelfstandig product. Test op een echt mid-range Android-toestel, niet alleen op je iPhone 15.

Wat je vandaag kunt doen zonder ontwikkelaar

Een groot deel van de mobiele snelheidswinst zit in beslissingen die geen code vereisen. Welke afbeeldingen je gebruikt, welke fonts je laadt, welke tracking-scripts je toelaat. Loop deze lijst af voordat je een offerte voor een rebuild aanvraagt.

1. Open je homepage op een mobiele 4G-verbinding en zet een stopwatch. Boven de 3 seconden tot eerste tekst is een rood signaal.
2. Tel het aantal scripts in de broncode. Zoek op de term script src. Boven de 15 externe scripts is bijna altijd te veel.
3. Open de grootste afbeelding van je hero in een nieuw tabblad en kijk naar de bestandsgrootte. Boven de 200 kB is te zwaar voor mobiel.
4. Controleer of je Google Fonts via een link-tag of via een CSS-import laadt. Importeren in CSS blokkeert renderen, een link met preconnect doet dat niet.
5. Kijk welke chat-widget je gebruikt. Tools als Tawk, Intercom of HubSpot Chat laden vaak 300 kB aan JavaScript voordat de bezoeker iets doet.
6. Tel het aantal cookie-banners en consent-tools. Eén CMP volstaat. Drie tegelijk is geen uitzondering bij oude WordPress-sites.
7. Schakel tijdelijk je analytics uit en hertest. Als de site twee seconden sneller wordt, ligt het probleem daar.
8. Open de mobiele site op een tablet en draai hem horizontaal. Zie je content verspringen tijdens het laden, dan is je CLS niet in orde.
9. Zoek je domein op in PageSpeed Insights en kijk niet alleen naar de score, maar naar het tabblad veldgegevens. Daar staat wat echte bezoekers ervaren.
10. Check of je hosting HTTP/2 of HTTP/3 spreekt. Op shared hosting bij budget-providers is dat vaak nog HTTP/1.1, wat alles trager maakt.
11. Controleer of je een service worker hebt draaien van een vorige bouwer. Oude service workers cachen verouderde bestanden en sloperen je laadtijd zonder dat je het merkt.
12. Bekijk de laadtijd in Search Console onder Pagina-ervaring. Daar zie je per URL of CWV groen, oranje of rood is.

Wat een snelle moderne stack er anders doet

De combinatie die wij in 2026 standaard inzetten ziet er zo uit. Astro of Next.js als framework, zodat je per pagina kiest of HTML statisch wordt voorgegenereerd of pas op een server wordt gerenderd. Vercel of Cloudflare Pages als hosting met een edge-netwerk dat dichtbij de bezoeker zit. Afbeeldingen via een image-CDN dat automatisch WebP en AVIF aanlevert in de juiste resolutie. Lettertypen via font-display: swap en alleen de gewichten die je echt gebruikt. Geen jQuery, geen Bootstrap, geen full-stack CMS-thema dat 200 kB CSS oplevert voor één knop.

Voor de Keurmeesters-site betekende dit een first-byte-tijd van 80 milliseconden vanuit Amsterdam en een LCP van 1,1 seconde op een Moto G4-emulatie. Geen AMP nodig. De BAG-API-koppeling die de gebruiker zijn adres laat invullen draait via een edge-functie van 40 regels code. Het hele formulier inclusief validatie en error-handling laadt sneller dan de cookie-banner van een gemiddelde WordPress-site.

Belangrijk om te beseffen, hosting alleen lost niets op. Een trage WordPress-site op Vercel zetten maakt hem nauwelijks sneller. De winst zit in de architectuur. Statische HTML waar mogelijk, server-side renderen waar nodig, client-side JavaScript alleen voor delen die echt interactief moeten zijn. Dat is precies waar de meeste MKB-bureaus de plank misslaan. Ze leveren een mooi ontwerp, gooien er een zwaar CMS onder en hopen dat de hosting het oplost.

Wanneer rebuild zinvol is en wanneer niet

Een rebuild kost geld. Bij DesignCheck rekenen we €1.995 voor het Starter-pakket, €3.995 voor Groei en €6.995 voor Premium. Voordat je die uitgave doet, moet de business case kloppen. De vuistregel die wij hanteren, een rebuild verdient zichzelf terug als hij minstens één van drie dingen levert. Meer aanvragen via Google omdat je hoger rankt op CWV. Meer conversie omdat het formulier sneller en helderder is. Minder onderhoudslast omdat de nieuwe stack 80 procent minder plugins nodig heeft.

Als je site nu 200 bezoekers per maand trekt en je gemiddelde klantwaarde is €150, dan zit er ergens rond de €30.000 omzet per jaar op die site. Eén extra aanvraag per maand uit Google verdient een rebuild van €3.995 binnen drie maanden terug. Trekt je site nu 30 bezoekers per maand, dan zit je probleem niet bij snelheid maar bij vindbaarheid en moet je daar eerst investeren.

Twijfel je, gebruik de verliescalculator op designcheck.nl/verliescalculator om in te schatten hoeveel omzet je per maand mist door een trage of verouderde site. De berekening is conservatief, gebaseerd op gemiddelde conversieratio's per branche, en geeft je een richtbedrag voordat je een offerte aanvraagt.

De stack die in 2026 werkt

Een snelle moderne mobiele site is een keten van keuzes. Elke schakel telt. Hieronder de stack die wij in 2026 standaard inzetten bij DesignCheck, met de redenen erbij.

Voor het framework kiezen we tussen Astro en Next.js, afhankelijk van de project-aard. Astro voor content-zware sites die voornamelijk statisch worden gerenderd, zoals MKB-brochure-sites met een blog. Next.js voor sites met veel interactie of dynamische data, zoals een booking-systeem of een dashboard. Beide leveren native ondersteuning voor server-componenten, lazy hydration en image-optimization.

Voor hosting kiezen we Vercel of Cloudflare Pages. Vercel voor Next.js, omdat de integratie naadloos is en de edge-runtime native wordt ondersteund. Cloudflare Pages voor Astro of voor klanten die wereldwijde bezoekers hebben, omdat het Cloudflare-netwerk meer edge-locaties heeft. Beide platforms bieden HTTP/3, Brotli-compressie en automatische cache-strategieën.

Voor afbeeldingen werken we met een image-CDN dat AVIF en WebP automatisch genereert. Bij Vercel is dat ingebouwd via next/image. Bij Astro gebruiken we Cloudflare Images of imagekit.io voor dezelfde functionaliteit. De besparing op bandbreedte is significant, een AVIF-afbeelding is gemiddeld 50 procent kleiner dan dezelfde JPEG bij identieke visuele kwaliteit.

Voor fonts gebruiken we Google Fonts via een lokale fallback. We laden alleen de gewichten die we daadwerkelijk gebruiken, met font-display: swap zodat tekst nooit onzichtbaar is tijdens het laden. Een lettertype dat 80 kB kost voor zes gewichten, kan vaak terug naar 18 kB voor twee gewichten zonder dat de visuele kwaliteit eronder lijdt.

Voor analytics gebruiken we Vercel Analytics of een eigen lichte tracker. Geen Google Analytics tenzij de klant het expliciet vraagt en een goede reden heeft, omdat GA4 zwaar weegt op laadtijd en een uitgebreide cookie-banner vereist. Onze eigen tracker is twee kilobyte, draait zonder cookies en geeft real-user CWV-metingen door naar een dashboard dat de klant zelf kan inzien.

Wat doe je vandaag?

Open je eigen homepage op je telefoon, met mobiele data en niet via wifi. Tel hoeveel seconden je wacht tot de hoofdtekst leesbaar is en hoeveel keer de pagina verspringt. Noteer dat getal. Vraag daarna de gratis audit aan via designcheck.nl. Binnen 48 uur ontvang je een rapport met je CWV-scores, je drie grootste snelheidsproblemen en een eerlijke inschatting of een rebuild de moeite waard is voor jouw situatie. Wij werken wereldwijd vanuit Mijdrecht en sturen je analyse in het Nederlands of Engels, naar voorkeur.

Veelvoorkomende misverstanden

Een paar misverstanden over mobiele snelheid die we wekelijks tegenkomen. Een, een snelle hosting maakt mijn WordPress-site snel. Niet noodzakelijk, want de architectuur van WordPress met zijn vele plugins is de bottleneck, niet de hosting. Twee, mijn site is snel want Lighthouse zegt 90. Lighthouse is een lab-test, kijk altijd ook naar veldgegevens in Search Console. Drie, AMP heeft Google's voorkeur nog steeds. Niet meer sinds 2024, normale CWV-optimalisatie is voldoende. Vier, een snelle site kost duizenden euro's per maand aan hosting. Onzin, een statische site op Cloudflare Pages kost vaak minder dan vijf euro per maand voor het MKB.

Een vijfde misverstand, een snelle site is ten koste van design. Het tegendeel is waar. Een goed gebouwde snelle site kan visueel rijker zijn dan een trage, omdat je rekenkracht overhebt voor smooth animaties, hoge-resolutie-afbeeldingen en mooie typografie. Het is geen zero-sum-keuze tussen ontwerp en snelheid, maar een kwestie van technische discipline.

Veelgestelde vragen

Verder lezen