Optimizador SVG — vectores más pequeños y rápidos

¿Qué hace exactamente esta herramienta?

Suelta un archivo SVG (o una carpeta en modo bulk), la herramienta lo envía a través de un optimizador SVG especializado y le muestra el resultado: un código fuente más pequeño, una vista previa de render frente al original y el ahorro de bytes. La optimización corre en el navegador mediante un motor optimizador pure-JavaScript — sin subida, sin cuenta, sin tracking. Salida: un archivo optimizado o un archivo ZIP en modo bulk. La operativa es deliberadamente fina: cuatro presets, un modo «Personalizado» para pros y dos conmutadores de salida (Formatear legible, Múltiples pasadas).

El ahorro varía dramáticamente con el tipo de authoring. Un path escrito a mano con coordenadas a tres decimales sin adornos se reduce 5–15 %. Un logo exportado desde un programa vectorial con espacios de nombres de editor, comentarios, metadatos y precisión de ocho decimales baja rutinariamente 60–80 %. Un flujo que envía un SVG a través de una herramienta de grabación de pantalla y un editor puede producir archivos que son al 90 % lastre — hemos visto iconos de 200 KB encogerse a 25 KB sin que un solo píxel cambie en el render.

¿Por qué optimizar SVG en 2026?

Tres razones que se suman. Primero rendimiento del First Paint: cada kilobyte de SVG inline retrasa su render hero. Las webs modernas linean 8–20 iconos en su navegación; ahorrar 3 KB por icono alivia el payload del Critical Path en 60 KB. Segundo ratio gzip: los optimizadores ordenan atributos alfabéticamente (sortAttrs), lo que mejora la ventana del compresor — el SVG optimizado no solo es más pequeño en bruto, también comprime mejor. Tercero integración en pipeline de build: los SVG pasados por esta herramienta no traen el lastre de editor, de modo que las herramientas downstream (constructores de fuentes de iconos, generadores de sprites, loaders de framework) reciben entrada más limpia.

Hay también un aspecto de privacidad que sorprende a muchos. Las exportaciones de herramientas de diseño incrustan a menudo metadatos de usuario en el SVG: el nombre del autor, la ruta del archivo en disco local, el timestamp de trabajo del editor, a veces incluso imágenes de referencia no usadas como data-URIs. Eliminar comentarios y metadatos significa que esa información ya no viaja con su asset.

¿Cómo se distinguen los cuatro presets?

Web es el default y el más agresivo — lo que la mayoría necesita para iconos e ilustraciones en el navegador. Elimina comentarios, metadatos, <title>, <desc>, espacios de nombres de editor, DOCTYPE y el prólogo XML. Acorta IDs, redondea valores numéricos a tres decimales (en tamaño de icono casi siempre invisible), acorta colores (#ffffff → #fff, rgb(255,0,0) → red), convierte formas a paths si ahorra bytes, fusiona paths y colapsa transformaciones y grupos redundantes. La viewBox no se elimina; el sizing intrínseco es demasiado a menudo importante. Reducción esperada: 40–80 % en exportaciones típicas.

Figma-Safe mantiene los IDs sin cambios. Las herramientas de diseño vectorial referencian formas vía IDs cuando configura variantes de símbolo u overrides de componente; si los IDs se renombran en un SVG reimportado, el cableado de variantes se rompe. Además, <title> y <desc> (accesibilidad) permanecen, y el merging de paths se omite. Reducción esperada: 30–60 %.

Editor-Safe es el preset de ida-y-vuelta para SVG que quiera seguir editando en un programa vectorial. Preserva comentarios, espacios de nombres de editor, IDs, títulos, descripciones, marcadores de capa — todo lo que un editor necesita para restaurar su estado de trabajo. Solo corren las minificaciones más seguras. Reducción esperada: 5–20 %.

Personalizado le deja marcar exactamente las optimizaciones a ejecutar. La lista es una rejilla de dos columnas con etiquetas descriptivas. El estado inicial corresponde al preset Web; puede deseleccionar entradas y volver a ejecutar tantas veces como quiera. Necesita este modo cuando ha aparecido una regresión: deseleccionar la optimización que rompió el icono y recalcular.

¿Para qué sirve la vista previa antes/después?

La regresión visual es el modo de error que mejor esconde la optimización agresiva. Un path que se veía bien a 24 px empieza a oscilar a 96 px porque el redondeo a tres decimales ha desplazado un punto de control del ancla. Un gradiente que referenciaba un stop faltante se renderiza en color sólido tras eliminar <defs> no usados. Un clipPath que dependía de un ID se renombró, y el clip ya no corta nada. Ninguno de estos problemas destruye el SVG; los tres cambian cómo se presenta.

La vista previa renderiza ambas versiones en una sandbox aislada. Verá a la izquierda el original, a la derecha el optimizado, ambos escalados a la misma caja. Si el optimizado se ve diferente, el arreglo suele ser: elegir preset más conservador, aumentar la precisión float en modo «Personalizado» o desactivar la optimización específica que causó la diferencia.

¿Cómo funciona el modo bulk?

Soltar o seleccionar varios archivos SVG simultáneamente. La herramienta lee cada uno en memoria, aplica el preset activo a cada uno y le muestra una lista por archivo con delta de tamaño. Un resumen batch sobre la lista muestra los bytes totales ahorrados, la reducción ponderada en porcentaje y el tiempo total de optimización. Descarga todos los archivos optimizados como un archivo ZIP.

El modo bulk es la vía correcta cuando ha heredado una biblioteca de iconos o quiere incorporar limpiamente una carpeta de ilustraciones a su build. El preset Web sobre una biblioteca de 200 iconos ahorra típicamente 60–80 % de los bytes totales — es una mejora Lighthouse perceptible para cualquier página que los entregue inline.

¿Qué se ve en la pestaña de red mientras la herramienta optimiza?

Abrir DevTools, pestaña de red, soltar un SVG de 1 MB y observar. Verá cero peticiones salientes para la optimización misma. El optimizador se carga dinámicamente una vez tras el primer idle de página y se cachea por el navegador; todos los demás archivos usan el módulo cargado en memoria. No hay ping de analytics, ni endpoint de logging ni API Background-Sync o Reporting que algunas herramientas usan para sacar datos en silencio.

No es promesa de marketing sino propiedad verificable de la construcción de página. El optimizador es un módulo JavaScript que corre en su pestaña; las fuentes SVG se leen con la API FileReader del navegador; las salidas se construyen en memoria y se enganchan a Blob URLs que el navegador conserva localmente hasta cerrar la pestaña.

¿Cuándo no es esta herramienta la elección correcta?

Unos cuantos casos en los que debería usar otra herramienta. Rasterización SVG-a-PNG: esta herramienta optimiza SVG-como-SVG, no renderiza a PNG. Simplificación de path (Ramer-Douglas-Peucker): esta herramienta aprieta las coordenadas pero no cambia la topología. Vectorización bitmap-a-SVG: es un problema completamente diferente. Edición interactiva calidad editor: este es un optimizador one-shot, no un canvas de trabajo. Conversión WebP/AVIF: use nuestro convertidor de formato de imagen para formatos raster.

En lo que esta herramienta es realmente buena: enviar iconos SVG limpios, pequeños y predecibles a su build de producción, sin perder fidelidad, sin subir nada y sin tener que aprender una CLI.

¿Cómo encaja la optimización SVG en una pipeline de build?

Tres puntos de integración habituales. En tiempo de authoring (esta herramienta o el CLI equivalente sobre una carpeta): optimiza SVG antes de que vayan al control de versiones. En tiempo de build (CLI en package.json postinstall o script de build): conserva el código fuente verboso para la amigabilidad de editor y stripa solo en el paso a producción. En tiempo de petición (middleware servidor que optimiza al vuelo): raro, casi siempre sobredimensionado.

Esta herramienta encaja exactamente con el primer punto de integración: una ejecución manual ocasional que produce SVG production-ready. La salida que copia o descarga es la misma secuencia de bytes que una optimización CLI produciría con la misma selección de plugins.

¿Qué mide exactamente el porcentaje de reducción?

El porcentaje sobre la salida corresponde a (bytes_original − bytes_optimizado) / bytes_original, calculado sobre longitud de bytes codificada UTF-8. Es el tamaño de archivo que escribiría en disco o entregaría a un navegador. Para SVG inline en HTML, es también exactamente el ahorro de bytes en la descarga del documento — cada byte ahorrado aquí es un byte menos que el navegador debe parsear antes de renderizar su icono.

Dos cosas que el porcentaje no captura. Primero mejoras de ratio gzip: por el ordenamiento alfabético de los atributos y la normalización del whitespace, el SVG optimizado comprime a menudo mejor de lo que el delta bruto sugiere. Empíricamente añade otro 10–20 % encima cuando gzip se aplica. Segundo ahorro de tiempo de parsing: un SVG más pequeño con paths fusionados es más rápido de parsear y dibujar para el renderizador SVG del navegador.

¿Dónde encuentra el estándar y más contexto?

• Especificación W3C SVG — el estándar al que el optimizador se atiene.
• Tutorial MDN SVG — cómo renderizan los SVG en el navegador y qué atributos respetan los navegadores.
• Wikipedia: Scalable Vector Graphics — contexto histórico y visión general del formato.

Optimizar un SVG, ver caer el contador de bytes, entregar un bundle más pequeño. Sin subida, sin cuenta, sin tracking — verificable en la pestaña de red de DevTools de su navegador.