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ę?
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. I
nawet gdyby te strony były popularne jak onet.pl, to gra dalej nie
byłaby warta świeczki.


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

do góry

Konrad Kosmowski pisze:
> ** Paweł Piskorz <n...@p...nie?> wrote:
>
>> W moim przypadku zminimalizowany i zgzipowany CSS nieznacznie mniej waży od
>> zgzipowanego, więc nawet nie ma sensu szukać jakiegoś minimizera i go
>> podpinać. Zaś jak mam przyjemność jakieś skrypty pisać, to ważą one
>> niespakowane max 20KB (+ do tego jQuery, ale to oczywiście zminimalizowane +
>> gzip), więc znowu zysk praktycznie żaden, tym bardziej że ustawiam długie
>> expires. Także bardziej mi się opłaca poświęcić czas na zautomatyzowanie
>> optymalizacji grafik,
>
> Najpierw piszesz o JS i CSS, a potem stwierdzasz ni z gruszki ni z pietruszki,
> że grafik...

Późna pora to i czytanie ze zrozumieniem Ci siada, wróć rano jak się
wyśpisz.


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

do góry

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

> Po co więc gdzieś wysyłać i to wielokrotnie dziennie tą grafikę - i
> to każdy z jej kawałków?

Mój drogi, optymalizacja jest ostatnim etapem przygotowywania szaty
graficznej. Tym, w którym grafika jest już zrobiona, pocięta, wstawiona
na stronę i zatwierdzona przez klienta.
--
Niżej podpisany, zamieszkały w http://minio.xt.pl ,
Mirosław Zalewski

do góry

** 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? 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.

> 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ą? I co z tego, że były największe?

> 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.

--
+ ' .-. .
, * ) )
http://kosmosik.net/ . . '-' . kK

do góry

** Paweł Piskorz <n...@p...nie?> wrote:

>>> W moim przypadku zminimalizowany i zgzipowany CSS nieznacznie mniej waży od
>>> zgzipowanego, więc nawet nie ma sensu szukać jakiegoś minimizera i go
>>> podpinać. Zaś jak mam przyjemność jakieś skrypty pisać, to ważą one
>>> niespakowane max 20KB (+ do tego jQuery, ale to oczywiście zminimalizowane
>>> + gzip), więc znowu zysk praktycznie żaden, tym bardziej że ustawiam długie
>>> expires. Także bardziej mi się opłaca poświęcić czas na zautomatyzowanie
>>> optymalizacji grafik,

>> Najpierw piszesz o JS i CSS, a potem stwierdzasz ni z gruszki ni z
>> pietruszki, że grafik...

> Późna pora to i czytanie ze zrozumieniem Ci siada, wróć rano jak się wyśpisz.

Jak masz zamiar w ten sposób dyskutować to spierdalaj po prostu.

--
+ ' .-. .
, * ) )
http://kosmosik.net/ . . '-' . kK

do góry

>Mój drogi, optymalizacja jest ostatnim etapem przygotowywania szaty
>graficznej. Tym, w którym grafika jest już zrobiona, pocięta, wstawiona
>na stronę i zatwierdzona przez klienta.

No to zazdroszczę klienteli gdyż jeszcze mi się nie zdarzyło abym nie musiał
poprawek nanosić. :)

No ale to było na marginesie. W każdym razie osobiscie nie widzę powodu aby
grafika jeszcze nie zatwierdzona przez klienta nie była zoptymalizowana już
na tym etapie. Konkretnie nie widzę powodu aby unikać optymalizacji przy
każdym eksporcie slice'ów szczególnie, ze ten proces trwa niezauważalny
okiem ludzkim moment. Co zyskam gdy pieczołowicie poustawiam w
profesjonalnym programie to grafiki WWW jak najniższe parametry
optymalizacji tylko po to aby przesłać tą grafikę gdzieś tam w celu jej
optymalizacji a potem skorygowaną umieszczę w miejscu docelowym? Jaki jest
sens takich zabiegów?

do góry

> Przecież w tym sposobie kompresji grafiki nie wydłużasz sobie czasu pracy.
> Zainstaluj sobie dodatek do Firefoksa, który jednym kliknięciem z
> aktualnego URL kompresuje grafikę i pakuje to do jednego pliku zip.

No, ale w jakim celu miałbym to robić skoro grafika pod danym URL jest już
zoptymalizowana? W prfesjonalnych programach do tworzenia grafiki WWW
eksportujesz zoptymalizowaną grafikę. Po co na siłę pogarszać parametry
optymalizacji w celu późniejszego posłużenia się procedurą jaką opisujesz?
Właśnie tego pojąć nie mogę.

Proces optymalizacji programem desktopowym trwa ułamek sekundy po każdej
modyfikacji projektu plus FTPowanie. Tymczasem przesyłanie gdzieś tej
grafiki, odbieranie jej, zapisywanie jej do katalogu lokalnego i FTPowanie
na serwer zajmie dużo więcej czasu. Nie wspomnę o tym, że pierwsza metoda
jest zwykle automatyczna i nie trzeba nawet myśleć co się robi. Wszystko
samo wędruje na serwer do stosownej lokalizacji.

> Zwróć uwagę na to, że algorytmy kompresji bardzo mogą się od siebie
> różnić. Kiedy wydaje nam się, że Adobe Photoshop czy inny "kombajn"
> wycisnął wszystko z kompresji obrazka, to może się okazać, że jest jakiś
> mikro program lub inne rozwiązanie, co pozwoli ten sam obrazek
> skompresować jeszcze ze 20% albo lepiej.

Tak, to prawda. Jednakże czy takie testy zostały przeprowadzone? Czy webowy
optymalizator daje istotnmie lepsze wyniki od np. Adobe Fireworks'a?

Sprawdziłem na losowo wybranych plikach PNG wyeksportowanych z Adobe
Fireworksa i otrzymałem mizerny rezultat - poprawę miedzy 5 a 13%..

Ponadto czy 20% różnicy w rozmiarze pliku ma jakieś praktyczne znaczenie
poza poczuciem satysfakcji? Oczywiście nie biorę tu jakiś skrajnych
przypadków pod uwagę typu strony porno, gdzie odwiedzalność jest
gigantyczna. Może tam warto pokombinować z każdym obrazkiem. Uwzględniając
mechanizmy cacheowania przeglądarek - ten procent nie będzie przekładał się
wprost na transfer. Modemami już też chyba nikt nie łączy się z internetem
aby te 20% mogło być zauważalne.

> Przykład: Adobe Fireworks zapisuje plik PNG niechlujnie duży, ale już GIMP
> nieco lepiej, a już całkiem po kompresji przez PNGOutWin plik staje się
> jeszcze mniejszy. To pokazuje, że nie ma jedynego, słusznego programu do
> kompresji grafiki, a jedynie metodą testów można dojść które z rozwiązań
> daje optymalne wyniki.

Oczywiście zgadzam się z tezą, że różne programy różnie sobie radzą.
Jednakże mam na myśli to co wyżej wspomniałem - czy różnice nawet załóżmy
20% mają praktyczne znaczenie?

do góry

> A po co jest mnóstwo fabryk kół, nie wystarczyłaby jedna?

No i smushit będzie Twoim zdaniem tą jedną fabryką?

> Ale masz coś na poparcie tej prawdy objawionej?

Pewnie, ze mam. Włącz sobie stoper a następnie spróbuj od zera stworzyć dwa
identyczne projekty WWW wliczając cięcie i optymalizację: jeden w np. Adobe
Fireworksie a drugi w kilku aplikacjach webowych (bo pewnie w jednej się nie
da, o ile w ogóle jest to wykonalne). Potem porównaj oba wyniki pomiaru
czasu pracy.

> To nie zawsze jest zaletą, a już na pewno nie w przypadku gdy szukasz
> prostego narzędzia do szybkiego wykonania jakiegoś zadania.

Projektując grafikę nigdy nie wykonuję jednego prostego zadania.

> Każdemu wg potrzeb, nikt Ci nie każe odinstalowywać Photoshopa i używać
> Smushita :]

Pewnie... bo spróbuj narysować coś w Smushicie aby móc to zoptymalizować
potem :]

> Dla mnie niedorzecznością jest wydawanie kilku tysięcy na Photoshopa czy
> Corela tylko po to, żeby zoptymalizować pliki. Tym bardziej iż nie mam
> żadnego dowodu, że potrafią one to zrobić lepiej niż smushit/PngOptimizer.

To prawda... tylko ja nie jestem optymalizatorem grafiki lecz grafikiem,
który m.in. optymalizuje grafikę.Nie sądzę aby stanowisk pracy o nazwie
"otymalizator grafiki i nic więcej" było na tyle dużo aby opłacało się
tworzyć specjalną aplikację w tym celu.

> W czasie rozwoju to ja sobie nie zawracam głowy takimi pierdołami, bo
> jaki jest sens optymalizować obrazek, który i tak za 15 min. będę
> zmieniał?

Np taki, że zazwyczaj nie podmieniasz fotki na nie-fotkę i możesz tylko raz
ustawić optymalizację dla danego slice'a. Fotka zmieni się a optymalizacja
dla niej nie musi więc nie ruszasz jej.Optymalizuje się zazwyczaj typ treści
graficznej a nie każdorazowo dany slice jeśli pod nim zmieni się treść z
zachowaniem typu.

> Jak już pisałem Konradowi, wkrótce mają być dostępne źródła, więc sobie
> dodam do skryptu pakującego i wysyłającego projekt jedną linijkę i
> wszystko się samo zrobi. Takie koła to ja rozumiem!

Tak, to praktyczne bardzo usprawnienie o ile połączenie z serwerem będzie
dobre.

> A już teraz udostępniają API, jak chcesz to sobie możesz zautomatyzować
> cały proces.

W którymś z wątków zadałem poniższe pytanie.
Czy jest o co kopię kruszyć jeśli można zaoszczędzić 5-13% rozmiaru pliku
korzystając z odrębnej aplikacji optymalizującej? Dodam, że taki wynik
uzyskałem testując losowo wybrane PNG wygenerowane przez FW.

do góry

On Sun, 05 Apr 2009 02:16:26 +0100, Marek <m...@s...interia.pl> wrote:

> No, ale w jakim celu miałbym to robić skoro grafika pod danym URL jest
> już zoptymalizowana? W prfesjonalnych programach do tworzenia grafiki
> WWW eksportujesz zoptymalizowaną grafikę.

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

> Tak, to prawda. Jednakże czy takie testy zostały przeprowadzone? Czy
> webowy optymalizator daje istotnmie lepsze wyniki od np. Adobe
> Fireworks'a?
>
> Sprawdziłem na losowo wybranych plikach PNG wyeksportowanych z Adobe
> Fireworksa i otrzymałem mizerny rezultat - poprawę miedzy 5 a 13%..

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.

*) na tych, gdzie nie ma prototype + scriptaculous :)

> będzie przekładał się wprost na transfer. Modemami już też chyba nikt
> nie łączy się z internetem aby te 20% mogło być zauważalne.

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).

> Oczywiście zgadzam się z tezą, że różne programy różnie sobie radzą.
> Jednakże mam na myśli to co wyżej wspomniałem - czy różnice nawet
> załóżmy 20% mają praktyczne znaczenie?

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

--
http://pornel.net
this.author = new Geek("porneL");

do góry

Marek pisze:
> Projektując grafikę nigdy nie wykonuję jednego prostego zadania.

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


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

do góry