Convertir SVG a WebP

Un SVG es un conjunto de instrucciones —dibuja este trazo, rellena esta forma, contornea esta línea— sin resolución propia. Renderizar sigue esas instrucciones a un tamaño concreto y guarda el resultado como píxeles, y desde ese momento el dibujo desaparece y solo queda la imagen.

Así que el tamaño elegido en el momento de convertir es el que tienes. Ampliar el WebP después solo puede inventar los píxeles intermedios, que es exactamente lo que el arte vectorial existe para evitar. Acertar con la escala es todo el oficio de esta conversión; el resto son detalles.

Una pantalla de móvil mete dos o tres píxeles físicos en cada píxel CSS, así que una imagen renderizada exactamente a su tamaño de visualización se ve blanda en la mayoría de dispositivos que la van a mostrar. Renderizar al doble o al triple y dejar que el navegador reduzca es la práctica habitual, y cuesta menos de lo que parece: un logo plano al doble comprime a una fracción de lo que pesaría una fotografía de las mismas dimensiones.

La excepción es cualquier cosa realmente grande. Una cabecera a todo lo ancho renderizada al triple produce un archivo que nadie debería descargar; ahí conviene renderizar al doble y aceptarlo, o plantearse si el propio SVG podría servirse directamente.

Un SVG nombra sus fuentes en lugar de contenerlas. Cuando el motor de render tiene la fuente, el texto se dibuja bien; cuando no, se sustituye por otra cosa, con otro ancho, así que un nombre comercial compuesto en una tipografía con licencia llega en una genérica de palo seco, con otra anchura, y con la maquetación alrededor rota.

La solución va en el programa de diseño, antes de exportar: convierte el texto en trazados, para que las letras se vuelvan rutas y no dependan de nada. El texto deja de ser editable y pasa a ser fiable, que para un logo es el cambio correcto. Para un diagrama con etiquetas que quieras conservar editables, incrusta la fuente en el SVG en su lugar.

El WebP que se escribe aquí siempre tiene pérdida —el control de calidad decide cuánto aprieta el codificador, y en este par no hay modo sin pérdida. El valor por defecto de 82 está pensado para fotografías, y en arte vectorial se nota justo donde no debería: una línea de un píxel coge una mancha, y el límite entre dos colores planos gana un halo de píxeles intermedios.

Súbelo a 95 o más para un logo, un icono o un gráfico, y esos defectos desaparecen mientras el archivo sigue siendo pequeño, porque el color plano comprime bien a cualquier ajuste. Una ilustración con degradados y sombras suaves se comporta como una fotografía y no necesita nada de esto. Si el arte tiene que salir exacto en vez de aproximado, renderiza a PNG en su lugar: ese codificador es sin pérdida.

A menudo. Si el dibujo es un logo, un icono o una ilustración sencilla que va a una página web que controlas, el SVG suele pesar menos que cualquier raster equivalente, se ve nítido a cualquier zoom en cualquier pantalla, y se puede recolorear desde CSS sin generar un segundo archivo.

Conviene convertir cuando algo rechaza el SVG, y hay bastantes casos así: las imágenes de vista previa en redes sociales exigen PNG o JPG a un tamaño fijo, los clientes de correo son poco fiables con el SVG, muchos formularios de subida lo rechazan directamente, y las plataformas que aceptan contenido de usuarios a menudo lo prohíben por seguridad —un SVG es XML y puede contener scripts. Son restricciones reales, y por eso existe esta página en vez de una preferencia general por los píxeles.

Los iconos vienen en conjuntos, no de uno en uno. Suelta la carpeta entera: cada archivo se renderiza a su vez a la escala elegida, conserva su nombre con la extensión cambiada, y todo vuelve como un ZIP listo para incorporar a un proyecto.

Dos costumbres mantienen el resultado coherente. Renderiza cada icono a la misma escala en vez de a ojo, para que el conjunto se vea intencionado de un vistazo. Y conserva los SVG en el control de versiones como origen: regenerar todo el conjunto a un nuevo tamaño cuesta entonces una pasada, no volver a dibujar nada.

El render ocurre en la pestaña del navegador, sobre tu propio procesador. Nada se sube, así que no hay cola, ni límite diario, ni cuenta que crear —y ningún tercero acaba guardando el material de marca todavía sin publicar, algo que preocupa más con logos que con la mayoría de archivos.

También significa que una carpeta de doscientos iconos se convierte tan rápido como tu equipo pueda dibujarlos, en vez de tan rápido como se puedan subir y volver a descargar.

Vale la pena comparar antes de aceptar el resultado como definitivo. Un SVG bien optimizado de un icono simple puede pesar menos de un kilobyte; el mismo dibujo renderizado a WebP a un tamaño razonable para pantalla suele pesar más, aunque siga siendo pequeño en términos absolutos.

Eso no invalida la conversión —el destino a menudo no admite SVG y el punto ya está decidido—, pero conviene tenerlo presente antes de repetir la conversión para todo un sistema de iconos: si el destino terminara aceptando SVG en algún momento, el ahorro de peso sería mayor que cualquier ajuste de calidad en esta página.

WebP guarda sus dimensiones en catorce bits y no admite más de 16.383 píxeles en ningún lado. Es un límite que casi nunca se toca desde un SVG —el rango de escala llega como mucho a 10.240 píxeles de ancho—, pero conviene conocerlo si el dibujo se va a renderizar para un cartel o una lona y no solo para pantalla.

Si algún día el destino pide más que eso —un plano, una lona de gran formato— este par deja de ser la opción correcta, y AVIF o un TIFF sin comprimir son los que admiten dimensiones mayores. Para prácticamente todo lo que se muestra en una página web, el límite del WebP nunca aparece.

WebP lo leen todos los navegadores actuales, pero no todo lo que procesa una imagen es un navegador: algunos gestores de contenidos antiguos, algunas plantillas de correo y algún que otro formulario de subida siguen sin reconocerlo, sobre todo en sistemas que llevan años sin actualizarse.

Cuando el destino es incierto o es software que no controlas, exportar también un PNG desde el mismo SVG cuesta una segunda pasada y elimina la duda. Cuando el destino es tu propia página web, WebP con un elemento picture y una fuente de PNG como respaldo cubre igual el caso raro sin renunciar al ahorro de peso en el resto de visitas.

Cuando la imagen final va a ocupar distinto espacio según el ancho de pantalla —una cabecera que es de página completa en un móvil y una franja lateral en un monitor grande—, un solo render no basta por bien elegido que esté. La respuesta habitual es un conjunto de anchos, cada uno servido con srcset, para que el navegador pida solo el que necesita.

Esta conversión no genera ese conjunto por sí sola: hay que repetirla una vez por cada ancho, siempre desde el mismo SVG y no desde un WebP ya renderizado, porque partir de un raster ya perdido no recupera ningún detalle. Tres o cuatro anchos suelen bastar para cubrir el rango habitual entre un móvil y un monitor de escritorio.