Kort samengevat: rendervertraging
- Rendervertraging is de tijd tussen het moment dat de browser de HTML ontvangt en het moment dat de gebruiker de voltooide pagina ziet. Op bijna elke moderne site wordt dit gedomineerd door JavaScript-executie, niet door netwerktransport.
- De grootste boosdoener zijn synchrone third-party-scripts geladen in de head: tag manager, analytics en chatwidgets die het commit van de renderboom blokkeren.
- Web Vitals-metrieken (LCP, FID, INP) meten de observeerbare symptomen, maar vertellen niet welk specifiek script je pagina vertraagt. In-sessie-monitoring van script-execution-timing wel.
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.
Als het trage deel de download zelf is, controleer dan eerst de eenheid voordat je cijfers vergelijkt. Een browser die MB/s toont en een internetabonnement dat in Mbps wordt verkocht gebruiken verschillende eenheden; Mbps, Mb/s en MB/s hebben een 8-op-1-conversie nodig.
Lazy loading
Lazy loading is een techniek die webontwikkelaars gebruiken om het laden van niet-belangrijke onderdelen van de pagina uit te stellen. Dingen zoals afbeeldingen, video’s en ingesloten content laden meestal als laatste, of pas wanneer ze daadwerkelijk nodig zijn op de pagina. In plaats van gretig 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 toe scrolt. Doordat niet al deze content elke keer wordt geladen, is de initiële paginalading veel sneller en voelt lichter aan.
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 het perspectief van de gebruikerservaring is lazy loading duidelijk voordelig: je ziet de 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 op de pagina) 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.
Zie het op je eigen site
Rendervertraging wordt vaak toegeschreven aan netwerklatentie, maar op moderne sites is de echte oorzaak niet-geauditeerde third-party-JavaScript die het renderpad blokkeert. cside laat precies zien welke scripts je pagina vertragen in elke echte gebruikerssessie. Gratis niveau beschikbaar.
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, ziet de gebruiker helemaal geen woorden.
Prestaties balanceren met ervaring
Webontwikkelaars moeten streven naar de snelst mogelijke pagina zonder de gebruiker te overvallen met ongestylede content, ontbrekende tekst of lange laadtijden. Elk vertraagd element op een pagina moet een goede reden hebben om vertraagd te zijn, en die vertraging moet in de UI worden beheerd met spinners en placeholders.
