Aby zmniejszyć liczbę żądań na serwerze, osadziłem niektóre obrazy (PNG i SVG) jako BASE64 bezpośrednio w css. (Jest zautomatyzowany w procesie kompilacji)
lubię to:
background: url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAFWHRTb2Z0d2FyZQBBZG etc...);
Czy to dobra praktyka? Czy są jakieś powody, aby tego uniknąć? Czy są jakieś popularne przeglądarki, które nie obsługują adresów URL?
Pytanie dodatkowe: czy ma sens robienie tego również dla CSS i JS?
Odpowiedzi:
Czy to dobra praktyka? Czy są jakieś powody, aby tego uniknąć?
Jest to dobra praktyka zwykle tylko dla bardzo małych obrazów CSS, które mają być używane razem (jak sprite CSS), gdy zgodność z IE nie ma znaczenia, a zapisanie żądania jest ważniejsze niż możliwość buforowania.
Ma wiele godnych uwagi wad:
W ogóle nie działa w IE6 i 7.
Działa tylko dla zasobów o rozmiarze do 32 KB w IE8 . To jest limit, który obowiązuje po kodowaniu base64. Innymi słowy, nie może mieć więcej niż 32768 znaków.
Zapisuje żądanie, ale zamiast tego powiększa stronę HTML! I sprawia, że obrazy stają się nieczytelne. Są ładowane za każdym razem, gdy ładowana jest zawierająca je strona lub arkusz stylów.
Kodowanie Base64 zwiększa rozmiary obrazów o 33%.
data:Obrazy podawane w zasobie spakowanym gzipem prawie na pewno będą strasznym obciążeniem dla zasobów serwera! Obrazy tradycyjnie wymagają bardzo dużej ilości procesora do kompresji, przy niewielkim zmniejszeniu rozmiaru.
Wydaje się, że typowe odpowiedzi sugerują, że nie jest to potrzebne z wielu uzasadnionych powodów. Jednak wszystko to wydaje się zaniedbywać zachowanie i proces tworzenia nowoczesnych aplikacji.
Nie jest niemożliwe (a właściwie całkiem łatwe) zaprojektowanie prostego procesu, który przejdzie przez obrazy folderów i wygeneruje pojedynczy plik CSS ze wszystkimi obrazami tego folderu.
Ten plik CSS zostanie w pełni zapisany w pamięci podręcznej i radykalnie zredukuje cykliczne podróże do serwera, co jest słusznie sugerowane przez @MemeDeveloper jako jeden z największych hitów wydajnościowych.
Jasne, to hack. bez wątpienia. tak samo jak sprite'y to hack. W idealnym świecie nie będzie to potrzebne, do tego czasu jest to możliwa praktyka, jeśli to, co musisz naprawić, to:
mój widok.
To nie jest dobra praktyka. Niektóre przeglądarki nie obsługują identyfikatorów URI danych (np. IE 6 i 7) lub ich obsługa jest ograniczona (np. 32 KB dla IE8).
Zobacz także ten artykuł w Wikipedii, aby uzyskać szczegółowe informacje na temat wad identyfikatora URI danych:
Niedogodności
- Identyfikatory URI danych nie są oddzielnie buforowane od dokumentów zawierających je (np. Plików CSS lub HTML), więc dane są pobierane za każdym razem, gdy dokumenty zawierające je są ponownie pobierane.
- Treść musi zostać ponownie zakodowana i ponownie osadzona za każdym razem, gdy wprowadzana jest zmiana.
- Internet Explorer w wersji 7 (około 15% rynku od stycznia 2011 r.) Nie jest obsługiwany.
- Internet Explorer 8 ogranicza identyfikatory URI danych do maksymalnej długości 32 KB.
- Dane są dołączane jako prosty strumień, a wiele środowisk przetwarzania (takich jak przeglądarki internetowe) może nie obsługiwać kontenerów (takich jak
multipart/alternativelubmessage/rfc822) w celu zapewnienia większej złożoności, takiej jak metadane, kompresja danych lub negocjacja treści.- Identyfikatory URI danych zakodowane algorytmem Base64 są o 1/3 większe niż ich odpowiedniki binarne. (Jednak ten narzut jest zmniejszony do 2-3%, jeśli serwer HTTP kompresuje odpowiedź za pomocą gzip)
- Identyfikatory URI danych utrudniają oprogramowaniu zabezpieczającemu filtrowanie treści.
Używałem data-uri przez około miesiąc i po prostu przestałem ich używać, ponieważ sprawiły, że moje arkusze stylów stały się absolutnie ogromne.
Data-uri działa w IE6 / 7 (wystarczy podać plik mhtml plik do tych przeglądarek).
Jedyną korzyścią, jaką uzyskałem z używania danych uri, było to, że moje obrazy tła renderowały się zaraz po pobraniu arkusza stylów, w przeciwieństwie do stopniowego ładowania, które widzimy inaczej
Fajnie, że mamy dostępną tę technikę, ale w przyszłości nie będę jej zbyt często używać. Zalecam jednak wypróbowanie tego, żebyś wiedział sam
Byłem bardziej skłonny używać CSS Sprites do łączenia obrazów i oszczędzania na żądaniach. Nigdy nie próbowałem techniki base64, ale najwyraźniej nie działa ona w IE6 i IE7. Oznacza to również, że jeśli jakiekolwiek obrazy się zmienią, musisz ponownie dostarczyć całość utraconą, chyba że masz oczywiście wiele plików CSS.
Nie mam pojęcia o ogólnych najlepszych praktykach, ale nie chciałbym widzieć tego typu rzeczy, gdybym mógł temu zaradzić. :)
Przeglądarki internetowe i serwery mają wbudowany cały ładunek pamięci podręcznej, więc pomyślałem, że najlepszym rozwiązaniem byłoby po prostu skłonienie serwera do poinformowania klienta, aby buforował pliki obrazów. O ile na stronie nie ma wielu naprawdę małych obrazów, nie pomyślałbym, że narzut wielu żądań jest tak duży. Przeglądarki zazwyczaj używają tego samego połączenia do żądania wielu plików, więc nie ma nowych połączeń sieciowych, więc jeśli natężenie ruchu przez nagłówki HTTP nie jest znaczące w porównaniu z rozmiarem plików obrazów, nie martwiłbym się zbytnio o wiele żądań .
Czy są powody, dla których sądzisz, że w tej chwili do serwera trafia zbyt wiele żądań?
Sugerowałbym to dla malutkich obrazków, które są używane bardzo często, na przykład typowe ikony aplikacji internetowych.
Oczywiście należy pamiętać o problemach z obsługą starszych przeglądarek. Dobrym pomysłem może być również wykorzystanie możliwości frameworka do automatycznego wstawiania obrazów i adresów URL danych, takich jak ClientBundle GWT, lub przynajmniej użycie klas CSS zamiast bezpośredniego dodawania go do stylu elementu.
Więcej informacji można znaleźć tutaj: http://davidbcalhoun.com/2011/when-to-base64-encode-images-and-when-not-to/