Comentarios de la encuesta de optimización de imágenes del verano de 2019

Comentarios de los encuestados sobre varias técnicas de optimización de imágenes

Sam Dutton

En esta publicación, se enumeran los comentarios de formato libre que recibió el equipo de DevRel de Google Web en su encuesta sobre técnicas de optimización de imágenes del verano de 2019. Se solicitaron respuestas a través de Web Fundamentals y @ChromiumDev. El objetivo de la encuesta era averiguar por qué la mayoría de los sitios no siguen las prácticas recomendadas de optimización de imágenes, a pesar de que parecen una forma relativamente fácil de mejorar el rendimiento. Los datos de las respuestas no se incluyen aquí porque hubo fallas en la metodología de la encuesta.

Público

  • Si eres desarrollador web, es posible que esta publicación te resulte útil para descubrir nuevas técnicas de optimización de imágenes o detalles sobre cómo otros desarrolladores web resolvieron un problema que tienes, así como los costos, los beneficios y las limitaciones de cada técnica.
  • Si tienes un servicio de imágenes o un proveedor de CDN de imágenes, esta publicación podría ayudarte a encontrar nuevas oportunidades de mercado.
  • Si eres desarrollador de frameworks, herramientas de compilación o CMS, esta publicación podría darte ideas sobre nuevas funciones que implementar.

Comentarios

WebP

  • "Me gusta WebP, pero aún no está completamente listo. Además, nuestro WordPress no admite WebP. Una de las apps de edición de fotos más populares, Photoshop, tampoco admite WebP de forma predeterminada. Por lo tanto, no podemos depender de apps o servicios de terceros para la compresión de imágenes".
  • "Hacer que WebP sea utilizable en Safari".
  • "Me encantaría usar WebP si pudiera exportarlo desde Photoshop/Figma/Sketch y todos los navegadores lo admitieran". [Nota: Sketch sí admite WebP]
  • “Sería genial tener una solución de formato de nueva generación”.
  • "Deja de promocionar WebP tanto cuando la compatibilidad con el navegador es baja y considera la necesidad de usar PNG en lugar de JPEG para las capturas de pantalla".
  • “Documentos de Google no admite WebP”.
  • "Usaríamos WebP de forma exclusiva, pero nos preocupa la compatibilidad con los navegadores".
  • "Primero, corrige la compatibilidad del navegador y actualiza los navegadores heredados o agrega correcciones heredadas. Luego, las personas estarán más dispuestas a adoptar nuevos tipos de imágenes, como WebP…"
  • "Anima a los desarrolladores de complementos o temas a que consideren brindar compatibilidad con WebP y otros tipos de imágenes de nueva generación, de modo que las personas que no sean desarrolladores no tengan que manipularlos".

Imágenes vectoriales y SVG

  • "Si es posible, uso SVG (animado). gatsby-image corrigió muchos de estos problemas. Sin embargo, cuando analizas lo que hicieron, es completamente irreal que un sitio web normal deba crear algo así para que las imágenes funcionen correctamente. El navegador debería asumir más responsabilidad en este tema".
  • "¿Sería posible documentar cómo crear animaciones SVG con lottie.js?"
  • "La mayoría de las veces, intentamos usar imágenes JPEG de alta resolución con tamaños pequeños en nuestro sitio web para evitar los tiempos de carga. También nos aseguramos de usar SVG cuando sea necesario para proporcionar calidad al diseño responsivo".
  • "Si es posible, intentamos usar gráficos vectoriales optimizados para todo, excepto para las imágenes".

Otros formatos de imagen

  • “Debemos educar mejor a las personas para que dejen de usar GIF”.

Carga diferida

  • “Ten en cuenta al usuario cuando consideres funciones como la carga diferida, ya que para muchos es molesta”.
  • "Haz que el atributo de carga diferida funcione con background-image".
  • "Los frameworks deberían realizar un mejor procesamiento de recursos de forma predeterminada".
  • "Hace mucho tiempo que cambiamos de la carga diferida. Los usuarios informan que millones de imágenes y sitios "NO SE CARGAN". Así es como nuestro equipo resumió la situación. Es difícil para los usuarios no técnicos describir los problemas".
  • "Me gustaría comprender mejor el uso de la API de Intersection Observer para la carga diferida en lugar de usar técnicas tradicionales".
  • "Esto funciona bien para mí: pwafire.org/developer/codelabs/progressive-loading".

Imágenes de fondo

  • “Por lo general, cargo imágenes como fondos en CSS”.
  • "La etiqueta <img> es problemática y es difícil controlar los detalles detallados, especialmente con el contenido que envían los usuarios. Usamos <div> y el diseño de imagen de fondo con mucha más frecuencia, ya que nos permite usar background-size, background-position y evitar que se guarde la imagen con el clic derecho".

Transparencia

  • “Estamos en 2019. ¿Cómo es que los archivos JPG siguen sin transparencia alfa?"
  • “Solo uso archivos PNG para fotografías cuando necesito un fondo transparente”.

Marcadores de posición de imagen de baja calidad (LQIP)

  • "Usamos LQIPS y es una excelente técnica para mantener la participación de los visitantes sin cargar imágenes de alta calidad demasiado pronto".

Rendimiento

  • “Tuvimos un problema de rendimiento reciente con las imágenes. A medida que el usuario se desplaza hacia abajo en nuestro sitio, mostramos las siguientes 60 tarjetas, que incluyen una miniatura. Debido al límite de 6 conexiones en el mismo dominio, se bloqueaban las miniaturas, así como la siguiente solicitud AJAX para obtener las siguientes 60 tarjetas si un usuario continuaba desplazándose hacia abajo".
  • "Nos encantaría usar HTTP/2, pero la mayoría de nuestros clientes usan IE11. Por lo tanto, estamos explorando el particionamiento de dominios o la carga de solicitudes de datos JSON de AJAX desde un dominio diferente".

Tamaño

  • "Lo siento por intrinsicsize. Creo que aprovechar la altura o el ancho es mejor".
  • “Estoy buscando una forma de generar menos tamaños, en este momento son alrededor de 12”.
  • "El cambio de tamaño dinámico de las imágenes es muy difícil e imposible sin JS".
  • “Una herramienta como responsivebreakpoints.com es buena para web.dev :)”.

Imágenes de alta calidad y alta resolución

  • "¿Cómo descargar imágenes comprimidas sin perder la calidad del DPI?"
  • “Somos una empresa de administración de documentos. Nuestras apps manejan MILLONES de imágenes escaneadas de alta resolución, generalmente en formato TIFF o PDF".
  • "Es un problema. Los archivos de imágenes de alta resolución son necesarios para el formato impreso y deben estar optimizados para la Web. Reducir el tamaño de las imágenes para la Web es un inconveniente, pero es un inconveniente si los autores solo proporcionan archivos ligeros para las imágenes destinadas a la publicación impresa. Enviamos mensajes contradictorios sobre los requisitos para enviar manuscritos con material gráfico. Luego, terminamos con flujos de trabajo complejos para procesar esos materiales".

Funciones del navegador

  • "El recorte automático del src responsivo desde el navegador como función [integrada] sería muy útil, ya que recortar todas las imágenes en 4 tamaños y escribir todo el marcado lleva tiempo. Si pudiéramos subir una foto grande y escribir una etiqueta de imagen simple para que los navegadores creen automáticamente los múltiples atributos src, sería una función ganadora".
  • "Personalmente, me cuesta evitar el reflujo de páginas cuando el CSS establece la imagen con imágenes responsivas (max-width: 100%; height auto o height: width: 100%; height auto), especialmente en combinación con la dirección de arte de las imágenes adaptables o la etiqueta de imagen. La mejor manera de evitarlo parece ser usar el "truco de padding negativo" para una relación de imagen fija y, luego, posicionar la imagen dentro de este cuadro de relación. Una mejor compatibilidad con navegadores o un manejo de imágenes responsivas sería de gran ayuda".
  • "Inhabilita la "reproducción automática" de GIFs recuperando solo el primer fotograma".

CDN y servicios de imágenes

  • “Google debería proporcionar una CDN gratuita como Cloudflare”.
  • “Quizás sería bueno tener más herramientas para configurar la escalamiento dinámico y las CDN con diferentes proveedores”.
  • "Una sola imagen de gran tamaño y sobrecomprimida es una solución muy decente sin costo de producción adicional. Necesitas imágenes de alrededor de 1,000 píxeles de ancho para dispositivos móviles (ancho de renderización de 500 px), que también es el tamaño que necesitas para pantallas grandes o de computadoras de escritorio que no sean Retina. Creo que las CDN que cambian el tamaño de las imágenes son una solución muy mala, aunque las he usado en el pasado. El CMS debe controlar el cambio de tamaño y, si es demasiado complejo de configurar, una sola solución es un buen compromiso (por ahora).
  • "CloudFlare ajusta automáticamente el tamaño de nuestras imágenes para que coincidan mejor con la pantalla del usuario. De esta manera, podemos ahorrar tiempo de carga porque las imágenes se cargan en relación con la pantalla del usuario. Por ejemplo, si un usuario está en un teléfono, no se cargará en un fondo del tamaño de una computadora de escritorio".
  • "Cloudflare hace esto en segundo plano sin que tengamos que hacer nada, excepto marcar una casilla en nuestro panel de configuración".
  • “Solo para reiterar, la única razón por la que puedo usar srcset, etc., es la facilidad de Cloudinary. Sin embargo, Cloudinary se vuelve costoso, muy rápido. Esto parece un gran problema en la experiencia de desarrollo".
  • "Necesitamos una forma de recortar imágenes automáticamente de forma inteligente y sencilla para que puedan funcionar con diferentes relaciones de aspecto en diferentes contextos".
  • "También uso imágenes de otros proveedores, como Unsplash, en los que hay mucho menos control de la resolución, la calidad y la compresión".

CMS, plataforma y framework

  • "Aún me cuesta descubrir cuál es la mejor manera de usar imágenes cuando creo un sitio con un CMS. Los autores suelen configurar imágenes con diferentes dimensiones y esperan que no se reduzcan ni se ajusten. No sé si está bien establecer un ancho o una altura máximos en las imágenes".
  • “He estado usando gatsby-image en los últimos proyectos y nunca miré atrás”.
  • "Las imágenes suelen ser la parte más difícil, ya que el usuario final las coloca en el CMS. Pueden usar cualquier tamaño o formato, a veces la imagen original en el formato ideal, y las dimensiones no están disponibles".
  • "Las imágenes son difíciles de mantener, ya que nuestro sistema es de autoservicio, por lo que agregar controles es difícil, a menos que todo suceda automáticamente sin afectar la resolución. Además, las imágenes no se ven bien en dispositivos móviles en comparación con computadoras de escritorio".
  • "Ayudo a las personas a optimizar sus sitios (WordPress). Los mayores problemas que he visto con las imágenes son los siguientes: Dependencia de una CDN o complementos para crear WebP. Los desarrolladores de temas deben codificar correctamente srcset/picture. La mayoría de los complementos de carga diferida se cargan lentamente, lo que genera una mala UX. Las imágenes de fondo son difíciles de cargar de forma diferida".

Costo/beneficio

  • “Las prácticas nuevas son eficaces, pero aumentan el tiempo de desarrollo de los sitios”.
  • "La falta de cumplimiento de los nuevos estándares, como srcset y WebP, ha sido lenta para que muchas empresas de Fortune 500 los adopten. Debido a esto, muchas empresas se resistieron al cambio, ya que lo consideraban un costo de desarrollo innecesario para los sitios web actuales. El usuario final (UX) no analiza ni informa ampliamente los aumentos de rendimiento. En todo caso, dificulta un poco más guardar imágenes de la Web".
  • "Es costoso crear y administrar varios tamaños y versiones".
  • "Ocupan mucho espacio en nuestro servidor".

SEO

  • “Es difícil encontrar un equilibrio entre la calidad de imagen aceptable y el tamaño del archivo. Por un lado, quiero una carga rápida para beneficiar el SEO, pero, por otro lado, las imágenes de baja calidad perjudicarán la IU/UX".

El rol de las imágenes en la Web

  • “Hay demasiados en la Web. Deja de usar imágenes inútiles que no mejoran el contenido escrito".
  • "¿Recuerdas cuando la Web no tenía imágenes y compartíamos selfies como ASCII art?"

Herramientas, orientación, estándares y prácticas recomendadas: frustraciones y solicitudes

  • [Un participante escribió una entrada de blog en respuesta a esta encuesta]
  • “Los requisitos parecen cambiar constantemente. Como desarrollador web, es muy frustrante porque lleva tiempo guardar las imágenes en primer lugar. Hacemos la optimización lo mejor que podemos, revisamos el sitio y, meses después, Google decide que las imágenes podrían estar aún más comprimidas o que deben tener un formato diferente. Esto nos impide proporcionarle al cliente la mejor solución posible que dure y, en cambio, crea un esfuerzo costoso para nosotros y para él. Algunos de nuestros clientes de pequeñas empresas simplemente no tienen el presupuesto para que sigamos corrigiendo las imágenes y volviendo a guardarlas para que cumplan con los requisitos. No tenemos el presupuesto para realizar este trabajo dentro de sus paquetes de administración. Escribir el código para llamar a diferentes tamaños de imagen para diferentes dispositivos también lleva tiempo. Sería genial crear un sistema para guardar imágenes que sean coherentes durante un período más largo".
  • “Sí, creo que no entendiste bien el parámetro "Asegúrate de que la cantidad de solicitudes y los tamaños de transferencia sean reducidos" en Lighthouse. Si un sitio se entrega a través de HTTP1.x, por supuesto, pero si un sitio se entrega a través de HTTP2, la cantidad de solicitudes es menos importante o ni siquiera es un problema si proviene del mismo nombre de host. Tengo un sitio web ligero, pero cargo 30 archivos WebP pequeños de aproximadamente 35 solicitudes en total a través de HTTP2 en el mismo nombre de host. Lighthouse lo marca como un problema de "Mantener los recuentos de solicitudes bajos y los tamaños de archivo pequeños", mientras que es muy rápido y, debido a HTTP2 en el mismo nombre de host, la cantidad de solicitudes no es un problema. Y sí, los archivos ya son pequeños (la mayoría entre 1 KB y 2 KB o menos). Podría cargar un sprite, pero luego se debe realizar más procesamiento de CSS. Por lo tanto, actualiza el informe "Asegúrate de que la cantidad de solicitudes y los tamaños de archivo sean reducidos" en Lighthouse para tener en cuenta HTTP2 en el mismo nombre de host".
  • "Para las personas, es difícil recordar comprimir sus imágenes".
  • "El comportamiento entre navegadores sigue siendo impredecible, por lo que las soluciones más simples suelen ser las más seguras".