SVB — Scalable Vector Binary
Un formato abierto de imágenes vectoriales que he especificado e implementado: la misma geometría que un SVG en alrededor del 27% del tamaño, con la accesibilidad dentro del archivo como requisito verificable y funcionando hoy en cualquier navegador vía Service Worker.
svb validate) lo comprueba con 14 verificaciones y emite informe citable con SHA-256 — sin ejecutar nada.Demo en vivo →
Iconos
.svbrenderizándose en tu navegador ahora mismo, vía Service Worker.Benchmark (1.087 SVGs) →
Corpus real (Feather, Bootstrap, Simple Icons) pasado por svgo antes de medir. Datos completos y reproducibles.
github.com/kinti/svb →
Spec byte a byte, codec sin dependencias, CLI con conversión por lotes, 56 tests y benchmark reproducible. MIT.
Por qué existe
SVG está parado, y eso deja un hueco real de mejora. El estándar está congelado: SVG 2 murió como Candidate Recommendation abandonada y el grupo de trabajo del W3C lleva años dormido. Mientras, el formato arrastra tres problemas estructurales:
- Es texto, y el texto cuesta: cada coordenada gasta 3–8 bytes de ASCII y la compresión de transporte (gzip/brotli) no entiende lo que comprime.
- La accesibilidad es opcional en la práctica:
<title>,<desc>y ARIA dentro del SVG casi nadie los pone, y nada en el formato permite verificarlos. - No evoluciona: sin render progresivo estándar, SMIL semimuerto, y cada animación vectorial vive en formatos privados (Lottie, Rive).
SVB ataca cada problema por su lado: codificación binaria con deltas y tabla de estilos compartida; un chunk de accesibilidad de gramática fija que un validador puede exigir y un peritaje certificar; y un contenedor por chunks preparado para evolucionar sin romper nada. Además, por diseño no puede llevar scripts: elimina el vector clásico de XSS de los SVG subidos por usuarios.
Los números
Benchmark sobre 1.087 SVGs de producción, cada uno optimizado antes con svgo (comparar contra un SVG sin optimizar sería hacer trampa):
| métrica | resultado |
|---|---|
| mediana svb / svg optimizado | ×0,277 |
| SVB crudo menor que svgo+brotli | el 100% de los archivos |
| svb+brotli / svgo+brotli | ×0,545 |
| tamaño mediano | 467 B → 140 B |
| ahorro medio por archivo | 72,7% (570 B) |
| bytes ahorrados en el corpus | 73,8% |
| codificaciones limpias | 1.087 / 1.087 |
El titular está en la segunda fila: el binario crudo ya gana al SVG comprimido con brotli. La reducción viene del formato, no de un filtro posterior — de hecho, SVB es tan denso que volver a comprimirlo lo agranda.
El detalle que me importa: la accesibilidad
En SVB el nombre accesible y la descripción no son atributos opcionales: viajan en un chunk propio, con gramática fija y presencia anunciada en la cabecera del archivo. Un validador puede exigirlo y una auditoría certificarlo sin interpretar la geometría. Es la misma línea de trabajo que a11y-toolkit: hacer la accesibilidad verificable en vez de recomendable.
Estado
Versión 0.2.1: especificación pública con gramática formal del contenedor, implementación de referencia en JavaScript sin dependencias, 56 tests, demo funcionando, benchmark reproducible y validador de conformidad y accesibilidad (svb validate: 14 verificaciones y el sello «SVB accesible»). La v0.2 añadió gradientes lineales y radiales, repetición como templates e instancias (la semántica de <use> llevada a binario) y packing de comandos estilo MVT. El tooling ya es de proyecto serio: conversión por lotes con aviso explícito de todo lo que se descarta, vectores de conformidad públicos y fuzzing con 6.000 mutantes sin un solo fallo. Siguen fuera texto, clip/mask y el modelado geométrico de la clase orgánica — la hoja de ruta completa está en el repo. La ruta de estandarización (tipo de medio en IANA, y un Community Group si hay tracción) se decide con adopción, no antes.
¿Curiosidad por el proceso o quieres usarlo en un proyecto? Escríbeme.