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.
width: 256px;
et height: 192px;
transforme une image de taille intrinsèque de 320 x 240.
pour en obtenir une de 256 x 192 de taille extrinsque.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:
- 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
. - Sélectionnez une résolution d'image en consultant les indices
Width
etDPR
. choisir une source adaptée à la taille de mise en page et à la densité de l'écran de l'image (comme le fonctionnement des descripteursx
etw
danssrcset
). - 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.
![Comparaison d'un site qui n'utilise pas l'authentification
conseils pour s'adapter à une connexion réseau lente (à gauche) et au même site qui le fait
(à droite).](https://web.dev/static/articles/performance-optimizing-content-efficiency-client-hints/image/a-comparison-a-site-doe-b20caac28fc7f.png?authuser=6&hl=fr)
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:
![Une cascade WebPagetest de la Sconnie
Site Timber chargeant toutes les ressources avec une connexion réseau lente.](https://web.dev/static/articles/performance-optimizing-content-efficiency-client-hints/image/a-webpagetest-waterfall-6bc17bbfd8c27.png?authuser=6&hl=fr)
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:
![Une cascade WebPagetest de la Sconnie
Site Timber utilisant les indications du client pour décider de ne pas charger les ressources non critiques sur un
une connexion réseau lente.](https://web.dev/static/articles/performance-optimizing-content-efficiency-client-hints/image/a-webpagetest-waterfall-3ba4268e712f2.png?authuser=6&hl=fr)
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
:
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
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.