Desarrollar sitios que sean rápidos en todas partes puede ser una tarea difícil. La gran cantidad de capacidades de los dispositivos y la calidad de las redes a las que se conectan pueden hacer que parezca una tarea imposible. Si bien podemos aprovechar las funciones del navegador para mejorar el rendimiento de la carga, ¿cómo sabemos de qué es capaz el dispositivo del usuario o la calidad de su conexión de red? La solución son las Client Hints.
Los Client Hints son un conjunto de encabezados de la solicitud HTTP de aceptación que nos brindan información sobre estos aspectos del dispositivo del usuario y la red a la que está conectado. Si aprovechamos esta información del servidor, podemos cambiar cómo entregamos el contenido según las condiciones del dispositivo o de la red. Esto puede ayudarnos a crear experiencias del usuario más inclusivas.
Todo se trata de la negociación de contenido
Client Hints son otro método de negociación de contenido, lo que significa cambiar las respuestas de contenido según los encabezados de la solicitud del navegador.
Un ejemplo de negociación de contenido involucra el encabezado de la solicitud Accept. Describe qué tipos de contenido comprende el navegador, que el servidor puede usar para negociar la respuesta. Para las solicitudes de imágenes, el contenido
del encabezado Accept de Chrome es el siguiente:
Accept: image/webp,image/apng,image/*,*/*;q=0.8
Si bien todos los navegadores admiten formatos de imagen como JPEG, PNG y GIF, Accept indica en este caso que el navegador también admite 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, Client Hints son otra vía para negociar contenido, pero en el contexto de las capacidades del dispositivo y las condiciones de la red. Con las sugerencias del cliente, podemos tomar decisiones de rendimiento del servidor en función de la experiencia individual de un usuario, como decidir si se deben entregar recursos no críticos a los usuarios con malas condiciones de red. En esta guía, describiremos todas las sugerencias disponibles y algunas formas en que puedes usarlas para que la publicación de contenido sea más conveniente para los usuarios.
Cómo habilitarlo
A diferencia del encabezado Accept, las sugerencias de clientes no aparecen por arte de magia (con la excepción de Save-Data, que analizaremos más adelante). Para mantener los encabezados de la solicitud al mínimo, deberás habilitar los Client Hints que quieras recibir 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 que el sitio
usará para determinar los resultados de la solicitud de recursos posterior. Cuando el cliente lee este encabezado, se le indica que “este sitio quiere los Client Hints Viewport-Width y Downlink”. No te preocupes por los Client Hints específicos.
Los analizaremos en un momento.
Puedes configurar estos encabezados de habilitación en cualquier lenguaje de backend. Por ejemplo, se podría usar la función header de PHP.
Incluso puedes establecer estos encabezados de habilitación con el atributo http-equiv en una etiqueta <meta>:
<meta http-equiv="Accept-CH" content="Viewport-Width, Downlink" />
Todas las sugerencias del cliente
Las sugerencias del cliente describen una de dos cosas: el dispositivo que tus usuarios, bueno, usan, y la red que usan para acceder a tu sitio. Analicemos brevemente todas las sugerencias disponibles.
Sugerencias de dispositivos
Algunas sugerencias de clientes describen las características del dispositivo del usuario, por lo general, las características de la pantalla. Algunos de ellos pueden ayudarte a elegir el recurso multimedia óptimo para la pantalla de un usuario determinado, pero no todos son necesariamente centrados en el contenido multimedia.
Antes de entrar en esta lista, puede ser útil aprender algunos términos clave que se usan para describir las pantallas y la resolución de los medios:
Tamaño intrínseco: Son las dimensiones reales de un recurso multimedia. Por ejemplo, si abres una imagen en Photoshop, las dimensiones que se muestran en el diálogo de tamaño de la imagen describen su tamaño intrínseco.
Tamaño intrínseco corregido por densidad: Son las dimensiones de un recurso multimedia después de que se corrigió para la densidad de píxeles. Es el tamaño intrínseco de la imagen dividido por una proporción de píxeles del dispositivo. 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 el tamaño intrínseco de la imagen 1x en este caso es de 320 x 240, y el tamaño intrínseco de la imagen 2x es de 640 x 480. Si un cliente instalado en un dispositivo con una proporción de píxeles de pantalla de 2 (p.ej., una pantalla Retina) analiza este lenguaje de marcado, se solicita la imagen 2x. El tamaño intrínseco corregido por densidad de la imagen 2x es de 320 × 240, ya que 640 × 480 dividido por 2 es 320 × 240.
Tamaño extrínseco: Es el tamaño de un recurso multimedia después de que se le aplicaron CSS y otros factores de diseño (como los atributos width y height). Supongamos
que tienes un elemento <img> que carga una imagen con un tamaño intrínseco
corregido por densidad de 320 x 240, pero que también tiene propiedades width y height de CSS
con valores de 256px y 192px aplicados, respectivamente. En este ejemplo,
el tamaño extrínseco de ese elemento <img> se convierte en 256 × 192.
width: 256px; y height: 192px; transforma una imagen de tamaño intrínseco de 320 × 240 en una de tamaño extrínseco de 256 × 192.Ahora que ya conoces algunos términos, veamos la lista de Client Hints específicas del dispositivo que tienes disponibles.
Viewport-Width
Viewport-Width es el ancho del viewport del usuario en píxeles de CSS:
Viewport-Width: 320
Este indicador se puede usar con otros indicadores específicos de la pantalla para ofrecer diferentes tratamientos (es decir, recortes) de una imagen que sean óptimos para tamaños de pantalla específicos (es decir, dirección de arte) o para omitir recursos que no son necesarios para el ancho de pantalla actual.
DPR
DPR, abreviatura de proporción de píxeles del dispositivo, informa la proporción de píxeles físicos con respecto a los píxeles de CSS de la pantalla del usuario:
DPR: 2
Esta sugerencia es útil cuando se seleccionan fuentes de imágenes que corresponden a la densidad de píxeles de una pantalla (como lo hacen los descriptores x en el atributo srcset).
Ancho
La sugerencia Width aparece en las solicitudes de recursos de imagen que activan las etiquetas <img> o
<source> con el atributo
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
sea óptimo para el diseño actual.
Por ejemplo, supongamos que un usuario solicita una página con una pantalla de 320 píxeles CSS de ancho con un DPR de 2. El dispositivo carga un documento con un elemento <img> que contiene un valor de atributo sizes de 85vw (es decir, 85% del ancho del viewport para todos los tamaños de pantalla). Si se habilitó la sugerencia Width, el cliente enviará
esta sugerencia Width al servidor con la solicitud de src de <img>:
Width: 544
En este caso, el cliente le indica al servidor que un ancho intrínseco óptimo para la imagen solicitada sería el 85% del ancho del viewport (272 píxeles) multiplicado por el DPR de la pantalla (2), lo que equivale a 544 píxeles.
Esta sugerencia es especialmente potente porque no solo tiene en cuenta el ancho de la pantalla con corrección de densidad, sino que también concilia esta información fundamental con el tamaño extrínseco de la imagen dentro del diseño. Esto les da a los servidores la oportunidad de negociar respuestas de imágenes que sean óptimas tanto para la pantalla como para el diseño.
Content-DPR
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 simples de selección de recursos, las proporciones de píxeles entre los dispositivos y los recursos pueden ser las mismas. ¡Pero se me ocurrió una idea! En los casos en que se usan los encabezados DPR y Width, el tamaño extrínseco de un recurso puede producir situaciones en las que ambos difieren. Aquí es donde entra en juego la sugerencia Content-DPR.
A diferencia de otros indicadores del cliente, Content-DPR no es un encabezado de solicitud que deben usar los servidores, sino un encabezado de respuesta que los servidores deben enviar cada vez que se usan los indicadores DPR y Width para seleccionar un recurso. El valor de Content-DPR debe
ser el resultado de esta ecuación:
Content-DPR = [Tamaño del recurso de imagen seleccionado] / ([Width] / [DPR])
Cuando se envía un encabezado de la solicitud Content-DPR, el navegador sabrá cómo escalar la imagen determinada 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 se ajusten correctamente.
Device-Memory
Técnicamente, como parte de la API de Device Memory, 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 JavaScript que se envía a los navegadores en dispositivos con memoria limitada, ya que JavaScript es el tipo de contenido que consume más recursos que suelen cargar los navegadores. También puedes enviar imágenes con una DPR más baja, ya que usan menos memoria para decodificarse.
Sugerencias de red
La API de Network Information proporciona otra categoría de Client Hints que describen el rendimiento de la conexión de red del usuario. En mi opinión, este es el conjunto de sugerencias más útil. Con ellas, podemos adaptar las experiencias a los usuarios cambiando la forma en que entregamos recursos a los clientes con conexiones lentas.
RTT
La sugerencia RTT proporciona el tiempo de ida y vuelta aproximado, en milisegundos, en
la capa de aplicación. A diferencia del RTT de la capa de transporte, la sugerencia RTT incluye el tiempo de procesamiento del servidor.
RTT: 125
Esta sugerencia es útil debido a la función que tiene la latencia en el rendimiento de carga.
Con la sugerencia RTT, podemos tomar decisiones basadas en la capacidad de respuesta de la red, lo que puede ayudar a acelerar la entrega de una experiencia completa (p.ej., omitiendo algunas solicitudes).
Downlink
Si bien la latencia es importante en el rendimiento de la carga, el ancho de banda también influye. La sugerencia Downlink, expresada en megabits por segundo (Mbps), revela la velocidad de descarga aproximada de la conexión del usuario:
Downlink: 2.5
Junto con RTT, Downlink puede ser útil para cambiar la forma en que se entrega el contenido 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 una
lista enumerada de tipos de conexión, cada uno de los cuales describe una conexión
dentro de los rangos especificados de los valores RTT y Downlink.
Este encabezado no explica cuál es el tipo de conexión real; por ejemplo, no informa si tu puerta de enlace es una torre de telefonía celular o un punto de acceso Wi-Fi. 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 te 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 efectiva:
ECT: 2g
Los valores válidos para ECT son 4g, 3g, 2g y slow-2g. Esta sugerencia se puede usar como punto de partida para evaluar la calidad de la conexión y, luego, definirla mejor con las sugerencias RTT y Downlink.
Save-Data
Save-Data no es tanto una sugerencia que describe las condiciones de la red, sino una preferencia del usuario que indica que las páginas deben enviar menos datos.
Prefiero clasificar Save-Data como una sugerencia de red porque muchas de las cosas
que harías con ella son similares a otras sugerencias de red. También es probable que los usuarios lo habiliten en entornos de alta latencia o bajo ancho de banda. Cuando está presente, esta sugerencia siempre se ve de la siguiente manera:
Save-Data: on
En Google, hablamos sobre lo que puedes hacer con
Save-Data.
El impacto que puede tener en el rendimiento puede ser profundo. Es un indicador de que los usuarios
literalmente te están pidiendo que les envíes menos contenido. Si escuchas y actúas en función de esa
señal, los usuarios lo apreciarán.
Cómo juntar las piezas
Lo que hagas con los Client Hints depende de ti. Como ofrecen tanta información, tienes muchas opciones. Para que fluyan algunas ideas, veamos qué pueden hacer los Client Hints por Sconnie Timber, una empresa maderera ficticia ubicada en la zona rural del Medio Oeste superior. Como suele suceder en las áreas remotas, las conexiones de red pueden ser inestables. Aquí es donde una tecnología como Client Hints puede marcar una diferencia real para los usuarios.
Imágenes responsivas
Todos los casos de uso de imágenes responsivas, excepto los más sencillos, pueden complicarse. ¿Qué sucede si tienes varios tratamientos y variantes de las mismas imágenes para diferentes tamaños de pantalla y diferentes formatos? Ese lenguaje de marcado se vuelve muy complicado muy rápido.
Es fácil equivocarse y olvidar o malinterpretar conceptos importantes (como sizes).
Si bien <picture> y srcset son, sin duda, herramientas increíbles, su desarrollo y mantenimiento pueden llevar mucho tiempo en casos de uso complejos. Podemos automatizar
la generación de lenguaje de marcado, pero hacerlo también es difícil porque la funcionalidad
que proporcionan <picture> y srcset es lo suficientemente compleja como para que su automatización deba
realizarse de una manera que mantenga la flexibilidad que proporcionan.
Las sugerencias del cliente pueden simplificar este proceso. La negociación de las respuestas de imágenes con Client Hints podría verse de la siguiente manera:
- Si corresponde a tu flujo de trabajo, primero selecciona un tratamiento de imagen (es decir,
imágenes con dirección de arte) marcando la sugerencia
Viewport-Width. - Para seleccionar una resolución de imagen, verifica las sugerencias
WidthyDPR, y elige una fuente que se ajuste al tamaño del diseño de la imagen y a la densidad de la pantalla (similar a cómo funcionan los descriptoresxywensrcset). - Selecciona el formato de archivo más óptimo que admita el navegador (algo que
Acceptnos ayuda a hacer en la mayoría de los navegadores).
En lo que respecta a mi cliente ficticio de la empresa maderera, desarrollé una rutina de selección de imágenes responsivas ingenua en PHP que usa sugerencias del cliente. Esto significa que, 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 según 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 de PHP seguida de parámetros
reescritos por
mod_rewrite. Toma un nombre de archivo de imagen y parámetros adicionales para ayudar a una secuencia de comandos de backend a elegir la mejor imagen en las condiciones dadas.
Presiento que tu primera pregunta es “¿Pero esto no es solo volver a implementar <picture> y srcset en el backend?”.
En cierto modo, sí, pero con una distinción importante: cuando una aplicación usa sugerencias del cliente para crear respuestas de medios, la mayor parte del trabajo (si no todo) es mucho más fácil de automatizar, lo que puede incluir un servicio (como una CDN) que puede hacerlo en tu nombre. En cambio, con las soluciones HTML, se debe escribir un lenguaje de marcado nuevo para cada caso de uso. Sí, puedes automatizar la generación de lenguaje de marcado. Sin embargo, si cambian tus requisitos o tu diseño, es muy probable que debas revisar tu estrategia de automatización en el futuro.
Las sugerencias del cliente permiten comenzar con una imagen de alta resolución sin pérdidas que, luego, se puede cambiar de tamaño de forma dinámica para que sea óptima para cualquier combinación de pantalla y diseño. A diferencia de srcset, que requiere que enumeres una lista fija de posibles 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 aproximado de variantes (por ejemplo, 256w, 512w, 768w y 1024w), una solución con sugerencias del cliente puede entregar todos los anchos, sin una gran cantidad de lenguaje de marcado.
Por supuesto, no tienes que escribir la lógica de selección de imágenes por tu cuenta. Cloudinary usa Client Hints para crear respuestas de imágenes cuando usas el parámetro w_auto y observó que los usuarios promedio descargaron un 42% menos de bytes cuando usaban navegadores que admiten Client Hints.
Pero ¡ten cuidado! Los cambios en la versión para computadoras de Chrome 67 quitaron la compatibilidad con las sugerencias de clientes de origen cruzado. Afortunadamente, estas restricciones no afectan las versiones para dispositivos móviles de Chrome y se quitarán por completo para todas las plataformas cuando se complete el trabajo en la política de funciones.
Cómo ayudar 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 proporcionan los Client Hints, específicamente, la información sobre el estado actual de la conexión de red del usuario.
En lo que respecta al sitio de Sconnie Timber, tomamos medidas para aligerar la carga cuando
las redes son lentas, con los encabezados Save-Data, ECT, RTT y Downlink que se
examinan en nuestro código de backend. Cuando se completa este proceso, generamos una puntuación de calidad de la red que podemos usar para determinar si debemos intervenir para mejorar la experiencia del usuario. Esta puntuación de red se encuentra entre 0 y 1, donde 0 es la peor
calidad de red posible 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 que sea necesario para que la experiencia sea más ligera y rápida.
Sin embargo, si no hay Save-Data, seguimos adelante y ponderamos los valores de las sugerencias ECT, RTT y Downlink para calcular una puntuación que describa la calidad de la conexión de red. El código fuente de generación de puntuación de red está disponible en GitHub. La conclusión es que, si usamos las sugerencias relacionadas con la red de
alguna manera, podemos mejorar las experiencias de quienes tienen redes
lentas.
Cuando los sitios se adaptan a la información que proporcionan los Client Hints, 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 imágenes de menor calidad para una pantalla determinada y, así, acelerar el rendimiento de carga cuando la calidad de la red es deficiente.
En este ejemplo, podemos ver el impacto que tienen los Client Hints cuando se trata de mejorar el rendimiento de los sitios en redes más lentas. A continuación, se muestra un gráfico de cascada de WebPagetest de un sitio en una red lenta que no se adapta a Client Hints:
Y ahora, un gráfico de cascada para el mismo sitio en la misma conexión lenta, excepto que, esta vez, el sitio usa sugerencias del cliente para eliminar los recursos de página no críticos:
Client Hints redujeron el tiempo de carga de la página de más de 45 segundos a menos de una décima parte de ese tiempo. Los beneficios de Client Hints en esta situación no se pueden enfatizar lo suficiente y pueden ser una gran ventaja para los usuarios que buscan información crítica en redes lentas.
Además, es posible usar las sugerencias del cliente sin interrumpir la experiencia de los navegadores que no las admiten. Por ejemplo, si queremos ajustar la entrega de recursos con el valor de la sugerencia ECT y, al mismo tiempo, ofrecer la experiencia completa para los navegadores que no la admiten, podemos establecer un valor predeterminado de la siguiente manera:
// 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 mayor calidad que describe el encabezado ECT. Si inicializamos $ect en "4g", los navegadores que no admiten sugerencias de clientes no se verán afectados. ¡Habilita la función para ganar!
¡Cuidado con las cachés!
Cada vez que cambies una respuesta en función de un encabezado HTTP, debes tener en cuenta
cómo las cachés controlarán las recuperaciones futuras de ese recurso. El encabezado Vary es indispensable aquí, ya que asigna claves a las entradas de caché para el valor de los encabezados de la solicitud que se le proporcionan. En pocas palabras, si modificas cualquier respuesta en función de un encabezado de la solicitud HTTP determinado, casi siempre debes incluir ese encabezado en Vary de la siguiente manera:
Vary: DPR, Width
Sin embargo, hay una gran advertencia: Nunca debes usar Vary en respuestas que se pueden almacenar en caché en un encabezado que cambia con frecuencia (como Cookie), ya que esos recursos se vuelven imposibles de almacenar en caché. Sabiendo esto, es posible que quieras evitar
Vary en encabezados de Client Hints, como RTT o Downlink, ya que son
factores de conexión que podrían cambiar con bastante frecuencia. Si deseas modificar
las respuestas en esos encabezados, considera usar solo el encabezado ECT, lo que
minimizará los errores de caché.
Por supuesto, esto solo se aplica si, en primer lugar, almacenas en caché una respuesta.
Por ejemplo, no almacenarás en caché los recursos HTML si su contenido es dinámico, ya que eso puede afectar la experiencia del usuario en las visitas repetidas. En casos como estos, puedes
modificar esas respuestas según lo consideres necesario y no
preocuparte por Vary.
Client Hints en service workers
La negociación de contenido ya no es solo para los servidores. Debido a que los service workers actúan
como proxies entre los clientes y los servidores, tienes control sobre cómo se entregan los recursos
a través de JavaScript. Esto incluye Client Hints. En el evento fetch del service worker, puedes usar el método request.headers.get del objeto event para leer los encabezados de la 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 Client Hints que habilites se puede leer de esta manera. Sin embargo, esa no es la única forma de obtener parte de esta información. Los indicadores específicos de la red se pueden leer en estas propiedades de JavaScript equivalentes en el objeto navigator:
| Client Hints | Equivalente de JS |
|---|---|
| `ECT` | `navigator.connection.effectiveType` |
| `RTT` | `navigator.connection.rtt` |
| `Save-Data` | `navigator.connection.saveData` |
| `Downlink` | `navigator.connection.downlink` |
| `Device-Memory` | `navigator.deviceMemory` |
Debido a que estas APIs no están disponibles en todas partes, debes verificar las funciones con el operador in:
if ('connection' in navigator) {
// Work with netinfo API properties in JavaScript!
}
A partir de aquí, puedes usar una lógica similar a la que usarías en el servidor, excepto que no necesitas un servidor para negociar contenido con Client Hints. Los service workers por sí solos tienen el poder de hacer que las experiencias sean más rápidas y resilientes debido a la capacidad adicional que tienen para publicar contenido cuando el usuario no tiene conexión.
Conclusión
Con Client Hints, tenemos el poder de hacer que las experiencias sean más rápidas para los usuarios de una manera completamente progresiva. Podemos publicar contenido multimedia según las capacidades del dispositivo del usuario de una manera que facilite la publicación de imágenes responsivas en lugar de depender de <picture> y srcset, en especial para casos de uso complejos. Esto nos permite no solo reducir el tiempo y el esfuerzo en el desarrollo, sino también optimizar los recursos, en particular las imágenes, de una manera que se oriente a las pantallas de los usuarios con mayor precisión que
Quizás lo más importante es que podemos detectar conexiones de red deficientes y cerrar la brecha para los usuarios modificando lo que enviamos y cómo lo enviamos. Esto puede ayudar mucho a que los sitios sean más fáciles de acceder para los usuarios que se encuentran en redes inestables. En combinación con los service workers, podemos crear sitios increíblemente rápidos que estén disponibles sin conexión.
Si bien los Client Hints solo están disponibles en Chrome y en los navegadores basados en Chromium, es posible usarlos de manera que no obstaculicen los navegadores que no los admiten. Considera usar Client Hints para crear experiencias verdaderamente inclusivas y adaptables que tengan en cuenta las capacidades del dispositivo de cada usuario y las redes a las que se conectan. Esperamos que otros proveedores de navegadores vean su valor y muestren intención de implementarlas.
Recursos
- Automatic Responsive Images with Client Hints
- Client Hints and Responsive Images—What Changed in Chrome 67
- Take a (Client) Hint! (Presentaciones)
- Cómo entregar aplicaciones rápidas y ligeras con
Save-Data
Agradecemos a Ilya Grigorik, Eric Portis, Jeff Posnick, Yoav Weiss y Estelle Weyl por sus valiosos comentarios y ediciones en este artículo.