Desarrollar sitios que sean rápidos en todas partes puede ser un cliente potencial complicado. 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 insuperable. Si bien podemos aprovechar las funciones del navegador para mejorar el rendimiento de carga, ¿cómo sabemos lo que es capaz de hacer el dispositivo del usuario o la calidad de su conexión de red? La solución son las sugerencias para clientes.
Las sugerencias de clientes son un conjunto de encabezados de solicitud HTTP de aceptación que nos brindan estadísticas sobre estos aspectos del dispositivo del usuario y la red a la que está conectado. Si aprovechamos esta información en el servidor, podemos cambiar cómo entregamos contenido según las condiciones del dispositivo o la red. Esto puede ayudarnos a crear experiencias del usuario más inclusivas.
La negociación del contenido es clave
Las sugerencias de clientes son otro método de negociación de contenido, lo que significa cambiar las respuestas de contenido según los encabezados de solicitud del navegador.
Un ejemplo de negociación de contenido implica el encabezado de la solicitud Accept. Se describe qué tipos de contenido entiende el navegador, que el servidor puede usar para negociar la respuesta. Para las solicitudes de imagen, 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 imagen 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 otro medio para negociar contenido, pero en el contexto de las capacidades del dispositivo y las condiciones de la red. Con las sugerencias de clientes, podemos tomar decisiones de rendimiento del servidor según la experiencia individual de un usuario, como decidir si se deben entregar los recursos que no son críticos a los usuarios con condiciones de red deficientes. En esta guía, describiremos todas las sugerencias disponibles y algunas formas de usarlas para que la publicación de contenido se adapte mejor a los usuarios.
Cómo habilitarlo
A diferencia del encabezado Accept, las sugerencias de clientes no solo aparecen mágicamente (a excepción de Save-Data, que analizaremos más adelante). Para mantener
los encabezados de las solicitudes al mínimo, deberás elegir qué sugerencias de clientes quieres
recibir. Para ello, envía 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 lea este encabezado, se le indicará que este sitio quiere las sugerencias del cliente Viewport-Width y Downlink. No te preocupes por las sugerencias específicas.
Las abordaremos en un momento.
Puedes configurar estos encabezados de habilitación en cualquier idioma del backend. Por ejemplo, se podría usar la función header de PHP.
Incluso puedes configurar 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 de clientes
Las sugerencias de clientes describen uno de estos dos aspectos: el dispositivo que tus usuarios usan y la red que utilizan para acceder a tu sitio. Veamos brevemente todas las sugerencias disponibles.
Sugerencias sobre dispositivos
Algunas sugerencias de clientes describen características del dispositivo del usuario, por lo general, características de la pantalla. Algunas de ellas pueden ayudarte a elegir el recurso multimedia óptimo para la pantalla de un usuario determinado, pero no todas se centran necesariamente en el contenido multimedia.
Antes de entrar en esta lista, puede ser útil conocer algunos términos clave que se usan para describir las pantallas y la resolución del contenido multimedia:
Tamaño intrínseco: Las dimensiones reales de un recurso multimedia. Por ejemplo, si abres una imagen en Photoshop, las dimensiones que se muestran en el diálogo del tamaño de la imagen describen su tamaño intrínseco.
Tamaño intrínseco corregido de densidad: Las dimensiones de un recurso multimedia después de que se haya corregido para la densidad de píxeles Es el tamaño intrínseco de la imagen dividido por la relación de píxeles del dispositivo. Por ejemplo, analicemos 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 que el tamaño intrínseco de la imagen 2x es de 640 x 480. Si un cliente instalado en un dispositivo con una relación de píxeles de dispositivo 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 x 240, ya que 640 x 480 dividido por 2 es 320 x 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 de densidad corregido de 320 x 240, pero 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> pasa a ser de 256 x 192.
width: 256px; y height: 192px; transforma una imagen de tamaño intrínseco de 320 × 240 en una de 256 × 192 de tamaño extrínseco.Con un poco de terminología, pasemos a la lista de sugerencias de clientes específicas del dispositivo que tienes disponibles.
Ancho de la vista del puerto
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 pantalla para entregar diferentes tratamientos (es decir, recortes) de una imagen que sean óptimos para tamaños de pantalla específicos (es decir, la dirección del arte), o bien omitir recursos que no son necesarios para el ancho de pantalla actual.
RPDC
DPR, que es la abreviatura de la proporción de píxeles del dispositivo, informa la proporción de píxeles físicos a los píxeles 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 para solicitar una imagen con un tamaño intrínseco óptimo 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 de atributo sizes de 85vw (es decir, 85% del ancho del viewport para todos los tamaños de pantalla). Si la Width sugerencia se habilitó, el cliente la enviará
esta Width sugerencia al servidor con la solicitud del <img> src:
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 la DPR (2) de la pantalla, lo que equivale a 544 píxeles.
Esta sugerencia es especialmente eficaz porque no solo tiene en cuenta el ancho de la pantalla corregido por densidad, sino que también concilia esta información fundamental con el tamaño extrínseco de la imagen dentro del diseño. De esta manera, los servidores tienen la oportunidad de negociar las respuestas de imagen que sean óptimas para la pantalla y el diseño.
DPR de 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 de selección de recursos más sencillos, la proporción de píxeles entre dispositivos y recursos puede ser la misma. Pero. En los casos en que los encabezados DPR y Width están en juego, el tamaño extrínseco de un recurso puede producir situaciones en las que ambos difieren. Aquí es donde entra en juego la sugerencia de Content-DPR.
A diferencia de otras sugerencias de clientes, Content-DPR no es un encabezado de solicitud que usen los servidores, sino que los servidores de encabezados de respuesta deben enviar cada vez que se usan sugerencias DPR y Width para seleccionar un recurso. El valor de Content-DPR debe ser el resultado de la siguiente ecuación:
Content-DPR = [Tamaño del recurso de imagen seleccionado] / ([Width] / [DPR])
Cuando se envía un encabezado de solicitud Content-DPR, el navegador sabrá cómo ajustar la imagen determinada para la proporción de píxeles del dispositivo de la pantalla y el diseño. Sin él, es posible que las imágenes no se escalen de forma adecuada.
Memoria del dispositivo
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 los navegadores suelen cargar con más recursos. También podrías enviar imágenes con una DPR más baja, ya que usan menos memoria para la decodificación.
Sugerencias de red
La API de Network Information proporciona otra categoría de sugerencias de cliente que describen el rendimiento de la conexión de red del usuario. En mi opinión, estas son las sugerencias más útiles. Con ellas, podemos adaptar las experiencias a los usuarios y cambiar 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 la aplicación. La sugerencia RTT, a diferencia del RTT de la capa de transporte, incluye el 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., mediante la omisión de algunas solicitudes).
Vínculo descendente
Si bien la latencia es importante en el rendimiento de carga, el ancho de banda también tiene influencia. 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 se entrega el contenido a los usuarios según la calidad de una conexión de red.
ECT
La sugerencia ECT significa Effective Connection Type. 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 valores RTT y Downlink.
Ese encabezado no explica cuál es el tipo de conexión real; por ejemplo, no informa si la puerta de enlace es una torre de telefonía celular o un punto de acceso Wi-Fi. En su lugar, 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, es posible que ECT se propague con un valor de 2g, que es la aproximación más cercana a la conexión real:
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, se puede definir mejor con las sugerencias de RTT y Downlink.
Guardado de datos
Save-Data no brinda una sugerencia para describir las condiciones de red, sino que es 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 acciones que se realizarían con ella son similares a otras sugerencias de red. También es probable que los usuarios la habiliten en entornos de latencia alta 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 en el que los usuarios
literalmente te piden que les envíes menos cosas. Si escuchas esa señal y actúas en función de ella, los usuarios la apreciarán.
Cómo juntar las piezas
Las acciones que hagas con las sugerencias de clientes dependen de ti. Debido a que ofrecen tanta información, tienes muchas opciones. Para que las ideas fluyan, veamos lo que las sugerencias de clientes pueden hacer para SconnieTimber, una empresa ficticia de madera ubicada en la zona rural del Medio Oeste. Como suele suceder en las áreas remotas, las conexiones de red pueden ser frágiles. Aquí es donde una tecnología como las sugerencias de clientes puede marcar la diferencia para los usuarios.
Imágenes responsivas
Todos los casos de uso de imágenes responsivas, excepto los más sencillos, pueden resultar complicados. ¿Qué sucede si tienes varios tratamientos y variantes de las mismas imágenes para diferentes tamaños de pantalla, y formatos diferentes? Este lenguaje de marcado se vuelve muy complicado muy
rápido.
Es fácil equivocarse y olvidarse o malinterpretar conceptos importantes (como sizes).
Si bien <picture> y srcset son herramientas excelentes, desarrollar y mantener su desarrollo y mantenimiento para casos de uso complejos puede llevar mucho tiempo. 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 la automatización deba realizarse de una manera que mantenga la flexibilidad que proporcionan.
Las sugerencias de los clientes pueden simplificar esto. La negociación de respuestas de imágenes con sugerencias de clientes podría verse de la siguiente manera:
- Si corresponde a tu flujo de trabajo, primero selecciona un tratamiento de imagen (es decir, imágenes dirigidas por arte) consultando la sugerencia
Viewport-Width. - Para seleccionar una resolución de imagen, verifica la sugerencia
Widthy la sugerenciaDPR, y elige una fuente que se adapte al tamaño del diseño de la imagen y a la densidad de la pantalla (similar al funcionamiento de los descriptoresxywensrcset). - Selecciona el formato de archivo más óptimo que admita el navegador (algo
Acceptnos ayuda a hacer en la mayoría de los navegadores).
En lo que respecta a mi cliente de una empresa de madera ficticia, desarrollé una rutina de selección de imágenes responsivas ingenua en PHP que usa sugerencias de clientes. Esto significaba que, en lugar de enviar este lenguaje de marcado a todos los usuarios, era lo siguiente:
<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 de PHP seguida de parámetros reescritos por mod_rewrite. Requiere 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 determinadas.
Creo que ¿esto no es solo la reimplementación de <picture> y srcset en el backend? es la primera pregunta.
En cierto modo, sí, pero con una distinción importante: cuando una aplicación usa sugerencias de clientes para crear respuestas multimedia, la mayor parte (si no todo) del trabajo es mucho más fácil de automatizar y puede incluir un servicio (como una CDN) que puede hacer esto por ti. Al igual que con las soluciones HTML, el lenguaje de marcado nuevo debe escribirse para que se adapte a cada caso de uso. Por supuesto, puedes automatizar la generación de lenguaje de marcado. Sin embargo, si tu diseño o tus requisitos cambian, es muy probable que debas volver a revisar tu estrategia de automatización en el futuro.
Las sugerencias de cliente permiten comenzar con una imagen sin pérdidas y de alta resolución a la que luego se le puede cambiar el 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. Si bien srcset te obliga a ofrecer a los navegadores un conjunto aproximado de variantes (por ejemplo, 256w, 512w, 768w y 1024w), una solución impulsada por sugerencias del cliente puede entregar todos los anchos, sin una pila gigante de lenguaje 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 el parámetro w_auto y observa que la mediana de los usuarios descargaron un 42% menos de bytes cuando usaban navegadores que las admiten.
Pero ten cuidado. Los cambios en la versión de escritorio de Chrome 67 quitaron la compatibilidad con las sugerencias de clientes de origen cruzado. Afortunadamente, estas restricciones no afectan a las versiones de Chrome para dispositivos móviles y se quitarán por completo para todas las plataformas cuando se complete el trabajo en la Política de funciones.
Ayuda a los usuarios que tienen redes lentas
El rendimiento adaptable consiste en la idea de que podemos ajustar la forma en que entregamos los recursos en función de la información que las sugerencias de los clientes pone a nuestra disposición, específicamente, la información que rodea 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 se examinan en nuestro código de backend. Cuando esto se hace, generamos un Nivel de calidad de red que podemos usar para determinar si debemos intervenir para mejorar la experiencia del usuario. Esta puntuación de red está entre 0 y 1, en la que 0 es la peor calidad de red posible y 1 es la mejor.
Inicialmente, comprobamos 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 la experiencia sea más liviana y rápida.
Sin embargo, si Save-Data está ausente, seguimos 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 la generación de puntuaciones de red está disponible en GitHub. La conclusión es que, si usamos las sugerencias relacionadas con la red de algún modo, podemos mejorar la experiencia de los usuarios que usan redes lentas.
Cuando los sitios se adaptan a la información que proporcionan las sugerencias de los clientes, no es necesario que adoptemos 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 las sugerencias de clientes cuando se trata de mejorar el rendimiento de los sitios en redes más lentas. A continuación, se muestra la cascada de WebPagetest de un sitio con una red lenta que no se adapta a las sugerencias de los clientes:
Y, ahora, una cascada para el mismo sitio con la misma conexión lenta, excepto que esta vez, el sitio utiliza sugerencias de clientes para eliminar los recursos de página no esenciales:
Las sugerencias de clientes redujeron el tiempo de carga de la página de más de 45 segundos a menos de un décimo de ese tiempo. En esta situación, los beneficios de las sugerencias para clientes no pueden enfatizarse lo suficiente y pueden ser de gran ayuda para los usuarios que buscan información crítica en redes lentas.
Además, en los navegadores que no son compatibles, puedes usar sugerencias de clientes sin afectar la experiencia. Por ejemplo, si queremos ajustar la entrega de recursos demandando el valor de la sugerencia ECT y, al mismo tiempo, ofrecer la experiencia completa para navegadores no compatibles, podemos establecer un resguardo en 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", no se verán afectados los navegadores que no admitan sugerencias de clientes. ¡Salgamos a participar!
Presta atención a esas cachés.
Cada vez que cambies una respuesta en función de un encabezado HTTP, debes tener en cuenta la manera en que la caché manejará las recuperaciones futuras para ese recurso. El encabezado Vary es indispensable aquí, ya que asigna claves de las entradas de caché al valor de los encabezados de solicitud que se le proporcionaron. En pocas palabras, si modificas una respuesta en función de un encabezado de solicitud HTTP determinado, casi siempre debes incluir la solicitud de ese encabezado en Vary de la siguiente manera:
Vary: DPR, Width
Sin embargo, hay una gran advertencia a esto: nunca recomendamos Vary las respuestas que se pueden almacenar en caché en un encabezado que cambia con frecuencia (como Cookie), ya que esos recursos realmente no se pueden almacenar en caché. Sabiendo esto, es posible que quieras evitar Vary en encabezados de sugerencias de clientes, como RTT o Downlink, ya que esos son factores de conexión que podrían cambiar con bastante frecuencia. Si deseas modificar las respuestas en esos encabezados, considera asignar solo el encabezado ECT, lo que minimizará los errores de caché.
Por supuesto, esto solo se aplica si almacenas una respuesta en caché.
Por ejemplo, no almacenarás en caché los recursos HTML si su contenido es dinámico, ya que eso puede interrumpir la experiencia del usuario en visitas repetidas. En casos como este, puedes modificar esas respuestas según lo consideres necesario y no preocuparte 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 clientes y servidores, puedes controlar cómo se entregan los recursos a través de JavaScript. Esto incluye las sugerencias de clientes. 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 sugerencia de cliente que habilites se puede leer de este modo. Sin embargo, esa no es la única manera de obtener parte de esta información. Las sugerencias específicas de red se pueden leer en estas propiedades equivalentes de JavaScript en el objeto navigator:
| Sugerencia para el cliente | Equivalente de JS |
|---|---|
| "ECT" | `navigator.connection.effectiveType` |
| “RTT” | “navigator.connection.rtt” |
| "Guardar datos" | `navigator.connection.saveData` |
| "Vínculo descendente" | `navigator.connection.downlink` |
| "Device-Memory" | "navigator.deviceMemory" |
Debido a que estas APIs no están disponibles en todos los lugares en los que necesitas verificar las funciones con el operador in, sigue estos pasos:
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 que no necesitas un servidor para negociar contenido con sugerencias de clientes. Por sí solos, los service workers tienen el poder de hacer que las experiencias sean más rápidas y más resistentes debido a la capacidad adicional que tienen de entregar contenido cuando el usuario no tiene conexión.
Conclusión
Con las sugerencias para los clientes, tenemos el poder de lograr que las experiencias de los usuarios sean más rápidas
de una manera completamente progresiva. Podemos entregar contenido multimedia según las capacidades del dispositivo del usuario de una manera que facilita la entrega de imágenes responsivas que depender de <picture> y srcset, en especial para casos de uso complejos. Esto nos permite reducir el tiempo y el esfuerzo del desarrollo, además de optimizar los recursos (especialmente las imágenes) de una manera que se oriente a las pantallas del usuario 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 si modificamos lo que enviamos y la forma en que lo enviamos. Esto puede ser largo para facilitar el acceso a los sitios para los usuarios de redes frágiles. Junto con los service worker, podemos crear sitios increíblemente rápidos que están disponibles sin conexión.
Si bien las sugerencias para clientes solo están disponibles en Chrome (y en los navegadores basados en Chromium), es posible usarlas de una manera que no obstaculice los navegadores que no las admiten. Considera usar sugerencias de clientes para crear experiencias realmente inclusivas y adaptables que sean conscientes de las capacidades de los dispositivos de cada usuario y las redes a las que se conectan. Con suerte, otros proveedores de navegadores verán el valor y muestren la intención de implementar.
Recursos
- Imágenes responsivas automáticas con Client Hints
- Imágenes responsivas y sugerencias de cliente: qué cambió en Chrome 67
- Haga una sugerencia (de cliente). (Presentaciones)
- Ofrece aplicaciones rápidas y livianas con
Save-Data.
Gracias a Ilya Grigorik, Eric Portis, Jeff Posnick, Yoav Weiss y Estelle Weyl por sus valiosos comentarios y ediciones en este artículo.