Konrad Kosmowski pisze:
> ** Paweł Piskorz <n...@p...nie?> wrote:
>
>> Konrad dotrze do Ciebie, że w moim przypadku minimalizowanie plików CSS/JS
>> nie daje wystarczających korzyści, aby zajmować sobie tym głowę?
>
> A skąd mam wiedzieć jaki to jest Twój przypadek?

Message-ID: <gqu50d$567$1@inews.gazeta.pl>
"Pytałeś czego używam - ja używam tej dyrektywy Apache ;)"

> Ja potwierdzam, że jednak robi to różnice, z resztą nie tylko ja.

Jedne gacie nie muszą pasować na wszystkie dupy.

>> I nie opieram się jak Ty na danych z sufitu, tylko przetestowałem to na
>> największych plikach CSS/JS jakie w ciągu ostatniego roku stworzyłem.
>
> Jaką metodą?

http://taat.pl/narzedzia/csstidy/
http://www.crockford.com/javascript/jsmin.html

> I co z tego, że były największe?

To, że pozostałe miały 4KB po zgzipowaniu.

>> I nawet gdyby te strony były popularne jak onet.pl, to gra dalej nie byłaby
>> warta świeczki.
>
> Tego akurat Ty nie oceniasz bo nie Ty płacisz za transfer.

Jako że nie robię dla onetu/fotki/facebooka/ebay/allegro, to klient też
się tym przejmować nie musi, bo nie ma bata żeby z tego powodu
przekroczył dostępny limit transferu u swojego dostawcy.


--
message[autor="PablO"]::after {
content:"Pozdrawiam";
}

do góry

porneL pisze:
> Na większości moich stron* lwią część ruchu generują obrazki.
>
> *) na tych, gdzie nie ma prototype + scriptaculous :)

To cache tak mało daje, czy na tych stronach z prototypem masz po prostu
mało danych/grafik i cokolwiek co ważyłoby tyle co ww. duet nabijałoby
tak samo transfer?


--
message[autor="PablO"]::after {
content:"Pozdrawiam";
}

do góry

> W Photoshopie "Save For Web" jest mizerne w porównaniu z PNGOUT.

Photoshop nie jest programem Web'owym. Tam dostawiono siekanie grafiki po to
aby dostawić kolejny punkt do listy możliwości. Dlatego jako odniesienie
zacytowałem FW.

> Na większości moich stron* lwią część ruchu generują obrazki. Ścięcie tego
> o 13% robi różnicę, gdy dochodzisz do limitów transferu.

Nie o 13 lecz średnio o 7% bazując na paru, pewnie niedoskonałych testach
jakie wykonałem. Przyjąłem politykę dokupowania transferu. W praktyce koszt
w przeliczeniu na jednego klienta w skali roku wynosi pojedyncze złotówki.
Natomiast koszt czasu włożonego na każdorazową optymalizację objętościową
plików dla każdego z projektów byłby znacznie wyższy.

> Komórki? iPhone nie umieszcza w cache plików większych, niż 25kb i ma
> 500kb cache na stronę (i to wielkości po rozpakowaniu HTTPowego gzipa).

Czy średnio 7% pomniejszenia objętości plików robi jakąkolwiek różnicę?

> 20% na 300-bajtowej ikonie nie, ale 20% na 250KB screenshocie to nawet na
> megabitowym łączu widać.

Rzadko widuje się tak duże obrazki na stronie WWW. Patrzałem jak to u mnie
wygląda. Zdjęcia w serwisach średnio mają po 40kB. Ikonki itp po 0.5-3kB.
Zakładając nawet, że mamy duże obrazki to czas oczekiwania na załadowanie
się obrazka rzędu 3 sekund kontra 2.4 sekundy (a raczej przy 7% oszczędności
2.79 sekundy) jest zauważalny przez kogokolwiek?

do góry

> Grupy Ci się chyba pomyliły ;) Nie każda osoba mająca styczność z
> grafiką na www to grafik/webdesigner, a już na pewno nie tu.

Tego faktycznie nie wziąłem pod uwagę :-)

> W Twoim
> przypadku użycie ww. narzędzia jest równie bez sensu, jak w moim zakup
> FW aby je zastąpić.

Punkt widzenia faktycznie zależy od punktu siedzenia :-)
Jednakże jest przemyślałem sprawę i znalazłem potencjalne zastosowanie
takiego webowego optymalizatora. Byłoby to dobre narzędzie dla systemów typu
CMS gdzie nie-graficzni redaktorzy dołączają fotki do tworzonych treści.
Jednakże jeste spore ryzyko takiego podejścia uzależniającego działanie CMS
od zewnętrznego serwisu: wyobraź sobie kilkudziesięciu wk... klientów gdy
tamten serwis przestanie działać.

do góry

Konrad Kosmowski pisze:
> A skąd mam wiedzieć jaki to jest Twój przypadek?

Jedne gacie nie muszą pasować na wszystkich ludzi, jesteś w stanie to
pojąć bez potrzeby zobaczenia wszystkich tyłków?

> Ja potwierdzam, że jednak robi
> to różnice, z resztą nie tylko ja. Zminifikowany plik mniej zajmuje (nie ma
> chociażby komentarzy) i lepiej się kompresuje, to nie jest tylko moje zdanie.

No i ja tego nie neguje, Wasze dupy, Wasze gacie.

>> I nie opieram się jak Ty na danych z sufitu, tylko przetestowałem to na
>> największych plikach CSS/JS jakie w ciągu ostatniego roku stworzyłem.
>
> Jaką metodą?

Jaką metodą testowałem?

> I co z tego, że były największe?

A widzisz sens optymalizacji pliku, który zgzipowany waży 1KB*?

>> I nawet gdyby te strony były popularne jak onet.pl, to gra dalej nie byłaby
>> warta świeczki.
>
> Tego akurat Ty nie oceniasz bo nie Ty płacisz za transfer.

Piszesz o transferze za który płaci klient hostując stronę, czy o
transferze za który płaci odbiorca po gprs? O tego pierwszego się nie
bój, limitu z tego powodu nie przekroczy*, zaś co do drugiego - jeżeli
dla Ciebie YouTube po gprs kosztuje grosze, to tym bardziej nie
odczujesz kosztu niezminimalizowanego pliku.

* Zakładając że nie pracuję dla onet.pl/fotka/ebay/facebook/itd.


--
message[autor="PablO"]::after {
content:"Pozdrawiam";
}

do góry

Marek pisze:
> Punkt widzenia faktycznie zależy od punktu siedzenia :-)

Da aa :]

> Jednakże jest przemyślałem sprawę i znalazłem potencjalne zastosowanie
> takiego webowego optymalizatora. Byłoby to dobre narzędzie dla systemów
> typu CMS gdzie nie-graficzni redaktorzy dołączają fotki do tworzonych
> treści. Jednakże jeste spore ryzyko takiego podejścia uzależniającego
> działanie CMS od zewnętrznego serwisu: wyobraź sobie kilkudziesięciu
> wk... klientów gdy tamten serwis przestanie działać.

Dlatego lepiej poczekać aż to udostępnią i postawić u siebie, nie mniej
warto wiedzieć że ktoś nad czymś takim pracuje i wkrótce będzie można to
wykorzystać, stąd mój pierwszy post ;)


--
message[autor="PablO"]::after {
content:"Pozdrawiam";
}

do góry

kwiecień roku pamiętnego 2009, prawdopodobnie 05. Wielka mądrość na
czytelników pl.comp.www spłynęła, gdy tako rzekł(a) Marek:

> W każdym razie osobiscie nie widzę powodu aby
> grafika jeszcze nie zatwierdzona przez klienta nie była
> zoptymalizowana już na tym etapie.

Ty, MID: <gr9uvv$ii$1@achot.icm.edu.pl>
> Natomiast koszt czasu włożonego na każdorazową optymalizację
> objętościową plików dla każdego z projektów byłby znacznie wyższy.
--
Niżej podpisany, zamieszkały w http://minio.xt.pl ,
Mirosław Zalewski

do góry

> Dlatego lepiej poczekać aż to udostępnią i postawić u siebie, nie mniej
> warto wiedzieć że ktoś nad czymś takim pracuje i wkrótce będzie można to
> wykorzystać, stąd mój pierwszy post ;)

Tak, właśnie... tyle tylko, że trzeba mieć pewnie własny serwer a to bardzo
nieliczne grono web-developerów. Na Homie itp niczego nie zainstalujesz co
nie jest skryptem.

do góry