Website snelheid verbeteren doe je in een vaste volgorde: eerst meten waar de vertraging zit, dan de beelden (vrijwel altijd de grootste post), daarna scripts van derden, fonts, het renderpad en pas als laatste de server. Met alleen de quick wins uit deze gids halen wij bij de meeste webshops al seconden van de laadtijd af; het structurele werk daarna maakt de winst blijvend.
Dit is de werkgids: wat je in welke volgorde doet en waarom. De begrippen en de businesscase staan in ons artikel over website performance, de meetlat in de verdieping over Core Web Vitals. Hier gaan we aan het werk.
Eerst meten: waar lekt jouw snelheid?
Optimaliseren zonder meting is gokken, dus de eerste stap kost geen regel code. Open het Core Web Vitals-rapport in Search Console: dat groepeert je URL's per probleem, op basis van echte bezoekers, en vertelt je of je pijn in het laden (LCP), het reageren (INP) of de stabiliteit (CLS) zit. Draai daarna PageSpeed Insights op één URL per paginatype (home, categorie, product) en scrol naar de bronnenlijst: sorteer op omvang en je ziet meteen of beelden, scripts of fonts je zwaarste post zijn.
Kijk in die waterval naar twee dingen: de grootste bytes (wat weegt het meest) en de langste ketens (wat moet op wat wachten). Een pagina die eerst een script laadt, dat een tweede script ophaalt, dat een font injecteert, is traag ongeacht hoe snel elk onderdeel afzonderlijk is. En meet mobiel: daar zit het merendeel van je bezoekers, op tragere hardware. Wil je de meting liever kant-en-klaar met de knelpunten erbij, doe dan de gratis webshop-analyse.
De volgorde die werkt
Alles wat volgt is geordend op rendement per uur werk. Beelden eerst, want die zijn op de gemiddelde webshop meer dan de helft van het paginagewicht en de fix is grotendeels risicoloos. Dan scripts van derden, want dat is het snelst groeiende blok en niemand houdt het bij. Dan fonts en het renderpad, waar de milliseconden in de honderden lopen. En pas daarna de server, want die is minder vaak het probleem dan iedereen denkt. Voer fixes één voor één door en meet ertussen; alleen zo weet je wat werkte. Zo wordt website snelheid verbeteren een lijst die je afwerkt in plaats van een project dat blijft liggen, en wie zijn pagespeed wil verbeteren zonder die volgorde, eindigt met losse trucjes en een score die niet beweegt.
Stap 1: beelden, de helft van je winst
Serveer een modern formaat. WebP is de veilige standaard en scheelt fors ten opzichte van JPEG en PNG; AVIF gaat daar vaak nog tientallen procenten onder en wordt inmiddels breed ondersteund. Het slimme patroon is beide aanbieden en de browser laten kiezen.
Verlaag de compressiekwaliteit verder dan je denkt. Uit onze eigen beeldpijplijn: kwaliteit 78 is visueel niet te onderscheiden van 86, maar scheelt ongeveer de helft in bestandsgrootte. Vrijwel elke webshop exporteert te voorzichtig en betaalt dat op elke paginaweergave.
Lever de juiste maten. Een beeld hoort geserveerd te worden op de grootte waarop het getoond wordt, per schermformaat (srcset). De klassieke fout blijft de productfoto van duizenden pixels in een kader van driehonderd; controleer het door een beeld in een nieuw tabblad te openen en naar de werkelijke afmetingen te kijken.
Regel de prioriteit. Het hoofdbeeld boven de vouw laadt met voorrang (eager, met een hoge fetchpriority), alles daaronder wacht tot de bezoeker scrolt (lazy loading). Andersom ingesteld, en dat zien we geregeld, wacht je bezoeker op beelden die niet eens in beeld staan.
Reserveer de ruimte. Elk beeld krijgt zijn afmetingen in de code, zodat de pagina niet verspringt wanneer het binnenkomt; een lichte blur-preview maakt het wachten bovendien gevoelsmatig korter. Dit is tegelijk je grootste CLS-winst.
Stap 2: scripts van derden temmen
Pixels, analytics, heatmaps, chatwidgets, reviewsterren: samen vormen ze op veel webshops het grootste blok JavaScript, en het groeit stilletjes omdat er nooit iets af gaat. De aanpak in drie bewegingen:
Inventariseer en schrap. Loop de lijst langs met één vraag per script: wie kijkt er nog naar de data of gebruikt de functie? Tools van vertrokken marketeers en campagnes van vorig jaar laden vrolijk door totdat iemand ze opzegt.
Verplaats wat blijft naar ná de pagina. Marketing-scripts hoeven niet vóór je productfoto te laden. Laad ze na het laadmoment of pas bij interactie, en koppel ze aan je consent-beheer zodat ze bij een weigering helemaal niet laden.
Gebruik facades voor zware embeds. Een YouTube-video of kaart laadt honderden kilobytes aan externe code, ook als niemand erop klikt. Toon een stilstaand voorbeeld met afspeelknop en laad de echte embed pas bij een klik: zelfde functie, fractie van het gewicht.
Wie verder wil: server-side tagging verplaatst het meetwerk van de browser van je bezoeker naar een server, waardoor één licht script overblijft. Dat is een project, geen quick win, maar bij een zwaar opgetuigde marketingstack is het de structurele oplossing.
Stap 3: fonts
Webfonts zijn kleine bestanden met onevenredig veel invloed, omdat tekst erop wacht. De regels: maximaal één fontfamilie in twee gewichten (kop en lopende tekst kunnen ook een systeemfont zijn), altijd woff2, en gesubset tot de tekens die je taal echt gebruikt. Zet font-display op swap zodat tekst direct zichtbaar is in een systeemfont en pas daarna wisselt, en preload het ene font dat boven de vouw nodig is. Wie het maximale wil: een goed gekozen systeemfont-stack kost nul downloads en is op moderne apparaten prima te stylen.
Stap 4: het renderpad en je JavaScript
Tussen "de server antwoordt" en "er staat iets op het scherm" zit het renderpad, en daar verdwijnen de stille honderden milliseconden. De grootste winsten:
Haal blokkades weg. Stylesheets en scripts die in de kop van de pagina laden, blokkeren het tekenen. Kritieke CSS hoort inline, de rest laadt erna; scripts krijgen defer zodat ze de opbouw niet ophouden.
Verklein wat je verstuurt. Elke kilobyte JavaScript moet niet alleen gedownload maar ook uitgevoerd worden, en dat laatste is op een telefoon de dure kant. Minder en kleinere bundels wegen dubbel mee: in de download én in de rekentijd.
Waarschuw de browser vooruit. Een preconnect naar domeinen die zeker nodig zijn (je CDN, je betaalprovider) scheelt een verbindingsopbouw op het kritieke pad.
Maak de volgende klik gratis. Het laden van de vervolgpagina kan alvast beginnen terwijl de bezoeker nog kijkt: prefetch van links die in beeld komen maakt elke tweede paginaweergave vrijwel direct. Zo bouwen wij onze eigen sites, en het verschil voelt iedereen.
Stap 5: server, caching en CDN
Pas als laatste de infrastructuur, want die is minder vaak schuldig dan gedacht, maar wanneer hij het is, remt hij alles. De meetlat is de Time To First Byte: onder de 800 milliseconden geldt als goed, en zit je daar structureel boven, dan begint het gesprek hier.
Cache wat niet verandert. Statische bestanden (beelden, CSS, scripts) krijgen lange cache-headers zodat terugkerende bezoekers ze niet opnieuw downloaden. De pagina zelf kan vaak korter gecachet worden dan je denkt, zeker buiten de winkelwagen.
Serveer vanaf een CDN. Afstand is latentie; een CDN legt kopieën van je bestanden dicht bij de bezoeker. Voor Nederlandse shops met Belgisch en Duits verkeer is dit al merkbaar, internationaal is het onmisbaar.
Comprimeer de tekstkant. HTML, CSS en JavaScript horen gecomprimeerd over de lijn (Brotli waar mogelijk, anders gzip); het is een serverinstelling die soms simpelweg uit staat.
Bouw pagina's vooraf op waar het kan. Een pagina die al klaarstaat als HTML is per definitie sneller dan één die per bezoek wordt opgebouwd. Statische generatie voor content- en categoriepagina's, dynamiek alleen waar het moet: dat is hoe onze eigen site aan zijn snelheid komt.
De verborgen vertragers die bijna niemand checkt
Vier posten die in geen standaardlijstje staan en die wij bij audits geregeld als stille rem vinden:
Interne redirect-ketens. Links in je eigen menu of content die via een oude URL lopen (http naar https, zonder www naar met, oude slug naar nieuwe) kosten elke klik een extra rondreis. Redirects zijn voor de buitenwereld; je eigen links horen rechtstreeks naar het eindadres te wijzen.
A/B-test- en personalisatiescripts. Die moeten vóór de pagina laden om geflikker te voorkomen, en blokkeren daarmee per definitie het renderen. Draai ze alleen op pagina's waar echt een test loopt, en ruim afgeronde tests direct op.
Zoek- en filterfuncties zonder rem. Een zoekveld dat bij elke toetsaanslag een verzoek afvuurt of een filter dat het hele grid opnieuw opbouwt, voelt traag en drukt je INP. Een kleine vertraging inbouwen voordat het zoeken start (pas na het typen) lost het vrijwel gratis op.
Polyfills en bibliotheken voor browsers die niemand meer gebruikt. Oudere thema's slepen ondersteuningscode mee voor browsers die je statistieken al jaren niet meer laten zien. Die code laadt en draait wél, elke paginaweergave opnieuw.
Eerste bezoek versus terugkerend bezoek
Eén nuance die het meetbeeld op zijn plek zet: de zwaarste meting is altijd het éérste bezoek, op een koud apparaat, zonder cache. Precies dat is het bezoek van je advertentieklik, en dus het bezoek waar je marketingbudget aan hangt; een trage landingspagina betaalt zich door in elke campagne, tot en met de kwaliteitsscore van je advertenties. Terugkerende bezoekers profiteren van je cache-werk en zitten er vaak ruim onder. Optimaliseer daarom op het koude eerste bezoek en beschouw de snelle herhaalbezoeken als bonus, niet andersom: wie alleen zijn eigen (gecachete) beleving meet, overschat zijn webshop structureel.
Structureel: als het gewicht in je fundament zit
Soms is de eerlijke conclusie na de meting dat het probleem niet in de aankleding zit maar in het fundament: een thema of plugin-stapel die per pagina meer aansleept dan je ooit wegoptimaliseert. Dan is de structurele route een licht, op maat gebouwd thema dat alleen bevat wat jouw winkel nodig heeft. Draai je op Shopify, begin dan bij de negen Shopify-specifieke fixes; blijkt het thema zelf de rem, dan lees je bij onze aanpak voor thema-development hoe wij dat oplossen, met groene Core Web Vitals als opleveringseis.
Het 30-dagenplan
Zo ziet de gids eruit als kalender:
Week 1: meten en beelden. Nulmeting vastleggen per paginatype, daarna de volledige beeldronde: formaat, kwaliteit, maten, prioriteit, gereserveerde ruimte. Dit is de week met de grootste zichtbare winst.
Week 2: scripts en fonts. De inventarisatieronde langs alle derde partijen, facades op de embeds, en de fontregels doorvoeren. Vooral opruimwerk; weinig risico, veel effect.
Week 3: renderpad en server. Het technische deel, samen met je ontwikkelaar: blokkades uit de kop, defer, preconnect, cache-headers en compressie controleren. Hier verdwijnen de laatste honderden milliseconden.
Week 4: nameten en borgen. Labscores vergelijk je direct, de veldcijfers volgen in de weken erna (het venster loopt 28 dagen). Leg vast wat gewonnen is, en spreek een snelheidsbudget af.
Dat snelheidsbudget is de borging: een simpele afspraak dat elke nieuwe app, elk nieuw script en elk campagnebeeld vooraf gewogen wordt op wat hij kost. Snelheid verlies je namelijk zelden in één keer; je verliest hem in twaalf kleine besluiten per jaar waar niemand bij stilstond.
Wat het oplevert
De cijfers blijven de moeite van het herhalen waard: boven de 3 seconden laadtijd haakt meer dan de helft van de mobiele bezoekers af, en een halve seconde snellere webshop kan tot 10 procent meer omzet opleveren. Snelheid is bovendien sinds 2021 een rankingfactor en, belangrijker, de basis onder elke conversie die je daarna optimaliseert. Wil je weten waar jouw webshop vandaag staat en waar de eerste seconden te halen zijn? Doe de gratis webshop-analyse of plan een vrijblijvende call: dan bepalen we samen jouw volgorde langs deze gids.
