Mijn site moest sneller op mobiel!

Mijn website was mobielvriendelijk. Maar nog niet snel genoeg

Performance met WordPress is een raar ding. En mobiele performance is helemaal een probleem. Wanneer je een vrij grote en complexe website als de mijne hebt, dan is het een constante strijd om de performance goed te houden. En daar is op zich niets mis mee. Het is in ieder geval een goede oefening, die ik dan weer in praktijk kan brengen bij mijn klanten. Maar toch…

De laatste twee jaar viel de mobiele performance van mijn eigen site ineens een heel stuk terug. En dat terwijl er vrijwel niets aan veranderd was. Nou ja, er kwamen natuurlijk iedere keer nieuwe blogposts bij, maar dat kon de oorzaak niet zijn. Wat mij vooral bevreemde was dat de performance voor de desktop site goed was, en goed bleef. Wat kan dan de oorzaak zijn van de plotselinge terugval in performance? Maar hoe dan ook, mijn site moest sneller op mobiel!

Een mobiele website is meer dan ‘slimme vormgeving’

Ooit in een grijs verleden, toen het bier nog in cadmium-gele kratjes kwam, konden we het ons niet voorstellen, dat we een website op een telefoon zouden kunnen bekijken. Maar een aantal slimme mensen bedachten een nieuwe manier om de layout van een HTML pagina te bepalen en hoera de ‘responsive website’ was geboren.

Het maken van een website die ook mobiel geschikt was, was dan wel iets meer dan het aanleren van een paar extra kunstjes, maar wanneer je vanaf het begin ook ‘mobiel’ denkt, is het tegenwoordig niet moeilijk meer om een website te bouwen die op alle mobiele formaten goed werkt.

Goed werken op mobiele formaten is echter niet hetzelfde als goed werken op mobiele apparaten. Een website die 100% responsive is op alle denkbare apparaten is nog niet per se ook ‘mobiel geschikt’.

Want dat kleine slimme apparaatje wat je bijna altijd bij je hebt mag dan meer rekenkracht en opslagvermogen hebben dan mijn eerste ‘personal computer’ (een Tulip Compact II, mocht het je interesseren. 640kb geheugen en een gigantische harddisk van 20 MB), in vergelijking met jouw huidige desk- of laptop stelt je telefoon weinig voor.

Je hebt namelijk te maken met

• (veel) minder geheugen
• een 4G/5G verbinding die constant van kwaliteit wisselt
• een hoge latency (‘vertraging’)
• minder rekenkracht (zwakkere processor, geen ‘hulpprocessoren’)
• minder (tijdelijke) opslag voor de cache, waardoor al snel de cache geleegd moet worden om nieuwe bestanden op te halen.
• en al die beperkte resources worden gedeeld door meerdere apps

Een website kan er op een mobiele telefoon prachtig uitzien en toch tergend langzaam zijn in het gebruik.

Mobiel ontwerpen is ontwerpen voor beperkingen!

Een mobiele webpagina is opgebouwd uit een groot aantal verschillende resources. Iedere afbeelding, ieder JavaScript bestand en iedere verbinding met een externe server moet hetzelfde proces doorlopen:

Downloaden → Verwerken → Uitvoeren → Weergeven

Op de moderne desktop met glasvezel merk je hier meestal nauwelijks iets van. Omdat ook meerdere taken makkelijk naast elkaar uitgevoerd kunnen worden, is alles in een vloek en een zucht gedownload.

Op een mobiele telefoon verbonden met een mobiel netwerk stapelen al deze activiteiten op en worden er veel na elkaar in plaats van naast elkaar uitgevoerd.

En het eindresultaat wat uiteindelijk getoond moet worden -de webpagina- kan pas getoond worden als al die kleine beetjes binnen zijn.

Eerst moet sowieso de HTML pagina geladen worden. Want in die HTML pagina staan in de ‘header’ (het deel wat je niet kan zien) of in de ‘body’ (het deel waar gedefinieerd wordt wat je wel kan zien) allerlei bestanden die mede gedownload moeten worden om de pagina op te kunnen bouwen. En om het allemaal vooral niet te eenvoudig te maken, in sommige van die bestanden kunnen weer instructies staan om andere bestanden te laden.

En dat het liefst zo snel mogelijk.

Vraag het Claude

Ik besloot onlangs te onderzoeken waar mogelijke knelpunten en oplossingen lagen en ging met Claude Code aan de slag om de fouten te vinden. Op zich een enigszins riskant project, omdat voor het oplossen van performance problemen je meestal het best terecht kunt op een live server.

Gelukkig is het mogelijk om Claude per actie toestemming te geven. Dus niet één prompt als:

Doe alles wat mogelijk is om mijn website sneller te maken.

Als je dit in Claude Code als opdracht in zou tikken loop je een zeker risico dat Claude beslist dat het CMS WordPress de grootste vertragende factor is, en daarom de site naar ‘platte HTML’ converteert. Claude heeft dan precies uitgevoerd wat je vroeg. Er is geen manier om de website nog sneller te maken.

Hoe ga je wel te werk?

Eerst de vertragende factoren onderzoeken

Wat je niet wilt is dat Claude zonder plan te werk gaat. Om een aantal redenen, maar de belangrijkste reden is wel, dat Claude -en iedere AI-agent- als een kip zonder kop aan de slag gaat, wanneer je het niet als een plan oppakt. En de grote boosdoener is hierbij het ‘context window’, de hoeveelheid geheugen die gebruikt wordt om een taak of een project uit te voeren. Wanneer ik een prompt zoals de prompt hierboven in zou geven, zou Claude Code letterlijk alles wat redelijk is (natuurlijk heef je parameters aan waarbinnen dit gedaan mag worden) uitproberen om je site sneller te maken. Want dat is hoe een AI-agent werkt en leert. Probeer iets, lukt het niet, probeer iets anders… totdat het lukt… dat is toch wel heel menselijk. Wanneer je niet inperkt wat en in welke volgorde het moet gebeuren, ‘vergeet’ Claude wat hij al gedaan heeft en zal waarschijnlijk eeuwig (nou ja, tot de creditsaldo op is) blijven proberen je website te versnellen.

Wat je dus doet is allereerst Claude te vertellen, dat er een aantal ‘nulmetingen’ moeten worden gedaan. Je moet vastleggen of de verandering ook daadwerkelijk een verbetering is.

Daarnaast zal je Claude toegang moeten geven tot bepaalde onderdelen van je site en mogelijk ook van je server. Toegang tot de Elementor MCP -wanneer je een Elementor website hebt- kan bovendien goed zijn om Claude te laten zoeken aan pagina’s die nog volgens ‘oude’ layout systemen zijn gemaakt. Door de loop der jaren is Elementor enorm verbeterd, maar een pagina die 9 jaar geleden is opgeslagen is opgeslagen met de HTML structuur van die tijd. Alleen het opnieuw opslaan van je pagina kan soms al een versnelling betekenen. Liever nog het ombouwen tot een meer eigentijdse structuur. Ook een goed moment om weer eens naar de layout te kijken ook.

Claud kan ook toegang nodig hebben tot bepaalde meet-tools die lokaal kunnen worden geregistreerd. Eén van deze meetinstrumenten die Claud voor mij op mijn desktop heeft geregistreerd om inzicht te krijgen in de performance van mijn site is de Lighthouse CLI van Google. Hiermee werden na iedere aanpassing de metrics volgens Google opnieuw gemeten.

Om je een indruk te geven van de meetstappen:

• Lighthouse tests uitvoeren
• Network Tab bekijken om ‘lastige externe verbindingen’ te inventariseren
• Bepalen welke bestanden geladen worden en waar vandaan
• Scripts en stylesheets aan specifieke plugins en/of pagina’s verbinden
• AJAX-verkeer bekijken
• Render-blocks (activiteiten die veel tijd kosten en het doorgaan met het ‘renderen’ (’tekenen’) van de pagina vertragen

Lighthouse en de Google-metrics

Meten is weten. Wanneer je twee mogelijke oplossingen naast elkaar zet en je wilt weten welke oplossing het snelst is, dan is niets zo goed als het daadwerkelijk te meten. Alleen hoe doe je dat? Er is een te groot aantal variabele factoren die de snelheid van het laden van je pagina bepalen.

Google heeft in het loop der jaren daarom de ‘Google Site Metrics’ ontwikkeld. Een aantal meetpunten om te bepalen hoe snel jouw site zich op lijkt te bouwen.

Op lijkt te bouwen? Op het moment dat je op een website bent, maakt het je weinig uit, dat de pagina zich nog opbouwt, wanneer je toch het begin van de pagina al kan lezen. Maar wanneer bovenin die pagina een formulier staat wat je in wilt vullen, maar je pas kunt beginnen wanneer je pagina helemaal is opgebouwd, dan is het feit dat die pagina nog bezig is te laden ineens wel een probleem. De ‘Google Site Metrics’ zijn te meten waarden die tot doel hebben de gebruikerservaring te verbeteren.

Bovendien, wanneer je een mobiele pagina hebt simuleert Lighthouse de ‘ervaring’ die je hebt wanneer je de site op een mobiele telefoon zou bekijken. En hierbij gaan ze uit van een ‘midprice’ telefoon die via een 4G netwerk verbinding zoekt. Of met andere woorden, ze meten hoe de meerderheid van de mobiele gebruikers de site zouden ervaren.

De Google-metrics zijn ook vooral heel praktische parameters. Het kan niemand -behalve degene die de daadwerkelijke tuning moet uitvoeren- een worst schelen hoe lang bepaalde bestanden moeten laden. Het gaat om de gebruikerservaring. En daarom zijn alle ‘meetpunten’ gebaseerd op hoe jouw bezoekers de website ervaren. De drie belangrijkste parameters zijn:

• LCP – Largest Contentful Paint: Hoe lang duurt het voor het belangrijkste zichtbare deel van de pagina verschijnt? Begint je pagina met een video, maar blijft dit een leeg vak voordat allerlei dingen buiten beeld geladen zijn, dan zal dit een ‘hoog getal’ worden. En bij de metrics is ‘hoog’ slecht.
• INP – Interaction to Next Paint: Hoe snel reageert de pagina wanneer je iets doet? Wanneer er een formulier op de pagina staat, maar je pas drie seconden nadat je het formulier ziet kan beginnen met invullen, is dit niet echt een positieve ervaring voor de bezoeker.
• CLS – Cumulative Layout Shift: Hoeveel elementen ‘verspringen’ er onverwacht? Je kent het misschien wel vanuit websites met een overvloed aan affiliate advertenties. Bent bezig een artikel te lezen, je ziet een link, wilt er op klikken, maar plotseling is er een advertentie ingevoegd, en klik je onbedoeld op de advertentie. Opnieuw hoe hoger de CLS, des te slechter wordt het door Google -en in eerste plaats de gebruikers natuurlijk- beoordeeld.

Er is nog een aantal andere belangrijke metrics, maar deze drie halen -bij een slechte (lees hoge) score- de gebruikerservaring wel heel sterk omlaag.

Lighthouse kent twee soorten metingen: Veld metingen en Lab metingen. Veld metingen is een gemiddelde van de resultaten gemeten door mensen met een Chrome browser die je site bezoeken. Een soort ‘praktijkmeting’ dus. Een Lab meting is een meting die gedaan wordt bij het specifiek laden van een pagina via PageSpeed. Zo’n labmeting kan je helpen om te bepalen of je maatregelen ook zoden aan de dijk hebben gezet, maar het werkelijke resultaat, de veldmeting, zie je pas een maand later terug.

Veldmetingen voor de desktop zijn voor de WP Digital Marketing (voorheen WordXPression) site de laatste jaren geen probleem geweest. Het gemiddelde van de veldmetingen lag meestal rond de 92. De veldmeting voor mobiel lag gemiddeld voor de hele site rond de 58, met als absolute dieptepunt toch wel een pagina met een meting van 49.

Toen ik met de labmetingen begon, dus de nulmetingen vastleggen als ijkpunt voor de verschillende pogingen de site te versnellen, mat ik 96 voor de desktop en 60 voor mobiel.

Aan het einde van de optimalisatie waren de labmetingen 98 voor de desktop en 85 voor mobiel. Er is nog enige snelheidswinst te behalen op mobiel, maar daarvoor moeten wat grotere aanpassingen aan de site komen.

Waar begon ik tijd te verliezen?

Wanneer je merkt, dat je site langzamer wordt, of voor één device razend snel is, en voor een ander device niet vooruit te branden, dan is het geen oplossing om meer plugins te installeren. Eerst moet je kijken naar de oorzaken van de vertraging. En hier heb je verschillende boosdoeners. En de meeste boosdoeners zijn vooral onvriendelijk voor mobiele apparaten.

Afbeeldingen

Eén van de zaken waar het makkelijk fout mee gaat wanneer we het over performance hebben is met afbeeldingen. Over het algemeen zijn afbeeldingen één van de grootste oorzaken van performance problemen. Want we willen natuurlijk allemaal haarscherpe afbeeldingen in levendige kleuren. Maar dat soort afbeeldingen zijn meestal vrij groot. Nu zijn er inmiddels allerlei mogelijkheden om je afbeeldingen te optimaliseren, van optimalisatiediensten tot simpele conversies, maar dan kunnen er nog steeds zaken mis gaan.

Zelf gebruik ik graag WebP Express. Een aantal jaar geleden was deze plugin nog een nachtmerrie om te configureren (maar wel de moeite waard), inmiddels beschikt de plugin over een goede uitleg bij vrijwel iedere in te stellen parameter. En over allerlei tests of het allemaal wel goed werkt.

Het is mijn ‘goto’ oplossing voor afbeeldingscompressie, vooral omdat je geen abonnement nodig hebt, en de plugin zelf helemaal gratis is. Nou ja, de maker vraagt je om af en toe een kop koffie voor hem te kopen.

En het mooie van deze plugin is dat hij zelf de herschrijfregels (vraagt de browser om een JPG/PNG geef dan een WebP in plaats daarvan) voor Apache verwerkt. En Apache is de meest gebruikte webserver, vooral in de shared hosting wereld. Voor NGINX -omdat die wat beter beveiligd is- moet je zelf de herschrijfregels (laten) aanpassen in de configuratie bestanden.

En sinds ik deze plugin gebruik heb ik eigenlijk helemaal geen performance problemen meer met afbeeldingen. Nou ja, tot ik dus mijn website migreerde naar een NGINX in eigen beheer. Wat bleek? WordPress houdt afbeeldingen in allerlei dimensies bij. Een thumbnail, een kleine versie, een iets grotere versie, een versie van 1000px breed en een ‘origineel formaat’. Heb je bepaalde plugins of thema’s geïnstalleerd is het mogelijk dat hier nog extra formaten bijkomen.

Al die afbeeldingen worden netjes als WebP opgeslagen -lekker klein en inmiddels geaccepteerd in iedere moderne browser- en in de juiste dimensies aan de juiste devices gepresenteerd.

In theorie. Door een configuratiefout in de NGINX server zelf stonden er twee herschrijfregels voor de paden van PNG/JPG. En aangezien de tweede regel de eerste regel (om WebP aan te leveren) teniet deed, bleven de mensen op de mobiel de minder gecomprimeerde bestanden ontvangen. En vaak is een WebP bestand slechts 30% van zijn origineel, dus de bezoeker kreeg maar liefst 3x meer dataverkeer.

Omdat in de settings pagina’s van zowel het hostingpaneel als de WordPress website alles goed leek te staan, dacht ik dat mijn mobiele bezoekers de juiste bestanden kregen.

Hoe heeft Claude Code hierbij geholpen?

Als ik al een idee in de oplossingsrichting zou hebben, dan zou het mij nog uren gekost hebben om de verschillende configuratiebestanden door te nemen en de werkelijke fout te vinden.

Configuratiescripts voor NGINX zijn niet mijn specialiteit en normaliter huur ik liever iemand in (ook via een Strippenkaart) dan dat ik zelf in de code ga wroeten. Vooral omdat dit soort problemen zich meestal alleen op live servers voordoet, en als ik de kleinste fout zou maken in de configuratie van mijn webserver gaat het systeem down.

Maar Claude vond ook een aantal plaatsen waar de gekozen grootte van een afbeelding binnen een Elementor pagina te groot was voor de feitelijk getoonde grootte.

Heel menselijk: Je hebt een foto op een bepaalde plaats staan, bedenkt dat die wel wat kleiner mag… en je maakt het afbeeldingsvenster kleiner, maar vergeet de achterliggende foto op de achtergrond aan te passen.

Na een uitgebreide test -allemaal automatisch door Claude uitgevoerd- bleek dat de laadsnelheid zonder cache wel wat beter was geworden, maar nog ver onder de maat bleef. Maar we waren op de juiste weg. Wat konden we nog meer doen?

Externe koppelingen

Hoe meer externe koppelingen je hebt, hoe meer er geladen moet worden. En bovendien geladen via een langzamere route.

Een aardig voorbeeld was een widget wat je vroeger vrijwel op iedere website tegenkwam. De Facebook widget waar je behalve het aantal ‘subscribers’ op een Facebook groep ook een aantal profielfoto’s zag. Dat betekende wel dat wanneer Jan was ingelogd op Facebook en de site van Piet bezocht, speciaal voor Jan de foto’s van zijn vrienden werden getoond die lid waren van Piet zijn groep. Kwam Karel vervolgens op Piet’s site, dan krijg Karel weer zijn eigen vrienden te zien. Dus voor iedere bezoeker moest er een call naar Facebook worden gedaan om iemand’s vrienden op te zoeken en in een widget te laten zien.

Los van het feit dat dit nu waarschijnlijk niet eens meer zou mogen in het kader van de GDPR, wil niemand meer zo’n widget op zijn site vanwege de slechte performance.

Maar er is meer. Want ook links met analytische tools, chat programma’s, marketing mail providers en meer vertragen je website.

Fonts

Een extern font lijkt onschulding en het is natuurlijk heel handig, dat veel thema’s standaard Google Fonts gebruiken, maar wanneer je verschillende bestanden, gewichten etcetera gebruikt, dan kan het laden van fonts een extra vertraging betekenen. Vooral wanneer er meer fonts worden geladen dan er daadwerkelijk nodig zijn.

Download liever de fonts die je gebruikt naar de website en laad ze vanaf je eigen website. Dat scheelt gelijk ook een mogelijke inbreuk op privacy regels.

JavaScript

JavaScript maakt het mogelijk om interactieve mogelijkheden toe te voegen in je webbrowser. En een website op een smartphone maakt ook gewoon gebruik van een webbrowser. Maar een grote hoeveelheid JavaScript kan je website ernstig vertragen.

JavaScript neemt relatief veel plaats in in het werkgeheugen. En aangezien je smartphone in vergelijking met een desktop over zeer beperkt werkgeheugen beschikt, kan JavaScript de opbouw van je website sterk vertragen. Om de eerste beelden niet direct te blokkeren wordt JavaScript waar mogelijk pas uitgevoerd nadat de pagina geladen is. Maar dit kan gelijk ook de oorzaak zijn, dat bijvoorbeeld formulieren op een website pas traag reageren.

AJAX en achtergrond verzoeken

En zelfs wanneer een pagina helemaal geladen is, is het mogelijk dat er via AJAX, een soort ‘achtergrond protocol voor het laden van informatie’ nog steeds informatie wordt verzonden of opgevraagd. Denk hier bijvoorbeeld aan een pagina met een formulier, waar de pagina niet herladen hoeft te worden, wanneer je op ‘Verzenden’ drukt. De gegevens worden op de achtergrond via AJAX doorgegeven.

Maar dat wil ook zeggen, dat er een stukje code geladen moet worden op het moment dat de pagina geladen wordt.

De grote performance boosdoener: WordPress zelf!

Ik heb de laatste twee jaar meer dan eens geschreven hoe WordPress zelf eigenlijk een beetje een mastodont op zomervakantie is. Een toepassing die te zwaar is voor het huidige klimaat. Meer dan anderhalf jaar geleden heb ik een vrij uitgebreid artikel geschreven, waarin ik de vraag stel of WordPress zijn langste tijd heeft gehad.

Het grote probleem van WordPress is, dat bij iedere pagina die je laadt een groot deel van het ‘achtergrond systeem’ ook wordt meegeladen. Op de ‘algemene voorwaarden’ pagina van een webshop, een pagina waar totaal geen functionele eisen anders dan het tonen van een tekst nodig zijn, wordt nog steeds heel WooCommerce op de achtergrond meegeladen.

Dus inclusief alle opmaakregels voor de webshop, inclusief alle JavaScripts en inclusief alle AJAX aanroepen.

Er zijn plugins waarmee het mogelijk is om andere plugins conditioneel te laden. Dan kan je per pagina of paginagroep aangeven welke plugins er wel of niet geladen moeten worden. Maar dat is eigenlijk gigantisch veel werk om uit te zoeken en daarna ook nog eens te testen.

Bovendien worden hier ook vaak bronnen geladen die helemaal niet noodzakelijk zijn.

Om een eenvoudig voorbeeld te noemen. Ik gebruik Elementor voor mijn formulieren. En voor het tonen van die formulieren is specifiek JavaScript en CSS nodig. Inmiddels doet Elementor het anders, maar in de eerste jaren werden het JavaScript en de CSS op iedere pagina geladen. Dus niet alleen op de pagina’s waar ook daadwerkelijk een formulier op stond.

Of WooCommerce. Een aardig voorbeeld is het ‘winkelwagen’ icoon met een indicatie van het aantal producten in de winkelwagen. Helaas blijkt deze ‘aardige voorziening’ toch voor heel wat extra ballast te zorgen. Want om het aantal producten in de winkelwagen te kunnen tellen, moet de hele WooCommerce webshop op de achtergrond geladen worden. En die WooCommerce webshop is verantwoordelijk voor het laden van toch wel heel veel extra’s.

Wanneer je een webshop hebt, dan is die winkelwagen met het aantal producten in de wagen essentieel. Op een site als de mijne, waar mensen hoofdzakelijk slechts één product tegelijk kopen – een training of een strippenkaart- is zo’n winkelwagen minder noodzakelijk. Mensen klikken, kiezen en betalen. Ze ‘winkelen’ niet.

Het vervangen van de winkelwagen met een teller voor de producten werd dus vervangen door een winkelwagen icoon met een link naar de winkelwagen pagina.

Een plugin om conditioneel te laden

Na het optimaliseren van de afbeeldingen, het opschonen van oude tabellen in de database en het verwijderen van functies die er toch niet echt noodzakelijk waren, ging ik met het echte werk aan de slag. Of eigenlijk, Claude ging hier mee aan de slag. Door het maken van een site specifieke plugin.

JavaScript en CSS worden in een wachtrij om te worden geladen gezet door een specifieke aanroep, met een bepaalde prioriteitsvolgorde. En wat Claude eigenlijk deed is de CSS die op een pagina niet nodig was direct na het plaatsen in de wachtrij, hier weer uit weg te halen. Werd een script bijvoorbeeld met prioriteit 40 in de wachtrij gezet, werd direct daarna het script met prioriteit 41 weer uit de wachtrij verwijderd.

Hierdoor worden op verschillende pagina’s veel scripts niet meer geladen.

Maar het gaat nog iets verder. Bij het laden van plugins is er een dergelijke vergelijkbare volgorde. En wanneer ik natuurlijk een plugin alleen maar nodig heb op één of twee pagina’s, is het onzin wanneer ik hem op iedere pagina laadt.

Claude heeft geïndexeerd op welke pagina’s er wel of geen functionaliteit van andere plugins nodig was, en wanneer niet, werd de plugin niet geladen.

Dat scheelt alleen al een enorme hoeveelheid plugins die niet meer geladen hoeven te worden: Alle plugins die alleen iets doen in het beheerdersgedeelte zijn op de gewone webpagina’s overbodig.

De plugin die hiervoor gemaakt is, is een heel specifieke plugin die alleen op deze site zal werken. En op deze site alleen optimaal zal werken, wanneer ik regelmatig deze evaluatie opnieuw laat doen. Want iedere nieuwe toegevoegde plugin is een nieuwe potentiële vertragende factor die opnieuw getest zal moeten worden.

En dan hebben we nog wat over…

Vervuilende bezoekers en firewalls

De laatste weken heb ik enorm veel last van vervuilde bezoekersstatistieken door een exponentieel groeiend aantal bezoekers vanuit China en Hong Kong. Maar geen echte bezoekers, maar AI-bots die druk bezig zijn te leren. Dat was geen probleem toen vanuit China 4-5 bots per dag mijn site bezochten.

Toen het er 50 per dag werden begon het toch echt een probleem te worden en terwijl ik bezig was met mijn website optimalisatie waren het inmiddels meer dan 4000 bots die die dag mijn site bezocht hadden.

Ik kon de echte bezoekers bijna niet meer terugvinden in mijn bezoekstatistieken.

Nu is het mogelijk om verkeer op land te filteren. Er zijn verschillende plugins die dat doen. De meeste van deze plugins gebruiken echter een GeoIP dienst (een dienst die voor een IP adres een regio terug geeft) en voor dit soort diensten moet je betalen. Gewoonlijk per hit.

Maar met 4000 hits per dag en het risico dat dit exponentieel zou kunnen groeien, klonk mij dit toch een beetje als een nachtmerrie in de oren: Gaan betalen voor de mensen die je website niet bezoeken!

Maar mijn grootste bezwaar was vooral het feit, dat met deze aantallen bezoekers per dag die ik niet wil ik opnieuw een plugin toe zou moeten voegen, bovendien een plugin die voor iedere bezoeker een opvraag aan de hand van het IP zou moeten doen, om het land te ontdekken.

Gelukkig was dit ook vrij direct op te lossen. Claud hielp me met het downloaden van de IP reeksen die aan Chinese instanties zijn toegekend en het schrijven van blokkerende firewall regels, waardoor verkeer uit China niet meer op de site kan komen.

Ik denk niet dat er een realistische kans is, dat ik werkelijk een lead uit China zou krijgen.

De ambtelijke verwijzing – van loket naar loket

Wanneer je een pagina, product of blogpost wilt verwijderen is het mogelijk om de oude URL naar een nieuwe pagina, product of blogpost te laten verwijzen. En dat kan heel handig zijn. Bijvoorbeeld omdat je nog steeds verkeer op een product krijgt wat inmiddels niet meer bestaat.

Een voorbeeld: Jan heeft een webshop met mobiele telefoons. Eén van de telefoons die hij verkoopt is de Samson Milky Way 12. Na enkele jaren is deze telefoon niet meer te koop, maar mensen landen nog steeds op zijn pagina. In plaats van mensen teleurgesteld weg te sturen met de mededeling dat hij de telefoon niet meer verkoopt kan hij natuurlijk ook de pagina door laten sturen naar de Samson Milky Way 13.

Als de 13 ook niet meer verkocht wordt, verwijst hij de Milky Way 13 door naar de 14… en je begrijpt het al. Een aantal jaren later verwijst de 14 door naar de 15.

Landt er nog iemand op de 12, dan gaat hij via de 13 en de 14 naar de 15.

Dit soort doorverwijzingen kost extra tijd en veel doorverwijzingen wordt door Google negatief gewaardeerd. Onder andere omdat je iemand ergens heen zou kunnen sturen, waar hij helemaal niet wil zijn.

Toen ik toch bezig was mijn site ‘op diep niveau’ te optimaliseren vroeg ik Claude Code direct om alle ’tussendoor verwijzingen’ uit alle verwijzingen (bij mij opgeslagen in de ‘Redirection’ plugin) te verwijderen. Dus 12 direct naar 15 door te verwijzen, 13 naar 15 en 14 naar 15 en alle tussenstappen te verwijderen.

Dit bespaart tijd, maar ook latere problemen. Want een browser staat een maximaal aantal ‘redirects’ toe. Je kan niet oneindig door blijven verwijzen. En ongemerkt en ongewild zouden bepaalde pagina’s niet meer bereikbaar worden.

Wat kost een dergelijke versnelling en opschoning?

Vaak hebben mensen het idee dat alles wat via AI wordt gedaan geen tijd kost. Dat kan overigens wel. Je kan AI-agents een opdracht geven en weglopen zonder er verder naar te kijken. Over het algemeen betekent dat, dat je daarna behoorlijk wat werk hebt de chaos te herstellen.

Een proces als hierboven beschreven heeft een groot aantal beslismomenten die je beslist niet door een AI-agent wilt laten nemen. Sterker nog, als AI het wel zou kunnen zou ik het nog niet laten doen. Nog niet zolang geleden heb ik een medische operatie ondergaan. De operatie zou op twee verschillende manieren plaats kunnen vinden. De arts vroeg mij, na enige uitleg, waar ik voor zou kiezen. Ik vertelde hem, dat ik het hem over een week zou laten weten. In die week heb ik het advies van twee bevriende artsen (waarvan één mijn vriendin) gevraagd, voor ik uiteindelijk een beslissing nam. En geen van de bevriende artsen -ze kennen me te goed- heeft mij geadviseerd wat te doen. Ze hebben alleen de voor- en nadelen van beide opties aangegeven.

Ik zit zo in elkaar en ik hoop dat de meeste klanten van mij ook zo in elkaar zitten. Je wilt een gemotiveerde keuze maken. Met een magisch stokje zwaaien en hopen dat alles dan goed gedaan is, zit mij niet in het bloed.

De relevante factoren

Ik heb een grote site. Een gecomprimeerde backup is 8GB groot en ‘uitgepakt’ neemt de WordXPression site maar liefst 23 GB in beslag. Ik heb slechts twee klanten die in schijfbeslag een grotere website hebben. Om een grote website te inventariseren kost natuurlijk meer tijd dan het inventariseren van een site met laat maar zeggen 5 pagina’s. Om je een indruk te geven, ik heb meer dan 800 active blogposts. Dat wordt langzamerhand minder (ik ben bezig oude blogposts op te ruimen en per 5-10 oude blogposts over bepaalde onderwerpen één nieuwe, meer diepgaande post over hetzelfde onderwerp te schrijven), maar op het moment dat ik aan de performance werkte waren het er net iets minder dan 850.

Ik heb een complexe website. Met veel verschillende custom post types, templates en een aantal zelfgebouwde plugins om koppelingen met andere systemen te leggen. Eén van de voordelen van het kunnen programmeren.

En ik heb een ‘open’ server. Ik ben zelf de beheerder van mijn server (met een geweldige linux expert achter de hand voor die zaken waar ik zelf niet uit kom) en kan dus overal bijkomen. Zoals bijvoorbeeld bij de poorten van de server om die ‘dicht’ te gooien voor verkeer uit bepaalde landen.

Wanneer jij een shared hosting pakket bij een doorsnee provider hebt, zal je veel van de toegang die ik heb niet hebben en dus niet alles kunnen doen wat ik kon (laten) doen door Claude Code.

Of met andere woorden, ik denk dat ik met mijn site heel wat langer aan de gang ben geweest dan jij (of iemand namens jou) het met de jouwe zal zijn.

Maar mijn vraag- en antwoordspel met Claude heeft mij, samen met de tijd voor aanpassingen door Claude (die altijd net te kort waren om werkelijk iets anders te gaan doen) ruim vijf uur gekost.

Dat lijkt veel. Toch heeft het mij heel veel opgeleverd:

• In totaal ben ik de laatste twee jaar ruim twaalf uur met performance issues bezig geweest. Dat heeft vooral voor de desktop website enorme versnellingen opgeleverd, dus het is geen verloren tijd. Maar juist de performance van de mobiele website was een hindernis waar ik steeds niet overheen kon komen.
• Omdat ik ’toch al bezig was’ heb ik gelijk twee problemen opgelost (firewall en redirects). Vooral de redirects waren nu nog geen probleem, maar met één of twee redirects erbij zou het een sterk negatieve invloed op mijn SEO waardering krijgen.
• Wanneer ikzelf het werk had moeten doen voor het conditioneel in- en uitschakelen van plugins was ik waarschijnlijk tientallen uren kwijt geweest, zonder te weten wat het effect zou zijn op de performance. Ook nu nam dit onderdeel de meeste tijd in beslag (uit de logs bleek, dat bijna drie van de vijf uur het tunen van de plugins/pagina’s was), maar slechts een fractie van wat het mij anders zou kosten.
• Het was een goede manier om Claude Code voor iets anders dan ‘alleen coderen’ te leren kennen. Het voordeel van Claude Code is dat ik als WordPress professional vaak en graag de problemen in WordPress oplos, en minder ervaring heb met het tunen van servers. De ‘kennis’ van Claude Code maakte het makkelijk oplossingen te vinden, waar ik zelf niet zo snel aan zou denken.

Wil je ook je website versnellen?

Presteert jouw website ook wat minder op mobiel? En je vindt om zelf met AI-agents aan de slag gaan toch wat eng? Neem eens contact op.

Dit artikel geeft onder meer een antwoord op de volgende vragen:

• Waarom is een website die er op een mobiel scherm goed uitziet nog niet automatisch snel op een echte smartphone?
• Welke Google-metrics en Lighthouse-scores zijn belangrijk bij het beoordelen van mobiele performance?
• Welke invloed hebben afbeeldingen, fonts, JavaScript, externe koppelingen en AJAX-verzoeken op de laadsnelheid?
• Hoe kun je met Claude Code via SSH systematisch onderzoeken waar een WordPress-site performance verliest?
• Waarom kan een websitespecifieke plugin meer winst opleveren dan alleen een algemene caching- of optimalisatieplugin?