¿Qué es un SVG y por qué vale la pena usarlo?
Por qué el formato de tu logotipo debería ser SVG, qué lo hace distinto de un PNG, por qué el que exporta tu diseñador pesa diez veces lo necesario y qué se le puede quitar sin romperlo.
Por Javier Tenjo, Desarrollador full stack
En esta página
Hay una petición que hacemos en la primera semana de casi todos los proyectos: «mándanos el logotipo en SVG». Y hay una respuesta que llega más veces de las que debería: «te mando el PNG en alta, que se ve muy bien».
No es lo mismo, y la diferencia se nota exactamente cuando ya es tarde: en la cabecera de la web, en el pie de una factura, en un rótulo, en el favicon.
Píxeles contra instrucciones
Un PNG o un JPG guardan píxeles: una cuadrícula de puntos de color. Cuando los amplías, el navegador se inventa los puntos que faltan, y eso es lo que se ve como borroso o dentado.
Un SVG no guarda píxeles. Guarda instrucciones de dibujo: «una línea de aquí a aquí», «una curva con esta forma», «rellena de este color». El navegador las ejecuta al tamaño que haga falta, así que el resultado es nítido en un favicon de 16 píxeles y en una valla publicitaria, con el mismo archivo.
De ahí salen tres consecuencias prácticas:
- Pesa poco. Un logotipo típico ocupa unos pocos kilobytes, muchos menos que su equivalente en PNG a tamaño grande.
- Es texto. Un SVG se abre con un editor de código, se compara en un control de versiones y se genera desde un script. Es el único formato de imagen del que puedes ver el diff.
- Se puede tocar desde el sitio. Colores, grosores y animaciones se controlan con CSS. Un icono que hereda el color del texto con
currentColorno necesita una versión clara y otra oscura: se adapta solo al tema.
¿Cuándo sí y cuándo no?
Sí: logotipos, iconos, ilustraciones de líneas o planas, gráficos y diagramas, patrones, mapas.
No: fotografías. Un SVG puede llevar una foto dentro, pero eso es meter un mapa de bits en una caja vectorial: pesa igual o más y no gana nitidez. Para fotos, WebP o AVIF.
La frontera práctica es sencilla: si lo dibujó alguien con formas, es SVG; si lo capturó una cámara, no.
Un caso que casi nadie tiene en cuenta: los códigos QR. Un QR es una matriz de cuadrados, así que en SVG se imprime nítido a cualquier tamaño, mientras que un PNG ampliado deja los bordes dentados y complica la lectura. Está explicado en cómo funcionan los códigos QR.
¿Por qué el SVG que exportas pesa diez veces lo necesario?
Aquí es donde casi todo el mundo se lleva la sorpresa. Un icono simple exportado desde una herramienta de diseño puede ocupar 40 KB cuando su versión limpia son 3 KB. No es que el dibujo sea complejo: es todo lo que el editor deja dentro.
Metadatos del editor. Bloques enteros describiendo qué programa lo generó, con qué versión, en qué fecha y con qué nombre de capa. Nada de eso se dibuja.
Precisión absurda. Coordenadas como 12.000000000000002 cuando 12 produce el mismo píxel en pantalla. Cada decimal sobrante son bytes multiplicados por cientos de puntos.
Estructura muerta. Grupos vacíos, capas ocultas que alguien dejó apagadas, definiciones de degradados que ya no usa nadie, atributos repetidos en cada elemento en lugar de heredarse.
Estilos duplicados. El mismo relleno declarado cincuenta veces en vez de una.
¿Qué se puede quitar y qué no?
Optimizar un SVG es sobre todo borrar. Pero hay cuatro cosas que no hay que tocar, y verlas rotas es más frecuente de lo que parece:
- El
viewBox. Es lo que le dice al navegador la proporción del dibujo y le permite escalarlo. SinviewBox, el SVG deja de ser flexible y aparece con un tamaño fijo. - Los
idreferenciados. Si tu CSS o tu JavaScript apuntan a un elemento por suid, o si un degradado se referencia desde otro sitio, renombrarlos rompe el dibujo o su comportamiento. titleydesc. Son la accesibilidad del SVG: lo que lee un lector de pantalla. Un logotipo sintitlees una imagen muda.- Los grupos con significado. Si vas a animar una pieza concreta, esa pieza necesita seguir existiendo como elemento propio.
Por eso conviene comprobar el resultado, y no solo el peso. Nuestro optimizador de SVG hace justo eso: reduce el archivo y enseña el antes y el después superpuestos para que veas si algo se movió. La comparación importa más que el porcentaje de ahorro.
¿Cómo ponerlo en la página?
Dos formas, y la elección no es de gusto:
Con <img src="logo.svg"> cuando la imagen es independiente y no necesitas tocarla desde el sitio. Se cachea como cualquier archivo, no ensucia el HTML y —detalle importante— el navegador no ejecuta el JavaScript que pudiera llevar dentro.
En línea, pegando el <svg> en el HTML, cuando necesitas controlarlo con CSS: iconos que cambian de color al pasar el cursor, gráficos que reaccionan al tema oscuro, piezas animadas. El coste es que ese código viaja en cada página que lo use.
Un aviso de seguridad que casi nadie da
Un SVG es un documento, no una imagen inerte: puede contener scripts y referencias externas. Si tu aplicación permite subir archivos y acepta SVG —fotos de perfil, logotipos de clientes, adjuntos—, estás aceptando código.
Las dos defensas razonables: sanear el archivo en el servidor antes de guardarlo, y servirlo siempre dentro de una etiqueta <img>, que lo trata como imagen y no ejecuta nada. Para tus propios SVG, los que tú controlas, esto no aplica.
Resumiendo: pide siempre el logotipo en SVG, guárdalo con el resto del código, límpialo antes de publicarlo y comprueba con los ojos que sigue siendo el mismo dibujo. Son quince minutos una vez, y a cambio tienes una marca que se ve nítida en cualquier sitio durante años.