Kritisch renderingpad

Het kritieke renderingpad is de reeks stappen die een browser moet doorlopen tussen het ontvangen van een pagina en het weergeven van inhoud op het scherm. Het omvat het parsen van de markup naar een documentstructuur, het parsen van de stylesheets naar een stijlstructuur, het combineren van beide tot een renderingtree, het berekenen van de lay-out en het tekenen van het resultaat. Inzicht in het kritieke renderingpad verklaart waarom sommige bronnen de eerste weergave van inhoud vertragen en andere niet.

Stijlpagina's blokkeren de weergave opzettelijk, en dit is geen fout. Een browser die de pagina zou laden voordat de stijlen beschikbaar waren, zou ongestylede inhoud weergeven en vervolgens de pagina opnieuw laten renderen, wat erger is dan een korte vertraging. Het praktische gevolg hiervan is dat elke stijlpagina waarnaar in de documentkop wordt verwezen, moet worden gedownload en verwerkt voordat er iets verschijnt. Het aantal, de grootte en de snelheid waarmee stijlpagina's worden geladen, bepalen dus direct wanneer de pagina zichtbaar wordt.

Scripts blokkeren de parser, tenzij anders aangegeven, wat de andere belangrijke bron van vertraging is. Een synchroon script dat tijdens het parsen wordt aangetroffen, onderbreekt de documentconstructie totdat het is gedownload en uitgevoerd, omdat het het document mogelijk wijzigt. Door scripts als 'uitgesteld' te markeren, kan het parsen doorgaan en worden ze uitgevoerd nadat het document is voltooid; door ze als 'asynchroon' te markeren, kunnen ze worden uitgevoerd zodra ze binnenkomen. Het kiezen van het juiste attribuut voor elk script is een van de goedkoopste beschikbare verbeteringen.

Het verkorten van het pad houdt in dat zowel het aantal retourvluchten als de benodigde werkzaamheden in elke fase worden verminderd. Door de stijlen die nodig zijn voor de initiële weergave direct in de code op te nemen, wordt een blokkerend verzoek volledig geëlimineerd, waarna de rest zonder blokkering wordt geladen. Het uitstellen van scripts die niet nodig zijn voor de eerste rendering, het minimaliseren en comprimeren van resources en het elimineren van omleidingen die extra retourvluchten veroorzaken voordat er iets begint, verkorten allemaal de tijd die verstrijkt voordat de eerste weergave plaatsvindt.

Resource hints zorgen ervoor dat de browser eerder aan de slag kan dan wanneer de bron pas op basis van detectie beschikbaar zou zijn. Preloading geeft aan dat een bron die laat in het document wordt gevonden, zoals een lettertype waarnaar wordt verwezen vanuit een stylesheet of een hero-afbeelding die via CSS is toegepast, nodig is, waardoor de download direct begint. Preconnect legt vooraf verbindingen met externe bronnen, waardoor de overhead van de verbinding en de onderhandeling op het cruciale moment wordt weggenomen. Selectief gebruikt, zijn deze functies nuttig; ondoordacht gebruikt, concurreren ze om bandbreedte en maken ze de situatie alleen maar erger.

Lettertypen verdienen specifieke aandacht omdat ze zich in het laadpad bevinden en pas laat worden ontdekt. ​​Een weblettertype waarnaar vanuit een stylesheet wordt verwezen, kan pas worden gedownload nadat die stylesheet is verwerkt. Afhankelijk van de weergavestrategie kan de tekst zelfs onzichtbaar blijven totdat het lettertype is geladen. Door de lettertypen die boven de vouw worden gebruikt vooraf te laden, een weergavestrategie te kiezen die direct fallback-tekst toont en fallback-metrics te gebruiken om herberekeningen te minimaliseren, kunnen deze problemen worden aangepakt.

Client-side rendering verlengt het pad aanzienlijk, waardoor het een doelbewuste oplossing vereist. Wanneer het initiële document geen inhoud bevat en alles door JavaScript moet worden opgebouwd, omvat het pad het downloaden, parsen en uitvoeren van de bundel, en vervolgens het ophalen van gegevens, voordat er iets verschijnt. Server-side rendering of statische generatie voegt betekenisvolle inhoud toe aan het initiële pad, wat de structurele oplossing is in plaats van een optimalisatie.

Omdat het pad wordt bepaald door hoe de pagina is opgebouwd en weergegeven, vereist verbetering meestal wijzigingen in de template en de build, in plaats van in de configuratie. In de praktijk vindt deze analyse plaats binnen webprestaties werk, de implementatie wordt geleverd via productontwikkelingEn wanneer de weergavemethode van een website de onderliggende beperking vormt, wordt de discussie een architectuurdiscussie over hoe pagina's worden geproduceerd, in plaats van een optimalisatieoefening.