PageSpeed Insights Diepgaande Analyse (Volledige Uitleg & Tips voor het Behalen van een Score van 100)

Op het internet is er geen snelheidslimiet – maar gelukkig is er wel een snelheidsmeter.

De snelheid en prestaties van jouw website hebben een grote invloed op je bedrijf. Het kan je zoekrangschikkingen en SEO verbeteren, de betrokkenheid bij de website verhogen en meer conversies – en omzet – stimuleren.

Maar voordat je de snelheid van je website kunt optimaliseren, moet je weten hoe deze presteert.

Daar komt PageSpeed Insights bij kijken.

Dit gratis hulpmiddel van Google helpt je de prestaties van je website te begrijpen, maar het kan ingewikkeld zijn om ermee te beginnen.

Tenslotte, wat betekenen al deze verschillende termen en scores? Hoe moet je weten wat je moet doen of waar je moet beginnen?

Deze gids richt zich op wat je moet doen met de resultaten van je PageSpeed Insights-rapport en hoe je strategisch kunt werken aan specifieke oplossingen om elk van je scores te verbeteren, ongeacht welke problemen moeten worden aangepakt!

Vandaag gaan we door alle belangrijke factoren en laten we strategieën zien om je prestaties voor elk daarvan te verbeteren.

Wat is Google PageSpeed Insights?

PageSpeed Insights is een tool die test, meet en rapporteert over de prestaties van je website. Het verzamelt essentiële gegevens over hoe gebruikers je site ervaren en ermee omgaan door zaken zoals snelheid van de site, laadtijd en gebruikerservaring te analyseren.

Naast het beoordelen van je website op een reeks belangrijke prestatie-indicatoren, voert PageSpeed Insights een reeks diagnostische tests uit en beveelt het specifieke actiepunten aan om de prestaties van je website te verbeteren.

PageSpeed Insights wordt aangedreven door Google’s open-source analyse-engine, Lighthouse.

Wat PageSpeed Insights met name belangrijk maakt voor webmasters en marketeers, is dat de prestaties van de site nauw verbonden zijn met de gebruikerservaring (UX), SEO, verkeer, conversies en alle andere KPI’s die het belangrijkst zijn voor het bedrijf.

Een score van 100% behalen op PageSpeed Insights is vergelijkbaar met het halen van een perfecte score op je SAT.

Het betekent niet noodzakelijk dat je het geweldig zal doen op de universiteit, maar het geeft je zeker een voorsprong.

Paginasnelheid en SEO

Laten we eerst de hoofdvraag beantwoorden.

Ja, de snelheid en prestaties van je website kunnen invloed hebben op zoekmachineoptimalisatie (SEO).

In het bijzonder kan slechte prestatie jouw SEO schaden. Het is handig om je PageSpeed Insights te beschouwen als een “gouverneur” voor je website. Als je scores laag zijn, betekent dit dat de website traag is – wat ook jouw groei in de SERPs (Search Engine Results Page) vertraagt!

Google heeft openbaar verklaard dat ze website snelheidssignalen gebruiken, die ze “page experience” noemen, als een SEO-classificatiefactor.

Er zijn drie centrale factoren opgenomen in het zoekalgoritme waar Google naar verwijst als Core Web Vitals:

1. Laden – Grootste Contentvolle Verf (LCP)
2. Interactiviteit – Vertraging Bij Eerste Invoer (FID)
3. Visuele Stabiliteit – Cumulatieve Layoutverschuiving (CLS)

Al deze factoren meten hoe snel je website laadt en de snelheid en kwaliteit van de gebruikerservaring, wat ook de toegankelijkheid kan beïnvloeden.

Deze drie factoren maken deel uit van de in totaal zes gemeten metrics door PageSpeed Insights.

Hoe PageSpeed Insights Werkt

Nu we weten wie, wat, waar en waarom… blijft alleen het hoe over.

Hoe werkt PageSpeedInsights, en hoe gebruik je de informatie die het biedt?

Eerst iets over hoe de tool achter de schermen functioneert, rechtstreeks van Google:

“PageSpeed Insights biedt zowel lab- als veldgegevens over een pagina. Labgegevens zijn nuttig voor het debuggen van problemen, aangezien ze worden verzameld in een gecontroleerde omgeving. Het kan echter geen real-world knelpunten vastleggen. Veldgegevens zijn nuttig om de echte, real-world gebruikerservaring vast te leggen – maar hebben een beperktere set aan metrics.”

Met andere woorden, PageSpeed Insights kijkt naar twee dingen.

Eerst laden de computers van Google jouw website om te zien hoe deze presteert.

Ten tweede, aangezien de computers van Google niet hetzelfde zijn als een laptop die je thuis of op het werk zou gebruiken, bekijken ze een logboek van historische gegevens van echte gebruikers die je site in de afgelopen 28 dagen hebben bezocht. (Deze gegevens zijn afkomstig uit het Chrome User Experience Report, vaak “CrUX” genoemd, en worden verzameld van gebruikers die de Chrome-browser gebruiken.)

Daarna combineert PageSpeed Insights deze twee tests en beoordeelt je website op basis van hoe echte gebruikers deze zouden ervaren.

De PageSpeed Insights Score is een verzameling van metingen over de prestaties van je site die aangeeft welke gebieden goed zijn en welke mogelijk verbetering behoeven.

Er zijn 6 scores om te weten:

1. Eerste Contentvolle Verf (FCP)
2. Vertraging Bij Eerste Input (FID)
3. Grootste Contentvolle Verf (LCP)
4. Cumulatieve Layout Verschuiving (CLS)
5. Interactie tot Volgende Verf (INP)
6. Tijd tot Eerste Byte (TTFB)

Elke van deze metingen wordt gemeten en vervolgens beoordeeld op basis van de prestatieniveau.

Wanneer je een PageSpeed Insights-rapport voor je site uitvoert, ontvang je een score en een “cijfer” voor elk hiervan, die in een van de drie categorieën zal vallen:

1. Goed
2. Voor Verbetering Vatbaar
3. Slecht

Deze beoordelingen worden bepaald door vooraf gedefinieerde reeksen die Google instelt:

Hoe Deze Gids Te Gebruiken Om Je PageSpeed Insights Score Te Verbeteren

Begrijpen van PageSpeed Insights is het eerste deel van de strijd.

Vervolgens moeten we uitzoeken hoe we alle scores, cijfers en suggesties kunnen vertalen naar een uitvoerbaar plan voor verbetering.

Hier is hoe je deze gids gebruikt:

• Voer je website PageSpeed Insights-rapport uit.
• Zoek naar mislukte CWV-tests of -metrieken aan het “Slechte” uiteinde van de schaal.
• Vind de sectie hieronder die betrekking heeft op die specifieke metrieken.
• Volg de stappen (gepresenteerd in volgorde van hoogste tot laagste impact).
• Voer het PageSpeed Insights-rapport opnieuw uit.
• Herhaal het proces indien nodig voor alle metrieken die nog steeds als “Slecht” zijn gemarkeerd.
• Ga naar de metrieken gemarkeerd als “Verbetering Nodig”.
• Herhaal vanaf het begin.

#1 – Eerste Contentful Paint (FCP)

Laten we duiken in de eerste metriek op Google’s lijst.

Het is de Eerste Inhoudelijke Verf, of FCP, en het meet hoe snel de gebruiker jouw website kan zien tijdens het laden.

Wat is First Contentful Paint?

First Contentful Paint (FCP) is de tijd die nodig is voor het eerste object om te laden in de browser van een gebruiker. Dit verschilt van de paginalaadsnelheid of laadtijd omdat het niet de tijd is die nodig is om de hele pagina te renderen — Het is slechts het eerste deel van de pagina dat op het scherm verschijnt.

Dit is belangrijk vanuit het perspectief van de gebruiker omdat ze vooruitgang kunnen zien terwijl de pagina begint te verschijnen.

Dit betekent ook dat de strategieën om FCP te versnellen uniek zijn ten opzichte van het simpelweg sneller laden van de hele pagina.

FCP wordt in seconden gemeten.

• Goed: < 1.8 seconden
• Verbetering nodig: 1.8 – 3 seconden
• Slecht: > 3 seconden

Technieken Om Fcp Te Verbeteren

Laten we zeggen dat je een FCP-score van 2,2s hebt behaald. Je hoopt dit te verlagen naar 1,8s.

Welke tools staan tot je beschikking?

Render-blocking-bronnen Minimaliseren

Onthoud, First Contentful Paint gaat niet alleen over hoe lang het duurt voordat de hele pagina is geladen. Het gaat erom de eerste pixels zo snel mogelijk op het scherm te krijgen.

Een belangrijke strategie is simpelweg het veranderen van de volgorde van inhoud op je pagina.

Laat de browser de belangrijkste tekst, afbeeldingen en stijlen eerst renderen voordat het begint met het laden van zware scripts, fancy animaties en inhoud die “onder de vouw” is.

Het eerste wat je moet doen: Verwijder alle ongebruikte stijlen of scripts van je pagina.

Als je JavaScript of CSS op de pagina laadt (meestal in het Head-gedeelte van de website), zal dit de FCP vertragen. Als je ze niet gebruikt, dan vertraagt het je alleen maar voor niets.

In WordPress kun je dit meestal bereiken door ongebruikte Plugins uit te schakelen, die mogelijk code op de pagina laden, zelfs als de Plugin niet wordt gebruikt of weergegeven.

Als je naar de resultaten in je PageSpeed Insights-rapport kijkt, zal het code markeren die in de pagina is geladen maar niet wordt gebruikt:

Dit zou je moeten vertellen welke code of plugins je veilig kunt verwijderen.

(Opmerking: alleen omdat code niet op één pagina wordt gebruikt, wil nog niet zeggen dat het niet op andere pagina’s van je website staat! Wees voorzichtig voordat je begint te hakken en snijden in je pagina’s.)

Volgende: Stel uit of laad scripts asynchroon.

Als je scripts of styling op je pagina nodig hebt, maar ze zijn niet direct essentieel voor de eerste inhoud die de gebruiker ziet, dan kun je ze uitstellen of asynchroon laden. Dit geeft de browser de opdracht om te wachten met laden in plaats van ze te laden in de volgorde waarin ze op de pagina verschijnen.

Dit is vrij eenvoudig — Je kunt een beetje extra code aan je website toevoegen die de browser instrueert om het laden uit te stellen of asynchroon te laden (of beide):

<script src="app.js" async></script>

(Nerdaantekening: Async en defer zijn technisch gezien niet precies hetzelfde. Maar, voor de meesten van ons, is het verschil voornamelijk semantisch. Voel je echter vrij om dieper in te duiken en meer te ontdekken over de subtiele nuances.)

Als je op zoek bent naar een makkelijkere manier om deze stap te beheren, overweeg dan het gebruik van de JetPack Boost plugin voor WordPress.

JetPack is een gratis pluginsuite die je allerlei hulpmiddelen biedt om de snelheid en prestaties van je website te optimaliseren. Opmerkelijk is dat je ervoor kunt kiezen om het laden van niet-essentiële JavaScript uit te stellen met een simpele klik.

Vanuit WordPress ga je naar Plugins > Nieuwe toevoegen.

Zoek dan naar Boost. Klik op “Installeren” en “Activeren”.

Je zou een nieuw menu in je linker navigatie moeten zien genaamd “JetPack”.

Ga naar JetPack > Boost.

De plugin zal je site op de achtergrond renderen en je score tonen, plus opties voor verbetering. Om niet-essentiële JS uit te stellen, klik je simpelweg op de schakelaar om deze in te schakelen.

Eindelijk: Herstructureer CSS (styling).

Als je bekend bent met CSS, weet je dat het gebruikelijk is om al je stijlen in één grote codeblob te gooien en alles te laden in een standaardbestand zoals style.css.

Het is niet verkeerd. Het is gewoon niet erg performant.

Om FCP te verbeteren, kun je jouw CSS-structuur optimaliseren:

1. Verwijder alle stijlen die van toepassing zijn op inhoud die deel uitmaakt van de FCP (alles “boven de vouw.”)
2. Voeg deze stijlen toe als een inline stijlblok in de header van je website.
3. Laad de overige stijlen asynchroon met een “preload” functie (hieronder getoond.)

<link rel="preload" href="styles.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="styles.css"></noscript>

Als alternatief, als je veel aparte stijlen hebt voor verschillende apparaten en browsers, wil je misschien je stylesheet opsplitsen in meerdere bestanden en een media query @import gebruiken om alleen de geschikte stijlen te laden.

Optimaliseren Van Afbeeldingen En Video’s

Aangezien FCP voornamelijk gaat over optimalisatie voor de eerste paar honderd pixels bovenaan de pagina, gaan we hier niet te veel in detail over optimalisatie voor afbeeldingen en video’s.

Maar als je koptekst veel afbeeldingen bevat of je hebt een video bovenaan de pagina, dan kan het de moeite waard zijn om te onderzoeken hoe je deze elementen kunt optimaliseren om de initiële laadsnelheid te verbeteren. Zie hieronder voor meer details over hoe je het optimaliseren kunt aanpakken.

Een Content Delivery Network (CDN) Gebruiken

Zelfde als hierboven. CDN’s kunnen helpen je hele pagina sneller te laden, wat een kleine boost geeft aan FCP. Zie hieronder voor meer details over het gebruik van een CDN.

#2 – Eerste Input Vertraging (FID), Totale Blokkeertijd (TBT), en Tijd tot Interactief (TTI)

Laten we nu praten over compromissen.

Als je alleen aandacht besteedt aan First Contentful Paint, zou je kunnen denken dat alles wat je hoeft te doen om je PageSpeed Insights-score te verbeteren, het uitstellen is en al je bronnen later laden om dat bovenste deel van je website snel te laten laden.

Maar als de website snel lijkt te laden, maar ik er niet echt mee kan interageren, dan is dat ook een slechte gebruikerservaring.

Voer in: Eerste Inputvertraging.

First Input Delay houdt ook verband met de Total Blocking Time (TBT) en Time to Interactive (TTI) metingen.

Laten we elk van deze uitpakken en hoe ze gerelateerd maar verschillend zijn.

Wat Is First Input Delay?

First Input Delay (FID) is de tijd die het kost voor de browser om te reageren op een eerste input of interactie van de gebruiker (bijv. het klikken op een link of knop). De prestaties van je website beïnvloeden de vertraging omdat de meeste interacties niet kunnen worden verwerkt terwijl de browser code laadt of weergeeft.

Met andere woorden, als jouw code lang duurt om te laden, zal dit voorkomen dat de gebruiker met de website kan interacteren, en er zal een vertraging of wachttijd zijn tussen het moment dat ze klikken en wanneer de actie plaatsvindt.

Deze metriek wordt gemeten in milliseconden en is gebaseerd op echte gebruikersgegevens.

• Goed: < 100ms
• Verbetering nodig: 100 – 300ms
• Slecht: > 300ms

Wat is Time to Interactive (TTI)?

Time to Interactive is de tijd die nodig is om de pagina “betrouwbaar interactief” te maken.

Google definieert “betrouwbaar interactief” als wanneer de hoofdthread van de browser minstens 5 seconden vrij is, waardoor de pagina volledig interactief wordt voor de gebruiker.

Dit is een door Google’s Lighthouse gemeten metric, dus het is niet gebaseerd op daadwerkelijke gebruikersgegevens. In plaats daarvan wordt het gemeten onder specifieke, gecontroleerde criteria.

Wat Is Totale Blokkeertijd (TBT)?

Total Blocking Time meet de volledige periode tussen FCP en TTI.

Met andere woorden, de klok begint pas te lopen als de bovenkant van de pagina is weergegeven, en stopt nadat de pagina als “betrouwbaar interactief” wordt beschouwd of 5 seconden nadat de hoofdthread vrij is.

Vertraging Eerste Input vs Tijd tot Interactief vs Totale Blokkeringstijd

Deze drie statistieken zijn gerelateerd maar niet identiek.

First Input Delay is gebaseerd op echte gebruikersgegevens en Core Web Vitals. TTI en TBT worden gemeten door het prestatierapport in PageSpeed Insights, mogelijk gemaakt door Google’s Lighthouse.

Wat betreft het verbeteren van de prestaties van deze drie metrieken, zijn de oplossingen ook vergelijkbaar maar niet identiek. Met name oplossingen voor het verbeteren van FID die het uitstellen van JavaScript-rendering inhouden, zullen TTI of TBT niet verbeteren omdat JavaScript nog steeds geladen moet worden.

Maar oplossingen zoals verwijderen, verkleinen en cachen moeten helpen om alle drie de metingen te verbeteren.

Technieken Om FID, TTI en TBT Te Verbeteren

Verreweg de grootste invloed op FID is de JavaScript die op je pagina wordt geladen.

Je kunt JavaScript zien als een aparte treinbaan voor de browser. Terwijl het JavaScript-code rendert of uitvoert, kan het geen andere taken voltooien of reageren op invoer zoals een gebruiker die op een link klikt (de “hoofdthread” moet vrij zijn zodat de browser kan reageren).

Dus hoe langer het duurt om de JavaScript te lezen en uit te voeren bij het eerste laden van de pagina, hoe langer de vertraging zal zijn als de gebruiker begint te interacteren met de pagina.

Verminder de Impact van Code van Derden

Een veelvoorkomende oorzaak van trage invoerreactie is dat de website nog steeds allerlei tools van derden, widgets en apps aan het laden is.

Elke keer dat je dingen zoals Facebook, Drift, Intercom, HotJar of andere tools en diensten van derden toevoegt aan je website, wordt er een stukje code toegevoegd dat geladen en weergegeven moet worden op de pagina.

Als je veel van deze diensten hebt, kan het lang duren om ze allemaal te laden.

Nog erger, je hebt geen enkele controle over hoe snel deze bronnen worden geladen op je site. Dus als de browser probeert wat JavaScript op te halen van een website van een derde op een trage server, kan dit aanzienlijke vertragingen veroorzaken.

Laten we het repareren.

Optie #1: Verwijder alle ongebruikte externe tools.

Waarschijnlijk heb je in de loop der jaren allerlei diensten, plugins en tools op je website geïnstalleerd. En je gebruikt er waarschijnlijk maar een paar van.

Het is nu tijd om degene die je niet actief gebruikt te verwijderen of te de-installeren.

Om een volledige lijst te krijgen van de JavaScript van derden die op je pagina wordt geladen, raadpleeg je rapport van PageSpeed Insights of voer een apart Lighthouse rapport uit.

Je zou een lijst moeten zien van alle scripts die worden geladen en hoe lang ze duren:

Nu, met deze informatie, kun je beslissen welke hiervan cruciaal zijn en welke veilig verwijderd kunnen worden.

Afhankelijk van welke diensten je wilt verwijderen, moet je mogelijk handmatig de code van je website verwijderen, een WordPress plugin deïnstalleren, of code verwijderen die via Google Tag Manager is toegevoegd om de pagina prestaties te verbeteren.

Optie #2: Laad JavaScript asynchroon.

Tenzij het essentieel is voor het renderen van de FCP, is het bijna altijd raadzaam om scripts van derden asynchroon te renderen. Als je essentiële JavaScript hebt die FID vertraagt maar je het niet kunt verwijderen, dan kun je proberen het asynchroon te laden.

De Uitvoeringstijd Van JavaScript Minimaliseren

Code van derden kan een schurk zijn, maar wat dacht je van onze eigen code die we op onze website hebben gezet?

De kans is groot dat het een rol speelt in de trage laadtijd.

Als je niet-essentiële JavaScript hebt toegevoegd aan je eigen website, wil je deze misschien verwijderen.

Als je naar het PageSpeed Insights-rapport kijkt, moet je een sectie zien die verwijst naar ongebruikt JavaScript:

• Als de JavaScript 100% ongebruikt is, overweeg dan om het te verwijderen
• Als de JavaScript op andere pagina’s wordt gebruikt, overweeg dan om het selectief alleen op de pagina’s te leveren waar het nodig is (ook bekend als “code splitting“)

Je kunt ook opties verkennen om de laadtijd van de JavaScript te verbeteren.

De meest voorkomende manier om de laadtijd te versnellen, is door de bestandsgrootte te verkleinen. En met JavaScript zijn er twee hoofdstrategieën:

• Minificatie – Het verwijderen van alle spaties, regeleinden, etc. in de code
• Compressie – Het “zippen” van het bestand om het kleiner te maken

Een van deze kan helpen om je code beter te laten presteren.

Zichtbare Inhoud Prioriteren

Als je vooral bezorgd bent over het verbeteren van FID, dan wil je misschien de focus leggen op het uitstellen van JavaScript en andere pagina-elementen om alleen te focussen op inhoud binnen de eerste contentful paint.

Uiteindelijk kunnen gebruikers niet interageren met elementen die niet zijn weergegeven.

#3 – Grootste Inhoudelijke Verfbeurt (LCP)

Als FCP de 0 tot 60 tijd van je auto is, dan is LCP de kwartmijl.

Oke, voor de niet-techneuten, wat ik bedoel is dat LCP meet hoe snel de gebruiker de “hoofd” inhoud op je webpagina kan zien.

Wat is Largest Contentful Paint?

Largest Contentful Paint (LCP) is een meetwaarde die bepaalt hoe lang het duurt voordat het grootste inhoudsblok op een pagina zichtbaar is voor de gebruiker. In tegenstelling tot FCP kijkt het naar de laadtijd van het grootste blok afbeelding of tekst op de pagina, ongeacht de positie of volgorde ervan.

Het meet het grootste blok inhoud op basis van de afmetingen binnen het zichtveld van de gebruiker. Met andere woorden, als er een enkele <div> is met veel tekst of een enkele afbeelding die een groot deel van het scherm inneemt, kan dat worden beschouwd als het grootste blok inhoud en gebruikt worden om de LCP te berekenen.

Het wordt gemeten in seconden en is gebaseerd op gegevens van echte gebruikers (of “in het veld”):

• Goed: < 2.5s
• Verbetering Nodig: 2.5 – 4s
• Slecht: > 4s

Technieken Om LCP Te Verbeteren

Voordat je begint met het optimaliseren van je LCP, wil je misschien bepalen welk deel van je pagina wordt beschouwd als het grootste inhoudsblok.

Dit kan je helpen om je inspanningen te richten op het verbeteren van de prestaties op een specifieke pagina of sjabloon.

Je kunt dit doen door Chrome DevTools in je browser te gebruiken om de LCP-bron te identificeren op een specifieke pagina.

Optimaliseer Laadprioriteit

In de bovenstaande secties hebben we opties besproken zoals het gebruik van asynchrone of uitstelstrategieën om het renderen van belangrijke delen van de pagina te versnellen.

Je wilt misschien deze hier als eerste optie overwegen.

Het verwijderen of uitstellen van render-blokkerende bronnen kan helpen om de hoofdinhoud sneller te laden. Maar onthoud dat als deze bronnen de lay-out of structuur van de pagina aanzienlijk veranderen, dit daadwerkelijk kan veranderen welk blok als het grootste wordt beschouwd en LCP kan vertragen in plaats van verbeteren!

Je kunt deze strategie nog een stap verder nemen. Vooral als het grootste blok content een afbeelding is.

Je kunt wat bekend staat als een PRPL (Preload, Render, Precache, Lazy load) framework toepassen om specifieke bronnen op je pagina te richten en als eerste in de wachtrij te laden. Als die afbeelding het grootste inhoudsblok is, dan zal het je LCP-score aanzienlijk verbeteren.

Naast asynchrone renderingsopties biedt dit framework andere strategieën voor het optimaliseren van het renderingpad.

Een van de eenvoudigste is het vooraf laden van cruciale middelen.

Je kunt dit doen door gewoon een klein stukje code toe te voegen aan de kop van je website die de browser instrueert om kritieke afbeeldingen, lettertypen, stijlen of scripts te prioriteren, die cruciaal kunnen zijn voor je grootste inhoudssectie.

Bijvoorbeeld, als je een hero-afbeelding hebt die het grootste blok op de pagina is, dan wil je misschien die afbeelding op elke pagina vooraf laden met een fragment zoals dit:

<link rel="preload" as="image" href="image1.png">

Dit vertelt de browser om deze bron meteen te beginnen laden, voordat deze op de pagina ontdekt wordt.

Optimaliseer Bestand (Resource) Grootte

Laten we nu over bestandsgrootte praten.

Grotere bestanden hebben langer nodig om te laden. Dit geldt voor afbeeldingen, scripts, video’s, lettertypen en alles wat op je pagina kan worden geladen als onderdeel van het grootste inhoudsblok.

Een manier om je LCP-score te verbeteren is optimalisatie van bestandsgrootte.

Strategieën voor het optimaliseren van bestandsgrootte zijn afhankelijk van het bestandsformaat.

Afbeeldingen Optimaliseren

Veelal zul je grote voordelen vinden door je afbeeldingen te comprimeren en te optimaliseren.

Begin met het evalueren van deze gebieden voor verbetering:

• Formaat: Verschillende afbeeldingsformaten bieden variërende niveaus van compressie en kwaliteit. Voor de meeste webgebruikssituaties zijn JPEG, PNG en WebP de meest gangbare formaten.
  • JPEG is meestal het beste voor foto’s.
  • PNG is meestal het beste voor ontworpen afbeeldingen met tekst of scherpe randen.
  • WebP is een efficiënter formaat dat betere compressie biedt zonder kwaliteitsverlies, maar het wordt mogelijk niet door alle browsers ondersteund.
• Compressie: In veel gevallen kun je de bestandsgrootte van een afbeelding comprimeren zonder veel of enige zichtbare kwaliteit te verliezen.
  • Online afbeeldingscompressietools: TinyPNG (voor PNG en JPEG), Squoosh (voor WebP).
  • WordPress afbeeldingscompressietools: ShortPixel, Imagify.
• Afbeeldingsgrootte: Als je ruwe afbeeldingen of foto’s naar je website uploadt en vervolgens aan je pagina toevoegt, zijn ze waarschijnlijk veel groter dan nodig, wat de laadtijd vertraagt.
  • Pas je afbeeldingen aan en upload alleen de grootte die je nodig hebt.
  • Gebruik een WordPress plugin om afbeeldingen automatisch te verkleinen na het uploaden.
  • Gebruik de “srcset” en “sizes” attributen in de “img” tag om meerdere afbeeldingsbronnen en -formaten te specificeren. De browser kiest automatisch de meest geschikte afbeelding op basis van de schermgrootte en resolutie van de gebruiker.

Scripts En Stijlen Optimaliseren

Alle bronnen die nodig zijn om het grootste inhoudsblok weer te geven, moeten volledig geladen zijn voordat de LCP berekend wordt.

Dit omvat scripts en stijlen die invloed hebben op je grootste inhoudsblok.

Door gebruik te maken van enkele technieken die we eerder hebben besproken, kun je LCP verbeteren door de bestandsgrootte en het renderpad voor JavaScript, CSS, enz. te optimaliseren:

• Minimaliseer de bestanden.
• Code opsplitsen om bestandsgrootte te verminderen.
• Voeg stijlen en scripts in-line toe.
• Pre-load of cache.

Video’s Optimaliseren

Als je LCP-bron een video kan zijn, dan moet je overwegen hoe je video’s kunt optimaliseren.

• Host de video op YouTube of een andere service met een snelle CDN in plaats van deze rechtstreeks te uploaden.
• Comprimeer de bestandsgrootte van de video.

Lettertypen Optimaliseren

Als de LCP-bron in kwestie tekst is en die tekst een geïmporteerd lettertype gebruikt (bijvoorbeeld van Google Fonts), dan kun je optimaliseren door de laadsnelheid van het lettertypebestand te verbeteren.

• Gebruik alleen WOFF en WOFF2.0 lettertypebestanden voor het web.
• Laad het lettertypebestand vooraf met een link rel tag (zie hierboven).
• Verken meer opties voor het verder verkleinen van de laadtijd van lettertypebestanden.

Implementeer Een CDN

Denk aan een CDN als een carpoolstrook op de snelweg.

Het helpt de browser om bronnen sneller te downloaden door ze te cachen op servers over de hele wereld.

Het belangrijkste wat je moet weten is dit: Het implementeren van een CDN kan de prestaties van een website over de hele linie aanzienlijk verbeteren. En vooral als het op LCP aankomt, kan het helpen om afbeeldingen, scripts en andere middelen sneller te renderen dan de normale server van je webhost.

Om een CDN te implementeren:

• Selecteer Een CDN-Provider: Er zijn verschillende populaire CDN-providers beschikbaar op de markt, zoals Cloudflare, Amazon CloudFront, Google Cloud CDN, en Fastly.
• Richt Een Account In En Configureer De CDN: Nadat je een CDN-provider hebt geselecteerd, maak je een account aan en configureer je de CDN-instellingen. Dit omvat doorgaans het creëren van een CDN-zone, het configureren van cache-regels, en het instellen van SSL/TLS-encryptie.
• Integreer De CDN Met Je Website: Om de CDN te integreren met je website, moet je de URL’s van de inhoud die je via de CDN wilt serveren bijwerken. Dit houdt in dat je de nameservers wijzigt zodat ze naar de CDN wijzen in plaats van naar je normale server.
• Test De CDN: Nadat je de CDN hebt geïntegreerd met je website, voer je tests uit om te verzekeren dat de inhoud via de CDN wordt geserveerd en dat de LCP-prestatie is verbeterd.

Voor een uitgebreidere handleiding, bekijk ons artikel over het gebruik van een CDN met WordPress.

Verbeter Serverprestaties

Als laatste, maar zeker niet onbelangrijk, speelt de serverprestatie van je webhost ook een sleutelrol in LCP.

We zullen dit volledig behandelen als we dieper ingaan op TTFB; het is voldoende om te zeggen dat de browser alleen maar bronnen zo snel kan downloaden als de server toelaat. Als het veel tijd kost voor de server om te reageren, zal het ook veel tijd kosten om de bron te laden.

#4 – Cumulatieve Lay-outverschuiving (CLS)

Wist je dat websites kunnen dansen?

Nou, soort van. En niet erg goed.

Nauwkeuriger gezegd, ze kunnen verschuiven. De elementen op de pagina bewegen terwijl verschillende afbeeldingen, scripts, stijlen en tekst worden weergegeven totdat de pagina volledig geladen is.

Wat Is Cumulatieve Layout Verschuiving?

Cumulatieve layoutverschuiving meet hoe ver de afbeeldingen, tekst, knoppen en andere elementen op je pagina verplaatsen op het scherm terwijl de gebruiker wacht tot de pagina is geladen. Een lagere CLS wordt als beter beschouwd voor de gebruikerservaring.

Dat is niet echt verrassend als je je eigen surfgedrag overweegt.

Als je het gevoel hebt dat je een spelletje ‘mollen meppen’ speelt terwijl je probeert op een link te klikken die steeds verder naar beneden op de pagina verschuift, raak je waarschijnlijk gefrustreerd en verlaat je de site helemaal. (Hallo, bouncepercentage!)

Deze ervaring kan vooral frustrerend zijn tijdens het browsen op een mobiel apparaat.

CLS is veldgegevens van echte gebruikers, en het wordt gemeten als een score die de “impactfractie” (welk percentage van elementen in het viewport verschoven is) en “afstandsfractie” (hoe ver ze zijn verplaatst ten opzichte van de totale grootte van het scherm) combineert.

Er is ook een speciale aanduiding voor “verwachte verschuivingen” (bijvoorbeeld het klikken op een knop die een nieuw gedeelte op de pagina opent) en “onverwachte verschuivingen”, die niet door gebruikersinput worden veroorzaakt.

CLS wordt gemeten door de impactfractie en afstandsfractie te vermenigvuldigen:

• Goed: < 0.1
• Verbetering Nodig: 0.1 – 0.25
• Slecht: > 0.25

Technieken Om CLS Te Verbeteren

De kans is groot dat als je je gebruikers niet opzettelijk probeert te misleiden door dingen op je pagina te verplaatsen, je CLS standaard vrij laag is, maar er zijn een paar onschuldige fouten die je kunt maken en die de moeite waard zijn om te corrigeren.

Definieer De Maten Van Alle Afbeeldingen En Video’s

Eén klein ding met een grote impact. Als je de grootte van de afbeeldingen en video’s op je pagina niet expliciet definieert, kan dit leiden tot een verschuiving in de lay-out omdat de browser niet zeker weet hoeveel ruimte hij moet reserveren voor die bron.

Dit is net zo eenvoudig als het toevoegen van het attribuut voor elke afbeelding of video op de pagina:

<img src="hero_image.jpg" width="400" height="400">

Vermijd Advertenties en Pop-ups Die Lay-outverschuivingen Veroorzaken

Je moet op een of andere manier de rekeningen betalen, maar vermijd het gebruik van pop-ins of pop-ups die de paginalay-out veranderen. Gebruik anders een CSS aspect ratio box om ruimte te “reserveren” voor advertenties of andere berichten die geladen worden op de pagina terwijl de gebruiker interactie heeft.

Kies Animaties Zorgvuldig

Met moderne CSS en JavaScript kunnen we allerlei coole en fancy animaties op de pagina implementeren.

Maar, vanuit het perspectief van de gebruiker, gaat functie altijd boven vorm.

Verwijder alle animaties die lay-outwijzigingen activeren, aangezien elke veranderingsstatus kan bijdragen aan de algehele lay-outverschuiving en je CLS-score kan beïnvloeden.

#5 – Interactie Tot Volgende Schilderbeurt (INP)

Zoals Jay-Z ooit zei, “Ik heb geen geduld. En ik haat wachten.”

Doen we dat niet allemaal?

Hoewel we de invoervertraging bij de eerste interactie met je website (FID) al hebben besproken, is INP een bredere metriek die de algehele responsiviteit van je website beoordeelt.

Wat Is Interactie Tot De Volgende Schilderbeurt?

Interactie tot Volgende Weergave meet hoe lang het duurt voordat de volgende “weergave” of bijgewerkte frame op je website verschijnt nadat de gebruiker een knop of pagina-element heeft aangeraakt. Het meet de algehele responsiviteit van de website en hoe vloeiend de interacties aanvoelen.

Dit is vooral belangrijk voor webapps die aanzienlijke gebruikersinteractie vereisen en traag en verwarrend kunnen aanvoelen als er te veel tijd zit tussen de invoer en de reactie of vertraging tussen de actie en het resultaat.

INP wordt gemeten in milliseconden:

• Goed: < 200ms
• Behoeft Verbetering: 200 – 500ms
• Slecht: > 500ms

Technieken Om INP Te Verbeteren

Als je problemen met INP hebt, vind ik dat erg voor je, zoon. (Sorry, dat is een andere songtekst van Jay-Z.)

Gelukkig kun je de meeste problemen onderverdelen in drie hoofdproblemen:

1. Vertraging bij invoer
2. Vertraging bij interactie
3. Vertraging bij presentatie

Dit is het echt lastige deel; Om het probleem nauwkeuriger te diagnosticeren, moet je Google Chrome’s prestatieprofiel of de opnamefunctie van Lighthouse gebruiken.

Hier kun je inzoomen op een individuele interactie en zien waar de langste vertraging optreedt.

Vanaf daar kunnen we naar enkele oplossingen voor elk probleem zoeken.

Vertraging Bij Invoer Oplossen

Inputvertraging wordt veroorzaakt wanneer de hoofdthread bezig is op het moment van de interactie. Dit betekent dat er iets anders gebeurt wanneer de klik of toetsaanslag plaatsvindt.

Om dit op te lossen, wil je onderzoeken welke processen deel uitmaken van de hoofdthread:

• Verwijder of optimaliseer JavaScript van derden.
• Gebruik web workers om JavaScript buiten de hoofdthread uit te voeren.
• Gebruik listeners zoals isInputPending() om de hoofdthread vrij te geven (dit is de meest geavanceerde optie.)

Vertraging Bij Interactie Oplossen

Als de interactie zelf de boosdoener is – wat betekent dat het lang duurt voordat de interactie daadwerkelijk wordt uitgevoerd – dan moet je de code voor deze invoer herstructureren.

De belangrijkste aanbeveling hier is om niet-essentiële berekeningen uit te stellen.

Met andere woorden, voer het deel van de interactie uit dat de gebruiker direct ziet en verwacht. Voer daarna, na het bijwerken van het frame, eventuele andere berekeningen of interacties achter de schermen uit.

Stel je voor dat de gebruiker op een knop klikt die een venster opent en ook een gebeurtenis registreert waaruit blijkt dat ze op de knop hebben geklikt. Je zou willen dat je code het venster eerst opent, waarmee je de interactie “voltooit” vanuit het perspectief van de gebruiker.

Log dan, eenmaal de interactie is voltooid, de gebeurtenis die de gebruiker niet direct zal zien of ervaren.

Vertraging Bij Presentatie Oplossen

Het is mogelijk dat zowel de invoer als de interactie vrij snel gebeuren, maar het duurt lang voordat de browser de presentatie met het nieuwe frame bijwerkt.

Helaas zal er niet veel herstructurering helpen bij dit probleem.

Maar een paar dingen kunnen een langere dan normale vertraging veroorzaken:

• Overmatig gebruik van requestAnimationFrame(). Elke keer dat deze functie wordt aangeroepen, ontstaat er een kleine vertraging. Kijk dus naar gevallen waarin het te vaak of onnodig gebruikt kan worden.
• “Async” attributen die mislopen. Afhankelijk van de context kunnen sommige bronnen die je hebt gemarkeerd voor asynchrone weergave de instructie negeren of onverwachts laden. Als dat gebeurt, zal het andere onderdelen van het renderpad vertragen en het volgende frame.

#6 – Tijd Tot Eerste Byte (TTFB)

Nu denken we aan dat allereerste moment waarop een webpagina laadt.

Voordat de pagina zelfs maar kan beginnen met renderen, moet de browser van de gebruiker contact maken met de webserver, uitzoeken met wie hij verbinding maakt, en instructies krijgen over wat in welke volgorde te laden.

Die initiële handdruk bevat de eerste byte aan informatie. Hoe snel die byte aankomt is als het pistoolschot bij de start van een paardenrace.

Wat Is Time To First Byte?

Time to First Byte is de tijd die je browser nodig heeft om processen zoals DNS-zoekopdracht, TCP en SSL-handshakes, en verbindingsopzet te doorlopen om de eerste bytes informatie van een webserver aan te vragen – en te ontvangen. De snelheid waarmee een verbinding met de webserver wordt gelegd, is bijna volledig afhankelijk van de server zelf en hoe de website wordt gehost.

Het wordt gemeten in milliseconden:

• Goed: < 800ms
• Verbetering Nodig: 800 – 1800ms
• Slecht: > 1800ms

Technieken Om TTFB Te Verbeteren

Je kunt TTFB zien als de tijd die je doorbrengt aan de startlijn voordat het startpistool afgaat. Alles wat de initiële groenlicht vertraagt, zal tijd toevoegen aan TTFB en de algehele paginalaadtijd.

Dus wat zijn je opties voor verbetering?

Verwijder Omleidingen

Allereerst, elimineer paginadoorverwijzingen waar mogelijk. Als je gebruikers doorstuurt van de ene naar de andere pagina, valt de tijd die het kost om dit uit te voeren binnen het TTFB-venster, wat betekent dat je een aanzienlijke hoeveelheid tijd aan je score toevoegt.

Dit omvat 301-omleidingen van oude URL’s naar een nieuwe, evenals tijdelijke omleidingen en andere implementaties.

Upgrade Je Web-Hosting

Hosting speelt een enorme rol in de algehele snelheid en prestatiescore van je website, vooral als het gaat om TTFB.

Je wilt kijken naar de specificaties van je webhostingprovider, let daarbij goed op zaken zoals:

• Shared versus Dedicated Hosting: Is je website gehost op een eigen instantie of deelt het middelen met andere gebruikers en hun websites? Dedicated Hosting kost meestal meer maar biedt consistentere prestaties.
• Geheugen (RAM): Het geheugen waartoe je site toegang heeft op de server speelt een grote rol in de algehele prestatie. Als het geheugen maximaal gebruikt wordt, kan de server niet meer reageren op nieuwe verzoeken.
• CPU / Processor: De snelheid van de server’s processor speelt ook een rol in de reactiesnelheid en verwerkingstijd.
• Infrastructuur updates: Wordt de software die op de server draait up-to-date gehouden en vrij van fouten of conflicten? Update naar de nieuwste versies van PHP, MySQL, en andere essentiële applicaties om de prestaties te maximaliseren.

Implementeer Caching

Op zogenaamde “dynamische websites”, zoals sites die op WordPress draaien, kan het cachen van je pagina’s enorme verbeteringen aanbrengen in de laadtijden van pagina’s en TTFB.

Caching betekent in wezen dat in plaats van elke keer informatie uit de database van je site te halen wanneer een pagina wordt geladen, de site een kopie van de pagina opslaat en die aan de gebruiker levert. Het is veel sneller dan elke keer informatie opzoeken.

Voor een uitleg over hoe dit werkt, lees onze gids voor website caching.

Een Opmerking Over De Snelheidsindex

We hebben geen aparte sectie over de Speed Index-metriek opgenomen in deze handleiding, omdat dat in wezen de totale laadtijd van de pagina meet.

Dit betekent dat het aanpakken van Speed Index-problemen meestal een kwestie is van het aanpakken van de andere gerelateerde metrieken die we al hebben besproken:

• Eerste Inhoudsrijke Verf
• Grootste Inhoudsrijke Verf
• Interactie tot Volgende Verf
• Tijd tot Eerste Byte

Elk zal een kleine rol spelen in de cumulatieve paginasnelheid en het direct aanpakken ervan zou je algehele Speed Index-score moeten verbeteren.

Laatste Gedachten Over PageSpeed Insights

In deze handleiding hebben we vrijwel alles besproken wat er te weten valt over het PageSpeed Insights-rapport en hoe je strategisch elk mogelijk probleem kunt aanpakken.

Altogether verwacht ik dat pagina-prestaties, toegankelijkheid en technische beste praktijken steeds belangrijker zullen worden. We bouwen samen het web – één website per keer – en dat vereist dat we allemaal investeren in het open, toegankelijk en mooi houden van het web.

Neem De Leiding Met Flexibele VPS Hosting

Hier is hoe de VPS-aanbieding van DreamHost zich onderscheidt: 24/7 klantenondersteuning, een intuïtief panel, schaalbare RAM, onbeperkte bandbreedte, onbeperkte hostingdomeinen en SSD-opslag.

Kies Je VPS Plan

Brian Glassman