Eric Portis se une a mí para profundizar en el mundo de las imágenes receptivas.
Empezamos por lo básico. Las imágenes receptivas son específicamente imágenes en HTML y existen debido al deseo de un mejor rendimiento. Las imágenes son probablemente el mayor culpable del peso total de los sitios web. Si podemos evitar enviar demasiados píxeles a través de la red, deberíamos hacerlo. Después de todo, una pantalla de solo 720 píxeles de ancho no necesita una imagen de 2000 píxeles de ancho, incluso si es una pantalla de 2x.
El problema es que los navegadores son muy agresivos a la hora de descargar activos como imágenes. Eso es bueno, ya que es por eso que la web (puede ser) tan rápida como es. Pero también significa que necesitamos proporcionar mucha información sobre nuestras imágenes directamente en el HTML. ¿No puede un navegador saber qué tan grande es una imagen? Seguro que puede, después de haberlo descargado. ¿No puede un navegador saber qué tan grande se mostrará una imagen en la página? Claro que puede, después de descargar todo el CSS y realizar el diseño. La sintaxis de imágenes receptivas intenta adelantarse a todo eso proporcionando esa información directamente en la sintaxis. ¡Descubrir esa sintaxis es complicado! Existe srcset
, sizes
y el elemento, y hay un montón de envolver su mente alrededor de allí.
Se vuelve aún más complicado.
La sintaxis que necesita construir se basa en tener múltiples copias de esa imagen en las que construir la sintaxis. ¿Cómo los haces? ¿Cuántos deberías hacer? ¿Qué tamaño deberían tener?
Afortunadamente, están apareciendo algunas herramientas automatizadas alrededor de las imágenes receptivas. WordPress fue uno de los primeros jugadores. WordPress creará múltiples versiones de las imágenes que cargue y etiquetas de salida con una
srcset
sintaxis útil . Pero puedes hacerlo mucho mejor. Puede proporcionar un sizes
atributo que realmente coincida con lo que está haciendo su tema y cómo está dimensionando esas imágenes.
Además, WordPress no usa ninguna inteligencia especial para crear múltiples copias de las imágenes que carga. Pero podría. Una herramienta como el generador de puntos de interrupción de imágenes receptivo usa algo de inteligencia para determinar cuántas imágenes diferentes puede crear, de modo que pueda lograr un equilibrio entre tener casi la imagen perfecta para el trabajo y no tener que hacer cientos o miles de copias de eso. ¡Esa herramienta tiene una API!
Se vuelve aún más complicado.
Los diferentes navegadores admiten diferentes formatos de imagen. Por ejemplo, WebP. Se pueden obtener ahorros de rendimiento al ofrecer el formato de imagen correcto en el navegador adecuado. La sintaxis de imágenes receptivas puede ayudar con eso, pero complica la sintaxis. Muchos formatos de imagen también tienen una noción de calidad. ¿Con qué calidad guarda estas copias múltiples?
En este punto, es un buen momento para mencionar Cloudinary. Lo tengo integrado ahora mismo en CSS-Tricks, y ayuda con muchas de estas cosas. Debo mencionar que soy un cliente que paga de Cloudinary, y este screencast no fue patrocinado, pero Cloudinary ha patrocinado CSS-Tricks en forma de dos publicaciones patrocinadas altamente relacionadas:
- Imágenes receptivas en WordPress con Cloudinary, parte 1
- Imágenes receptivas en WordPress con Cloudinary, Parte 2
En pocas palabras, así es como funciona todo en CSS-Tricks ahora:
- Subo imágenes como siempre lo haría con WordPress.
- En lugar de
srcset
generar la información con WordPress, la genera esta API más inteligente. - La imagen también se carga en Cloudinary.
- Cuando WordPress filtra y genera el HTML para las imágenes, se aplican todos esos datos buenos
srcset
(y personalizadossizes
). La URL apunta a las URL de Cloudinary. - Las URL de Cloudinary hacen uso de la capacidad de Cloudinary para ajustar automáticamente tanto el formato como la calidad (usando su tecnología sofisticada) para asegurarse de que todo sea lo mejor posible para el navegador en particular que solicita la imagen.
- Las imágenes antiguas que no se cargaron originalmente en Cloudinary todavía se benefician de todas las bondades de Cloudinary. No tienen
srcset
datos tan inteligentes , pero aún usan la URL de "búsqueda", lo que significa que pueden beneficiarse del formateo automático y la calidad automática (que probablemente sea una parte decente de la mejora del rendimiento, de todos modos).
En resumen, no solo estoy usando imágenes receptivas aquí en CSS-Tricks para ayudar con el rendimiento, la integración de Cloudinary mejora seriamente ese juego.
También estoy feliz de que esta no sea una dependencia difícil. Si el complemento de Cloudinary se apaga alguna vez, todo vuelve a las imágenes normales de respuesta de WordPress.