Forum PHP.pl

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

I tak i nie. Ogólnie, to robi się wtedy trochę bałaganu w kodzie, a co za problem pobawić się z 1 plikiem całego layoutu i ustawić background position? (IMG:style_emoticons/default/snitch.gif) Zresztą ja czasami jak siędzę na modemie gsm, to wyłączam wczytywanie obrazków, ale style zostawiam. W twoim wypadku niepotrzebnie pobiorę obrazek.

Nie wiem skąd wziąłeś 3-4% ale to jest 1/3 czyli 33% około. Nie każdy serwer obsługuje kompresję gzip.


- Dalej, IE8 ogranicza wielkość tego ciągu do 32kb... :[
- Słabe cachowanie elementów.

Wg mnie nie, wystarczy napisać parser który zamieni uri w backgrund-image na content w base64 i odwrotnie, taka prekompilacja (IMG:style_emoticons/default/smile.gif) Sekunda roboty i żaden bałagan.


Nie.
Najlepszy stosunek wielkości do jakości uzyskuje się w różnych formatach (PNG, GIF, JPEG) w zależności od własności danej grafiki.
Nie wspomne już o półprzeźroczystych PNG.
Takie rozwiązanie się nie nadaje kompletnie i musisz tutaj przyznać się do nie przemyślenia do końca tego co napisałeś..


Z punktu widzenia usera -> Fail
Z punktu widzenia developera -> WIN :-]


Sam sobie odpowiedziałeś, więc przemilcze :-]


Dobrze wiedzieć, mnie to nie odstarsza.
Mam tylko nadzieje, ze inne przeglądarki nie ograniczają tego jeszcze bardziej..
Na upartego można złożyć z kilku obrazków tworząc wzorcowy pomnik ludzkiego szaleństwa :-]
Tak czy inaczej, to jest bez wątpienia największy minus.


Co przez to rozumiesz?
Wg mnie cachowanie jest bardzo dobre.

Ten post edytował wNogachSpisz 26.05.2011, 03:16:16

To przekreśla całość, bo developer nie może być wygrany skoro strona na którą wchodzi użytkownik źle się wyświetli w jakimś tam przypadku.

Zmiana jednego stylu, np dodanie podkreślenia powoduje że cały ten plik musi pobrać od nowa użytkownik.

To Twoje zdanie, wg. mnie jest odwrotnie.
To jedna z największych zalet oamawianej techniki.


A kto powiedzial że musisz wszystko trzymać w jednym pliku .css ?

Więc jaki jest wtedy tego sens?

Nie rozumiem pytania.
Sens nie ulega zmianie.
Zamiast jednego pliku, trzymasz to w kilku, różnica będzie niewielka.

Ten post edytował wNogachSpisz 28.05.2011, 11:11:30

Podstawy protokołu TCP/IP się kłaniają. Nie każdy serwer ma odpowiednio ustawiony Keep-Alive, a pamiętaj, że każde nowe połączenie TCP, to zasoby CPU + łącze. Sama negocjacja potrafi pożreć więcej czasu niż faktyczny przesył zbioru.

Nie rozumiem co ma keep-alive do ilości plików stylów.


Dokładnie! Taki jest właśnie cel tej całej zabawy, minimalizacja tych połączeń.
Zamiast wielu drobnych elementów graficznych, jeden - lub jeśli trzeba więcej - plików .css.
Dziękuje za czytanie ze zrozumieniem... (ironia)

Ten post edytował wNogachSpisz 28.05.2011, 15:21:15

Ma. Bo jeśli Keep-Alive jest odpowiednio skonfigurowane, to wszystko poleci jednym połączeniem.

Nadal nie rozumiem, co to ma do rzeczy.
Piszesz nie na temat.

Ten post edytował wNogachSpisz 28.05.2011, 18:25:43

Ta technika nazywa się spritem i jest o wiele wygodniejsza i łatwiejsza w implementacji niż twój sposób ...

CSS Spirites, i jest aktualnie na modzie, redukuje liczbę połączeń oraz nie trzeba pisać dodatkowych skryptów które nam parsują plik css żeby zmienić url na data:base64.. Wyżej wymieniony sposób nie przemawia do mnie, jak i pewnie do 90% developerów. Widziałem niekiedy w js jak ktoś wrzucał w taki sposób obrazki i odlanezienie ewentualna korekta obrazka osoby która nie napisała dany arkusz styli, jest masakrą, równie dobrze możemy zacząć programować malbolge, i szczerze współczuje każdemu kto będzie próbował w ten sposób pisać style..

Właśnie, największym problemem będzie aktualizacja sprite'a. A co, jeśli zechcesz dodać jeden obrazek do tego? Więcej problemów niż korzyści.

Piszesz bzdury, zamiana URL na dane binarne zakodowane w base64 jest o galaktykę prostrza niż tworzenie spritów. Dosłownie kilku linijkowy skrypt w PHP wystarczy.
Sprity się nie nadają ze względu na różnorodność formatów i wymiarów obrazków. Nie da się ich efektywnie kompresować
Nie przemawia? Bardzo dobrze, przecież wszyscy na raz nie mogą być innowacyjni (IMG:style_emoticons/default/biggrin.gif)

Jak narazie jedyna rzecz ktróra mnie zmartwiła, to 32KB limit wielkości grafiki - cholerny Internet Explorer (IMG:style_emoticons/default/sad.gif)

Ten post edytował wNogachSpisz 29.05.2011, 23:33:39

Jaka różnorodność formatów? Przecież na chwilę obecną wykorzystuje się praktycznie wyłącznie PNG. Co więcej da się to bardzo dobrze skompresować - przecież możesz sobie stworzyć kilka takich map w których znajdą się odpowiednie obrazy. Dzięki temu z jednej uda Ci się pozbyć kanału alpha, z drugiej jakiegoś tam zakresu barw itd. - wątpię by udało Ci się uzyskać lepszy stopień kompresji.
Co do łatwości edycji... CSS Sprites używa się raczej tam gdzie wydajność ma kluczowe znaczenie co z definicji oznacza, że nie może to być zbyt wygodne.

Co więcej:
- brak możliwości jakiegokolwiek indywidualnego zarządzania cachem - jest się skazanym na ustawienia dla arkusza - to może być w pewnych sytuacjach nieco problematyczne,
- brak cache'owania przez pośredniczące serwery - niestety samemu czasami muszę włączyć sobie Operę Turbo by móc w miarę humanitarnie korzystać z Internetu i bardzo irytowałby mnie jeżeli nie mógłbym z tego skorzystać.

JPEG, PNG, PNG-semi-transparent, GIF


A JPEG?


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


Tak, pod warunkiem ze każdy składowy obrazek nie będzie miał więcej kolorów niż inny oraz będzie miał taką samą szerokość (lub w ostateczności wyskości, tyle że wtedy modyfikacja spritu to koszmar). W praktyce bardzo mocno ogranicza to sytuacjie w którym można efektywnie wykorzystać tę technikę.


Możesz dowolnie zarządzać cachem zarówno przez htaccess jak i nagłówki HTTP np. wygenerowane przez skrypt php.


Od kiedy to proxy nie cachują CSS? Co za bzdury wygadujesz??

Ten post edytował wNogachSpisz 30.05.2011, 11:41:08

1. O ile GIF-ów się jeszcze używa o tyle JPEG-ki do tworzenia interfejsu? To chyba jakieś nieporozumienie. A to właśnie interfejsy się robi w CSS-ie.
2. Czemu niby jeden duży obraz, zawierający w sobie jedynie powiedzmy tylko odcienie szarości nie miałby się dać ładnie skompresować?
3. Nie widzę też powodu dla którego poszczególne obrazy w takiej mapie miałby mieć takie same wymiary - nie jest to konieczne do utworzenia takiej mapy. Oczywiście stała szerokość i wysokość nieco uprościłaby używanie jej. Zresztą zawsze można sobie taką mapę podzielić na siatkę o stałej szerokości - puste białe, prostokątne przestrzenie bardzo ładnie się kompresują więc nie będzie to problemem.
4. Masz rację co do tego, że takie mapy edytuje się niezbyt przyjemnie, ale taka jest ich cena. Cena za to, że pozbywamy się całej masy niepotrzebnych informacji (nagłówków z formatu PNG czy innego) które w każdej innej technice (włącznie z zapisywaniem obrazów w arkuszu) muszą być powielone dla każdego pliku.
5.

[CSS] pobierz, plaintext 
body {
  background-image: url(...);
}
 
#sth {
  background-image: url(...);
}
[CSS] pobierz, plaintext 

Jakim sposobem chciałbyś ustawić osobny nagłówek dla tła z body i #sth?
6. Co do tych proxy źle się wyraziłem. Oczywiście arkusze CSS zostaną poddane kompresji, ale obrazy w nich zawarte nie będą mogły być poddane kompresji stratnej - a to właśnie ona daje największego kopa.

Tak, JPEGi do interfejsów.


Nie rozumiem pytania.


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


Nie rozumiem pytania.


Ale kiedy ja nie chce żeby grafika mojego layoutu była kompresowana. Jako developer chce żeby moja strona wyglądała zawsze tak samo. Zysk na "zniszczeniu" grafiki przez wątpliwej jakości algorytm kopresujący nie będzie "kopem", przeciwnie, pracą na marne, w rezultacie jedna różnica to popsuty wygląd strony.

Wybacz ale jeżeli najpierw rzucasz jakieś hasła, a potem przy naszym dopytywaniu się czy ich negowaniu piszesz, że nie rozumiesz czegoś, albo zarzucasz że ktoś pisze nie na temat (patrz posty @erix). Nie rozumiesz chyba na czym polega kompresja stratna i co niesie ona ze sobą. W dodatku jeszcze nigdzie nie podałeś żadnego uargumentowania, testów czy czegokolwiek konkretnego przy swoich opiniach.

Odnoszę wrażenie że czego by się tu nie podało i tak będziesz na upartego wszystko negował - nawet nie rozumiejąc co się do Ciebie pisze.