La web es un medio visual. La gran mayoría de ese paisaje visual es gracias a los archivos de imagen. Si bien se puede lograr mucho con CSS y SVG en línea, la mayoría de los sitios aún necesitan archivos de imagen.
En promedio, las imágenes representaron más de la mitad del tamaño de la página el año pasado y el año en el que aumenta el tamaño de la imagen; hubo un 21% de crecimiento en tamaño de imagen en 2014 solo.
Al mismo tiempo, la cantidad y diversidad de dispositivos que acceden a la web continúa creciendo. Las resoluciones ahora varían en cualquier lugar entre 72ppi (cada vez menos común) y más de 600ppi.
Crear una imagen para la pantalla que sea de suficiente calidad para cualquier dispositivo es simple: guárdelo a 1000ppi y llámelo por día. La imagen resultante será nítida incluso en los dispositivos de alta resolución más altos. Pero aunque su calidad será alta, también lo hará su tamaño de archivo. Con el tiempo de carga de la página a factor clave en UX nos corresponde garantizar que los sitios se entreguen a nuestros usuarios con prontitud. Cuando las imágenes son de una calidad tan alta que demoran unos doce segundos en descargarse en conexiones de banda ancha, y mucho menos en conexiones móviles, entonces son inutilizables.
El objetivo de las imágenes receptivas, entonces, no es entregar una imagen de mayor calidad a las pantallas que pueden mostrarla (lo que podemos hacer fácilmente), el objetivo es ofrecer la imagen de más alta calidad compatible y nada más.
Esta guía está diseñada para enseñarle lo que funciona, dónde aún se encuentran los problemas y las trampas, y cómo puede usar imágenes receptivas en los sitios web, hoy.
Siento la necesidad, la necesidad de velocidad
¿Por qué la velocidad importa? Seguramente nadie está en una conexión 3G por más tiempo? Nadie usa el acceso telefónico. Si el objetivo demográfico de su cliente habita en Manhattan urbano, ¿por qué debería preocuparse por Lesotho rural? El hecho es que es un mito que todos estamos en banda ancha súper rápida, que nos venden compañías que se benefician del deseo de velocidades cada vez mayores.
La mayoría de las personas pasan al menos dos horas al día con una conexión inferior. A menudo me encuentro con más tiempo para navegar cuando voy al trabajo, cuando incluso una conexión 3G confiable suena como un sueño lejano.
En abril Google anunció la facilidad de uso de dispositivos móviles se utilizaría como un factor de clasificación para las búsquedas realizadas en dispositivos que considera "móviles". Incluso antes de eso, la velocidad era un factor en el ranking de la página, tanto explícitamente como parte de los cálculos de Google, e implícitamente como un factor que contribuye a su tasa de rebote.
En dos sitios clasificados de manera idéntica, un 1Kb adicional podría colocarlo desde el tercer lugar en Google, hasta el 4to o el 5to. Incluso podría colocarlo del 10 al 11, en otras palabras, de la página 1 a la página 2, con todo el impacto asociado en los ingresos de su cliente.
¿Realmente necesitas esa imagen?
La imagen más altamente optimizada que existe, es ninguna imagen en absoluto. Si tiene cinco imágenes en su sitio y elimina una, se ha ahorrado un 20%, tal vez lo más importante es que se ha guardado una solicitud http. Si eliminamos todas las imágenes de nuestros sitios, nos ahorraríamos el 100% y las cinco solicitudes http. Entonces, ¿por qué no hacer eso?
No lanzamos imágenes de nuestros sitios porque se comunican de manera más efectiva que el texto a corto plazo. Crean una conexión emocional que atrae a los usuarios hacia el contenido.
Lo sabemos los usuarios no leen páginas web . Muy pocas personas leen en profundidad contenido en línea. Las imágenes nos permiten conectarnos, comunicarnos y reforzar una marca en una fracción del tiempo que el texto puede administrar.
Las imágenes pueden ser grandes y difíciles de descargar, pero una vez renderizadas en el navegador, son mucho más eficientes que el texto para establecer el compromiso del usuario y reforzar un mensaje de marca.
Las imágenes receptivas nos ayudan a garantizar que la construcción de imágenes de conexión emocional no se pierda cuando el usuario impaciente pulsa el botón Atrás.
¿Qué hay de SVG?
SVG (Scaleable Vector Graphics) es una de las verdaderas tecnologías pioneras de la Web. Está tan adelantado a la curva que la mayoría de los diseñadores todavía no han reconocido su verdadero potencial.
SVG, como su nombre lo indica, está basado en vectores. Esto significa que los gráficos SVG se construyen a partir de puntos, ángulos y distancias. SVG también es escalable, como su nombre lo indica, lo que significa que se mostrará igual de bien en un iMac de 5k o en un teléfono inteligente Android, sin pérdida de calidad ni cambios en el tamaño del archivo.
Si tiene una ilustración plana, un ícono, un logotipo, casi cualquier cosa que pueda mostrarse como SVG, entonces SVG es el camino a seguir.
La mayoría de las imágenes en la Web son mapas de bits. En términos generales, la forma en que funciona un mapa de bits es describir cada píxel de a uno por vez, su color (en RGB: valores rojo, verde y azul) y, en algunos casos, su transparencia. Si tienes una imagen que mide 100px por 100px, entonces tienes una imagen con 10,000 píxeles; si cada píxel tiene 4 valores para describirlo, entonces la imagen tiene 40,000 bits de datos asociados. Suena como mucho ¿no? A veces, eso es menos que un gráfico vectorial.
Considere una imagen de 1px por 1px; eso requeriría 4 bits de datos para registrar como un mapa de bits (valores rojo, verde, azul y alfa). Ahora considere el mismo píxel cuadrado registrado como un vector; eso requeriría x, y, ancho y alto del rectángulo, además de los valores RGBA.
Esos son ejemplos crudos, pero son precisos. A menudo, una versión vectorial de una imagen, si es que tenemos una disponible para nosotros, excede el tamaño de archivo del mapa de bits equivalente, y luego el mapa de bits es la única opción sensata.
(Mis) usando JavaScript
Al igual que la mayoría de los problemas en la vida (si su vida es en línea), las imágenes receptivas se pueden resolver con JavaScript. De hecho, durante varios años JavaScript fue la única forma de resolver el problema. JavaScript puede probar las capacidades de un agente de usuario, determinar qué tipo de navegador es y escribir una etiqueta de imagen HTML estándar que contenga la imagen adecuada.
Los diseñadores web que se oponen a usar JavaScript generalmente lo hacen porque algunas personas lo apagan . Sin embargo, ese ya no es el caso, especialmente en la web móvil, pero hay algunos problemas persistentes: escribir una imagen con JavaScript significa que la imagen no será analizada por los robots del motor de búsqueda, y solo se renderizará después de la secuencia de comandos como correr, por ejemplo.
El mayor problema con el uso de JavaScript es que se trata de un uso indebido del propósito principal de JavaScript. HTML contiene datos, CSS maneja la presentación, JavaScript maneja la funcionalidad. Cuando rompemos esos roles estructurados, empezamos a encontrarnos con problemas que requieren hacks para solucionarlos. Las imágenes son datos y, por lo tanto, deben manejarse con HTML.
El problema con los navegadores
Desde que RWD se pensó por primera vez, las imágenes han sido el mayor obstáculo. Pero ahora, estamos empezando a encontrar formas de resolver los diversos problemas. Técnicas que son resistentes a la batalla y lo suficientemente exitosas como para ser consideradas mejores prácticas. Los desarrolladores dedicados han renunciado a su tiempo para presionar al WC3 en busca de soluciones oficiales, y ahora, por primera vez, las imágenes receptivas son prácticas.
La clave para las imágenes receptivas es que han sido diseñadas con plena conciencia de las fallas de la Web. Se ha tenido cuidado para garantizar que las soluciones de imagen receptivas no rompan los navegadores existentes, de modo que incluso en navegadores que no admiten imágenes receptivas, el código fallará en silencio y no se mostrarán las imágenes predeterminadas.
En este artículo, analizaremos dos elementos HTML de imagen receptiva oficiales: srcset e imagen.
Actualmente, Edge, Safari y iOS Safari solo admiten un subconjunto de la especificación srcset . Firefox, Chrome, Opera, el navegador Android y las próximas versiones de Safari y iOS Safari son totalmente compatibles. (Discutiremos las diferencias a continuación).
En la actualidad, el elemento de imagen es totalmente compatible con Firefox, Chrome, Opera y el navegador Android. Edge, Safari y iOS Safari no lo admiten, y no han anunciado un calendario para implementarlo.
Incluso entre los navegadores que admiten el nuevo código, existen inconsistencias ya que los diferentes fabricantes de navegadores interpretan las especificaciones W3C de diferentes maneras. Por ejemplo, al especificar un cambio de imagen de pequeño a grande según el tamaño de la ventana gráfica, algunos navegadores cambiarán a la imagen grande cuando la ventana gráfica sea 1px mayor que el tamaño preferido de la imagen pequeña, mientras que otros cambiarán a la imagen grande solo cuando la ventana gráfica favorecido por la imagen de gran tamaño es totalmente coincidente.
En resumen, los navegadores se dividen en dos campos: los que favorecen las imágenes de mayor calidad siempre que sea posible, y los que favorecen las descargas más pequeñas siempre que sea posible. Los fabricantes de navegadores siguen duchándolo, eventualmente la implementación de alguien será más popular. Personalmente, espero que sea la última porque, como se señaló anteriormente, el rendimiento es crucial para la experiencia del usuario.
Por ahora, la mejor opción para los diseñadores web es ajustarse a la especificación y no intentar adivinar el navegador. Después de todo, la experiencia predeterminada en el navegador (mayor calidad o descargas más rápidas) es parte de lo que el usuario selecciona para un navegador predeterminado, por lo que si el usuario conoce los diferentes enfoques, entonces la preferencia del navegador es también la preferencia del usuario. .
Mejores prácticas de imagen receptiva (2015)
A lo largo de la historia de la Web, hemos utilizado un elemento para indicar una imagen, el elemento img . En HTML5, el elemento img ha experimentado un cambio sutil en su función, que está diseñado para permitir imágenes receptivas: el elemento img ya no representa una imagen, ahora es un marcador de posición para una imagen.
Esa distinción es importante, porque mientras que un elemento img tenía previamente un solo conjunto de datos de imagen, ya sea un mapa de bits o un vector, ahora una imagen puede contener múltiples conjuntos de datos.
El elemento img (para recapitular para cualquier no codificador) se ve así:
La versión de imagen receptiva del elemento img se ve así:
Apenas cualquier cambio en absoluto. Al observar este código, observa una cosa importante: el código es compatible con versiones anteriores. Si ocurre un navegador que no comprende el atributo srcset , simplemente lo ignorará y procesará la imagen de acuerdo con la especificación original de 1993.
Lo que esto significa es que ahora podemos usar imágenes receptivas en nuestro marcado, sin la necesidad de detección de características.
En el nuevo elemento responsivo de img , src se usa principalmente como imagen predeterminada y para navegadores que no reconocen srcset, mientras que srcset contiene todas las imágenes de formato de alta resolución disponibles para ese marcador de posición.
Al renderizar el elemento img , el navegador determinará por sí mismo qué archivo de imagen es el más apropiado.
Usando srcset
Ahora que sabemos que srcset fallará silenciosamente en los navegadores que no lo admiten, podemos agregar una imagen adicional de forma gratuita:
En este caso, cualquier navegador que admita srcset mostrará image-b.jpg y cualquier navegador que no admita srcset mostrará image-a.jpg.
Es importante tener en cuenta que el navegador solo descargará la imagen que decida que quiere mostrar, no descargará ambas imágenes y luego elegirá una.
Lamentablemente, esto no nos lleva muy lejos, porque a menos que demostremos soporte para srcset , no hay una aplicación práctica para cambiar las imágenes basadas solo en el soporte de srcset .
La solución es proporcionar información adicional al navegador sobre qué imagen debe elegir. Para hacer eso, necesitamos proporcionar información sobre el espacio disponible o la densidad de píxeles.
Usando x-descriptor
El descriptor x le dice a un navegador qué densos son los píxeles en una imagen.
Si, por ejemplo, desea proporcionar una imagen de grado retina con el doble de píxeles que una imagen estándar, debe especificar la imagen de la retina en el srcset, seguido de un espacio y luego la palabra clave "2x".
Tenemos nuestra imagen:
Para agregar una opción de retina para el navegador, agregamos el siguiente srcset:
En este caso, hay tres posibles resultados:
si el navegador no es compatible con srcset , usará el archivo de imagen especificado en el atributo src ;
si el navegador admite srcset y tiene una pantalla capaz de una resolución doble, usará la imagen especificada en el atributo srcset;
si el navegador admite srcset pero no tiene una pantalla de alta resolución, usará la imagen especificada en el atributo src (cuando no se especifica una imagen "1x" en el atributo srcset , se supone que el atributo src es esa imagen) opción).
El soporte del navegador es bueno y está mejorando rápidamente. Con un atributo, hemos resuelto el enigma de las imágenes receptivas, ¡yay nosotros!
Una última observación sobre el descriptor x: la elección de qué imagen cargar se basa en la densidad de píxeles, por lo que si un usuario amplía su navegador al 200% (reduciendo a la mitad el tamaño de la imagen y doblando la densidad de píxeles), el 2x la imagen se cargará Esto puede tener un efecto perjudicial en la accesibilidad: ciertamente no queremos que los sitios se carguen más despacio para las personas con problemas de visión, simplemente porque eligen acercar su navegador.
Usando w-descriptor
El descriptor w es un poco más avanzado que el descriptor x. El w-descriptor funciona al decirle al navegador cuántos píxeles reales existen en el eje x (el ancho) de una opción de imagen particular.
Edge, Safari y iOS Safari no son compatibles con el w-descriptor en el momento de la redacción, por lo que su utilidad se reduce un poco.
Volvamos a nuestra imagen original:
Si esta imagen es de 1600 píxeles de ancho y si queremos agregar una imagen de retina, como hicimos con el descriptor x anterior, especificaríamos una imagen en el atributo srcset de 3200 píxeles de ancho:
Hay un inconveniente importante con el descriptor w: aunque el atributo src se trata como el predeterminado al especificar imágenes usando el descriptor x, los navegadores que ignoran srcset lo utilizan por completo si utiliza el descriptor w. Al usar el descriptor w, debemos especificar el valor predeterminado explícitamente al agregar una segunda opción de imagen de srcset , con su propio descriptor w, y separarlos con una coma:
Lo que nos lleva pulcramente a ...
Usando múltiples imágenes
Ser capaz de especificar una opción de imagen de alta resolución para el navegador directamente en nuestro código HTML es decididamente genial, pero como probablemente haya adivinado, se enfría aún más cuando especificamos varias imágenes.
El objetivo de las imágenes con capacidad de respuesta es ofrecer la mejor calidad de imagen utilizable por el dispositivo de acceso, pero nada más. Entonces, simplemente el suministro de una imagen de retina no es adecuado, necesitamos suministrar imágenes a, por ejemplo, 1x, 1.5x, 2x, 2.5x y 3x.
Una vez más, aquí está nuestro marcado de imagen original:
Aquí está con una imagen de grado de retina proporcionada como una opción para el navegador:
Aquí está, esta vez con opciones adicionales en el srcset, separadas por comas:
Debido a que las palabras clave significan cosas diferentes para diferentes personas, me parece aconsejable nombrar mis imágenes de acuerdo con el descriptor x al que pertenecen, como una ayuda de memoria personal, y para asegurar que los diferentes tamaños sean claros para los otros miembros del equipo:
Recuerde, no le estamos diciendo al navegador qué imagen mostrar, le informamos las opciones disponibles y le permitimos que seleccione por sí mismo. El navegador solo descargará una de estas imágenes.
Uno tiene varias imágenes: nunca especifique dos imágenes en el atributo srcset con un descriptor x correspondiente y un descriptorw, por ejemplo:
El atributo de tamaños es una adición particularmente interesante a la especificación, porque el atributo de tamaños toma sus valores relativos a la ventana gráfica, no a la imagen.
Usando el valor de vw (ancho de ventana), especificamos el área de la imagen relativa al ancho del navegador. Recuerde, el elemento img ahora es solo un marcador de posición, por lo que no especificamos el tamaño real de la imagen, estamos especificando el tamaño del marcador de posición que contendrá la imagen.
100vw es el 100% del ancho de la ventana gráfica, 50vw es el 50% del ancho de la ventana gráfica, 25vw es el 25% del ancho de la ventana gráfica, etc.
Si quisiéramos configurar el ancho de img a la mitad del ancho del navegador, usaríamos:
Esto no es particularmente útil, hasta que lo combinemos con consultas de medios ...
Usando consultas de medios
El atributo de tamaños se vuelve mucho más poderoso cuando lo combinamos con consultas de medios. Podemos separar anchos de ventanas múltiples usando comas, y decirle al navegador cuál usar usando una consulta de medios de estilo CSS.
Por ejemplo, imagina que queremos que una imagen represente el 80% del ancho de nuestra ventana en la mayoría de los dispositivos, pero en dispositivos pequeños (como teléfonos) con un ancho de 380 píxeles o menos, queremos aprovechar al máximo el espacio disponible componiendo el 100% del ancho, lo escribiríamos así:
Siguiendo esta lógica, cualquier navegador con una vista de 380px o menos establecerá el ancho de la imagen al 100% de la ventana gráfica. Cualquier otro navegador hará que la consulta de medios devuelva falso y el navegador se moverá al siguiente valor del atributo de tamaños , que en este caso es 80vw.
Como regla general, no me siento cómodo usando consultas de medios en HTML. Del mismo modo que los datos de imagen receptivos pertenecen a HTML (no JavaScript), las consultas de medios pertenecen a CSS (no a HTML). Sin embargo, la opción está ahí para ti si la necesitas.
Mejores prácticas de imagen receptiva (¿2016?)
No sé ustedes, pero estoy muy emocionado por las posibilidades de srcset. Es una solución simple a un problema difícil y parece brindar todo lo que necesitamos.
Pero, al igual que los autobuses, esperas 20 años para obtener una solución oficial para las imágenes receptivas, y luego aparecen dos a la vez. Además del atributo srcset del elemento img , también tenemos el elemento picture .
El elemento de imagen es otro marcador de posición, aunque uno más tradicional. Ha sido diseñado para imitar los elementos de video y audio en HTML5, por lo que su sintaxis será familiar para la mayoría. El elemento de imagen está destinado a ser utilizado cuando necesita más control del que srcset puede proporcionar.
Lamentablemente, el elemento de imagen tiene mucho menos soporte de navegador que srcset y no siempre falla silenciosamente.
Usando el elemento de imagen
Aquí está nuestro elemento de imagen original:
Aquí está nuestra imagen anidada dentro de un elemento de imagen:
También podemos especificar un srcset para un elemento img dentro de un elemento de imagen :
Usando el elemento fuente
El elemento de imagen no cobra vida hasta que agreguemos el elemento de origen :
Al seleccionar qué archivo usar, el navegador comenzará con el primer elemento de origen y se moverá a través de los elementos hasta que encuentre uno cuyo atributo de medios se resuelva como verdadero, y luego usará el srcset de ese elemento de origen.
Por ejemplo, podríamos especificar diferentes imágenes para formatos de retrato y paisaje:
También podemos especificar múltiples imágenes utilizando x-descriptor y w-descriptor:
Al igual que con el uso de consultas de medios en el atributo de tamaños , cuestionaría la sabiduría de controlar las versiones de imágenes en función del estilo, en el marcado en lugar de en una hoja de estilo. Sin embargo, la opción de usar el atributo de medios está ahí si la necesita.
Usando tipo
El elemento de la imagen realmente se hace propio cuando se utiliza para intercambiar diferentes tipos de imágenes.
Imagine que tenemos un archivo PNG estándar, pero queremos usar un Archivo WebP, que es típicamente un 26% más pequeño, recuerde que las imágenes con capacidad de respuesta ofrecen la mejor calidad de imagen, al menor tamaño, pero que actualmente solo son compatibles con Chrome, Opera y el navegador Android. Tendremos que usar el atributo de tipo para determinar si WebP es compatible:
En este caso, el navegador comprobará si el formato de imagen WebP es compatible. Si lo es, determinará si la pantalla tiene suficiente densidad de píxeles para mostrar la imagen retina-image.webp , de lo contrario, mostrará la imagen image.webp . Si WebP no es compatible, el navegador saltará directamente al elemento img y trabajará a través de las opciones srcset y src de la forma en que ya estamos familiarizados.
El atributo tipo significa que podemos proporcionar formatos de imagen mucho más pequeños cuando es compatible, lo que da como resultado un tamaño de archivo más pequeño.
Problemas conocidos
IE9 tiene un problema conocido, eso evita que el elemento de imagen falle silenciosamente. Para manejar IE9, necesitas engañar a IE9 para que piense que los elementos fuente son parte de un elemento de video :
< !—[if IE 9]>< ![endif]—>
Es una solución fea, pero mejor que ninguna solución. Solo podemos esperar que el lanzamiento de Windows 10 acelere la desaparición de IE9, porque aunque Edge aún no es compatible con el elemento de imagen , no lo admite de la manera correcta (ignorándolo).
Existen polyfills eso puede ayudarte a soportar el elemento de imagen en IE, pero mi propia preferencia es evitarlos. Desconfío de los problemas de parchado con JavaScript, afecta el rendimiento y conduce a un código menos sostenible.
Por esta razón, recomiendo evitar el elemento de imagen por ahora. A menos que esté ejecutando un sitio de comercio electrónico a gran escala, el ahorro adicional en tiempo de descarga que ofrece el formato WebP es poco probable que supere la inconveniencia de parchear su marcado con script.
Una vez que IE9 cae por debajo del 1%, lo que debería suceder en algún momento del año siguiente, el elemento de la imagen será viable. Si estás leyendo esto en 2016, probablemente estés listo.
Crear imágenes receptivas
A diferencia de SVG, las imágenes de mapa de bits no se amplían. Nuestra estrategia para manejarlos, ya sea que usemos srcset o el elemento de imagen , es proporcionar una imagen diferente en función de las capacidades del navegador. Para manejar eso, necesitamos suministrar una variedad de tamaños de imagen diferentes.
La mayoría de las aplicaciones de edición de imágenes han automatizado el proceso de exportación de múltiples versiones de una sola imagen. No importa qué aplicación use, siempre que termine con múltiples tamaños de imagen sin tener que cambiar el tamaño manualmente y guardar cada uno.
Adobe Photoshop es el editor de mapa de bits de facto. No es una gran opción para el trabajo de diseño, pero su flujo de trabajo de procesamiento de imágenes es fluido y confiable. Generar múltiples resoluciones de imagen en Photoshop es relativamente sencillo:
Abra la imagen de la que desea generar múltiples versiones y colóquela en su propia capa.
Cambie el nombre de la capa como el nombre del archivo que desea generar (incluida la extensión).
Seleccione Archivo> Generar> Activos de imagen y una carpeta con su nueva imagen se guardará junto con su PSD.
Cambie el nombre de la capa, especificando cada imagen que desea generar precedida por su escala prevista. No necesita repetir el paso 3, una vez que cambie el nombre de la capa, las imágenes se generarán automáticamente.
El crédito por la imagen va aPhilip Collier.
Para obtener más información sobre la generación de imágenes en Photoshop, mira aquí.
En base a estas imágenes, podemos ofrecer al navegador cinco opciones diferentes:
Conclusión
El elemento img ha recorrido un largo camino en 20 años. O, para ser más precisos, el elemento img fue inadecuado durante 18 años, luego corrió para la línea en los últimos dos años, hasta el punto de que ahora es relativamente sofisticado.
Lo importante, es que llegamos a la (s) solución (es).
De las dos opciones disponibles, srcset y picture, la primera es de lejos la más compatible. Si está construyendo el 95% de los sitios, entonces la mejor opción es la compatibilidad superior y la implementación más sencilla del atributo srcset .
Si está ejecutando un gran sitio de comercio electrónico, con miles de imágenes de productos, el trabajo adicional para servir el formato WebP puede valer la pena, especialmente a medida que aumenta el soporte para el elemento de imagen en los próximos años.
La mayor debilidad en las opciones actuales es que los navegadores actualmente no tienen una forma de seleccionar una imagen en función de su velocidad de conexión. Nos vemos obligados a confiar en que los dispositivos más capaces también están en conexiones superiores.
En última instancia, finalmente podemos servir imágenes de la más alta calidad prácticamente posible, en el tamaño más pequeño. Eso significa una mejor experiencia, en un tiempo más corto, que solo puede ser algo para abrazar.
Usos de imágenes destacadas,imagen de la montañayimagen del dispositivoa través de Shutterstock.
