Een trage website valt op voor je kan klikken
Een herkenbaar geval: op kantoor lijkt een website vlot te werken, maar op een smartphone via 4G verschijnt eerst een leeg scherm. Daarna komt de grote foto bovenaan, vervolgens een cookiebanner en pas dan de knop waarop iemand wil drukken. Voor de bezoeker voelt dat als één traag probleem. Bij het nakijken blijken er meestal drie aparte oorzaken te zijn: zware foto's, te veel scripts en een server die te laat begint.
Dat verschil tussen kantoor en mobiel is geen detail. Een glasvezelverbinding en een recente laptop verbergen problemen die een klant op een smartphone wel voelt. Daarom testen wij zakelijke websites eerst op mobiel, met een normale verbinding en zonder ingelogd te zijn. Een hoge score op een desktoptest maakt een trage mobiele pagina niet goed.
Google vat die ervaring samen in Core Web Vitals. Dat zijn drie metingen die tonen hoe snel de nuttige inhoud verschijnt, hoe snel een pagina reageert en of alles op zijn plaats blijft staan. Ze zijn geen rapportcijfer voor je hele website. Ze helpen wel om te zien waar je moet beginnen.
Grote foto's maken je eerste scherm zwaar
Een foto van een moderne smartphone kan gemakkelijk 4 tot 8 MB groot zijn. Zet je die foto bovenaan je homepage, dan moet een mobiele bezoeker soms bijna hetzelfde bestand downloaden als iemand op een groot scherm. De foto staat misschien zichtbaar op 600 pixels breed, maar de browser krijgt een bestand van 4000 pixels doorgestuurd.
Dat vertraagt vooral de eerste grote zichtbare inhoud, meestal de sfeerfoto, banner of titelzone bovenaan. In Core Web Vitals heet die meting LCP, de tijd tot het grootste nuttige onderdeel zichtbaar is. Bij 2,5 seconden of minder zit je in de groene zone. Een grote foto is vaak de eerste verdachte wanneer die tijd te hoog ligt.
De oplossing is niet simpelweg elke foto kleiner slepen in het beheerpaneel. De originele bestanden moeten verkleind worden naar de afmetingen die de site echt nodig heeft. WebP of AVIF maakt meestal een veel kleiner bestand dan een oude PNG of een slecht gecomprimeerde JPEG. Een groot sfeerbeeld komt vaak uit op enkele honderden kilobytes, niet op meerdere megabytes. Dat is een richtwaarde, geen vaste grens.
Wij laden foto's onder het eerste scherm pas wanneer iemand naar beneden scrolt. De grote foto bovenaan doen we net niet lui laden, omdat die meteen nodig is. We geven elke foto ook een vaste breedte en hoogte mee. Zo blijft er ruimte gereserveerd en springt de tekst niet naar beneden terwijl het beeld binnenkomt.
Plugins en scripts houden de pagina bezig
Een website kan snel zijn opgebouwd en toch traag reageren. Dat gebeurt wanneer de browser na het laden nog allerlei opdrachten moet uitvoeren. Denk aan een chatvenster, een cookietool, een afsprakenkalender, een kaart, een video, bezoekersmeting en verschillende advertentie- of marketingcodes. Elk onderdeel maakt verbindingen en sommige wachten op een externe dienst.
Een slider met vijf foto's is niet automatisch een probleem. Vijf scripts die allemaal tegelijk de pagina willen aanpassen, zijn dat wel. Hetzelfde geldt voor plugins die ooit geïnstalleerd zijn voor één kleine functie en daarna blijven draaien op elke pagina. Een webshop kan bijvoorbeeld een voorraadkoppeling, reviews, betaalmodule en verzendtool laden op een gewone informatiepagina waar die niets doen.
Wij kijken daarom niet alleen naar hoeveel plugins er in het beheerpaneel staan. We zoeken uit welke code op welke pagina nodig is. Ongebruikte onderdelen gaan weg. Niet-dringende scripts laden pas na toestemming of nadat de zichtbare inhoud er staat. Een kaart komt bijvoorbeeld pas na een klik, in plaats van meteen bij het openen van de contactpagina.
De bijhorende Core Web Vital heet INP. Die meet hoe lang een pagina nodig heeft om op een klik of tik te reageren. Een INP van 200 milliseconden of minder is goed. Duurt een menu merkbaar langer, dan is het probleem vaak geen slechte internetverbinding, maar een browser die nog druk bezig is met scripts. Een koppeling met andere software kan hetzelfde effect hebben wanneer de site telkens op een trage externe server moet wachten.
Trage hosting laat elke pagina te laat beginnen
Voor een browser een foto of script kan downloaden, moet de server eerst antwoorden. Die wachttijd heet vaak de server response time of TTFB, de tijd tot de eerste byte. Duurt dat 1,2 seconden, dan is er al meer dan een seconde voorbij voor de browser iets kan tonen. Daarna moeten de bestanden nog gedownload en verwerkt worden.
Een drukke gedeelde server, geen paginacache, een verouderde PHP-versie of een database die te veel moet zoeken zijn bekende oorzaken. Bij een eenvoudige website hoort de eerste reactie niet telkens meerdere seconden te duren. Bij een webshop of een site met een klantenportaal kan er meer rekenwerk nodig zijn, maar dan moet duidelijk zijn welk proces die tijd vraagt.
Dit lossen wij niet op door meteen een volledige nieuwe website te bouwen. Eerst testen we dezelfde pagina meerdere keren en vergelijken we de serverreactie met het laden van de bestanden. Daarna kijken we naar caching, databasequeries, beeldverwerking en de hostingconfiguratie. Soms volstaat een betere instelling. Soms is de hosting te klein voor de software die erop draait. Een duurdere server maakt slechte code niet goed, maar goede code op een overvolle server blijft evenmin snel.
Een snelle eerste serverreactie helpt ook bij de drie metingen, maar vervangt ze niet. Een pagina kan snel beginnen en daarna nog vastlopen op een grote foto. Daarom moet je de oorzaak per onderdeel bekijken.
De meetcijfers vertellen welke oorzaak speelt
LCP toont wanneer de nuttige inhoud verschijnt
Zie je in PageSpeed Insights een slechte LCP, kijk dan eerst naar het grootste onderdeel bovenaan. Is dat een foto, dan controleer je formaat en afmetingen. Is het tekst met een webfont, dan kijk je naar de lettertypes en de serverreactie. Een spinner die snel verschijnt telt niet als nuttige inhoud. De bezoeker wil de dienst, prijs of contactknop zien.
INP toont of klikken meteen iets doet
Een slechte INP wijst vaak naar JavaScript. Openklappende menu's, filters en formulieren moeten reageren zonder dat de browser eerst een lange reeks opdrachten afwerkt. Haal scripts weg die niets bijdragen en stel zware functies uit tot iemand ze werkelijk gebruikt.
CLS toont waarom de pagina verspringt
Bij een slechte CLS komt de inhoud tijdens het laden onverwacht omhoog of omlaag. Dat gebeurt vaak wanneer een foto geen vaste afmetingen heeft, een advertentieblok te laat ruimte inneemt of een cookiebanner de pagina verschuift. Het gevolg is meer dan irritatie: iemand kan op een verkeerde knop tikken. Bij een CLS van 0,1 of minder zit deze meting in de groene zone.
Een score van 100 is geen zinnig doel op zichzelf. Een site die snel werkt voor echte bezoekers is beter dan een test die mooi oogt terwijl je contactformulier of productfilter traag blijft. Wij gebruiken de metingen om keuzes te maken, niet om een cijfer op een offerte te zetten.
Controleer deze week je homepage en één belangrijke dienst- of productpagina op een smartphone. Test in een privévenster, kijk eerst naar het moment waarop de titel en hoofdafbeelding verschijnen en klik daarna op het menu of formulier. Noteer wat traag voelt en bekijk de drie Core Web Vitals in PageSpeed Insights. De websitecheck helpt je om te bepalen of je moet beginnen bij foto's, scripts of hosting.