Waarom ik na 20 jaar webontwikkeling performance nog steeds op 1 zet
Het begon met een 56k-modem
Mijn eerste serieuze website bouwde ik rond 2004. De doelgroep: mensen met een 56k-modem. Elke kilobyte telde. Ik optimaliseerde afbeeldingen tot ze nauwelijks herkenbaar waren, schreef CSS met de hand, en vermeed JavaScript waar ik kon.
Niet omdat ik een perfectionist was. Oké, een beetje wel. Maar vooral omdat ik wist: als de pagina te lang laadt, is de bezoeker weg. Zo simpel was het.
Dat principe heeft me in twintig jaar niet verlaten. De technologie veranderde. Modems maakten plaats voor ADSL, ADSL voor glasvezel. Bezoekers werden op een andere manier ongeduldig: niet omdat hun verbinding te traag was, maar omdat de concurrentie op één klik afstand zit.
De maatstaf voor "snel genoeg" verschuift voortdurend. Maar de les? Die is precies hetzelfde. Performance is geen luxe. Het is een basisvoorwaarde.
In 2004 was 56k de standaard. In 2012 maten we performance in seconden. In 2018 in milliseconden. In 2026 meet een AI-crawler jouw server in de eerste paar honderd milliseconden en besluit dan of hij doorgaat of afhaakt. De lat verschuift. De les niet.
Twintig jaar klantprojecten, één constante
Bij Kobalt heb ik tientallen websites gebouwd en geoptimaliseerd. Van kleine lokale ondernemers tot middelgrote B2B-bedrijven. De projecten variëren enorm, maar de patronen? Die zijn opvallend consistent.
Elke keer als een klant klaagt over tegenvallend organisch verkeer, stel ik dezelfde eerste vraag: hoe snel laadt je website?
Niet de tweede of derde vraag. De eerste.
Want in negen van de tien gevallen is performance onderdeel van het probleem. Een trage website rankt slechter, converteert slechter en maakt een slechtere indruk. Ik heb ooit een hele avond besteed aan het shaven van 12 milliseconden van een TTFB. Mijn vrouw vond het minder indrukwekkend dan ik. Maar de klant merkte het verschil.
- Een website die in 0,8 seconden laadt, converteert gemiddeld twee keer zo goed als een website die in 3 seconden laadt.
- Google geeft snelle websites een directe voorkeur via Core Web Vitals.
- Mobiele gebruikers verlaten een pagina na drie seconden laden in meer dan 50% van de gevallen.
- AI-crawlers met strikte timeouts indexeren langzame websites minder volledig.
De perfecte storm: performance en AI
Wat me oprecht fascineert aan de huidige ontwikkeling rond AI en AEO, is dit: alles waarvoor ik de afgelopen twintig jaar heb gepleit, blijkt nu ook essentieel voor AI-zichtbaarheid.
Performance was altijd een overtuigingsgesprek. Ik kon aantonen dat een snellere website betere resultaten geeft. Maar het directe oorzaak-gevolg was soms lastig te kwantificeren.
Nu is het anders.
Nu kan ik zeggen: een trage website wordt letterlijk overgeslagen door AI-crawlers. Een site op shared hosting met een TTFB van 2 seconden wordt minder volledig geïndexeerd door GPTBot dan een VPS met een TTFB van 150ms. Dat is geen theorie. Dat is meetbaar, aantoonbaar, en direct te koppelen aan gemiste citaties in ChatGPT, Perplexity en Google AI Overviews.
Ik merk dat ik hier een beetje enthousiast word. Even terugspoelen.
Het punt is: de argumenten voor performance zijn altijd goed geweest. Maar nu zijn ze onweerlegbaar. AI-crawlers hebben het overtuigingsgesprek overbodig gemaakt.
Een B2B e-commerce klant investeerde in een volledige performance-optimalisatie: nieuwe hosting, HTTP/2, WebP-afbeeldingen, lazy loading, betere caching. De AEO-scan daarna liet een significante verbetering zien in de technische component. Niet omdat we iets aan de content hadden gedaan. Omdat de website simpelweg sneller was geworden.
Mijn advies: begin bij de basis
Als je vandaag begint met AEO, verleid je dan niet door de sexy onderwerpen. llms.txt is leuk. Schema.org is belangrijk. Maar als jouw website op een trage shared server staat met een TTFB van 1,5 seconden en een ongeoptimaliseerde database? Dan is de rest symptoombestrijding.
Begin bij de basis. Zorg dat je website snel is. Niet "snel genoeg voor een mens", maar snel voor een geautomatiseerde crawler met een strikte timeout.
- Meet eerst. GTmetrix, WebPageTest, Google PageSpeed Insights. Ken je baseline.
- Fix de server. Shared hosting? Overweeg een migratie naar VPS of managed hosting.
- Optimaliseer de kritische laadpaden. CSS inline for above-the-fold, JS defer of async, afbeeldingen als WebP of AVIF.
- Schakel HTTP/2 in op je server of via een CDN. Evalueer HTTP/3.
- Meet opnieuw. Bevestig dat de verbeteringen meetbaar zijn in TTFB en Core Web Vitals.
En pas daarna: llms.txt, Schema.org, E-E-A-T. In die volgorde.
Het is als bij vogelspotten: je kunt de duurste verrekijker hebben, maar als je niet stil kunt zitten, zie je niets. Performance is dat stil zitten. Het is de discipline die al het andere mogelijk maakt.
Veelgestelde vragen
Is performance echt altijd de eerste prioriteit?
Het hangt af van hoe slecht de performance is. TTFB onder de 400ms en groene Core Web Vitals? Dan is performance niet je eerste zorg. Maar in de praktijk heeft de meerderheid van de websites waarmee ik werk een performanceprobleem dat alle andere optimalisaties ondermijnt. Doe altijd eerst een meting.
Hoeveel verbetering kan ik verwachten?
Dat verschilt enorm. Websites die starten met een Lighthouse-score van 40 en een TTFB van 2 seconden, kunnen na optimalisatie scores van 85 tot 95 en TTFB's onder de 200ms halen. Het effect op AI-gereedheid is proportioneel: meer pages worden volledig gecrawld, meer content geïndexeerd, meer citaties volgen. Klanten die van shared naar VPS migreren, zien dit het duidelijkst.
Hoe houd ik performance op peil?
Performance degradeert standaard. Elke nieuwe plugin, elk nieuw script, elke ongeoptimaliseerde afbeelding voegt gewicht toe. De oplossing: monitoring. Stel een wekelijkse geautomatiseerde test in via SpeedCurve, Calibre of de gratis PageSpeed Insights API. Stel een drempelwaarde in (TTFB boven 500ms) en laat je waarschuwen bij overschrijding. Behandel performance als een metric, niet als een eenmalig project.
Na twintig jaar webontwikkeling is mijn conclusie simpel: performance is nooit het enige wat telt, maar het is altijd de eerste vraag. Alles wat je erop bouwt, staat of valt met de snelheid van de basis.
Hoe scoort jouw website op AI-gereedheid?
Krijg binnen 30 seconden je AEO-score en ontdek wat je kunt verbeteren.
