DurfMakersWebsite bezoeken →
← Terug naar blog

Website snelheid verbeteren: de 12 acties die echt verschil maken

9 oktober 2026
Website snelheid verbeteren: de 12 acties die echt verschil maken

Wil je je website snelheid verbeteren, focus dan eerst op hosting en TTFB, afbeeldingscompressie, caching en het verminderen van JavaScript. Dat zijn de vier maatregelen met het meeste rendement. Streef naar LCP van 2,5 seconden of minder, CLS onder 0,1 en INP onder 200 milliseconden, zoals Google's eigen thresholds aangeven. Meet eerst je huidige situatie, dan pas ga je wijzigen.

Kort samengevat:

  • Google beoordeelt de kernwaarden voor webprestaties op het 75e percentiel: driekwart van je bezoekers moet de grenswaarden halen, niet alleen een gemiddelde test.
  • Meet eerst de homepage en drie pagina’s die omzet opleveren; herhaal daarna dezelfde test na elke wijziging, zodat je het effect kunt vergelijken.
  • Afbeeldingen comprimeren en de browsercache aanpassen kun je meestal zelf; voor code opsplitsen en een verspreidingsnetwerk instellen heb je vaak een ontwikkelaar nodig.
  • Laad afbeeldingen, video’s en ingesloten kaarten onder de eerste schermweergave pas wanneer nodig, maar laat zichtbare hoofdafbeeldingen direct laden om vertraging te voorkomen.
  • Controleer je kernwaarden voor webprestaties elke paar weken, want updates van je thema, nieuwe uitbreidingen en meetcodes kunnen eerdere verbeteringen ongedaan maken.
Sneleenwebsitenodig
Een snelle website begint bij de bouw
Durfmakers bouwt websites op maat en maakt ze technisch vindbaar vanaf de eerste dag, ook voor ondernemers die snelheid belangrijk vinden.
Bekijk hoe Durfmakers werkt

Inhoudsopgave

12 snelle wins voor een snellere website, op volgorde van impact

Je hoeft niet alles tegelijk aan te pakken. Deze lijst staat op volgorde van wat doorgaans het meeste effect heeft per geïnvesteerd uur.

  1. Kies een goede host of upgrade je hosting: een trage server verhoogt je TTFB (time to first byte) direct, nog voordat er één pixel op het scherm staat.
  2. Comprimeer je afbeeldingen: converteer naar WebP of AVIF en comprimeer agressief, dit is meestal de grootste winst voor LCP.
  3. Gebruik srcset voor responsieve afbeeldingen: laad geen desktopformaat op een telefoonscherm.
  4. Zet browsercaching goed in: stel cache-headers in zodat terugkerende bezoekers bestanden niet opnieuw moeten downloaden.
  5. Minimaliseer en bundel CSS en JavaScript: minder code betekent minder werk voor de browser.
  6. Verwijder render-blocking scripts uit de kritieke laadpad: plaats niet-essentiële scripts onderaan of laad ze asynchroon.
  7. Pas code-splitting toe: laad alleen de JavaScript die een pagina daadwerkelijk nodig heeft, Web.
  8. Overweeg een CDN: een content delivery network haalt bestanden dichter bij de bezoeker vandaan en verlaagt daarmee TTFB.
  9. Reserveer ruimte voor dynamische content: widgets, advertenties en embeds die later laden, schuiven anders je layout omlaag.
  10. Gebruik lazy loading, maar niet overal: pas het toe op content onder de vouw, niet op je hero-afbeelding.
  11. Beperk het aantal lettertypen en varianten: elk extra gewicht van een webfont is extra laadtijd.
  12. Controleer plugins en externe scripts: elke toevoeging van een derde partij kost laadtijd, ook als je zelf niets aanpast.

De eerste zes punten kun je vaak zelf regelen via je hostingpaneel of CMS-instellingen. Vanaf code-splitting en CDN-configuratie heb je meestal een developer nodig, zeker als je thema of platform dat niet standaard ondersteunt.

Pro-tip: Gebruik lazy loading nooit op afbeeldingen die direct zichtbaar zijn bij het laden van de pagina. Dat vertraagt juist je LCP, terwijl het doel net is om die sneller te maken.

Pro-tip: Geef je belangrijkste afbeelding (meestal de hero-afbeelding) een fetchpriority="high" attribuut of een preload-tag in de head van je pagina. Zo weet de browser meteen dat dit bestand voorrang krijgt.

Wat LCP, CLS en INP betekenen en welke waarden je moet halen

Core Web Vitals zijn de drie metrics waarmee Google de ervaring van een bezoeker meet. Ze zijn niet alleen een technisch detail, ze hangen direct samen met hoeveel bezoekers daadwerkelijk klant worden.

  • LCP (Largest Contentful Paint): de tijd tot het grootste zichtbare element is geladen, meestal een hero-afbeelding of kopregel. Streefwaarde: 2500 milliseconden of minder.
  • CLS (Cumulative Layout Shift): hoeveel de inhoud van je pagina verspringt tijdens het laden. Streefwaarde: 0,1 of lager.
  • INP (Interaction to Next Paint): hoe snel je site reageert op een klik of tik. Streefwaarde: 200 milliseconden of minder.

Deze drempels gelden op het 75e percentiel van je bezoekers, niet als gemiddelde. Dat betekent dat driekwart van je bezoekers deze waarden moet halen voordat Google je pagina als "goed" beoordeelt.

Een seconde snelheidswinst kan de conversieratio op mobiel aanzienlijk verhogen, blijkt uit onderzoek van Shopify. Dat is geen marginale verbetering: het is het verschil tussen een bezoeker die afhaakt en een bezoeker die klant wordt. Hetzelfde onderzoek laat zien dat het afhaakrisico sterk toeneemt zodra een pagina langer dan drie seconden nodig heeft om te laden.

Snelheid testen: welke tools je gebruikt en hoe je begint

Meten gaat vooraf aan verbeteren. Zonder een nulmeting weet je niet of een aanpassing echt iets opleverde.

  • PageSpeed Insights: combineert labdata met echte veldgegevens van Chrome-gebruikers, handig als startpunt voor elke pagina.
  • WebPageTest: geeft een gedetailleerde waterfall-analyse, geschikt om precies te zien welk bestand je laadtijd vertraagt.
  • Chrome DevTools: ingebouwd in je browser, nuttig om live te zien welke scripts renderen blokkeren.

Begin met een baseline meting op je belangrijkste pagina's: de homepage en de pagina's waar bezoekers converteren. Voer daarna een lab-test uit via WebPageTest om de exacte resource-waterfall te zien. Check vervolgens de velddata in PageSpeed Insights, dat toont hoe echte bezoekers je site ervaren, niet alleen een gesimuleerde test. Test wijzigingen bij voorkeur eerst op een staging-omgeving voordat je ze live zet.

In een rapport let je op drie dingen: welk bestand je LCP-element vertraagt, welke scripts het renderen blokkeren en welke afbeeldingen onnodig groot zijn. CLS-problemen herken je meestal aan dynamische content die geen vaste ruimte heeft gekregen, zoals ook web.dev beschrijft.

Prioriteren: wat je eerst oplost en hoe je het rendement inschat

Niet elke fix is evenveel moeite waard. Zet impact tegenover inspanning voordat je aan een lijst met taken begint.

Begin altijd bij hoge impact en lage kost. Shopify noemt afbeeldingscompressie en cache-headers expliciet als laaghangend fruit dat vaak zonder grote ontwikkelkosten uitvoerbaar is.

  1. Inventariseer eerst: laat een PageSpeed Insights-rapport maken van je drie belangrijkste pagina's.
  2. Pak de laaghangende fixes zelf aan: afbeeldingscompressie en cache-instellingen vragen meestal geen developer.
  3. Briefing opstellen voor je developer of bureau: benoem concreet welke LCP-, CLS- en INP-waarden je nu meet en welke je wilt halen.
  4. Plan een hertest na elke wijziging: zo weet je zeker dat een aanpassing ook echt werkt.
  5. Stel een KPI vast: bijvoorbeeld "LCP onder 2,5 seconden op mobiel binnen vier weken."

Wie behoefte heeft aan een bredere blik op hoe snelheid past binnen je merk- en conversiedoelen, vindt relevante denkkaders bij Brand Strategy Frameworks.

Pro-tip: Vraag je developer altijd om een voor- en na-rapport uit dezelfde tool. Vergelijk je PageSpeed Insights met WebPageTest, dan vergelijk je appels met peren.

Hoe wij bij Durfmakers snelheid aanpakken bij elke oplevering

Bij elke website die we bouwen, toetsen we de snelheid vóórdat de klant hem te zien krijgt op het testadres. Dat is geen extra stap achteraf, het hoort bij de oplevering.

  • We draaien een Lighthouse-controle op elke pagina voordat we hem laten zien.
  • We comprimeren en formatteren afbeeldingen standaard, zonder dat de klant daar apart om moet vragen.
  • We stellen cachingregels in op serverniveau, niet als losse plugin-oplossing.
  • We checken LCP, CLS en INP tegen de drempelwaarden van Google voordat we het testadres delen.

Omdat je pas betaalt als je de site wilt houden, heb je zelf alle ruimte om de snelheid te controleren voordat je iets beslist. Overweeg je zelf een developer of bureau in te schakelen, vraag dan concreet naar hun Lighthouse-score, hun aanpak voor afbeeldingscompressie en hoe ze caching regelen. Dat zijn de drie vragen die het verschil maken tussen een snelle en een trage oplevering.

HTTP-verzoeken verminderen zonder functionaliteit te verliezen

Elke afbeelding, elk script en elk lettertype dat je pagina laadt, is een apart verzoek aan de server. Meer verzoeken betekent meer wachttijd, zeker op mobiele verbindingen.

Begin met een inventarisatie: open je site in Chrome DevTools en kijk naar het aantal verzoeken op het Network-tabblad. Vaak zie je tientallen aparte bestanden waar een handvol zou kunnen volstaan.

Bundel CSS- en JavaScript-bestanden waar mogelijk, in plaats van losse bestanden per functie te laden. Combineer kleine iconen in een sprite of gebruik inline SVG's in plaats van losse afbeeldingsbestanden. Verwijder plugins of widgets die je niet meer gebruikt, elke geïnstalleerde plugin kan eigen scripts en stylesheets toevoegen zonder dat je dat doorhebt.

Afbeelding van afzonderlijke bestanden en gebundelde aanvragen

Controleer ook of je site dubbele verzoeken doet, bijvoorbeeld wanneer een thema en een plugin allebei dezelfde jQuery-versie laden. Dat soort overlap is vaak onopgemerkt en relatief eenvoudig op te lossen zodra je het ziet.

Lazy loading toepassen op video's en iframes, niet alleen op afbeeldingen

Lazy loading wordt meestal geassocieerd met afbeeldingen, maar video's en iframes profiteren er net zo goed van, vaak nog meer omdat ze zwaarder zijn.

Een ingebedde YouTube-video of Google Maps-iframe laadt standaard direct mee, ook als een bezoeker nooit naar dat deel van de pagina scrolt. Gebruik het loading="lazy" attribuut op iframes, of laad de video pas in zodra een bezoeker op een thumbnail klikt in plaats van de volledige videospeler meteen te initialiseren.

Dezelfde regel als bij afbeeldingen geldt hier: alles wat boven de vouw staat, laad je direct. Alles daaronder mag wachten tot de bezoeker ernaartoe scrolt. Web.dev waarschuwt dat te veel lazy loading juist averechts werkt wanneer het wordt toegepast op content die meteen zichtbaar is.

Vermijd ook non-standaard implementaties die een video pas laden via een data-src-attribuut in plaats van de normale HTML-structuur. Web.dev raadt aan om standaard src- en srcset-attributen te gebruiken, zodat zoekmachines en metingstools de content correct herkennen, ook voordat JavaScript is uitgevoerd.

Snelheid is geen project, het is een gewoonte

De meeste ondernemers behandelen snelheid als een eenmalige klus: optimaliseren, vergeten, en pas weer kijken als klanten klagen. Dat is precies waar het misgaat. Een thema-update, een nieuwe plugin of een extra trackingscript kan maanden werk ongedaan maken binnen een paar weken.

Stel een vast ritme in: controleer je Core Web Vitals elke paar weken, niet pas wanneer de conversie daalt. Wie snelheid behandelt als iets dat je één keer regelt en daarna laat liggen, betaalt daar op de lange termijn in gemiste omzet voor terug.

— Patrick

Wanneer schakel je Durfmakers in voor je website snelheid

Heb je geen tijd of zin om zelf aan afbeeldingscompressie, caching en code-splitting te sleutelen, dan bouwen we je site graag met snelheid als uitgangspunt vanaf de eerste regel code.

Sneleenwebsitenodig

Zo werkt onze aanpak:

  • We bouwen je site eerst volledig af en laten hem zien op een testadres, je betaalt pas als je hem wilt houden.
  • Elke site krijgt standaard een snelheidscontrole voordat je hem te zien krijgt.
  • Na betaling krijg je volledig eigendom van broncode en ontwerp, zonder abonnement.

Prijzen zijn vooraf bekend en eenmalig; actuele details staan op onze website. Bekijk Start en Compleet en zie zelf hoe je site eruitziet voordat je iets betaalt.

Veelgestelde vragen

Wat is een goede laadtijd voor een website?

Er bestaat geen vaste seconde-grens, maar de richtlijn is dat je LCP onder 2,5 seconden blijft. Dat is de waarde waarop Google de ervaring van de meeste bezoekers als goed beoordeelt.

Hoeveel sneller wordt mijn site door afbeeldingen te comprimeren?

Dat verschilt per site, maar afbeeldingscompressie behoort tot de maatregelen met het snelste rendement omdat afbeeldingen vaak het grootste deel van de paginagrootte vormen. Shopify noemt dit expliciet als laaghangend fruit dat meestal zonder grote ontwikkelkosten uitvoerbaar is.

Wat is het verschil tussen LCP, CLS en INP?

LCP meet hoe snel het grootste zichtbare element laadt, CLS meet hoeveel je pagina visueel verspringt tijdens het laden en INP meet hoe snel je site reageert op een klik of tik. Google stelt voor elk een eigen streefwaarde: LCP onder 2500 milliseconden, CLS onder 0,1 en INP onder 200 milliseconden.

Kan Durfmakers mijn bestaande website sneller maken?

Durfmakers bouwt complete, op maat gemaakte websites met snelheid als vast onderdeel van de oplevering, van onepager tot meerdere pagina's. Je betaalt pas als je de site wilt houden, en je ziet de werkelijke snelheid eerst op een testadres via Start en Compleet.

Welke tool gebruik ik het beste om mijn website te testen?

PageSpeed Insights is het makkelijkste startpunt omdat het zowel labdata als echte gebruikersdata toont. Voor een diepgaande analyse van losse bestanden en vertragingen is WebPageTest geschikter, vooral om de exacte oorzaak van een trage LCP te vinden.

Bronnen

Elk extern script dat je pagina laadt, kost tijd, ook als je het zelf niet hebt geschreven. Google Fonts, chatwidgets en social media-embeds zijn de grootste boosdoeners.

Host lettertypen bij voorkeur lokaal in plaats van ze bij elk paginabezoek op te halen bij een externe server. Dat scheelt een extra netwerkverbinding. Gebruik font-display: swap zodat tekst zichtbaar blijft terwijl het lettertype nog laadt, in plaats van een lege pagina te tonen.

Social media-widgets, zoals een ingebedde Instagram-feed of een Facebook-like-knop, laden vaak hun eigen trage scripts. Overweeg een statische afbeelding met een link in plaats van een live widget, zeker als de widget zelden wordt aangeklikt. Plaats scripts die niet direct nodig zijn voor de eerste weergave onderaan de pagina of laad ze pas na een gebruikersactie, zoals scrollen.

Chatwidgets en advertentietags zijn ook een bekende oorzaak van layout shifts: als zo'n widget pas na enkele seconden inlaadt en ruimte claimt die eerst leeg was, verspringt je pagina. Web.dev adviseert om altijd ruimte te reserveren met CSS voordat zo'n element verschijnt, zodat de rest van de pagina niet schokt.

Aanbevelingen