WPO-gids om de snelheid van je website te optimaliseren

Wat is WPO?

Web Performance Optimization, wat we WPO noemen, is simpelweg de optimalisatie van de verschillende processen die invloed hebben op hoe een website laadt.

Hoe meet je de laadsnelheid van een website?

Er zijn voldoende tools om laadsnelheid te meten. De populairste zijn:

• ›

  Google Page Speed

• ›

  Lighthouse

• ›

  GTMetrix

Voordat je een audit start, is het belangrijk om in gedachten te houden dat de laadsnelheid voor elke gebruiker varieert. Verschillende variabelen kunnen invloed hebben op hoe de snelheid aanvoelt voor een gebruiker in Cuenca versus een in Ottawa.

Daarom raden we aan om in plaats van te werken aan laadtijden in seconden, je te focussen op het optimaliseren van:

• ›

  Websitegewicht (MB)

• ›

  Verzoeken

• ›

  Serverresponstijd

Als we deze 3 gebieden verbeteren, zal de laadsnelheid verbeteren ongeacht waar de gebruiker zich bevindt.

We duiken in elk gebied en, via de verschillende tools, zien we hoe we eraan kunnen werken om de prestaties van elke URL te verbeteren. Waarom zeg ik elke URL? Omdat, hoewel het misschien voor de hand liggend lijkt, ik veel gevallen ben tegengekomen waarin alleen de homepagedata werd geëvalueerd, en natuurlijk, laadt elke pagina op een site niet dezelfde resources.

Google Developer Tools

Voordat we beginnen, wil ik enkele opties uitleggen die Google biedt via zijn developer tools. Deze tool is een van de belangrijkste voor het analyseren van hoe een website werkt. Klik met de rechtermuisknop op de pagina die de browser geopend heeft en er verschijnt een paneel met verschillende opties. We gaan naar Inspect (Ctrl + Shift + I).

Zodra die tool open is, gaan we naar de NETWORK-optie die je bovenaan vindt. Als we opnieuw op ENTER drukken in de browser, zal de tool de laadtijd van de verschillende resources tonen.

Onderaan in de afbeelding kunnen we de data zien die we interessant vinden voor een algemeen overzicht van hoe de site laadt.

Als we dieper graven in dit paneel vanaf de bovenkant en naar de kolomstructuur kijken, hebben we:

• ›

  Name: de naam van de resource.

• ›

  Status: de responscode van de resource (200, 301, 404...)

• ›

  Type: het type resource (script, font, png, jpg, stylesheet...)

• ›

  Initiator: welke resource het verzoek triggert.

• ›

  Time: hoe lang het verzoek duurde.

• ›

  Waterfall: een grafische weergave van de laadtijden van een resource.

Als we met de rechtermuisknop bovenaan klikken, kunnen we kolommen met deze informatie toevoegen en verwijderen.

Het inschakelen van extra informatieve elementen zoals Domain, Scheme of Cookies kan in specifieke gevallen helpen om resources te lokaliseren die ons enig probleem zouden kunnen veroorzaken, maar op dit punt blijven we bij degene die vooraf gedefinieerd zijn.

Er is één aspect dat, hoewel zeer interessant, ik slechts kort zal aanstippen zodat we het in gedachten houden. Verbindingssnelheid, vooral op mobiel, is een sleutelelement van hoe een site laadt. Vanuit deze tool kunnen we tragere snelheden simuleren zoals 3G op mobiel.

Hoe ken je het gewicht van een URL en hoe verminder je het?

Gewicht, of het nu in Megabytes of Kilobytes is, is een van de belangrijkste redenen waarom een URL tijd nodig heeft om te laden. Daarom beginnen we door dieper in te gaan op dit aspect, want het zal het pad uitstippelen om een goede optimalisatie op onze site te bereiken.

De volgende data komt van de hierboven genoemde tool, GTMETRIX, en correspondeert met een website die ik op het punt sta te beginnen optimaliseren.

We gaan ons focussen op de data in de rechterkolom, degene die verwijst naar (Page Details), specifiek de Total Page Size.

Op het eerste gezicht ligt het gewicht van deze site ver boven het gemiddelde, maar houd in gedachten dat wat ertoe doet niet het totaalgewicht van de site is, maar hoe lang dat gewicht erover doet om te laden, omdat er iets bestaat genaamd Lazy Load, een functie die het laden uitstelt totdat de gebruiker de resource nodig heeft. We zullen er later over praten.

We kunnen deze informatie ook vinden in de developer tools, in het paneel dat we hierboven hebben bekeken, dat ik je nogmaals zal herinneren.

Als je onderaan kijkt, komen zowel de 7,5 MB als de 215 verzoeken zeer dicht bij de cijfers die door GTMETRIX worden gerapporteerd. Het is belangrijk dat je weet waar GTMETRIX zijn informatie vandaan haalt voor het geval je ooit een andere tool wilt gebruiken.

Laten we nu kijken wat zo zwaar weegt en hoe we het kunnen oplossen.

De Waterfall-optie biedt een visuele kijk op hoe resources laden, met de URL van de resource, status, domein en de Size-kolom. Als we op die laatste kolom klikken sorteert het de gewichten van groot naar klein en van klein naar groot.

Als we naar de gewichten kijken, kunnen we zien, zoals in de meeste gevallen gebeurt, dat afbeeldingen grotendeels verantwoordelijk zijn voor het buitensporige gewicht van de URL.

Er is geen formele specificatie voor het maximumgewicht dat een afbeelding zou moeten hebben, maar we raden niet meer dan 100 KB aan en, als je de optie hebt (als je Photoshop gebruikt heb je die), stel afbeeldingen in om progressief te laden als JPG en vermijd PNG telkens wanneer je geen Alpha-kanaal (transparantie) nodig hebt.

Door het gewicht van afbeeldingen te verminderen zullen we de laadtijd van de site aanzienlijk verbeteren, en er zijn verschillende tools die je kunt gebruiken. Persoonlijk optimaliseer ik met Photoshop, maar er zijn interessante online opties:

• ›

  https://imagecompressor.io/compress

• ›

  https://kraken.io/web-interface

Zowel GTMetrix als de Google-tool laten ons resources per type bekijken, dat wil zeggen alleen afbeeldingen, scripts, CSS...

Dit is nuttig voor een breder perspectief op waar te werken. Op deze URL maken afbeeldingen 4 MB van de 7,2 MB uit, dus een groot deel van het gewichtsprobleem zit daar. Toch zijn er andere resources die opvallen als extreem zwaar voor hun type, zoals een CSS-bestand van meer dan 700 KB en een Script van meer dan 300 KB.

Op dit punt wil ik verduidelijken dat wanneer we een laadsnelheidsoptimalisatie (WPO) uitvoeren, we bepaalde problemen onder ogen moeten zien die, hoewel ze oplossingen hebben, niet binnen ons bereik liggen om op te treden.

In dit geval zien we een zeer groot CSS-bestand. Als de ontwerper een CSS van meer dan 700 KB heeft gemaakt, zal het optimaliseren van dat specifieke bestand moeilijk zijn.

Wat kunnen we doen om het gewicht van deze bestanden te verminderen?

Minify (CSS, JS en HTML)

Minificatie is een proces dat probeert het gewicht van bestanden te verminderen door onnodige data te verwijderen zoals commentaar, spaties, herhaalde code en ongebruikte code. Er zijn veel tools om dit proces uit te voeren, behalve voor het ongebruikte code-gedeelte, dat moeilijker is om te optimaliseren en zou vereisen om handmatig in het bestand te gaan (iets wat ik niet aanraad).

Tools om bestanden te minificeren

• ›

  HTML Minifier http://kangax.github.io/html-minifier/

• ›

  CSS Nano https://cssnano.co/

• ›

  Uglify http://lisperator.net/uglifyjs/

Gelukkig hebben we het over WordPress, en zoals we allemaal weten is het in WordPress zeer zeldzaam om geen plugin te vinden die deze operatie afhandelt.

Persoonlijk gebruik ik graag een volledig gratis plugin, Autoptimize, en een betaalde, WP Rocket.

In dit artikel wil ik niet zozeer uitleggen hoe deze plugins werken, maar hoe je de optimalisatietaken uitvoert. Want als we andere plugins gebruiken, hebben die ook deze opties, en het beste is om te begrijpen wat we doen.

Minificeren met WP Rocket

Dit deel is niet complex. We gaan gewoon naar het tabblad bestandsoptimalisatie en vinken het vakje minify HTML aan. In WP Rocket wordt deze optie hieronder herhaald voor CSS- en JS-bestanden. Toch raad ik aan om dit vakje in te schakelen en te testen. Herhaal deze optie één voor één, want als er iets mis gaat is het gemakkelijker om het probleem te lokaliseren.

Voordat we het effect van minificatie controleren moeten we de cache wissen, anders zien we het resultaat van de bijgewerkte HTML niet.

Hoe wis je de browsercache?

Dit soort plugins komt met opties om de cache te wissen, die we bovenaan kunnen zien.

Een andere manier is via de browser, zodra Google Developer Tools is ingeschakeld (Ctrl + Shift + I).

Klik met de rechtermuisknop op de "reload page"-pijl en selecteer "empty cache and hard reload."

Minificeren met Autoptimize

Met Autoptimize is de optimize-actie wat de minificatie uitvoert, met de bijzonderheid dat het een optie biedt om HTML-commentaar te behouden. Deze commentaren worden meestal toegevoegd door ontwikkelaars om informatie te bewaren die in de toekomst nuttig kan zijn.

Om te controleren of deze optimalisatie effect heeft gehad, gaan we naar de broncode van de URL en zouden we zoiets als dit moeten zien:

De code wordt onleesbaar maar zijn functionaliteit is dezelfde.

Deze opties herhalen zich op dezelfde manier in WP Rocket en Autoptimize voor CSS- en JS-bestanden. Zoals ik eerder al noemde, raad ik niet aan om alles tegelijk te optimaliseren, maar 1 voor 1. Deze plugins bewaren kopieën van de geminificeerde bestanden, dus terugkeren naar het origineel is mogelijk door het bijhorende vakje uit te vinken.

Om het paginagewicht verder te verminderen hebben we 2 meer opties:

• ›

  Verwijder of verminder plugins die CSS of JS toevoegen aan de lading.

• ›

  Verwijder of trim ongebruikte code uit het CSS-bestand.

Deze 2 opties zijn complexer en vereisen meer kennis, want je moet voorzichtig zijn en ervoor zorgen dat er geen oproepen zijn vanaf andere pagina's naar het deel dat je verwijdert.

Hoewel het verwijderen van plugins niet altijd mogelijk is vanwege de resource die ze bieden, zijn er plugins die beter geoptimaliseerd zijn dan andere, wat betekent minder verzoeken en lichtere JS. Dus in het prachtige WordPress-ecosysteem is er bijna altijd een alternatief.

Laadtijd vs responstijd

Nu is het tijd om te praten over verzoeken, responstijd en laadtijd. Op dit punt moeten we een fundamenteel onderdeel van het proces vermelden: de server. Serveroptimalisatie is meestal niet aan ons, dus het is belangrijk om een efficiënte oplossing te kiezen.

Maar laten we het stap voor stap doen.

Wat is een verzoek?

Een verzoek, of HTTP Request, is een oproep van de client naar de server om een bepaalde resource te vragen. Verzoeken kunnen verschillende servers raken.

Verzoeken kunnen zowel HTTP als HTTPS zijn. Als we naar de structuur van een verzoek kijken, kunnen we analyseren waar de vertraging in tijd plaatsvindt.

Analyse van een HTTP-verzoektijd

Laten we uiteenzetten wat we zien in deze timing-grafiek.

• ›

  Het verzoek wordt gestart maar geblokkeerd of in de wachtrij geplaatst: Als de blokkade lang duurt kan dat te wijten zijn aan verschillende redenen: verzoeken met hogere prioriteit of veel verzoeken naar deze origin.

• ›

  DNS Lookup: de browser is het IP-adres van het verzoek aan het oplossen.

• ›

  Connecting: de tijd die het kost om verbinding te maken met de server om het verzoek op te lossen. Als deze tijd hoog is, kan dit duiden op netwerkproblemen, verbindingsfouten of een overbelaste server.

• ›

  Sending: het resourceverzoek wordt verzonden.

• ›

  Waiting: dit is de tijd die de server nodig heeft om een verzoek op te lossen en een respons te sturen; als het lang is, is er een probleem op de server.

• ›

  Receiving: ontvangen van de resource.

Een HTTPS-verzoek voegt nog één stap toe, hier weergegeven.

Deze twee screenshots horen bij twee verschillende sites, een niet-geoptimaliseerde (HTTP Request) en een andere geoptimaliseerde (HTTPS Request).

Als je goed kijkt en vergelijkt, zit het grootste verschil in de wachttijd. In deze gevallen zou je de server in meer detail moeten analyseren.

Serververzoeken: hoe kunnen we ze verminderen?

Zoals we hebben gezien, is het aantal verzoeken nauw verbonden met de laadtijd, dus het verminderen van het aantal verzoeken zou de laadtijden van een URL verbeteren. Gezond verstand speelt een rol in het optimalisatieproces en weten of een resource echt nuttig is voor de gebruiker of ons bedrijf. Dit is het moment om afscheid te nemen van bepaalde resources die niets toevoegen, maar ik ben niet degene die dat beslist.

Toch hebben we opties om verzoeken te verbeteren, zelfs als deze acties geen enorme verandering brengen in de laadtijd van de site. Ik herhaal mezelf: het beste is om resources te verwijderen die niets toevoegen.

CSS en JS combineren

Een andere populaire actie bij het optimaliseren van een webpagina is het combineren van CSS- en JS-resources, maar wat betekent dat?

Het doel van combineren is om verzoeken te verminderen ten koste van het verhogen van het bestandsgewicht. Combineren betekent het verenigen van de verschillende CSS- of JS-resources tot één enkele.

Als de responstijden lang zijn, kan combineren voordelig zijn. Als de verzendtijden zeer traag zijn, is een andere techniek misschien beter.

Het ideale is om te combineren met een goede server, zodat we aan beide kanten winnen.

Resources combineren met WP Rocket en Autoptimize

De combineer-operatie met deze plugins is zo eenvoudig als eerder. We vinken gewoon het bijhorende vakje aan.

In WP Rocket zijn de opties voor het combineren van CSS en JS hetzelfde; de panelen zijn praktisch identiek. Zoals we in de afbeelding zien, is er een vakje voor het toevoegen van het pad van bestanden die we niet willen combineren.

Onder het selectievakje zien we ook een opmerking over het niet gebruiken van de combineer-optie als we HTTP/2 gebruiken. Dit artikel legt meer uit over HTTP/2.

Autoptimize biedt meer opties om met CSS te werken en verzoeken te verminderen. In de optie die ik aangeef, combineert het en geeft het je een waarschuwing over het effect dat het kan hebben, maar uiteindelijk is dit altijd relatief.

In dit eerste deel van het artikel wilde ik uitleggen waar bepaalde basisacties uit bestaan, degene die we meestal in praktisch alle WPO-optimalisatieplugins zien, maar er is nog veel dat we kunnen doen om zowel verzoeken als laadtijden te verbeteren.

Cache-configuratie

Zonder twijfel is cache-optimalisatie een van de acties waar we de grootste verbeteringen zullen merken in hoe een site laadt. In dit artikel over SEO voor WordPress heb ik uitgelegd hoe de cache werkt. Ik moedig je aan om eens te kijken om te begrijpen hoe het werkt.

Autoptimize en WP Rocket voeren cache-acties uit, maar WP Rocket geeft je een paar meer opties. Het is de moeite waard te vermelden dat plugins deze optimalisatie hebben omgezet in iets eenvoudigers: je hebt nauwelijks een paar opties en het proces is snel en pijnloos.

Zoals je ziet, laat WP Rocket je werken aan 4 dingen:

• ›

  Caching inschakelen voor mobiele apparaten.

• ›

  Bestanden apart opslaan voor mobiele apparaten.

• ›

  Caching inschakelen voor ingelogde gebruikers.

• ›

  De tijd specificeren om de cache te wissen.

Het hangt af van elk project welke optie te selecteren, maar met dit alles in gedachten is mijn advies:

• ›

  Mobiele cache altijd, want hoewel de meeste sites responsive zijn, is er content die je op mobiel kunt hebben maar niet op desktop.

• ›

  Bestanden apart.

• ›

  Geen cache voor ingelogde gebruikers, vooral omdat als ik bewerkingen doe ik geen caching wil.

• ›

  Cache-tijd, die afhangt van hoeveel veranderingen je aan je site maakt. Als het een dagelijkse nieuwssite is, kort; als het content is die niet vaak wordt bijgewerkt, langer.

Lazyload

De lazyload-functie helpt resources (Afbeeldingen en Iframes) weer te geven wanneer de gebruiker ze nodig heeft; dat wil zeggen, de browser laadt deze resources niet totdat de gebruiker er naartoe scrollt. Deze functie is geïmplementeerd in veel plugins en komt zelfs voor-geconfigureerd in sommige WordPress-thema's. Vanaf Chrome-versie 76 komt het zelfs nativ in de browser.

Dit betekent dat door het loading="lazy"-attribuut toe te voegen, de browser al het lazy laden van de afbeelding interpreteert, maar natuurlijk zal niet elke browser dit interpreteren, dus ik raad aan de plugin te blijven gebruiken. Hier is een video gehaald van web.dev die een voorbeeld toont van waar lazy loading van afbeeldingen over gaat.

Iframe-optimalisatie

Als we iframes gebruiken om content van andere sites in te bedden, hebben we twee acties die we kunnen gebruiken om onze lading te verbeteren.

• ›

  Lazy loading via de lazyload-functie

• ›

  Of het iframe vervangen door een afbeelding totdat de gebruiker erop klikt.

Zowel de eerste als de tweede optie kunnen worden ingeschakeld via, alweer, onze go-to plugin WP Rocket.

Autoptimize heeft dit deel niet maar biedt de installatie van een aanvullende plugin om het te doen https://wordpress.org/plugins/wp-youtube-lyte/

Uitgesteld laden van JS-bestanden met Defer of Async

JS-bestanden zijn een van de boosdoeners van wat snelheidsaudits render blocking van een pagina noemen. Dit gebeurt wanneer de browser tijdens het renderen stopt om een JS-bestand te downloaden en het uit te voeren. Het doel van WPO-optimalisatie is om informatie zo snel mogelijk aan de gebruiker te leveren, daarom wordt dit als blokkerend beschouwd, want er wordt niets gerenderd totdat de gedownloade JS wordt uitgevoerd.

Daarom wordt dit type actie meestal gemarkeerd in de audit. Bij het gebruik van plugins van derden of thema's die niet goed geoptimaliseerd zijn, kunnen we JS hebben dat het renderen blokkeert omdat het bijvoorbeeld in de header staat.

In deze gevallen moeten we twee attributen gebruiken die worden toegevoegd in de JS-aanroepcode, Defer en Async. Voor deze attributen om te werken, moeten de scripts extern zijn.

Bij SEO Alive gebruiken we de plugin Pre Party Resource Hints, waarmee je kunt selecteren welke bestanden en welke laadmethode je wilt toepassen. Een wonder!

Wat is het verschil tussen Defer en Async?

Hoewel beide attributen een vergelijkbaar doel hebben, namelijk voorkomen dat de DOM HTML-interpretatie wordt gestopt door de JS, is er een opmerkelijk verschil tussen de twee.

Met het Async-attribuut wordt de resource gedownload zonder het laden van HTML te stoppen, maar zodra het is gedownload, wordt het laden van HTML gepauzeerd om de JS uit te voeren; met het defer-attribuut wordt de resource ook gedownload parallel met het laden van HTML, maar het draait wanneer het laden klaar is, dus er is geen blokkering door het script.

In dit opzicht zijn er verschillen tussen WP Rocket en Autoptimize. WP Rocket maakt beslissingen veel gemakkelijker voor je en handelt op een semi-automatische manier om te voorkomen dat JS rendering blokkeert; in Autoptimize daarentegen kun je alleen de Async-optie aan/uit zetten.

In Autoptimize, onder het tabblad extra hebben we deze optie om de JS-bestanden toe te voegen die we willen laden met Async, maar voor meer flexibiliteit raden ze een andere aanvullende plugin aan, "Async Javascript".

Met deze plugin kunnen we werken met zowel Defer als Async, en het biedt zelfs één-klik-opties om dingen gemakkelijker te maken. Het goede aan deze plugin is dat we kunnen werken met scripts en degene uit kunnen sluiten die we noodzakelijk achten. In WP Rocket daarentegen moeten we vertrouwen op wat de plugin doet, hoewel hij het goed doet.

Deze optie staat in hetzelfde tabblad voor bestandsoptimalisatie.

Wat is een CDN en hoe kan het ons helpen?

Een CDN is wat bekend staat als een content delivery network. De CDN is verantwoordelijk voor het opslaan van een deel van de informatie en de resources om de belasting van de server voor die resources te verlichten en beter te reageren op de lading. CDN's hebben ook een geografische kopiefunctie, om de resource beschikbaar te houden op verschillende punten en deze te serveren aan de gebruiker ongeacht waar ze vanaf verbinden. Meestal wordt dit soort service gebruikt voor zware bestanden zoals Afbeeldingen en Video's.

Aanmelden voor deze service is belangrijk wanneer we sites hebben met veel verkeer, hoewel het niet uitgesloten zou moeten worden voor sites met weinig verkeer.

Andere acties die ons wat meer verbetering opleveren

Om het artikel af te sluiten hebben we 3 meer verbeteringen die, hoewel ze geen enorme veranderingen zullen produceren in laadtijden, ons zullen helpen verzoeken te verminderen, en uiteindelijk is dat wat we willen.

Font-optimalisatie

Font-optimalisatie kan worden gedaan via plugins of handmatig door de CSS te bewerken en te optimaliseren. Het ideale zou zijn om alleen de font op te roepen die je gaat gebruiken en niet, zoals in veel gevallen gebeurt, een bestand met alle Google Fonts te downloaden.

Autoptimize heeft een optie om aan fonts te werken.

Het is moeilijk te zeggen welke optie te kiezen zonder het project te zien, want ik weet niet welke font je template gebruikt en wanneer het laadt, dus het beste is te testen en het resultaat te zien.

Zoals je ziet, hebben we direct na de Google Fonts-opties "Remove Emoji", wat ons een verzoek aan de server zal besparen. Zijn functie is simpelweg om symbolen die emoji's vertegenwoordigen om te zetten in het pictogram.

WP Rocket laat ons ook deze emoji's uitschakelen en biedt ook de optie om te voorkomen dat content wordt ingebed op sites van derden.

Uiteindelijk zijn er veel acties om de laadsnelheid van een site te verbeteren. Het is niet altijd mogelijk om diepgaand te werken om elke resource te optimaliseren, want het hangt af van het type bedrijf en wat het nodig heeft.

Ik hoop dat deze WPO-optimalisatiegids nuttig is en dat je het kunt toepassen in je projecten of voor je klanten.