Sneller laden van pagina's dankzij server-denktijd met Early Hints

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.

Afbeelding van de server, denk aan een tijdsverschil van 200 ms tussen het laden van de pagina en het laden van andere bronnen.
Zonder vroege tips: alles wordt geblokkeerd op de server en bepaalt hoe er moet worden gereageerd op de hoofdbron.

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 kritische subbronnen (bijvoorbeeld stylesheet voor de pagina, kritische JavaScript) of oorsprong 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.

Afbeelding die laat zien hoe Early Hints ervoor zorgt dat de pagina een gedeeltelijk antwoord verzendt.
Met Early Hints: de server kan een gedeeltelijk antwoord geven met resource-hints, terwijl hij het uiteindelijke antwoord bepaalt

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 voor/na-vergelijking:

Vergelijking van twee sites.
Voor/na vergelijking van vroege tips op een testwebsite uitgevoerd met WebPageTest (Moto G4 - DSL)

Implementatie van vroege tips

Voordat u dieper op het onderwerp ingaat, moet u er rekening mee houden dat vroege hints niet nuttig zijn als uw server meteen een 200 (of andere definitieve reacties) kan verzenden. Overweeg in plaats daarvan om in dergelijke situaties de reguliere link rel=preload of link rel=preconnect te gebruiken in het hoofdantwoord ( Link rel HTTP header ), of in het hoofdantwoord ( <link> elementen). Voor de gevallen waarin uw server wat tijd nodig heeft om het hoofdantwoord te genereren, lees verder!

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 de bruikbaarheid 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 deze geprioriteerde lijst met bestemmingspagina's heeft, bestaat de volgende stap uit het identificeren van welke oorsprong of subbronnen goede kandidaten zouden zijn voor preconnect- of preload- hints, als eerste benadering. 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 bronnen die subbronnen hosten die veel bijdragen aan de belangrijkste gebruikersstatistieken. Let op: als uw belangrijkste bronnen <link rel=preconnect> of <link rel=preload> al gebruiken, kunt u deze bronnen of bronnen beschouwen als kandidaten voor Early Hints. Zie dit artikel voor meer details.

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; het geldt voor elke link rel=preload of rel=preconnect , waar deze ook aanwezig is. Dit is het soort detail dat het beste kan worden aangepakt met automatisering of sjablonen (een handmatig proces leidt bijvoorbeeld eerder tot niet-overeenkomende hash- of versie-URL's tussen link rel=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 via 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

Serverondersteuning

Hier is een korte samenvatting van het ondersteuningsniveau voor Early Hints onder de populaire OSS HTTP-serversoftware:

Vroege hints inschakelen, op de gemakkelijke manier

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:

Problemen vermijden 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 .

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 subbronnen of oorsprongen met hoge prioriteit en weergaveblokkering. 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 preconnect en preload (dat wil zeggen, prefetch wordt niet ondersteund).
  • Early Hint gevolgd door een cross-origin redirect op het uiteindelijke antwoord zal ertoe leiden dat Chrome de bronnen en verbindingen die het via Early Hints heeft verkregen, laat vallen.

Andere browsers hebben vergelijkbare beperkingen en beperken 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 hints verzonden bij verzoeken om subbronnen.
  • 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 .