Czy osadzasz dane obrazu tła w CSS jako dobrą lub złą praktykę Base64?
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ć GZIPPEDBiorą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