Cuando producimos una imagen PNG, usamos un <img> etiqueta o un fondo CSS, y eso es todo. Es muy simple y está garantizado que funcionará.
PNG es mucho más simple de usar en HTML que SVG
Desafortunadamente, no se puede decir lo mismo de SVG, a pesar de sus muchas ventajas. Aunque tiene muchas opciones cuando usa SVG en HTML, realmente se reduce a inline, <object> y <img>, todo con serias trampas y compensaciones.
Problemas con SVG en línea
Si está insertando SVG, pierde la capacidad de usar la memoria caché del navegador, la compresión Gzip entre servidores y navegadores, y la indexación de imágenes del motor de búsqueda (el SVG integrado no se considera una imagen). Aunque es posible que su imagen no haya cambiado ni un poco, siempre se recargan y esto provoca tiempos de carga más lentos para su sitio web, una compensación que la mayoría no está dispuesta a tolerar.
Además, insertar SVG también causa problemas de dependencia complejos en los que no puede insertar fácilmente imágenes en HTML y tiene que recurrir a scripts (PHP o de otro tipo). Cuando tiene más de unas pocas imágenes, esto se convierte en un gran problema cuando se trata de mantener su sitio, porque esencialmente no puede usar el <img> etiquetar más.
Sin duda, hay áreas en las que brilla el SVG en línea, es decir, si desea que sus imágenes se muestren rápidamente, sin esperar a que se carguen otros recursos. Aparte de eso, claramente, simplemente no puedes alinear todo.
Problemas con la etiqueta del objeto
SVG es bien conocido por su excelente calidad cuando se muestra en dispositivos de todas las resoluciones y su capacidad para hacer referencia a recursos externos, como CSS y fuentes, manteniendo el tamaño del archivo muy pequeño. La idea es tener muchos SVG que compartan un solo CSS o un solo archivo de fuente, para reducir la cantidad de recursos que tiene que descargar.
El mito de compartir recursos
Desconocido para muchos, compartir recursos externos para SVG solo se aplica a SVG en línea. Porque el uso de <object> etiquetas permiten el acceso a estos recursos, la percepción es que el navegador descargará una sola copia de su CSS, aunque tenga muchos <object> etiquetas que hacen referencia al mismo archivo CSS.
Esto, sin embargo, no es cierto en absoluto:
Múltiples etiquetas de objetos descargarán múltiples CSS
Para complicar el problema está el hecho de que <object> las etiquetas no se reconocen como una imagen y, por lo tanto, la indexación de búsqueda de imágenes no es posible.
Para complicar aún más el problema están los problemas de dependencia. Por ejemplo, digamos que tiene 100 imágenes y 25 de ellas usan una fuente Roboto, otras 25 usan Lato, 25 usan Open Sans, mientras que el resto usa una combinación de las tres fuentes. Su CSS necesitaría hacer referencia a las tres fuentes porque es bastante imposible realizar un seguimiento de qué archivo está usando qué fuentes, lo que significa que puede estar cargando fuentes que no necesita en ciertas páginas.
la etiqueta de la imagen
Eso nos deja con la <img> etiqueta, que tiene mucho a su favor. Debido a que es la misma etiqueta que se usa para otros formatos de imagen, obtienes familiaridad, almacenamiento en caché del navegador, compresión Gzip y búsqueda de imágenes. Cada imagen es independiente, sin problemas de dependencia.
SVG pierde fuentes si se usa con el <img> etiqueta
El único problema es perderás tus fuentes. Para ser más precisos, si tiene texto en su SVG, a menos que incruste fuentes, su texto se mostrará con fuentes del sistema, generalmente Times New Roman. Ha pasado horas seleccionando una hermosa fuente, pero en el momento en que usa el <img> etiqueta para incrustar SVG, todo eso se pierde. ¿Cómo puede ser esto aceptable?
Investigando la rasterización de fuentes
Convertir fuentes en rutas
Nuestra primera reacción es ver si podemos realizar la rasterización de fuentes. Es una técnica comúnmente utilizada para convertir fuentes en rutas, por lo que se representará bien en todos los dispositivos y mantendrá cero dependencias. En la superficie, esto funciona muy bien, y en el editor, todo se ve perfecto.
Aunque el SVG rasterizado llegó a un precio increíble 137 KB en comparación con 15,7 KB antes de la rasterización, éramos optimistas porque, después de optimizar nuestro SVG usando la compresión Gzip, el archivo rasterizado se reduce a 11 KB, ligeramente más pequeño que el PNG equivalente en 11.9KB.
| Original | Rasterización de fuentes | Rasterización de fuentes (.svgz) |
|---|---|---|
| 15,7 KB | 137 KB | 11,0 KB |
| PNG @ 1x | PNG @ 2x | PNG @ 3x |
|---|---|---|
| 11.9KB | 26.5KB | 42.6KB |
Imagen SVG con rasterización de fuente
Por desgracia, una vez que incrustamos el SVG rasterizado en HTML, descubrimos que nuestro optimismo era prematuro. Aunque puede verse muy bien en pantallas de alta resolución, la calidad en pantallas de baja resolución es inaceptable.
Fuentes rasterizadas en la parte superior y originales en la parte inferior
La parte inferior de la imagen es la original, con fuentes claramente visibles mientras que, en la parte superior, las fuentes están pixeladas con rasterización de fuentes.
Cleartype diferencia cuando se muestra en las pantallas
Lo que sucede es que la mayoría de los sistemas operativos optimizarán las fuentes para garantizar que se muestren claras y nítidas en todas las pantallas. En Windows, esto se llama ClearType y, dado que rasterizamos nuestras fuentes, no se aplicarán optimizaciones, lo que dará como resultado un texto borroso, particularmente visible en pantallas de baja resolución.
Obviamente, una reducción en la calidad es inaceptable, así que volvamos a la mesa de dibujo.
Incrustación de fuentes al rescate
Inicialmente, éramos extremadamente escépticos acerca de la incrustación de fuentes, principalmente debido al complicado flujo de trabajo.
Para incrustar fuentes en SVG, primero debe saber qué familias de fuentes se utilizan. Luego, debe encontrar estos archivos de fuentes y descargarlos. Una vez descargado, debe convertir regular, negrita, cursiva y negrita cursiva a la codificación Base64. Si lo está haciendo manualmente, es bastante imposible, en una gran cantidad de archivos, saber qué archivo usa negrita y cuál no. Luego, debe copiar las cuatro cadenas codificadas en Base64 en su SVG.
Seguramente, tiene que haber una mejor manera. Y es por eso que construimos Nano. Nano escanea SVG automáticamente e inserta solo las fuentes que se utilizan. Por ejemplo, si no se usa negrita o si no existe texto, no se incrustarán fuentes.
Aún así, el archivo resultante es enorme y no es competitivo con el equivalente PNG, por lo que lo desconectamos y construimos nuestro propio optimizador SVG (Nano) que reducirá el tamaño de los archivos SVG a un mínimo. (Vea cómo Nano comprime SVG). Además, también optimizamos la forma en que incrustamos las fuentes en SVG, lo que da como resultado tamaños de archivo muy pequeños.
Imagen SVG con texto, optimizada con Nano y fuentes incrustadas
Comparación de tamaños de archivo y ahorro de ancho de banda
| Original | Rasterización de fuentes | Incrustación de fuentes no optimizadas | Incrustación de fuentes nano | |
|---|---|---|---|---|
| Tamaño | 15,7 KB | 137 KB | 65.2KB | 22,0 KB |
| Gzip | 3.57KB | 11,0 KB | 44.5KB | 11,7 KB |
| PNG @ 1x | PNG @ 2x | PNG @ 3x | |
|---|---|---|---|
| Tamaño | 11.9KB | 26.5KB | 42.6KB |
| Gzip | 12,1 KB | 26.1 KB | 41.7KB |
De lo anterior, podemos ver que Nano produce un SVG que es extremadamente liviano incluso con fuentes incrustadas, llegando a 11,7 KB (Gzipeado) en comparación con el equivalente PNG @1x en 11.9KB. Si bien esto puede parecer insignificante, el ancho de banda total ahorrado en su sitio seguramente será significativo.
Supongamos que el 50 % de su tráfico es de baja resolución, el 40 % tiene una resolución de 2X y el 10 % restante tiene una resolución de 3X. Si su sitio web tiene 10.000 visitas en una sola imagen:
(5000 * 11,9 KB) + (4000 * 26,5 KB) + (1000 * 42,6 KB) = 208.1 MB
Si usa Nano, SVG comprimido con GZip:
10.000 * 11,7 KB = 117.0 MB
Esto dará como resultado: 208,1 MB – 117,0 MB = 91.1 MB ahorros, o 43.7%, ahorros de ancho de banda, una cantidad significativa por cualquier medida.
Además del ahorro de ancho de banda, obtiene un flujo de trabajo mucho más simple sin tener que recurrir a múltiples imágenes PNG con múltiples srcset, con mucha mejor calidad, incluida la mejora de la fuente del sistema operativo para garantizar que sus imágenes se mantengan nítidas y nítidas en dispositivos de todas las resoluciones. Lo mejor de todo, una mejor experiencia de usuario para sus usuarios, ya que su sitio se cargará más rápido, especialmente en dispositivos con alta resolución.
Probando a fondo Nano
No satisfechos con todos los ahorros, comenzamos a buscar imágenes SVG para probar a fondo Nano. Un total 2,571 Se utilizaron archivos SVG de varios tamaños y diseños, totalizando 16.3 MB. Y después de la optimización Nano, resultando en 6.2 MB, un asombroso 61,8% de ahorro en tamaño.
Una pequeña selección de más de 2500 imágenes SVG utilizadas para probar Nano
Mostrando una diferencia visual
Debido a la gran cantidad de archivos que estábamos probando, y que aumenta de vez en cuando, tenemos que crear una prueba automatizada, que incluya resaltar automáticamente las diferencias de píxeles antes y después de la optimización. Una de las quejas sobre otros optimizadores de SVG es el hecho de que la minimización de SVG puede dañar su imagen, lo que hace que se reproduzca de manera diferente en comparación con el original.
Con este fin, trasladamos la diferenciación de píxeles en nuestra prueba automatizada al mismo Nano. Es decir, Nano le avisará si detecta que el SVG que optimiza tiene una diferencia de píxeles de más del 1 % en comparación con el original, por lo que garantiza que la optimización de Nano nunca romperá un SVG.
Nano optimización que muestra la diferencia visual
Debido a que las fuentes están incrustadas y conservadas, además de que SVG es un formato de gráficos vectoriales, la calidad de representación en todas las resoluciones es incomparable con otros formatos de trama.
¿Que sigue?
Esperamos que nuestro trabajo haga que SVG sea más fácil de usar en todas partes. Ahora estamos trabajando para producir tamaños de archivo aún más pequeños, portando nuestros códigos para que funcionen en Node.js para que pueda automatizar sus compilaciones de producción con Nano, entre otros.
¿Crees que Nano te resultará útil en tus proyectos? ¡Házmelo saber en los comentarios!