Geschreven op 13 mei 2024, laatst gewijzigd op 19 mei 2024.

Hoe laden browsers websites?

Tijdens het surfen op internet klik je op talloze links die naar verschillende websites leiden. Elke keer dat je op een link naar een nieuwe webpagina klikt, moet je wachten tot alles is geladen voordat je verder kunt. Achter de schermen moet je browser veel stappen doorlopen om dit mogelijk te maken. Dit artikel beschrijft het hele proces, zodat je weet wat er gebeurt wanneer je op een link klikt. We beginnen met hoe de browser alle benodigde informatie ophaalt, gaan verder met hoe de browser deze gegevens interpreteert en uiteindelijk bepaalt hoe alles aan de eindgebruiker getoond moet worden. Tot slot bespreken we hoe je kunt beïnvloeden wanneer browsers laden en welke methoden er zijn om de laadsnelheid van webpagina's te verbeteren.

Dit inzicht geeft je waardering voor al het werk dat nodig is om internetgebruik mogelijk te maken. Het biedt ook fundamentele kennis om de prestaties van de websites en online applicaties die je bouwt te verbeteren. Door deze details te leren over hoe de browser werkt, heb ik het Content Management Systeem (CMS) dat mijn collega's en ik gebruiken om websites voor onze klanten te bouwen, kunnen optimaliseren.

Stel je voor dat je meer wilt weten over hoe browsers websites laden. Je gaat naar je favoriete zoekmachine, typt je vraag in en drukt op enter. Bing toont je dan een interessante eerste link naar een artikel precies over dit onderwerp, misschien zelfs dit artikel! Je klikt op deze eerste link. Wat gebeurt er nu?

De link verwerken

Je browser ontvangt de informatie die nodig is om naar een andere pagina te gaan die te vinden is op de link waarop je zojuist hebt geklikt. Om te bepalen hoe deze informatie te verkrijgen, moet de browser uitzoeken wat er wordt gevraagd. Dit gebeurt met een link, ook wel een Uniform Resource Locator (URL) genoemd. Een URL is een manier om een bron ergens ter wereld te identificeren met een eenvoudig stukje tekst. Laten we een licht aangepaste versie van de link naar dit deel van de pagina nemen: https://rondekker.nl/artikelen/web-prestaties/hoe-laden-browsers-webpaginas/index.html#de-link-verwerken?utm_source=google. Laten we dit stap voor stap doornemen, beginnend van links.

• https:// - Dit is het protocol van het Hypertext Transfer Protocol Secure (HTTPS). Je hebt misschien ook gehoord van andere protocollen, zoals Secure Shell (SSH) of File Transfer Protocol (FTP). Een protocol betekent gewoon dat er een overeengekomen manier is om iets te doen en in dit geval wordt het HTTPS-protocol gebruikt. Later meer hierover.
• rondekker.nl - Dit is de domeinnaam, een onderdeel van het adres dat de website gebruikt en waarmee de browser kan opzoeken waar de computer die de website host, te vinden is.
• /artikelen/web-prestaties/hoe-laden-browsers-webpaginas/index.html - Dit is het pad. Net zoals je computer bestanden heeft en een pad dat ernaar leidt, is dit het pad dat leidt naar een bestand op de computer die de website bedient. Vaak wordt de bestandsnaam index.html als impliciet beschouwd en het weglaten ervan betekent hetzelfde. Net zoals deze website dat doet.
• #de-link-verwerken - Dit is een fragment. Het verwijst naar een element van het bestand dat we willen bezoeken, met andere woorden, een deel van de webpagina. Nadat de pagina is geladen, gebruikt de browser dit om automatisch naar het juiste deel van de pagina te scrollen.
• ?utm_source=google - Dit is een queryparameter. Hiermee kan extra informatie worden overgedragen bij het ophalen van de bron. Queryparameters worden op verschillende manieren gebruikt; een veelvoorkomend voorbeeld kan zijn om aan te geven welke pagina met gegevens je wilt via een page=4 parameter. Als meerdere parameters nodig zijn, kunnen ze worden gekoppeld met een ampersand.

Nu de URL is opgesplitst in zijn componenten, kan de browser beginnen uit te zoeken hoe en waar hij de gevraagde informatie kan vinden. De "hoe" is natuurlijk het protocol, in dit geval het HTTPS-protocol. Het volgende deel is uitzoeken waar de informatie kan worden opgehaald.

De juiste server vinden

Om de juiste computer te vinden die de informatie bedient, moet de domeinnaam door de browser worden gebruikt om een Domain Name System (DNS)-lookup uit te voeren. Op dit moment heeft de browser een naam, maar wat het nodig heeft is een Internet Protocol (IP)-adres. Dit kan worden vergeleken met een postadres in de fysieke wereld. Dit adres vertelt ons waar iets is, maar niet in absolute termen. Hiervoor moeten we de coördinaten weten. Een DNS-lookup stelt ons in staat om dit postadres om te zetten in de juiste coördinaten. Dit betekent simpelweg dat we een willekeurige set getallen kunnen koppelen aan een adres dat we kunnen onthouden en typen, omdat we anders elke keer dat we kattenvideo's op internet willen kijken, een set getallen zouden moeten onthouden in plaats van een eenvoudige naam.

Maar waarom moeten we het absolute adres krijgen in plaats van alleen een relatief adres te gebruiken? Goede vraag. Wanneer je computer met een server praat, moet het een exacte verbinding tot stand brengen, net zoals het bellen van een specifiek telefoonnummer. Op deze manier kunnen er veel computers zijn die dezelfde domeinnaam gebruiken, en een ander absoluut adres zal aan de browser worden gegeven. Dit is hetzelfde als wanneer je een noodnummer belt. In veel delen van de wereld is dit 112. Maar als je dit nummer zou bellen, krijg je de noodlijn van je eigen land, niet die van een ander land. Dit gebeurt door dynamisch te kijken naar wat het dichtstbijzijnde gerelateerde centrum zou zijn. Hetzelfde kan worden gedaan bij het bezoeken van websites, omdat het niet veel zin heeft om een enkele server in de wereld te hebben voor een enorme website. Vooral als het beperkt zou zijn tot een enkele locatie in de wereld, zou de latentie ongelooflijk lang zijn. Er zijn meer redenen waarom, maar dit is mijn favoriet.

De domeinnaam zelf bestaat uit een hiërarchie die begint aan het einde met een top-level domain (TLD). Dit is vaak ofwel een generiek top-level domain, zoals com en org, of een landcode top-level domain, voorbeelden hiervan zijn nl en de. Deze worden dan voorafgegaan door de naam die je registreert bij een domeinnaamregistrar. In mijn geval is mijn naam rondekker. Optioneel kun je er meer subdomeinen aan toevoegen. Je bent misschien gewend om www vaak te zien in de websites die je bezoekt, wat een goed voorbeeld is van een subdomein.

De manier waarop je computer het exacte IP-adres achterhaalt, is door een eenvoudig proces te doorlopen. Zodra een stap niet weet waar de domeinnaam zich bevindt, gaat het verder naar de volgende stap.

1. De browser controleert zijn eigen tijdelijke lijst, ook wel een cache genoemd, van domeinnamen die het recent heeft gecontroleerd om te zien of het het adres al kent. Dit wordt gedaan omdat het openen van de lokale opslag van je computer vele malen sneller is dan het netwerk vragen.
2. De browser controleert de cache van het besturingssysteem. Als het de domeinnaam kent, heeft misschien een ander programma op de computer het recentelijk opgevraagd en heeft het besturingssysteem het nog opgeslagen.
3. De browser vraagt een andere server waarvan je computer het adres al kent, een zogenaamde DNS Resolver. Deze kunnen vooraf geconfigureerd zijn in je computer of netwerkrouter. Bijvoorbeeld 8.8.8.8 beheerd door Google of 1.1.1.1 beheerd door CloudFlare. Deze DNS resolver fungeert als tussenpersoon en probeert een lijst van domeinen en hun adressen in zijn cache te houden.
4. Als de DNS Resolver het IP-adres niet in zijn cache heeft, kan het vervolgens de Root naamserver vragen waar het informatie kan opvragen over top-level domeinen als het dit nog niet weet. De DNS Resolver kan dan de TLD naamserver vragen naar de Authoritative naamserver voor het domein. De Authoritative naamserver kan dan uiteindelijk reageren met het IP-adres dat de browser zoekt.

Uiteindelijk zal de DNS resolver, als alles goed gaat, het IP-adres van waar het domein wordt gehost en de informatie kan worden gevonden aan je browser retourneren.

Een beveiligde verbinding tot stand brengen met TLS

Nu we weten waar de computer is die de website bedient, moeten we een beveiligde verbinding tot stand brengen voordat we de informatie opvragen. Dit wordt gedaan met behulp van het Transport Layer Security (TLS)-protocol, dat ervoor zorgt dat de gegevens die tussen je browser en de server worden uitgewisseld, beveiligd zijn. TLS is een cryptografisch protocol dat is ontworpen om veilige communicatie over een computernetwerk te bieden. Dit is belangrijk omdat het de privacy en integriteit van de overgedragen gegevens garandeert, waardoor afluisteren en knoeien worden voorkomen.

1. Wanneer je browser verbinding maakt met een server, stuurt het een "ClientHello"-bericht. Dit bericht bevat informatie zoals de TLS-versie en de ondersteunde versleuteling algoritmen (cipher suites) door de browser.
2. De server reageert met een "ServerHello"-bericht, waarin de TLS-versie en cipher suite worden geselecteerd die zowel de server als de client ondersteunen. De server stuurt ook zijn digitale certificaat, dat de openbare sleutel van de server bevat en wordt uitgegeven door een vertrouwde Certificate Authority (CA).
3. De browser verifieert het certificaat van de server aan de hand van een lijst van vertrouwde CA's. Als het certificaat geldig is, genereert de browser een "pre-master secret" en versleutelt het met de openbare sleutel van de server.
4. Zowel de browser als de server gebruiken het pre-master secret om sessiesleutels te genereren. Deze sleutels worden gebruikt om de gegevens die tijdens de sessie worden uitgewisseld te versleutelen en te ontsleutelen.
5. Zowel de browser als de server sturen een bericht naar elkaar om te bevestigen dat toekomstige communicatie versleuteld zal zijn met deze sessiesleutels. Dit wordt vaak het Finished-bericht genoemd in de TLS-handshake.

Dit proces, hoewel het ingewikkeld lijkt, vindt plaats in milliseconden, waardoor je gegevens privé en veilig blijven terwijl ze over het internet worden verzonden. Het begrijpen van TLS is cruciaal omdat het de beveiligde verbindingen ondersteunt die gebruikersgegevens beschermen en vertrouwen in online communicatie behouden. De meeste browsers tonen het succesvolle gebruik van TLS met een klein slotje naast de URL van de webpagina waarop je je bevindt. Moderne browsers geven nu ook een waarschuwing voordat de pagina wordt geladen als een website geen beveiligde verbinding ondersteunt. Gelukkig is het nu standaard geworden voor alle websites om dit correct in te stellen dankzij non-profitorganisaties zoals Let's Encrypt.

Nu de verbinding is tot stand gebracht, kunnen we verder ingaan op het protocol dat TLS gebruikt, namelijk het eerder genoemde HTTPS-protocol.

Leer het HTTPS protocol kennen

Nu de gegevensoverdracht aan de gang is, is het belangrijk om het gebruikte protocol te begrijpen, het Hypertext Transfer Protocol Secure (HTTPS). HTTPS is de veilige versie van HTTP, het protocol waarover gegevens worden verzonden tussen je browser en de website waarmee je bent verbonden. HTTPS gebruikt het eerder genoemde TLS om gegevens te versleutelen, zodat ze niet kunnen worden gelezen of gewijzigd door derden. Dit biedt niet alleen privacy, maar ook gegevensintegriteit en authenticatie.

HTTP, of Hypertext Transfer Protocol, is de basis van elke gegevensuitwisseling op het web. Het is een protocol dat wordt gebruikt voor het verzenden van hypertextverzoeken en informatie tussen servers en browsers. HTTP werkt op de toepassingslaag van de internetprotocolsuite (TCP/IP) en is essentieel voor het laden van webpagina's en het interactie met webdiensten.

Wanneer je een URL in je webbrowser invoert, wordt een HTTP-verzoek naar de server gestuurd die de website host. Dit verzoek bevat verschillende details, zoals het type verzoek, het pad naar de bron en eventuele extra headers die meer informatie over het verzoek bieden. De server verwerkt dit verzoek en stuurt een HTTP-antwoord terug, dat de gevraagde bron (zoals een HTML-pagina, afbeelding of JSON-gegevens) en statusinformatie bevat die aangeeft of het verzoek succesvol was. Een HTTP-verzoek kan er bijvoorbeeld als volgt uitzien:

GET /index.html HTTP/1.1
Host: rondekker.nl

En in reactie hierop kan een server antwoorden met dit:

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 96

<!DOCTYPE html>
<html>
  <head><title>Ron Dekker</title></head>
  <body>Welcome to rondekker.nl!</body>
</html>

Zoals het voorbeeld laat zien, definieert HTTP headers die sleutel-waardeparen zijn die samen met zowel verzoeken als antwoorden worden verzonden. Ze bieden essentiële informatie over het verzoek of antwoord, zoals inhoudstype, inhoudslengte, serverinformatie en cache-instructies.

Een belangrijk concept van HTTP is dat elk verzoek van een client naar een server onafhankelijk is. Dit betekent dat de server geen informatie over eerdere verzoeken behoudt. Hoewel dit het ontwerp van de server vereenvoudigt en grotere schaalbaarheid mogelijk maakt, vereist het aanvullende mechanismen, zoals cookies of sessies, om staatvolle interacties te behouden wanneer dat nodig is.

Daarnaast specificeert HTTP een reeks verzoekmethoden om de gewenste actie aan te geven die op de geïdentificeerde bron moet worden uitgevoerd. Deze methoden kunnen een van de volgende zijn:

• De OPTIONS methode beschrijft de communicatie-opties voor de doelbron, vaak gebruikt voor het controleren van ondersteunde HTTP-methoden of CORS (Cross-Origin Resource Sharing) preflight verzoeken. Een OPTIONS-verzoek aan /api/ kan worden gebruikt om de ondersteunde methoden van de API te bepalen. Deze methode is veilig en idempotent.
• De GET methode haalt gegevens op van een opgegeven bron, vaak gebruikt voor het openen van webpagina's en het downloaden van bestanden. Bijvoorbeeld, een GET-verzoek kan worden verzonden naar /artikelen/ om de lijst met artikelen op te halen. Het wordt beschouwd als veilig en idempotent, wat betekent dat het de bron niet wijzigt en meerdere keren kan worden opgeroepen zonder de uitkomst te veranderen.
• De HEAD methode haalt headers op voor een bron zonder de antwoordbody, vergelijkbaar met GET. Het is handig om te controleren of een bron bestaat of om headers te inspecteren voordat een groot bestand wordt gedownload. Een voorbeeld van een HEAD-verzoek aan /artikelen/ kan worden gebruikt om het bestaan van de artikelenbron te controleren. Deze methode is veilig en idempotent.
• De POST methode verzendt gegevens om te worden verwerkt naar een opgegeven bron, meestal gebruikt voor formulierinzendingen en het maken van nieuwe records in een database. Een voorbeeld van een POST-verzoek kan worden verzonden naar /gebruikers/ om een nieuw gebruikersaccount te maken. In tegenstelling tot GET is POST niet idempotent; het meerdere keren aanroepen kan leiden tot verschillende uitkomsten, zoals het maken van meerdere records.
• De PUT methode werkt een bron bij of maakt deze aan op een opgegeven URL. Het wordt vaak gebruikt voor het bijwerken van gebruikersprofielen of het uploaden van bestanden naar een specifieke locatie. Bijvoorbeeld, een PUT-verzoek aan /gebruikers/123/ kan de informatie voor gebruiker 123 bijwerken. Deze methode is idempotent, dus meerdere identieke verzoeken zullen hetzelfde resultaat opleveren.
• De PATCH methode past gedeeltelijke wijzigingen toe op een bron. Het wordt gebruikt voor het bijwerken van specifieke velden van een bron zonder de hele bron te beïnvloeden. Bijvoorbeeld, een PATCH-verzoek aan /gebruikers/123/ kan alleen het e-mailadres van gebruiker 123 bijwerken. Deze methode is niet noodzakelijk idempotent, omdat het afhangt van de toegepaste wijzigingen.
• De DELETE methode verwijdert een opgegeven bron, zoals het verwijderen van een gebruikersaccount of een bestand. Een DELETE-verzoek aan /gebruikers/123/ zou gebruiker 123 verwijderen. Deze methode is idempotent, wat betekent dat meerdere identieke verzoeken hetzelfde effect hebben.

HTTP is in de loop van de tijd geëvolueerd om de prestaties, beveiliging en mogelijkheden te verbeteren.

• HTTP/1.1 introduceerde persistente verbindingen, chunked transfer encoding en verbeterde cachecontrolemechanismen. Persistente verbindingen maken het mogelijk om meerdere verzoeken en antwoorden via een enkele verbinding te verzenden, waardoor de latentie die gepaard gaat met het opzetten van nieuwe verbindingen, wordt verminderd.
• HTTP/2 bracht aanzienlijke prestatieverbeteringen, waaronder multiplexing, waarmee meerdere verzoeken en antwoorden gelijktijdig via een enkele verbinding kunnen worden verzonden. Dit vermindert de latentie en verbetert de laadtijden van pagina's. HTTP/2 maakt ook gebruik van headercompressie om de overhead van headers te verminderen, waardoor gegevensoverdracht efficiënter wordt.
• HTTP/3 gebruikt het QUIC-transportprotocol, dat werkt via UDP in plaats van TCP. Dit vermindert de verbindingsopzettijden en verbetert de prestaties, vooral op onbetrouwbare netwerken. QUIC gaat efficiënter om met pakketverlies, wat resulteert in snellere en betrouwbaardere verbindingen.

Door HTTP en de evolutie ervan te begrijpen, kun je hopelijk waardering krijgen voor de rol die het speelt in webcommunicatie en hoe verbeteringen in het protocol blijven bijdragen aan een betere gebruikerservaring.

De server vragen om informatie

Met een beveiligde verbinding tot stand gebracht, kan de browser nu de server vragen om de informatie. De browser stuurt een verzoek over deze verbinding, inclusief de URL en extra headers. De server kan dan het verzoek verwerken en reageren met de gevraagde gegevens, als deze beschikbaar zijn en mogen worden verstrekt.

De server kan een reactie op verschillende manieren afhandelen. Laten we nu denken aan een eenvoudig scenario waarin de server een bestand op de computer heeft genaamd index.html in een /artikelen/web-prestaties/hoe-laden-browsers-webpaginas/ directory. De server kan dan dit bestand nemen en het simpelweg beginnen te verzenden naar de browser. Als de reactie groter is dan een paar kilobytes, zal het meer dan één reactie van de server vergen om de browser alle gegevens te leveren. Maar dit betekent niet dat de browser stil blijft zitten; het zal onmiddellijk beginnen met het verwerken van de gegevens.

De eerste reactie bevat waarschijnlijk enkele headers. Deze worden eerst gelezen om te bepalen wat de server terugstuurt. De browser stuurt waarschijnlijk informatie in de headers dat het HTML kan verwerken; de server kan dan reageren met informatie in de header dat het inderdaad HTML verzendt en dat het verzoek succesvol was. Dit betekent dat de browser de gegevens die volgen kan nemen en beginnen weer te geven.

Inhoud weergeven op het scherm

De eerste stap in het ontleden van de HTML-gegevens is het creëren van de structuur van de pagina. Hiermee kan de browser beginnen met het renderen van elementen op het scherm. De browser wil dit zo snel mogelijk doen, en de manier waarop dit gebeurt is door het gebruik van het zogenaamde critical rendering path.

De critical rendering path is de reeks stappen die een browser onderneemt om de initiële zichtbare inhoud van een webpagina zo snel mogelijk weer te geven. Het omvat de belangrijkste processen en bronnen die nodig zijn om het gedeelte van de webpagina dat aanvankelijk zichtbaar is in het viewport zonder te scrollen, bekend als de above-the-fold content, weer te geven. Het is daarom cruciaal voor het optimaliseren van webprestaties en gebruikerservaring, omdat het bepaalt hoe snel gebruikers de inhoud van een webpagina kunnen waarnemen en ermee kunnen interageren. Door de laadtijd en weergave van kritieke bronnen te prioriteren, kunnen browsers de waargenomen laadtijden minimaliseren en de algehele ervaring verbeteren. Het critical rendering path omvat de stappen en fasen zoals hieronder beschreven.

• HTML-parsing: De browser ontleedt het HTML-document dat van de server is ontvangen om het Document Object Model (DOM) te construeren, dat de structuur van de inhoud van de webpagina vertegenwoordigt. HTML-parsing omvat het ontleden van individuele elementen en het opbouwen van een boomstructuur die kan worden gemanipuleerd en weergegeven door de browser.
• CSS-parsing: Terwijl de browser het HTML-document ontleedt, verwerkt en ontleedt het ook gekoppelde CSS-stylesheets of ingesloten stijlblokken, die de stylingregels vertegenwoordigen die op elk element op de pagina worden toegepast. CSS-parsing omvat het oplossen van selectors, het berekenen van specificiteit en het toepassen van stijlen op de overeenkomstige elementen om hun visuele uiterlijk en lay-out te bepalen.
• Render tree constructie: Zodra het document en de stijlen zijn berekend, combineert de browser ze om de render tree te creëren, die de visuele hiërarchie van de inhoud van de webpagina vertegenwoordigt. De render tree bestaat alleen uit de elementen die op het scherm zullen worden weergegeven, met uitzondering van niet-zichtbare elementen zoals script tags of andere verborgen elementen.
• Lay-out: De browser voert vervolgens lay-outberekeningen uit om de positie, grootte en stijl van elk element in de render tree ten opzichte van het viewport te bepalen. Dit proces omvat het berekenen van de afmetingen van block-level en inline elementen op basis van hun inhoud, stijlen en positioneringseigenschappen. Lay-outberekeningen zijn nodig om de initiële visuele lay-out van de webpagina vast te stellen. Wanneer het document is gewijzigd, wordt dit proces vaak ook reflow genoemd.
• Painting: Zodra de lay-outberekeningen zijn voltooid, schildert de browser de pixels op het scherm om de visuele weergave van de webpagina weer te geven. Painting omvat het invullen van de pixels van elk element met de juiste kleuren, texturen en effecten volgens de gespecificeerde stijlen en lay-out eigenschappen. De geschilderde elementen worden vervolgens samengevoegd om het uiteindelijke gerenderde beeld te creëren.

Daarna is de pagina bijna klaar en worden scripts ge-parsed en uitgevoerd. Deze scripts kunnen de documentstructuur en styling manipuleren, wat de render tree en daaropvolgende reflow en painting beïnvloedt. Dit gedrag kan dynamische inhoudgeneratie, gebeurtenisafhandeling en het wijzigen van structuur of stijlen op basis van gebruikersinteracties of andere triggers omvatten. De volgende vraag die we onszelf moeten stellen is hoe de browser al deze bronnen ontdekt en wanneer deze worden geladen.

Bronontdekking en inladen

Aangezien er meer op een webpagina staat dan alleen HTML, is het belangrijk om te weten hoe en wanneer deze bronnen worden ontdekt en geladen. Een webpagina kan styling direct bevatten, maar vaker is het opgesplitst in een apart bestand en alleen verwezen met behulp van een link-tag in de structuur van de webpagina. Bijvoorbeeld, een eenvoudige pagina die een grappige kattenafbeelding met wat styling en interactie weergeeft, kan er als volgt uitzien:

<!DOCTYPE html>
<html>
  <head>
    <link rel="stylesheet" href="style.css">
    <script src="script.js"></script>
  </head>
  <body>
    <img src="kat.jpg" alt="Een kat met het hoofd door een sneetje brood.">
  </body>
</html>

De manier waarop de browser dit leest, is dat het eerst kijkt naar de head-tag en de inhoud daarvan. Het begint bovenaan en zal de eerste bron tegenkomen, wat in dit geval een link naar een stylesheet is. De browser zal deze bron dan laden en doorgaan naar de script-tag, waarbij wordt gezien dat er een extra bestand nodig is. Wanneer dat is geladen, gaat het verder naar de body-tag. Dit bevat natuurlijk het belangrijkste element: onze grappige kattenfoto. Het belangrijkste punt is dat voor elke externe bron de browser een extra netwerkverzoek moet doen, vergelijkbaar met wanneer het de HTML van de pagina opvroeg.

Prestaties verbeteren bij een volgende keer met caching

Alle geladen bronnen kunnen natuurlijk ook worden gecachet, wat afhankelijk is van wat de server antwoordt in de headers van het antwoord. Dit betekent dat de volgende keer dat de gebruiker de pagina bezoekt, het de stylesheet of andere bron al gedownload heeft, waardoor de tweede keer dat de pagina wordt bezocht veel sneller is.

In het voorbeeld moet de gebruiker natuurlijk wachten tot de stylesheet en het script zijn geladen voordat de afbeelding wordt gedownload en weergegeven. Hier komen we het eerste punt tegen waarop we de gebruikerservaring kunnen verbeteren. Aangezien er niets te interageren valt voordat de body is ontleed en weergegeven, kunnen we het script naar beneden in de body-tag verplaatsen. Dit is waar ik me op wil richten: hoe worden bronnen ontdekt en hoe kun je dit proces beïnvloeden.

Invloed uitoefenen op bronontdekking en inladen

De volgorde van tags, zoals eerder genoemd, is het eerste wat invloed heeft op de ontdekking van bronnen. Hoe verder naar beneden op de pagina, hoe later de bronnen worden gevonden en hoe later ze door de browser kunnen worden opgehaald, wat in sommige scenario's precies is wat je wilt. Maar dit kan verder worden aangepast om deze van boven naar beneden laadbenadering te doorbreken met behulp van verschillende attributen.

Vervolgens kunnen we het loading-attribuut gebruiken om lazy loading te benutten. Lazy loading is een techniek die het laden van niet-essentiële bronnen uitstelt totdat ze nodig zijn, meestal geactiveerd door gebruikersinteracties zoals scrollen of klikken. Door het laden van off-screen of below-the-fold content uit te stellen, minimaliseert lazy loading de initiële paginalaadtijd en vermindert het de hoeveelheid over het netwerk verzonden gegevens.

Een async-attribuut kan worden geplaatst op een script-tag. Dit geeft aan dat de browser het script asynchroon moet downloaden, waardoor het HTML-parsering- en renderingsproces zonder blokkering kan doorgaan terwijl het script wordt opgehaald. Het zal echter worden uitgevoerd zodra het beschikbaar is.

Op dezelfde manier instrueert het defer-attribuut, wanneer geplaatst op een script-tag, de browser om de download van het scriptbestand onmiddellijk te starten. De uitvoering van het script wordt echter uitgesteld tot na de HTML-parsering is voltooid. Als dit op een script-tag wordt geplaatst met het async-attribuut, negeert het het defer-attribuut en handelt het alsof alleen het async-attribuut is geplaatst.

Voordat een verwijzing naar een bron wordt gemaakt, kan de browser vooraf een verbinding met de server starten met behulp van het rel=preconnect-attribuut op een link-tag. Dit informeert de browser om vroegtijdig een verbinding tot stand te brengen met een opgegeven domein in afwachting van toekomstige bronverzoeken. Deze preconnect-hint stelt de browser in staat om de noodzakelijke netwerkverbindingen proactief tot stand te brengen, waardoor de latentie voor volgende bronverzoeken wordt verminderd.

Een zeer nauw verwante hiervan is het rel=dns-prefetch-attribuut. Dit voert een DNS-lookup uit van de opgegeven domeinnaam, maar zal nog geen verbinding met de server tot stand brengen, alleen wanneer de bron ervan zal worden geladen.

Dan hebben we het rel=prefetch-attribuut. Dit vertelt de browser om een opgegeven bron op de achtergrond op te halen en te cachen, zonder deze onmiddellijk weer te geven of uit te voeren. Met dit prefetch-mechanisme kan de browser proactief bronnen ophalen die waarschijnlijk in de toekomst nodig zullen zijn.

Een andere variant hiervan is het rel=preload-attribuut. Dit instrueert de browser om een opgegeven bron zo vroeg mogelijk tijdens het pagina laadproces op te halen en te cachen. Preload wordt gebruikt om bronnen aan te geven die cruciaal zijn voor het weergeven van de huidige pagina of aankomende interacties en moet prioriteit krijgen voor vroegtijdige ophalen en cachen.

Bronnen kunnen ook door andere bronnen worden geladen. Bijvoorbeeld, een lettertype kan worden opgegeven in een stylesheet. Dit kan alleen worden bepaald wanneer de stylesheet is geladen en het lettertype wordt gebruikt op de webpagina. Maar met behulp van het eerder genoemde preload-attribuut kunnen we dit versnellen door de browser te laten weten dat we dit zo snel mogelijk nodig hebben. Het tegenovergestelde geldt natuurlijk ook, we kunnen het laden van minder belangrijke bronnen uitstellen door ze achter een andere bron te plaatsen. Bijvoorbeeld, je kunt een script uitvoeren dat de pagina wijzigt en extra bronnen toevoegt, of het haalt gegevens op.

Service workers en hun rol in prestaties

Service workers zijn een krachtige functie die de webprestaties en gebruikerservaring aanzienlijk kan verbeteren. Een service worker is een script dat op de achtergrond draait, los van de webpagina, en functies mogelijk maakt die geen webpagina of gebruikersinteractie vereisen. Het begrijpen van hoe service workers werken is cruciaal omdat ze de prestaties, betrouwbaarheid en mogelijkheden van je webapplicaties kunnen verbeteren. Wanneer een gebruiker een website voor de eerste keer bezoekt, downloadt de browser en activeert de service worker. Dit proces omvat het downloaden van het service worker script en het registreren ervan bij de browser.

Service workers kunnen vervolgens netwerkverzoeken onderscheppen en antwoorden uit een cache bedienen. Hierdoor kunnen ontwikkelaars cachestrategieën implementeren, zoals het cachen van statische bronnen tijdens de installatie en het bedienen ervan vanuit de cache voor volgende verzoeken. Dit vermindert de noodzaak om bronnen van het netwerk op te halen, waardoor laadtijden worden verkort en gegevensgebruik wordt verminderd. Door kritieke bronnen te cachen, stellen service workers websites in staat om offline te functioneren. Wanneer de gebruiker offline is, kan de service worker gecachte inhoud bedienen, wat zorgt voor een naadloze ervaring, zelfs zonder internetverbinding.

Door te beheren hoe en wanneer bronnen worden opgehaald en gecachet, kunnen service workers de laadtijden aanzienlijk verkorten, vooral bij herhaalde bezoeken. Dit leidt tot een responsievere en snellere website, waardoor de algehele gebruikerstevredenheid toeneemt. Service workers kunnen dus een belangrijke rol spelen bij het sneller, betrouwbaarder en capabeler maken van webapplicaties en het bieden van een betere gebruikerservaring.

Webprestaties optimaliseren

Het begrijpen van hoe de browser webpagina's laadt, stelt ons in staat om webprestaties effectief te optimaliseren. Er zijn verschillende strategieën die kunnen worden toegepast om de snelheid en efficiëntie van je website te verbeteren.

Allereerst is het minimaliseren van HTTP-verzoeken cruciaal. Elke bron op een webpagina vereist een HTTP-verzoek. Het verminderen van het aantal van deze verzoeken kan de laadtijden aanzienlijk verbeteren. Dit kan worden bereikt door bestanden te combineren, zoals CSS en JavaScript, het gebruik van CSS sprites om meerdere afbeeldingen in één bestand te combineren, en het inline opnemen van kleine CSS- en JavaScript-bestanden rechtstreeks in de HTML.

Het inschakelen van compressie kan ook de grootte van HTML-, CSS- en JavaScript-bestanden verminderen. Het gebruik van Gzip- of Brotli-compressie op je server zorgt ervoor dat gecomprimeerde versies van bestanden worden bediend, waardoor de gegevensoverdrachtstijden worden verkort.

Het benutten van browsercaching is een andere belangrijke strategie. Caching stelt browsers in staat om bronnen lokaal op te slaan, waardoor herhaalde verzoeken worden verminderd. Dit kan worden gecontroleerd met behulp van HTTP-headers zoals Cache-Control, die cachebeleid specificeren, Expires, die een vervaldatum instellen voor gecachte bronnen, en ETag, waarmee browsers gecachte bronnen met de server kunnen valideren.

Het prioriteren van above-the-fold inhoud zorgt ervoor dat de inhoud die zichtbaar is voor gebruikers zonder te scrollen als eerste wordt geladen. Dit verbetert de waargenomen prestaties en gebruikerservaring. Kritieke CSS kan inline worden opgenomen, en JavaScript kan asynchroon worden geladen of worden uitgesteld tot na de HTML-parsering is voltooid.

Het optimaliseren van afbeeldingen is essentieel omdat ze vaak de grootste middelen op een webpagina zijn. Het gebruik van moderne afbeeldingsformaten zoals WebP voor betere compressie, het opnieuw schalen en comprimeren van afbeeldingen tot de juiste afmetingen voordat ze worden geüpload, kan de laadtijden drastisch verkorten, als het Content Management Systeem of bouwsysteem dit nog niet automatisch voor je doet. Daarnaast zorgt het gebruik van responsieve afbeeldingen en het srcset-attribuut ervoor dat verschillende afbeeldingen worden bediend op basis van de resolutie van het apparaat, wat zorgt voor optimale prestaties.

Ten slotte is het regelmatig monitoren van prestaties cruciaal om problemen te identificeren en aan te pakken. Tools zoals Google Lighthouse, PageSpeed Insights en WebPageTest kunnen worden gebruikt om prestatiestatistieken te analyseren. Het instellen van Real User Monitoring (RUM) verzamelt gegevens over echte gebruikerservaringen, waardoor gegevensgestuurde optimalisaties mogelijk zijn.

Core Web Vitals

Core Web Vitals zijn cruciale statistieken die door Google zijn geïntroduceerd om problemen met de gebruikerservaring bij het bezoeken van een webpagina te meten en kwantificeren. Deze omvatten statistieken zoals Cumulative Layout Shift (CLS), First Contentful Paint (FCP), Largest Contentful Paint (LCP) en Time to Interactive (TTI). Het begrijpen en optimaliseren van deze statistieken is essentieel voor het verbeteren van webprestaties en daarmee de gebruikerservaring.

Geweldig, en nu?

Nu je begrijpt hoe de browser webpagina's laadt en hoe je invloed kunt uitoefenen op de bronnen die door de browser worden geraadpleegd, raad ik aan om de ontwikkelaarstools van je browser te openen en enkele pagina's opnieuw te laden. Netwerkvertraging kan helpen te zien hoe het proces werkt en geeft een overzicht van alle bronnen die worden geladen en wanneer deze worden opgehaald. Met deze kennis zou je in staat moeten zijn om je websites en online applicaties te optimaliseren, waardoor snellere en efficiëntere ervaringen voor je gebruikers worden geboden.

Meer lezen

• Waarom de snelheid van jouw website verbeteren?