Echando un vistazo al estado de las imágenes progresivas y la percepción del usuario
Publicado: 2022-03-10“Imágenes progresivas” es un tema candente en estos días. A menudo nos encontramos con artículos que explican técnicas sobre cómo evitar mostrar un espacio vacío donde se cargará una imagen. Medium y Facebook son ejemplos de sitios web y aplicaciones móviles que aplican este patrón.
Recientemente escribí sobre diferentes formas de usar SVG como marcadores de posición, y el Calendario de rendimiento de PerfPlanet de este año incluyó dos publicaciones que describen más detalladamente SQIP, una técnica basada en SVG borrosos: Carga progresiva de imágenes usando Intersection Observer y SQIP y SQIP: vectores vagos para vistas previas de rendimiento.
Cuando documenté por primera vez la técnica de carga de imágenes de Medium, lo que más me interesaba era aplicar ingeniería inversa a su técnica. Había visto el efecto de navegar por Medium en una conexión lenta durante el vuelo. Pensé que era una buena idea renderizar una imagen pequeña antes, con carga diferida y con la transición a la versión final.
Suponemos que estas técnicas mejoran el rendimiento percibido de un usuario . La renderización rápida supera a la renderización lenta. Poner algo en la pantalla del usuario antes de tiempo, incluso si no es el contenido final.
¿Estamos seguros de esto?
Revisando algunos comentarios en Reddit, encontré muchas opiniones perspicaces (y negativas). Aquí hay dos de ellos:
“Odio los sitios web que muestran una versión borrosa de una imagen antes de que se cargue la última. Juega con mis ojos. Tengo que apartar la mirada y mirar para ver si está hecho antes de poder seguir leyendo. Desearía que hubiera una forma de desactivar esta función".
— rocky1138, Noticias de piratas informáticos
“¿Cómo ha llegado la gente a la conclusión de que mostrar una versión con poca información de la imagen que se va a cargar como marcador de posición da como resultado una carga percibida más rápida? Para mí, todos estos efectos parecen basura y distracciones, sin ningún beneficio en absoluto, ciertamente no la percepción de la velocidad. No es como si alguna vez pudiera entender qué es realmente la imagen antes de que esté completamente cargada de todos modos, con nuestro marcador de posición sin lujos".
— dwb, Noticias de piratas informáticos
Tratando de encontrar estudios sobre la percepción de los usuarios
Quería encontrar alguna investigación científica que pudiera respaldar que estas técnicas para cargar imágenes eran (o no) beneficiosas. Esto resultó ser un desafío. No pude encontrar ningún estudio que demuestre que mostrar algo como una miniatura borrosa antes de que se cargue la imagen mejore la percepción del usuario. Luego pensé en los JPEG progresivos.
Volver a la base: JPEG progresivos
En cierto modo, hemos tenido una "técnica de carga progresiva de imágenes" similar respaldada en imágenes durante mucho tiempo. JPEG progresivo es un buen ejemplo.
Los JPEG progresivos se han propuesto como una buena práctica para imágenes, especialmente para sitios que se utilizan en redes lentas. Ann Robson escribió una publicación alentando a los JPEG progresivos, ahora hace cinco años, donde resumió por qué eran superiores:
“Los JPEG progresivos son mejores porque son más rápidos. Aparentar ser más rápido es ser más rápido, y la velocidad percibida es más importante que la velocidad real . Incluso si estamos siendo codiciosos con lo que estamos tratando de ofrecer, los archivos JPEG progresivos nos brindan todo lo posible lo antes posible".
Un JPEG progresivo codifica la imagen en varios escaneos. El primer escaneo genera la imagen completa en baja calidad y se refina a medida que se procesan más escaneos. Una alternativa es el modo básico de JPEG en el que la imagen se decodifica de arriba a abajo.
Como nota al margen, la codificación JPEG se puede personalizar utilizando diferentes scripts de escaneo. Esto se puede usar para crear imágenes codificadas en un modo híbrido entre línea de base y progresiva.
Las técnicas progresivas como Blur-up, SQIP se parecen a los JPEG progresivos desde el punto de vista de la percepción del usuario. El navegador muestra primero una imagen de baja calidad y la reemplaza con la imagen final cuando se carga.
Curiosamente, la gran mayoría de las imágenes JPEG utilizan el modo de línea de base. Según algunas fuentes, los JPEG progresivos representan como máximo el 7% de todos los JPEG. Si parece que estamos de acuerdo en que estas técnicas mejoran el rendimiento percibido por el usuario, ¿por qué no se utilizan más los JPEG progresivos que los JPEG básicos?
El estudio
Solo pude encontrar un estudio llamado "Progressive Image Rendering - Good or Evil?", que trató de arrojar algo de luz sobre este tema.
“Cuando, al igual que con el método JPEG progresivo, la reproducción de imágenes es un proceso de dos etapas en el que una imagen inicialmente tosca se enfoca nítidamente, la fluidez cognitiva se inhibe y el cerebro tiene que trabajar un poco más para dar sentido a lo que se muestra. .”
Según el estudio, a los usuarios les cuesta más procesar los JPEG progresivos, aunque a primera vista pensaríamos que la experiencia es mejor.
Recientemente mencioné el estudio en una conversación sobre LQIP (marcadores de posición de imágenes de baja calidad). Pronto, recibí algunas respuestas que cuestionaban el rigor del estudio:
Sin embargo, muchas personas han cuestionado la validez de ese estudio. Es contrario a todo lo que asumimos sobre los beneficios del renderizado progresivo y nadie ha presentado todavía un segundo estudio con hallazgos similares. Necesitamos más datos.
— Tobias Baldauf (@tbaldauf) 9 de diciembre de 2017
El estudio fue muy limitado y polémico. Los datos a gran escala para probar o refutar son esenciales para sacar conclusiones.
— Yoav Weiss (@yoavweiss) 9 de diciembre de 2017
Hasta el momento, contamos con un solo estudio que es recibido con escepticismo. ¿Qué más tenemos? ¿Podemos usar las herramientas existentes para medir el desempeño percibido como un proxy?
Medición del tiempo de carga percibido
Imagine estas dos tiras de película hipotéticas grabadas desde un sitio:
El acuerdo general es que el usuario percibirá que la Versión B se carga más rápido que la Versión A. Esto se debe a que partes de la página se renderizaron antes que en la Versión A.
En cierto modo, la situación es similar a la de las imágenes progresivas, pero a mayor escala. Contenido parcial lo antes posible, aunque no sea el definitivo.
Un tiempo de carga de página de 1,2 segundos nos cuenta parte de la historia, pero no describe lo que ve el usuario durante ese tiempo. En estos días usamos métricas como el índice de velocidad para evaluar qué tan rápido carga una página. Speed Index mide el área de la página que no se completa visualmente. Esto se hace en varias capturas de pantalla tomadas a intervalos. Cuanto menor sea el número, mejor.
Si pensamos en las técnicas de carga progresiva de imágenes, ¿cómo variará el índice de velocidad a medida que se carga la imagen? ¿Se considerará esa área "completada visualmente" si usamos un marcador de posición de baja calidad?
Inicialmente, Speed Index medía el progreso comparando la distancia de los histogramas, uno por cada color primario (rojo, verde, azul). Esto se llama diferencia de histograma medio. El objetivo es evitar que cambios como los reflujos, en los que todos los elementos de la página se desplazan unos pocos píxeles, tengan un gran impacto en el cálculo. Para obtener más información sobre el algoritmo, lea la sección Medición del progreso visual del documento Índice de velocidad.
Decidí probar Webpagetest en una página que muestra marcadores de posición de baja calidad (ver informe en WebPageTest):
Podemos notar que entre el segundo 8 y el 10 se carga la imagen. El marcador de posición borroso aumenta el porcentaje de integridad visual del 75 % al 83 %. Cargar la imagen final la lleva del 83% al 93%.
Vemos que un marcador de posición contribuye a la integridad visual de la página según lo medido por el índice de velocidad. También podemos observar que el marcador de posición no cuenta como un área completamente visualmente completa.
Speed Index no es la única métrica que podemos usar para obtener una medida de qué tan rápido se procesa nuestra página. Chrome Developer Tools incluye una opción para realizar una auditoría de rendimiento. Vaya a Audits → Perform an audit → Check 'Performance' → Run audit .
Ejecutar una auditoría genera un informe como este:
Una de las métricas informadas es el "Índice de velocidad perceptual". En esta corrida el valor es 4,245 . Pero, ¿qué significa exactamente este término? ¿Es lo mismo que el "Índice de velocidad" de Webpagetest?
El enfoque de Speed Index para medir la similitud de píxeles, también llamado "diferencia de histograma medio", tiene algunos inconvenientes. El MHD no captura la percepción visual de la forma, el color o la similitud de los objetos.
En la mayoría de los casos, esto no supondrá una gran diferencia al ejecutar una evaluación de integridad visual. En la práctica, tanto el Índice de Velocidad como el Índice de Velocidad Perceptual tienen una alta correlación:
“En estudios empíricos a gran escala que llevamos a cabo (utilizando más de 500 videos de la página web móvil superior de Alexa recopilados a través de WebPagetest), encontramos que SI y PSI están correlacionados linealmente (en 0.91, para ser precisos)”. — Índice de velocidad perceptual (PSI) para medir el rendimiento web de la mitad superior de la página
Índice de velocidad perceptiva
Según la documentación de Google Lighthouse, el índice de velocidad perceptual se calcula utilizando un módulo de nodo llamado Speedline. Este paquete calcula el índice de velocidad perceptual, basado en el mismo principio que el índice de velocidad original, pero calcula la progresión visual entre cuadros utilizando el SSIM en lugar de la distancia del histograma .
SSIM (similitud estructural) se utiliza para medir la similitud entre dos imágenes. Este método trata de modelar cómo los seres humanos perciben las imágenes y captura la forma, el color y la similitud de los objetos. SSIM tiene otras aplicaciones interesantes: una de ellas es optimizar la configuración de compresión de imágenes, como cjpeg-dssim, que elige el nivel de compresión JPEG más alto y genera una imagen con un SSIM lo suficientemente cercano.
A continuación puede ver las puntuaciones de Image SSIM JS para imágenes SVG creadas con Primitive. Cuantas más formas usemos, más cerca estará de la imagen original (SSIM = 1).
Las alternativas más recientes a SSIM son butteraugli (utilizado por Guetzli, el codificador JPEG guiado por percepción de Google) y SSIMULACRA (utilizado por Cloudinary).
Conclusión
No existe una forma sencilla de sintetizar la percepción de un usuario de una imagen que se carga a lo largo del tiempo. Nos impulsa la corazonada de que mostrar antes es mejor, incluso si no es el contenido final, aunque algunos usuarios no estarán de acuerdo.
Como desarrolladores, necesitamos medir el rendimiento . Es la única forma en que podemos establecer objetivos para mejorarlo y saber cuándo no cumplimos con un presupuesto de rendimiento. La ventaja de apostar por la carga progresiva de imágenes es que podemos medirla con herramientas que se basan en la percepción del usuario. Nos dan una puntuación, son reproducibles y escalables. Se adaptan a nuestro flujo de trabajo y herramientas, y están aquí para quedarse.
Como desarrolladores web, deberíamos preocuparnos más por la experiencia de carga de los sitios web que construimos. Es genial que ahora tengamos herramientas como WebPageTest y Lighthouse que pueden ayudarnos a medir fácilmente el efecto del uso de técnicas de carga progresiva de imágenes. ¡No más excusas!