Trage website: zo stelt u een diagnose en kiest u de juiste verbeteringen

Late weergave, een trage reactie of verschuivende inhoud kan een taak bemoeilijken. Het zakelijke effect hangt af van context, publiek en traject; een snelheidstest kan niet zelfstandig berekenen hoeveel omzet u verliest.

Begin met prioritaire pagina’s en acties. Noteer toestel, verbinding, serverlocatie, cachestatus en de problematische stap zodat iemand anders de situatie kan reproduceren.

LCP meet wanneer de belangrijkste zichtbare inhoud verschijnt, INP de algemene reactiesnelheid op interacties en CLS de visuele stabiliteit. De door Google gepubliceerde ‘goede’ grenzen zijn LCP van maximaal 2,5 seconden, INP van maximaal 200 milliseconden en CLS van maximaal 0,1.

Deze grenzen worden beoordeeld op het 75e percentiel van paginaladingen, apart voor mobiel en desktop wanneer er voldoende data zijn. Ze beschrijven specifieke ervaringsaspecten, niet de volledige paginakwaliteit of het bedrijfsresultaat.

Velddata komen van echte gebruikers en weerspiegelen hun toestellen, netwerken en trajecten. Ze vereisen voldoende volume en bestrijken vaak een voortschrijdende periode. PageSpeed Insights toont ze wanneer ze beschikbaar zijn.

• Lighthouse maakt een laboratoriumdiagnose onder gesimuleerde omstandigheden.
• Dat helpt om een probleem te reproduceren en een wijziging te testen, maar de score kan variëren.
• Beoordeel metriek en aanbevelingen in plaats van de totaalscore als bedrijfsdoel te gebruiken.

Onderzoek voor LCP het hoofdelement, de serverreactie, blokkerende bronnen en het moment waarop de browser het element ontdekt. Zoek voor INP naar lange JavaScript-taken en verwerking na een interactie.

Reserveer voor CLS ruimte voor beelden en later ingevoegde content en controleer lettertypen en componenten die vertraagd verschijnen. Richt de oplossing op de gemeten oorzaak van het betrokken paginatype.

Los eerst problemen op die een actie blokkeren of veel pagina’s raken: een zware hoofdbron, kostbaar extern script, instabiele lay-out of wisselende serverreactie. Controleer of de oplossing toegankelijkheid en functies intact laat.

Publiceer meetbare wijzigingen in kleine groepen en vergelijk dezelfde omstandigheden. Velddata veranderen pas wanneer nieuwe waarnemingen de oudere gegevens vervangen.

De eerste is het gewicht van de afbeeldingen. Een foto van vier megabyte rechtstreeks uit een smartphone, getoond in een kader van driehonderd pixels, verplicht elke bezoeker om honderd keer meer te downloaden dan nodig. Verkleinen, comprimeren en een modern formaat zoals WebP of AVIF gebruiken, deelt het gewicht van een pagina door vijf of tien zonder zichtbaar verlies; het is bijna altijd de eerste correctie.

De tweede is de opeenstapeling van externe scripts: statistiektools, chatwidgets, lettertypes van een externe dienst, deelknoppen, advertentiepixels. Elk lijkt op zich licht; samen blokkeren ze de weergave en bezetten ze de processor van de smartphone secondenlang. Een eerlijke inventaris verwijdert er vaak de helft van zonder dat iemand het merkt.

Daarna komen een onderbemeten hosting die traag antwoordt op het eerste verzoek, een thema of paginabouwer die al zijn CSS en JavaScript op elke pagina laadt, en niet-geoptimaliseerde weblettertypes die de tekst laten flikkeren. Die vijf oorzaken verklaren het merendeel van de slechte LCP- en INP-waarden op kmo-sites.

Open het rapport en begin bij het gedeelte met praktijkgegevens, als het bestaat. Dat is het enige dat beschrijft wat uw bezoekers meemaken. Noteer welke metriek faalt en op welk type toestel; een slechte LCP op mobiel maar goed op desktop wijst meteen naar het gewicht van de bronnen en het netwerk, niet naar de server.

• Ga daarna naar de labdiagnoses en zoek het LCP-element dat de tool aanwijst.
• Is het een afbeelding, dan ligt het probleem bij haar gewicht, formaat of het moment waarop de browser ze ontdekt.
• Is het een tekstblok, kijk dan naar de lettertypes en de blokkerende CSS.
• Die gerichte lezing voorkomt dat u een dag verliest aan het optimaliseren van iets dat niet meeweegt in de meting.

Negeer de totaalscore als doel. Twee pagina’s met 70 kunnen totaal verschillende problemen hebben, en van 70 naar 95 gaan in het lab verandert niets als de echte LCP slecht blijft. Behandel de aanbevelingen als een lijst pistes gerangschikt op geschatte winst, en controleer de echte winst na elke correctie.

Stap één: de afbeeldingen. Verklein ze tot de werkelijk getoonde afmetingen, zet ze om naar WebP of AVIF, vermeld hun afmetingen in de code en laad de afbeelding bovenaan de pagina met voorrang terwijl de andere uitgesteld worden. Die stap alleen lost vaak LCP en CLS op.

• Stap twee: de scripts.
• Lijst elk extern script op, vraag wie het dient, en verwijder de scripts zonder antwoord.
• Stel de overblijvende uit tot na de weergave van de pagina.
• Een statistiektool kan een seconde wachten; een chatwidget kan bij de eerste scroll laden.

Stap drie: de server en de caching. Controleer de antwoordtijd van het eerste verzoek; boven enkele honderden milliseconden dringt een paginacache of een contentdistributienetwerk zich op. Stap vier: de lettertypes en de CSS, door het aantal lettertypebestanden te beperken, ze op de site zelf te hosten en alleen de nodige stijlen te laden. Meet tussen elke stap, anders weet u niet welke heeft gewerkt.

Studies van de grote webspelers koppelen regelmatig een langere laadtijd aan een daling van de conversies. Die resultaten komen van sites met zeer veel verkeer en zijn niet zomaar over te zetten op een buurtwinkel; ze als universele wet aanhalen zou oneerlijk zijn.

Wat zich daarentegen op eender welke site laat vaststellen: een mobiele bezoeker op een gemiddeld netwerk die vijf seconden naar een wit scherm kijkt, heeft de tijd om terug te keren naar de zoekresultaten en de volgende concurrent te kiezen. Traagheid jaagt niet iedereen weg; ze jaagt een deel van de minst besliste mensen weg, en dat zijn precies degenen die een site moet overtuigen.

Om het bij u te meten, vergelijkt u het aandeel bezoekers dat de landingspagina zonder interactie verlaat vóór en na een correctie, bij vergelijkbare periode en verkeersbron. Dat is geen bewijs, maar wel een aanwijzing die eigen is aan uw site, veel nuttiger dan een percentage dat elders is gelezen.

Een gecorrigeerde site gaat achteruit vanaf de eerste zware afbeelding die zonder compressie wordt gepubliceerd of het eerste script dat ‘om te testen’ wordt toegevoegd. Prestaties zijn hygiëne, geen afgesloten project. Leg drie eenvoudige regels vast voor wie publiceert: elke afbeelding gaat door een automatische verkleining, elk nieuw script wordt schriftelijk verantwoord, elke nieuwe pagina wordt vóór publicatie op mobiel gecontroleerd.

Automatiseer wat kan. Een contentbeheersysteem of een moderne bouwketen kan afbeeldingen bij publicatie verkleinen en omzetten zonder tussenkomst. Een prestatiebudget — maximaal gewicht per pagina, maximaal aantal scripts — dat bij elke productie­release wordt gecontroleerd, stopt regressies voordat ze de bezoekers bereiken.

Bekijk ten slotte de praktijkgegevens één keer per maand. Ze evolueren met toestellen, netwerken en content; een metriek die langzaam naar de verkeerde kant schuift, wordt goedkoop rechtgezet zolang ze vroeg wordt opgemerkt.

Google raadt goede Core Web Vitals aan voor zoekresultaten en gebruikers. Google benadrukt tegelijk dat pagina-ervaring meer omvat dan deze metrieken en dat goede scores geen toppositie garanderen.

Verbeter snelheid daarom voor gebruikers en betrouwbaarheid. Combineer dit met nuttige content, een begrijpelijke structuur, mobiel gebruik, een beveiligde verbinding en het vermijden van storende interstitials.