Développer des sites rapides partout peut s'avérer délicat. La pléthore de fonctionnalités des appareils et la qualité des réseaux auxquels ils se connectent peuvent donner l'impression que la tâche est insurmontable. Bien que nous puissions tirer parti des fonctionnalités du navigateur pour améliorer les performances de chargement, comment pouvons-nous déterminer les capacités de l'appareil de l'utilisateur ou la qualité de sa connexion réseau ? La solution : des indices au niveau du client.
Les indications client sont un ensemble d'en-têtes de requêtes HTTP à activer qui nous donnent des informations sur ces aspects de l'appareil de l'utilisateur et du réseau auquel il est connecté. En exploitant ces informations côté serveur, nous pouvons modifier la façon de diffuser 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.
Négociation de contenus : la clé du succès
Les indications client constituent une autre méthode de négociation de contenu, ce qui implique de modifier les réponses du contenu en fonction des en-têtes de requête du navigateur.
L'en-tête de requête Accept est un exemple de négociation de contenu. Il décrit les types de contenu que le navigateur reconnaît et que le serveur peut utiliser pour négocier la réponse. Pour les requêtes d'image, le contenu de l'en-tête Accept de Chrome est le suivant:
Accept: image/webp,image/apng,image/*,*/*;q=0.8
Bien que tous les navigateurs prennent en charge les formats d'image tels que JPEG, PNG et GIF, la commande Accept indique dans ce cas que le navigateur est également compatible avec WebP et APNG. Ces informations nous permettent de négocier les types d'images les mieux adaptés à 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 constituent un autre moyen de négocier du contenu, mais dans le contexte des capacités de l'appareil et des conditions du réseau. Avec les indices client, nous pouvons prendre des décisions concernant les performances côté serveur en fonction de l'expérience individuelle de l'utilisateur, par exemple décider si des ressources non critiques doivent être diffusées auprès d'utilisateurs dont l'état du réseau est mauvaise. Dans ce guide, nous allons décrire toutes les indications disponibles et vous expliquer comment 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, que nous aborderons ultérieurement). Afin de limiter au minimum les en-têtes de requête, vous devez activer les indices 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 d'indicateurs demandés, séparés par une virgule, que le site utilisera pour déterminer les résultats de la requête de ressource ultérieure. Lorsque le client lit cet en-tête, on lui dit "Ce site souhaite les indicateurs client Viewport-Width et Downlink". Ne vous souciez pas des indicateurs spécifiques.
Nous y reviendrons dans un instant.
Vous pouvez définir ces en-têtes d'activation dans n'importe quelle langue 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 du 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. Voyons brièvement tous les conseils disponibles.
Indices de l'appareil
Certaines suggestions client décrivent les caractéristiques de l'appareil de l'utilisateur, généralement des caractéristiques d'écran. Certaines d'entre elles peuvent vous aider à choisir la ressource multimédia optimale pour l'écran d'un utilisateur donné, mais elles ne sont pas toutes nécessairement axées sur les médias.
Avant d'entrer dans cette liste, il peut être utile de connaître quelques termes clés utilisés pour décrire les écrans et la résolution multimédia:
Taille intrinsèque:dimensions réelles d'une ressource multimédia. Par exemple, si vous ouvrez une image dans Photoshop, les dimensions affichées dans la boîte de dialogue "Taille de l'image" décrivent sa taille intrinsèque.
Taille intrinsèque corrigée en densité:dimensions d'une ressource multimédia après correction de la densité en pixels. Il s'agit de la taille intrinsèque de l'image divisée par le ratio de pixels de l'appareil. Prenons l'exemple de ce balisage:
<img
src="whats-up-1x.png"
srcset="whats-up-2x.png 2x, whats-up-1x.png 1x"
alt="I'm that image you wanted."
/>
Imaginons 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 est de 2 (par exemple, un écran Retina), l'image 2x est demandée. La taille intrinsèque corrigée en densité de l'image 2x est de 320 x 240, car 640 x 480 divisé par 2 correspond à 320 x 240.
Taille externe:taille d'une ressource multimédia une fois que le CSS et d'autres facteurs de mise en page (tels que les attributs width et height) lui ont été appliqués. Supposons que vous ayez un élément <img> qui charge une image avec une taille intrinsèque corrigée en densité de 320 x 240, mais qu'il comporte également des propriétés CSS width et height auxquelles les valeurs 256px et 192px sont appliquées, respectivement. Dans cet exemple, la taille externe de cet élément <img> devient 256 x 192.
width: 256px; et height: 192px; transforme une image de 320 x 240 de taille intrinsèque en une image de 256 x 192 dont la taille est externe.Voici la liste des clients spécifiques à l'appareil à votre disposition.
Fenêtre d'affichage-Largeur
Viewport-Width est la largeur de la fenêtre d'affichage de l'utilisateur en pixels CSS:
Viewport-Width: 320
Cette suggestion peut être utilisée avec d'autres suggestions spécifiques à l'écran pour fournir différents traitements (cadrages, par exemple) d'une image qui conviennent à des tailles d'écran spécifiques (par exemple, la direction artistique), ou pour omettre les ressources inutiles pour la largeur d'écran actuelle.
RPD
DPR, l'abréviation de "device pixel ratio", indique le ratio entre les pixels physiques et les pixels CSS de l'écran de l'utilisateur:
DPR: 2
Cette indication 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
La suggestion Width s'affiche pour les requêtes de ressources image déclenchées par les balises <img> ou <source> à l'aide de l'attribut sizes.
sizes indique au navigateur la taille externe de la ressource. Width utilise cette taille externe pour demander une image dont la taille intrinsèque est optimale pour la mise en page actuelle.
Par exemple, imaginons qu'un utilisateur demande une page avec un écran large de 320 pixels CSS avec un rapport DPR de 2. L'appareil charge un document avec un élément <img> contenant une valeur d'attribut sizes de 85vw (par exemple, 85% de la largeur de la fenêtre d'affichage pour toutes les tailles d'écran). Si la suggestion Width a été activée, le client envoie cette suggestion Width au serveur avec la requête de 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 égale à 85% de la largeur de la fenêtre d'affichage (272 pixels) multipliée par la DPR de l'écran (2), soit 544 pixels.
Cette indication est particulièrement efficace, car elle prend non seulement en compte la largeur de l'écran corrigée en fonction de la densité, mais elle rapproche également cette information essentielle avec la taille externe de l'image dans la mise en page. Cela permet aux serveurs de négocier des réponses d'image optimales pour l'écran et la mise en page.
RPD sur le contenu
Bien que vous sachiez déjà que les écrans ont un ratio de pixels de l'appareil, les ressources ont également leurs propres ratios 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… Si les en-têtes DPR et Width entrent tous les deux en jeu, la taille externe d'une ressource peut produire des scénarios dans lesquels les deux sont différents. C'est là que la suggestion Content-DPR entre en jeu.
Contrairement aux autres suggestions client, Content-DPR n'est pas un en-tête de requête destiné aux serveurs, mais 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 de l'écran et la mise en page. Sans cela, les images risquent de ne pas s'adapter correctement.
Mémoire de l'appareil
Techniquement, fait partie de l'API Device Memory, Device-Memory indique la quantité approximative de mémoire dont dispose l'appareil actuel en Gio:
Device-Memory: 2
Un cas d'utilisation de cette suggestion serait de réduire la quantité de code JavaScript envoyé aux navigateurs sur les appareils disposant d'une mémoire limitée, étant donné que JavaScript est le type de contenu le plus gourmand en ressources généralement chargé par les navigateurs. Vous pouvez également envoyer des images DPR plus faibles, car elles utilisent moins de mémoire pour le décodage.
Indices réseau
L'API Network Information fournit une autre catégorie d'indicateurs client qui décrivent les performances de la connexion réseau de l'utilisateur. À mon avis, cet ensemble d'indices est le plus utile. Grâce à eux, nous pouvons adapter l'expérience aux utilisateurs en modifiant la façon dont nous fournissons des ressources aux clients dont la connexion est lente.
Texte en temps réel
La suggestion RTT indique le délai aller-retour approximatif, en millisecondes, sur la couche d'application. L'indice RTT, contrairement au DAR de la couche transport, inclut le temps de traitement du serveur.
RTT: 125
Cette suggestion est utile du fait du rôle de la latence dans les performances de chargement.
L'indice RTT nous permet de prendre des décisions en fonction de la réactivité du réseau, ce qui peut contribuer à accélérer la diffusion d'une expérience complète (par exemple, en omettant certaines requêtes).
Liaison descendante
Si la latence est importante pour les performances de chargement, la bande passante joue également un rôle. La suggestion Downlink, exprimée en mégabits par seconde (Mbit/s), indique la vitesse en aval approximative de la connexion de l'utilisateur:
Downlink: 2.5
Combiné à RTT, Downlink peut être utile pour modifier la façon dont le contenu est diffusé auprès des utilisateurs en fonction de la qualité d'une connexion réseau.
ECT
L'optimisation ECT correspond à Effective Connection Type. Sa valeur figure dans une liste énumérée de types de connexion, 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, puis détermine le profil réseau qui lui 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 l'affiner à l'aide des indications RTT et Downlink.
Enregistrer les données
Save-Data n'est pas seulement un indice décrivant les conditions du réseau, mais une préférence utilisateur indiquant que les pages doivent envoyer moins de données.
Je préfère classer Save-Data en tant qu'indice de réseau, car la plupart des tâches que vous effectueriez s'apparentent aux autres indications réseau. Les utilisateurs peuvent également l'activer dans des environnements à latence élevée/faible bande passante. Ce indice, lorsqu'il est présent, se présente toujours comme suit:
Save-Data: on
Chez Google, nous avons parlé des possibilités qu'offre Save-Data.
L'impact sur les performances peut être considérable. C'est le signe que les utilisateurs
vous demandent de moins en envoyer ! Si vous écoutez et agissez en fonction
de ce signal, les utilisateurs l’apprécieront.
Associer les différentes structures
La façon dont vous disposez avec les indicateurs client dépend de vous. Ils offrent tellement d’informations que vous avez de nombreuses options. Pour laisser libre cours à vos idées, voyons ce que les clients peuvent faire pour Sconnie Timber, une entreprise fictive de bois située dans la région rurale du Midwest. Comme c'est souvent le cas dans les zones distantes, 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, sauf les plus simples, peuvent s'avérer compliqués. Que se passe-t-il si vous utilisez plusieurs traitements et variantes des mêmes images pour différentes tailles d'écran, et différents formats ? Ce balisage devient très complexe, très rapide.
Il est facile de se tromper, et d'oublier ou de mal comprendre des concepts importants (tels que sizes).
Bien que <picture> et srcset soient incontestablement géniaux, leur développement et leur gestion peuvent prendre beaucoup de temps pour des cas d'utilisation complexes. Il est possible d'automatiser la génération du balisage, mais cela est également difficile, car les fonctionnalités fournies par <picture> et srcset sont suffisamment complexes pour que leur automatisation soit effectuée de manière à conserver la flexibilité qu'elles offrent.
Les indications client peuvent simplifier ce processus. La négociation de réponses d'images à l'aide d'indications client peut se présenter comme suit:
- Le cas échéant, sélectionnez d'abord un traitement d'image (c'est-à-dire des images destinées à l'art) en cochant la suggestion
Viewport-Width. - Sélectionnez une résolution d'image en consultant les indications
WidthetDPR, puis choisissez une source qui correspond à la taille de mise en page et à la densité d'écran de l'image (comme le fonctionnement des descripteursxetwdanssrcset). - Sélectionnez le format de fichier optimal compatible avec le navigateur (c'est ce que
Acceptnous aide dans la plupart des navigateurs).
En ce qui concerne mon client fictif, j'ai développé en PHP une routine de sélection d'images responsives naïve qui utilise les indications du client. Cela signifiait 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 réduire ce nombre à ce qui suit en fonction de la compatibilité de chaque navigateur:
<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 à l'aide de mod_rewrite. Elle utilise un nom de fichier d'image et des paramètres supplémentaires pour aider un script backend à choisir la meilleure image dans les conditions données.
Je comprends que mais n'est-ce pas simplement la réimplémentation de <picture> et srcset sur le backend ? est votre première question.
D'une certaine manière, oui, mais avec une distinction importante: lorsqu'une application utilise des indices client pour créer des réponses multimédias, la plupart (voire la totalité) du travail est beaucoup plus facile à automatiser, ce qui peut inclure un service (tel qu'un CDN) capable de le faire en votre nom. Contrairement aux solutions HTML, un nouveau balisage doit être écrit pour chaque cas d'utilisation. Bien sûr, vous pouvez automatiser la génération de balisages. Toutefois, si votre conception ou vos exigences changent, vous devrez probablement revoir votre stratégie d'automatisation par la suite.
Les optimisations client permettent de commencer avec une image haute résolution sans perte, qui peut ensuite être redimensionnée dynamiquement pour être optimale pour toute combinaison d'écran et de mise en page. Contrairement à srcset, qui nécessite d'énumérer une liste fixe d'images candidates possibles pour le navigateur, cette approche peut se révéler plus flexible. Alors que srcset vous oblige à proposer aux navigateurs un ensemble approximatif de variantes (par exemple, 256w, 512w, 768w et 1024w), une solution basée sur les indications client peut être diffusée dans toutes les largeurs, sans s'accumuler dans le balisage.
Bien entendu, vous n'avez pas à écrire vous-même la logique de sélection des images. Cloudinary utilise les indicateurs client pour créer des réponses d'image lorsque vous utilisez le paramètre w_auto et a observé que les utilisateurs médians ont téléchargé 42% d'octets en moins dans les navigateurs compatibles avec les indications client.
Mais attention ! Des modifications apportées à la version de bureau de Chrome 67 ont supprimé la compatibilité des indications client multi-origines. Heureusement, ces restrictions n'affectent pas les versions mobiles de Chrome. Elles seront complètement supprimées pour toutes les plates-formes une fois que vous aurez terminé la réglementation des fonctionnalités.
Aider les utilisateurs dont le réseau est lent
Les performances adaptatives nous permettent d'ajuster la manière dont nous fournissons des ressources en fonction des informations mises à notre disposition par le client, en particulier les informations concernant 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, avec les en-têtes Save-Data, ECT, RTT et Downlink en cours d'examen dans notre code backend. Une fois cette opération effectuée, nous générons un niveau de qualité du réseau qui nous permet de déterminer si nous devons intervenir pour améliorer l'expérience utilisateur. Ce score de réseau est compris entre 0 et 1, où 0 correspond à la meilleure qualité de réseau possible et 1 à la meilleure qualité possible.
Dans un premier temps, nous vérifions 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 ce qui est nécessaire pour alléger et accélérer l'expérience.
Toutefois, si Save-Data est absent, nous continuons et pondons 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 de scores réseau est disponible sur GitHub. Conclusion : si nous utilisons les indices liés au réseau d'une manière ou d'une autre, nous pouvons améliorer l'expérience pour les utilisateurs qui utilisent des réseaux lents.
Lorsque les sites s'adaptent aux informations fournies par les indices du client, nous n'avons pas besoin d'adopter l'approche "tout ou rien". Nous pouvons décider intelligemment quelles ressources envoyer. Nous pouvons modifier notre logique de sélection d'image responsive pour envoyer des images de qualité inférieure pour un écran donné. Cela permet 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 indices client sur l'amélioration des performances des sites sur des réseaux plus lents. Vous trouverez ci-dessous une cascade d'annonces WebPagetest sur un site dont le réseau est lent et qui ne s'adapte pas aux indications des clients:
Il s'agit désormais d'une cascade pour le même site sur la même connexion lente, sauf que cette fois-ci, le site utilise des indications client pour éliminer les ressources de page non critiques:
Les indications client ont réduit le temps de chargement de la page de plus de 45 secondes à moins d'un dixième de ce temps. Dans ce scénario, les avantages des indices client ne sont pas assez soulignés et peuvent constituer un véritable avantage pour les utilisateurs qui recherchent des informations essentielles sur des réseaux lents.
De plus, il est possible d'utiliser les indications client sans interrompre l'expérience pour les navigateurs non compatibles. Par exemple, si nous souhaitons ajuster la distribution des ressources en fonction de la valeur de l'indicateur ECT tout en offrant une expérience complète pour les navigateurs non compatibles, nous pouvons définir 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 $ect est initialisé sur "4g", les navigateurs qui ne sont pas compatibles avec les indications du client ne seront pas affectés. Activer FTW !
Attention à ces caches !
Chaque fois que vous modifiez une réponse basée sur un en-tête HTTP, vous devez savoir comment les caches traiteront les futures récupérations de cette ressource. L'en-tête Vary est incontrôlable ici, car il associe les entrées de cache à la valeur des en-têtes de requête qui lui sont fournis. Pour faire simple, si vous modifiez une réponse en fonction d'un en-tête de requête HTTP donné, vous devez presque toujours inclure la requête correspondant à cet en-tête dans Vary comme suit:
Vary: DPR, Width
Cependant, il existe une grande mise en garde: vous ne souhaitez jamais Vary de réponses pouvant être mises en cache sur un en-tête changeant fréquemment (comme Cookie), car ces ressources ne peuvent plus être mises en cache. Sachant cela, vous devriez éviter d'utiliser Vary 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. Si vous souhaitez modifier les réponses sur ces en-têtes, envisagez de ne saisir que l'en-tête ECT, ce qui réduira les défauts de cache (miss).
Bien entendu, cela ne s'applique que si vous mettez en cache une réponse en premier lieu.
Par exemple, vous ne mettrez pas en cache les assets HTML si leur contenu est dynamique, car cela peut nuire à l'expérience utilisateur lors des visites répétées. Dans de tels cas, n'hésitez pas à modifier ces réponses selon ce que vous jugez nécessaire, sans vous soucier de Vary.
Optimisations client dans les service workers
La négociation de contenu n'est plus réservée aux serveurs ! Étant donné que les service workers servent de proxys entre les clients et les serveurs, vous contrôlez la manière 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'indications client que vous activez peut être lu de cette manière. Cependant, ce n'est pas le seul moyen
d'obtenir certaines de ces informations. Les indications propres au réseau peuvent être lues dans les propriétés JavaScript équivalentes de l'objet navigator:
| Indice pour le client | Équivalent JS |
|---|---|
| "ECT" | `navigator.connection.effectiveType` |
| DAR | "navigator.connection.rtt" |
| Enregistrer les données | `navigator.connection.saveData` |
| "Lien descendant" | `navigator.connection.downlink` |
| "Mémoire de l'appareil" | "navigator.deviceMemory" |
Étant donné que ces API ne sont pas disponibles partout, vous avez besoin d'une vérification des fonctionnalités à l'aide de 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 d'un serveur pour négocier le contenu avec des indications client. À eux seuls, les service workers peuvent rendre les expériences plus rapides et plus résilientes, en raison de la possibilité supplémentaire de diffuser du contenu lorsque l'utilisateur est hors connexion.
Conclusion
Grâce aux conseils destinés aux clients, nous avons la possibilité d'accélérer l'expérience des utilisateurs de manière entièrement progressive. Nous pouvons diffuser des contenus multimédias en fonction des fonctionnalités de l'appareil de l'utilisateur de manière à faciliter la diffusion d'images responsives par rapport à <picture> et srcset, en particulier pour les cas d'utilisation complexes. Cela nous permet non seulement de réduire le temps et les efforts nécessaires au développement, mais aussi d'optimiser les ressources (en particulier les images) d'une manière qui cible les écrans de l'utilisateur plus précisément que
Plus important encore, nous pouvons détecter les mauvaises connexions réseau et combler le fossé pour les utilisateurs en modifiant ce que nous envoyons et comment. Cela peut considérablement faciliter l'accès aux sites pour les utilisateurs de réseaux fragiles. En les associant à des service workers, nous pouvons créer des sites incroyablement rapides et accessibles hors connexion.
Bien que les indications client ne soient disponibles que dans Chrome et les navigateurs basés sur Chromium, vous pouvez les utiliser de manière à ne pas encombrer les navigateurs qui ne les prennent pas en charge. Pensez à utiliser les indicateurs client pour créer des expériences vraiment inclusives et adaptables qui tiennent compte des fonctionnalités de l'appareil de chaque utilisateur et des réseaux auxquels ils se connectent. J'espère que les autres fournisseurs de navigateurs en verront la valeur et montreront l'intention de les mettre en œuvre.
Ressources
- Images responsives automatiques avec indications du client
- Conseils client et images responsives – Ce qui a changé dans Chrome 67
- Donnez un indice (client) ! (Slides)
- Fournir 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 leurs modifications concernant cet article.