2009-09-24 12 views
5

Sto cercando di decidere il modo migliore per includere un'immagine che è richiesta per uno script che ho scritto.Utilizzo di un file immagine vs URI di dati nel CSS

ho scoperto this site e mi ha fatto pensare a provare questo metodo per includere l'immagine come data URI (definito da RFC 2397) dato che era così piccola - è una 1x1 pixel del 50% di opacità png di file (utilizzato per uno sfondo) - finisce a 2792 byte come immagine contro 3.746 byte come testo nel CSS.

Quindi questo sarebbe buona norma, o sarebbe semplicemente ingombrare il CSS inutilmente?

risposta

4

Non credo che otterrete molto ... e se si tratta di un'immagine di file, il browser può memorizzarlo nella cache. Non mi preoccuperei di farlo con i CSS a meno che tu non ne abbia una reale necessità.

20

C'è una buona ragione per usare un URI di dati, piuttosto che l'immagine.

Il Data URI è codificato base 64, che significa che è circa il 25% più grande dell'immagine. Tuttavia il tuo file CSS può essere memorizzato nella cache, quindi l'aumento di dimensioni ridotte probabilmente non è un grosso problema.

Se si dispone di un sacco di immagini c'è un overhead per la ricerca di ciascuno di essi, sia in termini di risoluzione dei nomi e ottenere l'immagine come un'altra risorsa.

Tutto ciò significa che se le immagini sono di piccole dimensioni e il file CSS complessivo è ancora piccolo e il CSS è condiviso tra le pagine che vengono colpite spesso, si ottengono prestazioni se si passa agli URI di dati.

Lo svantaggio è che funzionano solo in FX, Chrome, ecc parzialmente lavorare in IE8, ma solo per piccole immagini. Non funzionano affatto in IE7 o sotto.

+0

Si dice che il file css verrà memorizzato nella cache, ma c'è un aspetto negativo se davvero pensate. Quando si raggruppa il file css, si ottiene il nuovo css e il vecchio css è invalidato. Potresti aver salvato quei byte aggiuntivi memorizzando l'immagine separatamente nella cache. –

+0

@JaspreetSingh dipende molto da come si impacchetta il CSS - i visitatori non dovrebbero ancora recuperare il CSS ad ogni visita, e la cache o il lavoratore del servizio dovrebbero tenere tra una visita e l'altra (se la versione non è cambiata) . È davvero una questione di larghezza di banda e ping: il file CSS è più grande ma ti risparmia un round trip per l'immagine. Il più delle volte non è sufficiente un overhead per valere i byte extra, ma non sempre. – Keith

4

Penso che sia trascurabile in questo momento .. (? Un'immagine che è piccolo)

Tuttavia, ci sono alcune altre cose da considerare:

  1. Ci sarà il possiblity di più immagini in futuro ?
  2. gZip i file css?

Ragione di essere ..
Per ogni immagine caricata nella CSS è uno in meno chiamata al server, che richiede tempo. Lo sappiamo tutti dagli sprite. Anche uno sprite di dimensioni maggiori, rispetto a tutte le immagini combinate, è preferibile. Ciò significa che ogni immagine aggiunta, è un potenziale rallentamento in meno, se si utilizzano i dati: URI.

e per la seconda domanda .. dati: URI è MOLTO gZip friendly. Intendo MOLTO. Abbiamo alcuni file css legacy che sono enormi. 109 kb enorme .. e quando noi dati: URI l'immagine, che si gonfia in un enorme 246 kb! Dopo gZipping, siamo giù a 126 kb.

Per non parlare .. sprite non sono divertenti da mantenere, ma non v'è molto meno ragione di sprite se si sta utilizzando i dati: URI.

Spero che questo aiuti.

PS. un link riguardante i dati: URI. http://www.nczonline.net/blog/2010/07/06/data-uris-make-css-sprites-obsolete/#comment-5800

PS PS di controllo nella parte inferiore della pagina, per saperne di più Nicolas ha da dire su dati: URI

1

Using Data URIs si riferisce a Data URIs make CSS sprites obsolete e si estende l'utilizzo dello strumento CSSEmbed creando un passaggio di generazione Ant . CSSEmbed "supporta anche una modalità MHTML per creare fogli di stile compatibili con IE6 e IE7 che utilizzano immagini interne simili agli URI di dati."

Inoltre, quando si confrontano i byte dei file immagine con i byte codificati base64, non dimenticare che ogni richiesta/risposta di immagine http ha l'overhead dei byte delle intestazioni http. Questo esempio contro Yahoo consuma circa 900 byte (ho modificato il nome del proxy su example.com). Inoltre, il dominio yimg.com è ottimizzato per non avere cookie e salvare quei potenziali byte.

GET http://l.yimg.com/a/i/ww/met/yahoo_logo_us_061509.png HTTP/1.1 
Accept: */* 
Referer: http://www.yahoo.com/ 
Accept-Language: en-US 
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; GTB6.5; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; InfoPath.2; OfficeLiveConnector.1.3; OfficeLivePatch.0.0; .NET4.0C; .NET4.0E) 
Accept-Encoding: gzip, deflate 
Host: l.yimg.com 
Proxy-Connection: Keep-Alive 

HTTP/1.0 200 OK 
Date: Sat, 31 Jul 2010 22:27:25 GMT 
Cache-Control: max-age=315360000 
Expires: Tue, 28 Jul 2020 22:27:25 GMT 
Last-Modified: Wed, 16 Jun 2010 18:06:49 GMT 
Accept-Ranges: bytes 
Content-Length: 1750 
Content-Type: image/png 
Age: 321472 
Server: YTS/1.17.23.1 
X-Cache: MISS from a-proxy-server.example.com 
Via: 1.0 a-proxy-server.example.com:80 (squid/2.6.STABLE22) 
Proxy-Connection: keep-alive 
0

Quando utilizzare i dati URI

Quando viene utilizzato al posto di uno sprite immagine, URI di dati salvare una singola richiesta HTTP, e ogni piccolo conta bit. Tuttavia sono ancora più utili per le immagini che sono difficili da includere nei fogli sprite, ad esempio i punti elenco personalizzati che richiedono una quantità variabile di spazi bianchi.

Sebbene gli URI di dati siano un modo eccellente per ridurre le richieste HTTP, non ha senso utilizzarli in ogni situazione. Dal momento che incorporano i dati del file non elaborato direttamente nel foglio di stile, gli URI dei dati possono portare al gonfiamento del foglio di stile se vengono utilizzati in modo pesante.

Di seguito sono riportati alcuni collegamenti utili.

http://jonraasch.com/blog/css-data-uris-in-all-browsers

http://www.phpied.com/mhtml-when-you-need-data-uris-in-ie7-and-under/

Problemi correlati