Les navigateurs « prédicateurs » sont l’avenir de la navigation Internet haut débit, nous apportant les ressources que nous voulons avant même que nous sachions que nous les voulons. Les navigateurs d’aujourd’hui font déjà quelques prédictions pour accélérer la récupération et le rendu des documents. Pour passer à l’étape suivante, nous nous tournons vers les développeurs Web.
Les développeurs ont une bonne idée de la façon dont leurs sites Web sont consultés et des ressources qui sont demandées le plus souvent. Ils peuvent donc prédire les opérations futures que les navigateurs devraient effectuer pour les sites. Tout ce dont on a besoin maintenant, c’est que les développeurs trouvent un moyen de relayer ces prédictions aux navigateurs et de les utiliser à bon escient. C’est là que certains « liens HTML » spéciaux entrent en jeu.
Un rappel sur les requêtes HTTP
Avant de jeter un coup d’œil à ces liens, il est temps de rafraîchir notre mémoire sur la façon dont une opération de récupération de fichier demandée par HTTP est effectuée. Disons que quelqu’un nommé Joe veut visiter un site Web.
Voici ce qui se passe ensuite:
- Joe tape l’adresse rappelable par l’utilisateur du site Web dans la barre d’adresse d’un navigateur et appuie sur «Entrée».
- Une fois qu’il a reçu cette adresse, le navigateur demande à un serveur DNS (compliments de ISP) pour l’adresse IP de l’adresse donnée par Joe.
- Le serveur DNS oblige.
- Maintenant que le navigateur connaît l’adresse IP, il envoie un message (en dialecte TCP) au serveur du site, demandant une connexion.
- Si le serveur est bien vivant, il envoie une réponse accusant réception de la demande du navigateur et le navigateur répond et accuse réception du message du serveur. (Remarque : Oui, il s’agit d’une version extrêmement édulcorée d’une prise de contact TCP entre un client et un serveur.)
- Lorsque les poignées de main sont terminées, une connexion est établie entre les deux.
- Maintenant, le navigateur change son style de dialecte en HTTP et demande au serveur le site Web.
- Le serveur, connaissant la page d’accueil du site Web, retourne juste cela, qui est reçu par le navigateur et montré à Joe qui attend très patiemment devant l’ordinateur.
Une requête HTTP typique passe par tout cela (et plus) pour aller chercher un document sur Internet. Donc, si l’un de ces processus peut être déclenché lorsque cela est possible, nous pouvons réduire le temps que nous devons attendre pour la livraison des ressources que nous voulons.
Relations de lien HTML
W3C spécifie 4 relations de liens HTML ( relpour relation) nommé dns-prefetch, preconnect, prefetchet prerender. Ensemble, ils sont appelés (par le W3C) les «Conseils de ressources». Maintenant, nous verrons ce qu’ils peuvent faire et où ils peuvent être utilisés.
1. Préextraction DNS
Dans la préfecture DNS, la résolution du nom de domaine(c’est-à-dire obtenir l’adresse IP correspondante du serveur DNS) est effectuée à l’avance.
Disons qu’il y a une page de référence dans un site Web avec beaucoup de liens de référence vers son site soeur. Lorsqu’un utilisateur visite la page de référence, il est fort probable que l’utilisateur accède au site associé. Ainsi, une recherche DNS précoce pour le site frère peut réduire le temps d’ouverture du site (améliorant ainsi l’expérience utilisateur).
Cette réduction de latence via la pré-extraction DNS peut être effectuée en ajoutant ce code à la page de référence.
<link rel="dns-prefetch" href="//mysistersite.org">
Lorsqu’un navigateur traite ce code dans la page de référence, il ajoute la recherche DNS du site soeur à ses files d’attente de tâches, et lorsqu’il est libre d’autres tâches prioritaires dans la file d’attente, il lance la résolution DNS du serveur. site de soeur.
Ainsi, lorsqu’un utilisateur clique finalement sur l’un des liens qui les amène vers le site frère, la résolution DNS de ce site peut déjà être terminée et le navigateur peut immédiatement commencer à établir la connexion TCP client-serveur avec le site associé. serveur, ce qui rend la page plus rapide.
Cette fonctionnalité est disponible dans presque tous les navigateurs modernes sauf Safari à partir de mars 2016.
2. Preconnect
La pré-connexion est un peu plus éloignée de la pré-extraction DNS, elle établit une connexion avec le serveur auquel une demande peut être envoyée plus tard.
W3C répertorie un cas d’utilisation idéal pour preconnect: redirections. Les développeurs utilisent les redirections pour un certain nombre de raisons.
Dans ce cas, la prochaine requête d’un navigateur (site redirigé) est prévisible à 100% et peut être pré-connectée pour réduire la latence de navigation.
Imaginez qu’il y ait une page de site intermédiaire qui redirige vers « xyzsite » , le lien HTML suivant rendra le navigateur pré-connecté avec le serveur xyzsite, quand il arrivera à cette page intermédiaire.
<link rel="preconnect" href="//xyzsite.com">
Depuis mars 2016, il est disponible dans Chrome, Opera et Firefox.
3. Prefetch
Avec prefetch, pour une ressource, le navigateur commence à implémenter la résolution DNS du nom de domaine de la ressource, puis effectue une connexion TCP avec le serveur de la ressource, effectue la requête HTTP et finalement récupère et stocke la ressource pré-extraite dans le cache du navigateur.
Si vous êtes sûr des ressources qui seront nécessaires plus tard, c’est la ressource à pré-charger; c’est là que réside la prise. La pré extraction prend des devinettes, et si vous devinez à tort, vous pouvez ralentir au lieu d’accélérer votre site.
Pour les livres en ligne, les galeries ou les portefeuilles, si l’utilisateur est le plus susceptible de naviguer vers la page suivante, la lecture anticipée des ressources telles que les images peut accélérer considérablement les choses. Voici le code pour le faire.
<link rel="prefetch" href="//xyzsite.com/nextimage.jpg">
Prefetch est pris en charge dans Chrome, Firefox et Opera.
4. Prerender
Seules les pages HTML peuvent être préchargées. Une page HTML pré-rendue est rendue hors–ligne et est peinte à l’écran lorsqu’elle est réellement requise par l’utilisateur. Le rendu coûte un travail de calcul et une ressource de mémoire plus élevés; De plus, afin de rendre une page, le navigateur peut avoir besoin de ressources supplémentaires (comme des images ajoutées à la page) qui conduiront à des requêtes plus conséquentes par navigateur.
Donc, prerenderdoit être utilisé avec prudence, et pas surutilisé. L’ajout du code suivant prérèvera la page « About » au préalable.
<link rel="prerender" href="//example.com/about.html">
Prerender est déjà disponible dans Chrome, IE et Opera depuis mars 2016.
Quelques choses à noter
(1) Aucun des conseils de ressources mentionnées ci – dessus garantir l’exécution et la réalisation des différentes étapes de la demande, il est fait pour que lorsque le navigateur est déjà en train de traiter les demandes nécessaires pour les opérations de la page courante l’utilisateur est, l’exécution de ces optimisations peuvent entraver les tâches actuelles de l’utilisateur.
Ainsi, tout est mis en file d’attente et exécuté lorsque le navigateur se sent suffisamment libre pour le faire.
Ces conseils de ressources ne doivent pas nécessairement être présents dans la page avant même le chargement de la page. Ils peuvent être ajoutés plus tard par JavaScript, et les conseils de ressources feront leur travail comme d’habitude.
(2) W3C spécifie un attribut de lien HTML appelé probabilité d’indice, pr(avec une valeur de 0 à 1) pour ces conseils de ressources, qui peut être utilisé pour fournir la probabilité de demandes qui seront faites dans le futur. Je n’ai pas encore vu cet attribut mis en œuvre par un navigateur. À titre d’exemple, le code suivant indique qu’il y a 80% de chances que xyzsite soit demandé dans le futur et 30% pour la page about.
<link rel="preconnect" href="//xyzsite.com" pr="0.8"> <link rel="prerender" href="//example.com/about.html" pr="0.3">
Nous pouvons également ajouter l’attribut facultatif crossorigin aux indicateurs de ressource pour informer le navigateur des informations d’identification CORS de la requête liée.