Smashing Podcast Episodio 39 con Addy Osmani: Optimización de imágenes

Este episodio ha sido amablemente apoyado por nuestros queridos amigos de Storyblok, quienes ayudan a las personas a brindar experiencias de contenido poderosas en cualquier plataforma: sitios web corporativos, sitios de comercio electrónico, aplicaciones móviles y pantallas. ¡Gracias!

En el episodio de hoy de Smashing Podcast, hablamos sobre la optimización de imágenes. ¿Qué pasos debemos seguir para obtener imágenes de alto rendimiento en 2021? Hablé con la experta Addy Osmani para averiguarlo.

Mostrar notas

• “Optimización de imágenes”, Addy Osmani
• Adi en Twitter
• Sitio web personal de Addy

Actualización semanal

• Conozca :has, un selector principal de CSS nativo (y más)
  escrito por Adrián Bece
• Tres herramientas de auditoría front-end que descubrí recientemente
  escrito por Stefan Judis
• Útiles kits de inicio y repetitivos de front-end
  escrito por Cosima Mielke
• Diseño web bien hecho: hacer uso del audio
  escrito por Frederick O'Brien
• Cuando CSS no es suficiente: requisitos de JavaScript para componentes accesibles
  escrito por Stephanie Eckles

Transcripción

Drew McLellan: es un gerente de ingeniería que trabaja en Google Chrome, donde su equipo se enfoca en la velocidad, ayudando a mantener la velocidad de la web. Dedicado a la comunidad de código abierto, sus contribuciones anteriores incluyen Lighthouse, Workbox, Yeoman, Critical y NVC. Así que sabemos que conoce bien la optimización del rendimiento web. Pero, ¿sabías que quiere ganar el Oscar a la mejor actriz en un papel secundario debido a un error administrativo? Mis grandes amigos, denle la bienvenida a Addy Osmani. Hola, Addy. ¿Cómo estás?

Addy Osmani: Estoy genial.

Drew McLellan: Es bueno escuchar eso. Quería hablarles hoy sobre las imágenes en la web. Es un área en la que ha habido una sorprendente cantidad de cambios e innovaciones en los últimos años, y acabas de escribir un libro muy completo sobre la optimización de imágenes para Smashing. ¿Cuál fue la motivación para pensar en ese momento: “Ahora es el momento de escribir un libro sobre optimización de imágenes?”

Addy Osmani: Esa es una gran pregunta. Creo que sabemos que las imágenes han sido una parte clave de la web durante décadas y que nuestros cerebros pueden interpretar imágenes mucho más rápido que los mensajes de texto. Pero este tema general es uno que continúa volviéndose más y más interesante y más matizado con el tiempo. Y siempre le digo a la gente que este es probablemente, creo, mi tercer o cuarto libro. Nunca me propuse intencionalmente escribir un libro.

Addy Osmani: Empecé este libro escribiendo un artículo sobre optimización de imágenes y luego, con el tiempo, descubrí que accidentalmente había escrito un libro completo sobre el tema. Estuvimos trabajando en este proyecto durante unos dos años. E incluso en ese momento, la industria ha estado evolucionando, los navegadores y las herramientas en torno a las imágenes y los formatos de imagen han estado evolucionando.

Addy Osmani: Así que escribí este libro porque me resultó difícil estar al tanto de todos estos cambios. Y pensé: "Voy a ser un buen ciudadano de la web e intentaré registrar todo lo que he aprendido en un solo lugar para que todos los demás puedan aprovecharlo".

Drew McLellan: Es una de esas áreas, creo, con mucha optimización del rendimiento en el navegador, es un panorama que cambia rápidamente, ¿no es así? Cuando una técnica que ha aprendido como actual y como la mejor práctica, ocurre un cambio de tecnología, y luego descubre que en realidad es un anti-patrón y no debería estar haciéndolo. Y tratar de mantener su conocimiento y asegurarse de que está leyendo los artículos correctos y aprendiendo las cosas correctas y no está leyendo algo de hace dos años es bastante difícil.

Drew McLellan: Tener todo recopilado en un libro bien investigado de una fuente autorizada es realmente tremendo.

Addy Osmani: Sí. Incluso desde la perspectiva de un autor, una de las cosas más interesantes y quizás una de las más estresantes para nuestro equipo editorial fue que entregaba un capítulo y decía que estaba terminado. Y luego, dos semanas más tarde, algo cambiaría en un navegador y diría: “Oh, espera. Tengo que hacer otro cambio de última hora”.

Addy Osmani: Pero el panorama de la imagen ha evolucionado bastante, incluso en el último año. Hemos visto que la compatibilidad con WebP finalmente cruza la línea de meta en la mayoría de los navegadores modernos. El soporte de imágenes AVIF está en Chrome, llegando a Firefox, JPEG XL, carga diferida. Y en general, hemos visto mejoras en la forma en que puede usar imágenes en la web de manera bastante concreta en los navegadores. Pero de nuevo, mucho para que la gente se mantenga al tanto.

Drew McLellan: Algunas personas pueden ver el tema de la optimización de imágenes como un tema bastante serio. Todos hemos aprendido, en algún momento de nuestras carreras, cómo exportar para web desde nuestro software de gráficos. Y algunos de nosotros que podríamos tener el hábito de tomar esas imágenes exportadas y ejecutarlas a través de algo como ImageOptim.

Drew McLellan: Entonces, podríamos saber que debemos elegir un JPEG cuando es una imagen fotográfica y un PNG cuando es una imagen basada en gráficos y pensar que, “Está bien, eso es todo. Conozco la optimización de imágenes, ya terminé”. Pero en realidad, esas cosas son solo apuestas en la mesa, ¿no es así, en este momento?

Addy Osmani: Sí, lo son. Creo que nuestra capacidad para mostrar imágenes más detalladas y nítidas incluso en un contexto diferente, dependiendo de si te preocupas por la dirección de arte o no, ha evolucionado con el tiempo. Creo que la necesidad de descubrir cómo puede hacer que esas imágenes se vean tan hermosas como se esperaba para sus usuarios finales, teniendo en cuenta su entorno, las limitaciones de su dispositivo, las limitaciones de su red es un problema difícil y algo que mucha gente aún conoce. luchar con.

Addy Osmani: Entonces, cuando se trata de pensar en imágenes y obtener una visión un poco más refinada de esto más allá de simplemente, "Oye, usemos un JPEG" o "Usemos un PNG", creo que hay algunas dimensiones en esto que valen la pena. teniendo en cuenta. El primero es simplemente compresión en general. Mencionaste ImageOptim, y muchos de nosotros estamos acostumbrados a simplemente arrastrar una imagen a un lugar y obtener algo más pequeño de la parte posterior.

Addy Osmani: Ahora, cuando se trata de compresión, generalmente hablamos de diferentes códecs. Y los códecs son una tecnología de compresión que generalmente tiene un componente codificador para codificar archivos y un componente decodificador para decodificarlos y descomprimirlos. Y cuando llega a decidir si está usando algo, generalmente necesita pensar si las fotos o las imágenes que está usando están bien para que las acerque usando un enfoque de compresión con pérdida o un enfoque sin pérdida.

Addy Osmani: En caso de que la gente no esté tan familiarizada con esos conceptos, un enfoque sin pérdidas es aquel en el que se reproduce exactamente el mismo archivo al final de la descompresión. Así que realmente no estás perdiendo mucho en el camino de la calidad. Lossless es mucho más que poner su imagen a través de una máquina de fax. Obtienes un facsímil del original y no va a ser el archivo original. Puede haber algunos artefactos diferentes en su lugar allí. Puede parecer sutilmente diferente. Pero en términos generales, cuanto más comprima, más calidad perderá.

Addy Osmani: Entonces, con todos estos códecs de imagen modernos, están tratando de ver cuánta calidad se puede exprimir mientras se mantiene un tamaño de archivo relativamente decente, según el caso de uso.

Drew McLellan: Realmente, desde el punto de vista de la tecnología, tiene una imagen de origen y luego tiene el formato de archivo de destino. Pero el proceso de convertir uno en el otro está abierto a debate. Siempre que tenga un archivo conforme, la forma de hacerlo depende de un códec que puede tener muchas implementaciones diferentes, y algunas serán mejores que otras.

Addy Osmani: Absolutamente. Absolutamente. Y creo que, nuevamente, volviendo a donde comenzamos con JPEG y PNG, la gente puede saber que JPEG se creó para una compresión con pérdida de fotos. Por lo general, obtiene un archivo más pequeño de la parte posterior y, a veces, puede tener diferentes artefactos de bandas. PNG se creó originalmente para una compresión sin pérdidas, funciona bastante bien en imágenes no fotográficas.

Addy Osmani: Pero desde entonces, las cosas han evolucionado. Alrededor de 2010, comenzamos a obtener soporte para WebP, que se suponía que reemplazaría a JPEG y PNG y los superaría un poco en compresión. Pero la cantidad de formatos de imagen y opciones sobre la mesa se ha disparado desde entonces. Creo que, en general, las cosas van en una buena dirección, especialmente con formatos modernos como AVIF y JPEG XL. Pero nos ha tomado un tiempo llegar aquí. Incluso conseguir la compatibilidad con WebP en todos los navegadores llevó bastante tiempo.

Addy Osmani: Y creo que, en última instancia, lo que influyó fue asegurarse de que los desarrolladores lo hayan estado solicitando, hayan tenido el apetito de poder obtener una mejor compresión de estos formatos modernos y el deseo de tener una buena compatibilidad entre navegadores. para estas cosas también.

Drew McLellan: Sí. WebP me parece realmente interesante, porque además de tener disponible compresión sin pérdida y con pérdida dentro del formato, obviamente tenemos como resultado un tamaño de archivo mucho más reducido. Y hay un buen soporte de navegador, y vemos la adopción de grandes empresas como Google y Netflix y varias grandes empresas.

Drew McLellan: Pero mi percepción en la industria es que no vemos el mismo tipo de aceptación a nivel de base. ¿WebP sigue esperando que llegue su día?

Addy Osmani: Creo que diría que WebP está llegando. Mucha gente ha estado esperando que se materialice la compatibilidad con Safari y WebKit, y finalmente la tenemos. Pero cuando pensamos en nuevos formatos de imagen, es muy importante que entendamos qué significa realmente soporte. Hay soporte de navegador para decodificar esas imágenes. También necesitamos un soporte de herramientas realmente bueno para que, ya sea que esté en un entorno de nodo, CDN de imagen, si está en un CMS, tenga la capacidad de usar esos formatos de imagen.

Addy Osmani: Puedo recordar hace muchos años cuando salió WebP por primera vez. Los primeros usuarios tenían el problema de guardar el archivo WebP en el escritorio y, de repente, “Oh, espera. ¿Necesito arrastrar esto a mi navegador para verlo?” o “Si mis usuarios están descargando el WebP, ¿se quedarán atascados y se preguntarán qué está pasando?”.

Addy Osmani: Creo que es muy importante asegurarse de que haya un soporte bastante holístico para el formato de imagen tanto a nivel de sistema operativo como en otro contexto para que un formato de imagen despegue. También es importante que las personas que ofrecen imágenes piensen un poco en estos casos de uso para que, si estoy guardando o descargando un archivo, intente ponerlo en un formato portátil que la gente pueda compartir fácilmente. Y creo que aquí es donde, al menos en iOS, iOS tiene soporte para una caminata y un guión. Y convertir cosas a archivos JPEG cuando sea necesario permite que las personas las compartan.

Addy Osmani: Entonces, creo que es importante pensar en esos tipos de casos de uso en los que podemos asegurarnos de que los usuarios no pierdan mientras les brindamos una mejor compresión.

Drew McLellan: Tengo un servicio para compartir diapositivas que administro y que, como pueden imaginar, maneja cientos de miles de imágenes. Y cuando estuve mirando WebP, y esto fue probablemente hace unos tres años, buscaba principalmente una forma de reducir los costos de ancho de banda de CDN, porque si estás sirviendo un archivo más pequeño, se te cobra menos por servirlo. Pero aunque todavía necesitaba una imagen de respaldo completo, un formato de imagen heredado también, mis cálculos mostraron que el costo de almacenar otro conjunto de imágenes superaba los beneficios de servir un archivo más pequeño. Así que aquí estamos en 2021. ¿Es una decisión que debería reconsiderar en este momento?

Addy Osmani: Creo que esa es una consideración muy importante. A veces, cuando hablamos de cómo debería abordar su estrategia de imagen, es muy fácil dar a las personas una respuesta de alto nivel como: “Oye, sí. Solo genere cinco formatos diferentes, y eso se escalará infinitamente”. Y no siempre es así.

Addy Osmani: Creo que cuando tiene que tener en cuenta el almacenamiento, a veces vale la pena tener en cuenta cuál es el mejor denominador común para servir a sus usuarios. En estos días, en realidad diría que vale la pena considerar a WebP como ese denominador común. Para las personas que han estado acostumbradas a usar la etiqueta de imagen para servir condicionalmente diferentes formatos a las personas, normalmente usaría un JPEG como su principal alternativa. Tal vez esté bien en estos días usar WebP como su respaldo para la mayoría de los usuarios, a menos que haya personas que usen navegadores muy, muy antiguos. Y creo que estamos viendo mucho menos de eso en estos días. Pero definitivamente tienes algo de flexibilidad allí.

Addy Osmani: Ahora, si estás tratando de mirar hacia el futuro, te diría que elijas un formato que creas que funciona muy bien. Si puede abordar el almacenamiento de una manera que se adapte a sus necesidades y sea escalable, lo que yo diría que la gente debería hacer es considerar JPEG XL. Todavía no se envía técnicamente en un navegador. Cuando lo haga, JPEG XL debería ser una excelente opción para muchas fotos en casos de uso con pérdida o sin pérdida o también para casos de uso sin fotografías. Y probablemente será mucho mejor que WebP V1. Así que ese es un lugar.

Addy Osmani: Creo que AVIF probablemente será mejor si necesita velocidades de bits realmente bajas. Tal vez te importe mucho el ancho de banda. Tal vez te importe un poco menos la fidelidad de la imagen. Y a esas tasas de bits, podría imaginarlo con un aspecto más nítido que algunas de las alternativas. Y hasta que tengamos JPEG XL, intentaría echar un vistazo a sus análisis y comprender si es posible que sirvan AVIF. De lo contrario, me centraría en ese WebP. Si fuera analítico, supongo que a la mayoría de las personas se les puede servir WebP y le importa un poco menos la amplia gama o las superposiciones de texto, lugares donde el muestreo de cromosomas puede no ser perfecto en WebP. Eso es sin duda algo que vale la pena tener en cuenta.

Addy Osmani: Así que trataría de tener en cuenta que no va a haber una talla única para todos. Personalmente, en estos días, me preocupo un poco menos por los costos de almacenamiento, salida y ancho de banda, solo porque uso una imagen CDN. Y estoy feliz de decir que uso Cloudinary personalmente. Usamos muchos CDN de imágenes diferentes en donde trabajo. Pero descubrí que no tenía que preocuparme tanto por los costos de mantenimiento de lidiar con canalizaciones de imágenes, lidiar con cómo voy a brindar soporte como, "Oh, hey, aquí hay otro formato de imagen o nuevos tipos de respaldos o nuevas API web ”, ese ha sido un buen beneficio de invertir en algo que simplemente se ocupa de mí.

Addy Osmani: Y luego, el costo total de mis casos de uso ha estado bien. Pero me imagino totalmente que si está ejecutando un servicio de diapositivas a esa escala, esa podría no ser necesariamente una opción también.

Drew McLellan: Sí. Así que quiero volver a algunos de estos próximos formatos futuros. Pero creo que vale la pena profundizar en eso, porque con cualquier tipo de herramienta de rendimiento, Lighthouse o WebPageTests, si cualquiera de nosotros ejecuta nuestros sitios a través de él, una de las cosas clave que sugerirá es que usamos un CDN para imágenes. Y eso es algo muy realista para empresas muy grandes. ¿Es realista y está al alcance de las personas que crean sitios web y aplicaciones más pequeños, o en realidad es tan fácil de hacer como parece?

Addy Osmani: Creo que la pregunta que la gente debería hacer es: "¿Para qué estás usando imágenes?" Si solo tiene unas pocas imágenes, si está creando un blog y las imágenes que está agregando son relativamente simples, no tiene cientos y cientos o miles de miles de imágenes, es posible que esté de acuerdo con solo acercarse a este en el momento de la compilación, de forma muy estática, donde instala un par de paquetes NPM. Tal vez solo estés usando Sharp. Y eso te cuida en su mayor parte.

Addy Osmani: Existen herramientas que pueden ayudarlo a generar múltiples formatos. Aumenta un poco el tiempo de compilación, pero en realidad podría estar bien para muchas personas. Y luego, para las personas que quieren poder aprovechar múltiples

Addy Osmani: Y luego, para las personas que quieren poder aprovechar múltiples formatos, no quieren lidiar con tantas minucias de herramientas y quieren poder obtener una imagen o historia receptiva realmente rica en su lugar, yo diría probar una imagen CDN. Personalmente, era bastante reticente a usarlo para proyectos personales por cuestiones de costos al principio, y luego, con el tiempo, cuando eché un vistazo a mi facturación, me di cuenta de que me estaba ahorrando tiempo que, de lo contrario, estaría invirtiendo en abordar estos problemas yo mismo. No sé cuánto ha tenido que escribir scripts personalizados para manejar sus imágenes en el pasado, pero me di cuenta de que si puedo ahorrarme al menos un par de días de depuración a través de estos diferentes paquetes npm al mes, entonces los costos tipo de cuidar el tiempo que estoy ahorrando y por lo que está bien.

Addy Osmani: Pero puede ser algo en lo que si está escalando a cientos de miles o millones de imágenes y eso no es algo que necesariamente cubra sus ingresos o no sea algo por lo que esté preparado para pagar, necesita pensar. estrategias alternativas. Y creo que tenemos suerte de tener suficiente flexibilidad con las herramientas que tenemos disponibles hoy para poder ir en cualquiera de esas direcciones, donde hacemos algo un poco más personalizado, lo abordamos nosotros mismos o rodamos. nuestra propia imagen CDN o invertimos en algo un poco más comercial. Y estamos en un lugar donde diría que para algunos casos de uso, sí, puedes usar una imagen CDN y es asequible.

Drew McLellan: Supongo que uno de los principios rectores siempre es ser ágil y estar preparado para el cambio. Y puede comenzar usando una CDN de imágenes para convertir dinámicamente sus imágenes según las solicite, y si eso llega a un punto en el que no es sostenible en términos de costos, puede buscar otra solución y tener su base de código en un estado donde va a ser fácil sustituir una solución por otra. Creo que, en general, y en cualquier lugar en el que confíe en un servicio de terceros, ese es un buen principio, ¿no es así? Entonces, estos próximos formatos de imagen, mencionó JPEG XL. ¿Qué es JPEG XL? ¿De dónde viene? ¿Y qué hace por nosotros?

Addy Osmani: Esa es una excelente pregunta. Entonces, JPEG XL es un formato de imagen de próxima generación, se supone que es de propósito general y es un códec del comité JPEG. Comenzó con algunas raíces en el formato pic de Google y luego en el formato FUIF de Cloudinary. Ha habido muchos formatos a lo largo de los años que han sido subsumidos por este esfuerzo, pero se ha convertido en mucho más que la simple suma de sus partes individuales y algunos de los beneficios de JPEG XL son que es excelente para la alta fidelidad. imágenes, realmente bueno para sin pérdidas, tiene soporte para decodificación progresiva, transcodificación de JPEG sin pérdidas, y también es un poco complicado y libre de regalías, lo que definitivamente es un beneficio. Creo que JPEG XL podría ser un candidato muy fuerte. Antes hablábamos de que, si tuvieras que elegir uno, ¿cuál usarías? Y creo que el JPEG XL tiene potencial para ser ese.

Addy Osmani: Tampoco quiero prometer demasiado, todavía estamos en las primeras etapas con la compatibilidad con navegadores. Entonces, creo que realmente deberíamos esperar y ver, experimentar y evaluar qué tan bien se alinea en la práctica y cumple con las expectativas de las personas, pero veo mucho potencial con JPEG XL tanto para casos con pérdida como sin pérdida. En este momento, creo que Chrome es probablemente el más avanzado en términos de soporte, pero también he visto definitivamente interés del lado de Mozilla y otros navegadores en esto, así que estoy entusiasmado con el futuro con JPEG XL. Y si tuviéramos que decir, ¿cuál es el plazo aún más corto de interés para la gente? Por supuesto, también está AVIF.

Drew McLellan: Cuéntanos sobre AVIF, este es otro con el que no estoy familiarizado.

Addy Osmani: Está bien. Así que mencionamos un poco antes que AVIF podría ser un mejor candidato si necesita ir a tasas de bits bajas y le importa más el ancho de banda que la fidelidad de la imagen. Como principio general, AVIF realmente toma la delantera en compresión de baja fidelidad y alto atractivo. Y JPEG XL, debería sobresalir en fidelidad media a alta, pero son formatos ligeramente diferentes por derecho propio. Estamos en un lugar donde AVIF tiene un soporte de navegador cada vez más bueno, pero permítanme dar un paso atrás y hablar un poco más sobre el formato. Por lo tanto, AVIF en sí se basa en el códec de video AV1, que ha sido estandarizado por Alliance for Open Media, e intenta que las personas obtengan ganancias de compresión significativas sobre JPEG, sobre WebP, de las que hablábamos antes. Y aunque los ahorros exactos que puede obtener de AVIF dependerán del contenido y de sus objetivos de calidad, hemos visto muchos casos en los que puede ofrecer más del 50 % de ahorro en comparación con JPEG.

Addy Osmani: Tiene muchas funciones buenas, es capaz de brindarle soporte de contenedor para nuevas funciones como alto rango dinámico y amplias gamas de colores, síntesis de grano de película. Y nuevamente, similar a hablar de estar orientado hacia el futuro, una de las cosas buenas de la etiqueta de la imagen es que podría servir a los usuarios archivos AVIF en este momento y seguirá recurriendo a su WebP o su JPEG en los casos en que no sea necesariamente compatible. . Pero volviendo a tu ejemplo sobre Photoshop Save For Web, podrías tomar un JPEG de 500 kilobytes de tamaño, intentar disparar con una calidad similar a Photoshop Save For Web y con AVIF diría que probablemente puedas llegar a un punto en el que el tamaño del archivo es de aproximadamente 90 kilobytes, 100 kilobytes, lo que significa un gran ahorro sin una pérdida perceptible real en la calidad.

Addy Osmani: Y una de las cosas buenas de eso es que, idealmente, no verás tanta pérdida de textura en ninguna imagen que tenga muchos detalles. Entonces, si tiene fotos de bosques o campamentos o cualquiera de esos tipos de cosas, aún deberían verse realmente ricas con AVIF. Así que estoy bastante entusiasmado con la dirección que tiene AVIF. Creo que necesita un poco más de trabajo en términos de soporte de herramientas. Así que lancé un tweet sobre esto el otro día, tenemos varias opciones para usar AVIF en este momento, para imágenes individuales tenemos Squoosh, squoosh.app, que está escrito por otro equipo en Chrome, así que grita gracias a Surma y Jake por trabajar en Squoosh. Avif.io tiene una serie de buenas opciones para las personas que intentan usar AVIF hoy en día, independientemente de la pila tecnológica en la que se centren, Sharp también es compatible con AVIF.

Addy Osmani: Pero, por lo general, piensas en otros lugares donde tratamos con imágenes, ya sea en Figma, en Sketch, en Photoshop o en otros lugares, y yo diría que todavía tenemos que trabajar un poco en términos de El soporte de AVIF allí, porque debe ser omnipresente para que los desarrolladores y usuarios realmente sientan que aterrizaron y regresaron a casa. Y esa es una de las áreas de enfoque para nosotros con los equipos que trabajan en AVIF en Chrome en este momento, tratando de asegurarnos de que podamos llevar las herramientas a un lugar bastante bueno.

Drew McLellan: Así que ahora tenemos en HTML, el elemento de imagen, que nos da más flexibilidad sobre la etiqueta de imagen tradicional. Aunque la etiqueta de la imagen también ha recorrido un largo camino, ¿no es así? Pero vimos que se agregaba una imagen, fue casi al mismo tiempo que la etiqueta de video nativo, creo que en ese tipo de lote original de cambios HTML5. Y esto nos da la posibilidad de especificar múltiples fuentes, ¿no es así?

Addy Osmani: Sí, así es.

Drew McLellan: Entonces, puede enumerar diferentes formatos de imágenes y el navegador elegirá el que admita, y eso nos permite ser bastante experimentales de inmediato sin tener que preocuparnos demasiado por romper cosas para las personas con navegadores más antiguos.

Addy Osmani: Absolutamente. Creo que ese es uno de los mejores beneficios de usar la etiqueta de imagen fuera de los casos de uso en los que estamos pensando en nuestra dirección, solo poder mostrar a las personas una imagen y hacer que el navegador revise la lista de fuentes potenciales y vea, está bien, bueno, usaré el primero en esa lista que entiendo, de lo contrario, retrocederé, esa es una capacidad realmente poderosa para la gente. Creo que, al mismo tiempo, también escuché a algunas personas expresar cierta preocupación por el hecho de que estamos regenerando grandes cantidades de marcado ahora que estamos tratando de admitir múltiples formatos y se tienen en cuenta diferentes tamaños para esos formatos y de repente se pone un poco voluminoso.

Addy Osmani: Entonces, ¿existen otras formas de abordar esos problemas? No quiero vender demasiado a la gente en CDN de imágenes, quiero que se mantengan solos. Pero este es uno de esos lugares donde una idea llamada negociación de contenido puede ofrecerle un camino interesante. Entonces, hemos hablado un poco sobre la etiqueta de imagen donde tienes que generar un montón de recursos diferentes y decidir el orden de preferencia, correcto, HTML adicional. Con la negociación de contenido, lo que dice es que hagamos todo ese trabajo en el servidor. Entonces, los clientes pueden decirle al servidor qué formatos admite por adelantado a través de la lista de tipos MIME a través del encabezado Aceptar HTTP. Luego, el servidor puede hacer todo el trabajo pesado de generar y administrar los recursos finales y decidir cuáles enviar a los clientes. Y una de las cosas poderosas aquí es que si está usando una CDN de imagen, puede apuntar a un solo recurso.

Addy Osmani: Así que tal vez si tenemos una imagen de cachorro como cachorro.JPEG, podríamos darle a la gente una URL para cachorro.JPEG y si su navegador es compatible con WebP o con AVIF, el servidor puede volverse realmente inteligente al servir a la derecha. imagen a esos usuarios dependiendo de cómo se vea su soporte, pero de lo contrario retroceda sin necesidad de hacer un montón de trabajo adicional usted mismo. Ahora, creo que es una idea poderosa. Hay muchas cosas que puede hacer en el servidor, a veces hablamos sobre cómo no todos tienen acceso a una calidad de red realmente sólida, su tipo de conexión efectiva puede ser muy diferente dependiendo de dónde se encuentre.

Addy Osmani: Incluso viviendo en Silicon Valley, podría estar caminando de una cafetería a un hotel o podría estar en el automóvil y la calidad de mi wifi o mi señal puede no ser tan buena. Así que aquí es donde tiene acceso a otras API, otras ideas como la sugerencia del cliente Save-Data para poder servir a las personas con recursos incluso más pequeños, si el usuario ha optado por el ahorro de datos. Entonces, hay muchas cosas interesantes que podríamos estar haciendo en el lado del servidor y creo que deberíamos seguir impulsando estas ideas de encontrar un buen equilibrio donde las personas que se sienten cómodas con la ruta del mercado tienen toda la flexibilidad para hacerlo. y las personas que quieren una solución un poco más mágica también tienen algunas opciones.

Drew McLellan: El concepto de este tipo de enfoque de ahorro de datos fue algo que aprendí por primera vez en su libro. Quiero decir, profundicemos un poco más en eso porque es bastante interesante. Entonces, estás hablando de que el navegador puede indicar una preferencia por querer recuperar una experiencia de datos reducida porque tal vez está en una conexión medida o tiene poca batería o algo así.

Addy Osmani: Exactamente. Exactamente. He estado viajando en tiempos normales o en tiempos anteriores cuando viajábamos mucho más, he experimentado muchos lugares en el mundo o situaciones en las que la calidad de mi red puede ser muy mala o irregular, y por lo tanto incluso abrir crear una página web puede ser una experiencia frustrante o difícil. Podría estar buscando un menú y si no puedo ver fotos de la hermosa comida que tienen disponible, podría ir a algún lugar donde pueda, o podría, no sé, prepararme algo de comida en su lugar. Pero creo que una de las cosas interesantes sobre el ahorro de datos es que te da una conexión con las preferencias del usuario. Entonces, si como usuario, sé que estoy teniendo problemas con mi conexión de red. Puedo decir: "Está bien, bueno, optaré por el modo de ahorro de datos en mi navegador".

Addy Osmani: Y luego puede usar eso como desarrollador como una señal para decir: "Está bien, bueno, el usuario está un poco limitado, tal vez navegaremos por imágenes mucho más pequeñas o imágenes de una calidad mucho más baja". Pero aún pueden ver algunas imágenes, lo cual es mejor que esperar mucho tiempo para que se les sirva algo mucho más rico. Otros beneficios de este tipo de señales son que puede usarlas para servir medios de forma condicional. Entonces, tal vez haya casos en los que el texto sea lo más importante en esa página, tal vez pueda desactivar esas imágenes si descubre que los usuarios se encuentran en un entorno restringido. Solo dedicaré 30 segundos a esto, pero realmente puedes llevar esta idea al extremo. Algunas de las cosas interesantes que puede hacer con Save-Data son incluso desactivar características muy costosas implementadas en JavaScript.

Addy Osmani: Si tiene ciertos componentes que se consideran un poco más opcionales, tal vez no necesariamente deban enviarse a todos los usuarios si solo mejoran la experiencia. Todavía puede servir a todos una experiencia muy básica, pequeña y rápida, y luego simplemente superponerla con un buen glaseado para las personas que tienen una conexión o un dispositivo más rápido.

Drew McLellan: Potencialmente, supongo que podría tener en cuenta la paginación y podría arrojar 10 resultados en una página en lugar de 100 y ese tipo de cosas también. Así que hay muchas capacidades interesantes allí. Creo que todos estamos algo familiarizados con el frustrante proceso de preparar un nuevo sitio, optimizar todas las imágenes, entregárselo al cliente, darle un CMS para administrar el contenido y descubrir que simplemente reemplazan todo con Imágenes mal optimizadas. Quiero decir, nuevamente, una imagen CDN, supongo, sería una solución muy conveniente para eso, pero ¿hay otras soluciones, hay cosas que el CMS podría estar haciendo en el servidor para ayudar con eso o es una imagen CDN probablemente la ¿camino a seguir?

Addy Osmani: Creo que lo que hemos descubierto después de probablemente al menos seis o siete años de tratar de que todos optimicen sus imágenes es que es un problema difícil en el que algunas personas involucradas en la imagen pueden tener un poco más de conocimientos técnicos y tal vez se sientan cómodos con la configuración. crear sus propias herramientas o ejecutar Lighthouse o probar otras herramientas para saber si hay oportunidades para mejorar. Me encantaría ver a la gente usando constantemente cosas como Lighthouse para detectar si tiene oportunidades de optimizar aún más o mostrar imágenes del tamaño correcto, pero más allá de eso, a veces nos encontramos con casos de uso en los que las personas que cargan imágenes pueden no hacerlo. necesariamente incluso comprender el costo de los recursos que están cargando. Esto es algo con lo que comúnmente nos encontramos, y me disculpo, no voy a llamar demasiado la atención a la gente, pero esto es algo con lo que nos encontramos incluso con el blog de Google.

Addy Osmani: Cada dos semanas en el blog de Google, alguien subirá un GIF animado muy grande de 20 o 30 megabytes. Y no espero que sepan que esa no es una buena idea, están tratando de hacer que el artículo se vea genial, muy atractivo e interactivo, pero esas audiencias no necesariamente van a saber ir y ejecutar herramientas o usar ImageOptim. o usar cualquiera de estas otras herramientas en su lugar y documentarlas para que las revisen es sin duda una opción. Pero poder automatizar el problema, creo que es muy convincente y nos ayuda a llegar consistentemente a un lugar en el que esperamos equilibrar las necesidades de todos nuestros usuarios de CMS, ya sean técnicos o no técnicos. como las necesidades de nuestros usuarios.

Addy Osmani: So I think the image CDNs can definitely play a role in helping out here. Ultimately, the thing that's important is making sure you have a solution in place between people, stakeholders who might be uploading those images, and what gets served down to users. If it's an image CDN, if it's something you've rolled yourself, if it's a built step, just needs to be something in place to make sure that you are not serving down something that's very, very large and inefficient.

Drew McLellan: Talking about animated GIFs, they're surprisingly popular. They're fun, we love them, but they're also huge. And really, it's a case where a file format that was not designed for video is being used for video. Is there a solution to that with any of these image formats? What can we do?

Addy Osmani: Oh, gosh. The history of GIFs is fascinating. We saw a lot of the formats we know and love or have been around for a while were originated in the late '80s to early '90s, and the GIF is one of those. It was created in 1987. I'm about as old as the GIF.

Addy Osmani: As you mentioned, it wasn't originally created necessarily for use case. I think it was Netscape Navigator which in mid '90s maybe added support for looping GIFs and giving us this kind of crazy fun way to do memes and the like, but GIFs have got so many weaknesses. They're kind of limited in many cases to a very finite color palette; 256 colors, in many cases. They're a bitmapped raster format with pixel value stored in image files.

Addy Osmani: They're very inefficient, for a number of reasons. And you mentioned that they're also quite large. I think that we've gotten into this place of thinking that if we want a short segment of video or animation that's going to be looping, the GIF is the thing that we have to use. And that's just not the case.

Addy Osmani: While we do see that there are modern image formats that have support for animation, I think that the most basic thing you can do these days is make sure you're serving a video down instead of a GIF. Muted auto-play videos combined with HD64, HD65, whatever video you're going to use, can be really powerful, and significantly smaller for use cases where you need to be showing a sequence of images.

Addy Osmani: There are options for this. AVIF has got image sequences in there, potentially. Other formats have explored these ideas as well. But I think that one thing you can do is, if you're using GIFs today, or you have users who are slightly less technical who are using GIFs today, try to see if you can give them tools that will allow them to export a video instead, or if your pipeline can take care of that for them, that's even better.

Addy Osmani: I have plenty of conversations with CMS providers where you do see people uploading GIFs. They don't know the difference between a video and a GIF file. But if you can just, whether it's with an image CDN or via some built process, change the file over to a more efficient format, that would be great.

Drew McLellan: We talked briefly about tools like ImageOptim that manage to strip out information from the files to give us the same quality of result with a smaller file size. I'm presuming that's because the file formats that we commonly deal with weren't optimized for delivery over the Web in the first place, so they're doing that step of removing anything that isn't useful for serving on the Web. Do these new formats take that into consideration already? Is something like ImageOptim a tool that just won't be required with these newer formats?

Addy Osmani: I'm anticipating that some of the older formats… Things that have been around for a while, take a while to phase out or to evolve into something else. And so I can see tools like ImageOptim continuing to be useful. Now, what are modern image formats doing that are much better? Well, I would say that they're taking into account quite a few things.

Addy Osmani: They're taking into account, are there aspects of the picture that the human eye can't necessarily make out a difference around? When I'm playing around with different quality settings or different codecs, I'm always looking for that point where if I take the quality down low enough, I'm going to see banding artifacts. I'm going to see lots of weird looking squares around my buildings or the details of my picture.

Addy Osmani: But once those start to disappear, I really need to start zooming in to the image and making comparisons across these different formats. And if users are unlikely to do that, then I think that there are good questions around is that point of quality good enough? I think that modern image formats are pretty good at being able to help you navigate, filtering out some of those details pretty well. Keeping in mind what are the needs of color, because obviously we've got white gamut as a thing right now as well.

Addy Osmani: Some people might be okay with an amount of changing your color palette versus not, depending on the type of images that you have available, but definitely I see modern formats trying to be resilient against things like generational loss as well. Generational loss is this idea that… We mentioned memes earlier. A common problem on the Web today is you'll find a meme, whether it's on Facebook or Instagram or Reddit or wherever else, you'll save it, and maybe you'll share it around with a friend. Maybe they'll upload it somewhere else. And you suddenly have this terrible kind of copy machine or fax effect of the quality of that image getting worse and worse and worse over time.

Addy Osmani: And so when I see something get reshared that I may have seen three months ago, now it might not be really, really bad quality. You can still make out some of the details, but image formats, being able to keep that in mind and work around those types of problems, I think are really interesting.

Addy Osmani: I know that JPEG XL was trying to keep this idea of generational loss in mind as well. So there's plenty of things that modern codecs and formats are trying to do to evolve for our needs, even if they're very meme focused.

Drew McLellan: Let's say you've inherited a project that has all sorts of images on it. What would be the best way to assess the state of that project in terms of image optimization? Are there tools or anything that would help there?

Addy Osmani: I think that it depends on how much time you've got to sink into the problem. There are very basic things people can try doing, like obviously batch converting those images over to more modern formats at the recommended default quality and do an eyeball check on how well they're doing compared to the original.

Addy Osmani: If you're able to invest a little bit more time, there are plenty of tools and techniques like DSSIM and other ways of being able to compare what the perceptual quality differences are between different types of images that have been converted. And you can use that as a kind of data-driven approach to deciding, if I'm going to batch convert all of my old images to WebP, what is the quality setting that I should be relying on? If I'm going to be doing it for AVIF or JPEG XL, what is the quality setting that I should be relying on?

Addy Osmani: I think that there's plenty of tools people have available. It really just depends on your time sink that's possible. Other things that you can do, again, going back to the image CDN aspect, if you don't have a lot of time and you're comfortable with the cost of an image CDN, you can just bulk upload all of those images. And there are CDNs that support this idea of automatic quality setting. I think in Cloudinary it's q_auto, or something like that.

Addy Osmani: But the basic idea there is they will do a scan of the image, try to get a sense of the type of content that's in there, and automatically decide on the right level of quality that you should be using for the images that are getting served down to users. And so you do have some tooling options that are available here, for sure.

Drew McLellan: I mean, you mentioned batch processing of images. Presumably you're into the area of that generational loss that you're talking about, when you do that. When you take an already compressed JPEG and then convert it to a WebP, for example, you risk some loss of quality. Is batch converting a viable strategy or does that generational loss come too much into play if you care about the pristine look of the images?

Addy Osmani: I think it depends on how much you're factoring in your levels of comfort with lossy versus lossless, and your use case. If my use case is that I've inherited a project where the project in question is all of my family's photos from the last 20 years, I may not be very comfortable with there being too much quality loss in those images, and maybe I'm okay with spending a little bit more money on storage if the quality can remain mostly the same, just using a more modern format.

Addy Osmani: If those are images for a product catalog or any commerce site, I think that you do need to keep in mind what your use case is. Are users going to require being able to see these images with a certain level of detail? And if that's the case, you need to make those trade-offs in mind when you're choosing the right format, when you're choosing the right quality.

Addy Osmani: So I think that batch is still okay. To give you a concrete idea of one way of seeing people approach this at scale, sometimes people will take a smaller sample of the images from that big collection that they've inherited, and they'll try out a more serious set of experiments with just that set. And if they're able to land on an approach that works well for the sample, they'll just apply it to the whole batch. And I've seen that work to varying degrees of success.

Drew McLellan: So optimizing file size is just sort of one point on the overall image optimization landscape. And I'd like to get on to talking about what we can do in our browsers to optimize the way the images are used, which we'll do after a quick word from this episode sponsor.

Drew McLellan: So we've optimized and compressed our large files, but now we need to think about a strategy for using those in the browser. The good old faithful image tag has gained some new powers in recent times, hasn't it?

Addy Osmani: Yeah, it has. And maybe it's useful for folks… I know that a lot of people that ask me about images these days also ask me to frame it in terms of metrics and the Core Web Vitals. Would it be useful for me to talk about what the Core Web Vitals are and maybe frame some of those ideas in those current terms?

Drew McLellan: Absolutely, because Core Web Vitals is a sort of initiative from Google, isn't it, that we've seen more recently? We're told that it factors into search ranking potentially at some level. What does Core Web Vitals actually mean for us in terms of images?

Addy Osmani: Great question. As you mentioned, Core Web Vitals is an initiative by Google, and it's all about trying to share unified guidance for quality signals. That can be pretty key to delivering a great user experience on the Web. And it is part of a set of page experience signals Google Search may be evaluating for ranking purposes, but they can impact the Core Web Vitals in a number of ways.

Addy Osmani: Now, before I talk about what those ways are, I should probably say, what are the Core Web Vitals metrics? There's currently three metrics that are in the Core Web Vitals. There's largest contentful paint, there's cumulative layout shift, and there's first input delay. Now, in a lot of modern Web experiences we find that images tend to be one of the largest visible elements on the page. We see a lot of product pages where we have a big image that's the main product item image. We see images in carousels, in stories and in banners.

Addy Osmani: Now, largest contentful paint, or LCP, is a Core Web Vitals metric that tries to measure when the largest contentful element, whether it's an image text or something else, is in a user's viewport, such that we're able to tell when that image becomes visible. And that really allows a browser to determine when the main content of the page has really finished rendering.

Addy Osmani: Entonces, si estoy tratando de ir a un sitio de recetas, podría interesarme cómo se ve esa receta, por lo que nos preocupamos por asegurarnos de que la imagen del gran héroe de la receta sea visible para mí. Ahora, el elemento LCP puede cambiar con el tiempo. Es muy posible que al principio de la carga, lo más grande sea un encabezado, pero a medida que la página continúa cargándose, en realidad podría terminar siendo una imagen mucho más grande o un póster de algún tipo.

Addy Osmani: Entonces, cuando intenta optimizar la pintura con mayor contenido, hay unas cuatro cosas que puede hacer. Lo primero es asegurarse de solicitar su imagen de héroe clave lo antes posible. En general, tenemos una serie de cosas que son importantes en la página. Queremos asegurarnos de que podemos representar el contenido y el diseño de la página principal.

Addy Osmani: Para el diseño, por lo general estamos hablando de CSS. Por lo tanto, es posible que esté utilizando CSS crítico, CSS en línea, en sus páginas, quiera evitar cosas que bloquean el procesamiento, pero luego, cuando se trata de su imagen, idealmente debería solicitar esa imagen temprano. Tal vez eso implique simplemente asegurarse de que el navegador pueda descubrir esa imagen lo antes posible en la página, dado que muchos de nosotros en estos días dependemos de los marcos.

Addy Osmani: Si no está necesariamente usando SSR, renderizado del lado del servidor, si está esperando en el navegador para descubrir algunos de sus paquetes de JavaScript, paquetes para sus componentes, ya sea que tenga un componente para su imagen de héroe o imagen de producto, si el navegador tiene que esperar para buscar, analizar, ejecutar, compilar y ejecutar todos estos archivos diferentes antes de que pueda descubrir la imagen, eso podría significar que su imagen con mayor contenido tardará algún tiempo antes de que pueda ser descubierta.

Addy Osmani: Ahora, si ese es el caso, si se encuentra en un lugar donde la imagen se solicita bastante tarde, puede aprovechar una función del navegador llamada precarga de enlace rel para asegurarse de que el navegador pueda descubrir esa imagen lo antes posible. como sea posible. Ahora, la precarga es una capacidad realmente poderosa. También es uno con el que debes tener mucho cuidado. En estos días, es muy fácil llegar a un lugar donde tal vez escuche que recomendamos precargar su clave.

Addy Osmani: Tal vez escuche que recomendamos precargar su imagen de héroe clave, así como sus scripts clave, así como sus fuentes clave. Y se vuelve así de grande, enorme, tratando de asegurarse de que estás secuenciando las cosas en el orden correcto. Entonces, las imágenes LCP son definitivamente un lugar clave que vale la pena tener en cuenta para esto.

Addy Osmani: La otra cosa, como mencioné cuatro cosas, la otra cosa es asegurarse de que está utilizando un conjunto de fuentes y un formato de imagen moderno y eficiente. Creo que ese conjunto de fuentes es realmente poderoso. También veo que a veces, cuando las personas lo usan, intentan compensar en exceso y tal vez envíen 10 versiones diferentes de imágenes para cada resolución posible. Tendemos a encontrar, al menos en algunas investigaciones, que más allá de tres imágenes, a los usuarios les resulta muy difícil saber cuáles son las diferencias en la calidad de la imagen, la nitidez y el detalle. Por lo tanto, la limitación de DPR, la limitación de la proporción de píxeles del dispositivo, es sin duda una idea que vale la pena tener en cuenta.

Addy Osmani: Y luego, para los formatos de imagen modernos, hablamos de formatos antes, pero considere su WebP, su AVIF, su JPEG XL. Evita desperdiciar píxeles. Es muy importante contar con una buena estrategia para la calidad. Y creo que hay muchos casos en los que incluso la calidad predeterminada a veces puede ser demasiado. Por lo tanto, experimentaría tratando de reducir su tasa de bits, reducir su configuración de calidad y ver hasta dónde puede llevar las cosas para sus usuarios mientras mantiene la nitidez.

Addy Osmani: Y luego, cuando hablamos de carga, una de las otras cosas que la etiqueta de imagen ha evolucionado para admitir en los últimos años es la carga diferida. Entonces, con la carga igual a lazy, ya no necesita usar necesariamente una biblioteca de JavaScript para agregar lazy loading a sus imágenes. Simplemente coloca eso en tu imagen. Y en los navegadores Chrome y Firefox, podrá cargar esas imágenes de forma diferida sin necesidad de utilizar dependencias de terceros. Y eso también es bastante agradable.

Addy Osmani: Entonces, tenemos la carga diferida en su lugar. Tenemos soporte para otras cosas como la decodificación de sincronización, pero voy a mantener las cosas en marcha y hablaré muy rápidamente sobre las otras dos métricas vitales principales.

Drew McLellan: Adelante, sí.

Addy Osmani: Entonces, deshazte de los cambios de diseño. A nadie le gusta que las cosas salten en sus páginas. Siento que una de mis mayores frustraciones es abrir una página web. Paso el dedo sobre un botón en el que quiero hacer clic y, de repente, aparece un montón de anuncios o imágenes sin un conjunto de dimensiones u otras cosas. Y provoca una experiencia realmente desagradable.

Addy Osmani: Entonces, el cambio de diseño acumulativo intenta medir la inestabilidad del contenido. Y muchas veces, las cosas comunes que impulsan los cambios de diseño son imágenes u otros elementos en su página que simplemente no tienen un conjunto de dimensiones. Creo que ese es uno de esos lugares donde a menudo es sencillo para las personas establecer las dimensiones de la imagen. Tal vez no sea algo en lo que históricamente hayamos hecho tanto, pero ciertamente es algo en lo que vale la pena dedicar su tiempo. En herramientas como Lighthouse, intentaremos ayudarlo a recopilar, como ¿cuál es la lista de imágenes en su página que requieren dimensiones? Así que puedes ir y puedes configurarlos.

Drew McLellan: Iba a decir, ese es un punto realmente interesante porque cuando el diseño web receptivo se convirtió en una cosa, todos revisamos nuestros sitios y eliminamos las dimensiones de la imagen porque las herramientas que teníamos a nuestra disposición para hacer ese trabajo requerían que no hiciéramos No tiene atributos de alto y ancho en nuestras imágenes. Pero eso es una mala idea ahora, ¿verdad?

Addy Osmani: Lo viejo es nuevo otra vez. Diría que definitivamente vale la pena establecer dimensiones en sus imágenes. Establezca dimensiones en sus anuncios, sus marcos de ojos, todo lo que sea contenido dinámico que podría cambiar de tamaño vale la pena establecer dimensiones.

Addy Osmani: Y para las personas que están construyendo una experiencia realmente divertida, existe la frase incorrecta, experiencias de diseño realmente divertidas en las que tal vez necesites trabajar más en tarjetas receptivas y cosas por el estilo; Consideraría usar cuadros de relación de aspecto o relación de aspecto CSS para reservar su espacio. Y eso también puede complementar la configuración de las dimensiones en esas imágenes para asegurarse de que las cosas estén lo más arregladas posible cuando intenta evitar los cambios de diseño.

Addy Osmani: Y luego, finalmente, el último Core Web Vital es el primer retraso de entrada. Esto es algo en lo que la gente no necesariamente siempre piensa cuando se trata de imágenes. Entonces, de hecho, es posible que las imágenes bloqueen el ancho de banda y la CPU de un usuario en la carga de la página. Pueden interferir con la forma en que se cargan otros recursos críticos, en particular en conexiones realmente lentas o en dispositivos móviles de gama baja que pueden provocar la saturación del ancho de banda.

Addy Osmani: Entonces, el retraso en la primera entrada es una métrica de Core Web Vital que captura la primera impresión de los usuarios sobre la interactividad y capacidad de respuesta de un sitio. Y así, al reducir el uso de la CPU del subproceso principal, su primer retraso de entrada también puede minimizarse. Entonces, en general, solo evite las imágenes que puedan causar contención en la red. No son bloqueo de renderizado. Pero aún pueden afectar indirectamente el rendimiento de su renderizado.

Drew McLellan: ¿Hay algo que podamos hacer con las imágenes para evitar que se bloqueen? ¿Podemos quitar la carga del navegador en esa fase inicial de alguna manera para permitirnos ser interactivos más rápido?

Addy Osmani: Creo que es cada vez más importante en estos días tener una buena comprensión de la secuencia de imágenes óptima correcta para mostrar algo en la mitad superior de la página. Sé que arriba del pliegue hay un término sobrecargado, pero como en el primer puerto de visualización del usuario. Muy a menudo podemos terminar intentando solicitar una gran cantidad de recursos, algunos de ellos imágenes, que no son realmente necesarios para lo que el usuario va a ver de inmediato. Y esos tienden a ser grandes candidatos para cargar más adelante en el ciclo de vida de la página, grandes cosas para cargar de forma diferida en su lugar. Pero si está solicitando una gran cantidad de imágenes, como una cola completa de cosas desde el principio, eso puede tener un impacto potencial.

Drew McLellan: Sí. Entonces, quiero decir, mencionaste imágenes de carga diferida que históricamente hemos requerido una biblioteca de JavaScript para hacer, lo que tiene sus propios contratiempos, creo, debido a las formas históricas en que los navegadores optimizan la carga de imágenes, donde es casi imposible detenerlos cargando imágenes , a menos que simplemente no le dé una fuente. Y si no le da una fuente y luego intenta corregirlo con JavaScript, si ese JavaScript no se ejecuta, no obtiene imágenes. Entonces, la carga diferida, la carga diferida nativa es una respuesta a todo eso.

Addy Osmani: Sí, absolutamente. Y creo que este es un lugar en el que hemos tratado de mejorar en todos los navegadores, la experiencia nativa de carga diferida durante el último año. Como sabe, esta es una de esas funciones en las que enviamos algo temprano y podemos aprovechar las conversaciones con los líderes de opinión de la industria para comprender cosas como: "Oye, ¿cuáles son los umbrales que en realidad estás configurando manualmente? si está utilizando tamaños perezosos o está utilizando otras bibliotecas de carga diferida de JavaScript? Y luego ajustamos nuestros umbrales para tratar de acercarnos un poco más a lo que esperaría que fueran.

Addy Osmani: Entonces, en muchos casos, puedes usar la carga diferida nativa. Si necesita algo mucho más refinado, si necesita mucho más control sobre la posibilidad de establecer los umbrales del observador de intersección, el punto en el que el navegador va a solicitar cosas, generalmente sugerimos ir y usar una biblioteca en esos casos. , solo porque estamos tratando de resolver el caso de uso del 90%. Pero el 10% sigue siendo válido. Puede haber personas que todavía necesiten algo un poco más. Y así, para la mayoría de las personas, tengo la esperanza de que la carga diferida nativa sea lo suficientemente buena en el futuro previsible.

Drew McLellan: Sobre todo, es gratis. Un atributo simple para agregar, y obtienes toda esta funcionalidad de forma gratuita, lo cual es excelente. Si hubiera algo que nuestro oyente pudiera hacer, irse y hacerle a su sitio para mejorar la optimización de su imagen, ¿qué sería? ¿Por dónde deberían empezar?

Addy Osmani: Un buen lugar para comenzar es entender cuánto problema representa esto para su sitio. Iría y revisaría el faro o la velocidad de pago. Vaya y ejecútelo en algunas de sus páginas más populares y vea qué sale. Si parece que solo tiene una o dos cosas pequeñas que hacer, eso es fantástico. Tal vez puedas dedicar algo de tiempo allí.

Addy Osmani: Si hay una larga lista de cosas que puedes hacer, tal vez eche un vistazo a las oportunidades más altas que tiene allí, cosas que dicen: "Oh, oye, podrías ahorrar varios segundos si hicieras esto". cosa." Y enfoca tu energía allí para empezar.

Addy Osmani: Como hemos comentado aquí, las herramientas para los formatos de imagen modernos han mejorado con el tiempo. Definitivamente vale la pena considerar los CDN de imágenes. Pero más allá de eso, hay muchos pequeños pasos que puede tomar. A veces, si es un sitio lo suficientemente pequeño, incluso simplemente ir y abrir Squoosh, colocar algunas de sus imágenes allí puede ser un excelente punto de partida.

Drew McLellan: Ese es un consejo sólido. Ahora sé que es una publicación sensacional, pero realmente debo felicitarte por el libro. Es tan completo y muy fácil de digerir. Creo que es una lectura realmente valiosa.

Drew McLellan: He estado aprendiendo todo sobre la optimización de imágenes. ¿Qué has estado aprendiendo últimamente, Addy?

Addy Osmani: ¿Qué he estado aprendiendo últimamente? En realidad, en un tema ligeramente diferente que todavía tiene que ver con las imágenes, cuando estaba haciendo mi maestría en la universidad, me metí mucho en la visión por computadora y traté de entender cómo podemos detectar diferentes partes de una imagen y hacer cosas salvajes y cosas interesantes con ellos?

Addy Osmani: Y un problema específico en el que he estado investigando recientemente es que he estado mirando fotos mías cuando era un bebé o un niño. Y en ese entonces, mucha de la comida que mis padres tomaban no estaba necesariamente en cámaras digitales. Eran Polaroids. A menudo son imágenes de baja resolución. Y quería una manera de poder ampliarlos. Y entonces comencé a profundizar en este problema nuevamente recientemente. Y me llevó a aprender mucho más sobre lo que puedo hacer en el navegador.

Addy Osmani: Así que he estado desarrollando algunas herramientas pequeñas que te permiten, usando el aprendizaje automático, usando TensorFlow, usando las tecnologías existentes, tomar una imagen o ilustración de resolución relativamente baja y luego mejorarlas a algo de mucha más calidad. Así que es mejor que simplemente estirar la imagen. Es como realmente llenar en detalle.

Addy Osmani: Y eso ha sido algo divertido. He estado aprendiendo mucho sobre qué tan estable es ahora el ensamblado web a través del navegador, qué tan bien puede usar algunas de estas ideas para casos de uso de aplicaciones de escritorio. Y eso ha sido muy divertido. Así que he estado investigando mucho el ensamblaje web recientemente. Y eso ha sido genial.

Drew McLellan: Es divertido, ¿no? Cuando aparece una tecnología que pone patas arriba todo lo que conoces. Siempre hemos dicho que en la web podemos hacer las imágenes más pequeñas. Pero si solo tenemos una imagen pequeña, no podemos hacerla más grande. Es simplemente imposible. Pero ahora tenemos tecnología que, bajo muchas circunstancias, podría hacerlo posible. Es realmente fascinante.

Drew McLellan: Si usted, querido oyente, desea saber más de Addie, puede encontrarlo en Twitter donde es @AddieOsmani y encontrar todos sus proyectos vinculados desde AddyOsmani.com. El libro "Optimización de imagen" está disponible tanto física como digitalmente en Smashing ahora mismo en smashingmagazine.com. Gracias por acompañarnos hoy, Addy. ¿Tienes alguna palabra de despedida?

Addy Osmani: ¿Alguna palabra de despedida? Tengo una pequeña peculiaridad de la historia que compartiré con la gente. Tim Berners-Lee subió la primera imagen a Internet en 1992. No estoy seguro de que puedas adivinar de qué se trataba, pero probablemente te sorprendas. Drew, ¿tienes alguna conjetura?

Drew McLellan: Supongo que un gato.

Addy Osmani: Un gato. Es una buena suposición, pero no. Esto fue en el CERN. Y la imagen era en realidad de una banda llamada Les Horribles Cernettes, que era una banda pop de parodia formada por un grupo de empleados del CERN. Y la música que harían es como la música doo-wop. Y cantaban canciones de amor sobre colisionadores y peculiaridades y nitrógeno líquido y antimateria vistiendo atuendos de los años sesenta, que encontré simplemente maravillosos y aleatorios.