W dniu 2019-04-27 o 16:47, Cezary Tomczyk pisze:

> Minimalizacja nie jest walką z wiatrakami. W ogóle jakoś tak chciałem
> rozróżnić minimalizację od kompresji jako, że obie rzeczy są różne.
>
> Ogólnie minimalizować i kompresować powinno robić się niemalże zawsze.
>

Ok, ale ja się pytam o realne korzyści z minimalizacji. Bo w/g mnie
czynienie tego w imię zaoszczędzonych np. 50kB mnie nie przekonuje.
Stwierdzenie, że trzeba to robić, bo inni to robią jest średnio-dziwne.

--
Pozdrawiam,
Marek

do góry

W dniu 2019-04-28 o 15:29, Borys Pogoreło pisze:

>> I dokładnie to brałem!!!! Nie czytasz wątku a komentujesz?
>
> To jeszcze wytłumacz w jaki sposób wyszła Ci różnica 30% między 273KB a
> 86KB.


O czym Ty w ogóle piszesz? Sorki, ale zupełnie nie rozumiem o co Ci
chodzi. O jakich 86kB mowa? Ja pisałem w wątku otwierającym o 79kB (zip
dla no-min) vs 29kB (zip dla min) na przykładzie przestarzałego jQuery,
które wp używa. Skąd bierzesz 86kB?

--
Pozdrawiam,
Marek

do góry

Dnia Mon, 29 Apr 2019 23:40:34 +0200, Marek S napisał(a):

>> To jeszcze wytłumacz w jaki sposób wyszła Ci różnica 30% między 273KB a
>> 86KB.
>
> O czym Ty w ogóle piszesz? Sorki, ale zupełnie nie rozumiem o co Ci
> chodzi. O jakich 86kB mowa? Ja pisałem w wątku otwierającym o 79kB (zip
> dla no-min) vs 29kB (zip dla min) na przykładzie przestarzałego jQuery,
> które wp używa. Skąd bierzesz 86kB?

Z wielkości plików, które podlinkowałem. Ale ok, możemy liczyć dla
wielkości faktycznie przesyłanych plików po kompresji, niewiele to zmienia.
Nadal jestem ciekaw, jak oszacowałeś 1/3 różnicy między 29 a 79.

--
Borys Pogoreło
borys(#)leszno,edu,pl

do góry

On 29/04/2019 23:33, Marek S wrote:
> W dniu 2019-04-27 o 16:47, Cezary Tomczyk pisze:
>
>> Minimalizacja nie jest walką z wiatrakami. W ogóle jakoś tak chciałem
>> rozróżnić minimalizację od kompresji jako, że obie rzeczy są różne.
>>
>> Ogólnie minimalizować i kompresować powinno robić się niemalże zawsze.
>>
>
> Ok, ale ja się pytam o realne korzyści z minimalizacji. Bo w/g mnie
> czynienie tego w imię zaoszczędzonych np. 50kB mnie nie przekonuje.
> Stwierdzenie, że trzeba to robić, bo inni to robią jest średnio-dziwne.

Wg mnie realnie korzyści to zmniejszenie rozmiaru oraz ewentualne
mikro-optymalizacje.

Aczkolwiek, swego czasu przeglądałem kod po minifikacji i w paru
miejscach jakby nieco był zoptymalizowany, ale wg mnie to nie ma
większego wpływu na ogólną szybko przetwarzania kodu.

--
Cezary Tomczyk
http://www.ctomczyk.pl/

do góry

Dnia Mon, 29 Apr 2019 23:33:43 +0200, Marek S napisał(a):

>> Ogólnie minimalizować i kompresować powinno robić się niemalże zawsze.
>
> Ok, ale ja się pytam o realne korzyści z minimalizacji. Bo w/g mnie
> czynienie tego w imię zaoszczędzonych np. 50kB mnie nie przekonuje.

Przestań teoretyzować i zakładać jakieś liczby, tylko po prostu otwórz
sobie kilka popularnych serwisów WWW i policz ile plików JS musisz pobrać.
Dzisiejsze witryny serwują nawet po 500-1000KB kodu Javascript _po
minifikacji_. To są megabajty plików źródłowych.

--
Borys Pogoreło
borys(#)leszno,edu,pl

do góry

W dniu 2019-04-30 o 02:30, Borys Pogoreło pisze:

> Z wielkości plików, które podlinkowałem. Ale ok, możemy liczyć dla
> wielkości faktycznie przesyłanych plików po kompresji, niewiele to zmienia.
> Nadal jestem ciekaw, jak oszacowałeś 1/3 różnicy między 29 a 79.

Nie szacowałem - zaokrągliłem 29/79. Prędkość transferu obu plików
wyrażona w Mbps jest taka sama więc jej nie uwzględniam. Po drugie:
czasy transferu (bez zapytania/oczekiwania) dla przeróżnych innych
plików potwierdzają moją obserwację, że ten czas jest wprost
proporcjonalny do wielkości pliku.

--
Pozdrawiam,
Marek

do góry

W dniu 2019-04-30 o 13:39, Cezary Tomczyk pisze:
>
> Wg mnie realnie korzyści to zmniejszenie rozmiaru oraz ewentualne
> mikro-optymalizacje.


I mikro-korzyści z tego będą.

>
> Aczkolwiek, swego czasu przeglądałem kod po minifikacji i w paru
> miejscach jakby nieco był zoptymalizowany, ale wg mnie to nie ma
> większego wpływu na ogólną szybko przetwarzania kodu.

No więc właśnie. Stąd m.in. właśnie wątek. Niby coś się tam poprawia,
ale efekty tego są raczej filozoficzne.

--
Pozdrawiam,
Marek

do góry

W dniu 2019-04-30 o 15:23, Borys Pogoreło pisze:

> Przestań teoretyzować i zakładać jakieś liczby, tylko po prostu otwórz
> sobie kilka popularnych serwisów WWW i policz ile plików JS musisz pobrać.
> Dzisiejsze witryny serwują nawet po 500-1000KB kodu Javascript _po
> minifikacji_. To są megabajty plików źródłowych.

Ok, no to załóżmy czarny scenariusz: 1MB. Pasuje? Na podstawie jQuery
zzipowanego w wersji min i nie min otrzymałem 30% korzyść z
minimalizacji. Wynika z tego, że zaoszczędzimy 300kB na 1MB danych. Przy
średnim krajowym transferze 20 Mbps oznacza to ok 120ms różnicy.

Przypomnę, że mrugnięcie okiem to 300-400ms. Więc coś z tymi
kalkulacjami swoimi wyolbrzymiasz.

A teraz przypatrzmy się, co powoduje realne opóźnienia zamiast skupiać
się na w kółko mantrowanych mitach. Weźmy pod lupę taki Chrome. Może on
mieć otwartych max 6 połączeń TCP/IP z jedną domeną dla HTTP 1 i 1.1 (wp
używa wersji 1.1).

Jeśli taka wp.pl w ciągu ładowania się strony głównej wywołuje ponad 300
requestów do zatrzymania monitorowania przeze mnie (może z 10s) , to
łatwo wywnioskować jakie będą tego konsekwencje w timingach. Mnóstwo
czasu to będzie bierne czekanie. W/g Chrome, DOM załadował się po
1.45s!!! I to u mnie - na szybkim łączu! Te w/w 120ms to pikuś do całej
reszty.

--
Pozdrawiam,
Marek

do góry

Osoba podpisana jako Borys Pogoreło <b...@p...edu.leszno>
w artykule <news:d6kq7xx9xxaz$.usif10dvkfjb.dlg@40tude.net> pisze:

> Dnia Mon, 29 Apr 2019 23:33:43 +0200, Marek S napisał(a):
>
>>> Ogólnie minimalizować i kompresować powinno robić się niemalże zawsze.
>>
>> Ok, ale ja się pytam o realne korzyści z minimalizacji. Bo w/g mnie
>> czynienie tego w imię zaoszczędzonych np. 50kB mnie nie przekonuje.
>
> Przestań teoretyzować i zakładać jakieś liczby, tylko po prostu otwórz
> sobie kilka popularnych serwisów WWW i policz ile plików JS musisz pobrać.
> Dzisiejsze witryny serwują nawet po 500-1000KB kodu Javascript _po
> minifikacji_.

Albo wczorajsze albo po minimalizacji i zgzipowaniu razem.

> To są megabajty plików źródłowych.

Czyli jakby wczorajsze. Dzisiaj to bywają już dziesiątki megabajtów js,
czyli megabajty jsgz, po zgzipowaniu. W setkach kilobajtów to się liczy
CSS - w wariancie optymistycznym, bez szaleństw ze wstawianiem obrazków
i fontów zakodowanych w Base64.

--
Andrzej P. Woźniak u...@p...onet.pl (zamień miejscami z<->h w adresie)

do góry

Osoba podpisana jako Borys Pogoreło <b...@p...edu.leszno>
w artykule <news:1udnxpwp0uf7j$.jke413pano9f$.dlg@40tude.net> pisze:

> Dnia Sun, 28 Apr 2019 16:54:05 +0200, Andrzej P. Wozniak napisał(a):
>
>>>> I dokładnie to brałem!!!! Nie czytasz wątku a komentujesz?
>>> To jeszcze wytłumacz w jaki sposób wyszła Ci różnica 30% między 273KB a
>>> 86KB.
>> Nie różnica, tylko proporcja: 86/273 ~= 31,5%.
> "Załóżmy, że bez minimalizacji zajmie o 1/3 więcej"

Załóżmy, ale na jakiej podstawie? Dlaczego uważasz, że na podstawie
wielkości, które imputujesz zakładającemu? Może miał na myśli plik wejściowy
zmniejszony przez usunięcie zbędnych samych spacji i końców linii?

A może pytający należy do tej 1/3 (załóżmy), która ma kłopoty z poprawnym
wyrażeniem proporcji i gubi się w procentach? Wyobraź sobie, że ten problem
mają nawet osoby z dyplomem księgowego.

Rozumiem, że można się czepiać dla podtrzymania dyskusji, ale lepiej chyba
robić to po ustaleniu, co macie na myśli, przy okazji wyjaśnienia innych
szczegółów, a nie zamiast tego.

Podpowiem tylko w kwestii gzipowania:
* Plik tekstowy z czystym kodem CSS/JS kompresuje się do jakichś 20%
początkowej objętości, usunięcie zgędnych spacji i znaków końca linii
zmniejsza plik źródłowy, ale stopień kompresji spada do 25%.
* Zakodowane binarne wstawki mogą kompresować się gorzej lub znacznie
gorzej,
zależnie od typu źródłowego pliku binarnego.

--
Andrzej P. Woźniak u...@p...onet.pl (zamień miejscami z<->h w adresie)

do góry