Hay un montón de técnicas para lidiar con imágenes sensibles últimamente. Es decir, soluciones que nos ayuden a ofrecer la imagen adecuada para la ocasión (por ejemplo, tamaño de pantalla y ancho de banda disponible). Todos hacen las cosas de forma un poco diferente. Para realizar un seguimiento, Christopher Schmitt y yo hemos creado esta hoja de cálculo de técnicas.
La hoja de cálculo tiene los datos, pero digámoslos pensando en ellos a través del lente de las preguntas prácticas.
Para elegir la técnica adecuada para usted y su proyecto, estas preguntas pueden servir de guía. Muchas de las preguntas pueden aplicarse a su proyecto, por lo que tendrá que decidir qué técnicas se ajustan a qué escenarios y encontrar la superposición.
¿Tengo contenido heredado?
Lo que realmente significa … ¿Tengo contenido heredado que no es práctico actualizar? Por ejemplo, tengo miles de páginas de contenido sobre Programar Plusy un equipo de redacción de uno.
Yeahhhh… No voy a volver atrás y actualizar cada <img> en el sitio, por lo que necesito una técnica que me permita dejarlos en paz.
La única técnica que conozco que funciona sin absolutamente ningún cambio de marca es Adaptive Images. Funciona enrutando las solicitudes de imágenes a través de un archivo PHP que sirve de manera inteligente (y crea si es necesario) imágenes del tamaño apropiado para el ancho de la pantalla.
Otra pregunta que debe hacerse es si le importa el contenido heredado. Quizás la gran mayoría del tráfico a su sitio sea para contenido más nuevo en el que poder realizar cambios de marcado y así aprovechar otras técnicas. Si ese es el caso, siga leyendo para descubrir esas otras técnicas.
Si tiene un proyecto pequeño, un proyecto nuevo o un proyecto con contenido heredado que puede volver atrás y actualizar, también puede elegir una técnica que requiera un marcado especial, así que también siga leyendo.
¿Me preocupo por el marcado especial?
Esta es realmente una sub-pregunta de la anterior. Muchas de las técnicas requieren que uses HTML especial. Por ejemplo, HiSRC le pide que ponga imágenes de mayor resolución como atributos de datos:
<img src="https://css-tricks.com/which-responsive-images-solution-should-you-use/200x100.png" data-1x="400x200.png" data-2x="800x400.png">Yo diría que esta es una técnica semántica limpia, válida, pero también significa que necesita estos atributos en cada <img> en su sitio, lo que puede no ser posible en sitios con mucho contenido heredado.
Si sabe que el marcado especial (o CSS especializado) no es una opción para usted, realmente la única opción es Adaptive Images. Incluso Sencha.IO requiere prefijar el atributo src, lo que puede no ser posible con contenido heredado.
¿Me importa la semántica?
Algunas técnicas de imágenes receptivas implican marcas que no son estrictamente semánticas. En última instancia, solo hay una forma en que una imagen puede ser semántica. Eso es si el src apunta a una imagen real y tiene alt texto que describe esa imagen. Brad Frost lo resume muy bien:
@stowball Desafortunadamente, no es tan simple. Una imagen de un caballo debe ser una imagen de un caballo o de lo contrario no es una imagen de un caballo. 🙂
– Brad Frost (@brad_frost) 5 de abril de 2012
En otras palabras, si la técnica requiere en algún momento la src de la imagen que falta o enlaza a un GIF transparente (o similar), eso no es semántico.
Entonces, ¿por qué algunas técnicas de imágenes receptivas hacen esto? Porque tener una imagen con un src que apunta a esa imagen de un caballo significa que esa imagen comenzará a descargarse tan pronto como el navegador la analice. No existe una forma práctica de prevenir esto. Incluso si lo cambias muy rápido src con una versión más apropiada, ahora está descargando dos imágenes en lugar de una, que es un impacto de rendimiento en lugar de una ganancia de rendimiento. Puede decidir que es aceptable (por ejemplo, los entornos de “escritorio” suelen tener más ancho de banda). Por lo general, si se emplea esta técnica, la imagen en el src es la imagen más pequeña posible.
Si la semántica es importante para usted, debería mirar Adaptive Images (cubierto arriba) o HiSRC, un complemento de Christopher Schmitt que puede usar con una semántica src atributo.
Algunas de las técnicas utilizan <noscript> etiquetas en las que colocar un respaldo <img> en el caso de que JavaScript no esté disponible. Dejaré que decidas si eso es semántico o no.
¿Me importa la validez?
Validez como en “¿Se valida?” según el servicio de validación de marcado del W3C. La validación es una herramienta que le ayuda a encontrar problemas y escribir un mejor marcado. Pero el hecho de que algo no se valide no significa que sea malo o incorrecto. Si el código inválido funciona maravillosamente en todos los navegadores, a usted ni a nadie debería importarle.
Si le importa la validez (tal vez un cliente lo requiera irracionalmente y esté reteniendo su sueldo al azar), hay algunas técnicas que no puede usar. La técnica de relleno de imágenes, por ejemplo, utiliza la <picture> elemento para hacer su magia. En última instancia, esto puede estar estandarizado, pero aún no lo está, por lo que es una sintaxis técnicamente inválida. También se requiere que <img> los elementos tienen un src atributo, por lo que las técnicas que eliminan eso para evitar el problema de solicitud de doble imagen no son válidas.
Recomendaría estas técnicas si la validez es un requisito para usted: Adaptive Images, HiSRC o Responsive Enhance. Todos los cuales usan simple, válido <img> sintaxis que incluye un src.
¿Me importa la dirección de arte?
Algunas técnicas de imágenes receptivas sirven versiones de diferentes resoluciones de la misma imagen exacta. Si bien eso facilita las cosas (es decir, menos trabajo), puede que no sea aceptable. Aquí tienes un ejemplo visual:
A la izquierda, el “móvil” y el predeterminado src. En el medio, una imagen un poco más grande que podría usarse en (ejem) “tabletas”. A la derecha, la más grande de las imágenes (crédito).
Estas imágenes están hechas a mano por un diseñador, recortadas para conservar el significado y el impacto. Si toma la imagen de la derecha y simplemente la reduce, las personas en la imagen serían muy pequeñas y la sensación de la imagen podría perderse.
Si esta idea de la dirección de arte es importante para su proyecto, necesitará una técnica que le permita especificar exactamente a qué src servir bajo qué circunstancias. Esta es una imagen perfecta (¿CONSEGUIRLO?) Para el relleno de imágenes, lo que le permite ser muy específico sobre las fuentes y las circunstancias.
<picture alt="description">
<source src="https://css-tricks.com/which-responsive-images-solution-should-you-use/small.jpg">
<source src="medium.jpg" media="(min-width: 400px)">
<source src="large.jpg" media="(min-width: 800px)">
</picture>JavaScript lo toma a partir de ahí.
¿Me importa JavaScript?
La mayoría de estas técnicas de imágenes receptivas utilizan JavaScript para hacer su magia. Algunos solo un poquito para establecer una cookie, pero JavaScript no obstante. Algunos de ellos le han puesto un <img> en un <noscript> etiqueta para que haya una imagen de respaldo en el caso de que el usuario tenga JavaScript desactivado. Si no le gusta eso y necesita asegurarse absolutamente de que sus imágenes funcionen sin JavaScript, Sencha.IO es su mejor opción. Este servicio funciona identificando su dispositivo a través de su cadena de agente de usuario y mostrando una imagen de tamaño adecuado. Por lo tanto, se vincula a la versión más grande (razonable) que tiene y Sencha la reducirá y servirá versiones más pequeñas si es necesario (no se amplía, por razones obvias).
¿Qué pasa con la dependencia de la * biblioteca * de JavaScript?
HiSRC y rwdImages dependen de jQuery. Si su proyecto utiliza una biblioteca diferente, probablemente estas no sean para usted. Pero bueno, ¡podrías portarlo y abrirlo en código abierto! Si no está utilizando una biblioteca, probablemente debería hacerlo, pero no entremos en eso.
¿Me preocupan los componentes del lado del servidor?
Algunas de estas técnicas no dependen únicamente de JavaScript. Adaptive Images funciona de manera mágica principalmente a través de .htaccess y PHP. Bueno, .htaccess presupone un servidor Apache. Y, aunque, por supuesto, todos conocemos y amamos PHP (ejem), muchos sitios web funcionan con tecnologías como Ruby o Python.
Responsive Images (la técnica original de Filament Group) también usa .htaccess. Entonces, si está usando algo como Nginx como servidor web, esto está desactivado o tendrá que migrar el componente .htaccess a la sintaxis similar pero diferente de Nginx.
¿Me preocupan las pruebas de ancho de banda?
Probar el ancho de la ventana del navegador y tomar decisiones sobre qué imagen servir en base a eso es bastante bueno y fundamental para el concepto de imágenes receptivas. Pero en realidad es solo la mitad de lo que debe basarse en la decisión de qué imagen se debe publicar. La otra mitad es ancho de banda disponible. Si el usuario tiene una velocidad de conexión a Internet muy rápida, está bien servir imágenes grandes. Si el usuario tiene una velocidad de conexión a Internet muy lenta, debería obtener imágenes más pequeñas (independientemente del tamaño de la pantalla). Desafortunadamente, las consultas de medios de ancho de banda nativo no existen.
Dos de las técnicas actuales realizan pruebas de ancho de banda como parte de su toma de decisiones: Foresight.js y HiSRC (ambas se basan en la técnica de Foresight.js). Funciona descargando un archivo de prueba y midiendo cuánto tiempo tomó (configurable). La prueba en sí es un ligero golpe de rendimiento, pero teóricamente los ahorros obtenidos al ofrecer imágenes basadas en saber que el ancho de banda actual es una ganancia neta (¿OBTENERLO?).
¿Me importa confiar en terceros?
Sencha.IO es una forma completamente de terceros de manejar imágenes receptivas. Hasta donde yo sé, funciona muy bien y no se ha visto afectado por ningún tiempo de inactividad importante, pero, por supuesto, siempre corre ese riesgo.
Quizás estés pensando: Vaya, la técnica Sencha.IO es realmente genial, pero me preocupa la dependencia de terceros. Ojalá pudiera ejecutar eso en mi propio servidor. Si desea seguir ese camino, existe la base de datos pública WURFL y esta técnica de imágenes receptivas del lado del servidor que lo pone a trabajar localmente.
También existen servicios de terceros como Device Atlas Cloud, que realiza la detección de dispositivos por usted. También es una dependencia de terceros para su aplicación. Sin duda, su objetivo y enfoque es mantenerse activo y rápido en todo momento, pero debes tener mucho cuidado con en quién y en qué confías para tu negocio.
Un par de otros servicios de terceros: ReSRC.it, Responsive.io, Thumber.io
¿Existe un CMS específico con poderes específicos de CMS involucrados?
Digamos que su proyecto está en WordPress. WordPress tiene un cargador de medios integrado. Cuando carga una imagen con él, puede crear múltiples versiones (reduciendo la escala) de esa imagen para usted. Eso es muy bueno y poderoso y podrías / deberías aprovechar eso. Keir Whitaker habla sobre el uso de esa capacidad en su artículo Imágenes de respuesta automática en WordPress.
Sin embargo, esto no es solo una cosa de WordPress. Estoy seguro de que los conceptos que se utilizan aquí podrían hacerse (o hacerse para que se hagan) en cualquier sistema de gestión de contenidos.
¿Me preocupan las solicitudes dobles siempre que la solución sea móvil primero?
Muchas de estas soluciones intentan resolver el problema de la mejor manera posible: realizando una única solicitud del recurso adecuado. Si está de acuerdo con vincular la versión más pequeña del archivo (para que la solicitud se realice sin importar qué) y reemplazarla con imágenes más grandes cuando sea necesario, tal vez Source Shuffling funcione para usted. Tenga en cuenta que la biblioteca que usa ahora sugiere usar font-family en vez de content para detectar los cambios en la consulta de medios.
¿Puedo esperar al futuro?
El lanzamiento del “nuevo iPad” (el tercero, por longevidad) es lo que provocó muchas de estas técnicas y conversaciones. Su alta densidad de píxeles es ideal para vectores y fotos grandes, pero en realidad no es ideal para cosas como iconos pequeños que deben ampliarse para tener el tamaño correcto y pueden verse borrosos. Pero servir íconos de mayor resolución significa archivos de mayor tamaño y sitios web más lentos. De ahí la necesidad de atenderlos solo en situaciones / entornos que los necesiten.
El mundo de los estándares web es consciente de este problema. Hay todo un grupo dedicado a hablar de ello. Con el tiempo, pueden resolverlo y luego podemos comenzar a usar la forma que se les ocurra (asumiendo que es increíble y mejor que lo que tenemos ahora).
Es posible que esté cambiando el src de las imágenes a través del contenido CSS, como sugirió Nicolas Gallagher. Podría ser el <picture> elemento. Puede ser un atributo srclist en HTML o una propiedad src en CSS. Podría ser un prefijo.
Tal vez envíe solicitudes de información del navegador, como en Client-Hints.
Más recursos
- Jason Grigsby tiene una serie épica de tres partes sobre imágenes receptivas que comienza aquí.
- Las diapositivas de Christopher Schmitt sobre una charla completa sobre imágenes receptivas.
- Mat Marquis sobre las imágenes receptivas: cómo casi funcionaron y qué necesitamos