Penso che sia trascurabile in questo momento .. (? Un'immagine che è piccolo)
Tuttavia, ci sono alcune altre cose da considerare:
- Ci sarà il possiblity di più immagini in futuro ?
- 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
fonte
2010-07-10 01:54:38
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. –
@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