html - data - image url to base64

¿Por qué utilizar el esquema de URI de datos? (5)

De acuerdo con Wikipedia :

Ventajas:

No se requiere tráfico de encabezado y solicitud HTTP para datos incrustados, por lo que los URI de datos consumen menos ancho de banda siempre que la sobrecarga de codificación del contenido en línea como un URI de datos sea menor que la sobrecarga HTTP. Por ejemplo, la codificación base64 necesaria para una imagen de 600 bytes de longitud sería de 800 bytes, por lo que si una solicitud HTTP requería más de 200 bytes de sobrecarga, el URI de datos sería más eficiente.
Para transferir muchos archivos pequeños (menos de unos pocos kilobytes cada uno), esto puede ser más rápido. Las transferencias de TCP tienden a comenzar lentamente. Si cada archivo requiere una nueva conexión TCP, la velocidad de transferencia está limitada por el tiempo de ida y vuelta en lugar del ancho de banda disponible. El uso de HTTP keep-alive mejora la situación, pero puede no aliviar por completo el cuello de botella.
Al navegar por un sitio web seguro de HTTPS, los navegadores web comúnmente requieren que todos los elementos de una página web se descarguen a través de conexiones seguras, o se le notificará al usuario una seguridad reducida debido a una combinación de elementos seguros e inseguros. En servidores mal configurados, las solicitudes HTTPS tienen una sobrecarga significativa sobre las solicitudes HTTP comunes, por lo que incrustar datos en URI de datos puede mejorar la velocidad en este caso.
Los navegadores web generalmente están configurados para hacer solo un cierto número (a menudo dos) de conexiones HTTP simultáneas a un dominio, de modo que los datos en línea liberan una conexión de descarga para otro contenido.
Los entornos con acceso limitado o restringido a recursos externos pueden incrustar contenido cuando no se permite o no es práctico hacer referencia externamente. Por ejemplo, un campo de edición de HTML avanzado podría aceptar una imagen pegada o insertada y convertirla a un URI de datos para ocultar la complejidad de los recursos externos del usuario. Alternativamente, un navegador puede convertir (codificar) datos basados en imágenes del portapapeles a un URI de datos y pegarlo en un campo de edición de HTML. Mozilla Firefox 4 es compatible con esta funcionalidad.
Es posible administrar una página multimedia como un solo archivo. Las plantillas de mensajes de correo electrónico pueden contener imágenes (para fondos o firmas) sin que la imagen parezca ser un "archivo adjunto".

Desventajas:

Los URI de datos no se almacenan en caché por separado de sus documentos que contienen (por ejemplo, CSS o archivos HTML), por lo que los datos se descargan cada vez que se vuelven a descargar los documentos. El contenido debe volver a codificarse y volver a incrustarse cada vez que se realice un cambio.
Internet Explorer hasta la versión 7 (aproximadamente el 15% del mercado a partir de enero de 2011), carece de soporte. Sin embargo, esto puede superarse al servir contenido específico del navegador. Internet Explorer 8 limita los URI de datos a una longitud máxima de 32 KB.
Los datos se incluyen como una secuencia simple, y muchos entornos de procesamiento (como los navegadores web) pueden no admitir el uso de contenedores (como multipart / alternative o message / rfc822) para proporcionar una mayor complejidad como metadatos, compresión de datos o negociación de contenido.
Los URI de datos codificados en Base64 son 1/3 de mayor tamaño que su equivalente binario. (Sin embargo, esta sobrecarga se reduce a 2-3% si el servidor HTTP comprime la respuesta usando gzip). Los URI de datos dificultan que el software de seguridad filtre el contenido.

Según otras fuentes , las URL de datos son significativamente más lentas en los navegadores móviles.

Básicamente, la pregunta está en el título.

Muchas personas han tenido la pregunta stackoverflow de cómo crear un URI de datos y problemas en él.

Mi pregunta es ¿por qué usar el URI de datos?

¿Cuáles son las ventajas de hacer?

<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUA AAAFCAYAAACNbyblAAAAHElEQVQI12P4//8/w38GIAXDIBKE0DHxgljNBAAO 9TXL0Y4OHwAAAABJRU5ErkJggg==" alt="Red dot" />

Sobre hacer:

<img src="dot.png" alt="Red dot" />

Entiendo que uno tiene menos sobrecarga en el lado del servidor (tal vez), pero ¿cuáles son las ventajas / desventajas reales del uso del URI de datos ?

Estoy de acuerdo con que el valor real de los URI de datos es hacer que el contenido generado por el cliente esté disponible como descarga de archivos sin necesidad de viajes de ida y vuelta del servidor.

Un ejemplo práctico de uso de URI de datos para "ofrecer la descarga de una tabla como CSV" se describe en mi blog .

En mi humilde opinión, la incrustación de datos de imágenes (u otros recursos binarios) en un archivo HTML por motivos de rendimiento es una pista falsa. El aumento de velocidad debido a menos conexiones HTTP es insignificante y rompe el agradable principio de separación entre el marcado (textual) y los recursos binarios (archivos de imágenes, videos, etc.).

Creo que la canalización de HTTP 1.1 y algunas mejoras sugeridas para HTTP son una forma más limpia y mejor para manejar los problemas de velocidad de la red HTTP.

He utilizado el esquema de URI de datos en varias aplicaciones de línea de comandos (C ++, Python) para generar informes que incluyen gráficas de datos.

Tener un solo archivo es muy conveniente para enviar los informes por correo electrónico (o moverlos en general). Comparado con el PDF, no necesitaba una biblioteca adicional (aparte de una rutina de codificación base64) y no necesito ocuparme de los saltos de página (y casi nunca necesito imprimir estos informes). Normalmente no pongo estos informes en un servidor web, simplemente los veo en el sistema de archivos local con un navegador.

Principalmente encuentro el uso de esto si no puedo (por alguna razón) usar sprites de CSS y no quiero descargar cada pequeña imagen que usaré para diseñar.

O por alguna razón, no desea que nadie vincule la imagen desde una página externa. Esto se puede lograr con otras metodologías pero también con trabajos de integración.

De lo contrario, personalmente no codificaría imágenes grandes como fotos. Es mejor tener tus medios en un servidor diferente. Un servidor que puede carecer de todo el software relacionado con el servidor web instalado. Simplemente entregando medios. Mucho mejor uso de los recursos.

Un buen uso del URI de datos permite la descarga de contenido generado por el lado del cliente, sin recurrir a un "proxy" del lado del servidor. Aquí hay algunos ejemplos en los que puedo pensar:

guardando la salida de un elemento canvas como una imagen.
ofreciendo la descarga de una tabla como CSV
descarga de salida de cualquier tipo de editor en línea (texto, dibujo, código CSS ... etc.)