Dag 12: Je paginasnelheid boosten

Dag 12

Hallo.

Dag 12 alweer van onze SEO-cursus "SEO in 30 dagen".

Vandaag gaan we werken aan Pagina Snelheid.

Nu vraag je je misschien af:

"Hoe snel moet mijn pagina zijn?

Moet het sneller zijn dan een cheetah die achter zijn avondeten aan zit?"

Nou, nee...

Maar, hoe sneller je pagina laadt, hoe beter!

Dus hoe kunnen we meer snelheid bereiken?

Met onze magische toverstok genaamd WebSite Auditor, natuurlijk!

Laten we eens kijken hoe we dit gaan aanpakken.

Paginasnelheid is al eeuwen een positieve factor voor Google.

Nou ja, misschien niet eeuwen, maar sinds het eerste bericht in 2010.

Daarna kwamen ze met een update in 2018 en zetten ze de puntjes op de 'i' met de introductie van Core Web Vitals in 2020.

Vandaag kijken we naar:

wat is paginasnelheid nu precies, hoe meten we het en, het allerbelangrijkste, hoe verbeteren we die razendsnelle scores voor jouw website?

Wat is paginasnelheid?

Google zelf heeft lang zitten krabben achter de oren over het meten van paginasnelheid.

Wat zijn de juiste cijfertjes?

Gebruik je veldgegevens of labgegevens?

Klok je de hele pagina of alleen het topje van de ijsberg?

Er zijn tientallen maatstaven die meespelen in paginasnelheid en het was een ware ontdekkingstocht om erachter te komen welke daarvan echt belangrijk zijn voor de gebruiker.

Uiteindelijk heeft Google drie winnaars gekozen, nu gezien als de belangrijkste maten voor paginasnelheid:

• Largest Contentful Paint (LCP)
• First Input Delay (FID)
• Cumulative Layout Shift (CLS).

Samen bekend als de Core Web Vitals, zijn deze maatstaven bedoeld om de waargenomen paginasnelheid te meten, in plaats van de feitelijke paginasnelheid.

Largest Contentful Paint

De Largest Contentful Paint is de tijd die het kost voor het grootste element in het zichtbare gedeelte om volledig te laden. De normen voor deze maatstaf zijn als volgt:

LCP maatstaven

Vaak is het grootste element een afbeelding, dus beeldoptimalisatie is de hoofdrolspeler voor deze maatstaf.

Bovendien hangt LCP af van serverreactietijden, code die het renderen blokkeert, en client-side rendering.

Dat klinkt als abracadabra, toch?

Maar geen paniek, we gaan het allemaal ontrafelen.

First Input Delay

First Input Delay is de vertraging tussen het moment waarop een interactief element op de pagina verschijnt en het moment waarop het daadwerkelijk functioneert.

Stel je voor, er verschijnt een knop op de pagina, je klikt erop, maar hij is nog niet klaar om op jouw commando's te reageren.

De maatstaven voor deze meting zijn als volgt:

FID maatstaven

FID kan worden geoptimaliseerd door code op te splitsen en door minder JavaScript te gebruiken.

Het is in feite gewoon een kwestie van een beetje opruimen in de achterkant van je website.

Cumulative Layout Shift

Cumulative Layout Shift meet of de elementen op de pagina rondspringen tijdens het laden.

Stel je voor, een pagina lijkt klaar voor gebruik, maar dan verschijnt er een nieuwe afbeelding aan de bovenkant en wordt de rest van de inhoud naar beneden geduwd — dat is een layout verschuiving.

Het is alsof je op het punt staat een hap van je broodje te nemen, maar dan wordt de kaas plotseling vervangen door haring.

Bah!

De maatstaven voor deze meting zijn als volgt:

CLS benchmarks

CLS depends on properly set size attributes and on having your resources load in a specified sequence, top to bottom.

CLS maatstaven

CLS hangt af van de juiste instellingen voor je formaat attributen en het in een bepaalde volgorde laden van je bronnen,

van boven naar beneden.

Denk aan het opbouwen van een lego toren:

je wilt niet dat het blokje dat eigenlijk onderaan hoort, plots bovenaan verschijnt.

Chaos, toch?

Hoe meet je de paginasnelheid van je website?

Er zijn genoeg tools beschikbaar, allemaal met de hartelijke groeten van Google, die Core Web Vitals bevatten als onderdeel van hun pagina-audit:

Google tools voor het meten van Core Web Vitals

Eén klein probleempje is dat sommige van deze tools labgegevens gebruiken in plaats van veldgegevens, terwijl Google je pagina's beoordeelt puur op basis van die veldgegevens.

Het is een beetje als appels met peren vergelijken, en we weten allemaal hoe dat gaat, toch?

Je kunt deze tools herkennen doordat ze de FID-meting, die alleen in het veld wordt uitgevoerd, vervangen door de in het lab gemeten TBT-meting (Total Blocking Time).

Een ander probleempje is dat de meeste tools slechts één pagina tegelijk kunnen beoordelen, wat niet echt praktisch is als je je hele website wilt optimaliseren.

Van alle Google-tools die hierboven zijn genoemd, is waarschijnlijk Google Search Console de beste keuze.

Daar kun je naar Functionaliteit > Site Vitaliteit gaan en in één keer het rapport voor al je pagina's bekijken:

Core Web Vitals rapport in Google Search Console

Onder het rapport zie meer informatie over de status.

Problemen met Core Web Vitals in Google Search Console

En vanaf daar kun je het proces van uitspitten volgen om de specifieke problemen binnen elke meting te vinden, en vervolgens de pagina's die door het probleem worden beïnvloed.

Na een paar klikken beland je in het PageSpeed Insights rapport voor een specifieke pagina.

Hoewel het algemene rapport in bulk wordt aangeboden, kan het uitvogelen welke pagina's door welke problemen worden getroffen, een uitputtend proces zijn.

Het is alsof je een puzzel van 1000 stukjes moet oplossen terwijl je een blinddoek draagt.

Een misschien betere manier om de paginasnelheid te meten, is het gebruik van WebSite Auditor.

Daar kun je naar Site Structuur ► Site Analyse ► Page Speed gaan en een bulk rapport van de paginasnelheid voor je hele website krijgen, evenals alle getroffen pagina's bekijken — en dat allemaal vanaf één dashboard:

Core Web Vitals-rapport in WebSite Auditor

Of ga naar Site Structuur ► Pagina's ► Page Speed en bekijk de lijst met pagina's die te maken hebben met snelheidsproblemen die hen beïnvloeden.

Klik op een willekeurige pagina en je krijgt ook een lijst met pagina-elementen die kunnen worden geoptimaliseerd voor betere prestaties:

Core Web Vitals-rapport in WebSite Auditor

Over het algemeen vind ik WebSite Auditor handiger voor het eigenlijke werk van het optimaliseren van uw pagina's, terwijl Google Search Console meer een rapportagetool is.

How to improve page speed on your website?

Now that you have a list of affected pages, it’s time to work on improving your page speed. Below are some of the most common optimization opportunities as well as some advice on how you can exploit them.

Hoe verbeter je de paginasnelheid op je website?

Nu je een lijst met problemen pagina's hebt, is het tijd om te paginasnelheid te verbeteren.

Hieronder zie je enkele van de meest voorkomende optimalisatiemogelijkheden en advies over hoe je deze kunt benutten.

Afbeelding afmetingen instellen

Laten we beginnen met iets eenvoudigs. Wanneer u afbeeldingen afmetingen uit de code weglaat, kan het enige tijd duren voordat de browser de juiste afmetingen voor de afbeeldingen en video's heeft.

Dit betekent dat de inhoud op de pagina rondspringt en de CLS-score lager is.

Om dit probleem te voorkomen, stel je de breedte- en hoogte-eigenschappen voor de afbeeldingen in, zoals:

Met deze informatie kan elke browser de afmetingen van de afbeelding berekenen en voldoende ruimte op de pagina reserveren.

Dit zou de meeste, zo niet alle CLS-problemen moeten oplossen.

2. Serve images in next-gen formats

Not all image formats are created equal. Our trusty JPEG and PNG formats now have much worse compression and quality characteristics compared to AVIF, JPEG 2000, JPEG XR, and WebP.

Of these listed formats, WebP is probably the one to consider first. It supports both lossy and lossless compression, as well as allows for transparency and animation. On top of that, WebP files are generally 25% to 35% lighter than PNGs and JPEGs of similar quality. And although in the past it was a common concern that WebP format is not supported by some browsers, recently Safari has added the support for WebP in version 14, so the total support for the format among browsers is now over 90%.

If your website is built on WordPress, you can easily create a WebP copy of your images with an image optimization plugin like Imagify. If your website is not built on a CMS platform or you don't want to install too many plugins, you can convert your images using online converters or graphics editors.

Gebruik afbeeldingen in next-gen formaten

Niet alle afbeeldingsindelingen zijn even goed.

Onze vertrouwde JPEG- en PNG-indelingen hebben nu veel slechtere compressie- en kwaliteitskenmerken in vergelijking met AVIF, JPEG 2000, JPEG XR en WebP.

Van deze formaten is WebP waarschijnlijk degene die als eerste moet worden overwogen.

Het ondersteunt zowel lossy als lossless compressie, en maakt transparantie en animatie mogelijk.

Bovendien zijn WebP-bestanden over het algemeen 25% tot 35% lichter dan PNG's en JPEG's van vergelijkbare kwaliteit.

En hoewel het in het verleden een algemene zorg was dat het WebP-formaat niet door sommige browsers wordt ondersteund, heeft Safari onlangs de ondersteuning voor WebP toegevoegd in versie 14, dus de totale ondersteuning voor het formaat onder browsers is nu meer dan 90%.

Als jouw website op WordPress is gebouwd, kun je eenvoudig een WebP-kopie van de afbeeldingen maken met een plug-in voor afbeeldingen optimalisatie, zoals Imagify.

Gebruik je Joomla, dan zijn er ook veel extensies en templates die het omzetten naar WebP automatisch voor je kunnen regelen.

Als uw website niet op een CMS-platform is gebouwd of als je niet te veel plug-ins wilt installeren, dan kun je de afbeeldingen converteren met behulp van online converters of grafische editors.

3. Compress images

Whether you use next-gen image formats or not, compressing your images is still a valid way of reducing overall page size. Again, if your website is built on WordPress, you can compress your images in bulk with image plugins like WP Smush. You can also use online compressors if you don’t want to install too many plugins and risk slowing your website down. Last resort — use graphics editors to compress your images before uploading them to your website.

Just to give you an idea of how much you can save, I have run a quick test on a random selection of images from my download folder:

Comprimeer afbeeldingen

Of je nu next-gen afbeeldingsindelingen gebruikt of niet, het comprimeren van uw afbeeldingen is nog steeds een goede manier om de totale paginagrootte te verkleinen.

Nogmaals, als jouw website op WordPress of Joomla is gebouwd, kun je afbeeldingen in bulk comprimeren met afbeelding plug-ins.

Je kunt ook online compressoren gebruiken als je niet te veel plug-ins wilt installeren en het risico loopt je ​​website te vertragen.

Of gebruik grafische editors om afbeeldingen te comprimeren voordat je ze naar de website uploadt.

Om een idee te geven van hoeveel je kunt besparen, heb ik een snelle test uitgevoerd op een willekeurige selectie afbeeldingen uit mijn downloadmap:

Stel offscreen-afbeeldingen uit

Offscreen-afbeeldingen zijn de afbeeldingen die onder de vouw verschijnen, wat betekent dat de gebruiker ze pas ziet als hij voorbij het beginscherm scrolt.

En dit zal een gemeenschappelijk thema zijn in de rest van het artikel — het laden van alles dat zich onder de vouw bevindt, moet worden uitgesteld totdat elementen boven de vouw volledig zijn geladen.

Het gebied boven de vouw is wat Google gebruikt om uw paginasnelheid te meten, dus dit is waar je de meeste optimalisatie-inspanningen op moet richten.

Boven de vouw versus onder de vouw

De techniek om met offscreen-afbeeldingen om te gaan, wordt lazy loading (lui laden) genoemd.

Afbeeldingen boven de vouw worden eerst geladen en afbeeldingen onder de vouw worden alleen geladen als de gebruiker naar beneden scrolt op de pagina.

Raadpleeg deze handleiding over het lazy loaden van afbeeldingen voor meer informatie.

Converteer gifs naar video

HUH?

Het klinkt misschien raar, maar gifs hebben vaak een grotere bestandsgrootte dan video's.

Het slaat nergens op, maar het converteren van een grote gif naar een video kan een verkleining van wel 500% of meer opleveren.

Dus als uw paginasnelheid rapport aangeeft dat je videoformaten moet gebruiken voor geanimeerde inhoud, doe er dan wat mee!

Om gifs naar video's te converteren, kun je een online converter gebruiken of een tool zoals FFmpeg downloaden.

Google raadt eigenlijk aan om twee videoformaten te maken: WebM en mp4.

WebM is vergelijkbaar met WebP omdat het lichter is, maar nog niet door alle browsers wordt ondersteund.

Dus wanneer je de video aan de pagina toevoegt, moet je eerst de WebM-versie vermelden en vervolgens de mp4-versie als back-up:

Let op dat het video-element ook vier extra attributen heeft: autoplay, loop, muted en playsinline.

Deze kenmerken zorgen ervoor dat je video zich gedraagt ​​als een gif: hij begint automatisch te spelen, hij loopt door, zonder geluid en wordt inline afgespeeld.

Stel ongebruikte CSS uit

Ongebruikte CSS kan de constructie van de pagina door een browser vertragen.

Het punt is dat een browser de hele DOM-structuur moet doorlopen en moet controleren welke CSS-regels van toepassing zijn op elk knooppunt.

Hoe meer ongebruikte CSS er is, hoe meer tijd een browser nodig heeft om de stijlen voor elk knooppunt te berekenen.

Het doel hier is om de stukjes CSS te identificeren die ongebruikt of niet-kritiek zijn en deze volledig te verwijderen of de volgorde waarin ze worden geladen te wijzigen.

Raadpleeg deze gids over het uitstellen van ongebruikte CSS.

Verklein JS en CSS

JS- en CSS-bestanden bevatten vaak onnodige opmerkingen, spaties, regeleinden en stukjes code.

Als je ze verwijdert, kunnen de bestanden tot 50% lichter worden, hoewel de gemiddelde verkleining kleiner is.

Toch is het een bijdrage aan de paginasnelheid en het is het proberen waard.

Heb je een kleine website, dan kun je de code verkleinen met behulp van online minifiers, zoals CSS Minifier, JavaScript Minifier en HTML Compressor.

Is de website is gebouwd op een CMS-platform, zoals WordPress of Joomla, dan zijn er zeker enkele plug-ins die het werk voor je kunnen doen.

Raadpleeg voor een op maat gemaakte website deze gids over het verkleinen van CSS en deze over het verkleinen van JS.

Extraheer kritieke CSS

CSS is standaard een bron die de weergave blokkeert.

De pagina wordt pas weergegeven als de browser CSS-bestanden ophaalt en parseert, wat behoorlijk tijdrovend kan zijn.

Om dit op te lossen, kun je alleen die stijlen extraheren die nodig zijn voor het gebied boven de vouw van de pagina en deze toevoegen aan de van het HTML-document.

De rest van de CSS-bestanden kunnen asynchroon worden geladen.

Dit zal uw LCP-scores aanzienlijk verbeteren en ervoor zorgen dat uw pagina's sneller verschijnen voor de gebruikers.

Bekijk deze handleiding over het extraheren van kritieke CSS voor meer informatie.

Verbeter de responstijd van de server

Het vervelendste aan vertragingen in serverreacties is dat er veel oorzaken kunnen zijn.

Dit kunnen bijvoorbeeld trage routering, trage applicatie logica, uitputting van CPU-bronnen, trage database query's, geheugen uitval, trage frameworks, enz. zijn.

Een gemakkelijke oplossing voor deze problemen is overschakelen naar betere hosting, wat in veel gevallen betekent van gedeelde naar beheerde hosting.

Managed hosting wordt meestal geleverd met CDN-netwerken en andere trucs voor het leveren van inhoud die de paginasnelheid positief zullen beïnvloeden.

Maar als je je handen vuil wilt maken, vind je hier een meer gedetailleerde gids over het repareren van een overbelaste server.

JS van derden uitstellen / asynchroon laden

Bronnen van derden, zoals knoppen voor sociaal delen en ingesloten videospelers, zijn vaak erg belastend voor het verbruik van bronnen.

Bovendien, wanneer de browser een stukje JS tegenkomt, zal het de uitvoering van HTML onderbreken totdat het JS is afgehandeld.

Dit draagt bij aan een meetbare daling van de paginasnelheid.

Als een van de bronnen van derden niet-essentieel is, d.w.z. ze doen er niet toe voor het uiterlijk of de functie van boven-de-vouw, dan moet je ze uit het kritieke weergave pad verwijderen.

Om bronnen van derden efficiënter te laden, kun je het kenmerk async of defer gebruiken.

Het async-attribuut is zachter: het maakt gelijktijdig downloaden van HTML en JS mogelijk, maar het pauzeert nog steeds HTML om JS uit te voeren.

Het defer-attribuut weegt zwaarder - het zal HTML niet pauzeren om JS uit te voeren, wat alleen helemaal aan het einde zal worden uitgevoerd.

Async vs. defer attributes

Maak vooraf verbinding met bronnen van derden

Het tot stand brengen van verbindingen, vooral veilige, kost in de regel veel tijd.

Het punt is dat het DNS-lookups, SSL-handshakes, uitwisseling van geheime sleutels en communicatie met de uiteindelijke server vereist die verantwoordelijk is voor het verzoek van de gebruiker.

Dus om deze kostbare tijd te besparen, kun je van tevoren verbinding maken met de vereiste vertrekpunten.

Om de website vooraf te verbinden met een externe bron, hoef je alleen een link tag aan de pagina toe te voegen:

Nadat de tag geïmplementeerd is , hoeft de website geen extra tijd te besteden aan het tot stand brengen van een verbinding met de vereiste server, waardoor de gebruikers niet hoeven te wachten op verschillende extra rondreizen.

Lange taken opsplitsen

Wanneer er een stuk JavaScript is dat langer dan 50 ms nodig heeft om uit te voeren, kan het lijken alsof de pagina niet reageert op de gebruiker.

Om dit probleem op te lossen, wordt aanbevolen om deze lange taken op te zoeken, ze op te splitsen in kleinere segmenten en ze asynchroon te laten laden.

Op deze manier zijn er korte reactietijden ingebouwd in het laadproces van de pagina.

Je kunt Chrome DevTools gebruiken om lange taken te identificeren.

Dit zijn de taken die zijn gemarkeerd met rode vlaggen:

Lange taken in Chrome DevTools

Zodra je lange taken op je pagina's hebt geïdentificeerd, kun je ze opsplitsen in kleinere taken, de uitvoering ervan vertragen of ze zelfs van de hoofdlijn verwijderen.

Laad belangrijke bronnen vooraf

Het is aan browsers om te beslissen welke bronnen eerst worden geladen.

Daarom proberen ze vaak de belangrijkste bronnen zoals CSS te laden vóór bijvoorbeeld scripts en afbeeldingen.

Helaas is dit niet altijd de beste manier.

Door bronnen vooraf te laden, kun je de prioriteit van het laden van inhoud in moderne browsers wijzigen door hen te laten weten wat je later nodig zult hebben.

Met behulp van de tag kun je de browser laten weten dat er een bron nodig is als onderdeel van de code die verantwoordelijk is voor het weergeven van de inhoud boven de vouw, en ervoor zorgen dat deze de bron ophaalt zodra het mogelijk is.

Hier is een voorbeeld van hoe de tag kan worden gebruikt:

Houd er rekening mee dat de bron met dezelfde prioriteit wordt geladen.

Het verschil is dat de download eerder begint, omdat de browser van tevoren op de hoogte is van de preload.

Raadpleeg deze handleiding over het vooraf laden van kritieke onderdelen voor meer gedetailleerde instructies.

Gebruik browsercaching

Zonder browsercaching wordt elke keer dat je dezelfde pagina bezoekt, de hele pagina helemaal opnieuw geladen.

Bij browsercaching worden sommige pagina-elementen in het geheugen van de browser opgeslagen, zodat slechts een deel van de pagina van de server hoeft te worden geladen.

Uiteraard laadt de pagina veel sneller bij herhaalde bezoeken en gaan de algehele paginasnelheid scores omhoog.

Normaal gesproken is het doel om zoveel mogelijk paginabronnen zo lang mogelijk in de cache op te slaan en ervoor te zorgen dat bijgewerkte bronnen opnieuw worden gevalideerd voor caching.

Je kunt al deze parameters feitelijk beheren met speciale HTTP-headers die caching-instructies bevatten.

Een goede plaats om meer te weten te komen over HTTP-cache is deze gids van Google.

Verklein de DOM-grootte

Een te grote DOM-structuur met gecompliceerde stijlregels kan een negatieve invloed hebben op zaken als snelheid, looptijd en geheugenprestaties.

De best practice is om een ​​DOM-structuur te hebben, die in totaal minder dan 1500 knooppunten bevat, een maximale diepte heeft van 32 knooppunten en geen bovenliggend knooppunt met meer dan 60 onderliggende knooppunten.

Een zeer goede gewoonte is om de DOM-knooppunten te verwijderen die je niet meer nodig hebt.

Overweeg daarom om de knooppunten die momenteel niet worden weergegeven uit het geladen document te verwijderen en probeer ze pas te maken nadat een gebruiker een pagina naar beneden scrolt of op een knop drukt.

16. Avoid too many redirects

Getting rid of all unnecessary redirects is one of the best things you can do to your site speed-wise. Every additional redirect slows down page rendering and adds one or more HTTP request-response roundtrips.

The best practice is not using redirects altogether. However, if you desperately need to use one, it's crucial to choose the right redirect type. It’s best to use a 301 redirect for permanent redirection. But if, let's say, you're willing to redirect users to some short-term promotional pages or device-specific URLs, temporary 302 redirects are the best option.

Vermijd te veel omleidingen

Het verwijderen van alle onnodige omleidingen is een van de beste dingen die je voor de snelheid van de site kunt doen.

Elke extra omleiding vertraagt ​​de weergave van pagina's en voegt een of meer HTTP-verzoek-antwoord-roundtrips toe.

Het beste is natuurlijk om helemaal geen omleidingen te gebruiken.

Maar, als je er echt één moet gebruiken, is het van cruciaal belang om het juiste omleidingstype te kiezen.

Het is het beste om een ​​301-omleiding te gebruiken voor permanente omleiding.

Maar als u, laten we zeggen, gebruikers wilt omleiden naar kortetermijn promotie pagina's of apparaatspecifieke URL's, zijn tijdelijke 302-omleidingen de beste optie.

---

Nou, dat was een hele kluif.

Maar het is ook belangrijk voor Google en voor de bezoekers.

Je kunt het verbeteren van de pagina snelheid natuurlijk ook uitbesteden aan een webbouwer.

Maar nu weet je in ieder geval waar je op moet letten en kun je jouw provider simpel controleren.

Tot morgen!