Les sites se chargent encore trop lentement. Au moment le plus critique du processus de téléchargement, le canal est souvent presque complètement inactif. La nouvelle technologie de Fastly, proposée par l'ingénieur Kazuho Oku, aidera à mieux utiliser ces deux premières secondes critiques.

Avez-vous déjà téléchargé un site Web sur votre téléphone et cherché 10 secondes sur une page sans texte? Personne n'aime s'asseoir et regarder un écran vide pendant le chargement d'une police inhabituelle. Par conséquent, il est logique de transférer le chargement de ces choses importantes le plus tôt possible. La précharge Link rel = preload était censée résoudre partiellement le problème. Tout d'abord, le navigateur analyse les en-têtes HTTP, c'est donc l'endroit idéal pour pointer vers le préchargement d'une ressource dont vous aurez certainement besoin plus tard.

Par défaut, Internet est lent

Voyons ce qui se passe si vous n'utilisez pas la précharge. Le navigateur ne peut commencer à charger des ressources qu'après avoir découvert qu'il en a besoin. Cela est plus susceptible de se produire pour les ressources qui sont en HTML lors de l'analyse initiale du document (par exemple, <script> , <link rel=stylesheet> et <img> ).

Les ressources détectées après la construction de l'arborescence de rendu sont téléchargées plus lentement (c'est l'endroit où la page ralentit en raison du chargement de la police, car pour comprendre cela, vous devez d'abord charger la feuille de style, l'analyser, créer le modèle d'objet CSS, puis l'arborescence de rendu).

Les ressources ajoutées au document sont encore plus lentes à l'aide de chargeurs JavaScript déclenchés par des événements tels que DOMContentLoaded . Si vous mettez tout ensemble, nous obtenons une cascade non optimisée et plutôt vide de sens. La plupart du temps, le canal est inactif et les ressources sont chargées plus tôt que nécessaire ou trop tard:

Lien rel = précharge aide beaucoup

Au cours des dernières années, la situation s'est améliorée grâce à Link rel = preload . Par exemple:

 Link: </resources/fonts/myfont.woff>; rel=preload; as=font; crossorigin Link: </resources/css/something.css>; rel=preload; as=style Link: </resources/js/main.js>; rel=preload; as=script 

Grâce à ces directives, le navigateur peut commencer à charger des ressources immédiatement après avoir reçu les en-têtes et avant de commencer l'analyse du corps HTML:



Il s'agit d'une amélioration significative, en particulier pour les grandes pages et les ressources critiques qui seraient autrement découvertes tard. Surtout pour les polices, mais tout peut devenir une ressource critique, comme le fichier de données nécessaire pour charger une application JavaScript.

Mais nous pouvons faire plus. Après tout, le navigateur ne fait rien entre le moment où il a fini d'envoyer la demande et celui où il reçoit les premiers octets de la réponse (le gros fragment vert sur la demande initiale est plus élevé).

Nous utilisons le temps de la «pensée serveur» à l'aide de «premiers conseils»

D'un autre côté, le serveur est vraiment occupé. Il génère une réponse et détermine si elle réussit ou non. Après avoir accédé à la base de données, aux appels API, à l'authentification, etc. le serveur peut décider que l'erreur 404 est la bonne réponse.

Parfois, le temps de méditation du serveur est inférieur à la latence du réseau. Parfois beaucoup plus. Mais il est important de comprendre qu'ils ne se chevauchent pas. Pendant que le serveur réfléchit, nous n'envoyons pas de données au client.

Mais il est intéressant de noter que même avant de générer la réponse, vous connaissez déjà certains styles et polices que vous devez télécharger pour afficher la page. Après tout, les pages d'erreur utilisent généralement la même identité d'entreprise et le même design que les pages normales. Ce serait formidable d'envoyer ces en- Link: rel=preload avant que le serveur ne fonctionne . C'est pourquoi la norme Early Hints , conçue dans la RFC8297 par le groupe de travail HTTP, a été inventée par Fastly, mon collègue Kazuho Oku. Évaluez la magie de plusieurs barres d'état en une seule réponse :

 HTTP/1.1 103 Early Hints Link: <some-font-face.woff2>; rel="preload"; as="font"; crossorigin Link: <main-styles.css>; rel="preload"; as="style" HTTP/1.1 404 Not Found Date: Fri, 26 May 2017 10:02:11 GMT Content-Length: 1234 Content-Type: text/html; charset=utf-8 Link: <some-font-face.woff2>; rel="preload"; as="font"; crossorigin Link: <main-styles.css>; rel="preload"; as="style" 

Le serveur peut enregistrer le premier code de réponse dit «informationnel» , dès qu'il reçoit une requête, et l'envoyer au réseau. Il traitera ensuite de la définition d'une réaction réelle et de sa génération. Pendant ce temps, dans le navigateur, vous pouvez commencer le préchargement beaucoup plus tôt:



Bien sûr, cela nécessitera certains changements dans le fonctionnement des navigateurs, des serveurs et des CDN, et les développeurs de certains navigateurs ont exprimé des réserves quant aux difficultés de mise en œuvre. Par conséquent, on ne sait toujours pas quand ces en-têtes peuvent être mis en service. Vous pouvez suivre la progression dans les trackers publics pour Chrome et Firefox .

Nous espérons qu'à la fin, vous pourrez émettre des en-têtes Early Hints directement à partir de Fastly, tout en envoyant des demandes de manière standard. Nous n'avons pas encore décidé comment configurer l'interface via VCL, alors faites-moi savoir si vous avez des souhaits à ce sujet!

Mais qu'en est-il du serveur HTTP / 2 Push?

Avec HTTP / 2, il existe une nouvelle technologie appelée Server Push qui semble résoudre le même problème que Link rel = preload dans la réponse Early Hints. Bien que cela fonctionne vraiment (et vous pouvez même générer rapidement des push personnalisés à partir de serveurs Edge dans Fastly), il existe des différences importantes sur plusieurs points:

• Le serveur ne connaît pas la disponibilité d'une ressource sur le client, il la pousse donc souvent inutilement. En raison de la mise en mémoire tampon et de la latence du réseau, le client ne peut généralement pas annuler l'envoi avant de recevoir tout le contenu. (Bien qu'il existe une solution possible à ce problème, sous la forme de l'en-tête Cache Digest proposé, sur lequel Kazuho travaille avec Joam Weiss d'Akamai).
• Les ressources en streaming sont liées à la connexion, il est donc facile de démarrer une ressource que le client n'utilise pas, car il essaie de la faire passer par une autre connexion. Les clients peuvent avoir besoin d'utiliser une connexion différente car la ressource se trouve dans une source différente avec un certificat TLS différent ou parce qu'elle est récupérée dans un mode d'identification différent.
• H2 Push n'est pas implémenté de manière très cohérente dans les différents navigateurs. Par conséquent, il est difficile de prédire si cela fonctionnera ou non dans votre cas particulier.

D'une manière ou d'une autre, Early Hints et Server Push proposent différents compromis. Les premières indications permettent une utilisation plus efficace du réseau en échange d'échanges de paquets supplémentaires. Si vous vous attendez à une petite latence du réseau et à une longue période de réflexion sur le serveur, alors Early Hints est la bonne solution.

Mais ce n'est pas toujours le cas. Soyons optimistes et imaginons que les gens s'installeront bientôt sur Mars. Ils navigueront sur le Web avec un retard de 20 à 45 minutes pour chaque échange de packages, de sorte que l'échange supplémentaire est extrêmement douloureux et que le temps du serveur est négligeable par rapport à lui. Server Push gagne facilement ici. Mais si jamais nous regardons les pages Web de Mars, nous sommes plus susceptibles de télécharger une sorte de package de données, quelque chose comme des packages Web désormais proposés et des échanges signés .

Bonus supplémentaire: réduction plus rapide des demandes

Bien que Early Hints soit censé être utilisé principalement dans le navigateur, il existe un avantage potentiel intéressant pour CDN. Lorsque Fastly reçoit de nombreuses demandes pour la même ressource, nous n'envoyons généralement qu'une seule à la source et mettons le reste dans la file d'attente. Ce processus est connu sous le nom d' effondrement des demandes . Si la réponse de la source inclut Cache-Control: private , vous devez supprimer toutes les demandes de la file d'attente et les envoyer séparément à la source, car nous ne pouvons pas utiliser une seule réponse pour satisfaire plusieurs demandes.

Nous ne pouvons pas prendre de décision jusqu'à ce qu'une réponse soit reçue à la première demande, mais en cas de prise en charge des premiers indices, si le serveur a renvoyé une réponse des premiers indices avec l'en-tête Cache-Control, nous saurons bien plus tôt que la file d'attente ne peut pas être réduite en une seule demande, mais à la place transférez immédiatement toutes les demandes de la file d'attente à la source.

Commandez du contenu moins critique avec des conseils prioritaires

Les premiers conseils sont un excellent moyen d'accéder à certains des objets les plus précieux de la file d'attente (cascade): lorsque le réseau est inactif, l'utilisateur attend, il n'y a qu'une seule demande en cours et rien à l'écran. Mais dès que le code HTML est chargé et que la page est analysée, le nombre de ressources à charger augmente considérablement. Maintenant, il est important de ne pas charger les ressources le plus rapidement possible, mais de les charger dans le bon ordre. Les navigateurs utilisent un tableau d'heuristiques étonnamment complexe pour déterminer indépendamment la priorité du téléchargement, mais si vous souhaitez les redéfinir, cela pourra se faire à l'avenir à l'aide d'indices de priorité:

 <script src="main.js" async importance="high"></script> <script src="non-critical-1.js" async importance="low"></script> 

Avec ce nouvel attribut d'importance, les développeurs peuvent contrôler l'ordre de chargement des ressources en cas de concurrence pour le réseau. Les ressources de faible priorité peuvent être retardées jusqu'à ce que le processeur et le réseau soient libres, ou selon le type de périphérique.

Peut-il être utilisé?

Ni les premiers indices ni les indices prioritaires ne sont encore devenus la norme. Récemment, H2O, le serveur HTTP / 2 utilisé et pris en charge par Fastly, a commencé à utiliser les premiers indices (voir PR 1727 et 1767 ), et il est prévu d'implémenter des indices de priorité dans Chrome , ainsi que de suivre activement les réponses 1xx. Dans le même temps, il n'y a aucun mal à commencer à envoyer des premiers indices dès maintenant - et si vous voulez devancer la tendance, alors allez-y!