Szukałem źródła skryptu użytkownika fatmonkey i zauważyłem w swoim cs

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

Rozumiem, że skrypt fatmonkey chciałby spakować wszystko, co może w źródle, zamiast hostować go na serwerze, co jest dość oczywiste. Ponieważ jednak wcześniej nie widziałem tej techniki, rozważałem jej zastosowanie i wydaje się ona atrakcyjna z wielu powodów:

Zmniejszy to liczbę żądań HTTP przy ładowaniu strony, zwiększając w ten sposób wydajnośćJeśli nie ma CDN, spowoduje to zmniejszenie ruchu generowanego przez pliki cookie wysyłane obok obrazówliki @CSS można buforowaćliki @ CSS mogą być GZIPPED

Biorąc pod uwagę, że IE6 (na przykład) ma problemy z pamięcią podręczną obrazów tła, wydaje się, że nie jest to najgorszy pomysł ...

Czy to dobra lub zła praktyka, dlaczego NIE MOŻESZ jej używać i jakich narzędzi używałbyś do kodowania obrazów w base64?

update - wyniki testowania

testing with image:http: //fragged.org/dev/map-shot.jp - 133,6 KB

test URL:http: //fragged.org/dev/base64.htm

dedykowany plik CSS:http: //fragged.org/dev/base64.cs - 178.1Kb

Serwer kodowania GZIP po stronie

wynik wysłany do klienta (test komponentów YSLOW): 59,3Kb

Zapisywanie danych wysyłanych do przeglądarki klienta: 74.3Kb

Miło, ale myślę, że będzie to nieco mniej przydatne w przypadku mniejszych obrazów.

UPDATE: Bryan McQuade, inżynier oprogramowania w Google, pracujący nad PageSpeed, wyraził na ChromeDevSummit 2013, że dane: uris w CSS jest uważany za anty-wzorzec blokujący renderowanie w celu dostarczenia krytycznego / minimalnego CSS podczas jego rozmowy#perfmatters: Instant mobile web apps. Widziećhttp: //developer.chrome.com/devsummit/session i pamiętaj o tym - aktualny slajd