Zo optimaliseer je de perceived performance van je Drupal website
1 oktober 2021
Drupal Zoekmachine optimalisatie (SEO)
De snelheid van je Drupal website of platform is niet alleen belangrijk om met SEO hoog in de Google zoekresultaten terecht te komen. Voor de gebruikerservaring van je gebruikers en potentiële klanten is een snelle laadtijd van je website ook essentieel. Je kunt je dus volledig op de cijfertjes van de performance van je website gaan richten, maar er is ook nog zoiets als ‘perceived performance’. Dit drukt uit in hoeverre je bezoekers de snelheid van je website ervaren. En dat is minstens net zo belangrijk. In dit artikel leggen we je uit hoe je deze perceived performance voor je Drupal website kunt optimaliseren.
- De knelpunten bij het beoordelen van de perceived performance
- De front-end versus de back-end
- Welke statistieken zijn nu eigenlijk echt belangrijk
- Tools om de snelheden van pagina’s te controleren
- Referentiepunten om de perceived performance van je website te evalueren
- Zo kun je de meest voorkomende vertragers uit de weg werken
- Extra tips om de perceived performance van je Drupal website te verbeteren
De knelpunten bij het beoordelen van de perceived performance
Als je de perceived performance van je website wil optimaliseren, zul je deze performance als eerste vanuit het oogpunt van de gebruiker moeten beoordelen. Dat is natuurlijk best een dingetje, want iets als een waargenomen prestatie is hartstikke subjectief. Je komt dan de volgende knelpunten tegen:
- Hoe kun je de laadsnelheid vanuit user experience controleren?
- Welke tools kun je het beste gebruiken om de performance van je Drupal website na te gaan?
- Hoe identificeer je de kritische data tijdens je controles?
- Hoe gebruik je de uitkomsten van je controles om te gaan optimaliseren?
- Wat is nu eigenlijk een snelle laadtijd als je gaat vergelijken met de beste prestaties van je concurrenten en de verwachtingen van je bezoekers?
In principe zijn er voor een effectieve controle van de pagina performance maar 5 stappen nodig. En voor iedere stap zijn er vrij makkelijke acties om de perceived performance te optimaliseren.
De front-end versus de back-end
Zowel de front-end als de back-end hebben een groot aandeel in de user experience en daarmee de perceived performance van je Drupal website. Niets is immers zo frustrerend als een trage respons van een website. Dit ontmoedigt bezoekers en zorgt ervoor dat potentiële klanten naar de website van je concurrent gaan. De perfomance van de front-end wordt bepaald door elementen die door de browser tijdens het laadproces opgehaald moeten worden zoals: afbeeldingen, HTML, CSS en JavaScript bestanden en zogenaamde third-party scripts. Doordat de browser al deze elementen download en bij elkaar vertoont, verschijnt er een webpagina waar de bezoeker interactie mee kan hebben. Als je de laadtijd van de front-end wil optimaliseren is het dus essentieel dat de browser zo min mogelijk elementen op moet halen om de pagina te kunnen tonen. En dat de elementen die echt nodig zijn een minimale grootte hebben. De performance van de back-end meet je door te kijken naar de TTFB (Time to First Byte). Deze bestaat uit drie elementen:
- Latency van de verbinding;
- Snelheid van de verbinding;
- Tijd die de server nodig heeft om de content te renderen en tonen.
Ook hier geldt: less is more. Houd rekening met trage verbindingen, dan zit je altijd goed.
Welke statistieken zijn nu eigenlijk echt belangrijk?
Bij het meten van de perceived performance zijn er 5 relevante statistieken die je in de gaten moet houden:
Speed index
Bij deze indicator breng je in kaart hoe lang het duurt voordat de content op het scherm volledig zichtbaar is. Technieken zoals Lazy Loading en Critical CSS zijn het meest effectief om deze tijd te verkorten.
Time To First Byte (TTFB)
Zoals eerder vermeld: TTFB meet de tijd vanaf het verzoek van de gebruiker totdat de eerste byte van de pagina door de browser wordt ontvangen. Je wil dat deze tijd zo kort mogelijk is omdat je gebruiker anders een moment naar een wit scherm zit te kijken en dat is funest voor de perceived performance.
Start render
Met ‘Start render’ wordt de tijd bedoeld die nodig is om de eerste content in de browser van de client te genereren. Als dit lang duurt, ligt dat meestal aan opeenvolgende verzoeken. Je kunt deze beter reduceren, uitstellen of verplaatsen om de tijd te verkorten.
Laadtijd
Laadtijd staat voor de tijd die de browser nodig heeft om de content op de opgevraagde pagina te laden. Met het activeren van HTTP/2 kun je indrukwekkende resultaten boeken om de laadtijd van individuele pagina requests terug te brengen.
Fully loaded
Fully loaded meet de tijd waarin er geen netwerk activiteit is, zelfs als alle JavaScript bestanden al zijn ingezet. In veel gevallen zijn de third-party scripts de dader bij hoge fully loaded tijden.
Tools om de snelheden van pagina’s te controleren
Nu je weet wat je moet analyseren en evalueren om de perceived performance te optimaliseren is het zaak om na te gaan hoe je het beste kunt gaan meten. Dit zijn de beste tools:
Met deze tools kun je:
- Waardevolle data over alle bovengenoemde ijkpunten verzamelen;
- Inzicht krijgen in het proces dat de browser uitvoert op het moment dat er een pagina wordt geladen;
- De zwakke punten in de performance van je website in kaart brengen;
- Terugkerende automatische snelheidstests van pagina’s instellen;
- In Speedcurve kun je je website voor verschillende apparaten en in verhouding tot de performance van je concurrenten monitoren;
- In Chrome DevTools krijg je een overzicht van de structuur van een webpagina en het proces van het downloaden van de verschillende elementen.
Referentiepunten om de perceived performance van je website te evalueren
Wanneer duurt de Time to First Byte te lang? Wanneer is de fully loaded te traag? Je kunt pas echt iets met je statistieken als je ook goed vergelijkingsmateriaal hebt. Gebruik daarom deze 3 referentiepunten om in de controle van je pagina snelheden mee te nemen:
- Stel de concurrentie vast: meet de snelheden van de huidige website voordat je gaat optimaliseren en meet de laadtijden van directe en indirecte concurrerende websites;
- Bepaal welke pagina’s van je website het belangrijkste zijn: dit zijn vaak de homepage, aanbodpagina’s, product overzichten, productdetail pagina’s en eventuele cruciale landingspagina’s;
- Meet de perceived performance van de website van je grootste concurrent.
Zo kun je de meest voorkomende vertragers uit de weg werken
Voordat je met meten en analyseren begint, kunnen we al een beetje voorspellen welke vertragende elementen je tegen gaat komen. De kans is namelijk groot dat je hier tegenaan gaat lopen:
Factoren die impact op de performance van de front-end hebben
1. Te veel embedded resources
Embedded stylesheets, JavaScript en afbeelding zijn allemaal extra ballast bij het laden van een pagina. Ze zorgen voor een tragere start van de render en daardoor ook voor een mindere perceived performance van je website. Ga na of je al die onderdelen echt nodig hebt en overweeg daarna het gebruik van caching, verkleiningen, samenvoegingen en/of compressie.
2. Te grote bestanden
Het is de nagel aan de doodskist van respons tijden van websites: veel te grote afbeeldingen. De tweede nagel komt van grote stylesheets en JavaScript. Gebruik ook hier caching, verkleiningen, samenvoegingen en/of compressie. Lazy Loading kan ook een mooie toevoeging zijn.
3. Een verkeerd geconfigureerde cache
Het zou zomaar kunnen dat je de settings van je cache niet hebt geoptimaliseerd. Of dat je Drupal cache stuk is. Als dat het geval is, wordt er geen latency gereduceerd om onnodige rendering tegen te gaan. Controleer je response headers, URL/ pattern configuratie en loop de settings van je cache na.
4. Niet geoptimaliseerde fonts
Zware fonts kunnen ook een aandeel in het vertragen van je website hebben. Gebruik daarom caching, delivery, compressie en karakter sets. Samenvattend kunnen we stellen dat het belangrijk is om alle pagina’s, third-party scripts en afbeeldingen te evalueren. Dragen ze genoeg aan de user experience bij ten opzichte van de negatieve gevolgen van de laadtijd van de pagina? Wat caching betreft: dit is geen techniek om de performance van je website op te krikken. Als er serieuze problemen in de front- of back-end zijn, is caching geen oplossing om die problemen te maskeren. Caching werkt alleen voor de optimalisatie van de perceived performance op websites die als een zonnetje werken.
Factoren die impact op de performance van de back-end hebben
Natuurlijk zijn er ook genoeg oplossingen die de performance van de back-end van je website kunnen verbeteren:
- Kijk of je het renderen van pagina’s direct in het CMS kunt optimaliseren;
- Upgrade de structuur van de server hardware met bijvoorbeeld load balancing, RAM, schijfruimte, MySQL afstemming of overstappen op PHP7;
- Beperk het aantal redirects tot het minimum, elke redirect zorgt voor een vertraging van de TTFB;
- Herconfigureer de software componenten die zich lager in de server stack bevinden (zoals het cachen van de back-end en de applicatie container);
- Overweeg een CDN te gaan gebruiken;
- Overweeg om Redis of Varnish te gaan gebruiken.
Extra tips om de perceived performance van je Drupal website te verbeteren
Als je het nu echt serieus aan wil gaan pakken, dan neem je ook de volgende tips mee:
- Test de perceived performance voordat je aan de optimalisaties begint, en herhaal het als je klaar bent. Zo weet je precies hoeveel vooruitgang je hebt geboekt.
- Meet de perceived performance wekelijks.
- Definieer het doel van de performance test: wat ga je testen en meten en onder welke omstandigheden? Je kunt er bijvoorbeeld voor kiezen om alleen de back-end performance van de meest populaire pagina’s bij 700 bezoekers te testen.
- Houd de configuratie van je pagina snelheden bij zodat je nauwkeurige en representatieve resultaten hebt.
