Ontdek hoe uw server hints naar de browser kan sturen over kritieke subbronnen.
Wat zijn vroege hints?
Websites zijn in de loop van de tijd steeds geavanceerder geworden. Als zodanig is het niet ongebruikelijk dat een server niet-triviaal werk moet uitvoeren (bijvoorbeeld toegang tot databases of CDN's die toegang krijgen tot de oorspronkelijke server) om de HTML voor de opgevraagde pagina te produceren. Helaas resulteert deze "server-denktijd" in extra latentie voordat de browser de pagina kan weergeven. De verbinding blijft feitelijk inactief zolang de server nodig heeft om het antwoord voor te bereiden.
Early Hints is een HTTP-statuscode ( 103 Early Hints ) die wordt gebruikt om een voorlopig HTTP-antwoord te verzenden voorafgaand aan een definitief antwoord. Hierdoor kan een server hints naar de browser sturen over kritieke subbronnen (bijvoorbeeld stijlbladen voor de pagina, essentieel JavaScript) of oorsprongen die waarschijnlijk door de pagina zullen worden gebruikt, terwijl de server bezig is met het genereren van de hoofdbron. De browser kan deze hints gebruiken om verbindingen op te warmen en subbronnen op te vragen, terwijl hij wacht op de hoofdbron. Met andere woorden, Early Hints helpt de browser voordeel te halen uit deze "server-denktijd" door vooraf wat werk te doen, waardoor het laden van pagina's wordt versneld.
In sommige gevallen kan de prestatieverbetering van de Largest Contentful Paint variëren van enkele honderden milliseconden, zoals waargenomen door Shopify en door Cloudflare , en tot een seconde sneller, zoals te zien in deze vergelijking voor en na:
Hoe u vroege tips kunt gebruiken
De eerste stap om te profiteren van Early Hints bestaat uit het identificeren van de beste landingspagina's, dat wil zeggen de pagina's waar uw gebruikers doorgaans beginnen wanneer ze uw website bezoeken. Dit kan de startpagina zijn, of populaire pagina's met productvermeldingen als er veel gebruikers afkomstig zijn van andere websites. De reden dat deze toegangspunten belangrijker zijn dan andere pagina's is omdat het nut van Early Hints afneemt naarmate de gebruiker door uw website navigeert (dat wil zeggen dat de browser waarschijnlijk alle subbronnen heeft die hij nodig heeft bij de tweede of derde volgende navigatie). Het is ook altijd een goed idee om een geweldige eerste indruk achter te laten!
Nu u over deze geprioriteerde lijst met bestemmingspagina's beschikt, is de volgende stap het identificeren welke oorsprongen of subbronnen goede kandidaten zouden zijn voor preconnect of preload hints. Normaal gesproken zijn dit de herkomsten en subbronnen die het meest bijdragen aan belangrijke gebruikersstatistieken, zoals Largest Contentful Paint of First Contentful Paint . Meer concreet: zoek naar subbronnen die het renderen blokkeren, zoals synchroon JavaScript, stylesheets of zelfs weblettertypen. Zoek op dezelfde manier naar oorsprongen die subresources hosten die veel bijdragen aan de belangrijkste gebruikersstatistieken.
Houd er ook rekening mee dat als uw belangrijkste bronnen al gebruik maken van preconnect of preload , u deze bronnen of bronnen kunt beschouwen als kandidaten voor Early Hints. Zie hoe u LCP kunt optimaliseren voor meer details. Het is echter mogelijk dat het naïef kopiëren van de preconnect en preload richtlijnen van HTML naar Early Hints niet optimaal is .
Wanneer u deze in HTML gebruikt, wilt u doorgaans bronnen preconnect of preload die de Preload Scanner niet in de HTML zal ontdekken, bijvoorbeeld lettertypen of achtergrondafbeeldingen die anders te laat ontdekt zouden worden. Voor Early Hints beschikt u niet over de HTML, dus misschien wilt u vooraf preconnect met kritieke domeinen of kritieke bronnen preload die anders misschien vroeg in de HTML zouden worden ontdekt, bijvoorbeeld door main.css of app.js vooraf te laden. Bovendien kunt u: niet alle browsers ondersteunen preload van vroege hints; zie Browserondersteuning .
De tweede stap bestaat uit het minimaliseren van het risico van het gebruik van Early Hints op hulpbronnen of oorsprongen die mogelijk verouderd zijn of niet langer door de hoofdbron worden gebruikt. Bronnen die regelmatig worden bijgewerkt en voorzien van een versienummer (bijvoorbeeld example.com/css/main.fa231e9c.css ) zijn bijvoorbeeld mogelijk niet de beste keuze. Houd er rekening mee dat dit probleem niet specifiek geldt voor Early Hints, maar voor elke preload of preconnect , waar deze ook aanwezig is. Dit is het soort details dat het beste kan worden afgehandeld met automatisering of sjablonen (een handmatig proces leidt bijvoorbeeld eerder tot niet-overeenkomende hash- of versie-URL's tussen preload en de daadwerkelijke HTML-tag die de bron gebruikt).
Beschouw als voorbeeld de volgende stroom:
GET /main.html
Host: example.com
User-Agent: [....] Chrome/103.0.0.0 [...]
De server voorspelt dat main.abcd100.css nodig zal zijn, en stelt voor om het vooraf te laden met behulp van Early Hints:
103 Early Hints
Link: </main.abcd100.css>; rel=preload; as=style
[...]
Enkele ogenblikken later wordt de webpagina, inclusief de gekoppelde CSS, weergegeven. Helaas wordt deze CSS-bron regelmatig bijgewerkt en ligt de hoofdbron al vijf versies voor ( abcd105 ) op de voorspelde CSS-bron ( abcd100 ).
200 OK
[...]
<HTML>
<head>
<title>Example</title>
<link rel="stylesheet" href="/main.abcd105.css">
Streef in het algemeen naar hulpbronnen en herkomsten die redelijk stabiel zijn, en grotendeels onafhankelijk van de uitkomst van de belangrijkste hulpbron. Indien nodig kunt u overwegen uw belangrijkste bronnen in tweeën te splitsen: een stabiel deel dat is ontworpen om te worden gebruikt met Early Hints, en een dynamischer deel dat moet worden opgehaald nadat de hoofdbron door de browser is ontvangen:
<HTML>
<head>
<title>Example</title>
<link rel="stylesheet" href="/main.css">
<link rel="stylesheet" href="/experimental.3eab3290.css">
Tenslotte, aan de serverkant, zoek naar belangrijke bronverzoeken die worden verzonden door browsers waarvan bekend is dat ze Early Hints ondersteunen, en reageer onmiddellijk met 103 Early Hints. Neem in het 103-antwoord de relevante preconnect- en preload-hints op. Zodra de hoofdbron gereed is, volgt u het gebruikelijke antwoord (bijvoorbeeld 200 OK indien succesvol). Voor achterwaartse compatibiliteit is het een goede gewoonte om ook Link HTTP-headers op te nemen in het uiteindelijke antwoord, misschien zelfs aangevuld met kritieke bronnen die duidelijk werden tijdens het genereren van de hoofdbron (bijvoorbeeld het dynamische deel van een sleutelbron als je de instructies " in tweeën splitsen' suggestie). Hier is hoe dit eruit zou zien:
GET /main.html
Host: example.com
User-Agent: [....] Chrome/103.0.0.0 [...]
103 Early Hints
Link: <https://fonts.google.com>; rel=preconnect
Link: </main.css>; rel=preload; as=style
Link: </common.js>; rel=preload; as=script
Een paar momenten later:
200 OK
Content-Length: 7531
Content-Type: text/html; charset=UTF-8
Content-encoding: br
Link: <https://fonts.google.com>; rel=preconnect
Link: </main.css>; rel=preload; as=style
Link: </common.js>; rel=preload; as=script
Link: </experimental.3eab3290.css>; rel=preload; as=style
<HTML>
<head>
<title>Example</title>
<link rel="stylesheet" href="/main.css">
<link rel="stylesheet" href="/experimental.3eab3290.css">
<script src="/common.js"></script>
<link rel="preconnect" href="https://fonts.googleapis.com">
Browser-ondersteuning
Hoewel 103 Early Hints in alle grote browsers wordt ondersteund, verschillen de richtlijnen die op een Early Hint kunnen worden verzonden per browser:
Ondersteuning vooraf verbinden:
Browserondersteuning
- 103
- 103
- 120
- 17
Ondersteuning voorladen:
Browserondersteuning
- 103
- 103
- 123
- X
Chrome DevTools biedt ook ondersteuning voor 103 Early Hints en de Link headers zijn te zien in de documentbronnen:
Link worden weergegeven in Chrome DevTools. Let op: als u de Early Hints-bronnen wilt gebruiken, mag Disable cache niet zijn aangevinkt in DevTools, omdat Early Hints de browsercache gebruikt. Voor vooraf geladen bronnen wordt de initiator weergegeven als early-hints en de grootte als (Disk cache) :
early-hints initiator en worden geladen vanuit de schijfcache.Dit vereist ook een vertrouwd certificaat voor HTTPS-testen.
Firefox (vanaf v126) heeft geen expliciete 103 Early Hints-ondersteuning in DevTools, maar bronnen die zijn geladen met Early Hints tonen geen HTTP-headerinformatie, wat een indicator is dat ze zijn geladen via Early Hints.
Serverondersteuning
Hier is een korte samenvatting van het ondersteuningsniveau voor Early Hints onder populaire open source-software HTTP-serversoftware:
- Apache: ondersteund met mod_http2.
- H2O: ondersteund .
- NGINX: experimentele module .
- Knooppunt: ondersteund sinds 18.11.0 voor http en http2
Schakel vroege hints op de eenvoudigere manier in
Als u een van de volgende CDN's of platforms gebruikt, hoeft u Early Hints mogelijk niet handmatig te implementeren. Raadpleeg de online documentatie van uw leverancier van oplossingen om erachter te komen of deze Early Hints ondersteunt, of raadpleeg de niet-uitputtende lijst hier:
Hoe u problemen kunt voorkomen voor klanten die Early Hints niet ondersteunen
Informatieve HTTP-reacties in het bereik van 100 maken deel uit van de HTTP-standaard, maar sommige oudere clients of bots kunnen hier moeite mee hebben omdat ze vóór de lancering van 103 Early Hints zelden werden gebruikt voor algemeen surfen op het internet.
Alleen het uitzenden van 103 vroege hints als reactie op clients die een sec-fetch-mode: navigate de HTTP-verzoekheader moet ervoor zorgen dat dergelijke hints alleen worden verzonden naar nieuwere clients die begrijpen dat ze op het volgende antwoord moeten wachten. Omdat Early Hints alleen worden ondersteund bij navigatieverzoeken (zie huidige beperkingen ), heeft dit bovendien het extra voordeel dat wordt vermeden dat deze onnodig worden verzonden bij andere verzoeken.
Bovendien wordt aanbevolen dat Early Hints alleen via HTTP/2- of HTTP/3-verbindingen worden verzonden en dat de meeste browsers deze alleen via die protocollen accepteren.
Geavanceerd patroon
Als u Early Hints volledig heeft toegepast op uw belangrijkste bestemmingspagina's en merkt dat u op zoek bent naar meer mogelijkheden, bent u wellicht geïnteresseerd in het volgende geavanceerde patroon.
Voor bezoekers die zich op hun zoveelste paginaverzoek bevinden als onderdeel van een typische gebruikersreis, wilt u wellicht de Early Hints-reactie aanpassen aan inhoud die zich lager en dieper op de pagina bevindt, met andere woorden: Early Hints gebruiken voor bronnen met een lagere prioriteit. Dit klinkt misschien contra-intuïtief, aangezien we hebben aanbevolen om ons te concentreren op subresources of oorsprongen met hoge prioriteit en die het renderen blokkeren. Tegen de tijd dat een bezoeker een tijdje heeft genavigeerd, is het echter zeer waarschijnlijk dat zijn browser al over alle essentiële bronnen beschikt. Vanaf dat moment kan het zinvol zijn om uw aandacht te verleggen naar bronnen met een lagere prioriteit. Dit kan bijvoorbeeld betekenen dat u Early Hints gebruikt om productafbeeldingen te laden, of dat u extra JS/CSS gebruikt die alleen nodig is voor minder vaak voorkomende gebruikersinteracties.
Huidige beperkingen
Dit zijn de beperkingen van Early Hints zoals geïmplementeerd in Chrome:
- Alleen beschikbaar voor navigatieverzoeken (dat wil zeggen de hoofdbron voor het document op het hoogste niveau).
- Ondersteunt alleen
preconnectenpreload(dat wil zeggen,prefetchwordt niet ondersteund). - Vroege hints gevolgd door een cross-origin-omleiding op het uiteindelijke antwoord zullen ertoe leiden dat Chrome de bronnen en verbindingen laat vallen die het heeft verkregen met vroege hints.
- Bronnen die vooraf zijn geladen met Early Hints, worden opgeslagen in de HTTP-cache en daar later door de pagina opgehaald. Daarom kunnen alleen cachebare bronnen vooraf worden geladen met behulp van Early Hints, anders wordt de resource dubbel opgehaald (een keer door de Early Hints en opnieuw door het document). In Chrome is de HTTP-cache uitgeschakeld voor niet-vertrouwde HTTPS-certificaten (zelfs als u doorgaat met het laden van de pagina).
Andere browsers hebben vergelijkbare beperkingen en, zoals eerder opgemerkt , beperken sommige browsers de vroege hints verder tot alleen preconnect .
Wat is het volgende?
Afhankelijk van de interesse van de gemeenschap kunnen we onze implementatie van Early Hints uitbreiden met de volgende mogelijkheden:
- Vroege tips voor niet-cachebare bronnen die de geheugencache gebruiken in plaats van de HTTP-cache.
- Vroege hints verzonden bij verzoeken om subresources.
- Vroege hints verzonden op iframe-hoofdbronverzoeken.
- Ondersteuning voor prefetch in Early Hints.
We zijn blij met uw inbreng over welke aspecten prioriteit moeten krijgen en hoe u Early Hints verder kunt verbeteren.
Relatie met H2/Push
Als u bekend bent met de verouderde HTTP2/Push-functie , vraagt u zich misschien af hoe Early Hints verschilt. Terwijl Early Hints een retourvlucht vereist voordat de browser begint met het ophalen van kritieke subbronnen, kan de server met HTTP2/Push subbronnen naast het antwoord gaan pushen. Hoewel dit geweldig klinkt, resulteerde dit in een belangrijk structureel nadeel: met HTTP2/Push was het uiterst moeilijk om te voorkomen dat subbronnen werden gepusht die de browser al had. Dit "over-push"-effect resulteerde in een minder efficiënt gebruik van de netwerkbandbreedte, wat de prestatievoordelen aanzienlijk belemmerde. Over het geheel genomen bleek uit Chrome-gegevens dat HTTP2/Push feitelijk negatief was voor de prestaties op internet.
Daarentegen presteert Early Hints in de praktijk beter omdat het de mogelijkheid combineert om een voorlopig antwoord te sturen met hints die de browser de leiding geven over het ophalen of verbinden met wat hij werkelijk nodig heeft. Hoewel Early Hints niet alle gebruiksscenario's dekt die HTTP2/Push in theorie zou kunnen aanpakken, zijn wij van mening dat Early Hints een meer praktische oplossing is om de navigatie te versnellen.
Miniatuurafbeelding door Pierre Bamin .