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.
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).
Conexión descendente
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:
- 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
. - Para seleccionar una resolución de imagen, revisa las sugerencias de
Width
yDPR
. 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 descriptoresx
yw
ensrcset
). - 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.
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:
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:
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` |
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
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
- Imágenes responsivas automáticas con el cliente Pistas
- Imágenes responsivas y Sugerencias de clientes: Qué cambió en Chrome [67
- Pide una pista (del cliente) (Presentaciones)
- Ofrece aplicaciones rápidas y livianas con
Save-Data
Gracias a Ilya Grigorik, Eric Portis, Jeff Posnick y Yoav Weiss y Estelle Weyl por su comentarios y ediciones valiosos de este artículo.