De complete handleiding voor een snelle website

Website snelheid is een geavanceerd onderwerp waar veel artikelen over geschreven zijn. Vaak duiken deze artikelen diep in de materie om vervolgens technische oplossingen te geven voor complexe problemen. In dit artikel toen we dat anders. Ik leg je eerst precies uit watwebsite snelheid is, Wat een website traag maakt en hoe je een website weer snel maakt.

Waarom is website snelheid belangrijk

De laatste tijd er er een vernieuwde focus op website snelheid. Niet alleen door de https://webmasters.googleblog.com/2018/01/using-page-speed-in-mobile-search.html Google speed update of de meer recente page experience update (https://webmasters.googleblog.com/2020/05/evaluating-page-experience.html) waar snelheid een belangrijk onderdeel van is maar ook omdat website snelheid een grote impact heeft op user experience.

Waarom is website snelheid dus belangrijk?

User experience:
Bijna de helft van de bezoekers verwacht dat een webpagina later binnen 2 seconden. Maar in de praktijk is dat lang niet altijd zo. een gemiddelde webpagina in de ecommerce top 500 heeft een laadtijd van 9.3 seconden.

https://www.akamai.com/us/en/multimedia/documents/content/akamai-performance-matters-key-consumer-insights-ebook.pdf

Volgens een onderzoek van Google verlaat maar liefst 53% van de mobiele bezoekers website Wanneer deze langer dan 3 seconden laadt.

https://www.thinkwithgoogle.com/marketing-resources/data-measurement/mobile-page-speed-new-industry-benchmarks/

SEO

Sinds 2009 was website snelheid een ranking signaal op desktop zoekopdrachten maar sinds 2018 is het ook officieel een Ranking Factor voor mobiele zoek opdrachten.

https://webmasters.googleblog.com/2018/01/using-page-speed-in-mobile-search.html .

In 2020 kondigde Google deweb vitals ons aan. Dit zijn drie punten waarop Google in 2020 jouw website gaat beoordelen. 3 punten zijn snelheid interactiviteit en stabiliteit.

Website snelheid is niet alleen een belangrijke factor in Google. Website snelheid is ook belangrijk voor jou conversie. Onderzoek Van cloudflare bijvoorbeeld laat zien dat pagina's die snel zijn meer dan drie maal zo goed converteren dan tragere pagina's.

https://www.cloudflare.com/learning/performance/more/website-performance-conversion-rates/

Genoeg reden dus om eens te kijken hoe het zit met de snelheid van jouw webpagina is

Wanneer moet ik me druk maken om website snelheid?

Je vraag je misschien af wanneer je je druk moet maken om de snelheid van jouw website. Wat levert het op als je investeert in de snelheid van jouw wesite.

Investeren in een snellere website?

Iedere aanpassing die je maakt en je website kost tijd. De tijd die je hebt is niet onbeperkt dus je moet altijd keuzes maken.Wanneer heeft het zin om aanpassingen aan jouw website te maken die ervoor zorgen dat jouw pagina sneller laadt?

Er zijn grofweg 2 strategieën die gevolgd worden als het gaat om website snelheid. De eerste is ‘website snelheid als basisbehoefte’ en de volgende is ‘goed is goed genoeg’

Website snel uit als basisbehoeften gaat ervan uit dat een website die snel laad heeft vanaf het begin al een grotere groeipotentie heeft. Je zorgt er dus voor dat snelheid is alle delen van jouw site is verweven door bijvoorbeeld goede afspraken over snelle servers, lichtgewicht javascript, responsive afbeeldingen. Verander je wat aan de pagina of voeg je wat toe? Dan let je naast de inhoud ook goed op de snelheid.

De volgende strategie: ‘goed is goed genoeg’ wordt door veel meer sites gevolgd. Voor de meeste websites die wij kennen is website snelheid om eerlijk te zijn niet zo heel belangrijk. Zolang de pagina maar niet al te traag is en niet als hinderlijk wordt ervaren wordt er weinig tijd besteed aan snelheid verbetering. Is de pagina wel traag geworden dan wordt dat opgelost met een snelle fix zoals server side caching en niet door aan de basis van een site te gaan sleutelen.

Welke strategie is beter? Dat kunnen we natuurlijk niet meteen voor je beantwoorden.we zien regelmatig druk bezochte sites met gigantische advertentie budgetten waarbij de pagina's en structureel veel te lang over doen om te laden. We zien ook kleine sites zonder noemenswaardig verkeer die heel veel tijd besteden aan een goede technische achterkant. Beide voorbeelden zijn wat ons betreft niet handig bezig.

Website snelheid hoort in onze mening niet bovenaan het lijst te staan. Klopt, je leest het goed,ons advies zal nooit zijn dat je te veel tijd in technische aspecten van een website moet besteden. Je bent dan aan het over-optimaliseren ten koste van andere werkzaamheden. Goede content is en blijft veel belangrijker. Maar er is een trade-offen deze trade-off wordt door veel websites over het hoofd gezien. Door te investeren in een snelleresite kun je sneller groeien,meer bezoekers ontvangen en betere conversies behalen.

Wat is een goede laadtijd.

Wat is dan een goede laadtijd vraag je je misschien af? Er is geen officiële beste laadtijd maar er zijn wel vuistregels.

  1. Sneller is altijd beter, zonder uitzondering. Iedere milliseconde die je een pagina sneller kunt maken is altijd een verbetering.
  2. Zorg dat jouw pagina binnen 3 seconden laadt. 53% van de respondenten in een Google onderzoek gaf aan een pagina te verlaten wanneer deze langer dan 3 seconden moet laden. https://www.thinkwithgoogle.com/marketing-resources/data-measurement/mobile-page-speed-new-industry-benchmarks/
  3. Een mobiele site mag iets trager laden dan een desktop maar houdt er rekening mee dan mobiel internet trager is dan internet thuis of op het werk en dat een mobiele processor trager is dan een PC processor. Een mobiele pagina zou dus eigenlijk sneller en lichter moeten zijn dan een desktop pagina.
  4. Largest Contentful Paint (LCP): meet wanneer een gebruiker een webpagina als ‘klaar’ zal zien en moet onder de 2.5sec liggen.
  5. First Input Delay (FID) meet interativitieit en moet onder de 100ms liggen

https://www.youtube.com/watch?v=7HKYsJJrySY&feature=youtu.be&t=32

Waaruit bestaat website snelheid

Website snelheid is toch wel een lastig begrip om snel uit te leggen. Website snelheidlaat zich niet in een enkel punt in de tijd vastleggen. Dat komt deels doordat er steeds meer slimme technieken zijn om steeds groter wordende webpagina’s toch snel te laten laden en deels door een voortschrijdend inzicht.

Een aantal jaar geleden waren websites eenvoudiger. Websites waren minder ingewikkeld en laden meer recht toe recht aan. Van eenvoudige websites met wat tekst en een plaatje kun je gemakkelijk de snelheid meten.

Tegenwoordig zijn websites veel ingewikkelder opgebouwd. Er wordt door veel meer extra’s toegevoegd aan een pagina. Denk bijvoorbeeld aan sliders social media plug-ins, shopping cards, aanbevelingen een andere dynamische content die pas na het laden van de website binnen gehaaldwordt.Er worden ook steeds meer geavanceerde en grotere javascript bibliotheken gebruikt omhet ontwikkelen gemakkelijker te maken of om de site gebruiksvriendelijker en interactiever te maken. Om een pagina aantrekkelijker te maken worden er veel gebruik gemaak van webfonts, grote afbeeldingen en video.

Om te voorkomen dat websites stukken trager gingen laden zijn er slimmere technieken bedacht waarbij niet alles achter elkaar maar parallel aan elkaar wordt geladen.

Waarom zouden we bijvoorbeeld delen van een website laden die je toch nog niet kan zien. Wanneer is de website dan geladen? En denk eens aan allerlei soorten plugins. Een chat plugin, een ‘deel op social media plugin’. Deze worden vaak pas op een later moment aan de site toegevoegd. Is de site al klaar terwijl je het artikel aan het lezen bent maar de chat nog niet is geladen?

Dat heeft er voor gezorgd dat webpagina's zijn dus niet meer per se ‘klaar’ zijn wanneer je de tekst op de pagina kunt lezen maar op de achtergrond nog verder laden.

Je kunt website snelheid op dit moment opdelen in 3 onderdelen die vaak (maar niet altijd) met elkaar verbonden zijn.

  1. Wanneer begint de pagina met opbouwen?
    De pagina begint met opbouwen wanneer de HTML en alle kritieke, blokkerende bronnen (zoals sommige javascripts) zijn geladen. Dat is het punt dat er als eerste ‘iets’ op het scherm komt te staan. Soms vrijwel de hele pagina ineens maar dat hoeft lang niet altijd. Dit is een belangrijk punt voor website timing. Gaat er hier iets mis? Zoals (extern) een javascript dat heel traag laadt? Dan blijft de pagina gewoon wit.
  2. Wanneer is de belangrijkste inhoud zichtbaar?
    Nadat de pagina is begonnen met opbouwen heeft browser nog even tijd nodig om de belangrijkste inhoud op de pagina te laten zien. Hoe ingewikkelde pagina is Hoe langer het duurt voordat de belangrijkste inhoud zichtbaar is.
  3. Wanneer kun je interactie met de pagina aan gaan?
    Wanneer de belangrijkste inhoud zichtbaar is is de pagina nog niet perse klaar om interactie mee aan te gaan. Wanneer de ‘Main thread’ nog bezig is kun je bijvoorbeeld nog niet klikken op een link en ook niet op bijvoorbeeld een Ad to cart Button.

Mu we een idee hebben wat website snelheid precies is kijken we wat pagina's precies langzaam maakt.

Wat maakt pagina’s langzaam?

Zodra je een webpagina opent gebeuren er drie dingen. De server stuurt jou een html-bestand over het netwerk waarmee de browser aan de slag gaat. Het html-bestand wordt gelezen door de cliënt en de browser doet extra verzoeken naar de server voor bijvoorbeeld statistisch Javascript of afbeeldingen. ondertussen begint jouw browser ook met het renderen, het op het beeldscherm zetten, van de webpagina. In alle drie deze stappen kan een kleine of grote vertraging optreden.

  1. Server side processing
    Een webserverbouwt de HTML van de pagina vaak pas op wanneer de pagina wordt opgevraagd. De server moet in de database kijken en berekeningen maken en dat kost tijd. Wanneer het druk is op de server of er niet efficiënt wordt geprogrammeerd kan er een flinke wachttijd ontstaan voordat de pagina wordt verzonden.
  2. Netwerk vertraging
    Netwerk vertraging is de tijd die hetkost om verzoeken te versturen naar de server en de tijd die verloren gaat om een antwoord te sturen. Op een gemiddelde websiteworden er gemakkelijk meer dan 100netwerk verzoeken verstuurd. Een kleine vertraging in het netwerk kan zo dus oplopen tot een grotere vertraging op een website.
  3. Client side rendering
    Zelfs al wordt de HTML snel verstuurd over een snel netwerk Dan moet de browser de pagina nog opbouwen uit de HTML, Javascript, stylesheets, afbeeldingen en video's die op de pagina horen. Bij een ingewikkelde of slecht opgestelde pagina kan het lang duren om een pagina op te bouwen.

Tips voor het verbeteren van de pagina snelheid

Nu we weten wat website snelheid precies is en wat een website traag kan maken kunnen we kijken hoe we een pagina sneller laten laden.

Server-side processing versnellen

  • Snellere hardware
    Snellere hardware inschakelen is één van de meest simpele manieren om mijn pagina snelle te maken. Toch zien we in de praktijk dat heel veel websites, met een heel behoorlijke omzet, in onze ogen veel te weinig uitgeven aan hardware. Bedrijven met een dagomzet van €20000die geen €200 per maand uitgeven aan website Hosting zijn geen uitzondering.
  • Server-side caching
    Veel websites maken gebruik van zogenaamde dynamische pagina's. Dat zijn pagina's die op het moment dat ze worden opgevraagd was worden opgebouwd uit informatie die in een database gevonden kan worden.Veelgebruikte cms-systemen zoals WordPress Drupal en Joomla maken alleen maar gebruik van dynamische pagina's. Bij server-side caching sla je de uiteindelijk HTML tijdelijk op zodat je deze niet opnieuw hoeft te berekenen wanneer een volgende bezoeker dezelfde paginaopvraagt. Door deze techniek goed toepassen kun je we HTML soms in enkele milliseconde terugsturen naar de bezoeker.
  • efficiënt programmeren
    lukt het niet om caching toe te passen omdat de pagina bijvoorbeeld per bezoeker of per bezoek veranderd dan is het een goed idee om de achterliggende code eens tegen het licht te houden.Niet alleen deCode maar ook de match tussen de applicatie en de beste programmeertaal kunnen een bottleneck vormen.programmeertalen zoals PHP Voeren alle code achter elkaar uit waarbij de laatstecode op de eerste moetMoet wachten.NodeJs bijvoorbeeld kan code parallel uitvoerenwat voor een flinke snelheidswinst kan zorgen.
  • database queries verbeteren
    In de praktijk zien we dat er heel vaak grote winst te behalen is wanneer je kijkt hoe jouw gegevens opgeslagen zijn in de achterliggende database.
  • horizontaal schalen
    Bij grotere websites is het aanschaffen van snellere hardware soms niet meer mogelijk of rendabel. In plaats van de server op te schalen kun je haar ook Het aantal servers opschalen. Je verdeelt dan de belasting die normaal gesproken op een server staat over minderservers.Service die nietoverbelast worden kunnen sneller reageren.

Netwerk vertraging oplossen

  • De juiste web protocollen en server instellingen gebruiken
    Webprotocollen bestaan uit meerdere lagen. Iedere laag moet zo efficiënt mogelijk met de volgende laag praten. Een echte expert kan de verschillende protocollen op de juiste manier inregelen zodat het netwerk een flink stuk sneller en efficiënter kan werken.
    Voor de experts: denk eens aans OCSP Stapling, SSL Caching, HSTS, SSL protocal volgorde (van snel naar traag)
  • maak gebruik van HTTP/2
    HTTP/2 is de nieuwe, door google ontwikkelde,standaard voor communicatie op internet. HTTP/2 is gebouwd om sneller te zijn door bijvoorbeeld headercompressie en multiplexing (waarbij meerdere netwerk verzoeken over 1 verbinding worden gestuurd), en het meer geavanceerde server push of het instellen van netwerk prioriteiten. Met HTTP/1.1 was het vaak sneller om bestanden vanuit verschillende (sub)domeinen parallel te laden. Met HTTP/2 is het eigenlijk altijd sneller om deze bestanden door dezelfde, enkele verbinding te sturen.
  • sla netwerkverkeer over door client-side caching
    De beste manier om netwerk verkeer te versnellen is natuurlijk door het over te slaan. Dat kun je doen door statische bestanden, zoals afbeeldingen, CSS en Javascripts, een header mee te geven waarin staat dat de browser deze bestamden lokaal op mag slaan. Lokaal opgeslagen (ge-cachte) bestanden hoeven dan niet meer bij iedere pagina opnieuw over het internet verzonden te worden en zijn eigenlijk direct beschikbraar in de browser.
  • prefetch DNS of preconnect.
    Verbind al vroeg tijdens het laden met een externe server om snelheidswinst te behalden. Bij <link rel=dns-prefetch> haal je alvast de DNS op van de server. Bij <link rel=preconnect> haal je de DNS op, verbind je met de server en beveilig je de verbinding alvast. Dit kan een hoop tijd schelen als je zeker weet dat je de het bestand (zoals een JavaScript, StyleSheet of een Webfont) nodig hebt om het kritieke (zichtbare) deel van de pagina te laden.
  • Maak gebruik van een CDN
    Een CDN kan een goede oplossing zijn om netwerk vertraging te verminderen. Een CDN heeft servers over heel de wereld en serveert jouw content vanaf de server die het dicht bij de bezoeker staat. Dat kan een hoop tijd schelen. Niet alleen bij het ophalen van bestanden maar ook bij het leggen van een beveiligde verbinding (Early SSL termination) Bovendien heeft een CDN vaak een betere protocol implementatie (zoals we hierboven beschreven) dan jouw eigen servers.
  • Maak gebruik van compressie
    Een van de meest voordehandliggende manieren om eennetwerk vertraging te vermijden is door minder bytes over het netwerk te versturen. Wat kun je doen door middel van compressie. je kunt op tekst gebaseerde bestanden zoals stylesheets Javascript and HTML een stuk kleiner maken door compressie toe te passen. Dit doe je op de server. Er zijn twee soorten compressie mogelijk op het web. Deeerste is gzipcompressie en de tweede is het nieuwere Brotli compressie. Brotli, Is ontwikkeld door Google maar nog steeds watonbekendereBrotli werkt net zoals gzip maar heeft ook een een woordenboek van 13.000 meest voorkomende woorden in HTML bestanden waardoor bestanden als snel 20% tot 30% kleiner worden dan met gzip.

Client Side rendering verbeteren

Client side rendering werkt als volgt. Eerst haalt jouw browser een html bestand op. Dat html bestand wordt omgezet in een boomdiagram met html nodes, het DOM of Document Object Model. Komt de browser een externe stylesheet tegen dan wacht jouw browser met de DOM op te bouwen en wordt de stylesheet opgehaald. De styles worden ook omgezet in een boomdiagram met nodes: de CSSOM of CSS Object Model. Het DOM en CSSOM worden daarna samengevoegd tot de Render Tree, dat is een blauwdruk waarmee de browser de volgende stap, de lay-out zal bepalen waarbij de Render Tree aangepast wordt aan de maten van jouw browser. De laatste fase is de paint fase waarbij lagen van jouw websites tot afbeeldingen worden omgezet om zo op het scherm getekend te worden.

Oke, nu we dit weten wordt het een stuk logischer hoe je dit

  • Optimaliseer jouw afbeeldingen. Afbeeldingen en (video’s) kunnen voor een flinke vertraging zorgen bij het opbouwen van de pagina. Waarom? Omdat afbeeldingen het grootste gedeelte van het netwerkverkeer voor zich nemen. Is een afbeelding niet geladen? Dan kan deze niet worden meegenomen in de paint en wordt deze in een latere paint fase pas op het scherm gezet.
    En wat als je geen hoogte of breedte meegeeft? Dan zit de browser tijdens de lay-out fase al vast, er kan geen ruimte worden gereserveerd op het scherm. Dus moet de afbeelding eerst opgehaald worden voordat de browser verder kan of de lay-out moet op een later moment worden aangepast wat kan zorgen voor een layout-shift (iets wat je absoluut wilt voorkomen).
    Als laatste kan een te grote afbeelding zorgen voor overhead tijdens het schalen in de paint fase.
    Geef daarom altijd de hoogte en breedte van een afbeelding mee en kijk of jede bestandsgrootte van een afbeelding kunt verkleinen door afbeelding compressie. Wil je nog sneller of heeft mobiel prioriteit? Kijk dan eens naar responsieve afbeeldingen.
  • Stel laden van afbeelding uit met loading=lazy. Wanneer een afbeelding niet op direct zichtbare scherm staat kun je er voor kiezen om deze afbeelding niet te laten laden door een browser. De afbeelding wordt pas geladen wanneer je scrollt en de afbeelding bijna in het zichtbare gedeelte van de browser zit. Dat scheelt netwerkverkeer en paint tijd waardoor de browser zich eerder kan richten op het zichtbare gedeelte van de website.
    Het later laden van afbeeldingen noemen ze ‘lazy loading’. Daar zijn verschillende technieken voor. 1 van de meest handige technieken die helaas nog niet door iedere browser wordt ondersteund is het loading attribuut dat aangeeft of een afbeelding standaar of lazy geladen mag worden.

<blockquote class="twitter-tweet"><p lang="en" dir="ltr">Tip: Set width &amp; height on your &lt;img&gt; elements. This now allows modern browsers to infer their intrinsic size pre-download, reducing layout shifts. <a href="https://t.co/yhsIftiJzR">pic.twitter.com/yhsIftiJzR</a></p>&mdash; Addy Osmani (@addyosmani) <a href="https://twitter.com/addyosmani/status/1276779799198007301?ref_src=twsrc%5Etfw">June 27, 2020</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

  • Stel het laden van JavaScript uit wanneer dat mogeijk is. JavaScript is meestal single-threaded en blokkerend. Dat betekent dat een browser moet wachten op het uitvoeren van JavaScript. Wanneer javascript uitgevoerd wordt voor de paint dan duurt het dus langer voordat er iets op het scherm staat. Gelukkig is het meestal niet nodig om JavaScript uit te voeren voordat de content op het scherm staat, dat kan meestal ook prima daarna. Daarvoor bestaat ‘deferred’ of uitgesteld. Javascript. Hoe dat allemaal werkt kun je hier lezen https://www.marketingtracer.com/nl/seo/verbeter-website-snelheid-defer-javascript
  • Inline (kritieke) CSS
    CSS moet eerst omgezet worden tot de CSSOM voordat jouw browser ook maar iets verder kan doen. Wordt jouw CSS traag opgehaald of traag geanalyseerd dan moet heel jouw pagina wachten. Er zijn verschillende manieren om hier mee om te gaan. 1 van die maneiren is om (kritieke) CSS bij het eerste bezoek inline in de head van de pagina te zetten. Dat scheelt weer een netwerkverzoek waardoor jouw browser niet hoeft te wachten. Voor meer informatie hierover kijk je even ophttps://www.marketingtracer.com/nl/seo/verbeter-website-snelheid-met-inline-css
  • Wacht niet op webfonts
    De meeste sites maken gebruik van webfonts, dat zijn niet-standaard fonts die door de browser gedownload kunnen worden. Een webfont kan jouw pagina een stuk mooier maken. Maar tijdens het downloaden van font kan vertraging optreden. De tekst van depagina (om specifiek te zijn: text DOM-nodes) worden dan niet op het scherm gezet totdat het font is geladen. Om dat op te lossen kun je gebruk maken van de CSS property font-display https://css-tricks.com/almanac/properties/f/font-display/. De waarde hiervan (block,swap,fallback of optional) geeft je meer controle over hoe lang een browser wacht op een web-font met het laten zien van de text-nodes.
  • Vermijd langdurende taken
    Sommige taken die door Javascript uitgevoerd worden kunnen erg lang duren. Tijdens het uitvoeren van deze taak kan een browser niet zo heel veel doen. Gebeurt dit aan het begin van het laden dan zal deze taak laten blokkeren. Gebeurt dit aan het eind van het laden dan zal deze taak de responsieve tijd van jouw pagina verminderen. Je kunt dan dus bijvoorbeeld niet op een link klikken

Hoe moet je beginnen ?

Het online-marketing dashboard voor professionals

Meer dan de helft van de Emerce top-100 digital marketingbureaus gebruikt MarketingTracer.
Geen opzegtermijn, direct online, gratis trial.