Als je ooit een moderne webpagina hebt bezocht, merk je dat soms dingen op het scherm (zoals afbeeldingen, invoerelementen, etc.) eerder laden dan andere delen van de site. Webpagina’s laden vaak in fasen, waarbij sommige dingen pas verschijnen na een initiële vertraging. Dit gefaseerd laden kan opzettelijk zijn om de prestaties van de site te verbeteren, maar kan ook gewoon een bijeffect zijn van hoe je browser de pagina verwerkt.
Lazy loading
Lazy loading is een techniek die webontwikkelaars gebruiken om het laden van niet-belangrijke dingen op de pagina uit te stellen. Zaken als afbeeldingen, video’s en ingesloten content laden meestal als laatste, of pas wanneer ze daadwerkelijk nodig zijn op de pagina. In plaats van alles in één keer te laden (wat je browser kan verstoppen met een hoop verzoeken), wacht je browser met het laden van content buiten beeld totdat de gebruiker ernaar scrolt. Door niet al deze content elke keer te laden, is de initiële paginalading veel sneller en voelt lichter aan, wat de perceptie van prestaties verbetert.
Bijvoorbeeld, dit blogartikel laadt misschien eerst onze topbanner en auteursicoon, maar stelt het laden van de afbeeldingen onderaan de site uit totdat je ernaartoe scrolt. Dit versnelt de initiële laadtijd, aangezien alleen de eerste afbeelding laadt.
Vanuit gebruikerservaring is lazy loading duidelijk voordelig: je ziet de kritieke en belangrijke dingen sneller, en je bandbreedte wordt niet verspild aan afbeeldingen en video’s die de gebruiker misschien nooit ziet. Dit verbetert de First Contentful Paint van de pagina, wat een browsermetriek is die meet hoe snel het eerste item op het scherm verschijnt.
Er kunnen negatieve implementaties van lazy loading zijn, en het hangt uiteindelijk af van de ontwikkelaar van de pagina om ervoor te zorgen dat ze het goed gebruiken. Bijvoorbeeld, alles boven de vouw (content die zichtbaar is zonder naar beneden te scrollen) zou niet lazy loaded moeten worden. Een andere zorg is layout shifting, wat is wanneer de ruimte van een afbeelding niet is gereserveerd op de pagina en later laadt, waardoor alle content naar beneden wordt geduwd.
Client-side rendering en hydration
Moderne webapps zijn tegenwoordig voornamelijk JavaScript, wat betekent dat content vaak wordt gerenderd en daarna aan de gebruiker wordt getoond. In client-side rendering (CSR) frameworks zoals React, Angular en Vue stuurt de server een heel kale HTML-pagina, en wacht vervolgens tot de browser de content genereert. Dit betekent dat je bij de eerste laadactie van een pagina mogelijk alleen een leeg scherm of een laadspinner ziet terwijl de browser de content downloadt en genereert.
Deze implementatie kan vaak leiden tot een negatieve perceptie van de prestaties van je site, omdat gebruikers kunnen denken dat er niets laadt of dat het te lang duurt om überhaupt te laden. De First Contentful Paint metriek waar we het eerder over hadden kan aanzienlijk worden vertraagd in een pure CSR-situatie, omdat er niets betekenisvols op de pagina verschijnt tot veel, veel later.
Dit oplossen met Server-Side Rendering
Om enkele van de wachtvertragingen van client-side rendering te verminderen, gebruiken veel webframeworks Server-Side Rendering (SSR). Dit betekent dat een server een volledig ontwikkelde webpagina naar je browser stuurt (zodat je direct content ziet), en deze later hydrateert met meer interactieve elementen.
Hydration vereist nog steeds het genereren van die client-side browsercontent, maar het betekent dat je gebruikers ondertussen niet naar een leeg scherm staren. Dit verbetert de waargenomen prestaties van je pagina en leidt tot minder denken van “waarom is deze pagina zo traag?”.
Dat gezegd hebbende, SSR en hydration kunnen nog steeds problemen introduceren op een site als ze niet goed worden geïmplementeerd. Het probleem van content flickering is wanneer de server de gebruiker niet kent of welke context ze al hebben (zoals of een gebruiker al is ingelogd of niet), en als resultaat geeft het ze een generieke versie van de site. Zodra de site is gehydrateerd en realiseert dat de gebruiker wel is ingelogd, kan het delen van de UI vervangen met gepersonaliseerde of bijgewerkte content. Hoewel niet zo erg als een volledig lege pagina, kunnen deze mid-stream contentwijzigingen afleidend zijn en de gebruiker tijdelijk verwarren.
Vanuit gebruikerservaring is het doel om de vertraging te minimaliseren voordat gebruikers nuttige content zien. Als je CSR gebruikt, is het essentieel om je JavaScript slank te houden en een goed ontworpen laadindicator of skeleton toe te voegen zodat je gebruikers weten dat er content onderweg is. Nog beter, het gebruik van SSR voor de initiële weergave zorgt ervoor dat gebruikers eerst iets zien, en hun content daarna krijgen.
Bronnen die renders blokkeren
Niet alle vertragingen komen door scripts, en kunnen ook komen van hoe je browser omgaat met kritieke bronnen zoals CSS en fonts. Browsers weten niet inherent om deze te prioriteren, of realiseren misschien niet dat de content is gestyled tot later, wat leidt tot content die flasht op je pagina met het verkeerde font of de verkeerde stijl.
CSS is de meest klassieke van de render-blocking problemen. Meestal stelt de browser het renderen van de content van de pagina uit totdat de CSS is gedownload en verwerkt, maar als je CSS-bestand te groot of te complex is, zullen alle elementen die afhankelijk zijn van dat CSS-bestand laat verschijnen tot het is geladen. Ervoor zorgen dat je CSS is geoptimaliseerd en basislay-outstyling op je site bestaat, zorgt ervoor dat de content vroeg verschijnt en verbetert de waargenomen laadtijd van de gebruiker.
Het font van een site kan ook de verschijning van tekst vertragen, maar vaak op subtielere manieren. Wanneer een site een custom font gebruikt (via @font-face, of zoiets als Google Fonts), gaan browsers er voorzichtig mee om ervoor te zorgen dat een fallback font niet verschijnt. Browsers implementeerden “de flash van onzichtbare tekst”, wat betekent dat tekst is verborgen totdat het fontbestand is geladen. Tekst is er eigenlijk, op de pagina, je kunt het alleen niet zien. En als je font te lang duurt om te laden, zou de gebruiker geen woorden kunnen zien, wat niet leidt tot een ideale ervaring voor hen.
Prestaties balanceren met ervaring
Kortom, het is altijd belangrijk voor webontwikkelaars om de snelste pagina te bieden, zonder de gebruiker te schrikken met ongestylede content, missende tekst of lange laadtijden. Elk vertraagd element op een pagina moet een goede reden hebben om vertraagd te zijn, en de vertraging moet worden beheerd in de UI door spinners en placeholders.
Door de technische redenen achter deze vertraagde verschijningen te begrijpen, kunnen ontwikkelaars betere beslissingen nemen over hoe ze hun content willen laden - en de ervaring voor hun gebruikers verbeteren.
