Mantys Core
Te dijeron que el SVG es ligero y nítido como una cuchilla, así que lo pones en todas partes y pegas el código directamente en la página. Ese instinto es correcto, para una lupa de búsqueda o una flecha pequeña. Se convierte en una trampa de rendimiento en cuanto la imagen se vuelve compleja, y en un error real cuando lo que pegaste ni siquiera es un vector de verdad.
Al final de esta guía podrás mirar cualquier bloque de código SVG y decir, de un vistazo: ese va bien en línea, ese pertenece a un archivo externo, o ese ni siquiera es un SVG. Ese simple reflejo evita que las páginas dupliquen su peso sin motivo.
Qué significa realmente "SVG en línea"
Hay dos formas de poner una imagen en una página. Primero, una etiqueta de imagen que apunta a un archivo, como <img src="logo.svg">. El navegador lee la etiqueta, luego va a buscar el archivo por separado. Segundo, un SVG en línea: el dibujo se escribe por completo, dentro del propio código de la página, y cada trazo se convierte en una línea de código.
Una analogía. Una etiqueta de imagen es una nota que dice "la foto está en el cajón". Un SVG en línea es copiar la receta entera de la foto, trazo a trazo, justo en medio de tu texto.
Así que "en línea" no es bueno ni malo por sí mismo. Todo depende del tamaño de la receta.
Por qué un icono pequeño en línea es justo lo correcto
El caso legítimo: una lupa de búsqueda, una flecha, una marca de verificación, un pictograma pequeño. Unos pocos trazos, un puñado de nodos. Aquí el modo en línea brilla.
- Cero peticiones de red adicionales. No hay ida y vuelta para buscar un archivo de 300 bytes, el dibujo ya está ahí.
- Estilizable en CSS. Cambia el color al pasar el cursor con
currentColor, anímalo, todo gratis. - Visible desde el primer pintado, no hay nada que esperar.
Regla general: un icono en línea optimizado por debajo de unos 4 KB se mantiene sano. Más allá de eso, empieza a pensar en un archivo.
El punto de inflexión, cuando el modo en línea se convierte en un problema
Aquí está el meollo. Tres costes ocultos se acumulan en cuanto el dibujo deja de ser un simple icono y se convierte en una ilustración completa.
1. El DOM explota
El DOM (Document Object Model) es la lista de cada elemento que el navegador tiene que mantener en memoria y recalcular en cada interacción. Piénsalo como el inventario en curso de la página.
Un icono simple añade unos pocos nodos. Una ilustración detallada exportada desde una herramienta de diseño son cientos de trazados, es decir cientos de nodos, para una sola imagen. Una herramienta de medición como Lighthouse avisa a partir de unos 800 elementos en la página y lo trata como excesivo a partir de aproximadamente 1.400. Una sola ilustración mal colocada puede añadir 300 nodos por sí misma, una gran parte del presupuesto, para nada.
Cuanto más grande es el DOM, más lento es cada recálculo de estilo y disposición, y más se entrecortan el desplazamiento y los clics. Eso afecta directamente a la interactividad, la métrica INP (Interaction to Next Paint, la rapidez con que la página responde a un clic o un toque).
2. El tiempo de análisis sube
Antes de poder mostrar nada, el navegador tiene que leer e interpretar cada trazo del SVG en línea. Multiplicado por cientos de trazados, eso retrasa el primer pintado.
Y este coste se paga en el hilo principal, el mismo que responde a los clics. Así que se nota en todas partes, no solo al cargar.
3. Cero caché, recargado en cada página
Un SVG en línea vive dentro del código de la página. No se almacena en caché por sí solo. Si aparece en cinco páginas, se vuelve a descargar y a analizar cinco veces. Un archivo .svg externo, en cambio, se descarga una vez y luego se sirve desde la caché en todas las demás páginas. No bloquea el renderizado, y puede cargarse de forma diferida cuando está más abajo.
La analogía: copiar la misma receta completa en cada capítulo de un libro, en lugar de un único marcador que apunta a un solo apéndice.
La trampa dentro de la trampa, un raster disfrazado de SVG
El peor caso, y sorprendentemente común: un PNG o JPG codificado en base64, pegado dentro de una etiqueta SVG. Desde fuera se lee como "un SVG". En realidad es una foto comprimida convertida en texto.
Por qué es lo peor de ambos mundos
El base64 infla el peso en torno a un 33 %. Tres bytes se convierten en cuatro caracteres.
No se almacena en caché de forma independiente, así que se recarga en cada página en la que aparece.
El navegador tiene que decodificar ese muro de texto antes de poder mostrar nada.
Se descarga esté en pantalla o no. No es posible ninguna carga diferida.
La señal reveladora: si el "SVG" pesa cientos de kilobytes y contiene una cadena larga como data:image/png;base64,iVBOR..., no es un SVG. Es una imagen raster en el cajón equivocado.
<svg width="1200" height="800" ...>
<image href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUg...
...tens of thousands of characters of encoded photo...
...kSuQmCC" width="1200" height="800"/>
</svg>La solución: reexporta un archivo de imagen real, idealmente WebP (un formato de imagen moderno, más ligero que JPEG o PNG), en una etiqueta de imagen normal, con ancho y alto definidos, con carga diferida si está fuera de pantalla, y versiones responsivas. Esas versiones solo compensan con un atributo sizes correcto: véase nuestra guía sobre srcset y sizes.
Un caso real, anonimizado
Auditamos una página de un sitio (una construcción con Divi). Nada parecía mal en el editor, "solo tenía un par de imágenes" cerca del final.
La solución: el pictograma como un archivo .svg externo (o un WebP a su tamaño real), el visual del podcast como WebP en una etiqueta de imagen. Página esperada: alrededor de 400 KB, la mitad del código para descargar y analizar. La cuestión es que este es exactamente el tipo de deriva que saca a la luz una auditoría automatizada, mientras que a la vista, en el editor, "solo parece una imagen".
La regla de decisión, la parte que hay que guardar
Una pregunta, tres respuestas.
- ¿Es una foto, una captura de pantalla, un render realista? No es tarea para SVG. Etiqueta de imagen en WebP, responsiva, con carga diferida si está fuera de pantalla.
- ¿Es vectorial, pero grande o complejo (una ilustración grande, muchos trazados, más de ~4 KB una vez optimizada)? Un archivo
.svgexterno, referenciado por una etiqueta de imagen, precargado si es importante y visible pronto. - ¿Es un icono pequeño, con pocos nodos, que quieres colorear o animar en CSS? El modo en línea es perfecto.
En caso de duda, externaliza. No pierdes casi nada, y ganas la caché más un DOM ligero.
Se lee como sano
Unos pocos trazos, un puñado de nodos, menos de 4 KB, coloreado o animado con CSS. Ponlo en línea y sigue adelante.
Se lee como una fuga
Cientos de trazados, decenas o cientos de KB en línea, o una cadena data:image/png;base64 dentro. Archivo externo, o WebP en una etiqueta de imagen.
La conclusión
Un SVG no es bueno ni malo. Lo que cuenta es el formato correcto en el lugar correcto. Las mismas tres letras pueden ser una pluma o un yunque según lo que haya dentro.
El reflejo diagnóstico: mira el peso del bloque y el número de trazados, no solo cómo se ve. Un logo que se renderiza nítido en pantalla puede seguir siendo un raster de 300 KB disfrazado.
Abrir el código de cada página para pesar cada SVG no es escalable. Mantys Core vigila este tipo de fuga en todo el sitio:
Señala los SVG en línea pesados y las imágenes raster disfrazadas de vector, la deriva que parece inocente en el editor.
Convierte a WebP las imágenes elegibles, define sus dimensiones y carga de forma diferida lo que está fuera de pantalla.
Mantiene mínimo lo que está por encima del pliegue y aplaza el resto, así una ilustración perdida en la parte baja de la página nunca penaliza el primer pintado.
Tú conservas el discernimiento. La plataforma hace la búsqueda página por página, así no tienes que abrir el código archivo por archivo.
Comentarios
¿Atascado con un problema parecido? Describa su configuración y lo que observa. Leemos cada comentario y respondemos.
Todavía no hay comentarios. Comparta el primero su caso.