Website sneller maken: pak eerst de grootste rem aan

Een trage website kost aandacht. Niet omdat elke bezoeker met een stopwatch klaarzit, maar omdat wachten irritant is. Zeker op mobiel.

Deze gids is voor ondernemers die willen weten waar ze moeten beginnen. Niet met losse trucjes, maar met een volgorde die meestal het meeste effect geeft per uur werk. Je leert wanneer je afbeeldingen aanpakt, wanneer scripts de boosdoener zijn, wanneer hosting verdacht wordt en wanneer caching nuttig is.

Snelheid voelt simpel, maar meten is rommelig. Je eigen laptop, wifi en browser zeggen niet genoeg. Google kijkt bij Core Web Vitals naar echte gebruikers en beoordeelt de 75e percentielwaarde. Dat betekent: niet de beste meting, maar ook niet de slechtste uitschieter.

De belangrijkste waarden zijn:

• —
  LCP: goed bij ≤2,5 s, slecht boven 4,0 s.
• —
  INP: goed bij ≤200 ms, slecht boven 500 ms.
• —
  CLS: goed bij ≤0,1, slecht boven 0,25.

LCP gaat over het grootste zichtbare beeld- of tekstelement in de viewport. Vaak is dat een hero-afbeelding, grote titel of productfoto. INP gaat over hoe snel de site reageert op interactie. CLS gaat over verspringende layout.

Een Lighthouse-score kan helpen, maar staar je er niet blind op. Een score van 100 garandeert geen hoge Google-ranking. Google gebruikt meerdere signalen en Core Web Vitals zijn slechts onderdeel van page experience. Wil je breder naar technische vindbaarheid kijken, dan is de technische SEO-checklist voor MKB-websites een logische aanvulling.

Beslisregel: als je niet weet welke Core Web Vital slecht is, meet dan eerst en pas daarna ga je optimaliseren.

Bij veel MKB-sites zitten de grootste snelheidsproblemen in afbeeldingen. Denk aan een homepage met een grote sfeerfoto, een webwinkel met zware productfoto’s of een blog waar foto’s rechtstreeks uit de camera zijn geplaatst.

Als je LCP slecht is en het grootste element een afbeelding is, begin dan daar. Niet bij kleine CSS-aanpassingen. Niet bij een extra plugin. Eerst de afbeelding die de bezoeker direct ziet.

Let op drie dingen.

Gebruik het juiste formaat. WordPress ondersteunt sinds versie 6.5 het uploaden en gebruiken van AVIF-afbeeldingen. WordPress noemt AVIF-bestanden tot 50% kleiner dan JPEG bij dezelfde beeldkwaliteit. Dat kan flink schelen, vooral bij grote foto’s.

Reserveer ruimte. Afbeeldingen horen expliciete width en height te hebben, of een CSS aspect-ratio. Zonder gereserveerde ruimte kan de layout verspringen zodra de afbeelding geladen is. Dat verhoogt CLS.

Laad niet alles lui. Google adviseert afbeeldingen buiten de eerste viewport lazy te laden. Maar afbeeldingen die direct zichtbaar zijn, moet je juist niet lazy-loaden als ze belangrijk zijn voor LCP. De hero-afbeelding uitstellen voelt slim, maar kan de belangrijkste render vertragen.

Een herkenbaar voorbeeld. Stel, voorbeeld.nl heeft bovenaan een grote foto van een afgeronde verbouwing. Die foto is het grootste zichtbare element. De rest van de pagina is redelijk licht. Dan levert het meestal meer op om die foto goed te maken dan om onderaan de pagina kleine icoontjes te optimaliseren.

Beslisregel: als de LCP slecht is en het grootste zichtbare element een afbeelding is, optimaliseer eerst die afbeelding en laad die niet lazy.

Een derde partij is alles wat niet van je eigen website komt. Denk aan analytics, chat, reviews, betaalmodules, advertentiepixels, consenttools en webshopapps. Sommige zijn nodig. Andere zijn ooit toegevoegd en nooit meer opgeruimd.

web.dev adviseert third-party scripts te auditen omdat ze netwerkverzoeken, JavaScript-uitvoering en main-thread blocking kunnen toevoegen. Simpel gezegd: je browser moet wachten, rekenen of bestanden ophalen voor iets wat niet altijd direct waarde toevoegt.

In Lighthouse 10 telt Total Blocking Time voor 30% mee in de performance-score. LCP telt voor 25%, CLS voor 25%, FCP voor 10% en Speed Index voor 10%. Zware JavaScript is daarom vaak een grotere hefboom dan kleine CSS-aanpassingen.

Dit is vooral belangrijk bij webshops. Een fictieve webwinkel met betaalprovider, reviewwidget, chatfunctie, tracking, pop-up en meerdere apps kan technisch snel een drukke pagina worden. De bezoeker ziet één productpagina, maar de browser ziet een stapel externe scripts.

Voor Shopify geldt nog iets extra’s. Shopify waarschuwt dat apps code aan een thema kunnen toevoegen en dat verwijderen van een app niet altijd automatisch alle toegevoegde code verwijdert. Een app verwijderen betekent dus niet automatisch dat de prestatie-impact weg is. Achtergebleven theme-code kan blijven laden.

Beslisregel: als een script geen omzet-, betaal-, consent- of analyticswaarde heeft, verwijder het of stel het uit na meting van de impact.

TTFB staat voor Time to First Byte. Dat is de tijd totdat de browser de eerste reactie van de server krijgt. Als die traag is, kun je aan de voorkant poetsen wat je wilt, maar de pagina start al laat.

Google classificeert TTFB als goed bij ≤0,8 s, verbetering nodig bij >0,8 s en ≤1,8 s, en slecht bij >1,8 s. Gebruik dat als grove beslisregel. Niet elke trage site heeft slechte hosting. Soms is de server snel, maar de pagina zwaar. Soms is de pagina netjes, maar de server traag.

Bij WordPress of WooCommerce kan een slechte TTFB komen door hosting, databasequeries, plugins of een zwaar thema. Bij maatwerk kan het ook in backend-code zitten. Bij Shopify heb je minder controle over hosting zelf, maar wel over thema, apps en scripts.

Dit is ook het punt waarop ik eerlijk ben: hosting upgraden is niet altijd de beste keuze. Als je TTFB goed is en je LCP-afbeelding te zwaar is, koop je met betere hosting vooral een prettig gevoel. De echte rem blijft staan.

Beslisregel: als TTFB slecht is, onderzoek hosting of backend vóór frontend-micro-optimalisatie.

Caching betekent dat je iets bewaart zodat het niet steeds opnieuw opgebouwd hoeft te worden. Dat kan veel schelen, maar het is geen magische knop. Vooral bij WordPress en WooCommerce moet je opletten waar caching veilig is.

WooCommerce beveelt aan om dynamische pagina’s zoals winkelwagen, afrekenen en mijn account uit pagina-cache te houden. Caching van deze pagina’s kan verkeerde winkelwagen- of sessiegegevens tonen. Dat is geen klein schoonheidsfoutje. Dat raakt direct vertrouwen.

Object caching is iets anders. Het WordPress Performance Team adviseert object caching vooral voor sites met herhaalde databasequeries. Op hosting met persistente objectcache kan dit backend-responstijd verlagen. Simpele brochurewebsites zien vaak minder winst.

Caching is dus contextwerk. Voor een simpele dienstenwebsite kan pagina-cache genoeg zijn. Voor een grotere WooCommerce-site moet je nauwkeuriger kijken. Vooral als bezoekers inloggen, winkelwagens gebruiken of persoonlijke informatie zien.

Beslisregel: als een pagina persoonlijke, winkelwagen- of sessiegegevens toont, zet die pagina niet in volledige page cache.

De volgorde blijft hetzelfde, maar het platform bepaalt waar je kijkt.

Bij WordPress begin je vaak met afbeeldingen, thema en plugins. Sinds WordPress 6.5 kun je AVIF gebruiken. Dat maakt afbeeldingoptimalisatie praktischer. Daarna kijk je naar caching, object caching en overbodige scripts.

Bij WooCommerce moet je voorzichtiger zijn met caching. Productpagina’s, categoriepagina’s en content kunnen vaak profiteren. Winkelwagen, afrekenen en mijn account moeten dynamisch blijven. Als daar iets misgaat, voelt je webshop onbetrouwbaar.

Bij Shopify kijk je vooral naar thema, apps en app-code. De Shopify Theme Store vereist voor thema-indiening een gemiddelde Lighthouse performance-score van minimaal 60 over home-, product- en collectiepagina’s op mobiele tests. Dat zegt niet dat elke Shopify-site vanzelf snel is. Apps en theme-aanpassingen kunnen nog steeds vertragen.

Als je een nieuwe site of webshop laat bouwen, neem snelheid dan mee in de keuzes voor thema, techniek en beheer. Dat valt onder normale webontwikkeling voor ondernemers, niet onder een los trucje achteraf.

Beslisregel: als je Shopify gebruikt, controleer apps en achtergebleven theme-code; als je WooCommerce gebruikt, controleer cachingregels voor dynamische pagina’s.

Een snellere website kan helpen bij gebruikerservaring. Bezoekers hoeven minder te wachten, knoppen reageren beter en pagina’s voelen rustiger. Dat is waardevol.

Maar snelheid is niet hetzelfde als SEO. Een PageSpeed-score van 100 betekent niet dat je bovenaan komt. Voor vindbaarheid heb je ook goede content, technische basis, interne structuur en duidelijke pagina’s nodig. Er is geen vaste regel waarbij een bepaalde score automatisch een bepaalde positie oplevert.

Zie snelheid daarom als een hygiënefactor. Als je website traag is, los je dat op. Als je website snel genoeg is, ga je niet eindeloos schaven voor een hoger rapportcijfer terwijl je aanbod, content of structuur onduidelijk blijft. Wil je de basis snappen, lees dan ook SEO voor MKB-ondernemers en wat Core Web Vitals zijn.

Beslisregel: als je Core Web Vitals goed zijn, besteed dan niet automatisch meer tijd aan snelheid voordat je content en structuur hebt bekeken.

Gebruik deze volgorde als praktische beslisroute. Niet omdat elke site hetzelfde is, maar omdat dit vaak de meeste winst per uur werk geeft.

• —
  Meet eerst Core Web Vitals en TTFB.
• —
  Is LCP slecht en is het grootste element een afbeelding, pak die afbeelding aan.
• —
  Controleer daarna scripts van derden en verwijder of stel uit wat geen duidelijke waarde heeft.
• —
  Is TTFB slecht, onderzoek hosting, backend, database en zware plugins.
• —
  Zet caching goed in, maar houd dynamische WooCommerce-pagina’s erbuiten.
• —
  Controleer bij Shopify of verwijderde apps geen theme-code hebben achtergelaten.
• —
  Stop met optimaliseren zodra de technische rem weg is en kijk dan naar inhoud, aanbod en vindbaarheid.

Wil je een nuchtere check op waar jouw site vastloopt, dan kun je de gratis website-scan gebruiken.

Beslisregel: als je moet kiezen, pak eerst de grootste meetbare rem aan in plaats van de makkelijkste instelling in je CMS.