Je website sneller maken: een praktische checklist

Om een website sneller te maken, meet je hem eerst met PageSpeed Insights en repareer je daarna de grootste oorzaak die het aangeeft: meestal te grote afbeeldingen, te veel JavaScript, zware lettertypen of scripts van derden. Mik op de Core Web Vitals-doelen van Google, ‘goed’: de belangrijkste content zichtbaar binnen 2,5 seconden, reactie op tikken binnen 200 milliseconden, en bijna geen verspringende lay-out. De meeste sites halen dat met een handvol wijzigingen, niet met een herschrijving.

Meet voordat je iets verandert

Gissen kost tijd. Twee gratis tools dekken bijna iedereen:

• PageSpeed Insights (pagespeed.web.dev): plak een live URL. Het toont velddata van echte Chrome-gebruikers (als je site genoeg verkeer heeft) en labdata van een gesimuleerde load, plus een lijst met specifieke problemen.
• Lighthouse in Chrome DevTools: dezelfde labtest, op elke pagina die je kunt openen, ook een preview. Test in mobiele modus; op telefoons met tragere netwerken worden problemen zichtbaar.

De cijfers die ertoe doen, zijn de Core Web Vitals van Google. Vanaf september 2026 geven de documentatie van Google op web.dev deze ‘goed’-drempels, gemeten bij het 75e percentiel van paginaladingen:

INP verving in 2024 de oudere metriek First Input Delay. Als een tool nog FID rapporteert, is die verouderd.

Schrijf je startcijfers op. Test na elke reparatie opnieuw, zodat je weet wat heeft geholpen.

Waar de tijd naartoe gaat: opties en afwegingen

Elke veelvoorkomende oorzaak heeft een oplossing, en elke oplossing heeft een prijs. Begin bovenaan: die zijn het goedkoopst en komen het vaakst voor.

Afbeeldingen

Afbeeldingen zijn het vaakst het probleem en het makkelijkst te repareren. Een foto van 4.000 pixels breed die op 800 pixels wordt getoond, dwingt elke bezoeker vijf keer zoveel te downloaden als ze zien.

• Lever afbeeldingen aan in de grootte waarin ze worden getoond, met responsieve srcset-formaten voor telefoons en desktops.
• Gebruik moderne formaten (WebP of AVIF) en redelijke compressie.
• Stel width en height in op elke afbeelding, zodat de browser ruimte reserveert. Alleen dit lost al het meeste verspringen op.
• Lazy-load afbeeldingen onder de vouw met loading="lazy".
• Lazy-load nooit de belangrijkste afbeelding bovenaan de pagina. De LCP-richtlijn van Google is hier duidelijk over: lazy-loaden van het LCP-beeld vertraagt het altijd. Geef het fetchpriority="high".

JavaScript

Veel met AI gebouwde sites zijn single-page apps (SPA’s): de browser downloadt een JavaScript-bundel en tekent dan de pagina. Hoe groter de bundel, hoe langer het lege scherm. Oplossingen, op volgorde van inspanning:

1. Verwijder wat je niet gebruikt. Vraag om een lijst van afhankelijkheden en schrap bibliotheken die ooit zijn toegevoegd en vergeten: een datumbibliotheek voor één datum, een volledig iconenpakket voor vijf iconen.
2. Splits per route. Laad de code voor het beheerdashboard pas als iemand het opent, niet op de homepagina.
3. Prerender openbare pagina’s. Een marketingpagina die als echte HTML wordt geleverd, verschijnt voordat JavaScript draait. Dit helpt ook zoekmachines; zie SEO voor met AI gebouwde websites.

Een trage INP betekent meestal één lange taak die de pagina blokkeert: een enorme lijst bij elke toetsaanslag filteren, of een hele tabel opnieuw renderen wanneer één cel verandert. Het Performance-paneel van Chrome DevTools laat zien welke.

Lettertypen

Elke lettertypefamilie en elk gewicht is weer een bestand. Twee families en drie of vier gewichten zijn meestal genoeg. Preload het lettertype dat boven de vouw wordt gebruikt, gebruik font-display: swap zodat tekst meteen verschijnt, en host lettertypen zelf als de externe dienst traag is voor je bezoekers.

Scripts van derden

Chatwidgets, analyse, heatmaps, advertentiepixels, ingesloten video’s en social feeds laden allemaal code van andere servers. Elk lijkt klein; samen zijn ze vaak het traagste deel van de pagina. Houd de scripts die je echt gebruikt. Laad de rest nadat de pagina interactief is, en vervang zware embeds (een YouTube-speler, een kaart) door een lichte preview die het echte ding pas bij een klik laadt.

Serverreactie

Time to first byte (TTFB), de tijd die de server nodig heeft om te beginnen met antwoorden, ligt onder elke andere metriek. Statische pagina’s die vanaf een CDN worden geleverd (een netwerk van servers dicht bij je bezoekers; zie wat is een CDN) zijn bijna overal snel. Pagina’s die bij elk verzoek door een server worden gebouwd, hangen af van die server en zijn database. Caching van herhaald werk en databaseindexen voor trage query’s zijn de gebruikelijke oplossingen.

Prompts die werken

Wees specifiek: noem de pagina, de metriek en de beperking. Plak de PageSpeed Insights-bevindingen als je die hebt.

PageSpeed Insights meldt een LCP van 4,8 s op mobiel voor de homepagina, en het LCP-element is de heldafbeelding. Verklein en converteer de heldafbeelding naar WebP, lever responsieve formaten, stel width en height in, geef hem fetchpriority="high" en zorg dat hij niet lazy wordt geladen. Lazy-load elke afbeelding onder de vouw. Verander het ontwerp niet.

Audit de afhankelijkheden van deze app. Geef elk pakket, wat het gebruikt en ruwweg hoeveel het aan de bundel toevoegt. Verwijder ongebruikte pakketten en splits de routes /admin en /settings in aparte chunks die alleen laden wanneer ze worden bezocht.

Het zoekveld op /products voelt traag aan. Debounce het filter, voorkom dat de hele lijst bij elke toetsaanslag opnieuw wordt gerenderd, en pagineer of virtualiseer de lijst als hij meer dan 200 items heeft.

Stap voor stap

1. Test de live pagina in PageSpeed Insights op mobiel. Noteer LCP, INP en CLS, en de drie belangrijkste problemen.
2. Repareer eerst de afbeeldingen: formaten, conversie, afmetingen, lazy loading onder de vouw, prioriteit voor de held.
3. Schrap scripts van derden die je niet gebruikt, en stel de rest uit.
4. Snoei lettertypen tot wat het ontwerp nodig heeft.
5. Verklein JavaScript: verwijder ongebruikte pakketten, splits per route.
6. Prerender openbare pagina’s als ze nog aan de client worden gerenderd en LCP nog traag is.
7. Controleer de server: caching, databaseindexen, statische hosting voor content die zelden verandert.
8. Publiceer opnieuw en test opnieuw. Velddata in PageSpeed Insights wordt de komende weken bijgewerkt naarmate echte bezoeken binnenkomen, dus beoordeel vroege resultaten aan de hand van labdata.

Veelgemaakte fouten

• Alleen op een snelle laptop testen. Je bezoekers gebruiken middenklasse-telefoons en wisselvallige mobiele data. Test in mobiele modus.
• Achter een perfecte 100 aanjagen. De labscore is een richtlijn. Zodra de Core Web Vitals in het goede bereik zitten, tellen content en bruikbaarheid zwaarder dan de laatste paar punten.
• Alles lazy-loaden, inclusief de heldafbeelding. Dat maakt LCP slechter.
• Een snelheidsplugin of bibliotheek erbovenop zetten. Gewicht verwijderen verslaat bijna altijd code toevoegen om gewicht te beheren.
• De preview optimaliseren, niet de live site. Ontwikkelpreviews draaien niet-geoptimaliseerde builds. Meet de gepubliceerde URL.
• Snelheid maar één keer repareren. Elke nieuwe widget, afbeelding en functie voegt gewicht toe. Test opnieuw na grote wijzigingen.

Snelheidschecklist

• LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1 op mobiel
• Afbeeldingen verkleind, gecomprimeerd, modern formaat, met width en height
• Heldafbeelding niet lazy geladen; afbeeldingen onder de vouw wel
• Geen ongebruikte JavaScript-bibliotheken; zware routes gesplitst
• Twee lettertypefamilies of minder, hoofdlettertype gepreload
• Alleen de scripts van derden die je echt gebruikt, laat geladen
• Openbare pagina’s geprerenderd of statisch waar mogelijk
• Opnieuw getest op de live URL na publicatie

Snelheid en mobiele lay-out horen bij elkaar; zie hoe je een website mobielvriendelijk maakt. Voor een volledige controle voor de lancering behandelt hoe je een AI-prototype naar productie brengt de rest.

Snelheid op Mythex

Op Mythex maak je deze wijzigingen door het in de chat te vragen, of in de code-editor op Pro. Controleer de gepubliceerde URL, niet de Preview, want Preview draait een ontwikkelserver. Statische frontends worden bij publicatie als statische sites uitgerold (statische websites), wat geschikt is voor contentpagina’s. Apps met een server schalen naar nul: ze slapen als ze inactief zijn en worden wakker bij het volgende bezoek, dus het eerste verzoek na een rustige periode is trager. Een gekoppelde database slaapt na 5 minuten inactiviteit (hostinglimieten). Als een openbare pagina alleen bij het eerste bezoek traag is, is dat waarschijnlijk de oorzaak. Publieke marketingpagina’s statisch houden helpt. Publiceer na wijzigingen opnieuw en doe een harde refresh.

Veelgestelde vragen