Sitesnelheid optimaliseren: een praktische werkvolgorde
Werk aan sitesnelheid heeft een sterke Pareto-vorm: een handvol ingrepen verklaart op de meeste sites het merendeel van de verbetering, en het zijn vrijwel altijd afbeeldingen, serverreactie en scripts van derden.
Deze gids behandelt in welke volgorde je werkt, hoe je meet of een wijziging hielp, en de optimalisaties die de moeite meestal niet waard zijn.
Meet voordat je iets wijzigt#
Optimaliseren zonder meten betekent oplossen wat het makkelijkst is in plaats van wat traag is. Twee metingen, dan aan het werk.
- Haal velddata van echte bezoekers op — het Core Web Vitals-rapport in Search Console, of je eigen monitoring.
- Draai een labtest op de drie belangrijkste sjablonen, afgeknepen tot een middenklassetelefoon op 4G.
- Noteer de cijfers voordat je begint. Zonder nulmeting kun je niet zeggen of een wijziging hielp.
- Bepaal per sjabloon het grootste losse bestand en het grootste blokkerende verzoek.
- Noteer de Time to First Byte apart: ligt die boven 800 ms, dan redt geen front-endwerk je.
De volgorde die loont#
Ruwweg naar verbetering per uur inspanning, voor een typische content- of brochuresite.
| Werk | Typische winst | Inspanning |
|---|---|---|
| Afbeeldingen optimaliseren en correct schalen | Groot | Laag |
| Ongebruikte scripts van derden verwijderen | Groot | Laag — vooral een politieke klus |
| Caching en een CDN inschakelen | Groot | Laag |
| Renderblokkerende CSS en JS oplossen | Gemiddeld tot groot | Gemiddeld |
| De JavaScript-bundel verkleinen | Gemiddeld tot groot | Gemiddeld tot hoog |
| Trage databasequery's oplossen | Groot waar van toepassing | Gemiddeld |
| Het laden van lettertypen optimaliseren | Gemiddeld | Laag |
| Tekstbestanden verkleinen en comprimeren | Klein | Laag — meestal al aan |
| CSS-selectors micro-optimaliseren | Verwaarloosbaar | Niet de moeite waard |
Afbeeldingen: meestal de grootste winst#
Op de meeste sites vormen afbeeldingen het merendeel van het paginagewicht, en de meeste worden meerdere malen groter geserveerd dan ze worden getoond. Dit is de goedkoopste grote verbetering die er is.
- Serveer WebP of AVIF; beide worden breed ondersteund en zijn bij gelijke kwaliteit meestal 25–50 % kleiner dan JPEG.
- Genereer meerdere formaten en gebruik srcset met sizes zodat telefoons bestanden op telefoonformaat downloaden.
- Serveer nooit een afbeelding van 2000 px in een vak van 400 px — deze ene fout komt buitengewoon vaak voor.
- Laad alles onder de vouw uitgesteld, en niets erboven.
- Automatiseer het in de build of het CMS. Handmatig geoptimaliseerde afbeeldingen houden op geoptimaliseerd te zijn zodra iemand anders er een uploadt.
- Strip metadata; camera-EXIF kan tientallen kilobytes per bestand zijn.
De automatisering is de kern. Een eenmalige optimalisatieronde vervalt binnen maanden naarmate er content bij komt, en niemand merkt het tot het paginagewicht verdubbeld is.
Scripts van derden en de server#
Dit zijn de twee gebieden waar het probleem meestal organisatorisch is in plaats van technisch: niemand is eigenaar van de tagbeheerder, en niemand is eigenaar van de hostingkeuze.
| Probleem | Wat te doen |
|---|---|
| Tagbeheerder met onbekende tags | Elke tag nalopen; alles verwijderen dat niemand kan verantwoorden |
| Chatwidget die op elke pagina laadt | Bij interactie laden, of alleen waar ondersteuning nodig is |
| Meerdere statistiekhulpmiddelen | Er één houden; elk is een volledig script en een verbinding |
| A/B-testscript dat rendering blokkeert | Naar de server verplaatsen, of een flits accepteren en async laden |
| Trage TTFB op gedeelde hosting | Volledige paginacaching toevoegen; pakket ophogen als het aanhoudt |
| Ongecachete databasequery's | De dure cachen; indexen toevoegen voor de veelvoorkomende |
| Geen CDN | Er een toevoegen — de goedkoopste wereldwijde vertragingsoplossing die er is |
Scripts van derden zijn de betrouwbaarste bron van onverklaarde vertragingen, omdat ze veranderen zonder het je te vertellen en buiten je uitrolproces vallen.
Veelgestelde vragen
Wat is een goede laadtijd?
De bruikbare doelen zijn de Core Web Vitals-drempels in plaats van één laadgetal: LCP onder 2,5 seconden en Time to First Byte onder 800 ms. Totale laadtijd is een slechte maat omdat een pagina lang bruikbaar kan zijn voordat elk bestand klaar is, en op een traag apparaat ruim daarvoor al onbruikbaar.
Verhoogt een snellere site de conversie?
Doorgaans wel, en het effect is het grootst waar pagina's nu traag zijn en bezoekers op mobiele netwerken zitten. De winst van drie seconden naar twee is veel groter dan die van anderhalf naar één. Is je site al snel, besteed de inspanning dan aan content en helderheid — het rendement is beter.
Lossen cache-plug-ins alles op?
Ze lossen één echt ding goed op — herhaald serverwerk voor dezelfde pagina — en ze kunnen nieuwe problemen veroorzaken, vooral bij ingelogde gebruikers, winkelmandjes en formulieren. Ze doen ook niets aan te grote afbeeldingen of scripts van derden, meestal de grotere problemen. Nuttig, niet voldoende.
Is serverside renderen de moeite waard voor snelheid?
Worden je pagina's nu alleen in de browser gerenderd, dan ja: serverside renderen of statisch genereren neemt een hele heen-en-weergang weg voordat content verschijnt, en het helpt tegelijk de indexering. Zijn je pagina's al serverside gerenderde HTML, dan speelt de vraag niet — je hebt het voordeel al.
sitesnelheid optimaliserenpaginasnelheidwebsiteprestatiesbeeldoptimalisatiecachingcdn
