De snelheid van je website vanuit het perspectief van de gebruiker

7 april 2016

Dat de snelheid van je website van groot belang is voor de gebruikerservaring is logisch. Op een snelle website kunnen je bezoekers lekker doorklikken, daardoor ligt je bouncepercentage lager en zullen gebruikers eerder tot een conversie overgaan. Maar wanneer is je website of webshop snel genoeg? En hoe kun je dat, vanuit het perspectief van de gebruiker, meten? In dit blog het antwoord op deze twee vragen én een belangrijke manier waarop je jouw website sneller kunt maken.

Het gaat om de perceptie van laadtijd

Er zijn tools genoeg waar je een webpagina kunt invoeren om vervolgens te zien hoe snel deze is. Denk aan Pingdom, GTmetrix en Google’s PageSpeed Insights. De meesten geven ook meteen praktische aanbevelingen hoe je de snelheid van de pagina kunt verbeteren. Denk daarbij aan zaken als het optimaliseren van afbeeldingen en het verkleinen en combineren van HTML, JavaScript en CSS-bestanden. Over dit soort verbeteringen hebben we eerder al een blog geschreven.

Allemaal leuk en aardig, maar uiteindelijk gaat het erom dat jouw bezoeker de website snel genoeg vindt. Jouw bezoekers willen een optimale gebruikerservaring. Die hebben niets te maken met je achterliggende CMS-systeem en de vraag of je wel of geen (browser)caching toepast. Kortom: het gaat om de perceptie van de laadtijd door de bezoeker. De perceptie van de laadtijd is veel belangrijker dan de traditioneel gemeten laadtijd, paginaomvang etc. Om een goede indruk te krijgen van de perceptie van de snelheid kijk je naar twee variabelen: de start render tijd en de speed index.

Start render tijd

De start render tijd is de tijd tussen het opvragen van de pagina en het moment waarop er iets in de browser wordt weergegeven. Totdat de start render tijd is verstreken, kijkt de bezoeker dus naar een blanco scherm. Jakob Nielsen, een toonaangevend expert op het gebied van de gebruikersvriendelijkheid van computersystemen en websites, heeft al in 1993 onderzoek verricht naar responsetijden. Uit zijn onderzoek blijkt dat gebruikers geconcentreerd blijven op wat ze aan het doen zijn tot een responsetijd van maximaal één seconde. Tot deze seconde zullen je gebruikers het gevoel hebben dat zij vrij over je website kunnen navigeren zonder onnodig te hoeven wachten. Beperk de start render tijd daarom tot 1 seconde.

Speed index

De speed index is een goede indicator van de snelheid zoals een bezoeker die daadwerkelijk ervaart. Hierbij wordt gekeken naar hoe snel de content boven de vouw wordt weergegeven in de browser. Het gaat hierbij dus om het deel van de pagina dat direct, zonder te scrollen, zichtbaar is voor de bezoeker. De waarde van de speed index is daarmee dus afhankelijk van de schermresolutie. De speed index kan worden uitgerekend door te meten hoe snel delen van de pagina worden weergegeven. Klik hier voor een uitgebreide uitleg. Paul Irish, werkzaam bij Google, geeft aan dat je zou moeten streven naar een speed index onder 1000.

Hoe snel is jouw website of webshop?

Zowel de start render tijd en de speed index van een webpagina kun je met WebPagetest opvragen. Vul de URL van de te meten pagina in, selecteer een locatie van waar je wilt meten (zo dicht mogelijk bij het merendeel van jouw bezoekers) en kies een browser (de browser die het gros van je bezoekers gebruikt). Bij advanced settings kun je ook de snelheid van de internetverbinding kiezen of zelf bepalen. Start vervolgens de test.

webpagetest

Als de test(s) zijn uitgevoerd zie je een tabel met de resultaten verschijnen:

resultaten webpagetest

De load time is de traditionele laadtijd. De first byte is de tijd die verstrijkt tussen het opvragen van de pagina en de ontvangst van de eerste content (byte) door de bezoeker. De time to first byte is daarmee vooral een indicator van de snelheid van de hosting en het back-end van de website of webshop.

En nu je website sneller maken!

Dit blog begon met een aantal manieren om je website sneller te maken: afbeeldingen optimaliseren en het verkleinen en combineren van HTML, JavaScript en CSS. Dit blijven goede (en vaak snel te realiseren) manieren om je website te versnellen. Gegeven de start render tijd en de speed index is het belangrijk om het opbouwen en weergeven van een webpagina, en dan in het bijzonder dat deel boven de vouw, zo snel mogelijk te laten verlopen.

Hiervoor is het nodig dat je het ‘critical rendering path’ begrijpt. Een hele goede uitleg van het critical rendering path kun je hier lezen. Maar uiteraard heeft ook Google’s web performance guru Ilya Grigorik hier een artikel over geschreven. Als je je weleens hebt afgevraagd hoe Google verwacht dat je webpagina’s laat laden in één seconde, dan is dit je antwoord!

Critical rendering path

Het critical render path is een serie van acties in de browser die ervoor zorgt dat de webpagina in een browser verschijnt. De nadruk ligt daarbij op het renderen van de kritieke onderdelen voor de content boven de vouw. Je gaat de manier waarop een pagina wordt opgebouwd dus optimaliseren, dit wordt progressieve rendering genoemd. Grafisch ziet dat er zo uit:

critical rendering path

Wees ervan bewust dat een browser alle CSS- en JavaScript bestanden eerst allemaal moet downloaden en interpreteren, voordat de browser aan het opbouwen en weergeven van de pagina kan beginnen. Dit wordt render blocking genoemd; een browser kan pas verder gaan als al dit soort bestanden zijn ingelezen. Het oplossen van render blocking doe je door de niet kritieke onderdelen voor weergave boven de vouw uit te stellen. Dit wordt ook wel lazy loading, asynchronous loading of deferring genoemd.

Een aantal mogelijke verbeteringen:

  • De CSS-code die direct nodig is, opnemen in de HTML-code waardoor deze niet los ingeladen hoeft te worden. Overige CSS-codes laad je extern in, maar combineer je tot één bestand indien mogelijk.
  • Afbeeldingen die niet direct nodig zijn laad je later in door toepassing van lazy loading. Dit zie je al vaak bij categoriepagina’s van webshops, maar kun je ook voor overige beeldelementen gebruiken.
  • De meeste JavaScript (analytics, advertising, widgets, social media functies etc.) kun je laden nadat de webpagina zelf is geladen, waardoor deze verzoeken het renderen van de pagina niet meer blokkeren. Als je bijvoorbeeld jQuery functies gebruikt onder de vouw, is er geen enkele reden om jQuery in te laden voordat het wordt gebruikt. Hier kun je een voorbeeld zien van defer loading van javascript.

Hulp nodig? Neem contact op!

Dus: gaat het om de snelheid van je website of webshop, focus dan vooral op de metrics die voor je eindgebruiker relevant zijn: de start render tijd en de speed index. Als je de snelheid gaat optimaliseren, besteed dan aandacht aan de standaard aandachtspunten die je overal kunt raadplegen én het critical rendering path. Met de juiste optimalisaties wordt ook jouw website supersnel, hetgeen de conversie ten goede komt. Heel veel succes met het sneller maken van jouw website of webshop! Als je hierbij hulp kunt gebruiken, neem dan vrijblijvend contact met ons op.

Plaats een Reactie

We are part of Happy Horizon