Cómo optimizar SVG sin perder seguridad ni accesibilidad

Un SVG es texto y por eso parece fácil reducirlo: se eliminan espacios y el archivo pesa menos. Sin embargo, también puede contener referencias, metadatos, estilos, nombres accesibles y elementos que no pertenecen a un icono estático. Una optimización útil reduce bytes sin cambiar el dibujo, su función ni la forma prevista de entregarlo. Esta guía usa un icono sintético para explicar una revisión segura; no afirma que una misma configuración sea válida para todos los SVG.

El problema

El problema habitual no es solo el espacio en blanco. Las aplicaciones de diseño exportan grupos anidados sin transformación, atributos repetidos, rectángulos invisibles, comentarios y metadatos del editor. El navegador puede pintarlos sin protestar, pero todos esos bytes viajan y cada elemento adicional complica la revisión. Quitar un grupo exige saber si aporta una transformación, un recorte o un estilo heredado. Quitar un título exige saber si era el único nombre comprensible de una imagen informativa.

La seguridad y la compresión se relacionan, pero no son lo mismo. SVG 2 describe un lenguaje gráfico amplio. Un archivo obtenido de una fuente no controlada puede incluir referencias externas, enlaces, atributos de evento, contenido de script, filtros o imágenes. Que una forma concreta de incrustarlo parezca inocua en un navegador no convierte esas capacidades en necesarias. El optimizador transforma sintaxis; la decisión sobre qué aceptar corresponde a una política de activos y al contexto donde se publicará.

La accesibilidad aporta otra condición. Un gráfico decorativo debe ocultarse de forma adecuada en el componente que lo usa. Una imagen informativa necesita un equivalente textual que explique su propósito. Un elemento title puede colaborar en algunos patrones, pero no sustituye siempre a un alt, un pie de figura o el nombre de un control. Borrarlo solo para ahorrar bytes puede dejar una flecha, un estado o un gráfico sin explicación para quien no ve la pantalla.

Ejemplo práctico

Parte de un ejemplo pequeño e inventado, no de un logotipo ni de un archivo de cliente. El SVG de prueba contiene dos grupos redundantes, metadatos de editor, un título útil y una referencia externa sospechosa. El código se muestra para inspeccionarlo, no para copiar las partes que se deben rechazar.

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 48 48" role="img" aria-labelledby="estado-titulo">
  <title id="estado-titulo">Carga completada</title>
  <metadata>Exportado desde un equipo de pruebas</metadata>
  <g><g fill="#1d9bf0"><circle cx="24" cy="24" r="20" /></g></g>
  <g><path fill="#fff" d="M22 12h4v16h6l-8 8-8-8h6z" /></g>
  <image href="https://example.invalid/tracker.png" width="1" height="1" />
</svg>

Para un icono local y autocontenido, una salida revisada puede conservar el viewBox, el círculo, el trazado y el título significativo, y retirar los metadatos, los grupos sin función y la imagen externa. Los bloques exactos de esta página ocupan 425 y 268 bytes, respectivamente: UTF-8 sin BOM, saltos LF y un salto final. Son tamaños del código mostrado, no una promesa de compresión. Hay que abrir ambos en los tamaños reales de la interfaz y comparar color, posición, escala y nombre accesible. Una diferencia de bytes sin comparación de renderizado no demuestra equivalencia.

Esta es la salida revisada manualmente. Guarda los dos bloques como before.svg y after.svg respetando esos saltos; comprueba sus tamaños con el comando siguiente. No cargues la referencia externa del original.

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 48 48" role="img" aria-labelledby="estado-titulo">
  <title id="estado-titulo">Carga completada</title>
  <circle fill="#1d9bf0" cx="24" cy="24" r="20" />
  <path fill="#fff" d="M22 12h4v16h6l-8 8-8-8h6z" />
</svg>

node -e "const fs = require('node:fs'); for (const p of ['before.svg', 'after.svg']) console.log(p, fs.readFileSync(p).byteLength);"

Procedimiento

Haz una copia inmutable y anota dónde se utiliza el activo. Clasifícalo como decorativo, informativo o interactivo. Para un elemento decorativo, el componente debe aportar la semántica de ocultación y no conviene añadir un título engañoso. Para una imagen informativa, decide primero cuál será la alternativa textual visible o programática. Para un botón con icono, el botón necesita su propio nombre accesible; el dibujo no debe competir ni duplicarlo.

Inspecciona el texto antes de optimizar. Haz inventario de raíz SVG, formas, grupos, definiciones, reutilizaciones, degradados, texto, enlaces, imágenes, estilos, metadatos, identificadores y atributos de accesibilidad. Trata cualquier URL externa, script, atributo de evento o elemento desconocido como un hallazgo de revisión. Si el producto no lo necesita, elimínalo o rechaza el archivo mediante una regla explícita. Si una característica local sí es necesaria, por ejemplo un degradado con referencia por ID, conserva una muestra de prueba que demuestre el resultado.

Ejecuta una optimización conservadora sobre la copia y revisa el diff textual, no solo el porcentaje. Comprueba que viewBox permanezca si el CSS necesita escalar el icono; eliminar dimensiones no equivale a eliminar el sistema de coordenadas. Comprueba que los ID usados por aria-labelledby, url(#degradado), clip-path o use sigan coincidiendo tras limpiar identificadores. No conviertas texto en trazados automáticamente si debe poder seleccionarse, traducirse o leerse como texto.

Prueba por último el archivo en la misma ruta de entrega que usará la web. Abrirlo directamente es una comprobación, pero también hay que renderizarlo dentro del componente, sobre fondos claros y oscuros cuando aplique, a tamaños estrechos y amplios y con zoom. Revisa el árbol de accesibilidad y el foco de teclado si es interactivo. Una captura de referencia o una prueba visual evita que una modificación aparentemente mínima cambie un recorte o un degradado. Conserva el original si habrá que editarlo, investigar una regresión o comprobar su licencia.

Explicación técnica

SVG es un formato de gráficos vectoriales basado en XML, pero su significado práctico depende de cómo se incrusta. Un archivo solicitado por una imagen no se comporta igual que marcado SVG insertado dentro de un documento. La herencia de CSS, los permisos de script, las reglas de origen y la exposición a tecnologías de asistencia varían según el contexto y el navegador. Por eso que “se vea bien en una pestaña” no prueba que siga siendo equivalente después de optimizarlo, incluirlo en línea o servirlo con otra política de contenido.

Los grupos redundantes suelen existir porque el editor conserva capas. Un grupo sin transformación, estilo, recorte ni propósito puede desaparecer. Atributos idénticos pueden consolidarse y algunos decimales se pueden acortar dentro de una tolerancia visual. Son cambios sintácticos que intentan preservar la pintura. En cambio, retirar un grupo con transformación desplaza coordenadas; cambiar una regla de relleno modifica qué zona se pinta; borrar una definición rompe una referencia lejana. La revisión debe clasificar el riesgo de cada cambio, no adivinarlo por su tamaño.

El nombre accesible también forma una red de referencias. Si aria-labelledby señala a un ID y un proceso lo renombra o borra, el gráfico queda sin etiqueta. Si la imagen ya posee una alternativa textual precisa fuera del SVG, un título interno puede ser redundante. La elección correcta depende del patrón concreto, no de reglas absolutas como “quitar siempre títulos” o “conservarlos siempre”. La guía WCAG busca un propósito equivalente; la técnica exacta pertenece al componente y a su contexto editorial.

Errores frecuentes

Un fallo común es descargar un recurso de un catálogo, reducir su tamaño y asumir que ya es seguro. Borrar metadatos no elimina necesariamente referencias, atributos de evento ni todas las capacidades activas. Otro fallo es permitir todo porque la muestra no mostró un error visible. Una referencia invisible puede generar una petición; el comportamiento puede variar; y un uso futuro en línea puede abrir una exposición distinta. Define una lista de características permitidas según el tipo de activo e investiga las excepciones.

También falla eliminar viewBox y conservar solo dimensiones en píxeles. El icono puede verse bien a su tamaño exportado y recortarse o deformarse al escalarlo con CSS. La limpieza de ID puede romper degradados, máscaras, recortes y etiquetas. Estas incidencias aparecen a veces solo en una ruta o anchura, por lo que inspeccionar el archivo aislado no basta.

No midas el éxito únicamente en bytes. Convertir texto significativo a trazados puede reducir dependencias y a la vez perjudicar selección y traducción. Retirar un título puede volver opaco un icono compacto. Sustituir un filtro puede cambiar el contraste. Registra la reducción, pero también las decisiones visuales y de accesibilidad para que otra revisión sepa qué diferencia es intencionada.

Consideraciones

Define el límite de activos antes de aceptar archivos. Para un icono de interfaz puede bastar una raíz SVG, formas básicas, trazados, definiciones locales y atributos accesibles revisados, excluyendo recursos externos y elementos relacionados con script. Una visualización de datos o una ilustración de marca puede necesitar degradados, recortes, texto y más ID. Lo importante es que las características permitidas respondan a una necesidad real y se prueben, no que se acepten porque el exportador las generó.

Haz el proceso reproducible. Guarda fuente, versión o configuración de la herramienta, salida y una lista breve de aceptación. Fijar versiones ayuda cuando importa que los bytes sean estables. Si una automatización cambia un SVG, la revisión debería ver el diff y un resultado visual. Es especialmente útil para iconos compartidos: una regresión pequeña en un ID puede afectar a todas las páginas que reutilizan el activo.

Considera además la privacidad. Los metadatos pueden revelar nombre del editor, ruta de creación o versión de software; las referencias externas pueden revelar una visita a otro origen. Quitarlos puede ser adecuado, pero no autoriza a afirmar que el archivo resultante es privado o seguro en cualquier circunstancia. La página, cabeceras, caché y el resto de la cadena de entrega siguen importando.

Limitaciones

Ninguna guía genérica certifica que un SVG arbitrario sea seguro, accesible o visualmente idéntico. El navegador, la forma de incrustación, la política de contenido y la tecnología de asistencia condicionan el resultado. Una comparación visual puede no detectar diferencias de animación, filtros, fuentes o gestión de color. Una política adecuada para iconos estáticos puede ser demasiado estricta para gráficos o demasiado permisiva para archivos subidos por usuarios.

Esta guía no sustituye una revisión de seguridad de cargas no confiables, una revisión de licencia de arte de terceros ni pruebas profesionales de accesibilidad. Tampoco promete que un porcentaje de optimización mejore el rendimiento de página: compresión de transferencia, caché, dimensiones y uso en rutas cambian el resultado. Prueba el activo real y conserva una ruta de vuelta atrás.

Lista de comprobación

Clasifica el SVG antes de tocarlo. Trabaja sobre una copia e inspecciona elementos, referencias, ID, metadatos y atributos de nombre. Rechaza o elimina deliberadamente scripts, eventos y recursos externos fuera de la política. Conserva viewBox y cada referencia necesaria para degradados, recortes, reutilización o etiquetas. Optimiza con prudencia, inspecciona el diff, compara tamaño y renderiza en el componente final. Comprueba el nombre accesible en contexto, guarda fuente y configuración, y mantiene un original probado para revertir.