Développer des sites rapides partout peut être une tâche délicate. La pléthore de fonctionnalités des appareils et la qualité des réseaux auxquels ils se connectent peuvent sembler être une tâche insurmontable. Bien que nous puissions tirer parti des fonctionnalités du navigateur pour améliorer les performances de chargement, comment savoir de quoi l'appareil de l'utilisateur est capable ou quelle est la qualité de sa connexion réseau ? La solution est client hints !
Les indications client sont un ensemble d'en-têtes de requête HTTP activables qui nous donnent des informations sur ces aspects de l'appareil de l'utilisateur et du réseau auquel il est connecté. En accédant à ces informations côté serveur, nous pouvons modifier la manière dont nous fournissons le contenu en fonction des conditions de l'appareil et/ou du réseau. Cela peut nous aider à créer des expériences utilisateur plus inclusives.
Tout est une question de négociation de contenu
Les indications client sont une autre méthode de négociation de contenu, qui consiste à modifier les réponses de contenu en fonction des en-têtes de requête du navigateur.
Un exemple de négociation de contenu implique l'en-tête de requête Accept. Il décrit les types de contenu que le navigateur comprend, que le serveur peut utiliser pour négocier la réponse. Pour les requêtes d'images, le contenu de l'en-tête Accept de Chrome est le suivant :
Accept: image/webp,image/apng,image/*,*/*;q=0.8
Alors que tous les navigateurs sont compatibles avec les formats d'image tels que JPEG, PNG et GIF, Accept indique dans ce cas que le navigateur est également compatible avec WebP et APNG. Grâce à ces informations, nous pouvons négocier les meilleurs types d'images pour chaque navigateur :
<?php
// Check Accept for an "image/webp" substring.
$webp = stristr($_SERVER["HTTP_ACCEPT"], "image/webp") !== false ? true : false;
// Set the image URL based on the browser's WebP support status.
$imageFile = $webp ? "whats-up.webp" : "whats-up.jpg";
?>
<img src="<?php echo($imageFile); ?>" alt="I'm an image!">
Comme Accept, les indications client sont un autre moyen de négocier le contenu, mais dans le contexte des capacités de l'appareil et des conditions du réseau. Grâce aux indications client, nous pouvons prendre des décisions concernant les performances côté serveur en fonction de l'expérience individuelle d'un utilisateur. Par exemple, nous pouvons décider si des ressources non critiques doivent être fournies aux utilisateurs dont la connexion réseau est mauvaise. Dans ce guide, nous allons décrire tous les indices disponibles et quelques façons de les utiliser pour rendre la diffusion de contenu plus adaptée aux utilisateurs.
Activation
Contrairement à l'en-tête Accept, les indications client n'apparaissent pas comme par magie (à l'exception de Save-Data, dont nous parlerons plus tard). Pour limiter au maximum les en-têtes de requête, vous devez choisir les indications client que vous souhaitez recevoir en envoyant un en-tête Accept-CH lorsqu'un utilisateur demande une ressource :
Accept-CH: Viewport-Width, Downlink
La valeur de Accept-CH est une liste de suggestions demandées, séparées par des virgules, que le site utilisera pour déterminer les résultats des demandes de ressources ultérieures. Lorsque le client lit cet en-tête, il reçoit le message suivant : "Ce site souhaite obtenir les indications client Viewport-Width et Downlink". Ne vous inquiétez pas des indications spécifiques elles-mêmes.
Nous y reviendrons dans un instant.
Vous pouvez définir ces en-têtes d'activation dans n'importe quel langage de backend. Par exemple, la fonction header de PHP peut être utilisée.
Vous pouvez même définir ces en-têtes d'activation avec l'attribut http-equiv sur une balise <meta> :
<meta http-equiv="Accept-CH" content="Viewport-Width, Downlink" />
Tous les indices client !
Les indications client décrivent l'une des deux choses suivantes : l'appareil que vos utilisateurs utilisent et le réseau qu'ils utilisent pour accéder à votre site. Passons brièvement en revue tous les indices disponibles.
Recommandations concernant les appareils
Certains indices client décrivent les caractéristiques de l'appareil de l'utilisateur, généralement celles de l'écran. Certaines d'entre elles peuvent vous aider à choisir la ressource média optimale pour l'écran d'un utilisateur donné, mais toutes ne sont pas nécessairement axées sur les médias.
Avant de commencer, il peut être utile de connaître quelques termes clés utilisés pour décrire les écrans et la résolution des contenus multimédias :
Taille intrinsèque : dimensions réelles d'une ressource média. Par exemple, si vous ouvrez une image dans Photoshop, les dimensions indiquées dans la boîte de dialogue de taille d'image décrivent sa taille intrinsèque.
Taille intrinsèque corrigée en fonction de la densité : dimensions d'une ressource multimédia après correction de la densité de pixels. Il s'agit de la taille intrinsèque de l'image divisée par le ratio de pixels de l'appareil. Prenons par exemple le balisage suivant :
<img
src="whats-up-1x.png"
srcset="whats-up-2x.png 2x, whats-up-1x.png 1x"
alt="I'm that image you wanted."
/>
Supposons que la taille intrinsèque de l'image 1x soit de 320 x 240 et que celle de l'image 2x soit de 640 x 480. Si ce balisage est analysé par un client installé sur un appareil dont le ratio de pixels de l'écran est de 2 (par exemple, un écran Retina), l'image 2x est demandée. La taille intrinsèque corrigée de la densité de l'image 2x est de 320 x 240, car 640 x 480 divisé par 2 donne 320 x 240.
Taille extrinsèque : taille d'une ressource multimédia après l'application du CSS et d'autres facteurs de mise en page (tels que les attributs width et height). Supposons que vous ayez un élément <img> qui charge une image avec une taille intrinsèque corrigée par la densité de 320 x 240, mais qui possède également des propriétés CSS width et height avec des valeurs de 256px et 192px appliquées respectivement. Dans cet exemple, la taille intrinsèque de cet élément <img> devient 256 x 192.
width: 256px; et height: 192px; transforme une image de taille intrinsèque 320 x 240 en une image de taille extrinsèque 256 x 192.Maintenant que nous avons vu quelques termes, passons à la liste des indications client spécifiques aux appareils qui sont à votre disposition.
Viewport-Width
Viewport-Width correspond à la largeur de la fenêtre d'affichage de l'utilisateur en pixels CSS :
Viewport-Width: 320
Cet indice peut être utilisé avec d'autres indices spécifiques à l'écran pour fournir différents traitements (c'est-à-dire des recadrages) d'une image qui sont optimaux pour des tailles d'écran spécifiques (c'est-à-dire la direction artistique) ou pour omettre les ressources qui ne sont pas nécessaires pour la largeur d'écran actuelle.
DPR
DPR, abréviation de "device pixel ratio" (rapport de pixels de l'appareil), indique le rapport entre les pixels physiques et les pixels CSS de l'écran de l'utilisateur :
DPR: 2
Cet indice est utile lorsque vous sélectionnez des sources d'image qui correspondent à la densité de pixels d'un écran (comme le font les descripteurs x dans l'attribut srcset).
Largeur
L'indice Width apparaît dans les requêtes de ressources d'image déclenchées par les balises <img> ou <source> à l'aide de l'attribut sizes.
sizes indique au navigateur la taille extrinsèque de la ressource ;
Width utilise cette taille extrinsèque pour demander une image dont la taille intrinsèque est optimale pour la mise en page actuelle.
Par exemple, supposons qu'un utilisateur demande une page avec un écran de 320 pixels CSS de large et un DPR de 2. L'appareil charge un document avec un élément <img> contenant une valeur d'attribut sizes de 85vw (c'est-à-dire, 85% de la largeur de la fenêtre d'affichage pour toutes les tailles d'écran). Si l'indication Width a été activée, le client enverra cette indication Width au serveur avec la requête pour le src de <img> :
Width: 544
Dans ce cas, le client indique au serveur qu'une largeur intrinsèque optimale pour l'image demandée serait de 85% de la largeur de la fenêtre d'affichage (272 pixels) multipliée par le DPR de l'écran (2), soit 544 pixels.
Cet indice est particulièrement puissant, car il prend non seulement en compte la largeur de l'écran corrigée en fonction de la densité, mais il concilie également cette information essentielle avec la taille intrinsèque de l'image dans la mise en page. Les serveurs ont ainsi la possibilité de négocier des réponses d'image optimales à la fois pour l'écran et la mise en page.
Content-DPR
Vous savez déjà que les écrans ont un rapport de pixels de l'appareil, mais les ressources ont également leur propre rapport de pixels. Dans les cas d'utilisation les plus simples de sélection de ressources, les ratios de pixels entre les appareils et les ressources peuvent être identiques. Mais attention… Dans les cas où les en-têtes DPR et Width sont tous les deux utilisés, la taille extrinsèque d'une ressource peut entraîner des scénarios où les deux diffèrent. C'est là que l'indice Content-DPR entre en jeu.
Contrairement aux autres indications client, Content-DPR n'est pas un en-tête de requête à utiliser par les serveurs, mais plutôt un en-tête de réponse que les serveurs doivent envoyer chaque fois que les indications DPR et Width sont utilisées pour sélectionner une ressource. La valeur de Content-DPR doit être le résultat de cette équation :
Content-DPR = [Taille de la ressource d'image sélectionnée] / ([Width] / [DPR])
Lorsqu'un en-tête de requête Content-DPR est envoyé, le navigateur sait comment mettre à l'échelle l'image donnée pour le ratio de pixels de l'appareil et la mise en page de l'écran. Sans cela, les images risquent de ne pas être mises à l'échelle correctement.
Device-Memory
Techniquement, Device-Memory fait partie de l'API Device Memory et révèle la quantité approximative de mémoire dont dispose l'appareil actuel en Gio :
Device-Memory: 2
Un cas d'utilisation possible pour cet indice serait de réduire la quantité de JavaScript envoyée aux navigateurs sur les appareils dont la mémoire est limitée, car JavaScript est le type de contenu le plus gourmand en ressources que les navigateurs chargent généralement. Vous pouvez également envoyer des images avec un DPR inférieur, car elles utilisent moins de mémoire pour être décodées.
Indices réseau
L'API Network Information fournit une autre catégorie d'indices client qui décrivent les performances de la connexion réseau de l'utilisateur. À mon avis, ce sont les indices les plus utiles. Grâce à eux, nous pouvons personnaliser les expériences des utilisateurs en modifiant la façon dont nous fournissons des ressources aux clients disposant de connexions lentes.
Texte en temps réel
L'indication RTT fournit le temps aller-retour approximatif, en millisecondes, au niveau de la couche application. Contrairement au RTT de la couche transport, l'indice RTT inclut le temps de traitement du serveur.
RTT: 125
Cet indice est utile en raison du rôle que joue la latence dans les performances de chargement.
En utilisant l'indice RTT, nous pouvons prendre des décisions en fonction de la réactivité du réseau, ce qui peut aider à accélérer la diffusion d'une expérience complète (par exemple, en omettant certaines requêtes).
Lien de téléchargement
Bien que la latence soit importante pour les performances de chargement, la bande passante l'est également. L'indice Downlink, exprimé en mégabits par seconde (Mbit/s), révèle la vitesse de téléchargement approximative de la connexion de l'utilisateur :
Downlink: 2.5
En association avec RTT, Downlink peut être utile pour modifier la façon dont le contenu est diffusé aux utilisateurs en fonction de la qualité d'une connexion réseau.
ECT
L'indice ECT signifie Type de connexion compatible. Sa valeur est l'un des types de connexion d'une liste énumérée, chacun décrivant une connexion dans des plages spécifiées de valeurs RTT et Downlink.
Cet en-tête n'explique pas le type de connexion réel. Par exemple, il n'indique pas si votre passerelle est une antenne-relais ou un point d'accès Wi-Fi. Il analyse plutôt la latence et la bande passante de la connexion actuelle, et détermine le profil réseau auquel elle ressemble le plus. Par exemple, si vous vous connectez via le Wi-Fi à un réseau lent, ECT peut être renseigné avec la valeur 2g, qui est l'approximation la plus proche de la connexion effective :
ECT: 2g
Les valeurs valides pour ECT sont 4g, 3g, 2g et slow-2g. Cette indication peut servir de point de départ pour évaluer la qualité de la connexion, puis être affinée à l'aide des indications RTT et Downlink.
Save-Data
Save-Data n'est pas tant un indice décrivant les conditions du réseau qu'une préférence de l'utilisateur indiquant que les pages doivent envoyer moins de données.
Je préfère classer Save-Data comme un indice réseau, car de nombreuses choses que vous feriez avec sont similaires à d'autres indices réseau. Les utilisateurs sont également susceptibles de l'activer dans des environnements à latence élevée/bande passante faible. Lorsqu'il est présent, cet indice se présente toujours comme suit :
Save-Data: on
Chez Google, nous vous avons déjà présenté les possibilités offertes par Save-Data.
Cela peut avoir un impact considérable sur les performances. C'est un signal qui indique que les utilisateurs vous demandent littéralement de leur envoyer moins de contenu. Si vous écoutez ce signal et agissez en conséquence, les utilisateurs l'apprécieront.
Vue panoramique
Ce que vous faites avec les indications du client dépend de vous. Comme elles fournissent de nombreuses informations, vous avez le choix entre plusieurs options. Pour vous donner quelques idées, voyons ce que les indications client peuvent faire pour Sconnie Timber, une entreprise fictive de bois d'œuvre située dans le Midwest rural. Comme c'est souvent le cas dans les zones reculées, les connexions réseau peuvent être fragiles. C'est là qu'une technologie comme les indications client peut vraiment faire la différence pour les utilisateurs.
Images responsives
Tous les cas d'utilisation d'images responsives, à l'exception des plus simples, peuvent devenir complexes. Que se passe-t-il si vous avez plusieurs traitements et variantes des mêmes images pour différentes tailles d'écran et différents formats ? Ce balisage devient très compliqué très
rapidement.
Il est facile de se tromper, d'oublier ou de mal comprendre des concepts importants (comme sizes).
Bien que <picture> et srcset soient des outils fantastiques, leur développement et leur maintenance peuvent prendre du temps pour les cas d'utilisation complexes. Nous pouvons automatiser la génération de balises, mais cela est également difficile, car la fonctionnalité <picture> et srcset est suffisamment complexe pour que son automatisation soit effectuée de manière à préserver la flexibilité qu'elle offre.
Les indications client peuvent simplifier cette tâche. La négociation des réponses d'image avec les indications du client peut ressembler à ceci :
- Si cela s'applique à votre workflow, commencez par sélectionner un traitement d'image (c'est-à-dire une image artistique) en cochant l'indice
Viewport-Width. - Sélectionnez une résolution d'image en cochant les indications
WidthetDPR, puis en choisissant une source qui correspond à la taille de la mise en page et à la densité d'écran de l'image (comme les descripteursxetwdanssrcset). - Sélectionnez le format de fichier le plus adapté pris en charge par le navigateur (
Acceptnous aide à le faire dans la plupart des navigateurs).
En ce qui concerne mon client fictif, une entreprise de bois d'œuvre, j'ai développé une routine de sélection d'images responsives naïve en PHP qui utilise les indications client. Cela signifie qu'au lieu d'envoyer ce balisage à tous les utilisateurs :
<picture>
<source
srcset="
company-photo-256w.webp 256w,
company-photo-512w.webp 512w,
company-photo-768w.webp 768w,
company-photo-1024w.webp 1024w,
company-photo-1280w.webp 1280w
"
type="image/webp"
/>
<img
srcset="
company-photo-256w.jpg 256w,
company-photo-512w.jpg 512w,
company-photo-768w.jpg 768w,
company-photo-1024w.jpg 1024w,
company-photo-1280w.jpg 1280w
"
src="company-photo-256w.jpg"
sizes="(min-width: 560px) 251px, 88.43vw"
alt="The Sconnie Timber Staff!"
/>
</picture>
J'ai pu le réduire à ce qui suit en fonction de la compatibilité avec les différents navigateurs :
<img
src="/image/sizes:true/company-photo.jpg"
sizes="(min-width: 560px) 251px, 88.43vw"
alt="SAY CHEESY PICKLES."
/>
Dans cet exemple, l'URL /image est un script PHP suivi de paramètres réécrits par mod_rewrite. Il prend un nom de fichier image et des paramètres supplémentaires pour aider un script de backend à choisir la meilleure image dans les conditions données.
Je sens que votre première question est la suivante : Mais n'est-ce pas simplement une réimplémentation de <picture> et srcset sur le backend ?
D'une certaine manière, oui, mais avec une distinction importante : lorsqu'une application utilise des indications client pour créer des réponses multimédias, la plupart (voire la totalité) des tâches sont beaucoup plus faciles à automatiser, ce qui peut inclure un service (tel qu'un CDN) qui peut le faire à votre place. En revanche, avec les solutions HTML, un nouveau balisage doit être écrit pour chaque cas d'utilisation. Bien sûr, vous pouvez automatiser la génération du balisage. Toutefois, si votre conception ou vos exigences changent, il y a de fortes chances que vous deviez revoir votre stratégie d'automatisation à l'avenir.
Les indications client permettent de commencer avec une image haute résolution sans perte, qui peut ensuite être redimensionnée de manière dynamique pour être optimale pour n'importe quelle combinaison d'écran et de mise en page. Contrairement à srcset, qui vous oblige à énumérer une liste fixe de candidats d'images possibles parmi lesquels le navigateur peut choisir, cette approche peut être plus flexible. Alors que srcset vous oblige à proposer aux navigateurs un ensemble de variantes approximatif (par exemple, 256w, 512w, 768w et 1024w), une solution basée sur les indices client peut diffuser toutes les largeurs, sans une énorme quantité de balisage.
Bien sûr, vous n'avez pas besoin d'écrire vous-même la logique de sélection des images. Cloudinary utilise des indications client pour créer des réponses d'image lorsque vous utilisez le paramètre w_auto. Il a également observé que les utilisateurs moyens téléchargeaient 42% moins d'octets lorsqu'ils utilisaient des navigateurs compatibles avec les indications client.
Mais attention ! Les modifications apportées à la version pour ordinateur de Chrome 67 ont supprimé la compatibilité avec les indices client d'origine croisée. Heureusement, ces restrictions n'affectent pas les versions mobiles de Chrome et seront levées pour toutes les plates-formes une fois que le travail sur la Feature Policy sera terminé.
Aider les utilisateurs sur les réseaux lents
La performance adaptative est l'idée que nous pouvons ajuster la façon dont nous fournissons les ressources en fonction des informations que les indications client mettent à notre disposition, en particulier les informations sur l'état actuel de la connexion réseau de l'utilisateur.
En ce qui concerne le site de Sconnie Timber, nous prenons des mesures pour alléger la charge lorsque les réseaux sont lents. Les en-têtes Save-Data, ECT, RTT et Downlink sont examinés dans notre code de backend. Une fois cette opération effectuée, nous générons un score de qualité du réseau que nous pouvons utiliser pour déterminer si nous devons intervenir afin d'améliorer l'expérience utilisateur. Ce score de réseau est compris entre 0 et 1, où 0 correspond à la qualité de réseau la plus mauvaise possible et 1 à la meilleure.
Nous vérifions d'abord si Save-Data est présent. Si c'est le cas, le score est défini sur 0, car nous partons du principe que l'utilisateur souhaite que nous fassions tout le nécessaire pour rendre l'expérience plus légère et plus rapide.
Toutefois, si Save-Data est absent, nous passons à l'étape suivante et pondérons les valeurs des indices ECT, RTT et Downlink pour calculer un score qui décrit la qualité de la connexion réseau. Le code source de la génération du score réseau est disponible sur GitHub. En résumé, si nous utilisons les indications liées au réseau d'une certaine manière, nous pouvons améliorer l'expérience des utilisateurs qui sont sur des réseaux lents.
Lorsque les sites s'adaptent aux informations fournies par les indications client, nous n'avons pas besoin d'adopter une approche "tout ou rien". Nous pouvons décider de manière intelligente quelles ressources envoyer. Nous pouvons modifier notre logique de sélection d'images responsives pour envoyer des images de qualité inférieure pour un écran donné afin d'accélérer les performances de chargement lorsque la qualité du réseau est mauvaise.
Dans cet exemple, nous pouvons voir l'impact des indications client sur l'amélioration des performances des sites sur les réseaux plus lents. Vous trouverez ci-dessous un graphique en cascade WebPagetest d'un site sur un réseau lent qui ne s'adapte pas aux indications du client :
Voici maintenant un graphique en cascade pour le même site sur la même connexion lente, sauf que cette fois, le site utilise des indications client pour éliminer les ressources non critiques de la page :
Les indications client ont permis de réduire le temps de chargement des pages de plus de 45 secondes à moins d'un dixième de ce temps. On ne saurait trop insister sur les avantages des indications client dans ce scénario. Elles peuvent être d'une grande aide pour les utilisateurs qui recherchent des informations essentielles sur des réseaux lents.
De plus, il est possible d'utiliser des indications client sans nuire à l'expérience des navigateurs qui ne les prennent pas en charge. Par exemple, si nous voulons ajuster la diffusion des ressources à l'aide de la valeur de l'indication ECT tout en offrant une expérience complète pour les navigateurs non compatibles, nous pouvons définir un retour à une valeur par défaut comme suit :
// Set the ECT value to "4g" by default.
$ect = isset($_SERVER["HTTP_ECT"]) ? $_SERVER["HTTP_ECT"] : "4g";
Ici, "4g" représente la connexion réseau de la meilleure qualité décrite par l'en-tête ECT. Si nous initialisons $ect sur "4g", les navigateurs qui ne sont pas compatibles avec les indications client ne seront pas affectés. En avant l'activation !
Attention aux caches !
Chaque fois que vous modifiez une réponse en fonction d'un en-tête HTTP, vous devez savoir comment les caches géreront les futures récupérations de cette ressource. L'en-tête Vary est indispensable ici, car il associe les entrées de cache à la valeur des en-têtes de requête qui lui sont fournis. En d'autres termes, si vous modifiez une réponse en fonction d'un en-tête de requête HTTP donné, vous devez presque toujours inclure cet en-tête dans Vary, comme suit :
Vary: DPR, Width
Il existe toutefois une grande mise en garde : vous ne devez jamais mettre en cache les réponses Vary sur un en-tête qui change fréquemment (comme Cookie), car ces ressources deviennent effectivement non cachables. Sachant cela, vous pouvez éviter de vous appuyer sur les en-têtes d'indices client tels que RTT ou Downlink, car il s'agit de facteurs de connexion qui peuvent changer assez souvent.Vary Si vous souhaitez modifier les réponses sur ces en-têtes, envisagez de n'utiliser que l'en-tête ECT, ce qui minimisera les échecs de cache.
Bien sûr, cela ne s'applique que si vous mettez en cache une réponse en premier lieu.
Par exemple, vous ne mettez pas en cache les éléments HTML si leur contenu est dynamique, car cela peut nuire à l'expérience utilisateur lors des visites répétées. Dans ce cas, n'hésitez pas à modifier ces réponses selon ce qui vous semble nécessaire, sans vous soucier de Vary.
Indicateurs client dans les service workers
La négociation de contenu n'est plus réservée aux serveurs. Comme les service workers agissent comme des proxys entre les clients et les serveurs, vous pouvez contrôler la façon dont les ressources sont fournies via JavaScript. Cela inclut les indications client. Dans l'événement fetch du service worker, vous pouvez utiliser la méthode request.headers.get de l'objet event pour lire les en-têtes de requête d'une ressource comme suit :
self.addEventListener('fetch', (event) => {
let dpr = event.request.headers.get('DPR');
let viewportWidth = event.request.headers.get('Viewport-Width');
let width = event.request.headers.get('Width');
event.respondWith(
(async function () {
// Do what you will with these hints!
})(),
);
});
Tout en-tête d'indication client que vous activez peut être lu de cette manière. Toutefois, ce n'est pas la seule façon d'obtenir certaines de ces informations. Les indications spécifiques au réseau peuvent être lues dans ces propriétés JavaScript équivalentes de l'objet navigator :
| Hint client | Équivalent JS |
|---|---|
| `ECT` | `navigator.connection.effectiveType` |
| `RTT` | `navigator.connection.rtt` |
| `Save-Data` | `navigator.connection.saveData` |
| `Downlink` | `navigator.connection.downlink` |
| `Device-Memory` | `navigator.deviceMemory` |
Étant donné que ces API ne sont pas disponibles partout, vous devez vérifier les fonctionnalités avec l'opérateur in :
if ('connection' in navigator) {
// Work with netinfo API properties in JavaScript!
}
À partir de là, vous pouvez utiliser une logique semblable à celle que vous utiliseriez sur le serveur, sauf que vous n'avez pas besoin de serveur pour négocier le contenu avec les indices du client. Les service workers sont les seuls à pouvoir rendre les expériences plus rapides et plus résilientes, car ils peuvent diffuser du contenu lorsque l'utilisateur est hors connexion.
Conclusion
Grâce aux indications client, nous pouvons rendre les expériences plus rapides pour les utilisateurs de manière entièrement progressive. Nous pouvons diffuser des contenus multimédias en fonction des capacités de l'appareil de l'utilisateur, ce qui facilite la diffusion d'images responsives par rapport à l'utilisation de <picture> et srcset, en particulier pour les cas d'utilisation complexes. Cela nous permet non seulement de réduire le temps et les efforts de développement, mais aussi d'optimiser les ressources, en particulier les images, de manière à cibler les écrans des utilisateurs plus précisément que
Plus important encore, nous pouvons détecter les mauvaises connexions réseau et combler le manque à gagner pour les utilisateurs en modifiant ce que nous envoyons et la façon dont nous l'envoyons. Cela peut grandement faciliter l'accès aux sites pour les utilisateurs disposant de réseaux instables. Combinés aux service workers, ils nous permettent de créer des sites incroyablement rapides et disponibles hors connexion.
Bien que les indications client ne soient disponibles que dans Chrome et les navigateurs basés sur Chromium, il est possible de les utiliser de manière à ne pas gêner les navigateurs qui ne les prennent pas en charge. Envisagez d'utiliser les indications client pour créer des expériences véritablement inclusives et adaptables, qui tiennent compte des capacités de l'appareil de chaque utilisateur et des réseaux auxquels il se connecte. Nous espérons que d'autres fournisseurs de navigateurs verront leur intérêt et manifesteront leur intention de les implémenter.
Ressources
- Images responsives automatiques avec les indications client
- Indices client et images responsives : ce qui a changé dans Chrome 67
- Prenez un indice (client) ! (Slides)
- Créer des applications rapides et légères avec
Save-Data
Merci à Ilya Grigorik, Eric Portis, Jeff Posnick, Yoav Weiss et Estelle Weyl pour leurs précieux commentaires et modifications apportés à cet article.