We houden van snelle websites. Je bezoekers nog meer! Maar niet elke website is hier goed op ingericht. Wat slechts een klik op de knop is voor jou, kan voor je browser een flink takenpakket zijn. Wat gebeurt er nou eigenlijk bij het laden van een website? Neem dit proces daarom eens onder de loep. Lees verder en krijg meer inzicht!
Inhoudsopgave
Wat is je bestelling, alsjeblieft?
Je hebt vast weleens iets gegeten bij een fastfoodzaak. Je bestelt wat en een paar minuten later krijg je een dienblad met een warme hap. Als alles klaarstaat en er genoeg personeel aanwezig is, dan kun je binnen een mum van tijd beginnen aan je burger en patat. Echter, is de medewerker in zijn eentje, staat de grill staat uit en moeten de aardappelen nog worden geschild? Je kunt dan lang wachten op je menu…
Het laden van jouw website heeft hier eigenlijk best veel mee gemeen. In plaats van burgers en friet gaat het nu alleen om bytes. Zie het intypen van het domein als het plaatsen van de bestelling. In plaats van het grillen van een burger, worden er bytes gedownload. Daarna krijg je de website geserveerd. Dit doet je internetbrowser gelukkig allemaal automatisch. Wanneer jij op Enter drukt om naar een website te gaan, start het proces vanzelf. Hoe beter je website erop is voorbereid, hoe sneller die inlaadt.
Webhosting bij Antagonist
Je website en e-mail veilig hosten bij Antagonist? Met Patchman, 24/7 monitoring en gratis SSL krijg je een compleet pakket!
De structuur van een website
Met inzicht in de werking van HyperText Markup Language (HTML) is dit verloop beter uit te leggen. HTML beschrijft hoe inhoud op een website is gestructureerd. Je opent met een tag tussen brackets <> en aan het einde sluit je af met </>. Kijk maar eens naar het volgende voorbeeld:
<html>
<header>
<.......>
</header>
<body>
<.......>
</body>
</html>Hierin geeft alles tussen <html> en </html> aan dat die inhoud zich aan de regels van HTML moet houden. De tekst tussen <header> en </header> bevat een titel. Op zijn beurt staat tussen <body> en </body> de tekst, afbeeldingen, tabellen en andere elementen.
Gebruik je WordPress en een plugin zoals Elementor?
De benodigde HTML om een pagina op te bouwen wordt dan vanzelf toegevoegd. Tegenwoordig hoef je dus geen uitgebreide HTML-kennis meer te hebben om een website te maken.
De basis bij laden van een website
Het inladen van een website is op te delen in aantal belangrijke stappen:
- Request
- Response
- DOMContentLoaded
- Largest Contentful Paint (LCP)
Request
Bij een request (voluit GET-request) wordt er met behulp van internet data opgevraagd. Ga je bijvoorbeeld naar antagonist.nl, dan verzoek je om de website van Antagonist in te laden. Je browser zet dan de HTML om naar een zichtbare website. De tijd tussen dat je op Enter drukte en waarop de eerste byte van de HTML door je browser wordt gedownload, noemen we de Time To First Byte (TTFB). Vanaf dit moment begint de browser met het opbouwen van de website.
In het fastfoodrestaurant kun je dit vergelijken met het plaatsen van je order. De tijd die het kost voordat de hamburger klaar is, komt overeen met de TTFB. Terwijl je wacht op je hamburger, kun je wellicht zien dat het personeel begint met de bereiding. Op dezelfde manier begint de webserver met het samenstellen van de webpagina. De TTFB is afhankelijk van onder andere de serversnelheid en hoe groot je website is. Vergelijk dit met het bereiden van een grote of kleine hamburger met veel of weinig personeel.
Response
De response kun je vergelijken met klaarzetten van je dienblad in de fastfoodzaak. In deze stap wordt de basis van jouw website opgebouwd. Alles uit de HTML-code wordt werkelijk ingeladen. Denk hierbij aan de indeling, opmaak (CSS), afbeeldingen en script-elementen. Wat hier precies wordt ingeladen, hangt af van bijvoorbeeld je WordPress-thema en -plugins, frameworks, en de programmeertaal die je gebruikt.
DOMContentLoaded
DOMContentLoaded is een gebeurtenis die plaatsvindt wanneer een webpagina is geladen. De browser heeft dan alle HTML en CSS verwerkt. De structuur van de pagina is klaar is en de inhoud kan worden weergegeven aan de bezoeker. Op dit punt kan er nog steeds worden gewacht op het laden van bepaalde scripts of afbeeldingen, maar de belangrijkste inhoud is klaar om te worden bekeken.
In het metaforische fastfoodrestaurant is dit de fase waarin alles verpakt wordt en op je dienblad wordt gelegd. Het eten is klaar om te worden geconsumeerd. Echter, er kunnen nog steeds dingen zijn die moeten worden gedaan voordat je volledig tevreden bent met je maaltijd. Denk aan het toevoegen van ketchup of mayonaise aan je frietjes. Op dezelfde manier kan er nog steeds aanvullende inhoud zijn die moet worden geladen op de webpagina, zoals afbeeldingen of scripts.
Largest Contentful Paint (LCP)
Tegenwoordig wordt de Largest Contentful Paint (LCP) als een betere metriek gezien dan DOMContentLoaded. LCP meet de tijd die het kost om het grootste inhoudselement op de pagina te laden en weer te geven. Denk aan een grote afbeelding of video. Dit is waardevol, omdat het toont hoe snel de belangrijkste inhoud wordt weergegeven aan de gebruiker. Het is dus meer gericht op de gebruikerservaring. Langer wachten op de belangrijkste inhoud betekent een mindere ervaring.
Hoewel bij DOMContentLoaded de HTML- en CSS-code is geladen, wil het niet zeggen dat de gebruiker ook daadwerkelijk de belangrijkste inhoud kan zien of gebruiken. Daarom is het nuttiger om naar de LCP te kijken. Dit kun je vergelijken met bestellen van een hamburgermenu. De LCP is het moment dan het belangrijkste deel van je bestelling – de hamburger – klaar is en aan je wordt geserveerd. De frietjes en de milkshake kunnen later komen.
Laden van je site meten
De laadtijd van je website analyseren kan op meerdere manieren. Persoonlijk vind ik Page load time voor Google Chrome erg fijn en overzichtelijk. Deze extensie toont je een overzicht van de stappen in het laadproces. Je kunt daarbij ook direct zien hoe lang elke stap duurt, zoals op de onderstaande afbeelding.
Daar vind je ook de eerder genoemde stappen request, response en DOM. Hoe langer de blauwe balk is, hoe langer de omschreven stap duurt.
Wil je meer details zien van hoe je website laadt, gebruik dan de Web Developer Tools van je webbrowser. Ga daar naar het tabje Network laad je pagina opnieuw in. Je ziet dan hoe deze chronologisch geladen wordt en hoe lang elk element hierover doet. Merk je op dat een onderdeel er langer dan gewenst over doet, dan kun je deze stap in de meeste gevallen optimaliseren.
De laadtijd verkorten van je site
Je hebt nu een idee van de pijnpunten. Maar wat kun je eraan doen en heb je overal wel invloed op? Laten we kijken naar de mogelijk maatregelen die je kunt treffen voor drie eerder genoemde punten.
Langdurige requests
Het versnellen van de request-fase ligt buiten je eigen invloed en is voor elke bezoeker anders. Besteed hier dus niet te veel tijd aan. Een langdurige request heeft meestal een lokale oorzaak, waardoor er slecht contact met de server kan worden gemaakt. Denk hierbij aan netwerkproblemen of wegvallende wifi. Je kunt het dan via een ander netwerk proberen. Merk je het op meerdere apparaten? Controleer voor de zekerheid op onze statuspagina of er geen tijdelijke problemen spelen op de server van je website.
Trage responstijd
Om de response te versnellen, moet je kritisch kijken naar HTML, CSS en scripts. De Web Developer Tools komen daarbij van pas. Zodra je het verantwoordelijke bestand hebt gevonden, kun je deze openen. Wellicht is de oorzaak simpel, doordat je in de Developer Tools al een foutmelding hebt gezien. Goede kennis van webontwikkeling werkt hierin in je voordeel, omdat een oplossing altijd maatwerk is. Kom je hierin zelf niet verder? Dan is hulp inschakelen van een (collega) webbouwer een volgende stap. Specifiek voor WordPress kun je ook onze eerdere blogs over WordPress optimaliseren raadplegen.
DOMContentLoaded verbeteren
Zodra je browser alle benodigde data heeft opgevraagd en ontvangen, krijg je de website op je scherm te zien. Ook het verbeteren hiervan is maatwerk. Vaak komen hierbij zaken zoals caching en database-optimalisatie kijken. Zelf heb je invloed op de manier waarop bepaalde processen worden ingeladen. Zo laad je met lazy load pas delen van je website, zodra ze in beeld moeten komen. Ook kun je door middel van asynchroon programmeren meerdere taken tegelijkertijd laten lopen.
LCP verbeteren
Dit zijn een paar stappen waaraan je kunt denken om de LCP van je website te verbeteren.
- Optimaliseer de grootste inhoudselementen
Bekijk welke onderdelen op je webpagina het grootst zijn en optimaliseer deze. Denk aan afbeeldingen comprimeren of video’s verkleinen. - Verminder de server-responstijd
Een trage responstijd kun je onder andere verbeteren door caching te gebruiken. Denk aan bijvoorbeeld het gebruik van Redis. - Gebruik lazy loading
Met lazy loading wordt alleen de inhoud geladen die de gebruiker direct nodig heeft. Dit verbetert de laadtijd en gebruikerservaring meestal aanzienlijk. - Verminder blokkerende JavaScript
JavaScript vertraagt soms de laadtijd van je pagina. Verminder dit door JavaScript te optimaliseren, onnodige scripts te verwijderen en ze op de juiste manier te laden. - Optimaliseer webfonts
Ook webfonts kunnen bijdragen aan een trage LCP. Verbeter dit door alleen lettertypen te gebruiken die je daadwerkelijk nodig hebt en comprimeer ze om de bestandsgrootte te verkleinen.
Controleer, pas aan en merk het verschil
Hopelijk heeft dit artikel je aan het denken gezet. Ben je zelf ook nieuwsgierig waar er nog winst te halen valt? Je weet nu waar je moeten beginnen. Test verschillende methodes en vind de beste voor jou. Veel succes gewenst met het verbeteren van de laadtijd van je website!
P.S. Blijf op de hoogte en volg ons via Facebook, X, Instagram, e-mail en RSS. Heb je vragen, tips of opmerkingen? Laat het achter als reactie. Vond je het artikel nuttig? Deel het dan met anderen!
Sinds gisteren heeft mijn forum weer regelmatig een snelheidsdip waarbij het soms even erg sloom werkt. Zijn er meerdere die op server S228 zitten met hetzelfde probleem? Ik heb dit al eens eerder gehad waarbij vanuit antagonist werd aangegeven dat dit aan mijn website/forum zou liggen. Pas nadat er op het forum meerdere personen meldingen gaven (op dezelfde server) kwam Antagonist erachter dat het (naar ik meen) met een probleem met de database te maken heeft. Hopelijk word dit ook door ander Antagonist klanten met dezelfde server gelezen zodat zij hun ervaringen kunnen delen.