Snelheid en mobiel:wat u moet meten en waar het ophoudt te lonen

De drie waarden in gewone taal

LCP, largest contentful paint. Hoe lang duurt het voor het grootste blok tekst of de grootste afbeelding in beeld staat. Dat is het moment waarop een bezoeker denkt: de pagina is er. Niet het moment waarop alles klaar is. De gebruikelijke boosdoeners zijn een enorme headerafbeelding die niet verkleind is, een trage server en een cookiebanner die alles achter zich ophoudt.

CLS, cumulative layout shift. Hoeveel verspringt de pagina onder uw vinger terwijl ze laadt. U wil op een link klikken en op het laatste moment schuift er een advertentie of een banner tussen, waardoor u iets anders raakt. Dat is CLS. De oorzaak is bijna altijd hetzelfde: afbeeldingen of iframes zonder opgegeven hoogte en breedte. Een tweede oorzaak is iets dat later in de pagina wordt ingeschoven.

INP, interaction to next paint. Hoe lang duurt het voor de pagina zichtbaar reageert nadat u iets aanklikt of aantikt. Een menu dat pas na een seconde opengaat, een knop die niets lijkt te doen. INP verving in maart 2024 de oudere meetwaarde FID en het meet strenger, want het kijkt naar de hele reactie in plaats van naar de eerste vertraging. De oorzaak is meestal te veel JavaScript dat tegelijk draait.

De drempelwaarden

Tussen goed en slecht ligt een middenzone die Google aanduidt als voor verbetering vatbaar. Twee dingen bij deze tabel.

Eerst: de meting gebeurt op het 75e percentiel. Drie op de vier bezoekers moeten onder de drempel zitten. Uw eigen gevoel op een snelle laptop met glasvezel zegt dus niets. De bezoeker die telt is die met een drie jaar oude telefoon op een matige verbinding.

Tweede: deze drempels staan niet in steen. Google heeft de set eerder gewijzigd en kan dat opnieuw doen. Controleer de actuele waarden bij de bron voor u ze in een bestek of een contract zet.

Labdata en velddata: hier loopt bijna iedereen vast

Dit is het onderscheid dat de meeste discussies over paginasnelheid onnodig maakt.

Labdata is een meting in een gecontroleerde omgeving. Eén apparaat, één gesimuleerde verbinding, één moment. Lighthouse en het labgedeelte van PageSpeed Insights doen dit. Voordeel: herhaalbaar en het zegt precies wat er mis is. Nadeel: het is niet uw publiek.

Velddata komt van echte Chrome-gebruikers die uw site bezochten, verzameld over een periode van 28 dagen. Dit heet het Chrome User Experience Report. Het rapport Core Web Vitals in Search Console toont deze cijfers. Voordeel: het is de werkelijkheid en het is wat meetelt voor uw positie. Nadeel: het loopt achter en u ziet het effect van een verbetering pas weken later.

Twee gevolgen die u moet kennen. Een kleine site heeft vaak te weinig bezoekers voor velddata. Dan meldt Search Console dat er onvoldoende gegevens zijn. Dat is geen fout en geen probleem, het is een gevolg van uw bezoekersaantal. U werkt dan met labdata en met gezond verstand.

En INP is in het lab niet fatsoenlijk te meten, want er is niemand die klikt. Lighthouse geeft in plaats daarvan total blocking time als benadering. Wie u een INP-cijfer uit een labtest voorlegt, meet iets anders dan hij zegt.

Lighthouse lokaal draaien, gratis

U heeft hier geen betaald gereedschap voor nodig en geen account.

1. Open de pagina in Chrome.
2. Rechtermuisknop en dan Inspecteren. De sneltoets is F12 op Windows en Cmd+Option+I op Mac.
3. Kies het tabblad Lighthouse. Staat het er niet, klik dan op de dubbele pijl naast de tabbladen.
4. Zet het apparaat op Mobiel en vink Prestaties aan.
5. Klik op Pagina-analyse.

Drie praktische regels. Draai de test in een incognitovenster, anders meet u uw eigen browserextensies mee. Draai hem drie keer en neem de middelste uitkomst, want de score schommelt tussen twee identieke metingen. En test niet alleen de homepage. De pagina's waar uw bezoekers binnenkomen zijn belangrijker en dat is zelden de homepage.

Wilt u velddata en labdata naast elkaar, gebruik dan PageSpeed Insights op het web. Bovenaan staat de velddata als die er is, daaronder de labmeting. Verwar de twee blokken niet, want ze staan onder elkaar en meten iets anders.

Mobiel: viewport en zoom

Google indexeert mobiel-eerst. Wat niet in de mobiele versie van uw pagina staat, telt niet mee. Een site die op mobiel de helft van de tekst verbergt, verbergt die helft ook voor Google.

Eén regel HTML is verplicht in de <head> van elke pagina:

<meta name="viewport" content="width=device-width, initial-scale=1">

Zonder die regel toont een telefoon uw pagina als een uitgezoomde desktopversie en moet de bezoeker inzoomen om iets te lezen.

Wat u er niet bij zet: user-scalable=no of maximum-scale=1. Die twee blokkeren zoomen. Dat is een probleem voor iedereen die minder scherp ziet en het is een toegankelijkheidsfout. Sommige browsers negeren de instelling intussen. Reken daar niet op en laat ze gewoon weg.

Drie dingen die op mobiel verder terugkomen:

• Tekst te klein. Onder de 16 pixels wordt lezen op een telefoon lastig. Bij invoervelden heeft het een bijkomend gevolg: iOS zoomt automatisch in wanneer de lettergrootte onder 16 pixels ligt, wat de bezoeker uit de lay-out gooit.
• Tapdoelen te dicht op elkaar. Twee links onder elkaar met enkele pixels ertussen zijn met een vinger niet te scheiden.
• Horizontaal scrollen. Een tabel of afbeelding breder dan het scherm duwt de hele pagina scheef. Lighthouse meldt dit onder de noemer dat de inhoud niet correct is geschaald.

Waar het ophoudt te lonen

Nu het eerlijke deel. Snelheid is een rankingsignaal van beperkt gewicht. Het werkt vooral als scheidsrechter tussen pagina's die inhoudelijk gelijkwaardig zijn. Een tragere pagina met een beter antwoord verslaat een snelle pagina met een slecht antwoord.

Van vijf seconden naar twee seconden is een merkbaar verschil, voor de bezoeker en voor de meting. Van 1,4 seconde naar 1,2 seconde is dat niet. Hoeveel een tiende seconde precies opbrengt in omzet is voor uw site niet betrouwbaar bekend. Wat wel vaststaat is waar de drempel ligt: 2,5 seconden voor LCP en niet nul. Zit u eronder, dan is dit onderwerp klaar en gaat uw volgende dag werk beter naar inhoud.

Wie desondanks blijft jagen op een Lighthouse-score van 100, betaalt daarvoor meestal met iets anders. Een chatwidget die weg moet, tracking die weg moet, een lettertype dat weg moet. Soms is dat de juiste afweging. Vaak is het een score optimaliseren in plaats van een site.

Waar de winst voor een kmo wél zit, in deze volgorde:

1. Afbeeldingen. Te grote bestanden zijn de meest voorkomende oorzaak van een slechte LCP. Verklein tot de weergavegrootte, sla op als WebP en laat afbeeldingen onder de vouw pas laden als ze nodig zijn.
2. Scripts die u niet gebruikt. Een chatvenster, drie trackingpixels, een tag manager met vergeten regels en een sliderplugin uit 2019. Elk script kost INP.
3. De cookiebanner. Die is er vaak zowel voor de slechtste LCP als voor de slechtste CLS verantwoordelijk, omdat hij bovenop de pagina laadt en de rest naar beneden duwt.
4. Caching en compressie bij uw hoster. Meestal een schakelaar in het configuratiescherm van uw hosting.
5. Vaste afmetingen op afbeeldingen en iframes. Twee attributen, width en height, lossen het merendeel van de CLS-problemen op.

Wat u zelf kan en wat niet

Zelf te doen, zonder ontwikkelaar:

• Lighthouse draaien in Chrome en het rapport Core Web Vitals in Search Console openen.
• Afbeeldingen verkleinen voor u ze uploadt. Dit is de goedkoopste winst in dit hele hoofdstuk.
• Plugins en scripts uitzetten die niemand nog gebruikt.
• De viewport-regel controleren en user-scalable=no weghalen als het er staat.
• Caching en compressie aanzetten bij uw hoster.

Waarvoor u hulp nodig heeft:

• Een trage serverreactie. Als de eerste byte al traag komt, ligt het aan uw hosting of aan de opbouw van de site. Dat is geen instelling.
• CSS en JavaScript die het tekenen van de pagina blokkeren. Herschikken vraagt kennis van het thema.
• Een site die volledig in JavaScript wordt opgebouwd. Daar zijn snelheid en vindbaarheid één en hetzelfde bouwvraagstuk en dat lost u niet met een plugin op.
• Een thema dat zwaar is van ontwerp. Op een bepaald punt is vervangen goedkoper dan repareren.

Onze werkvolgorde: eerst meten, dan de vijf punten hierboven doorlopen, dan opnieuw meten. Blijft u daarna boven de drempels, dan is het een gesprek over hosting of over het thema en niet meer over instellingen.

Wenst u dit niet zelf te doen: SEMANU voert de volledige SEO- en GEO-audit uit voor 1.450 euro, inclusief rapport en werksessie. Wat erin zit staat op de gidspagina.