Bronnen voor het blokkeren van renders

Render-blocking resources zijn bestanden die een browser moet downloaden en verwerken voordat de inhoud kan worden weergegeven. Het gaat hierbij voornamelijk om stylesheets waarnaar in de documentkop wordt verwezen en synchrone scripts die tijdens het parsen worden aangetroffen. Dit is de meest voorkomende reden waarom een ​​pagina langer nodig heeft om te laden dan de inhoud rechtvaardigt.

Stijlpagina's blokkeren om een ​​begrijpelijke reden. Het weergeven van content voordat de stijlen beschikbaar zijn, zou een flits van ongestylede content opleveren, gevolgd door een abrupte herberekening van de pagina. Daarom wachten browsers. Het probleem is niet dat stijlpagina's blokkeren, maar dat websites doorgaans veel meer stijlen laden dan nodig is voor de initiële weergave. Dit omvat stijlen voor componenten verderop op de pagina, voor andere sjablonen en voor functies die de bezoeker mogelijk nooit zal gebruiken. Al deze stijlen moeten geladen zijn voordat er iets wordt weergegeven.

Scripts worden geblokkeerd omdat een script dat tijdens het parsen wordt aangetroffen het document kan wijzigen. De parser stopt daarom totdat het script is uitgevoerd. De meeste scripts hebben dit gedrag niet nodig: analyses, chatwidgets, personalisatietools en de meeste applicatiecode kunnen na het parsen van het document worden uitgevoerd zonder verlies van correctheid. Door het attribuut `defer` toe te voegen, kan het parsen worden voortgezet en worden de scripts daarna in de juiste volgorde uitgevoerd, terwijl `async` de scripts uitvoert zodra ze binnenkomen, zonder garanties voor de volgorde.

De standaardoplossing voor stylesheets is om de stijlen die nodig zijn voor de initiële weergave te scheiden van de rest. Het cruciale gedeelte wordt direct in het document opgenomen, waardoor er geen verzoek nodig is, en de rest wordt geladen op een manier die de uitvoering niet blokkeert. Dit is effectief, maar voegt complexiteit toe aan het bouwproces, omdat de cruciale set stijlen opnieuw gegenereerd moet worden telkens wanneer stijlen veranderen, en verouderde cruciale CSS zichtbare fouten veroorzaakt.

Externe bronnen zijn vaak de grootste bijdragers en het moeilijkst te controleren. Tagmanagers, toestemmingsplatformen, lettertypeleveranciers, chattools en testframeworks worden doorgaans met blokkerend gedrag aan de documentheader toegevoegd, waarbij elk een verbinding met een aparte bron vereist. De cumulatieve vertraging is aanzienlijk, en omdat elk onderdeel door een ander team om een ​​gerechtvaardigde reden is toegevoegd, is niemand verantwoordelijk voor het totaal. Het controleren van de totale kosten en het toewijzen ervan aan de aanvragende functie maakt de afweging inzichtelijk.

Lettertypen vereisen een speciale behandeling omdat ze de tekstweergave blokkeren in plaats van de paginastructuur. Afhankelijk van de weergavestrategie kan tekst onzichtbaar zijn terwijl een lettertype wordt gedownload, wat betekent dat inhoud die volledig is geladen, opzettelijk wordt achtergehouden. Door een strategie te kiezen die direct fallback-tekst weergeeft en deze vervangt zodra het lettertype is geladen, en door lettertypen die boven de vouw worden gebruikt vooraf te laden, wordt voorkomen dat een pagina technisch gezien wel wordt weergegeven, maar blanco blijft.

Het meten van de werkelijke kosten vereist zorgvuldigheid, omdat het verwijderen van een beperkende factor niet altijd de voorspelde besparing oplevert. Bronnen worden parallel gedownload, dus het elimineren van de ene bron kan er simpelweg voor zorgen dat een andere bron de beperkende factor wordt, en de waargenomen verbetering is vaak kleiner dan de som van de individuele schattingen. Door na elke wijziging metingen uit te voeren in plaats van te vertrouwen op de geprojecteerde totalen, blijven de verwachtingen accuraat.

Met standaardtools is het eenvoudig om vast te stellen wat de voortgang daadwerkelijk belemmert. Deze tools rapporteren de blokkerende factoren en schatten de besparing in die het aanpakken van elke factor zou opleveren. Deze schattingen moeten echter als indicatief en niet als exact worden beschouwd, aangezien het verwijderen van één blokkerende factor vaak aan het licht brengt dat een andere de werkelijke beperking vormde. Verbeteringen kunnen het beste worden geverifieerd door metingen in plaats van te worden afgeleid uit het rapport.

Omdat de benodigde middelen doorgaans in de loop der tijd door verschillende teams worden toegevoegd, vereist herstel zowel governance als engineering. In de praktijk vinden de audit en prioritering plaats binnen de engineeringafdeling. webprestaties werk, de wijzigingen in de build worden geïmplementeerd via productontwikkelingEn beslissingen over welke tools van derden hun blokkeringskosten rechtvaardigen, vereisen overeenstemming met de teams die erom hebben gevraagd, wat voor de meeste sites betekent dat... digitale marketingafdeling.