S'adapter aux utilisateurs grâce aux indices client

Développer des sites rapides sur tous les marchés n'est pas une mince affaire. La pléthore des fonctionnalités des appareils, et la qualité des réseaux qu'ils connectent peut sembler être une tâche insurmontable. Bien que nous puissions prendre des fonctionnalités du navigateur pour améliorer les performances de chargement, comment savoir les capacités de l'appareil de l'utilisateur, ou la qualité de son réseau ; d'une connexion ? La solution est client d'astuces !

Il s'agit d'un ensemble d'en-têtes de requêtes HTTP à activer qui nous renseignent sur ces aspects de l'appareil de l'utilisateur et du réseau auquel il est connecté. Par exploitant ces informations côté serveur, nous pouvons modifier notre mode de diffusion en fonction de l'état 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 hints client constituent une autre méthode de négociation de contenu : vous devez donc modifier en fonction des en-têtes de requêtes du navigateur.

Un exemple de négociation de contenu implique Accept en-tête de requête. Il décrit les types de contenus que le navigateur comprend, lesquels permettant au serveur de négocier la réponse. Pour les demandes d'images, 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 soient compatibles avec des formats d'image tels que JPEG, PNG et GIF, Accept indique dans ce cas, 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 pour Accept, les indices côté client sont 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 indications client, peuvent prendre des décisions de performances côté serveur en fonction des caractéristiques comme décider si des ressources non critiques doivent être servies à aux utilisateurs dont le réseau est dans de mauvaises conditions. Dans ce guide, nous décrirons les astuces disponibles et comment les utiliser pour optimiser la diffusion de contenu. adaptée aux utilisateurs.

Activation

Contrairement à l'en-tête Accept, les suggestions du client ne s'affichent pas comme par magie (avec le exception de Save-Data, dont nous parlerons plus tard). Afin de conserver les en-têtes de requête au minimum, vous devez activer les indications client que vous souhaitez recevoir en envoyant un en-tête Accept-CH lorsqu'un utilisateur demande un ressource:

Accept-CH: Viewport-Width, Downlink

La valeur de Accept-CH est une liste d'indices demandés séparés par une virgule que le site l'utilisera pour déterminer les résultats des requêtes de ressources ultérieures. Lorsque le client lit cet en-tête, le message "Ce site veut l'Viewport-Width" et Downlink suggestions client." Ne vous souciez pas des indices spécifiques. Nous y reviendrons dans quelques instants.

Vous pouvez définir ces en-têtes d'activation dans n'importe quelle langue back-end. Par exemple, PHP' header. Vous pouvez même définir ces en-têtes d'acceptation avec le http-equiv sur un tag <meta>:

<meta http-equiv="Accept-CH" content="Viewport-Width, Downlink" />

Toutes les indications client !

Les hints client décrivent l'un des deux éléments suivants: l'appareil utilisé par vos utilisateurs, et le réseau qu'ils utilisent pour accéder à votre site. Récapitulons brièvement les et conseils disponibles.

Astuces concernant l'appareil

Certaines suggestions du client décrivent les caractéristiques de l'appareil de l'utilisateur, généralement l'écran caractéristiques. Certains peuvent vous aider à choisir la ressource multimédia optimale pour l'écran d'un utilisateur donné, mais tous ne sont pas nécessairement centrés 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 lorsque vous ouvrez une image dans Photoshop, les dimensions indiquées dans la boîte de dialogue "Taille de l'image" décrire sa taille intrinsèque.

Taille intrinsèque corrigée avec la densité:les dimensions d'une ressource multimédia après la densité en pixels a été corrigée. C'est la taille intrinsèque de l'image. divisé par un pixel de l'appareil ratio. 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."
/>

Imaginons que la taille intrinsèque de l'image 1x soit de 320 x 240, et que La taille intrinsèque de l'image 2x est de 640 x 480. Si ce balisage est analysé par un client installé sur un appareil dont le rapport de pixels est de 2 (par exemple, un écran Retina) écran), l'image 2x est demandée. La taille intrinsèque corrigée de la densité de l'image 2x mesure 320 x 240, car 640 x 480 divisé par 2 équivaut à 320 x 240.

Taille externe:taille d'une ressource multimédia après la mise en page CSS ou autre. facteurs (tels que les attributs width et height) qui lui ont été appliqués. Supposons que vous disposiez d'un élément <img> qui charge une image dont la densité a été corrigée. taille intrinsèque de 320 x 240, mais les propriétés CSS width et height sont également incluses auxquels sont appliquées respectivement les valeurs 256px et 192px. Dans cet exemple, la taille extérieure de cet élément <img> devient 256 x 192.

Maintenant que nous avons acquis une terminologie spécifique, entrons dans la liste des applications les conseils client à votre disposition.

Largeur de la fenêtre d'affichage

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érentes traitements (recadrage) d'une image qui sont optimaux pour des tailles d'écran spécifiques (par exemple, l'art direction), ou pour omettre les ressources inutiles pour la largeur d'écran actuelle.

DPR

DPR, abréviation de "device pixel ratio", indique le ratio entre les pixels physiques et les fichiers CSS. pixels de l'écran de l'utilisateur:

DPR: 2

Cet indice est utile lorsque vous sélectionnez des sources d'image correspondant à la configuration densité de pixels (comme le font les descripteurs x dans srcset ).

Largeur

L'indice Width s'affiche pour les requêtes de ressources d'image déclenchées par <img> ou Balises <source> utilisant sizes . sizes indique au navigateur la taille externe de la ressource. Width utilise cette taille externe pour demander une image ayant une taille intrinsèque qui est optimale pour la mise en page actuelle.

Par exemple, imaginons qu'un utilisateur demande une page avec un écran d'une largeur de 320 pixels CSS. avec un DPR de 2. L'appareil charge un document avec un élément <img> contenant une valeur 85vw pour l'attribut sizes (par exemple, 85% de la largeur de la fenêtre d'affichage tailles d'écran). Si l'indicateur Width a été activé, le client envoie cette suggestion Width au serveur avec la requête pour le src de <img>:

Width: 544

Dans ce cas, le client indique au serveur qu'une fonctionnalité intrinsèque la largeur de l'image demandée correspond à 85% de celle de la fenêtre d'affichage (272 pixels). multiplié par la DPR de l'écran (2), soit 544 pixels.

Cet indice est particulièrement efficace, car il ne tient pas seulement compte la largeur de l'écran après correction de la densité, mais aussi d'informations avec la taille externe de l'image dans la mise en page. Cela vous donne aux serveurs la possibilité de négocier des réponses d'image optimales l'écran et la mise en page.

République démocratique du contenu

Bien que vous sachiez déjà que les écrans ont un ratio de pixels d'appareil, les ressources ont leurs propres rapports de pixels. Dans les cas d'utilisation de sélection de ressources les plus simples, les ratios entre appareils et ressources peuvent être identiques. Mais attention… Lorsque les deux les en-têtes DPR et Width sont en jeu, la taille externe d'une ressource peut produire des scénarios où les deux diffèrent. C'est ici 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 qui doit être utilisé par mais avec un en-tête de réponse, les serveurs doivent envoyer chaque fois que DPR et Les indices Width permettent de 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 effectuer le scaling l'image fournie pour le rapport de pixels de l'appareil de l'écran et la mise en page. Sans cela, les images peuvent ne pas s'adapter correctement.

Mémoire de l'appareil

Techniquement, elle fait partie de la mémoire de l'appareil de l'API, Device-Memory révèle les approximativement souvenir de l'appareil actuel en Gio:

Device-Memory: 2

Un cas d'utilisation possible pour cette suggestion consisterait à réduire la quantité de JavaScript sont envoyées aux navigateurs sur les appareils dont la mémoire est limitée, car JavaScript est le plus les navigateurs de type de contenu gourmands en ressources généralement de charge. Vous pouvez également envoyer des images DPR moins volumineuses, car elles utilisent moins de mémoire pour le décodage.

Indices réseau

L'API Network Information fournit une autre Catégorie d'indications client qui décrivent les performances du réseau de l'utilisateur . À mon avis, il s'agit de l'ensemble d'indices le plus utile. Avec eux, nous ont la possibilité d'adapter l'expérience aux utilisateurs en modifiant la façon dont nous les proposons aux clients dont la connexion est lente.

Texte en temps réel

L'indice RTT fournit le délai aller-retour approximatif, en millisecondes, sur la couche d’application. La suggestion RTT, contrairement au DAR de la couche de transport, inclut le temps de traitement du serveur.

RTT: 125

Cet indice est utile en raison 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 permet d'accélérer la diffusion d'une expérience complète (par exemple, omettant certaines requêtes).

Liaison descendante

Si la latence est importante pour les performances de chargement, la bande passante a une influence. . La suggestion Downlink, exprimée en mégabits par seconde (Mbit/s), révèle la Vitesse approximative de la connexion de l'utilisateur en aval:

Downlink: 2.5

Combiné à RTT, Downlink peut être utile pour modifier la façon dont le contenu est livré aux utilisateurs en fonction de la qualité d'une connexion réseau.

ECT

L'indice ECT signifie Effective Connection Type (Type de connexion effectif). Sa valeur est l'une des valeurs une liste énumérée de types de connexions, chacun décrivant une connexion dans les plages spécifiées de RTT et Downlink valeurs.

Cet en-tête n'explique pas quel est le type de connexion réel, par Par exemple, il n'indique pas si votre passerelle est une antenne-relais ou un réseau Wi-Fi point d'accès. Il analyse plutôt la latence et la bande passante de la connexion actuelle, et détermine à quel profil réseau il ressemble le plus. Par exemple, si vous connectez via le Wi-Fi vers un réseau lent, ECT peut être renseigné avec la valeur 2g, qui est l'approximation la plus proche de la connexion effectuée:

ECT: 2g

Les valeurs valides pour ECT sont 4g, 3g, 2g et slow-2g. Cet indice peut être utilisée comme point de départ pour évaluer la qualité de la connexion. affinées à l'aide des suggestions RTT et Downlink.

Enregistrer les données

Save-Data n'est pas tant un indice décrivant les conditions du réseau que l'utilisateur. indiquant que les pages doivent envoyer moins de données.

Je préfère considérer Save-Data comme une suggestion de réseau, car de nombreux paramètres que vous effectueriez avec les indications réseau. Les utilisateurs peuvent également être susceptibles de l'activer dans des environnements à latence élevée/faible bande passante. Ce conseil, lorsque présent, se présente toujours comme suit:

Save-Data: on

Chez Google, nous avons parlé de ce que vous pouvez faire avec Save-Data. L'impact sur les performances peut être considérable. C'est un signal grâce auquel les utilisateurs vous demandent littéralement de leur envoyer moins de choses ! Si vous écoutez et agissez en conséquence , cela plaira aux utilisateurs.

Associer les différentes structures

Ce que vous faites avec les indications client dépend de vous. Parce qu’ils offrent beaucoup de choses informations, vous avez de nombreuses options. Pour laisser libre cours à vos idées, voyons ce que pour Sconnie Timber, un bois fictif située dans la zone rurale du Haut-Midwest. Comme c'est souvent le cas dans par zone géographique, les connexions réseau peuvent être fragiles. C'est ici qu'une technologie comme les indices pour les clients peut vraiment faire une différence pour les utilisateurs.

Images responsives

Tous les cas d'utilisation d'images responsives, sauf les plus simples, peuvent se compliquer. Et si vous avoir plusieurs traitements et des variantes d'une même image pour différents écrans tailles d'annonces et différents formats ? Ce balisage devient très compliqué, très rapidement. Il est facile de se tromper, et il est facile d'oublier ou de mal comprendre (par exemple, sizes).

Si <picture> et srcset sont des outils incontestablement géniaux, ils peuvent être longs à développer et à gérer pour des cas d'utilisation complexes. Nous pouvons automatiser pour générer des balises, mais il est également difficile de le faire, car la fonctionnalité <picture> et srcset sont suffisamment complexes pour répondre à leurs besoins d'automatisation tout en conservant la flexibilité qu'ils offrent.

Les optimisations destinées au client peuvent simplifier ce processus. Négocier les réponses d'image avec le client Voici à quoi peuvent ressembler les indices:

1. Le cas échéant, sélectionnez d'abord un traitement d'image (par exemple, images destinées à des œuvres d'art) en cochant la case Viewport-Width.
2. Sélectionnez une résolution d'image en consultant les indices Width et DPR. choisir une source adaptée à la taille de mise en page et à la densité de l'écran de l'image (comme le fonctionnement des descripteurs x et w dans srcset).
3. Sélectionnez le format de fichier optimal compatible avec le navigateur (Accept dans la plupart des navigateurs).

Là où était inquiet mon client fictif de la société de bois, j’ai développé un modèle naïf routine de sélection d'images responsive en PHP qui utilise les suggestions 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 le réduire à ce qui suit grâce à 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 correspond à un script PHP suivi de paramètres. réécrit par mod_rewrite. Il 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 ne s'agit-il pas simplement de réimplémenter <picture> et srcset sur les ou backend ?" est votre première question.

D'une certaine manière, oui, mais avec une distinction importante: lorsqu'une application utilise conseils du client pour élaborer des réponses médiatiques, la plupart (voire la totalité) du travail plus facile à automatiser, ce qui peut inclure un service (un CDN, par exemple) capable de le faire en votre nom. Avec les solutions HTML, le nouveau balisage doit être écrit pour chaque cas d'utilisation. Bien sûr, vous pouvez automatiser la génération de balisage. Si votre l'évolution de la conception ou des exigences, il y a de fortes chances que à revoir votre stratégie d'automatisation par la suite.

Les hints client permettent de commencer avec une haute résolution sans perte image qui peut ensuite être redimensionnée de façon dynamique afin d'optimiser toute combinaison de l'écran et de la mise en page. Contrairement à srcset, qui nécessite d'énumérer une valeur fixe liste d'images candidates que le navigateur peut choisir, cette approche peut être plus flexible. Bien que srcset vous oblige à proposer aux navigateurs un ensemble approximatif de variantes (par exemple, 256w, 512w, 768w et 1024w) pour vous donner et optimisée, qui peut diffuser des annonces de toutes largeurs, sans qu'il soit nécessaire de s'empiler sur une immense pile de balisage.

Bien entendu, vous n'avez pas besoin d'écrire vous-même la logique de sélection des images. Cloudinaire utilise les hints client pour créer des réponses d'image lorsque vous utilisez w_auto , et constaté que les utilisateurs médians avaient téléchargé 42% d'octets en moins lorsqu'ils se trouvaient dans un navigateur. avec la prise en charge des indications destinées aux clients.

Mais attention ! Les modifications apportées à la version pour ordinateur de Chrome 67 ont supprimé la compatibilité pour les clients multi-origines conseils. Heureusement, ces restrictions n'affectent pas les versions mobiles de Chrome. elles disparaîtront complètement pour toutes les plates-formes si vous travaillez sur la fonctionnalité la règle est terminée.

Aider les utilisateurs dont les réseaux sont lents

Les performances adaptatives signifient que nous pouvons ajuster la façon dont nous fournissons les ressources en fonction des informations mises à notre disposition par le client ; en particulier des 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é dans notre code back-end. Ensuite, nous générons un rapport de qualité que nous utilisons pour déterminer si nous devons intervenir pour améliorer l'expérience expérience. Ce score réseau est compris entre 0 et 1 (0 étant la pire note). de réseau, mais 1 est la meilleure.

Pour commencer, 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 prenions les mesures nécessaires pour que pour une expérience plus fluide et plus rapide.

Toutefois, si Save-Data est absent, nous passons à la suite et pesons les valeurs de ECT, Indices RTT et Downlink pour calculer un score décrivant le réseau la qualité de la connexion. La source de génération de score réseau du code est disponible sur GitHub. Ce qu’il faut retenir, c’est que si nous utilisons les conseils liés au réseau dans un certain type, nous pouvons améliorer l'expérience des utilisateurs lents. réseaux sociaux.

Lorsque les sites s'adaptent aux informations fournies par les clients, nous n'avons pas à adopter une approche du « tout ou rien ». Nous pouvons décider intelligemment des ressources à utiliser envoyer. Nous pouvons modifier notre logique de sélection d'images responsive pour envoyer des images de moins bonne qualité d'images pour un écran donné afin d'accélérer les performances de chargement lorsque la qualité du réseau est faible.

Cet exemple montre l'impact des conseils clients l'amélioration des performances des sites sur des réseaux plus lents. Vous trouverez ci-dessous un test de page Web cascade d'un site sur un réseau lent qui ne s'adapte pas aux indications du client:

Et maintenant, une cascade d'annonces pour le même site avec la même connexion lente, temps, le site utilise les indications du client pour éliminer les ressources non essentielles de la page:

Les indications du client ont réduit le temps de chargement de la page, passant de plus de 45 secondes à moins d'un dixième de cette durée. Dans ce scénario, les avantages des conseils destinés aux clients et peut être une aubaine pour les utilisateurs à la recherche d'informations des informations sur des réseaux lents.

De plus, il est possible d'utiliser les indications client sans perturber l'expérience. pour les navigateurs qui ne sont pas compatibles. Par exemple, pour ajuster les ressources La diffusion de la valeur de l'indicateur ECT tout en continuant à diffuser l'intégralité 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é (l'en-tête ECT). décrit. Si nous initialisons $ect sur "4g", les navigateurs qui ne prennent pas en charge le client Les conseils ne seront pas affectés. Activez la nouvelle version !

Faites attention à ces caches !

Chaque fois que vous modifiez une réponse en fonction d'un en-tête HTTP, vous devez connaître la manière dont les caches traiteront les futures extractions de cette ressource. Vary en-tête est est indispensable, car elle permet d'associer les entrées de cache à la valeur des en-têtes de requête qui lui est fournie. En d'autres termes, si vous modifiez une réponse en fonction d'une requête HTTP donnée l'en-tête de requête, vous devez presque toujours inclure cet en-tête dans Vary comme suit:

Vary: DPR, Width

Une grande mise en garde toutefois: vous ne devez jamais Vary mettre en cache sur un en-tête changeant fréquemment (comme Cookie), car ces ne peuvent plus être mises en cache. Sachant cela, vous voudrez peut-être éviter Vary sur les en-têtes d'indication du client tels que RTT ou Downlink, car il s'agit facteurs de connexion qui pourraient changer assez souvent. Si vous souhaitez modifier réponses sur ces en-têtes, envisagez de ne saisir que l'en-tête ECT, ce qui pour minimiser les défauts de cache (miss).

Bien sûr, cela ne s'applique que si vous mettez d'abord une réponse en cache. Par exemple, vous ne mettrez pas en cache les éléments HTML dont le contenu est dynamique, car qui peuvent nuire à l'expérience utilisateur lors de visites répétées. Dans de tels cas, ressentez de modifier ces réponses à votre convenance, vous préoccupez-vous de Vary.

Indices client dans les service workers

La négociation de contenu ne se limite plus aux serveurs. Comme les service workers agissent en tant que proxys entre les clients et les serveurs, vous contrôlez la façon dont les ressources sont diffusés via JavaScript. Cela inclut les indices côté client. Dans le service worker fetch, vous pouvez utiliser l'objet event request.headers.get 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'indice client que vous activez peut être lu de cette manière. Bien que cela soit pas le seul moyen d’obtenir certaines de ces informations. Conseils spécifiques au réseau peut être lu dans les propriétés JavaScript équivalentes dans l'objet navigator:

Plug-ins Imagemin pour les types de fichiers.

Indice client	Équivalent JS
"ECT"	`navigator.connection.effectiveType`
"DAR"	`navigator.connection.rtt`
"Save-Data"	`navigator.connection.saveData`
"Downlink"	`navigator.connection.downlink`
"Device-Memory" (Mémoire de l'appareil)	`navigator.deviceMemory`

Ces API ne sont pas disponibles partout où vous avez besoin d'une vérification des fonctionnalités in opérateur:

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 vous n'avez pas besoin d'un serveur pour négocier du contenu à l'aide des suggestions client. Service les travailleurs à eux seuls peuvent rendre l'expérience plus rapide et plus résiliente grâce à la possibilité supplémentaire qu'ils ont de servir du contenu lorsque l'utilisateur est hors connexion.

Conclusion

Grâce aux hints client, nous pouvons rendre l'expérience des utilisateurs plus rapide dans un de manière totalement progressive. Nous pouvons diffuser des contenus multimédias en fonction de l'appareil de l'utilisateur d'une manière qui facilite la diffusion d'images responsives sur <picture> et srcset, en particulier pour les cas d'utilisation complexes. Cela nous permet non seulement pour réduire le temps et les efforts nécessaires au développement, mais aussi pour optimiser ressources (en particulier les images), de manière à cibler les écrans des utilisateurs que et srcset peuvent le faire.

Peut-être plus important encore, nous pouvons détecter les mauvaises connexions réseau et ponter pour les utilisateurs en modifiant ce que nous envoyons (et la façon dont nous le faisons). Cela peut qui facilitent l'accès aux sites pour les utilisateurs de réseaux fragiles. Associés aux service workers, ils permettent de créer des sites incroyablement rapides disponibles hors connexion.

Les hints client ne sont disponibles que dans Chrome et dans Chromium les navigateurs, il est possible de les utiliser sans les encombrer. des navigateurs qui ne les prennent pas en charge. Pensez à utiliser les indications client pour créer de véritables des expériences inclusives et adaptables qui tiennent compte de l'appareil de chaque utilisateur leurs capacités et les réseaux auxquels ils se connectent. Espérons que d’autres fournisseurs de navigateurs verront leur valeur et montreront une intention de les implémenter.

Ressources

• Images responsives automatiques avec le client Astuces
• Conseils pour les clients et images responsives – Ce qui a changé dans Chrome 18
• Prenez un indice (client) ! (Slides)
• Proposer des applications rapides et légères avec Save-Data

Merci à Ilya Grigorik, Eric Portis, Jeff Posnick, Yoav Weiss et Estelle Weyl pour leur de précieux commentaires et de modifications à apporter à cet article.