[CSS] background: url(data:image/ ...., czyli odejście od obrazków Opcje

[wNogachSpisz]

Ostatnio eksperymentuje z nowym (nowym dla mnie) podejściem do elementów graficznych layoutu strony.
Obrazki przechowuje w plikach .css w stylach background: url(data:image/png;base64,iVBORw0KGgo......)
zakodowane w base64..

Plusy:
- łatwiejsze grupowanie, znika potrzeba tworzenia map obrazków, nie pamiętam jak ta technika się nazwała, chodzi o to, że kiedy mamy wiele obrazków o małej wielkości, to celem unikniecia wielu połączeń z serweram, tworzymy jeden obrazek zawierający wszystkie mniejsze jeden obok drugiego, a potem przy pomocy stylu CSS background-position osadzamy je w dokumecie. Trzymając je w plikach .css ten problem znika
- omijamy algorytmy kompresujące na serwerach proxy, może to problem dotyczący niewielkiej ilości odwiedzających, ale z doświadczenia wiem, że np. sieci komórkowe obligatoryjnie kompresują wszystkie jpegi, przez co strona wygląda okropnie. Ten problem z pewnością będzie narastał w przyszłości.
- łatwiejsze zarządzenie cachowaniem HTTP,
- mniejsza ilość połączeń do serwera - oszczędność transferu
- szybsze ładowanie strony, mniej elementów do pobrania czy sprawdzenia aktualności cachu..

Minusy:
- 3-4% narzut wielkości (base64) - częściowo rekompensowany zmniejszoną ilością połączeń
- rozwiązanie mało konwencjonalne, przez co prawdopodobnie, gdzieś tam w świecie, jest platforma która tego nie wspiera (może jakieś urządzenie mobilne?)
- i jeszcze raz technika mało konwencjonalna, więc potencjalnie gorzej zoptymalizowana w przeglądarkach, przez co wolniejsza

Warto nie przekraczać granic absurdu, nie ma sensu galerii zdjęć ładować do plików .css
Jednak moim zdaniem jest to jest dobre miejsce dla wszystkich elementów graficznych podstawowego layoutu strony.


A jakie jest Wasze zdanie?

Ten post edytował wNogachSpisz 26.05.2011, 00:07:58

[thek]

JPEG, PNG, PNG-semi-transparent, GIF

Zapomniałeś jeszcze o bmp i kilku innych, które obsługują przeglądarki (jak choćby animowany png). Ale mam wrażenie, że "nie rozumiem pytania" dla wielu osób świadczy nie o tym, że tego nie rozumiesz, ale że nie chcesz zrozumieć. Gdyby było inaczej samodzielnie byś potrafił podejść do problemu i stwierdzenia danej osoby. Inna sprawa, że w wielu przypadkach z gifa można na rzecz png zrezygnować i jest on mniejszy. No ale do tego trzeba nieco wiedzieć o optymalizacji grafiki, której to wiedzy najprawdopodobniej Ci nieco brakuje. Dlatego ostatecznie do wyboru masz tylko png, jpg i czasem gif dla animacji oraz kwestia zastanowienia co będzie w danej sytuacji lepszym rozwiązaniem.

Przykładem tego jest poprawianie czegoś, co w efekcie i tak wychodzi na to samo lub gorsze w efekcie. Z jednej strony postulujesz swoje rozwiązanie jako mające redukować liczbę połączeń do serwisu, a już kilka postów gdy wytyka Ci się wady rozwiązania piszesz, że uniknąć tego można... zwiększając liczbę odwołań do serwera poprzez podział na kilka plików css. Tak. Super rozwiązanie, które prowadzi do punktu wyjścia (IMG:style_emoticons/default/wink.gif) Tyle że zamiast iluś obrazków masz ileś plików css z zakodowanymi danymi jako base64. Pewne dane choćby nie wiem co robić są już niezwykle trudne do kompresji i zużywanie pamięci lub czasu procesora na próbę tego jest zwyczajną głupotą. Dlatego kompresji poddaje się jedynie pliki tekstowe, ale już grafikę nie. I dla testów weź sobie plik jpg zobacz ile ma, a potem zrób z niego base64 i spróbuj gzipować (bo tak zrobi serwis przy próbie wysyłki css) oraz porównaj rozmiary, a zobaczysz bezsens swojego rozwiązania. Każdy czytający ten temat od początku dojdzie do tego co właśnie napisałem i stwierdzi, że sam się pogubiłeś w tym co piszesz już. Użycie sprite'ów jest znacznie wygodniejsze, a to co Ty proponujesz (base64) używane jest jedynie w przypadku niewielkich grafik, ale dla czegoś co ma być już zastępstwem dla sprite'ów jest po prostu marnotrastwem łącza i mocy serwera. Zamiast bowiem zaserwować od razu dane jako sprite i właściwy css, które to mogą iść jako osobne połączenia niezależnie, walisz kilka plików CSS w najgorszym wypadku, a CSS są przetwarzane kaskadowo i na serwerze jeszcze będą gzipowane a po stronie usera dekompresowane, przetwarzane i dopiero wyświetlane. Nie tylko masz gorsze parametry od zrobionego z głową sprite'a, ale jeszcze serwer i klienta zmuszasz do dodatkowej pracy. Świetne rozwiązanie - nie ma co, gratuluję (IMG:style_emoticons/default/wink.gif)

Od tego co piszesz (redukcja liczby połączeń) są właśnie sprite'y. To user decyduje czy chce wyświetlać grafikę i ściągać cokolwiek. Ty go chcesz uszczęśliwiać na siłę. Pakujesz mu obrazki poprzez CSS, choć wyraźnie on chce je zablokować. Kosztem przykładowo sprite'a z plikami, każesz mu pobierać znacznie większe niż normalnie pliki CSS. I tutaj kompresja niewiele zmieni. Wcale nie rozumiesz algorytmów kompresji i to jest luka w Twoim rozumowaniu. Sprite'y mają w zasadzie jedno ograniczenie poważne - nie mogą zawierać animacji. Ale widziałem już przykłady, że poprzez odpowiednie zabawy z nimi i JS można zasymulować ją. Ja wolę nie wiedzieć ile miałby css z animowanymi gifami przejechanymi base64, który musiałby user pobierać czy chce czy nie.

Konole... Jaki problem z aktualizacją sprite'a? Sensownie przemyślany sprite podczas aktualizacji będzie wymagał jedynie niewielkiej modyfikacji grafiki i dodania jej parametrów do css, bez ruszania czegokolwiek w starych danych. Nie mówię o sytuacjach nawet gdy zmieniasz layout i cała zabawa to... podmiana linku do innego sprite'a, bez ruszania pozostałej części css (co nieraz się praktykuje). Ale do tego faktycznie trzeba rozumieć jak powstają sprite'y. Gdy to załapiesz, obserwując choćby kod wynikowy generatorów, to samodzielne tworzenie do nich css staje się banalne. Summa sumarum nawet utworzenie css do pliku z kilkudziesięcioma małymi elementami będzie mniej obciążające i zajmie mniej zasobów niż Twoje rozwiązanie, a dodatkowo będzie nieco elastyczniejsze przy aktualizacjach. Wystarczy trzymać się tylko kilku zasad prostych

A JPEG? (...) Tak, JPEGi do interfejsów.

A o artefaktach jpeg słyszał i wie dlaczego ich stosowanie jest czasem strzałem w stopę? Aż mi się wspomniała jedna graficzka (całkiem inteligentna kobieta), która podesłała mi puzzle pocięte i rozrzucone na białym tle... ale skompresowane do pliku jpg, co jest w takiej sytuacji głupotą, bo artefakty kompresji sprawiły, że nie mogłem tych puzzli ułożyć bez problemów.

Nie da się, a już na pewno nie da się tego zrobić BARDZO dobrze.

I tutaj kłaniają się znajomości grafiki oraz algorytmów kompresji. Kto je nieco ogarnia zredukuje parę rzeczy w grafice i tym samym poprawić może znacząco współczynnik kompresji przy niezauważalnej utracie jakości lub nawet bez utraty choćby bita danych. To co uważasz za świetne rozwiązanie w porównaniu z użyta z głową optymalizacją grafiki nawet nie będzie mieć porównania.

Nie ma to jak puste białe przestrzenie...

...których wielkość nawet tysięcy pikseli liczona jest w bajtach, a wielkość i tak uzupełniana jest do wielokrotności minimalnej jednostki alokacji dysku, czyli zazwyczaj krotności od 512B do nawet 32(!) kB. Tak, argument po prostu kładący na łopatki (IMG:style_emoticons/default/wink.gif)

Dlatego jeśli już piszesz o jakimś rozwiązaniu to posłuchaj także zdania osób, które oprócz stosowania rozwiązań jakie opisujesz znają się także dobrze na: protokole tcp/ip, algorytmach kompresji, obróbce grafiki w stopniu bardziej zaawansowanym oraz wielu mechanizmów, o których zwyczajny webmaster zwyczajnie nie wie, bo nie ma w tej dziedzinie wiedzy nie tylko teoretycznej, ale i praktycznej. A są tutaj tacy, ale ich spojrzenie na problem i wytykane uchybienia bagatelizujesz, "nie rozumiesz pytań" lub stwierdzasz, że "nie mają związku z tematem" (IMG:style_emoticons/default/wink.gif)