De snelheidsscore in uw builder heeft het template gemeten. Uw klanten laden de pagina pas nadat al het andere is toegevoegd: de herovideo, de chatwidget, de boekingsmodule, de analytics- en advertentietags. Wie een AI-gebouwde website sneller wil maken, begint bij dat verschil. Deze gids laat zien waar pagina’s zwaarder worden op Framer, Webflow en React- of Next.js-builds die door een AI-tool zijn gegenereerd, met welke drie metingen Google het resultaat beoordeelt, wat u eerst aanpakt en hoe de site snel blijft zodra marketing er dingen aan toevoegt.
TL;DR
Website-prestatieoptimalisatie is het werk waardoor pagina’s sneller verschijnen, sneller reageren en stabiel blijven voor echte bezoekers op echte apparaten. Begin op een AI-gebouwde site bij wat na het genereren is toegevoegd en, bij code-builds, bij de manier waarop pagina’s worden gerenderd.
- Waar AI-gebouwde sites zwaarder worden: Framer- en Webflow-sites door afbeeldingen op volle resolutie, animaties en embeds van derden; React- of Next.js-builds die door een AI-tool zijn gegenereerd ook door grote JavaScript-bundels en rendering in de browser.
- Welke metingen tellen: de Core Web Vitals LCP (goed: 2,5 s of minder), INP (200 ms of minder) en CLS (0,1 of minder), voor minstens 75% van de bezoeken.
- Wat u eerst aanpakt: de zwakste Core Web Vital op uw belangrijkste pagina’s, herleid tot de gemeten oorzaak; afbeeldingen en scripts van derden zijn een praktisch startpunt als de metingen daarnaar wijzen, en rendering als belangrijke content afhangt van JavaScript in de browser.
- Hoe de site snel blijft: één prestatiebudget per paginatemplate, één eigenaar die nieuwe scripts goedkeurt en een maandelijkse controle van de velddata over 28 dagen in Search Console.
Waarom een AI-gebouwde site trager is dan de snelheidsscore doet vermoeden
Een AI-gebouwde site kan in de builder 90 of hoger scoren en toch traag laden op de telefoon van een klant, omdat beide cijfers iets anders meten. Een builderscore of een Lighthouse-test is labdata: één test van één pagina, op een gesimuleerd apparaat en een gesimuleerde verbinding. Velddata is wat echte bezoekers op hun eigen apparaten en netwerken hebben ervaren.
Google verzamelt velddata van Chrome-gebruikers in het Chrome UX Report (CrUX). Volgens Chrome for Developers tonen PageSpeed Insights en Google Search Console CrUX-data allebei als een voortschrijdend gemiddelde over 28 dagen, dat dagelijks wordt bijgewerkt. Door dat venster kan een site op de lanceerdag goed scoren en een maand later tekortschieten: de labtest draaide op het lege template, terwijl de velddata de pagina’s weergeeft die bezoekers laden nadat content, embeds en tags zijn toegevoegd.
Het verschil kost eerst geld en pas daarna posities. Een betaalde klik die landt op een pagina waarvan de hero-afbeelding nog laadt, betaalt u ook als de bezoeker afhaakt voordat het formulier verschijnt. Zichtbaarheid in zoekresultaten komt op de tweede plaats: Google Search Central stelt dat Core Web Vitals worden gebruikt door de rankingsystemen van Google, terwijl relevante content zwaarder weegt. Paginasnelheid is een van de controles bij AI-gebouwde producten veilig live brengen.
Volgende stap: test uw drie meest bezochte pagina’s, niet alleen de homepage, in PageSpeed Insights op het tabblad Mobiel en lees de velddata voordat u naar de labscore kijkt.
Core Web Vitals in begrijpelijke taal
Core Web Vitals zijn de drie metingen waarmee Google beschrijft hoe een pagina laadt en reageert. Volgens web.dev is een pagina “goed” als elke meting voor minstens 75% van de bezoeken binnen de grenswaarde blijft:
- Largest Contentful Paint (LCP) meet hoe lang het duurt voordat de hoofdcontent, zoals de hero-afbeelding of het kopblok, verschijnt. Goed: 2,5 seconden of minder.
- Interaction to Next Paint (INP) meet hoe snel de pagina reageert als een bezoeker op een knop tikt, een menu opent of in een formulier typt. Goed: 200 milliseconden of minder.
- Cumulative Layout Shift (CLS) meet hoeveel de lay-out verspringt tijdens het laden. Goed: 0,1 of minder.
Time to First Byte (TTFB), de tijd die de server nodig heeft om de pagina te gaan versturen, is geen Core Web Vital, maar een trage TTFB vertraagt de LCP van elke pagina.
| Meting | Wat de bezoeker merkt | Mogelijke oorzaak op een AI-gebouwde site | Eerste oplossing |
|---|---|---|---|
| LCP | De hoofdafbeelding of kop verschijnt laat | Hero-afbeelding op volle resolutie of videoachtergrond; content die met JavaScript in de browser wordt gerenderd | Hero-afbeelding verkleinen en comprimeren; contentpagina’s op de server renderen |
| INP | Tikken en klikken reageren traag | Chat-, boekings- en trackingscripts die strijden om de main thread van de browser; zware animatiecode | Scripts van derden verwijderen of uitstellen; embeds pas bij interactie laden |
| CLS | Content verspringt tijdens het laden | Afbeeldingen en embeds zonder gereserveerde ruimte; late fontwissels; een cookiebanner die content omlaag duwt | Afmetingen van afbeeldingen en embeds vastleggen; cookiebanner als overlay tonen |
Een site met weinig verkeer heeft mogelijk te weinig Chrome-bezoeken om in CrUX velddata te krijgen; PageSpeed Insights toont dan alleen het labresultaat, en dat is dan de beste beschikbare leidraad. Pak eerst de meting aan die op uw belangrijkste landingspagina buiten “goed” valt.
Waar het gewicht vandaan komt op AI-gebouwde sites
Het gewicht van een AI-gebouwde site zit in twee lagen: wat na het genereren aan de pagina’s is toegevoegd, en hoe het platform of de gegenereerde code die pagina’s aflevert. Bij Framer en Webflow regelt het platform hosting en levering, dus de problemen die u zelf kunt oplossen zitten in content en embeds. Bij een React- of Next.js-build die door een AI-tool is gegenereerd, bepaalt de code hoeveel JavaScript laadt en waar elke pagina wordt gerenderd, dus de problemen kunnen dieper zitten.
Framer- en Webflow-sites: afbeeldingen, interacties en embeds
Op een Framer- of Webflow-site gaat snelheid verloren door keuzes in de editor. Controleer deze bronnen:
- gegenereerde of stockafbeeldingen die op volle resolutie zijn geüpload en op een fractie van dat formaat worden getoond
- scroll- en entree-animaties in elke sectie, die scriptwerk uitvoeren terwijl de bezoeker leest of tikt
- videoachtergronden in de hero, die met de hoofdcontent om bandbreedte strijden
- embeds van derden, zoals chat, boekingstools, reviewwidgets en kaarten, die elk hun eigen scripts laden
- trackingtags en eigen codeblokken die in de head van de site zijn geplakt
- meer dan twee webfontfamilies
Afbeeldingen vragen om twee aanpassingen: exporteer ze als WebP of AVIF op het formaat waarop ze worden getoond, en laad afbeeldingen en video’s onder de vouw pas als de bezoeker ernaartoe scrolt (lazy loading). Pas lazy loading nooit toe op de hero-afbeelding; web.dev raadt dat af omdat het de LCP vertraagt. Kijk eerst wat uw platform al met geüploade afbeeldingen doet: de winst zit in bestanden die groter zijn dan hun weergaveformaat.
React- en Next.js-builds die door een AI-tool zijn gegenereerd
Een React- of Next.js-build die door een AI-tool is gegenereerd, kan traag zijn om redenen die geen editorinstelling oplost. De belangrijkste is client-side rendering: de browser ontvangt een bijna lege pagina en moet eerst JavaScript downloaden en uitvoeren voordat de content verschijnt, wat de LCP bij elk bezoek vertraagt. De andere bronnen zijn keuzes in de code:
- grote bundels met bibliotheken die de pagina’s nooit gebruiken
- geen code splitting, zodat elke pagina de code van alle andere pagina’s meelaadt
- afbeeldingen die zonder optimalisatiestap op hun oorspronkelijke formaat worden geserveerd
- hosting ver van bezoekers in de EU, wat de TTFB van elk verzoek verhoogt
Bestaat de site vooral uit contentpagina’s (home, diensten, blog, prijzen), dan is server-side rendering of statische generatie de standaardkeuze, zoals Rendering on the Web uitlegt: de server stuurt kant-en-klare HTML, zodat de hoofdcontent kan verschijnen voordat het JavaScript klaar is. Client-side rendering past alleen bij app-achtige pagina’s achter een login, waar bezoekers één keer een dashboard laden en daarin verder werken.
Als uw site op WordPress draait
WordPress-sites verliezen snelheid op andere plekken: PHP-verwerking, de database, cachingplugins en het gewicht van het thema. Die oplossingen staan in onze gids over WordPress-prestaties optimaliseren. De onderdelen over cookietoestemming en monitoring hieronder gelden ook voor WordPress-sites.
Op een buildersite zijn de snelheidsproblemen die u zelf kunt oplossen vooral keuzes over content en scripts. Op een gegenereerde code-build kunnen ze ook zitten in de manier waarop pagina’s worden gerenderd, en dat laat één score niet zien. Een onafhankelijke AI-built product review bekijkt de code, de scripts en de data die die scripts versturen, en geeft u een geprioriteerde lijst van wat u eerst aanpakt.
Wat pakt u eerst aan? Prioriteer de gemeten bottleneck
Begin bij de pagina’s die voor uw bedrijf het zwaarst wegen, zoals landingspagina’s die betaald verkeer ontvangen of leads opleveren. Controleer hun Core Web Vitals en gebruik een labtest om te onderzoeken welke resources of welk renderwerk achter de zwakste meting zitten.
Is de LCP slecht, bekijk dan het grootste contentelement, het laadpad ervan, de responstijd van de server en vertragingen bij het renderen. Is de INP slecht, onderzoek dan de uitvoering van JavaScript en de interacties die vertraging veroorzaken. Is de CLS slecht, zoek dan naar afbeeldingen, embeds, fonts of dynamisch ingevoegde content die de lay-out verschuiven.
Afbeeldingen en scripts van derden zijn een praktisch startpunt als de metingen laten zien dat ze bijdragen aan het probleem. Controleer op een React- of Next.js-site de renderstrategie als belangrijke content afhangt van JavaScript in de browser. Prioriteer aanpassingen op gemeten impact, benodigde inspanning en het belang van de betreffende pagina.
De aanpassingen hieronder komen vaak voor op AI-gebouwde sites; gebruik ze als voorbeelden zodra metingen ernaar wijzen. Meet met PageSpeed Insights voor veld- en labdata per pagina, Lighthouse in Chrome DevTools voor herhaalde labtests, en het Core Web Vitals-rapport in Search Console voor groepen pagina’s door de tijd heen.
- Afbeeldingen op de belangrijkste landingspagina’s. Verklein ze tot het weergaveformaat, zet ze om naar WebP of AVIF en gebruik lazy loading onder de vouw. Wie: marketeer bij een builder, developer bij een code-build. Zo controleert u het: de LCP in de labtest daalt en de hero-afbeelding is niet langer het grootste verzoek.
- Scripts en embeds van derden. Zoek scripts op die niet meer nodig zijn en verwijder ze. Overweeg niet-essentiële chat-, boekings- of video-embeds pas te laden als de bezoeker interactie heeft met een lichte placeholder (web.dev). Wie: marketeer, samen met de eigenaar van elke externe tool en met ondersteuning van een developer waar nodig. Zo controleert u het: vergelijk Total Blocking Time (TBT), activiteit op de main thread en scriptuitvoering in gecontroleerde labtests. Volg INP om de reactiesnelheid voor echte gebruikers te beoordelen als er voldoende velddata is. Een verbetering van TBT in het lab betekent niet automatisch een verbetering van INP in het veld.
- Fonts en animaties boven de vouw. Beperk de site tot twee fontfamilies en haal entree-animaties uit het eerste scherm. Wie: designer of marketeer. Zo controleert u het: de CLS blijft op of onder 0,1 en de kop verschijnt zonder op een animatie te wachten.
- Caching en CDN. Serveer bij een code-build statische bestanden met lange cacheheaders via een content delivery network (CDN), een netwerk van servers dat bestanden levert vanaf een locatie dicht bij de bezoeker, en host in een EU-regio. Controleer bij Framer of Webflow in plaats daarvan de standaardinstellingen van het platform. Wie: developer. Zo controleert u het: de TTFB voor bezoekers in de EU verbetert.
- Renderstrategie en bundelgrootte (alleen code-builds). Zet contentpagina’s over naar server-side rendering of statische generatie, splits de code per pagina en verwijder ongebruikte bibliotheken. Wie: developer. Zo controleert u het: de hoofdcontent staat in de HTML voordat JavaScript wordt uitgevoerd.
- Velddata na 28 dagen opnieuw meten. Labtests tonen de verandering op dezelfde dag; velddata heeft een volledig venster van 28 dagen nodig om te laten zien of echte bezoekers er baat bij hebben. Wie: eigenaar van de site. Zo controleert u het: de URL-groep schuift naar “goed” in het Core Web Vitals-rapport van Search Console.
Cookietoestemming, trackingtags en snelheid
Voor websites in de EU is het pas na toestemming laden van trackingtags zowel de wettelijke inrichting als de snellere. Volgens artikel 11.7a van de Telecommunicatiewet, waarmee de Europese ePrivacy-regels zijn ingevoerd, heeft een website toestemming van de bezoeker nodig voordat die trackingcookies plaatst of uitleest; de Autoriteit Persoonsgegevens legt uit wanneer analytische cookies met weinig impact op de privacy zijn uitgezonderd. Wachten niet-essentiële tags op toestemming, dan laadt de eerste paginaweergave minder scripts. Dat helpt de LCP en INP voor elke bezoeker die nog niet op de banner heeft gereageerd.
Een AI-gebouwde site kan precies andersom zijn ingericht: een template wordt geleverd met analytics en advertentiepixels die vast in de head staan, en daarna wordt er een cookiebanner bovenop gezet. De tags laden dan voordat de bezoeker antwoordt, dus de pagina is trager en de banner regelt niet wat hij belooft te regelen. Laad elke niet-essentiële tag daarom via de toestemmingstool. Onze AVG-checklist voor websites behandelt de eisen voor toestemming in detail.
Controleer het in vijf minuten: open de pagina in een privévenster, weiger toestemming, open het tabblad Network in Chrome DevTools en laad de pagina opnieuw. Er mag geen verzoek naar een analytics- of advertentiedomein gaan.
Hoe houdt u de site snel na de lancering?
Een site blijft snel als elk nieuw script, elke widget en elke sectie binnen een grens moet passen die iemand controleert. Een prestatiebudget is die grens: een maximaal paginagewicht, aantal verzoeken of meetwaarde waarbinnen een pagina moet blijven (web.dev). Stel één budget in per paginatemplate, zoals de homepage, een landingspagina en een blogartikel, omdat elk template andere content bevat.
- Eén eigenaar voor nieuwe scripts. Eén persoon keurt elke nieuwe tag, widget of embed goed voordat die live gaat, en verwijdert tools die het bedrijf niet meer gebruikt.
- Opnieuw testen na elke toevoeging. Test het betreffende template in PageSpeed Insights nadat u een widget, tag of sectie hebt toegevoegd, en vergelijk het resultaat met het budget.
- Maandelijkse controle van de velddata. Open het Core Web Vitals-rapport in Search Console één keer per maand. Omdat het de voorgaande 28 dagen weergeeft, begon een achteruitgang die daar zichtbaar wordt al weken eerder; herleid die tot de wijzigingen uit die periode.
Gaat een template over zijn budget heen, verwijder of stel dan eerst iets uit voordat u het nieuwe onderdeel toevoegt.
Hoe Sunbytes AI-gebouwde sites beoordeelt
Een website die er in een preview klaar uitziet, kan nog technische problemen hebben die echte gebruikers raken. Om die problemen te begrijpen kan het nodig zijn de gegenereerde code, het gedrag van het product, de afhankelijkheden en de deployment-inrichting te beoordelen, in plaats van alleen op een prestatiescore te vertrouwen.
De AI-Built Product Review van Sunbytes brengt expertise in software engineering en security samen om de afgesproken onderdelen van een AI-gebouwd product te beoordelen. Afhankelijk van het product en de reviewscope kan dat gaan om relevante risico’s in code en architectuur, afhankelijkheden van derden, kritieke workflows, configuratie en operationele gereedheid.
De review levert bevindingen met onderbouwend bewijs, een geprioriteerd actieplan en een technische overdracht waarmee uw team het herstelwerk kan plannen. Specifieke diagnose van websiteprestaties, het testen van Core Web Vitals of optimalisatiewerk bespreekt u apart tijdens het bepalen van de scope; ga er niet van uit dat dit in elke review is inbegrepen.
Sunbytes brengt ervaring mee uit meer dan 300 opgeleverde projecten, ondersteund door een ISO/IEC 27001-gecertificeerd managementsysteem voor informatiebeveiliging.
Wilt u een onafhankelijke beoordeling van de bredere technische gereedheid van uw AI-gebouwde website? Bekijk de AI-Built Product Review van Sunbytes en bespreek welke onderdelen en prestatievragen u wilt laten meenemen.
