Adapta la app a usuarios con Client Hints

Desarrollar sitios rápidos en todas partes puede ser complicado. La plétora de las capacidades de los dispositivos y la calidad de las redes que conectan puede hacer que parezca una tarea insuperable. Si bien podemos tomar las funciones del navegador para mejorar el rendimiento de carga, ¿cómo sabemos qué es capaz de hacer el dispositivo del usuario o la calidad de su red conexión? La solución es que el cliente sugerencias.

Las sugerencias de clientes son un conjunto de encabezados de solicitud HTTP opcionales que nos proporcionan información sobre estos aspectos del dispositivo del usuario y la red a la que está conectado. De aprovechando este lado del servidor de información, podemos cambiar cómo brindamos contenido según el estado del dispositivo o de la red. Esto puede ayudarnos a crear experiencias del usuario más inclusivas.

Lo que importa es la negociación del contenido

Las sugerencias de clientes son otro método de negociación de contenido, lo que significa cambiar respuestas de contenido basadas en encabezados de solicitud del navegador.

Un ejemplo de negociación de contenido implica Accept encabezado de la solicitud. Describe qué tipos de contenido entiende el navegador, lo cual que el servidor puede usar para negociar la respuesta. En el caso de las solicitudes de imágenes, del encabezado Accept de Chrome es:

Accept: image/webp,image/apng,image/*,*/*;q=0.8

Si bien todos los navegadores admiten formatos de imagen como JPEG, PNG y GIF, Accept le indica En este caso, el navegador también es compatible con WebP y APNG Con esta información, podemos Negociar los mejores tipos de imágenes para cada navegador:

<?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!">

Al igual que Accept, las sugerencias de clientes son otra forma de negociar contenido, pero el contexto de las capacidades del dispositivo y las condiciones de la red. Con las sugerencias de clientes, puede tomar decisiones de rendimiento del servidor según la información experiencia, como decidir si los recursos no esenciales se deben entregar usuarios con malas condiciones de red. En esta guía, describiremos todos los las sugerencias disponibles y algunas formas en las que puedes usarlas para que la publicación de contenido sea más para los usuarios.

Cómo habilitarlo

A diferencia del encabezado Accept, las sugerencias de clientes no aparecen mágicamente (con el excepción de Save-Data, que analizaremos más adelante). Para mantener encabezados de solicitudes como mínimo, deberás habilitar las sugerencias de clientes que recibirás enviando un encabezado Accept-CH cuando un usuario solicite un recurso:

Accept-CH: Viewport-Width, Downlink

El valor de Accept-CH es una lista separada por comas de sugerencias solicitadas para el sitio usaremos para determinar los resultados de las solicitudes de recursos posteriores. Cuando un cliente lee este encabezado y le indica que "este sitio quiere la Viewport-Width y Downlink de las sugerencias de clientes”. No te preocupes por las pistas específicas en sí. Las veremos en un momento.

Puedes configurar estos encabezados de habilitación en cualquier idioma de backend. Por ejemplo, los PHP header. Incluso puedes configurar estos encabezados de habilitación con el elemento http-equiv atributo en una etiqueta <meta>:

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

Todas las sugerencias de clientes.

Las sugerencias de clientes describen uno de estos dos aspectos: el dispositivo que usan los usuarios. la red que usen para acceder a tu sitio. Veamos brevemente que están disponibles.

Sugerencias para dispositivos

Algunas sugerencias de clientes describen las características del dispositivo del usuario, que suelen ser pantallas del usuario. Algunas de ellas pueden ayudarte a elegir el recurso de medios óptimo para la pantalla de un usuario determinado, pero no todos ellos están necesariamente centrados en los medios.

Antes de empezar con esta lista, puede ser útil aprender algunos términos clave usados para describir pantallas y resolución de contenido multimedia:

Tamaño intrínseco: Las dimensiones reales de un recurso multimedia. Por ejemplo, abres una imagen en Photoshop, las dimensiones que aparecen en el diálogo de tamaño de la imagen describen su tamaño intrínseco.

Tamaño intrínseco corregido por densidad: Las dimensiones de un recurso multimedia después de corregimos la densidad de píxeles. Es el tamaño intrínseco de la imagen. dividida por un píxel del dispositivo relación de aspecto. Por ejemplo, tomemos este lenguaje de marcado:

<img
  src="whats-up-1x.png"
  srcset="whats-up-2x.png 2x, whats-up-1x.png 1x"
  alt="I'm that image you wanted."
/>

Supongamos que, en este caso, el tamaño intrínseco de la imagen 1x es de 320 x 240. El tamaño intrínseco de la imagen de 2x es de 640 x 480. Si un cliente analiza este lenguaje de marcado Se instale en un dispositivo con una proporción de píxeles del dispositivo de pantalla de 2 (p. ej., una pantalla Retina). pantalla), se solicita la imagen 2x. El tamaño intrínseco corregido por densidad de La imagen 2x es de 320 x 240, ya que 640 x 480 dividido por 2 es de 320 x 240.

Tamaño extremo: El tamaño de un recurso multimedia después de CSS y otros diseños se le aplicaron factores (como los atributos width y height). Veamos supongamos que tienes un elemento <img> que carga una imagen con una densidad corregida un tamaño intrínseco de 320 x 240, pero también tiene propiedades CSS width y height con valores de 256px y 192px aplicados, respectivamente. En este ejemplo, el tamaño extrínseco de ese elemento <img> pasa a ser 256 × 192.

Una ilustración del tamaño intrínseco frente a
tamaño extrínseco. Se muestra un cuadro de 320 x 240 píxeles con una etiqueta de INTRÍNSECO
SIZE Dentro de él, hay un cuadro más pequeño de 256 x 192 píxeles, que representa una
Elemento img de HTML con CSS aplicado. Este cuadro tiene la etiqueta EXTRINSIC
SIZE A la derecha, hay un cuadro que contiene CSS aplicado al elemento, el cual
modifica el diseño del elemento img para que su tamaño extrínseco difiera
a partir de su tamaño intrínseco.
Figura 1: Una ilustración de las diferencias entre tamaño extrínseco. Una imagen gana su tamaño extrínseco cuando se asignan los factores de diseño. que se le aplicaron. En este caso, aplicar las reglas de CSS de width: 256px; y height: 192px; transforma una imagen de 320 x 240 de tamaño intrínseco. a uno de 256 × 192 de tamaño extrínseco.

Ya tenemos algo de terminología, así que pasemos a la lista de apps las sugerencias de clientes disponibles.

Ancho de la ventana de visualización

Viewport-Width es el ancho del viewport del usuario en píxeles CSS:

Viewport-Width: 320

Esta sugerencia se puede usar con otras sugerencias específicas de la pantalla para ofrecer diferentes tratamientos (es decir, recortes) de una imagen que son óptimos para tamaños de pantalla específicos (es decir, arte indicaciones), o que omitan recursos que son innecesarios para el ancho de pantalla actual.

DPR

DPR, que es la forma abreviada de relación de píxeles del dispositivo, informa la relación entre los píxeles físicos y CSS. píxeles de la pantalla del usuario:

DPR: 2

Esta sugerencia es útil cuando seleccionas fuentes de imágenes que corresponden al nivel de densidad de píxeles (como lo hacen los descriptores x en srcset) ).

Ancho

La sugerencia Width aparece en las solicitudes de recursos de imagen que activa <img> o Etiquetas <source> que usan el sizes . sizes le indica al navegador cuál será el tamaño extrínseco del recurso. Width usa ese tamaño extrínseco para solicitar una imagen con un tamaño intrínseco que es óptima para el diseño actual.

Por ejemplo, supongamos que un usuario solicita una página con una pantalla ancha de 320 píxeles CSS. con una DPR de 2. El dispositivo carga un documento con un elemento <img> que contiene Un valor del atributo sizes de 85vw (es decir, El 85% del ancho de la viewport para todos tamaños de pantalla). Si se habilitó la sugerencia Width, el cliente enviará esta sugerencia de Width al servidor con la solicitud del src de <img>:

Width: 544

En este caso, el cliente insinúa al servidor que un mecanismo intrínseco óptimo el ancho de la imagen solicitada sería el 85% del ancho del viewport (272 píxeles) multiplicado por la DPR de la pantalla (2), que es igual a 544 píxeles.

Esta pista es muy poderosa, ya que no solo tiene en cuenta con corrección de densidad del ancho de la pantalla, pero también reconcilia esta pieza crítica de información con el tamaño extrínseco de la imagen dentro del diseño. Esto le brinda permite a los servidores negociar respuestas de imagen óptimas tanto para la pantalla y el diseño.

DPR del contenido

Si bien ya sabes que las pantallas tienen una proporción de píxeles del dispositivo, los recursos también tienen sus propias proporciones de píxeles. En los casos de uso más sencillos de selección de recursos, entre dispositivos y recursos puede ser la misma. ¡Pero! En los casos en que tanto los encabezados DPR y Width están en juego, el tamaño extrínseco de un recurso puede podría producir escenarios en los que ambos difieren. Aquí es donde la sugerencia Content-DPR entra en juego.

A diferencia de otras sugerencias de clientes, Content-DPR no es un encabezado de solicitud para que lo use. sino que los servidores de encabezado de respuesta deben enviar cuando DPR y Se usan las sugerencias Width para seleccionar un recurso. El valor de Content-DPR debe sería el resultado de esta ecuación:

Content-DPR = [Tamaño de recurso de la imagen seleccionada] / ([Width] / [DPR])

Cuando se envíe un encabezado de solicitud Content-DPR, el navegador sabrá cómo escalar la imagen dada para la proporción de píxeles del dispositivo de la pantalla y el diseño. Sin ella, es posible que las imágenes no escalen adecuadamente.

Memoria del dispositivo

Técnicamente, una parte de la Memoria del dispositivo API, Device-Memory revela la cantidad aproximada de memoria que tiene el dispositivo actual en GiB:

Device-Memory: 2

Un posible caso de uso para esta sugerencia sería reducir la cantidad de código JavaScript enviados a navegadores en dispositivos con memoria limitada, ya que JavaScript es el los tipos de contenido que consumen muchos recursos, de usuario. O puedes enviar imágenes de DPR más bajas, ya que usan menos memoria para decodificarse.

Sugerencias de red

La API de Network Information proporciona otro categoría de sugerencias de clientes que describen el rendimiento de la red del usuario conexión. En mi opinión, estos son los consejos más útiles. Con ellos, Personalizar las experiencias de los usuarios cambiando la forma en que brindamos recursos a clientes con conexiones lentas.

RTT

La sugerencia RTT proporciona el tiempo de ida y vuelta aproximado, en milisegundos, en la capa de aplicación. La sugerencia RTT, a diferencia de la RTT de la capa de transporte, incluye tiempo de procesamiento del servidor.

RTT: 125

Esta sugerencia es útil debido al rol que desempeña la latencia en el rendimiento de carga. Con la sugerencia RTT, podemos tomar decisiones en función de la capacidad de respuesta de la red, lo que puede ayudar a acelerar la entrega de una experiencia completa (p.ej., a través de omitir algunas solicitudes).

Aunque la latencia es importante en el rendimiento de carga, el ancho de banda también. La sugerencia Downlink, expresada en megabits por segundo (Mbps), revela la velocidad descendente aproximada de la conexión del usuario:

Downlink: 2.5

Junto con RTT, Downlink puede ser útil para cambiar la forma en que el contenido se para brindar a los usuarios según la calidad de una conexión de red.

ECT

La sugerencia ECT significa Tipo de conexión efectiva. Su valor es uno de un lista enumerada de tipos de conexión, cada uno de los cuales describe una conexión dentro de los rangos especificados de RTT y Downlink de salida.

Este encabezado no explica cuál es el tipo de conexión real para por ejemplo, no informa si la puerta de enlace es una torre de telefonía celular o un acceso a Wi-Fi punto. En cambio, analiza la latencia y el ancho de banda de la conexión actual, y determina a qué perfil de red se parece más. Por ejemplo, si conectas a través de Wi-Fi a una red lenta, ECT puede completarse con un valor de 2g, que es la aproximación más cercana de la conexión real:

ECT: 2g

Los valores válidos para ECT son 4g, 3g, 2g y slow-2g. Esta pista puede ser como punto de partida para evaluar la calidad de la conexión y, luego, refinado con las sugerencias RTT y Downlink.

Ahorro de datos

Save-Data no es tan solo una sugerencia que describe las condiciones de la red, sino que es un usuario. preferencia que indique que las páginas deberían enviar menos datos.

Prefiero clasificar Save-Data como una sugerencia de red porque muchas de las cosas que harías con él son similares a otras sugerencias de red. Los usuarios también pueden en entornos de latencia alta o ancho de banda bajo. Esta pista, cuando presente, siempre se ve así:

Save-Data: on

En Google, hemos hablado sobre lo que puedes hacer con Save-Data El impacto que puede tener en el rendimiento puede ser profundo. Es un indicador en el que los usuarios que, literalmente, te piden que le envíes menos cosas. Si escuchas y actúas en consecuencia indicador, los usuarios lo apreciarán.

Cómo juntar las piezas

Lo que debes hacer con las sugerencias de cliente depende de ti. Porque ofrecen mucho información, tienes muchas opciones. Para que las ideas fluyan, veamos cuáles que las sugerencias de clientes pueden hacer para Sconnie Timber, una madera ficticia en el Alto Medio Oeste rural. Como suele ser el caso áreas de trabajo, las conexiones de red pueden ser frágiles. Aquí es donde una tecnología como sugerencias de clientes realmente puede marcar una diferencia para los usuarios.

Imágenes responsivas

Todos los casos de uso de imágenes responsivas más simples pueden volverse complicados. ¿Qué sucede si Tienen múltiples tratamientos y variantes de las mismas imágenes para diferentes pantallas. tamaños y diferentes formatos? El lenguaje de marcado se vuelve muy complicado muy con rapidez. Es fácil equivocarse y olvidarse o malinterpretar lo importante. conceptos (como sizes).

Si bien <picture> y srcset son herramientas increíbles, pueden ser y mantener para casos de uso complejos. Podemos automatizar generar lenguaje de marcado, pero hacerlo también es difícil, ya que la funcionalidad El suministro de <picture> y srcset es lo suficientemente complejo como para que sus necesidades de automatización de una forma que mantenga la flexibilidad que brindan.

Las sugerencias de clientes pueden simplificar esto. Negociación de respuestas de imagen con el cliente las pistas podrían ser parecidas a lo siguiente:

  1. Si corresponde a tu flujo de trabajo, primero selecciona un tratamiento de imágenes (es decir, imágenes dirigidas por obras de arte) verificando la sugerencia Viewport-Width.
  2. Para seleccionar una resolución de imagen, revisa las sugerencias de Width y DPR. elegir una fuente que se ajuste al tamaño de diseño de la imagen y a la densidad de la pantalla (similar a cómo funcionan los descriptores x y w en srcset).
  3. Selecciona el formato de archivo óptimo que admita el navegador (algo Accept nos ayuda a hacerlo en la mayoría de los navegadores).

Con respecto a mi cliente ficticio de la empresa madera, desarrollé un estilo Rutina de selección de imágenes responsivas en PHP que usa sugerencias de cliente Esto significaba en lugar de enviar este lenguaje de marcado a todos los usuarios:

<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>

Pude reducirlo a lo siguiente en función de la compatibilidad de cada navegador:

<img
  src="/image/sizes:true/company-photo.jpg"
  sizes="(min-width: 560px) 251px, 88.43vw"
  alt="SAY CHEESY PICKLES."
/>

En este ejemplo, la URL /image es una secuencia de comandos PHP seguida de parámetros reescrito por mod_rewrite: Integra toma un nombre de archivo de imagen y parámetros adicionales para ayudar a una secuencia de comandos de backend elegir la mejor imagen según las condiciones determinadas.

Presiento "¿Pero no se trata solo de implementar <picture> y srcset en la back-end?” es tu primera pregunta.

En cierto modo, sí, pero con una distinción importante: cuando una aplicación usa sugerencias de clientes para elaborar respuestas de los medios, la mayoría (si no todo) del trabajo es mucho más fáciles de automatizar, lo que puede incluir un servicio (como una CDN) que puede hacerlo por ti. Mientras que con las soluciones HTML, el lenguaje de marcado nuevo debe escribirse en para cada caso de uso. Por supuesto, puedes automatizar la generación de lenguaje de marcado. Si el sin embargo, el diseño o los requisitos cambian, es muy probable que debas y volver a revisar tu estrategia de automatización en el futuro.

Las sugerencias de clientes permiten comenzar con una resolución Imagen a la que se le puede cambiar el tamaño de forma dinámica para que sea óptima para cualquier combinación de la pantalla y el diseño. A diferencia de srcset, que requiere que enumeres un de imágenes candidatas para que el navegador elija, este enfoque puede ser más flexible. Mientras que srcset te obliga a ofrecer a los navegadores un conjunto general de variantes (por ejemplo, 256w, 512w, 768w y 1024w), una sugerencia del cliente solución con tecnología potente que puede servir en todos los anchos, sin una pila gigante de marcado.

Por supuesto, no tienes que escribir la lógica de selección de imágenes por tu cuenta. Cloudinary usa sugerencias de clientes para crear respuestas de imagen cuando usas w_auto parámetro, y observaron que la mediana de usuarios descargaban un 42% menos de bytes al usar navegadores que admiten sugerencias de clientes.

Pero ten cuidado. Los cambios en la versión para computadoras de Chrome 67 quitaron la compatibilidad para el cliente de origen cruzado sugerencias. Afortunadamente, estas restricciones no afectan las versiones de Chrome para dispositivos móviles y se levantarán por completo para todas las plataformas cuando trabajes en Función La política está completa.

Ayuda a los usuarios con redes lentas

El rendimiento adaptable es la idea de que podemos ajustar la forma en que entregamos los recursos. según la información que nos proporciona las sugerencias de clientes; específicamente información relacionada con el estado actual de la conexión de red del usuario.

En lo que respecta al sitio de Sconnie Timber, tomamos medidas para reducir la carga cuando las redes son lentas y los encabezados Save-Data, ECT, RTT y Downlink son se examina en nuestro código de back-end. Cuando se hace esto, generamos una red de más alto que podemos usar para determinar si debemos intervenir para que un usuario mejore una experiencia fluida a los desarrolladores. Esta puntuación de red se encuentra entre 0 y 1, donde 0 es la peor de red de la posible calidad de red, y 1 es la mejor.

Inicialmente, verificamos si Save-Data está presente. Si es así, la puntuación se establece en 0, ya que suponemos que el usuario quiere que hagamos lo necesario para que experiencia cada vez más ligera y rápida.

Sin embargo, si Save-Data no está presente, se siguen y ponderamos los valores de ECT, RTT y Downlink sugerencias para calcular una puntuación que describa la red la calidad de la conexión. La fuente de generación de puntuaciones de red código está disponible en GitHub. La conclusión es que, si usamos las sugerencias relacionadas con la red en algo de moda, podemos mejorar las experiencias para los usuarios lentos redes.

Comparación de un sitio que no utiliza el cliente
sugerencias para adaptarse a una conexión de red lenta (izquierda) y al mismo sitio que
(derecha).
Figura 2. Una página "Acerca de nosotros" para una agencia local sitio de tu empresa. La experiencia de referencia incluye fuentes web, JavaScript para impulsar como el comportamiento de carrusel y acordeón, y las imágenes de contenido. Todas estas son cuestiones podemos omitir cuando las condiciones de la red son demasiado lentas para cargarlos. rápidamente.

Cuando los sitios se adaptan a la información que proporcionan las sugerencias de clientes, no tenemos que adoptar un enfoque de “todo o nada”. Podemos decidir de forma inteligente qué recursos enviar. Podemos modificar nuestra lógica de selección de imágenes responsivas para enviar una calidad imágenes de una pantalla determinada para acelerar el rendimiento de carga cuando la calidad de la red es deficiente.

En este ejemplo, podemos ver el impacto que tienen las sugerencias de clientes a la hora de lo que mejora el rendimiento de los sitios en redes más lentas. A continuación se incluye una prueba de página web cascada de un sitio en una red lenta que no se adapta a las sugerencias de clientes:

Cascada WebPagetest del Sconnie
Sitio de madera que carga todos los recursos con una conexión de red lenta.
Figura 3. Un sitio con muchos recursos que carga imágenes secuencias de comandos y fuentes en una conexión lenta.

Ahora una cascada para el mismo sitio en la misma conexión lenta, excepto que con el tiempo, el sitio usa sugerencias de clientes para eliminar los recursos de la página que no son críticos:

Cascada WebPagetest del Sconnie
Sitio de madera que usa sugerencias de cliente para decidir no cargar recursos no esenciales en un
una conexión de red lenta.
Figura 4. El mismo sitio en la misma conexión, solo se excluyen los recursos “que es bueno tener” para brindar acceso cargando.

Las sugerencias de clientes redujeron el tiempo de carga de la página de más de 45 segundos a menos de un la décima parte de ese tiempo. En este caso, los beneficios de las sugerencias de clientes no se pueden enfatizado lo suficiente y puede ser una gran ayuda para los usuarios que buscan críticas información en redes lentas.

Además, es posible usar sugerencias de clientes sin afectar la experiencia. para los navegadores que no las admiten. Por ejemplo, si queremos ajustar los recursos de entrega mediante la solicitud del valor de la sugerencia de ECT y, al mismo tiempo, la entrega completa para los navegadores no compatibles, podemos volver a un valor predeterminado así:

// Set the ECT value to "4g" by default.
$ect = isset($_SERVER["HTTP_ECT"]) ? $_SERVER["HTTP_ECT"] : "4g";

Aquí, "4g" representa la conexión de red de más alta calidad en el encabezado ECT. describe. Si inicializamos $ect en "4g", navegadores que no admiten el cliente. las pistas no se verán afectadas. Participa en el programa

¡Olvídate de las memorias caché!

Cuando cambies una respuesta basada en un encabezado HTTP, debes tener en cuenta cómo las cachés controlarán futuras recuperaciones para ese recurso. Vary encabezado es indispensable aquí, ya que claves las entradas de caché en el valor de los encabezados de la solicitud suministrados. En pocas palabras, si modificas cualquier respuesta basada en una solicitud HTTP encabezado de solicitud, casi siempre debes incluir la solicitud de ese encabezado en Vary así:

Vary: DPR, Width

Sin embargo, hay una advertencia gran sobre esto: nunca querrás que Vary se pueda almacenar en caché respuestas en un encabezado que cambia con frecuencia (como Cookie) porque aquellas los recursos dejan de estar disponibles y no se pueden almacenar en caché. Con esta información, deberías evitar Vary en encabezados de sugerencia de cliente, como RTT o Downlink, porque son factores de conexión que podrían cambiar con bastante frecuencia. Si quieres modificar respuestas en esos encabezados, considera agregar solo el encabezado ECT, que y minimizar los errores de caché.

Por supuesto, esto solo se aplica si estás almacenando una respuesta en caché. Por ejemplo, no almacenarás recursos HTML en caché si su contenido es dinámico que pueden perjudicar la experiencia del usuario en visitas repetidas. En casos como estos, puedes la libertad de modificar esas respuestas según lo que consideres necesario y no Preocúpate por Vary.

Sugerencias de clientes en service workers

La negociación de contenido ya no es solo para servidores. Debido a que los service workers actúan como proxies entre los clientes y los servidores, puedes controlar el modo en que los recursos se entregan a través de JavaScript. Esto incluye las sugerencias de clientes. En el service worker fetch, puedes usar el event request.headers.get para leer los encabezados de solicitud de un recurso de la siguiente manera:

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!
    })(),
  );
});

Cualquier encabezado de sugerencia de cliente que habilites se puede leer de esta manera. Aunque eso es no es la única forma de obtener parte de esta información. Sugerencias específicas de la red se puede leer en estas propiedades de JavaScript equivalentes en el objeto navigator:

Sugerencia del cliente Equivalente en JS
"ECT" `navigator.connection.effectiveType`
"RTT" `navigator.connection.rtt`
"Save-Data" `navigator.connection.saveData`
"Vínculo descendente" `navigator.connection.downlink`
"Device-Memory" `navigator.deviceMemory`
Complementos de Imagemin para los tipos de archivo.

Debido a que estas APIs no están disponibles en todos los lugares donde necesites comprobar las funciones, consulta el in Operador:

if ('connection' in navigator) {
  // Work with netinfo API properties in JavaScript!
}

Desde aquí, puedes usar una lógica similar a la que usarías en el servidor, excepto no necesitas un servidor para negociar contenido con sugerencias de clientes. Servicio los trabajadores solos tienen el poder de hacer que las experiencias sean más rápidas y resilientes debido a la capacidad adicional de entregar contenido cuando el usuario está sin conexión.

Conclusión

Con las sugerencias de clientes, podemos hacer que las experiencias de los usuarios sean más rápidas de forma totalmente progresiva. Podemos entregar contenido multimedia según el dispositivo del usuario. de rendimiento de modo que la entrega de imágenes responsivas sea más fácil que confiar en <picture> y srcset, en especial para casos de uso complejos. Esto nos permite no solo para reducir el tiempo y el esfuerzo en el desarrollo, sino también para optimizar recursos, en particular las imágenes, de una manera que se oriente a las pantallas de los usuarios de manera más precisa que y srcset.

Quizás lo más importante es detectar las conexiones de red deficientes para los usuarios modificando lo que enviamos y la forma en que lo hacemos. Esto puede ayudan a facilitar el acceso a los sitios a los usuarios de redes frágiles. Junto con los service workers, podemos crear sitios con una rapidez increíble disponibles sin conexión.

Si bien las sugerencias de clientes solo están disponibles en Chrome, y las basadas los navegadores, es posible usarlos de una manera que no obstruya navegadores que no son compatibles. Considera usar sugerencias de clientes para crear experiencias inclusivas y adaptables que reconozcan el dispositivo de cada usuario capacidades y las redes a las que se conectan. Esperamos que otros proveedores de navegadores verán su valor y mostrarán la intención de implementarlas.

Recursos

Gracias a Ilya Grigorik, Eric Portis, Jeff Posnick y Yoav Weiss y Estelle Weyl por su comentarios y ediciones valiosos de este artículo.