Fase 5 · Realisatie & Bewijs
Theorie omgezet in code
Na het rapport met rode cijfers was de keuze simpel: dichtklappen of doorpakken. Ik koos het
tweede. Hieronder de concrete realisatie — elke ingreep direct gekoppeld aan het ontwerpdoel: Perceived
Performance herstellen.
De nepscore ontmantelen
Eerst even het olifantje in de kamer. Die 100/100 van Google PageSpeed Insights? Compleet verzonnen door de
server zelf. De Wordfence-firewall gooide de deur dicht voor elke crawler — inclusief Googlebot. Dus
PageSpeed Insights mat braaf een lege 403-foutpagina, gaf daar een perfecte score aan, en iedereen was
tevreden. Behalve de bezoeker die zes seconden naar een wit scherm zat te staren, uiteraard.
Om écht te meten wat die site deed, moest ik onder die firewall door kruipen. Via een lokale headless
Lighthouse-audit — Chrome opstarten zonder venster, rechtstreeks vanuit de terminal — kon ik de blokkade
omzeilen. De crawler gedroeg zich als een reguliere bezoeker, Wordfence liet hem door, en voor het eerst
hadden we eerlijke cijfers.
Die eerlijke cijfers? Een performance score van 31 op 100. Geen oranje. Diep rood. De LCP
— het moment waarop het grootste element op je scherm verschijnt — duurde bijna negen volle seconden. Negen.
Je had in die tijd twee kopjes koffie kunnen inschenken.
Stap 1: Smush — de foto's aanpakken
Het lag voor de hand om bij de afbeeldingen te beginnen. Die DSC_2729.jpg van achttien keer te groot was
het schoolvoorbeeld: een rauwe camerafoto van 1920×1280 pixels, gepropt in een vakje van 452×301. Niet te
bevatten eigenlijk, dat soort dingen standaard zijn in WordPress als niemand oplet.
De Smush plugin deed precies wat-ie beloofde. Bulk-compressie over alle bestaande
afbeeldingen — lossless, geen zichtbaar kwaliteitsverlies — plus het activeren van lazy
loading. Dat laatste is misschien nog belangrijker dan de compressie zelf: afbeeldingen buiten je
viewport worden pas opgehaald als je ernaar scrolt. Voorheen downloadde de browser álles in één keer,
ongeacht of je het ooit zou zien.
Resultaat: het totale afbeeldingsgewicht daalde naar zo'n 648 KB per paginalading.
Abstract getal, maar vergelijk het met de megabytes die er voorheen doorheen vlogen — dan snap je de omvang.
Stap 2: WP Super Cache — eindelijk goed instellen
Dit irriteerde me eerlijk gezegd. De plugin stónd er al. WP Super Cache was geïnstalleerd maar half
geconfigureerd. Alsof je een slot op de deur hebt laten zetten maar vergeet de sleutel om te draaien. De
geavanceerde instellingen — paginacompressie via gzip, cache rebuild, uitgesloten caching voor beheerders —
stonden allemaal uit.
Na het juist configureren serveerde de site gecachte pagina's als statieke HTML, waardoor de hele
WordPress-database-dans werd overgeslagen. In plaats van elke keer PHP uitvoeren, databases raadplegen en
alles opnieuw assembleren, stuurt de server gewoon een kant-en-klaar bestand terug. Of ja — dat zou-ie
moeten doen. De TTFB bleef hardnekkig schommelen rond de twee seconden, wat vertelde dat de hosting
zelf de bottleneck is, niet WordPress.
Stap 3: Flying Scripts — het gouden ei
En toen de klapper. Van alle drie de ingrepen was dit diegene waarvan ik achteraf dacht: waarom doet niet
iedereen dit standaard? Flying Scripts is een piepkleine plugin die externe
JavaScript-bestanden uitstelt tot het moment dat een bezoeker interacteert — muisbeweging, scroll,
toetsaanslag. Tot dat moment laadt het script simpelweg niet.
Ik configureerde vier trefwoorden:
googletagmanager — alle Google-trackers in één klap uitgesteldfbevents — de beruchte Facebook Pixel, die altijd mee wil laden alsof-ie de belangrijkste
gast op het feest isinsight.min — LinkedIn's tracking-scripttrustindex — de Google Reviews widget die een bezoeker toch pas ziet als die scrolt
Het effect was absurd. De Total Blocking Time — de periode waarin de browser zegt "even
wachten, ik ben scripts aan het uitvoeren" — ging van 1.180 milliseconden naar letterlijk
nul. Niet "bijna nul." Nul. De browser werd niet meer gegijzeld door trackers.
Stap 4: Autoptimize — de laatste visuele vertraging wegsnijden
Na die eerste drie ingrepen stond de teller op 69/100. Best netjes. Maar iets knaagde. Als
je de site opende — vooral op een wat trager netwerk — zag je nóg steeds een flits. Eentje die je bijna niet
kon plaatsen: de tekst verscheen, verdween dan een fractie, en dook weer op in een ander lettertype. Alsof
de pagina even van gedachten veranderde halverwege het opbouwen.
Dat fenomeen heeft een naam. Flash of Invisible Text (FOIT) — de browser wacht met het
tonen van tekst totdat het externe lettertype volledig is gedownload. Bij CompleetFit ging het om Adobe
Typekit-fonts die via een apart CSS-bestand worden opgehaald. Zolang dat bestand niet binnen is, zie je:
niks. Leegte waar tekst hoort te staan.
Tegelijkertijd lag er nog een ander slepend probleem. De audit uit de vorige ronde had al 10
render-blocking CSS-bestanden gespot — Divi, Divi Pixel, Trustindex, Typekit, noem maar op. Ik
had de tracker-scripts aangepakt met Flying Scripts, maar die stylesheets? Die stonden er nog steeds. De
browser wachtte braaf tot alle tien geladen waren voordat hij ook maar één pixel tekende.
De oplossing was Autoptimize, dezelfde tool die ik in Fase 2 al had afgewogen tegen de alternatieven. Twee
specifieke ingrepen:
- CSS-aggregatie: De 10 losse stylesheets samengevoegd tot één bestand. Eén HTTP-request
in plaats van tien. De browser hoeft nu niet meer tien afzonderlijke bestanden op te halen voordat hij mag
beginnen met tekenen.
font-display: swap geforceerd op alle externe lettertypes. Dat betekent:
de browser toont direct een systeemlettertype als placeholder, en wisselt geruisloos naar het Adobe-font
zodra dat geladen is. De bezoeker ziet per direct tekst — geen FOIT meer.
De resultaten van deze vierde stap alleen al:
Het Evaluatie-Plafond
BC 8.3.2
72 op 100. Is dat een bliksemschitterende score? Eerlijk gezegd: nee. Maar pak de reisweg erbij — van 31
via 69 naar 72, over twee optimalisatierondes met vier gratis WordPress-plugins — en je begrijpt hoever we
gekomen zijn zonder ook maar één euro uit te geven. De bezoeker die voorheen bijna negen seconden wachtte op
de hoofdafbeelding? Die ziet nu in anderhalve seconde een compleet scherm. Dat is het verschil tussen
wegklikken en blijven hangen.
Wat me na de tweede ronde opviel — en dit is eerlijk een beetje frustrerend — is dat elke volgende punt
harder gaat. Het verschil tussen 31 en 69 was spectaculair, bijna makkelijk zelfs. Maar van 69 naar 72? Dat
kostte net zoveel denktijd voor drie schamele punten. De wet van de afnemende meeropbrengst in actie, zeg
maar.
En dat brengt me bij de kern: wat er nu overblijft is niet met plugins op te lossen. De TTFB
schommelt nog steeds rond de 3 seconden — dat is puur de hosting die het niet trekt. Google's
grens voor een "goede" TTFB ligt op 600 milliseconden. Je kunt het frontend nog zo strak optimaliseren, als
de server er drie seconden over doet om überhaupt te antwoorden, dan start je elk rapport met een handicap.
De Cumulative Layout Shift is daarnaast iets verslechterd doordat Smush lazy loading activeert zonder dat
Divi vaste afmetingen meegeeft aan de afbeeldingscontainers. Dat verspringen ken je wel: je begint te lezen
en dan schuift alles ineens een stuk naar beneden omdat er een plaatje inlaadt. Irritant, maar oplosbaar —
mits je bij de broncode kan. En bij Divi is dat altijd een gevecht.
Wat er nog nodig is
Vervolgstappen
Wil CompleetFit structureel boven de 80 komen, dan zijn er drie dingen nodig die
buiten de scope van plugin-optimalisatie vallen: een CDN ervoor (Cloudflare, gratis), krachtiger hosting die
de TTFB naar onder de seconde trekt, en vaste dimensies op álle afbeeldingscontainers om die CLS te fixen.
Op de langere termijn is dat Divi-thema gewoon te lomp voor wat deze site nodig heeft. Maar dat — dat is een
ander gesprek dan waar we mee begonnen.
Eigen reflectie
Wat ik hiervan leerde
De meest waardevolle les uit dit hele traject had niks met code te maken. Het was
het besef dat een getal — of dat nou 100/100 is of 31/100 — pas iets betekent als je weet hoe het tot stand
komt. Die fake 100 vertelde een verhaal dat compleet los stond van de werkelijkheid. Pas toen ik de
methodiek wijzigde kwamen de échte cijfers boven
water. Soms zijn de kleinste numerieke winsten de meest zichtbare verbeteringen in de gebruikerservaring.
De bezoeker merkt een wereld van verschil. Wat nu overblijft voelt als een
nulmeting voor een volgend gesprek — eentje over hosting, over architectuur, over de vraag of een
pagebuilder als Divi nog houdbaar is als snelheid ertoe doet. Maar dat is precies wat een goede audit hoort
te doen: niet alles oplossen, maar glashelder maken wat er speelt en waar de grenzen van je eigen ingrepen
liggen.
Praktijk
vs Opleiding
Idealisme vs. Realisme BC 8.5.1
Op de CMD-opleiding is de mantra duidelijk: schrijf schone, custom code, houd je
DOM-tree ondiep, werk mobile-first en zorg dat performance vanaf seconde één in je architectuur zit
verweven. De praktijk bij Like Bamboo en CompleetFit bleek echter compleet anders. Omwille van budget en
klantbeheergemak is de frontend in elkaar geklikt met Divi — een loeizware pagebuilder die zonder pardon
honderden overbodige node-elementen en scripts inlaadt.
Mijn initiële CMD-instinct was: het fundament is verrot, we moeten het thema
herbouwen. Echter, dat zou CompleetFit duizenden euro's kosten, wat financieel totaal onhaalbaar is
voor hun omzet/ROI. Ik werd gedwongen om de 'praktiijk-aanpak' te prefereren boven de theorie: in plaats van
de bron aanpakken, heb ik gekozen voor agressieve symptoombestrijding via caching en bestandsaggregatie
(Autoptimize). Hoewel dit indruist tegen mijn theorie-idealen, besefte ik dat dit voor deze MKB-context wél
veruit de verstandigste aanpak is. Goed werk afleveren in een agency-omgeving betekent niet altijd 'de
perfecte code' schrijven, maar de business case van de klant accepteren en daar met beperkte middelen
maximale impact binnen uithalen.
„We hadden geen Google rapport nodig om te voelen dat het traag was. Maar we hadden wél een eerlijke meting
nodig om te bewijzen hoe traag — en om te laten zien dat het anders kan."
