Bronhints
Inleiding
In het afgelopen decennium zijn bronhints essentiële primitieven geworden waarmee ontwikkelaars paginaprestaties en dus de gebruikerservaring verbeteren.
Het vooraf laden van bronnen en het laten toepassen van intelligente prioriteiten door browsers is iets dat eigenlijk al in 2009 begon door IE8 met iets genaamd de preloader. Naast de HTML-parser had IE8 een lichtgewicht vooruitkijk-preloader die scande op tags die netwerkverzoeken konden initiëren (<script>, <link>, en <img>).
In de daaropvolgende jaren deden browserverkopers steeds meer van het zware werk, waarbij ze elk hun eigen speciale saus toevoegden voor het prioriteren van bronnen. Maar het is belangrijk om te begrijpen dat de browser alleen enkele beperkingen heeft. Als ontwikkelaars kunnen we deze limieten echter overwinnen door goed gebruik te maken van bronhints en te helpen beslissen hoe bronnen prioriteit moeten krijgen, door te bepalen welke moeten worden opgehaald of voorverwerkt om de paginaprestaties verder te verbeteren.
In het bijzonder kunnen we enkele van de overwinningen noemen die het afgelopen jaar zijn behaald/gemaakt met bronhints:
- CSS-Tricks weblettertypen worden sneller weergegeven bij een eerste 3G-weergave.
- Wix.com met behulp van bronhints kreeg 10% verbetering voor FCP.
- Ironmongerydirect.co.uk gebruikte preconnect om het laden van productafbeeldingen te verbeteren met 400 ms bij de mediaan en meer dan 1 seconde bij het 95e percentiel.
- Facebook.com gebruikte preload voor snellere navigatie.
Laten we eens kijken naar de meest voorkomende bronhints die tegenwoordig door de meeste browsers worden ondersteund: dns-prefetch, preconnect, preload, prefetch, en native lazy loading.
Bij het werken met elke individuele hint adviseren we om altijd de impact voor en na in het veld te meten, door bibliotheken zoals WebVitals te gebruiken, Perfume.js, of een ander hulpprogramma dat de Web Vitals-statistieken ondersteunt.
dns-prefetch
dns-prefetch helpt het IP-adres voor een bepaald domein van tevoren op te lossen. Als de oudste beschikbare bronhint, gebruikt het minimale CPU- en netwerkbronnen in vergelijking met preconnect, en helpt de browser om de “worst-case” vertraging voor DNS-resolutie te vermijden, diemeer dan 1 seconde kan zijn.
<link rel="dns-prefetch" href="https://www.googletagmanager.com/">Wees voorzichtig met het gebruik van dns-prefetch, want zelfs als ze licht van gewicht zijn, is het gemakkelijk om de browserlimieten uit te putten voor het aantal gelijktijdige in-flight DNS-verzoeken dat is toegestaan (Chrome heeft nog steeds een limit van 6).
preconnect
preconnect helpt het IP-adres op te lossen en van tevoren een TCP/TLS-verbinding voor een bepaald domein te openen. Vergelijkbaar met dns-prefetch wordt het gebruikt voor elk cross-origin-domein en helpt het de browser om alle bronnen op te warmen die worden gebruikt tijdens het laden van de eerste pagina.
<link rel="preconnect" href="https://www.googletagmanager.com/">Let op wanneer u preconnect gebruikt:
- Warm alleen de meest voorkomende en significante bronnen op.
- Voorkom het opwarmen van origins die te laat in de eerste lading zijn gebruikt.
- Gebruik het voor niet meer dan drie bronnen, omdat het CPU- en batterijkosten kan hebben.
Ten slotte is preconnect niet beschikbaar voor Internet Explorer of Firefox, en het gebruik van dns-prefetch als een terugval is sterk geadviseerd.
preload
De preload hint initieert een vroeg verzoek. Dit is handig voor het laden van belangrijke bronnen die anders laat door de parser zouden worden ontdekt.
<link rel="preload" href="style.css" as="style">
<link rel="preload" href="main.js" as="script">Houd rekening met wat u gaat preloaden, omdat het het downloaden van andere bronnen kan vertragen, dus gebruik het alleen voor wat het meest kritisch is om u te helpen de Largest Contentful Paint te verbeteren (LCP). Wanneer het in Chrome wordt gebruikt, heeft het ook de neiging om te hoge prioriteit te geven aan preload-bronnen en mogelijk preloads eerder te verzenden dan andere kritieke bronnen.
Ten slotte, indien gebruikt in een HTTP-antwoordheader, zullen sommige CDN’s ook automatisch een preload omzetten in een HTTP/2-push die in het cachegeheugen opgeslagen bronnen te veel kan pushen.
prefetch
De prefetch hint stelt ons in staat om verzoeken met lage prioriteit te initiëren waarvan we verwachten dat ze gebruikt zullen worden bij de volgende navigatie. De hint downloadt de bronnen en zet deze in de HTTP-cache voor later gebruik. Belangrijk om op te merken, prefetch zal de bron niet uitvoeren of anderszins verwerken, en om het uit te voeren, zal de pagina de bron nog steeds moeten aanroepen met de <script> tag.
<link rel="prefetch" as="script" href="next-page.bundle.js">Er zijn verschillende manieren om de voorspellingslogica van een bron te implementeren, deze kan zijn gebaseerd op signalen zoals muisbewegingen van de gebruiker, algemene gebruikersstromen/reizen, of zelfs op een combinatie van beide, bovenop machine learning.
Let op, afhankelijk van de kwaliteit van HTTP/2-prioriteitstelling van het gebruikte CDN, kan prefetch prioritering ofwel de prestaties verbeteren ofwel het langzamer maken, door meer prioriteit te geven aan prefetch verzoeken en belangrijke bandbreedte weg te nemen voor de initiële belasting. Zorg ervoor dat u het CDN dat u gebruikt dubbel controleert en pas het aan om rekening te houden met een paar van de best praktijken die worden gedeeld in het artikel van Andy Davies.
Native lazy loading
De native lazy loading hint is een native browser-API voor het uitstellen van het laden van offscreen afbeeldingen en iframes. Door het te gebruiken, zullen middelen die niet nodig zijn tijdens het laden van de eerste pagina geen netwerkverzoek initiëren, dit zal het gegevensverbruik verminderen en de paginaprestaties verbeteren.
<img src="image.png" loading="lazy" alt="…" width="200" height="200">Houd er rekening mee dat Chromium’s implementatie van logica voor lazy-loading drempels historisch gezien nogal conservatief was, waarbij de offscreen-limiet op 3000px wordt gehouden. Het afgelopen jaar is de limiet actief getest en verbeterd om de verwachtingen van ontwikkelaars beter op elkaar af te stemmen en uiteindelijk de drempels te verschuiven naar 1250px. Er is ook geen standaard voor alle browsers en webontwikkelaars kunnen de standaard drempels die door de browsers worden geboden niet overschrijven.
Bronhints
Laten we op basis van het HTTP Archive de trends voor 2020 analyseren en de gegevens vergelijken met de eerdere gegevensset van 2019.
Hints acceptatie
Steeds meer webpagina’s gebruiken de belangrijkste bronhints en in 2020 zien we dat de acceptatie consistent blijft tussen desktop en mobiel.
dns-prefetch bronhint, 18% gebruikt preload, 8% gebruikt preconnect, 3% gebruikt prefetch en minder dan 1% gebruikt prerender. Mobiel is vergelijkbaar, behalve dat dns-prefetch 34% gebruik heeft (1% hoger) en preconnect 9% (1% hoger).De relatieve populariteit van dns-prefetch met een acceptatie van 33% vergeleken met andere bronhints is niet verrassend aangezien het voor het eerst verscheen in 2009, en heeft de breedste ondersteuning van alle belangrijke bronhints.
Vergeleken met 2019 had de dns-prefetch een toename van 4% in Desktop-acceptatie. We zagen ook een vergelijkbare toename voor preconnect. Een belangrijke reden waarom dit de grootste groei was tussen alle hints, is het duidelijke en nuttige advies dat de Lighthouse-audit geeft over deze kwestie. Vanaf het rapport van dit jaar introduceren we ook hoe de nieuwste dataset presteert ten opzichte van de aanbevelingen van Lighthouse.
dns-prefetch is met 5% gestegen, van 29% naar 34%. preload is met 2% gestegen, van 16% naar 18%. preconnect is met 5% gestegen, van 4% naar 9%. prefetch bleef vlak bij 3% gebruik. prerender bleef ook vlak bij minder dan 1% gebruik.Het gebruik van preload heeft een langzamere groei doorgemaakt met slechts een stijging van 2% ten opzichte van 2019. Dit zou gedeeltelijk kunnen zijn omdat het wat meer specificatie vereist. Hoewel u alleen het domein nodig hebt om dns-prefetch en preconnect te gebruiken, moet u de bron specificeren om preload te gebruiken. Hoewel dns-prefetch en preconnect een redelijk laag risico vormen, maar nog steeds kunnen worden misbruikt, heeft preload een veel groter potentieel om de prestaties daadwerkelijk te schaden als het onjuist wordt gebruikt.
prefetch wordt gebruikt door 3% van de sites op Desktop, waardoor het de minst gebruikte bronhint is. Dit lage gebruik kan worden verklaard door het feit dat prefetch nuttig is om volgende, in plaats van huidige, paginaladingen te verbeteren. Het wordt dus over het hoofd gezien als een site alleen is gericht op het verbeteren van de bestemmingspagina of de prestaties van de eerste pagina die wordt bekeken. In de komende jaren met een duidelijkere definitie van wat moet worden gemeten om de volgende pagina-ervaring te verbeteren, kan het teams helpen prioriteit te geven aan prefetch-acceptatie met duidelijke prestatiekwaliteitsdoelen om te bereiken.
Hints per pagina
Over de hele linie leren ontwikkelaars hoe ze resource-hints beter kunnen gebruiken, en vergeleken met 2019 hebben we een verbeterd gebruik van preload, prefetch en preconnect. Voor dure bewerkingen zoals preload en pre-connect daalde het mediaan gebruik op desktop van 2 naar 1. We hebben het tegenovergestelde gezien bij het laden van toekomstige bronnen met een lagere prioriteit met prefetch, met een toename van 1 naar 2 in mediaan per pagina.
preload en prerender hebben beide (mediaan) één hint per pagina op zowel mobiel als desktop. prefetch en dns-prefetch hebben beide (mediaan) twee hints per pagina op zowel mobiel als desktop. preconnect heeft (mediaan) één hint per pagina op desktop en (mediaan) twee hints per pagina op mobiel.bronhints zijn het meest effectief wanneer ze selectief worden gebruikt (“als alles belangrijk is, is niets”). Het hebben van een duidelijkere definitie van welke bronnen helpen bij het verbeteren van kritische weergave, versus toekomstige navigatie-optimalisaties, kan de focus verleggen van het gebruik van preconnect en meer naar prefetch door een deel van de bronnenprioritering te verschuiven en bandbreedte vrij te maken voor wat de gebruiker in eerste instantie het meest helpt.
Dit heeft echter niet het misbruik van de preload-hint gestopt, aangezien we in één geval een pagina ontdekten die dynamisch de hint toevoegde en een oneindige lus veroorzaakte die meer dan 20k nieuwe preloads creëerde.
Aangezien we steeds meer automatisering creëren met bronhints, moet u voorzichtig zijn bij het dynamisch injecteren van preload hints - of welke elementen dan ook!
Het as-attribuut
Met preload en prefetch is het cruciaal om het as-attribuut te gebruiken om de browser te helpen de bron nauwkeuriger te prioriteren. Hierdoor is de juiste opslag in de cache mogelijk voor toekomstige verzoeken, wordt het juiste Inhoudsbeveiligingsbeleid (CSP) en de juiste Accept-verzoekheaders toegepast.
Met preload kunnen veel verschillende content-types worden voorgeladen en de complete lijst volgt de aanbevelingen die in de Fetch spec staan. De meest populaire is het script-type met 64% gebruik. Dit heeft waarschijnlijk te maken met een grote groep sites die zijn gebouwd als Enkele Pagina Apps die de hoofdbundel zo snel mogelijk nodig hebben om de rest van hun JS-afhankelijkheden te downloaden. Daaropvolgend gebruik komt van lettertype op 8%, stijl op 5%, afbeelding op 1% en ophalen op 1%.
as-attribuutwaarden op mobiele pagina’s van 2019 en 2020 wordt vergeleken, uitgesplitst naar as-attribuutwaarde. Het merendeel van de as-waarden is script met 81% gebruik in 2019 en 64% gebruik in 2020. script-gebruik daalde met 17% jaar op jaar, terwijl alle andere waarden toenamen in gebruik. not set verhoogd met 8%, lettertype verhoogd met 5%, style verhoogd met 2%, de rest van de opmerkelijke waarden zijn 1% of minder voor beide jaren.as per jaar.
Vergeleken met de trend in 2019, hebben we een snelle groei gezien in het gebruik van lettertypen en stijlen met het kenmerk as. Dit heeft waarschijnlijk te maken met het feit dat ontwikkelaars de prioriteit van kritieke CSS verhogen en ook preload-lettertypen combineren met display:optional om de Cumulative Layout Shift (CLS) te verbeteren.
Houd er rekening mee dat het weglaten van het as-attribuut of het hebben van een ongeldige waarde het voor de browser moeilijker zal maken om de juiste prioriteit te bepalen en in sommige gevallen, zoals scripts, er zelfs voor kan zorgen dat de bron tweemaal wordt opgehaald.
Het crossorigin attribuut
Met preload en preconnect bronnen die CORS hebben ingeschakeld, zoals fonts, is het belangrijk om het crossorigin attribuut op te nemen, zodat de bron correct kan worden gebruikt. Als het attribuut crossorigin ontbreekt, volgt het verzoek het single-origin-beleid, waardoor het gebruik van preload nutteloos is.
preload dat crossorigin gebruikt.