Ontdek alle mogelijkheden met ApplePY. Bekijk alle features
In de zomer van 2021 heeft Google updates gegeven over de manier waarop zijnprioriteit bieden aan websites die geoptimaliseerd zijn voor de bezoekers. Deze update was bekend als de Core Web Citals, waarbij de update URLs beoordeeld op basis van snelheid, toegankelijkheid en visueie stabiliteit. En uiteindelijk ook SEO.
Hoewel een 100/100 score bijna onmogelik is, biedt Google wel de optie om een landingspagina te testen met de Pagespeed Insights. Het volgen van de uitkomsten van de test is echter geen garantie voor hogere posities. Echter, het opvolgen van deze suggesties is wel aan te raden.
Google scoort sites op basis van drie criteria: Largest Contentful Paint (LCP), First Input Delay (FID) en Cumulative Layout Shift (CLS). Dit artikel onderzoekt methoden die we nuttig hebben gevonden om elke categorie te verbeteren.
Het grootste element van de pagina. Om deze score te meten, identificeert Google het voglende:
De meest efficiënte manier om de LCP-score te verbeteren, is door de afbeeldingsgrootte en lazy loading te optimaliseren. Afbeeldingen en video's zijn doorgaans de grootste elementen die via de server worden verzonden, waardoor er een ernstig knelpunt kan ontstaan bij het laden van een website. Het optimaliseren van afbeeldingen is een relatief eenvoudige taak dankzij moderne libraries, diensten of websites.
De meeste content management systemen (CMS) zoals Wordpress en Sitefinity bieden ingebouwde tools om afbeeldingen te optimaliseren, maar je kunt ook gebruik maken van een tool, zoals Squoosh.
Een andere methode om te overwegen wanneer je de score wilt verbeteren, is lazy loading. Lazy loading is een methode die wordt gebruikt om het laden van alle niet-kritieke bronnen op een website uit te stellen.
Dit wordt over het algemeen toegepast op afbeeldingen, video's en iframes, maar kan voor een breed aan andere elementen worden gebruikt. De eenvoudigste manier om een afbeelding lazy te laden, is het gebruik van:
ApplePY voor online marketeers
ApplePY voor freelancers
ApplePY voor agencies
<img src=”image.jpg” alt=”...” laden=”lazy” />
Helaas is dit kenmerk geen functie in Safari voor iOS of MaOS. We hebben echter verschillende andere opties, zoals de Intersectie Waarnemer API of een library. Je kunt ook vanilla-lazyload gebruiken, waardoor je een aantal extra opties hebben. De library wordt dan geïnstantieerd in een Javascript-hoofdbestand met de volgende code en geeft je de mogelijkheid om een aangepaste selector te definiëren.
Het toepassen van de library op een element is eenvoudig - voeg een class toe met de waarde die is gedefinieerd door de eigenschap elements_selector.
<img src=”image.jpg” alt=”...” class=”lazy” />
Het verminderen van het aantal elementen dat op een pagina wordt geladen, zal de prestaties van de website en de LCP-score aanzienlijk verbeteren.
FID meet het tijdsverschil tussen de eerste interactie van een gebruiker met een pagina en het moment waarop de browser de event begint te verwerken. FID wordt voornamelijk beïnvloed door het aantal en de grootte van libraries van derden, de grootte van de Javascript- en CSS-bestanden van een website, het aantal verzoeken en het main thread.
Het optimaliseren van het laadproces van scripts van derden is best lastig, afhankelijk van het project, maar moderne tooling biedt de ontwikkelaar veel opties. Je kunt eerst overwegen om async of defer op de scripts toe te passen.
<script async src=”script.js”>
<script defer src=”script.js”>
Een scripttag met het async-kenmerk wordt zo snel mogelijk na het downloaden uitgevoerd. Het kenmerk defer wordt uitgevoerd nadat de HTML is geparseerd, maar voordat de gebeurtenis DOMContentLoaded wordt geactiveerd. Als je het script onmiddellijk nodig hebt, gebruik je async, anders is uitstellen handig voor bronnen die later kunnen worden aangeroepen.
Een ander kenmerk dat je kunt toepassen, is <preload>. Preload kan worden toegepast op verschillende typen content. Veel websites bevatten bijvoorbeeld lettertypen van Google Fonts. Als je het kenmerk preload gebruikt, wordt het lettertype zo vroeg mogelijk geladen, waardoor de kans kleiner wordt dat lettertypen worden verwisseld of de weergave wordt geblokkeerd.
Ten slotte is het minimaliseren van de grootte van Javascript- en CSS-bestanden van het grootste belang. Alle moderne programma's zoals Webpack, Parcel of Laravel zitten boordevol functies om minificatie, codesplitsing, chunking en boomschudden mogelijk te maken. Codesplitsing splitst de CSS- en Javsacript-bestanden op in meerdere bundels die parallel kunnen worden geladen, waardoor de algehele laadtijd wordt verkort. ‘Shaking Trees’ verwijdert oude code, of code die momenteel niet in gebruik is, uit deze bestanden, waardoor hun grootte wordt geminimaliseerd.
TailwindCSS en PurgeCSS worden gebruikt om alle onnodige styles te verwijderen die momenteel niet op een pagina worden gebruikt, waardoor de totale grootte van ApplePY werd teruggebracht van 45 kb naar 8 kb.
CLS is de meting van de visuele verschuiving van elementen op een pagina na het laden. Als de startpagina van een website bijvoorbeeld een grote afbeelding met een knop bevat, kan het lijken alsof de pagina stuitert totdat de afbeelding volledig is geladen. Advertenties, iframes, embedded content en animaties dragen ook bij aan een lagere CLS-score.
Om het verschuiven van content met afbeeldingen te voorkomen, geeft het verstrekken van een beeldverhouding voor afbeeldingen de browser de informatie die nodig is om ruimte voor de afbeelding te reserveren.
Gelukkig wordt dit in moderne browsers automatisch afgehandeld door de attributen width en height op een afbeelding te gebruiken. De browser neemt deze waarden, berekent de beeldverhouding en reserveert ruimte op de pagina voordat de afbeelding is geladen. Op dezelfde manier kun je placeholder-afbeeldingen gebruiken of een skeletlay-out maken.
<img src=”auto.jpg” width=”500” height=”300” alt=”Een snelle auto” />
Een van de grootste boosdoeners van het verschuiven van de lay-out zijn advertenties. Advertenties worden doorgaans geladen via een advertentiebibliotheek van derden, wat betekent dat ze mogelijk pas worden weergegeven als andere content op de pagina is geladen.
Het kan een uitdaging zijn om de grootte en/of plaatsing van advertenties te bepalen, zal het reserveren van ruimte voor een advertentie andere content op de juiste locatie plaatsen. Plaats indien mogelijk geen advertenties bovenaan de pagina, omdat hierdoor alle content eronder wordt verplaatst.
Andere elementen zoals een Google Map of iframe kunnen ook resulteren in een verschuiving, aangezien de grootte van de insluiting over het algemeen wordt bepaald bij het renderen. Bij het toevoegen van een Map aan een website reserveren we een vast gedeelte op een pagina totdat het script volledig is geladen.
Externe tools voor het testen van de sitesnelheid kunnen veel aanbevelingen bieden over hoe je de snelheid van de website kunt verbeteren. De tools die we regelmatig gebruiken zijn:
In dit artikel gebruiken we de gratis testtool DebugBear. Er zijn ook andere alternatieven die soortgelijke resultaten leveren, zoals WebPageTest of GTmetrix.
Chrome DevTools kan veel data leveren over hoe de website laadt. Testen op jouw eigen PC maakt het testresultaat echter sterk afhankelijk van de lokale omgeving. Een ander nadeel is dat je alle relevante caches handmatig moet wissen om de ervaring van een nieuw bezoek aan de website te ervaren.
PageSpeed Insights gebruiken we om snel een overzicht te krijgen van de snelheid van de website.
Je krijgt zowel echte data als suggesties over hoe je jouw website kunt versnellen op basis van een laboratoriumtest. Omdat er gebruik wordt gemaakt van gesimuleerde threads, zijn de labgegevens echter niet altijd nauwkeurig.
Het testen van de snelheid van een website met DebugBear duurt slechts enkele seconden. Een webprestatietest uitvoeren:
Laten we ingaan op enkele statistieken en (proberen) te begrijpen hoe je jouw website kunt versnellen. Streef naar een mobiele score van +75%.
Uit analyses blijkt dat websites die ranken in de TOP 3 een stabiele snelheid hebben. Dit percentage helpt je te begrijpen hoe goed een website presteert voor echte bezoekers.
Op basis van data die Google verzamelt van echte Chrome - gebruikers, geeft dit getal aan welk percentage gebruikers een goede ervaring op de website hebben gehad. Deze gegevens worden gebruikt als signaal voor Google. Streef naar minstens 75%.
Krijg een goed beeld van wat bezoekers daadwerkelijk ervaren als ze een website bezoeken. Je komt er bijvoorbeeld achter dat pagina’s pas later wordt ingeladen. Of dat het grootste element geen <preload> heeft, waardoor dit ten koste gaat van de LCP.
De strip op de tijdlijn toont de voortgang van de weergave van de website in de loop van de tijd.
Deze pagina begint bijvoorbeeld na 1,53 seconden te renderen en de hero-banner wordt na enkele seconden weergegeven.
De website wordt volledig gerenderd, ook wel Visually Complete genoemd, wanneer de afbeelding na 2,69 seconden wordt weergegeven.
Stel dat je een website aan het optimaliseren bent en wilt weten of deze wijzigingen effect zullen hebben.
Deze tool voert een laboratoriumtest uit in een optimale omgeving om te ontdekken of jouw website correct geoptimaliseerd is.
Wanneer je een website wilt testen, krijg je een officiële 'Lab Score', een samenvatting van zes prestatiestatistieken die afkomstig zijn van de prestatiescore van de Lighthouse-tool van Google:
Met behulp van deze data ontdek je hoe nuttig de laatste optimalisaties was en wat je mogelijk moet wijzigen.
Inmiddels vraag je je waarschijnlijk af wat je moet veranderen. Laten we eens kijken hoe we de website kunnen optimaliseren met behulp van elke belangrijke statistiek uit het overzicht.
Laten we beginnen door de website sneller zichtbaar te maken voor bezoekers: we gaan eerst dieper in op First Contentful Paint.
First Contentful Paint meet hoe snel de content van een pagina voor het eerst verschijnt nadat de bezoeker naar die pagina navigeert.
Het is belangrijk dat de belangrijkste content snel wordt weergegeven om te voorkomen dat een bezoeker de website verlaat. Hoe sneller een gebruiker de website verlaat, hoe sneller Google aangeeft dat de ervaring op de landingspagina slecht is.
Maar hoe weet je precies waardoor je website langzaam laadt? Hoe ontdek je welke serverproblemen je website vertragen?
De FCP kan worden beïnvloed door de snelheid van de server, serververzoeken en bronnen die de weergave blokkeren.
Je kunt dit heel snel analyseren door de zogeheten waterval. Deze handige tool laat zien welke verzoeken door de website worden gedaan en wanneer elk verzoek begint en eindigt.
In deze schermafbeelding zien we bijvoorbeeld eerst een verzoek om het HTML-document en vervolgens twee verzoeken om stylesheets te laden waarnaar in het document wordt verwezen.
Voordat de eerste elementen op de webpagina kunnen worden geladen, moet de browser van de gebruiker eerst verbinding maken met de server en de content ophalen.
Als dit proces lang duurt, duurt het lang voordat de gebruiker de website ziet. Jouw doel is om te leren wat er aan de hand is voordat de website begint te laden, zodat je problemen kunt lokaliseren en de ervaring kunt versnellen.
Voordat je voor het eerst een website opvraagt bij een server, moet de browser van de bezoeker een netwerkverbinding met die server tot stand brengen.
Dit duurt doorgaans drie stappen:
Deze drie stappen worden achtereenvolgens uitgevoerd door de browser. Elke stap vereist tijd van de browser.
In dit geval duurt het ongeveer 153 milliseconden om de serververbinding tot stand te brengen.
De browser vraagt om het HTML-document (time to first byte gebeurt hier). Zodra de serververbinding tot stand is gebracht, kan de browser van de bezoeker de HTML-code opvragen die de content van de website bevat. Dit wordt een HTTP-verzoek genoemd.
In dit geval duurt het HTTP-verzoek 102 milliseconden. Deze duur omvat zowel de tijd die is besteed aan de server als de tijd die is besteed aan het wachten op de server om een antwoord te genereren.
Na 251 milliseconden om de verbinding tot stand te brengen en 102 milliseconden om het HTTP-verzoek te doen, kan de browser van de bezoeker eindelijk beginnen met het downloaden van een HTML-request. Dit wordt Time to First Byte (TTFB) genoemd. In dit geval gebeurt dat na in totaal 758 milliseconden.
Nadat de reactie van de server klaar is, besteedt de browser van de bezoeker wat extra tijd aan het downloaden van de HTML-code. In dit geval is de respons vrij klein en duurt het downloaden slechts 10 milliseconden extra.
De website laadt extra bronnen voor weergaveblokkering. Browsers geven of tonen pagina's niet direct na het laden van het document. In plaats daarvan zijn er meestal extra bronnen die de weergave blokkeren.
De meeste pagina's zouden er slecht uitzien zonder visuele styling, dus CSS-stylesheets worden geladen voordat een pagina begint met renderen.
Het laden van de 2 extra stylesheets in dit voorbeeld van de snelheidstest van de website duurt 137 milliseconden.
Houd er rekening mee dat voor deze verzoeken geen nieuwe serververbinding nodig is. De CSS-bestanden worden geladen vanuit hetzelfde domein als voorheen en kunnen de bestaande verbinding opnieuw gebruiken.
De browser geeft de pagina weer. Als alle benodigde bronnen eenmaal zijn geladen, kan de browser van de bezoeker beginnen met het weergeven van de pagina. Het uitvoeren van dit kost echter ook enige verwerkingstijd.
Optimalisatie voor de kwaliteit van de gebruikerservaring is de sleutel tot het succes op lange termijn van elke website op internet. Meer informatie over Core Web Vitals.
TIP! Met ApplePY heb je heel veel extra scripts om topic clusters aan te maken. Maar ook nog meer dan 50+ andere scripts voor andere toepassingen. Er zijn talloze scripts en elke maand komen daar weer nieuwe scripts bij. Probeer ApplePY de eerste 7 dagen gratis.
Nu je begrijpt waardoor de website wordt weergegeven, kun je nadenken over hoe je deze kunt optimaliseren.
Nu de begindelen van de website sneller worden geladen, is het tijd om te concentreren op het sneller laden van de volledige website.
Er zijn veel manieren om de LCP te versnellen. Om het makkelijker te maken, geeft DebugBear de vervolgstappen onder hun sectie Aanbevelingen.
Laten we een paar voorbeelden van de aanbevelingen bekijken en leren hoe we het LCP van deze website kunnen versnellen.
Als het grootste contentelement op de pagina een afbeelding is, kun je het beste ervoor zorgen dat de URL rechtstreeks in het oorspronkelijke HTML-document is opgenomen. Dit zal helpen om het laden zo snel mogelijk te starten.
Deze best practice wordt echter niet altijd gebruikt en soms duurt het lang voordat de browser ontdekt dat het de hoofdafbeelding moet downloaden.
Oplossing: Afhankelijk van de website zijn er twee mogelijke oplossingen:
Na het laden van de HTML-code van een pagina, kunnen de browsers van de bezoekers zien dat naast de hoofdafbeelding mogelijk een groot aantal aanvullende bronnen, zoals stylesheets, moeten worden geladen.
Het doel hier is om ervoor te zorgen dat de grotere hoofdafbeelding wordt geladen om te voldoen aan de eis van Google voor LCP.
Andere bronnen, zoals third-party scripts, zijn niet zo belangrijk als de afbeelding above the fold (noemen ze ook wel hero-banner).
Bovendien staan de meeste afbeeldingen waarnaar wordt verwezen in de HTML van de website below the fold zodra de pagina is weergegeven.
Daarom stellen browsers in eerste instantie de prioriteit van alle afbeeldingen-requests in op Low. Zodra de pagina is weergegeven, zoekt de browser uit welke afbeeldingen belangrijk zijn en verandert de prioriteit.
Je kunt daar een voorbeeld van zien in de onderstaande schermafbeelding, zoals aangegeven door het sterretje in de prioriteitskolom.
De waterval laat zien dat hoewel de browser al vroeg van de afbeelding op de hoogte was, deze niet begon te downloaden, zoals aangegeven door de grijze balk.
Hoe op te lossen: om dit op te lossen, kun je een nieuwe browserfunctie gebruiken, fetch priority genaamd. Als je het kenmerk fetchpriority=”high” aan een img-element toevoegt, begint de browser de afbeelding vanaf het begin te laden.
Google heeft Core Web Vitals opgenomen in verschillende van zijn beste tools voor ontwikkelaars en webmasters. ApplePY beheert meerdere API-koppelingen om data te verzamelen per domeinnaam en per pagina.
