Uw website sneller maken, meetbaar en blijvend

Een trage website voelt voor de bezoeker als een winkel waar niemand aan de balie staat. Even wachten, nog even wachten, en dan toch maar weg. Dat gedrag is inmiddels goed in kaart gebracht. Uit onderzoek van Google blijkt dat de kans dat een bezoeker een mobiele pagina verlaat met ruim dertig procent toeneemt zodra de laadtijd van één naar drie seconden gaat; bij vijf seconden loopt dat op tot ongeveer negentig procent. Ander onderzoek in de detailhandel laat zien dat elke tiende seconde snelheidswinst de conversie meetbaar verhoogt, met percentages die per branche tussen de vijf en tien procent liggen.

Voor een Nederlandse ondernemer met een website die aanvragen of bestellingen moet opleveren, betekent dat iets concreets. Stel dat uw website maandelijks 4.000 bezoekers trekt en dat twee procent daarvan een aanvraag doet: tachtig aanvragen. Wordt de website merkbaar sneller en stijgt de conversie naar 2,4 procent, dan zijn dat 96 aanvragen. Zestien extra aanvragen per maand, zonder één euro extra aan advertenties of één extra bezoeker.

Daar komt de rol van Google bij. Sinds enkele jaren gebruikt Google de laadsnelheid en de gebruikerservaring van een pagina als een van de factoren voor de rangschikking. Snelheid maakt van een middelmatige website geen nummer één, maar bij twee vergelijkbare websites heeft de snellere een streepje voor. Wij doen geen beloftes over posities in Google; wel zien wij dat een structureel trage website het zichzelf onnodig moeilijk maakt.

Mobiel verdient daarbij aparte aandacht. Bij de meeste van onze klanten komt inmiddels meer dan zestig procent van de bezoekers via een telefoon. Die telefoon hangt vaak aan een 4G-verbinding in de trein of op een bouwplaats, met een processor die trager is dan uw laptop. Een website die op uw kantoorcomputer prima aanvoelt, kan op die telefoon vijf seconden nodig hebben. Bij het meten en optimaliseren kijken wij daarom altijd eerst naar mobiel; wat daar goed werkt, werkt op een computer vanzelf.

Snelheidsoptimalisatie is dus geen technisch hobbyproject, maar een investering met een meetbaar rendement. Wij bieden het aan als eenmalig traject vanaf € 199, en als vast onderdeel van ons onderhoud voor klanten die willen dat de winst blijft.

Google heeft de gebruikerservaring van een pagina samengevat in drie meetwaarden, de Core Web Vitals. Ze klinken technisch, maar elk van de drie beschrijft iets wat u als bezoeker direct voelt. Wie ze begrijpt, begrijpt ook waarom een rapport zegt dat een website 'snel' of 'traag' is, en waar de winst zit.

LCP, Largest Contentful Paint: hoe snel ziet u het belangrijkste. Dit is de tijd tussen het intikken van het adres en het moment waarop het grootste zichtbare element op het scherm staat, meestal de grote foto of de kop bovenaan de pagina. Google wil dat dit binnen 2,5 seconden gebeurt. Een trage LCP heeft bijna altijd te maken met een te grote afbeelding bovenaan, een trage server, of scripts die eerst geladen moeten worden voordat de pagina mag worden getekend.

INP, Interaction to Next Paint: hoe snel reageert de pagina op u. U tikt op een menuknop, opent een filter of klikt op 'toevoegen aan winkelwagen'. INP meet hoe lang het duurt voordat de pagina zichtbaar reageert, gemeten over alle interacties tijdens een bezoek. De grens ligt op 200 milliseconden. Een slechte INP voelt als een website die 'plakt': u klikt, er gebeurt even niets, en dan ineens wel. De oorzaak is vrijwel altijd te veel JavaScript dat de browser bezighoudt, bijvoorbeeld van plugins, chatwidgets, trackingscripts en zware thema's.

CLS, Cumulative Layout Shift: verspringt de pagina onder uw vingers. Iedereen kent het: u wilt op een knop tikken, er laadt boven de knop nog een afbeelding of een banner in, de knop schuift naar beneden en u tikt op iets anders. CLS meet hoeveel de pagina tijdens het laden verschuift. Google wil een waarde onder 0,1. Oorzaken zijn afbeeldingen zonder vooraf opgegeven afmetingen, lettertypen die later inladen en de tekst laten verspringen, en advertenties of cookiemeldingen die ruimte innemen die niet was gereserveerd.

Deze drie waarden worden door Google gemeten bij echte bezoekers van uw website, via de Chrome-browser, en samengevat in Search Console. Dat is de score die telt. Een pagina 'slaagt' als minstens 75 procent van de bezoeken binnen de grenzen valt. Bij een snelheidsoptimalisatie richten wij ons dus niet op één mooi cijfer in een testtool, maar op het verbeteren van deze drie waarden voor de bezoekers die u daadwerkelijk krijgt.

Wie zijn website in PageSpeed Insights invoert, krijgt een score tussen 0 en 100, in rood, oranje of groen. Die score is nuttig, maar wordt vaak verkeerd begrepen. Een score van 62 is geen rapportcijfer voor uw website, en een score van 95 betekent niet dat uw bezoekers een snelle website ervaren. Om goed te optimaliseren gebruiken wij verschillende metingen naast elkaar, elk met een eigen doel.

• PageSpeed Insights en Lighthouse (labmetingen). Een gesimuleerde bezoeker met een langzame telefoon en een beperkte verbinding laadt uw pagina één keer. Het resultaat is reproduceerbaar en geeft een gedetailleerde lijst van verbeterpunten. Nadeel: het is een momentopname vanaf één locatie, en de score schommelt van test tot test. Wij gebruiken labmetingen om oorzaken te vinden, niet om succes te meten.
• CrUX en Search Console (veldmetingen). CrUX, het Chrome User Experience Report, bevat de werkelijke Core Web Vitals van echte bezoekers over de afgelopen 28 dagen. In Search Console ziet u per groep pagina's of ze 'goed', 'verbetering nodig' of 'slecht' scoren. Dit zijn de cijfers die Google gebruikt en die het echte gedrag weerspiegelen. Nadeel: ze lopen weken achter en zijn bij kleine websites soms niet beschikbaar.
• Eigen metingen vanuit Nederland. Testtools meten vaak vanuit een datacenter in de Verenigde Staten of Duitsland. Wij meten daarnaast vanaf Nederlandse locaties, omdat uw bezoekers daar zitten. Een website die op een Nederlandse server staat, presteert hier anders dan vanuit Frankfurt.
• Metingen op specifieke pagina's. De homepage is zelden de pagina die het meest wordt bezocht. Wij meten de pagina's die er voor u toe doen: de dienstenpagina waar aanvragen vandaan komen, de productpagina's, de contactpagina.

Bij de start van een optimalisatie leggen wij een nulmeting vast: labscores, veldgegevens waar beschikbaar, en de laadtijd van de vijf belangrijkste pagina's op mobiel en desktop. Na afloop herhalen wij die meting op dezelfde manier, zodat u een eerlijke vergelijking krijgt en niet een cijfer dat toevallig gunstig uitviel. Enkele weken later kijken wij opnieuw naar Search Console om te zien of de veldgegevens de verbetering bevestigen.

Wat u zelf kunt controleren: open Search Console, kies 'Core Web Vitals' en bekijk of er pagina's in de categorie 'slecht' staan. Dat overzicht zegt meer over de ervaring van uw bezoekers dan welke losse score dan ook.

Bij het overgrote deel van de trage WordPress-websites die wij zien, zijn afbeeldingen de grootste boosdoener. Een foto rechtstreeks van de camera of van een stockfotosite is al snel vier tot acht megabyte en 5.000 pixels breed, terwijl hij op een telefoon in een vak van 400 pixels wordt getoond. De browser downloadt dan tientallen keren meer gegevens dan nodig, en de bezoeker wacht. Een homepage van tien megabyte is geen uitzondering; die hoort onder de één tot anderhalve megabyte te zitten.

Wat wij doen met afbeeldingen:

• Omzetten naar WebP of AVIF. Dit zijn moderne bestandsformaten die dezelfde foto met een fractie van de bestandsgrootte opslaan, zonder zichtbaar kwaliteitsverlies. Een JPEG van 400 kilobyte wordt in WebP typisch 120 tot 150 kilobyte, in AVIF nog kleiner. Voor oudere browsers blijft automatisch het originele formaat beschikbaar.
• De juiste afmetingen leveren. WordPress maakt van elke upload meerdere formaten. Wij zorgen dat de browser voor elk schermformaat de kleinste passende versie krijgt, zodat een telefoon nooit een afbeelding van 2.000 pixels breed hoeft te laden.
• Afmetingen vooraf opgeven. Elke afbeelding krijgt breedte en hoogte mee in de code, zodat de browser de ruimte reserveert en de pagina niet verspringt. Dit is de belangrijkste maatregel tegen een slechte CLS.
• Lazy loading, met verstand. Afbeeldingen die onder de vouw staan, laden pas als de bezoeker ernaartoe scrolt. Maar de grote afbeelding bovenaan moet juist meteen laden, met voorrang. Veel websites hebben lazy loading op alles staan, ook op die eerste foto, wat de LCP verslechtert. Wij stellen het per positie in.
• Een CDN waar dat zin heeft. Een content delivery network bewaart kopieën van uw afbeeldingen op servers dicht bij de bezoeker. Voor een Nederlandse website met Nederlandse bezoekers op Nederlandse hosting is de winst beperkt; voor websites met veel beeld of bezoekers uit meerdere landen is het merkbaar. Wij adviseren per geval, in plaats van standaard een extra dienst te verkopen.
• Bestaande bibliotheek opschonen. Ook de duizenden afbeeldingen die al in uw mediabibliotheek staan, worden omgezet en verkleind. Dat scheelt vaak gigabytes aan opslag, wat ook back-ups sneller en kleiner maakt.

Een praktische afspraak voor daarna: upload nieuwe afbeeldingen nooit groter dan nodig, en laat de website de omzetting naar WebP automatisch doen. Wij richten dat zo in dat u er verder niet over hoeft na te denken. Wat u zelf kunt controleren: open een pagina op uw telefoon, druk lang op een afbeelding en bekijk de afmetingen. Is die veel groter dan het vak waarin hij staat, dan is er winst te halen.

WordPress bouwt elke pagina op het moment dat iemand hem opvraagt: het voert code uit, haalt gegevens uit de database, voegt het thema toe en stuurt het resultaat naar de browser. Voor een pagina die maar eens per maand verandert, is dat verspilling. Caching betekent dat het resultaat wordt bewaard en bij het volgende bezoek meteen wordt geserveerd, zonder al dat werk. Er zijn vier lagen, en een goed ingerichte website gebruikt ze allemaal.

1. Paginacache. De volledig opgebouwde pagina wordt als kant-en-klaar bestand bewaard. De eerste bezoeker wacht op de opbouw, alle volgende bezoekers krijgen het bestand in enkele tientallen milliseconden. Dit is de laag met verreweg het grootste effect. Belangrijk is wat er gebeurt als u iets wijzigt: de cache moet dan automatisch worden ververst, anders zien bezoekers de oude versie.
2. Browsercache. Bestanden die niet veranderen, zoals uw logo, de stijlbestanden en lettertypen, mogen door de browser van de bezoeker lokaal worden bewaard. Bij een tweede pagina of een volgend bezoek hoeven ze niet opnieuw te worden opgehaald. Dit vraagt om de juiste instellingen op de server, die bij veel websites ontbreken.
3. Objectcache. Ook pagina's die niet volledig gecacht kunnen worden, zoals de winkelwagen of het beheer, doen veel dezelfde databasevragen. Een objectcache zoals Redis of Memcached houdt de antwoorden op die vragen in het werkgeheugen. Voor webshops, ledensites en drukke websites is dit de laag die het verschil maakt voor ingelogde bezoekers.
4. Servercache. Sommige hostingomgevingen bieden caching op serverniveau, vóór WordPress: LiteSpeed Cache op LiteSpeed-servers, FastCGI-cache op NGINX, of Varnish als aparte laag. Die is sneller dan een cachingplugin, omdat het verzoek WordPress helemaal niet bereikt. Welke variant beschikbaar is, hangt van uw hostingpartij af; wij stemmen de configuratie daarop af.

Waar het vaak misgaat, is de combinatie. Twee cachingplugins naast elkaar, een servercache die niet weet dat de plugin ook cachet, of een cache die bij wijzigingen niet wordt geleegd; het resultaat is een website die soms snel is, soms traag, en soms een verouderde pagina toont. Ook zien wij geregeld dat de cache is ingeschakeld, maar dat uitzonderingen ontbreken: de checkout of een formulier wordt dan gecacht, waardoor bezoekers gegevens van iemand anders te zien krijgen of een formulier niet werkt.

Bij een optimalisatie kiezen wij daarom één samenhangende opzet die past bij uw hosting, stellen de uitzonderingen zorgvuldig in en testen daarna alle dynamische onderdelen: formulieren, zoekfunctie, inloggen, winkelwagen. Caching moet onzichtbaar zijn voor de bezoeker; het enige wat opvalt, is dat de website ineens snel is.

Elke plugin die u installeert, laadt vaak eigen stijlbestanden en scripts mee, en meestal op elke pagina, ook waar de plugin niets doet. Een plugin voor een contactformulier laadt zijn scripts op de homepage; een plugin voor een fotogalerij laadt op de contactpagina. Na een paar jaar telt een gemiddelde WordPress-website dertig tot vijftig plugins en laadt elke pagina tientallen bestanden die de browser moet ophalen, lezen en uitvoeren. Dat is de belangrijkste oorzaak van een slechte INP: de telefoon van de bezoeker is bezig met scripts terwijl die op een knop wil tikken.

Onze aanpak begint met een inventarisatie. Van elke plugin bekijken wij:

• Wordt hij nog gebruikt, of is hij een overblijfsel van een vorige webbouwer of een oud experiment?
• Doet hij iets wat een andere plugin ook al doet, zoals twee plugins voor SEO of twee voor beveiliging?
• Hoeveel laadt hij, en op welke pagina's?
• Wordt hij nog onderhouden door de maker, en is er een lichter alternatief?

Daarna volgen drie stappen. Overbodige plugins verwijderen wij, na een back-up en in overleg met u. Van plugins die blijven, beperken wij het laden tot de pagina's waar ze nodig zijn; een formulierplugin laadt dan alleen op pagina's met een formulier. En scripts die pas later nodig zijn, laten wij uitgesteld laden, zodat de zichtbare inhoud eerst op het scherm staat en de browser daarna pas aan de rest begint.

Aparte aandacht gaat naar scripts van derden: statistieken, advertentiepixels, chatwidgets, video-insluitingen, socialemediaknoppen en reviewwidgets. Die komen van externe servers, u hebt er geen invloed op, en ze zijn vaak zwaarder dan alles wat op uw eigen website staat. Een chatwidget alleen kan een halve megabyte JavaScript laden voordat de bezoeker iets ziet. Wij bekijken per script of het nodig is, of het uitgesteld kan laden, en of een lichter alternatief bestaat. Een YouTube-video laden wij bijvoorbeeld pas als de bezoeker op de afspeelknop klikt; tot die tijd staat er alleen een lichte voorbeeldafbeelding.

Ook het thema zelf verdient een kritische blik. Sommige populaire thema's en paginabouwers laden honderden kilobytes aan stijlen en scripts voor functies die u niet gebruikt. Een thema vervangen valt buiten een snelheidsoptimalisatie, want dat is bouwen, maar wij kunnen wel ongebruikte onderdelen uitschakelen en de uitvoer inperken. Dat scheelt vaak meer dan verwacht.

Wat u zelf kunt controleren: tel het aantal actieve plugins in uw beheer. Meer dan dertig is een signaal om te laten kijken. Meer dan vijftig is bijna altijd een probleem.

Twee onderdelen die bij snelheid vaak worden vergeten, maar die samen een merkbaar verschil maken: de lettertypen en de database. Beide zijn onzichtbaar voor de bezoeker, en juist daarom blijven ze jaren onaangeroerd.

Lettertypen. De meeste WordPress-thema's laden hun lettertypen van Google Fonts. Dat betekent dat de browser voor elke pagina eerst een verbinding met een server van Google moet opzetten, een lijst ophalen, en daarna de lettertypebestanden zelf. Tot die binnen zijn, is de tekst onzichtbaar of verspringt hij zodra het lettertype inlaadt, wat de CLS verslechtert. Bovendien is het laden van Google Fonts in de EU juridisch aangevochten, omdat het IP-adres van de bezoeker naar Google gaat.

De oplossing is eenvoudig: wij zetten de lettertypen op uw eigen server, in een modern formaat (WOFF2), beperken de set tot de diktes die het thema echt gebruikt (meestal twee of drie in plaats van acht) en stellen in dat de tekst tijdens het laden alvast in een tijdelijk lettertype wordt getoond. Resultaat: minder verzoeken, geen externe afhankelijkheid, geen verspringende tekst en één privacyzorg minder.

Database. De database van WordPress groeit met alles wat u doet, en ruimt zichzelf nauwelijks op. Wat wij daar tegenkomen:

• Honderden revisies per pagina, elke tussentijdse versie die ooit is opgeslagen.
• Tijdelijke gegevens (transients) van plugins die allang zijn verwijderd.
• Spamreacties en prullenbakitems van jaren terug.
• Instellingen en tabellen van plugins die niet meer bestaan.
• Logboeken van beveiligings-, statistiek- of formulierplugins die miljoenen regels bevatten.
• Autoload-opties: instellingen die bij elke pagina worden geladen, ook als ze niet nodig zijn. Een autoload van meerdere megabytes vertraagt elk verzoek.

Bij een optimalisatie schonen wij dit op, na een back-up, en optimaliseren wij de tabellen. Op een website die een aantal jaar draait, krimpt de database daarbij regelmatig met de helft of meer, en reageert het beheer merkbaar vlotter. Daarna stellen wij een grens in op het aantal revisies en een automatische opschoning van transients en logboeken, zodat het probleem niet terugkomt.

Voor webshops en websites met veel inhoud kijken wij daarnaast naar de indexen van de database: de 'inhoudsopgave' die bepaalt hoe snel een zoekopdracht in de database wordt beantwoord. Een ontbrekende index op een grote tabel kan het verschil zijn tussen een categoriepagina van drie seconden en een van een halve seconde.

Alle optimalisaties aan de website zelf hebben een grens, en die grens wordt bepaald door de server waarop hij draait. Wij komen regelmatig websites tegen die aan de kant van WordPress keurig zijn ingericht, maar die toch traag zijn omdat de server er anderhalve seconde over doet om überhaupt te reageren. Die reactietijd, in meetrapporten 'Time to First Byte' genoemd, hoort onder de 200 tot 300 milliseconden te liggen. Zit hij daar structureel boven, dan zit het probleem in de hosting.

De meest voorkomende oorzaken:

• Verouderde PHP-versie. PHP is de taal waarin WordPress is geschreven. Elke nieuwe versie is sneller dan de vorige; het verschil tussen PHP 7.4 en PHP 8.3 is bij WordPress al snel twintig tot dertig procent. Toch draaien veel websites nog op een oude versie, omdat niemand het heeft omgezet uit angst dat er iets breekt. Wij testen de overstap eerst op staging en voeren hem daarna uit.
• Goedkope gedeelde hosting. Bij een pakket van enkele euro's per maand deelt u een server met honderden andere websites. Is één daarvan druk of gehackt, dan merkt u dat. Voor een bedrijfswebsite met omzetbelang is een pakket met gegarandeerde capaciteit vrijwel altijd de moeite waard.
• Te weinig geheugen. WordPress met een paar zware plugins heeft geheugen nodig. Zit de limiet te laag, dan wordt de website traag of geeft hij sporadisch foutmeldingen.
• Serverlocatie. Een server in de Verenigde Staten voegt voor Nederlandse bezoekers bij elk verzoek meetbare vertraging toe. Voor een Nederlands publiek hoort de server in Nederland of in elk geval in West-Europa te staan.
• Ontbrekende servercaching en oude webserversoftware. Moderne omgevingen met LiteSpeed of NGINX, HTTP/2 of HTTP/3 en objectcache zijn merkbaar sneller dan een klassieke Apache-installatie zonder aanvullende lagen.

Wij verkopen zelf geen hosting en verdienen niets aan uw keuze; dat maakt ons advies onafhankelijk. Blijkt de hosting de bottleneck, dan bespreken wij dat eerlijk met u, adviseren wij een passend pakket bij uw huidige of een andere hostingpartij, en verzorgen wij desgewenst de verhuizing voor een vast bedrag. Vaak is een verhuizing binnen de eigen hostingpartij naar een beter pakket al voldoende.

Wat u zelf kunt controleren: in uw hostingpaneel staat meestal welke PHP-versie actief is. Staat daar een versie die begint met 7, dan is er winst te halen. En vraag uw hostingpartij eens waar de server fysiek staat; het antwoord verrast soms.

Voor een informatieve website is snelheid na een goede optimalisatie grotendeels een kwestie van caching: de pagina staat klaar, de bezoeker krijgt hem meteen. Bij een webshop, een ledenomgeving, een cursusplatform of een intranet werkt dat maar gedeeltelijk. Zodra een bezoeker inlogt of iets in een winkelwagen legt, wordt elke pagina persoonlijk, en een persoonlijke pagina kan niet uit een algemene cache komen. Juist die bezoekers zijn het meest waardevol, en juist voor hen is de website vaak het traagst.

Voor deze situaties verschuift de aandacht van caching naar de efficiëntie van wat er zonder cache gebeurt:

• Objectcache als basis. Redis of Memcached houdt de antwoorden op terugkerende databasevragen in het geheugen. Voor ingelogde gebruikers is dit de maatregel met het grootste effect, omdat het aantal databasevragen per pagina vaak van enkele honderden naar enkele tientallen daalt.
• Gedeeltelijke caching. De pagina zelf wordt gecacht, en alleen de persoonlijke onderdelen, zoals de naam van de gebruiker of het aantal artikelen in de winkelwagen, worden apart en licht ingeladen. Dit vergt zorgvuldig instellen, maar geeft ingelogde bezoekers bijna dezelfde snelheid als anonieme.
• Trage databasevragen opsporen. Met een profileringstool zien wij per pagina welke vraag aan de database de meeste tijd kost. Vaak is het één plugin of één filter die een onnodig zware vraag stelt. Die aanpassen of vervangen scheelt seconden.
• Achtergrondtaken verplaatsen. WordPress voert geplande taken uit tijdens bezoeken van gewone bezoekers, die daar de vertraging van merken. Wij verplaatsen die naar een echte servertaak die op vaste tijden draait.
• Beheer en bestelverwerking. Ook de snelheid van het beheer telt. Een productpagina die in het beheer tien seconden nodig heeft om te openen, kost uw medewerkers elke dag tijd. Dezelfde maatregelen helpen daar.

Bij WooCommerce komt daar nog de winkelwagen bij, die op elke pagina wordt ververst met een extra verzoek naar de server. Op drukke shops zorgt dat verzoek voor een groot deel van de serverbelasting; het is mogelijk dat verzoek te beperken tot de pagina's waar het echt nodig is. Ook checkoutpagina's zijn vaak zwaarder dan nodig, omdat er scripts laden van plugins die op die pagina niets doen. Voor de doorlopende zorg voor webshops hebben wij aparte WooCommerce-onderhoudsdiensten; de snelheidsoptimalisatie legt daarvoor de basis.

Wat u zelf kunt controleren: log in op uw website of leg een product in de winkelwagen en klik dan door een paar pagina's. Voelt dat merkbaar trager dan als anonieme bezoeker, dan is dit het onderdeel waar de winst zit.

Snelheidsoptimalisatie is een onderwerp waarover veel goedbedoelde adviezen circuleren, en waarbij de website met enkele klikken flink kapot kan gaan. Wij worden regelmatig ingeschakeld om de gevolgen te herstellen van een optimalisatie die te enthousiast is aangepakt. Een overzicht van wat wij afraden:

• Meerdere optimalisatieplugins tegelijk. Een cachingplugin, een aparte plugin voor afbeeldingen, nog één voor scripts, één voor de database en één 'alles-in-één': ze werken elkaar tegen, cachen elkaars uitvoer en maken fouten moeilijk te vinden. Eén goede plugin, correct ingesteld, of caching op serverniveau, is beter dan vijf half werkende.
• Alles minificeren en samenvoegen zonder te testen. De knop 'CSS en JavaScript samenvoegen en minificeren' klinkt onschuldig. In de praktijk breekt hij geregeld sliders, formulieren, menu's op mobiel en de checkout, en dan alleen in bepaalde browsers, zodat u het zelf niet ziet. Sinds HTTP/2 levert samenvoegen bovendien veel minder winst op dan vroeger. Wij passen dit alleen toe na een test van elk onderdeel, en vaak niet.
• Scripts uitstellen die niet uitgesteld mogen worden. Het uitstellen van JavaScript is een krachtige maatregel, maar sommige scripts moeten juist eerst laden, zoals het script dat een cookiemelding aanstuurt of een betaalformulier opbouwt. Zonder uitzonderingen werkt de pagina niet meer goed.
• Afbeeldingen agressief comprimeren. Een 'compressie 40 procent' oogt in het plugin-menu als een mooie besparing en op uw productfoto's als een korrelige puinhoop. WebP met een verstandige kwaliteitsinstelling levert dezelfde besparing zonder zichtbaar verlies.
• Een CDN als wondermiddel. Een CDN helpt bij het uitleveren van bestanden, maar lost een trage server of een slecht thema niet op. Wie een CDN inschakelt bovenop een verkeerd ingestelde cache, krijgt soms een website die verouderde pagina's blijft tonen.
• Optimaliseren op de score. Een score van 100 in PageSpeed is haalbaar door alles wat de bezoeker nodig heeft uit te stellen of uit te schakelen. De score is groen, de website onbruikbaar. Het doel is een snelle ervaring voor echte bezoekers, en de score is hooguit een hulpmiddel.
• Zonder back-up beginnen. Elke optimalisatie raakt de kern van de website. Zonder back-up vooraf is een fout niet terug te draaien; met back-up is hij binnen een kwartier hersteld.

Een laatste misverstand: dat snelheid een kwestie is van één keer 'aanzetten'. Elke nieuwe plugin, elk nieuw thema-onderdeel en elke update kan de winst weer tenietdoen. Vandaar dat wij snelheid ook in het doorlopende onderhoud meenemen; daarover meer in de laatste sectie.

Een installatiebedrijf met een website van ongeveer zestig pagina's en een offerteformulier als belangrijkste doel kwam bij ons met de klacht dat de website 'op de telefoon niet vooruit te branden was'. De website was vier jaar oud, gebouwd met een populaire paginabouwer en in de loop der tijd uitgebreid met 47 plugins. De nulmeting op de dienstenpagina, gemeten op mobiel:

• Paginagrootte: 8,4 megabyte, waarvan 6,9 megabyte aan afbeeldingen.
• Aantal verzoeken: 142.
• Reactietijd server: 1,1 seconde (PHP 7.4, gedeelde hosting zonder servercache).
• LCP: 6,8 seconden. INP: 410 milliseconden. CLS: 0,34.
• PageSpeed-score mobiel: 23.
• Core Web Vitals in Search Console: alle pagina's in de categorie 'slecht'.

Wat er is gedaan, in volgorde: back-up en staging-kopie; PHP naar 8.3 na test; overstap binnen dezelfde hostingpartij naar een pakket met LiteSpeed-servercache en objectcache; 19 plugins verwijderd (dubbele functies, ongebruikte uitbreidingen, twee overbodige optimalisatieplugins die elkaar tegenwerkten); alle afbeeldingen omgezet naar WebP en op maat gemaakt, met voorrang voor de bovenste afbeelding en lazy loading voor de rest; lettertypen lokaal, teruggebracht van zeven naar drie diktes; database opgeschoond van 1,9 gigabyte naar 310 megabyte, vooral logboeken van een oude beveiligingsplugin; scripts van derden beperkt en uitgesteld; ongebruikte onderdelen van de paginabouwer uitgeschakeld. Doorlooptijd: vijf werkdagen, waarvan de meeste tijd in het testen van formulieren en paginabouwer-elementen zat.

De meting na afloop, op dezelfde pagina, dezelfde manier:

• Paginagrootte: 1,1 megabyte.
• Aantal verzoeken: 38.
• Reactietijd server: 180 milliseconden.
• LCP: 1,6 seconden. INP: 120 milliseconden. CLS: 0,02.
• PageSpeed-score mobiel: 91.

Zes weken later bevestigde Search Console het beeld: alle pagina's in de categorie 'goed'. Belangrijker voor de klant: het aantal ingevulde offerteformulieren via mobiel lag in de twee maanden na de optimalisatie ruim een derde hoger dan in de twee maanden ervoor, bij een vergelijkbaar aantal bezoekers. Wij zijn voorzichtig met zulke cijfers, want er spelen altijd meer factoren mee, maar de richting was onmiskenbaar.

Dit voorbeeld is bewust niet uitzonderlijk gekozen. Een score van 23 naar 91 is bij een website met deze uitgangssituatie eerder regel dan uitzondering. Wat wel verschilt, is waar de winst zit: bij de ene website in de afbeeldingen, bij de andere in de hosting, bij een derde in de plugins. Daarom begint elke optimalisatie met een meting en niet met een standaardlijstje.

Een snelheidsoptimalisatie levert een website op die op dat moment snel is. Of hij dat over een jaar nog is, hangt af van wat er in de tussentijd gebeurt. En er gebeurt altijd iets: een collega installeert een plugin voor een actie, het thema krijgt een update die nieuwe scripts meebrengt, de mediabibliotheek groeit met foto's rechtstreeks van de telefoon, de database vult zich weer met revisies en logboeken, en de hostingpartij wijzigt iets aan de server. Elk van die dingen is klein; samen brengen ze de website in twaalf maanden terug naar waar hij begon.

Daarom is snelheid bij ons een vast onderdeel van het onderhoud, en niet alleen een eenmalige dienst. Wat dat in de praktijk inhoudt:

• Maandelijkse meting. Van de belangrijkste pagina's leggen wij elke maand de laadtijd en de Core Web Vitals vast. Loopt een waarde terug, dan zoeken wij de oorzaak voordat bezoekers het merken. U ziet het verloop in het maandrapport.
• Controle bij updates. Na elke update-ronde meten wij opnieuw. Een thema- of pluginupdate die de website merkbaar zwaarder maakt, valt dan direct op, en wij bekijken of de update anders kan worden ingesteld of moet worden teruggedraaid.
• Nieuwe afbeeldingen automatisch op maat. De omzetting naar WebP en het verkleinen van uploads blijven op de achtergrond draaien, zodat een nieuw geplaatste foto nooit meer een pagina van tien megabyte oplevert.
• Periodieke opschoning. Database, revisies, transients en logboeken worden automatisch en periodiek opgeruimd.
• Toezicht op nieuwe plugins. Wilt u een plugin toevoegen, dan bekijken wij vooraf wat die laadt en of er een lichter alternatief is. Dat is geen betutteling, maar het voorkomt dat één toevoeging de winst van de hele optimalisatie tenietdoet.
• Hosting bijhouden. Nieuwe PHP-versies en serververbeteringen voeren wij door zodra ze stabiel zijn, na een test op staging.

Hoe dat bij ons is ingedeeld: de eenmalige snelheidsoptimalisatie is beschikbaar vanaf € 199 en staat los van een abonnement. In het Zakelijk-abonnement van € 149 per maand en het Groei-abonnement van € 249 per maand is snelheidsoptimalisatie doorlopend inbegrepen, naast updates, back-ups, beveiliging en een vast aantal uren voor aanpassingen. Alle abonnementen zijn maandelijks opzegbaar, zonder opstartkosten, en de eerste maand geldt een niet-goed-geld-terug-garantie. Op de pagina met alle tarieven op een rij vindt u de volledige vergelijking.

Wilt u eerst weten hoe uw website er nu voor staat, vraag dan een gratis snelheidsmeting aan. U ontvangt binnen enkele werkdagen een verslag in gewoon Nederlands: de huidige cijfers, de belangrijkste oorzaken en wat een optimalisatie naar verwachting oplevert. Daarmee kunt u een onderbouwde beslissing nemen, ook als u het werk uiteindelijk door iemand anders laat uitvoeren.