Hoe we Hyvä-snelheid testen met Lighthouse, en de valkuilen

Lighthouse-cijfers zie je overal in discussies over Hyvä, ook op onze eigen pagina's. Een score van 94 zegt niets als je niet weet hoe die gemeten is. Test dezelfde pagina twee keer en je kunt twee verschillende cijfers krijgen. Test verkeerd en je kunt een perfecte score krijgen voor een pagina die nooit geladen is.

Dit artikel legt de methode uit die we gebruiken als we Hyvä- en Luma-webshops meten. Het noemt ook de valkuilen waar we zelf in zijn gestapt, zodat je ze kunt vermijden als je je eigen webshop controleert.

Waarom één Lighthouse-run niet genoeg is

Lighthouse simuleert een middenklasse telefoon op een vertraagde verbinding. Het resultaat hangt af van de pagina, maar ook van de reactietijd van de server op dat moment, de CDN en de machine waarop de test draait.

Eén run kan een uitschieter zijn, naar boven of naar beneden. Daarom noemen we nooit één run. We testen elke pagina drie keer en gebruiken de mediaan.

We testen ook de drie paginatypes die voor een webshop het belangrijkst zijn: home, categorie en product. Een snelle homepage met een trage productpagina is geen snelle webshop.

Onze methode, stap voor stap

1. Gebruik de Lighthouse CLI. We draaien Lighthouse 13 vanaf de command line, niet vanuit een browsertab met geïnstalleerde extensies. Browserextensies kunnen scripts injecteren en het resultaat veranderen.
2. Gebruik headless Chrome. We starten Chrome met --headless=new, dat dezelfde rendering-engine gebruikt als gewone Chrome.
3. Test de echte URL. We testen de publieke URL achter de CDN, niet een server-IP of een interne hostnaam. Klanten bereiken de webshop via de CDN, dus de test hoort dat ook te doen.
4. Leeg en verwarm eerst de cache. Na een deploy legen we de cache en vragen we elke pagina één keer op voordat we meten. Anders meet de eerste run een koude cache.
5. Drie runs per pagina. We nemen de mediaan van 3 mobiele runs, plus 1 desktoprun.
6. Bewaar het volledige rapport. We bewaren de JSON-uitvoer, zodat we naar LCP, total blocking time, aantal requests en overdrachtsgrootte kunnen kijken, niet alleen naar de score.

Een typisch commando ziet er zo uit:

lighthouse https://www.example.com/women/dresses.html \
  --only-categories=performance \
  --chrome-flags="--headless=new" \
  --output=json --output-path=./category-run1.json

Voor de desktoprun voegen we --preset=desktoptoe. Mobiel is de standaard vormfactor.

Valkuil 1: botbeveiliging blokkeert de test

Deze verraste ons. Onze nginx-configuratie blokkeert bot-user-agents die “lighthouse” of “headless” bevatten. Dat is een verstandige regel tegen scrapers, maar hij blokkeert ook de test.

Als het verzoek wordt geblokkeerd, geeft de server een 403-foutpagina terug. Lighthouse meet dan die kleine foutpagina, en de score kan er uitstekend uitzien. Het cijfer klopt, maar het beschrijft de verkeerde pagina.

De oplossing is de test te draaien met een normale browser-user-agent, of je eigen testmachine toe te staan. Controleer altijd de uiteindelijke URL en de screenshot in het rapport voordat je een score vertrouwt.

Valkuil 2: testen buiten de CDN om

Direct de originserver testen kan een trager resultaat geven dan klanten zien, omdat de CDN dan niets cachet. Een pagina testen die nog niet in de CDN-cache staat, geeft weer een ander resultaat.

We liepen ook tegen een minder voor de hand liggende variant van dit probleem aan bij afbeeldingen. Productafbeeldingen werden opgevraagd en in de CDN gecachet voordat Magento de verkleinde versies had aangemaakt. De CDN bleef het verkeerde antwoord serveren nadat het verkleinen klaar was.

De oplossing was om eerst catalog:images:resize te draaien en daarna de CDN-cache per hostnaam te legen. De volledige afbeeldingsopzet behandelen we in WebP-productafbeeldingen serveren achter Cloudflare.

Valkuil 3: developer mode en ontbrekende statische content

Magento in developer mode genereert bestanden op aanvraag en slaat veel optimalisaties over. Een Lighthouse-score uit developer mode zegt bijna niets over productie.

We meten alleen in production mode, na de static content deploy en met indexers op schedule. De opzet staat beschreven in production mode en deploys voor Hyvä-webshops.

Valkuil 4: labscores vergelijken die niet vergelijkbaar zijn

Een schoon Luma-thema op een snelle server achter Cloudflare, in production mode, scoort ook goed. In onze eigen benchmark scoorde schone Luma mobiel 88 tot 99 en Hyvä 93 tot 100.

Het grotere verschil zat in wat de browser moet laden:

Echte Luma-webshops met extensies en trackingscripts scoren meestal veel lager dan een schone installatie. Op echte goedkope telefoons telt een halve megabyte JavaScript zwaarder dan het lab laat zien. Daarom vergelijken we de belasting, niet alleen de score. De volledige cijfers staan in onze benchmark van Hyvä versus Luma.

Labdata versus velddata

Lighthouse is labdata: één gesimuleerd apparaat, één locatie, één moment. Het is uitstekend om builds te vergelijken en regressies op te sporen.

Velddata komt van echte bezoekers, bijvoorbeeld via het Chrome User Experience Report in Search Console. Het weerspiegelt echte telefoons, echte netwerken en echte trackingscripts.

We gebruiken Lighthouse om doelen te stellen en elke release te controleren. Na de lancering kijken we naar data van echte gebruikers en afgeronde checkouts, want dat is wat klanten echt ervaren. Onze Core Web Vitals-checklist behandelt de veldmetingen uitgebreider.

Veelgestelde vragen

Waarom wijkt mijn PageSpeed Insights-score af van die van jullie?

PageSpeed Insights draait Lighthouse op de servers van Google, vanaf een andere locatie en op een ander moment. Het toont ook velddata als daar genoeg van is. Kleine verschillen tussen tools zijn normaal; daarom gebruiken we een vaste methode en een mediaan.

Moeten we pagina's testen waarvoor je ingelogd moet zijn?

Voor snelheidsdoelen testen we publieke pagina's die voor gasten gecachet zijn. Winkelwagen, checkout en accountpagina's controleer je beter met data van echte gebruikers en functionele tests.

Welke score garanderen jullie bij de lancering?

Een Lighthouse Performance-score van minimaal 89 op mobiel voor home-, categorie- en productpagina's. Dit geldt op een voor Hyvä geoptimaliseerde server en met de afbeeldingen en scripts die in het projectplan zijn afgesproken.

Wil je weten hoe je huidige webshop echt presteert? Bekijk hoe Hyvä zich verhoudt tot Luma, of vraag ons om een Magento 2-audit met metingen zoals we die hier beschrijven.