una poner pantalla insertar imagen hoja fondo estilo div data completa como ajustar css base64 background-image data-uri

poner - ¿Es una buena o mala práctica incorporar datos de imagen de fondo en CSS como Base64?



imagen de fondo html5 (12)

Estaba buscando en la fuente de un script de greasemonkey y noté lo siguiente en su css:

.even { background: #fff url(data:image/gif;base64,R0lGODlhBgASALMAAOfn5+rq6uvr6+zs7O7u7vHx8fPz8/b29vj4+P39/f///wAAAAAAAAAAAAAAAAAAACwAAAAABgASAAAIMAAVCBxIsKDBgwgTDkzAsKGAhxARSJx4oKJFAxgzFtjIkYDHjwNCigxAsiSAkygDAgA7) repeat-x bottom}

Puedo apreciar que un script de greasemonkey querría agrupar todo lo que pueda dentro de la fuente en lugar de alojarlo en un servidor, eso es lo suficientemente obvio. Pero como no había visto esta técnica anteriormente, consideré su uso y me parece atractivo por varias razones:

  1. Reducirá la cantidad de solicitudes HTTP en la carga de la página, mejorando así el rendimiento
  2. Si no hay CDN, reducirá la cantidad de tráfico generado a través de las cookies que se envían junto con las imágenes
  3. Los archivos CSS se pueden almacenar en caché
  4. Los archivos CSS pueden ser GZIPPED

Teniendo en cuenta que IE6 (por ejemplo) tiene problemas con la memoria caché para las imágenes de fondo, parece que no es la peor idea ...

Entonces, ¿es esta una buena o mala práctica, por qué NO lo usarías y qué herramientas usarías para codificar las imágenes en base64?

actualización - resultados de las pruebas

Bien, pero será un poco menos útil para imágenes más pequeñas, supongo.

ACTUALIZACIÓN: Bryan McQuade, ingeniero de software de Google, que trabaja en PageSpeed, expresó en ChromeDevSummit 2013 que data: uris en CSS se considera un anti-patrón de bloqueo de procesamiento para entregar CSS crítico / mínimo durante su charla #perfmatters: Instant mobile web apps . Consulte http://developer.chrome.com/devsummit/sessions y tenga eso en cuenta: diapositiva real


Base64 agrega aproximadamente un 10% al tamaño de la imagen después de GZipped, pero eso supera los beneficios cuando se trata de dispositivos móviles. Dado que existe una tendencia general con un diseño web sensible, es altamente recomendable.

W3C también recomienda este enfoque para dispositivos móviles y, si utiliza la canalización de activos en rieles, esta es una característica predeterminada al comprimir su css

http://www.w3.org/TR/mwabp/#bp-conserve-css-images


En mi caso, me permite aplicar una hoja de estilo CSS sin preocuparme por copiar las imágenes asociadas, ya que ya están incrustadas dentro.


Gracias por la información aquí. Considero que esta incrustación es útil y especialmente para dispositivos móviles, especialmente con el archivo css de las imágenes incrustadas que se almacena en caché.

Para ayudar a que la vida sea más fácil, ya que mis editores de archivos no manejan esto de forma nativa, hice un par de scripts simples para el trabajo de edición de computadora portátil / escritorio, y los comparto aquí en caso de que sean de alguna utilidad para cualquier otra persona. Me he quedado con php ya que está manejando estas cosas directamente y muy bien.

En Windows 8.1 diga ---

C:/Users/`your user name`/AppData/Roaming/Microsoft/Windows/SendTo

... allí, como administrador, puede establecer un acceso directo a un archivo por lotes en su ruta. Ese archivo por lotes llamará a un script php (cli).

A continuación, puede hacer clic con el botón derecho en una imagen en el explorador de archivos y en Enviar al archivo por lotes.

Acepte la solicitud de Admiinstartor y espere a que se cierren las ventanas negras del shell de comandos.

Luego simplemente pegue el resultado del portapapeles en su editor de texto ...

<img src="|">

o

`background-image : url("|")`

Lo siguiente debe ser adaptable para otros sistemas operativos.

Archivo por lotes...

rem @echo 0ff rem Puts 64 encoded version of a file on clipboard php c:/utils/php/make64Encode.php %1

Y con php.exe en su ruta, eso llama a un script php (cli) ...

<?php function putClipboard($text){ // Windows 8.1 workaround ... file_put_contents("output.txt", $text); exec(" clip < output.txt"); } // somewhat based on http://perishablepress.com/php-encode-decode-data-urls/ // convert image to dataURL $img_source = $argv[1]; // image path/name $img_binary = fread(fopen($img_source, "r"), filesize($img_source)); $img_string = base64_encode($img_binary); $finfo = finfo_open(FILEINFO_MIME_TYPE); $dataType = finfo_file($finfo, $img_source); $build = "data:" . $dataType . ";base64," . $img_string; putClipboard(trim($build)); ?>


Intenté crear un concepto en línea de herramienta analizador de CSS / HTML:

http://www.motobit.com/util/base64/css-images-to-base64.asp

Puede:

  • Descargue y analice archivos HTML / CSS, extraiga elementos href / src / url
  • Detectar datos de compresión (gzip) y tamaño en la URL
  • Compare el tamaño de los datos originales, el tamaño de los datos base64 y el tamaño de los datos base64 comprimidos.
  • Convierta la URL (imagen, fuente, css, ...) en un esquema URI de datos base64.
  • Cuente el número de solicitudes que pueden evitarse con los URI de datos

Comentarios / sugerencias son bienvenidos.

Antonin


No es una buena idea cuando desea que las imágenes y la información de estilo se almacenen en caché por separado. Además, si codifica una imagen grande o una cantidad significativa de imágenes en su archivo css, el navegador tardará más en descargar el archivo, dejando su sitio sin ninguna información de estilo hasta que se complete la descarga. Para imágenes pequeñas que no pretende cambiar a menudo, si alguna vez es una buena solución.

En cuanto a generar la codificación base64:


No estoy de acuerdo con la recomendación de crear archivos CSS separados para imágenes no editoriales.

Suponiendo que las imágenes son para fines de la interfaz de usuario, es el estilo de la capa de presentación, y como se mencionó anteriormente, si está haciendo una interfaz de usuario móvil, es definitivamente una buena idea mantener todo el estilo en un solo archivo para que pueda guardarse en caché una vez.


Por lo que he investigado,

Uso: 1. Cuando está utilizando un sprite svg. 2. Cuando sus imágenes son de menor tamaño (máximo 200 mb).

No uses: 1. Cuando seas imágenes más grandes. 2. Iconos como svg''s. Como ya están bien y gzip después de la compresión.


Puedes codificarlo en PHP :)

<img src="data:image/gif;base64,<?php echo base64_encode(file_get_contents("feed-icon.gif")); ?>"> Or display in our dynamic CSS.php file: background: url("data:image/gif;base64,<?php echo base64_encode(file_get_contents("feed-icon.gif")); ?>"); 1 That’s sort of a “quick-n-dirty” technique but it works. Here is another encoding method using fopen() instead of file_get_contents(): <?php // convert image to dataURL $img_source = "feed-icon.gif"; // image path/name $img_binary = fread(fopen($img_source, "r"), filesize($img_source)); $img_string = base64_encode($img_binary); ?>

Source


Si hace referencia a esa imagen solo una vez, no veo un problema para incrustarla en su archivo CSS. Pero una vez que use más de una imagen o necesite hacer referencia a ella varias veces en su CSS, puede considerar usar un mapa de una sola imagen, en lugar de eso puede recortar sus imágenes individuales (consulte CSS Sprites ).


Trayendo un poco para los usuarios de Sublime Text 2, hay un complemento que le da al código base64 que cargamos las imágenes en el ST.

Llamado Image2base64: https://github.com/tm-minty/sublime-text-2-image2base64

PS: Nunca guarde este archivo generado por el complemento porque sobrescribiría el archivo y lo destruiría.


Una de las cosas que sugeriría es tener dos hojas de estilo separadas: una con sus definiciones de estilo normales y otra que contenga sus imágenes en codificación base64.

Tienes que incluir la hoja de estilo base antes de la hoja de estilo de imagen, por supuesto.

De esta manera, se asegurará de que su hoja de estilo regular se descargue y se aplique lo antes posible al documento, y al mismo tiempo se beneficie de la reducción de solicitudes de http y otros beneficios que le brindan los datos que urge.


Esta respuesta está desactualizada y no debe utilizarse.

1) La latencia media es mucho más rápida en dispositivos móviles en 2017. https://opensignal.com/reports/2016/02/usa/state-of-the-mobile-network

2) Multiplexores HTTP2 https://http2.github.io/faq/#why-is-http2-multiplexed

Los "URI de datos" definitivamente deberían ser considerados para sitios móviles. El acceso HTTP a través de redes celulares viene con una mayor latencia por solicitud / respuesta. Por lo tanto, hay algunos casos de uso en los que el atasco de sus imágenes como datos en plantillas CSS o HTML podría ser beneficioso para las aplicaciones web móviles. Debería medir el uso caso por caso. No estoy abogando por que los URI de datos se usen en todas partes en una aplicación web móvil.

Tenga en cuenta que los navegadores móviles tienen limitaciones en el tamaño total de los archivos que se pueden almacenar en caché. Los límites para iOS 3.2 eran bastante bajos (25K por archivo), pero se están haciendo más grandes (100K) para las versiones más recientes de Mobile Safari. Así que asegúrese de mantener un ojo en el tamaño total de su archivo cuando incluya URI de datos.

http://www.yuiblog.com/blog/2010/06/28/mobile-browser-cache-limits/