Herramientas de desarrollo · Codificador y decodificador Base64
Imágenes Base64 en línea en CSS: cuándo los datos: los URI ayudan y cuándo perjudican
· Por qué es importante
base64 rendimiento
Insertar una imagen como datos Base64: URI elimina una solicitud pero hace crecer el archivo y anula el almacenamiento en caché. Esta publicación explica cuándo vale la pena realizar la operación y cuándo un archivo separado es más rápido.
La hoja de estilo que creció a cientos de kilobytes: el hábito de incorporación de un equipo y cómo se manifestó en los tiempos de carga
Un equipo de desarrollo decidió que incluir íconos pequeños como datos Base64: URI en su CSS reduciría las solicitudes HTTP y mejoraría la velocidad de carga de la página. Con el tiempo, a medida que se agregaron más íconos, la hoja de estilo creció a 400 kilobytes.
El paquete CSS, que debería contener reglas de estilo, ahora está dominado por datos de imágenes. El equipo midió el tiempo de carga y descubrió que la página era más lenta que antes de la inserción, no más rápida. El problema quedó claro: la hoja de estilo de 400-kilobytes se descarga en cada carga de página y se almacena en caché por página, mientras que si los íconos fueran archivos separados, un solo archivo de ícono se almacenaría en caché y se compartiría en cada página.
Qué datos: URI en línea y por qué es Base64: la sintaxis, el tipo de medio y la penalización de tamaño
Agregar más páginas al sitio empeoró el problema, ya que cada página descarga nuevamente la misma hoja de estilo con todas esas imágenes incorporadas. Esta publicación explica qué es un dato: URI, por qué es Base64, cómo la inserción en línea afecta el almacenamiento en caché y el rendimiento, y las reglas generales para decidir cuándo vale la pena la compensación. Una URL de datos es una forma de incrustar un recurso directamente en un archivo HTML o CSS en lugar de vincularlo a un archivo externo. La sintaxis es datos: tipo de medio; base64, bytes_codificados.
El mediaType declara qué tipo de recurso sigue, como image/svg+xml para SVG, image/png para PNG o text/plain para texto. El indicador ;base64 indica que la carga útil está codificada en Base64 en lugar de texto codificado en porcentaje. Los codificados_bytes son los datos reales. Cuando un navegador encuentra una URL de datos: en una propiedad href, src o imagen de fondo, decodifica Base64 y presenta el recurso en línea. No se produce ninguna solicitud HTTP porque el recurso ya está ahí, incrustado en el documento principal. Esto ahorra una o varias solicitudes HTTP, lo cual es importante en un mundo HTTP/1.1 donde cada solicitud tiene una sobrecarga.
Almacenamiento en caché y ruta crítica: por qué los bytes insertados se descargan nuevamente con cada página que incluye la hoja de estilo
En un mundo HTTP/2 o HTTP/3 donde muchas solicitudes se pueden multiplexar en una conexión, los ahorros son menores. La penalización de tamaño de la codificación Base64 es inmediata y significativa. Un icono SVG que tiene 3 kilobytes cuando se guarda como un archivo XML se convierte en 4 kilobytes cuando está codificado en Base64 e incrustado como un dato: URI. El aumento de tamaño del 33% debido a la codificación se debe agregar a cada página que incluya la hoja de estilo. Si el ícono se usa en diez páginas, la hoja de estilo se descarga diez veces, cada vez incluyendo la misma imagen codificada de 4 kilobytes.
Si el ícono fuera un archivo separado, el original de 3 kilobytes se descargaría una vez y se almacenaría en caché, luego se usaría desde la caché en las diez páginas. La elección económica es clara para la mayoría de los iconos: los archivos separados son en general más pequeños. El beneficio de inserción se aplica solo cuando un ícono se usa exactamente en una página o en muy pocas páginas, y el ícono es realmente crítico para esa página. Un favicon que aparece en cada página es un mal candidato para insertarlo; es mejor como un archivo en caché separado.
Costos de análisis en el cliente: qué tan grandes son las cadenas en línea que manejan los analizadores CSS y HTML, descritos cualitativamente
Una ilustración única utilizada solo en una página de destino podría beneficiarse de incluirla para guardar una solicitud. El almacenamiento en caché anula la mayoría de los beneficios de insertar datos: URI en hojas de estilo. Una hoja de estilo suele almacenarse en caché durante días o semanas. Cuando se descarga la hoja de estilo, todos los recursos incluidos en ella se descargan nuevamente, incluso si el navegador ya tiene esa imagen en caché. Si se actualiza la hoja de estilo, todos los datos incorporados se deben revalidar o volver a descargar, incluso si solo se cambió una regla CSS.
Esto provoca hinchazón: los cambios en los colores o el espaciado provocan una nueva descarga completa de la hoja de estilo, incluidos los kilobytes de datos de imagen que no cambiaron. Un archivo de imagen independiente se puede almacenar en caché de forma independiente con sus propios encabezados de caducidad, actualizarse por separado y reutilizarse en hojas de estilo y páginas. La caché del navegador es mucho más eficiente cuando los recursos son archivos separados que cuando están incrustados en documentos más grandes. Los costos de análisis y renderizado aumentan cuando se incrustan grandes cadenas Base64 en hojas de estilo. Un analizador de CSS debe leer la hoja de estilo completa antes de aplicar las reglas.
Ejemplo resuelto: insertar un pequeño icono SVG como texto: pegar el marcado en el codificador y ensamblar los datos: URI a mano
Una hoja de estilo de 400 kilobytes con Base64 incorporado son 400 kilobytes de texto que se deben analizar antes de que se pueda aplicar cualquier regla. Un analizador HTML que representa una página con una gran cantidad de datos: URI en un atributo de estilo o una propiedad de imagen de fondo debe decodificar Base64 y construir la imagen antes de que el elemento pueda renderizarse. Para iconos SVG simples esto es trivial. Para imágenes más complejas o íconos más grandes, la decodificación y la representación se realizan en el hilo principal, lo que potencialmente bloquea la interactividad. El costo cualitativo es real pero difícil de medir sin elaborar perfiles.
Como regla general, si la imagen incorporada tiene un tamaño superior a unos pocos kilobytes, los archivos separados son más rápidos. Un ejemplo resuelto muestra la compensación exacta. Tome un icono de flecha SVG simple, 1.2 kilobytes de XML. Codificado en Base64 se convierte en 1600 caracteres, o alrededor de 1.6 kilobytes con los datos: prefijo de URL. Una regla CSS separada con imagen de fondo: url(/icons/arrow.svg) agrega quizás 40 bytes a la hoja de estilo. El archivo del ícono se descarga una vez, se almacena en caché y se reutiliza. La inserción guarda una solicitud HTTP para ese ícono pero agrega 1.6 kilobytes a cada carga de la hoja de estilo.
Reglas generales que se mantienen: activos pequeños, críticos y de un solo uso en línea; todo lo demás como un archivo
Si la hoja de estilo tiene 50 kilobytes y se comparte en 20 páginas, al insertar ese icono la descarga total aumenta en 32 kilobytes por visita al sitio. La solicitud HTTP que guarda tiene como máximo unos cientos de bytes de sobrecarga. La solicitud también se multiplexa automáticamente en HTTP/2, eliminando la diferencia de gastos generales. El comercio en línea pierde mucho a menos que la hoja de estilo sea pequeña, el ícono sea enorme o el ícono aparezca exactamente en una página y en ningún otro lugar. Las reglas generales que sobreviven al escrutinio son limitadas y específicas.
Se pueden incorporar activos pequeños, críticos y de un solo uso. Se puede incluir una flecha SVG de 200 bytes que aparece solo en una página inusual para ahorrar la sobrecarga de la solicitud. Todo lo demás debería estar separado. La lógica de la ruta de renderizado crítica es importante: si un ícono debe ser visible inmediatamente y cada milisegundo de tiempo de carga cuesta conversión, la inserción en línea podría ganar. Para páginas típicas con íconos típicos, los archivos separados casi siempre son mejores. Pruebe ambos enfoques con sus activos reales y mida la carga de la página, las tasas de aciertos de la caché y la cascada de solicitudes.
Lo que esto no cubre: detalles de multiplexación HTTP/2 y HTTP/3 y compresión de formato de imagen
No asuma que la inserción es una optimización sin medición. La forma más fácil de terminar con una hoja de estilo inflada es alinearla de forma incremental sin medir si cada adición es realmente más rápida. El codificador y decodificador Base64 le ayuda a tomar esta decisión antes de comprometerse con la integración. Pegue su marcado SVG u otra fuente de ícono en la herramienta como texto. Haga clic en Codificar y configure las opciones para generar un dato: URI. La herramienta te muestra la longitud exacta de los datos: URL. Compare eso con el tamaño de una regla CSS separada y el archivo de activos en sí.
Calcule cuántas páginas se necesitarían compartir la hoja de estilo para alcanzar el punto de equilibrio en archivos integrados versus archivos separados. Reúna los datos: URI y pruébelo en una página HTML real antes de enviarlo a la hoja de estilo. Si el URI tiene más de unos pocos cientos de caracteres, es probable que el costo de incrustarlo sea mayor que el beneficio de guardar una solicitud. Utilice la herramienta para probar sus íconos y activos reales, luego mida el impacto en las métricas de carga de su página real antes y después de la inserción.
Conclusión: en línea con moderación y medición: cómo el codificador y descodificador Base64 le permite codificar el marcado SVG y ver el tamaño exacto antes de confirmar
El enfoque de rendimiento es ser selectivo acerca de la inserción. Los iconos utilizados en cada página o en muchas páginas son archivos almacenados en caché separados. Los íconos utilizados exactamente en una página o que son realmente críticos para la primera pintura se pueden incluir en línea. Mida la compensación de sus activos y páginas reales en lugar de seguir consejos genéricos. Utilice el codificador y decodificador Base64 para ver el tamaño exacto de cualquier recurso incorporado antes de agregarlo a una hoja de estilo. La penalización por tamaño es real y se multiplica en cada página vista.
El almacenamiento en caché y la multiplexación de solicitudes han hecho que el beneficio original de la inserción sea menos importante. Para la mayoría de las aplicaciones modernas, las hojas de estilo más pequeñas y una mejor eficiencia de la caché de archivos separados compensan la sobrecarga de la solicitud. En línea con moderación, mida el resultado y confíe en la medición por encima de la intuición.