Czy minimalizacja plików JS/CSS jest jeszcze "w modzie"?

[Marek S]

Słyszałem opinie iż minimalizacja zmniejsza transfery etc. Coś mnie
tknęło i postanowiłem sprawdzić jak to w praktyce jest. Pobrałem sobie
jQuery w obu wersjach: zwykłej i zminimalizowanej. Wiem, że jQuery jest
już na wymarciu, ale na czymś testować muszę a jest to jeszcze dość
popularna biblioteka. Zzipowałem oba, aby mieć podobny efekt jak bym
ściągał te pliki oglądając jakąś stronę WWW. Otrzymałem pliki 79kB i
29kB. Czyli 50kB na korzyść wersji min.

Następnie wylosowałem w głowie portal, który generuje duży ruch więc
potencjalnie jest o co walczyć. Padło na wp.pl. Popatrzałem jaki
transfer on generuje. Okazało się, że narastający. Ale po 30 sekundach
było ok 12MB. Z matematyki wynika, że te 50kB to zaledwie 0.4% ogółu.
Czy zatem minimalizacja to przypadkiem nie jest walką z wiatrakami
tudzież czymś w rodzaju odpędzania demonów?

--
Pozdrawiam,
Marek

[zlotowinfo]

nie włączyć kompresję?

--
fb.com/groups/allegro.pomoc
fb.com/groups/zlotowinfo


Użytkownik "Marek S" <pr...@spamowi.com> napisał w wiadomości
news:q9kc84$v0d$1...@node2.news.atman.pl...

[Cezary Tomczyk]

Ale jakby tak wszystkie pliki JS/CSS nie kompresować to z 12MB zrobiłoby
się zapewne 20MB. A przy dużym ruchu to już ma znaczenie.

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

[Borys Pogoreło]

Dnia Mon, 22 Apr 2019 14:31:59 +0200, Marek S napisał(a):

> Następnie wylosowałem w głowie portal, który generuje duży ruch więc
> potencjalnie jest o co walczyć. Padło na wp.pl. Popatrzałem jaki
> transfer on generuje. Okazało się, że narastający. Ale po 30 sekundach
> było ok 12MB. Z matematyki wynika, że te 50kB to zaledwie 0.4% ogółu.
> Czy zatem minimalizacja to przypadkiem nie jest walką z wiatrakami
> tudzież czymś w rodzaju odpędzania demonów?

To, ile strona "waży", nie ma większego znaczenia. Ciebie interesuje ile
trzeba pobrać i przetworzyć zanim strona zaczyna być dostępna dla klienta.
A to już zależy od wielu czynników. wp.pl jest dostępna już po 2 sekundach
i przesłaniu ok. 500KB. Jest różnica?

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

[Cezary Tomczyk]

Coś tam po 2 sekundach się pojawia, ale nie nazwałbym do już na tyle
dostępnym, że da się wp.pl używać. W tle ładuje się mnóstwo kodu jeszcze
+ strona "lata" we wszystkie strony. Więc trzeba poczekać aż wszystko
się załaduje i odpowiednio ułoży :-)

[Borys Pogoreło]

Dnia Tue, 23 Apr 2019 18:00:40 +0200, Cezary Tomczyk napisał(a):

>> To, ile strona "waży", nie ma większego znaczenia. Ciebie interesuje ile
>> trzeba pobrać i przetworzyć zanim strona zaczyna być dostępna dla klienta.
>> A to już zależy od wielu czynników. wp.pl jest dostępna już po 2 sekundach
>> i przesłaniu ok. 500KB. Jest różnica?
>
> Coś tam po 2 sekundach się pojawia, ale nie nazwałbym do już na tyle
> dostępnym, że da się wp.pl używać. W tle ładuje się mnóstwo kodu jeszcze
> + strona "lata" we wszystkie strony. Więc trzeba poczekać aż wszystko
> się załaduje i odpowiednio ułoży :-)

Tak, ale DOM już jest gotowy i możesz korzystać ze strony. A że później
jeszcze jakieś skrypty to dalej przetwarzają, to inna sprawa - zostały one
jednak już wczytane i nie blokują przeglądarki. Sprawdź jakie są czasy i
ilości danych dla takich serwisów jak Amazon czy eBay, oni też walczą z
wiatrakami?

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

[Marek S]

W dniu 2019-04-23 o 08:29, Cezary Tomczyk pisze:

>
> Ale jakby tak wszystkie pliki JS/CSS nie kompresować to z 12MB zrobiłoby
> się zapewne 20MB. A przy dużym ruchu to już ma znaczenie.

Po pierwsze: nieskompresowany JS ma 270kB.

Po drugie: jeśli komuś zależy na transferze, to nie bardzo rozumiem
czemu by miał kompresję mieć wyłączoną? Czyż nie plikom tekstowym ona
jest dedykowana (HTML/JS/CSS)? Zresztą jakie byłoby praktyczne
zastosowanie wyłączenia kompresji?

--
Pozdrawiam,
Marek

[Marek S]

W dniu 2019-04-23 o 12:54, Borys Pogoreło pisze:

> To, ile strona "waży", nie ma większego znaczenia. Ciebie interesuje ile
> trzeba pobrać i przetworzyć zanim strona zaczyna być dostępna dla klienta.
> A to już zależy od wielu czynników. wp.pl jest dostępna już po 2 sekundach
> i przesłaniu ok. 500KB. Jest różnica?

Ok, dla pustego DOM, to racja. Jednakże jeśli 500kB leci przez 2s, to
znaczy, że mamy łącze 2Mbps. To już prędkość dość rzadko stosowana.
Średnia prędkość łącza w PL w 2018 wynosi 10x tyle.

No chyba, że uwzględniasz w tym czasie oczekiwanie na odpowiedź serwera.
Ale chyba zgodzisz się ze mną, że niezależnie od wielkości plików - nic
w tym czasie nie jest przesyłane?

U mnie (UPC, łącze 600Mbps) DOM w wp.pl ładuje się w 750ms na czystym
cache, z czego oczekiwanie zajmuje aż 492ms! Samo ładowanie to 254ms.
Strona główna to 184kB tekstu. Załóżmy, że bez minimalizacji zajmie o
1/3 więcej, więc załaduje się w 254 * 30% = 330ms. Czy to jest
jakakolwiek praktyczna różnica?

Dla porównania: czas mignięcia okiem to 300-400ms.

--
Pozdrawiam,
Marek

[Borys Pogoreło]

Dnia Tue, 23 Apr 2019 20:31:28 +0200, Marek S napisał(a):

> Ok, dla pustego DOM, to racja. Jednakże jeśli 500kB leci przez 2s, to
> znaczy, że mamy łącze 2Mbps. To już prędkość dość rzadko stosowana.
> Średnia prędkość łącza w PL w 2018 wynosi 10x tyle.

Super, tylko te cyferki to mają znaczenie jak sobie film ściągasz i
wysycasz łącze. Transmisja HTTP/1 (do tego opakowana w SSL/TLS) działa
"nieco" inaczej.

> U mnie (UPC, łącze 600Mbps) DOM w wp.pl ładuje się w 750ms na czystym
> cache, z czego oczekiwanie zajmuje aż 492ms!

Gratuluję. A Ferrari ma do setki 3 sekundy. Czy to coś mówi o większości
samochodów poruszających się po drogach? O smartfonach, słabych
komputerach, łączach na końcu świata? Popatrz trochę szerzej.

> Samo ładowanie to 254ms. Strona główna to 184kB tekstu. Załóżmy, że bez
> minimalizacji zajmie o 1/3 więcej, więc załaduje się w 254 * 30% =
> 330ms. Czy to jest jakakolwiek praktyczna różnica?

Może jednak sprawdź, jaka to jest faktycznie różnica?

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

[Cezary Tomczyk]

Ależ ja nie napisałem, że należy wyłączać kompresję. Odniosłem się do
Twojego pytania:

"Czy zatem minimalizacja to przypadkiem nie jest walką z wiatrakami
tudzież czymś w rodzaju odpędzania demonów?"

[Cezary Tomczyk]

Nie bardzo rozumiem. Wskazałem tylko na to, że możliwość korzystania ze
strony przez użytkownika jest względna i zależna od wielu parametrów
(szybkość łącza, komputera, itd.), co z resztą widać ewidentnie na
wp.pl. Co z tego, że mam
https://developer.mozilla.org/en-US/docs/Web/API/Window/DOMContentLoaded_event
skoro to jest wyłącznie dla programistów użyteczne.

Strona jest dostępna do użytku dla mnie w momencie, kiedy faktycznie da
się z niej korzystać, a nie w momencie jak event DOMContentLoad będzie
wywołany.

Przykładem jeszcze może być https://www.onet.pl/ - pierwsze załadowanie
szybkie, ale zaraz potem mnóstwo reklam, które rozwalają całą zawartość
i muszę poczekać aż wszystko się ułoży zanim można korzystać z portalu.

btw Akurat strona Amazona wypada całkiem przyzwoicie :-)

[Borys Pogoreło]

Dnia Wed, 24 Apr 2019 10:40:16 +0200, Cezary Tomczyk napisał(a):

> Przykładem jeszcze może być https://www.onet.pl/ - pierwsze załadowanie
> szybkie, ale zaraz potem mnóstwo reklam, które rozwalają całą zawartość
> i muszę poczekać aż wszystko się ułoży zanim można korzystać z portalu.

Ale to nie ma najmniejszego znaczenia z technicznego punktu widzenia w
kontekście ilości danych, które są niezbędne do wyrenderowania strony. Gdy
skrypty zostały załadowane i przetworzone, strona się stała dostępna (+/-
kolejne skrypty dociągane dynamicznie m.in. przez adserwery, ale to już z
reguły leci jako async/defer). I udział wielkości tych skryptów w owej
minimalnej ilości danych jest już znaczący. A że strona dalej wywija
fikołki to już należy mieć pretensje do tych, którzy te skrypty reklamowe
implementowali.

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

[Marek S]

W dniu 2019-04-24 o 10:32, Cezary Tomczyk pisze:

> Ależ ja nie napisałem, że należy wyłączać kompresję. Odniosłem się do
> Twojego pytania:
>
> "Czy zatem minimalizacja to przypadkiem nie jest walką z wiatrakami
> tudzież czymś w rodzaju odpędzania demonów?"

Ok, czytam, co napisałeś wszerz i wzdłuż i za diabła nie rozumiem Twoich
intencji, jakie chciałeś przekazać. Zupełnie nie rozumiem jak świadomy
webmaster mógłby chcieć w ten sposób zadziałać?

Miałby wyłączyć kompresję aby móc sobie ponarzekać na duże transfery
plików tekstowych?

--
Pozdrawiam,
Marek

[Marek S]

W dniu 2019-04-24 o 00:11, Borys Pogoreło pisze:

>> Ok, dla pustego DOM, to racja. Jednakże jeśli 500kB leci przez 2s, to
>> znaczy, że mamy łącze 2Mbps. To już prędkość dość rzadko stosowana.
>> Średnia prędkość łącza w PL w 2018 wynosi 10x tyle.
>
> Super, tylko te cyferki to mają znaczenie jak sobie film ściągasz i
> wysycasz łącze. Transmisja HTTP/1 (do tego opakowana w SSL/TLS) działa
> "nieco" inaczej.

Chwila, ale ja podaję rzeczywiste dane, gdzie złącza nie wysycam, jest
ssl. To są rzeczywiste timingi dokonane przez narzędzia deweloperskie w
Chrome. Nie wyssałem sobie tego z palca.

>> U mnie (UPC, łącze 600Mbps) DOM w wp.pl ładuje się w 750ms na czystym
>> cache, z czego oczekiwanie zajmuje aż 492ms!
>
> Gratuluję. A Ferrari ma do setki 3 sekundy.

Jak zwykle podteksty u Ciebie są ważniejsze od treści. Jeśli da się coś
podkręcić / przekręcić / nadinterpretować, to nie omieszkasz tego
dokonać. Ehhh...
Podałem prędkość łącza aby można było zrelatywizować podane przeze mnie
czasy jakoś, o ile się da.

>> Samo ładowanie to 254ms. Strona główna to 184kB tekstu. Załóżmy, że bez
>> minimalizacji zajmie o 1/3 więcej, więc załaduje się w 254 * 30% =
>> 330ms. Czy to jest jakakolwiek praktyczna różnica?
>
> Może jednak sprawdź, jaka to jest faktycznie różnica?

Podasz mi dane dostępu FTP do serwera wp.pl? :-D

Wątek utworzyłem, bo różnice jakie obserwuję we własnych projektach są
pomijalnie małe.

--
Pozdrawiam,
Marek

[Borys Pogoreło]

Dnia Thu, 25 Apr 2019 22:38:57 +0200, Marek S napisał(a):

> Chwila, ale ja podaję rzeczywiste dane, gdzie złącza nie wysycam, jest
> ssl. To są rzeczywiste timingi dokonane przez narzędzia deweloperskie w
> Chrome. Nie wyssałem sobie tego z palca.

Z pustym czy wypełnionym cache? Z nawiązaną sesją TLS czy przed negocjacją?
Na HTTP/1.1 czy HTTP/2? Z adresem w cache DNS czy bez? Treść strony mieści
się w jednej ramce TCP czy nie? Druga strona omija limit jednoczesnych
połączeń HTTP/1.1 czy nie? Uwzględniłeś to w swoich pomiarach?

> Podałem prędkość łącza aby można było zrelatywizować podane przeze mnie
> czasy jakoś, o ile się da.

Da się, napisać analogię do Ferrari. Bo to ma się nijak do łącz, z których
korzysta większość użytkowników. Mam nadzieje, że prędkości przetwarzania
skryptów nie testujesz dodatkowo na jakimś i9?

>> Może jednak sprawdź, jaka to jest faktycznie różnica?
>
> Podasz mi dane dostępu FTP do serwera wp.pl? :-D

Wystarczy wziąć przykład jednego z najpopularniejszych kawałków kodu w
sieci:

https://code.jquery.com/jquery-3.4.0.js
https://code.jquery.com/jquery-3.4.0.min.js

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

[Marek S]

W dniu 2019-04-25 o 23:00, Borys Pogoreło pisze:

>> Chwila, ale ja podaję rzeczywiste dane, gdzie złącza nie wysycam, jest
>> ssl. To są rzeczywiste timingi dokonane przez narzędzia deweloperskie w
>> Chrome. Nie wyssałem sobie tego z palca.
>
> Z pustym czy wypełnionym cache?

Oczywiście z pustym bop inaczej nie byłoby o czym dyskutować.

> Z nawiązaną sesją TLS czy przed negocjacją?

Bez nawiązania sesji.

> Na HTTP/1.1 czy HTTP/2?

Chrome raczej tego nie podaje. Możesz sobie sam to sprawdzić przecież.

> Z adresem w cache DNS czy bez?

Tak, w cache

> Treść strony mieści
> się w jednej ramce TCP czy nie?

Nie.

> Druga strona omija limit jednoczesnych
> połączeń HTTP/1.1 czy nie?

Jaka druga strona?

> Uwzględniłeś to w swoich pomiarach?

Nie sposób nie uwzględnić. To się samo uwzględnia w postaci sumarycznych
czasów.

>> Podałem prędkość łącza aby można było zrelatywizować podane przeze mnie
>> czasy jakoś, o ile się da.
>
> Da się, napisać analogię do Ferrari.

Wybacz mi, że mam tak szybkie łącze. Obiecuję, że go więcej nie użyję. :-D
Jakaś pokuta jeszcze?

> Wystarczy wziąć przykład jednego z najpopularniejszych kawałków kodu w
> sieci:
>
> https://code.jquery.com/jquery-3.4.0.js
> https://code.jquery.com/jquery-3.4.0.min.js

I dokładnie to brałem!!!! Nie czytasz wątku a komentujesz?

--
Pozdrawiam,
Marek

[Cezary Tomczyk]

Odniosłem się do tego, co napisałeś:

"Następnie wylosowałem w głowie portal, który generuje duży ruch więc
potencjalnie jest o co walczyć. Padło na wp.pl. Popatrzałem jaki
transfer on generuje. Okazało się, że narastający. Ale po 30 sekundach
było ok 12MB. Z matematyki wynika, że te 50kB to zaledwie 0.4% ogółu.

Czy zatem minimalizacja to przypadkiem nie jest walką z wiatrakami
tudzież czymś w rodzaju odpędzania demonów? "

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.

[Borys Pogoreło]

Dnia Sat, 27 Apr 2019 16:35:46 +0200, Marek S napisał(a):

> Wybacz mi, że mam tak szybkie łącze. Obiecuję, że go więcej nie użyję. :-D
> Jakaś pokuta jeszcze?

Tak, włącz sobie w narzędziach deweloperskich ograniczenie przepustowości.

>> https://code.jquery.com/jquery-3.4.0.js
>> https://code.jquery.com/jquery-3.4.0.min.js
>
> 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.

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

[Andrzej P. Wozniak]

Osoba podpisana jako Borys Pogoreło <bo...@pl.edu.leszno>
w artykule <news:tyd7ero9trze.10...@40tude.net> pisze:

Nie różnica, tylko proporcja: 86/273 ~= 31,5%.

--
Andrzej P. Woźniak us...@pochta.onet.pl (zamień miejscami z<->h w adresie)
ja wszystko umiem zadawajcie pytania bo jestem nauczycielem od matematyki
więc się nie bujcie tylko przysyłajcie wiadomości na serwer a ja postaram
się wam pomóc -- Artek <artur180519991(at)interia.pl> na pl.sci.matematyka

[Borys Pogoreło]

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"

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

[Marek S]

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

[Marek S]

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

[Borys Pogoreło]

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

[Cezary Tomczyk]

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.

[Borys Pogoreło]

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

[Marek S]

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

[Marek S]

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

[Marek S]

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

[Andrzej P. Wozniak]

Osoba podpisana jako Borys Pogoreło <bo...@pl.edu.leszno>

w artykule <news:d6kq7xx9xxaz$.usif10dv...@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. Wozniak]

Osoba podpisana jako Borys Pogoreło <bo...@pl.edu.leszno>

w artykule <news:1udnxpwp0uf7j$.jke413pano9f$.d...@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.

[Borys Pogoreło]

Dnia Tue, 30 Apr 2019 21:30:39 +0200, Andrzej P. Wozniak napisał(a):

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

IMO to już trochę przegięcie, bo to zabija wolniejsze sprzęty (w tym przede
wszystkim telefony). Ale nawet z dzisiejszymi frameworkami da się to
utrzymać poniżej 500KB, o ile nie jest to jakaś specyficzna aplikacja
wymagająca konkretnych bibliotek (ale wtedy klient raczej jest tego
świadomy).

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

[Borys Pogoreło]

Dnia Tue, 30 Apr 2019 20:47:37 +0200, Marek S napisał(a):

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

Jeśli według Ciebie między 29 a 79 jest 30% różnicy, to ja nie mam więcej
pytań.

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

[Borys Pogoreło]

Dnia Tue, 30 Apr 2019 21:34:26 +0200, Andrzej P. Wozniak napisał(a):

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

Cały czas mowa o typowej minifikacji, czyli reorganizacji kodu by zajmował
jak najmniej bajtów. Dokładnie tego używa wp.pl, przywołana jako przykład.

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

[Andrzej P. Wozniak]

Osoba podpisana jako Borys Pogoreło <bo...@pl.edu.leszno>

w artykule <news:1u91t0bbknroh.g...@40tude.net> pisze:

Ale się nie chce. Zobacz, ile ładują portalowe systemy komentarzy, ile
ładuje Youtube, Gmail czy inny webmail. Są jeszcze durnie, którzy konwertują
1 MB filmiku do wielokrotnie większego animowanego gifa, ale to już off
topic.
Na dodatek wszyscy wyklinają flasha, choć bez niego pchają znacznie więcej.

Co ciekawe, to chyba smartfonowa apka Gmaila dołącza 400 KB CSS do każdej
wiadomości, kiedy masz ustawione cytowanie poprzednika, choćbyś nawet wyciął
cały cytat i pozostawił jedną linijkę odpowiedzi.

A webmaile czy portale, w których kodzie ciągle ktoś dłubie? Nową wersję
programu desktopowego pobierasz średnio raz na miesiąc, a w przeglądarce
codziennie musisz od nowa ciągnąć megabajty CSS/JS. I tak dla każdego
webmaila oddzielnie, i dodtakowo jeszcze dla każdego folderu, a desktopowy
klient email po IMAP obskakuje wszystkich pobierając tylko kilobajty
nagłówków.

[Andrzej P. Wozniak]

Osoba podpisana jako Borys Pogoreło <bo...@pl.edu.leszno>

w artykule <news:bk22hz3r3qjy$.1v76b0udq0rjy$.d...@40tude.net> pisze:

Niby racja, ale trzymając się jednego portalu też można otrzymać różne
wyniki na różnych stronach i w różnych dniach, a nawet w kolejnych sesjach.
Inne wyniki mogą być też dla użytkowników anonimowych i zalogowanych. Akurat
wp stosuje jakieś takie manewry reklamowe zależne od dnia tygodnia.

Na marginesie - Mozilla wyraziła się negatywnie na temat udziwniania kodu, w
szczególności przez zaciemnianie. Już niedługo dodatki do Firefoxa mają być
przeglądane pod tym kątem:
https://www.ghacks.net/2019/05/03/mozilla-updates-its-firefox-add-on-policy/

W skrócie:
/----

Mozilla will make changes to Firefox Add-on policies in June 2019 that
are designed to improve user safety and privacy when using extensions.

Starting in June 2019, extensions may no longer contain obfuscated code.
Caitlin Neiman, Mozilla's Add-ons Community Manager notes that
extensions may still use minified, concatenated or otherwise
machine-generated code, but that the source code needs to be included
and that obfuscation is not allowed anymore.

Mozilla will improve the blocking process as well to block extensions
"more proactively" if they violate policies.
\----

[Marek S]

W dniu 2019-05-01 o 03:46, Borys Pogoreło pisze:

> Jeśli według Ciebie między 29 a 79 jest 30% różnicy, to ja nie mam więcej
> pytań.

hahaha
Sorki, sam się zamotałem. 29 stanowi ponad 30% z 79 miało być, co jest
bez sensu informacją, którą potem ciągnąłem przez wątek. :-D :-D
Uśmiałem się. Oczywiście % oszczędności jest znacznie wyższy.

Ale teraz do rzeczy. Pomijając już wartości, to i tak w przypadku WP,
oszczędność nawet rzędu 600kB (nie 300 - jak pisałem) jest kroplą w
oceanie transferu. Przypomnę, że po 10s WP wysłał 12MB danych.

--
Pozdrawiam,
Marek

[Borys Pogoreło]

Dnia Fri, 3 May 2019 17:16:54 +0200, Andrzej P. Wozniak napisał(a):

> Na marginesie - Mozilla wyraziła się negatywnie na temat udziwniania kodu, w
> szczególności przez zaciemnianie. Już niedługo dodatki do Firefoxa mają być
> przeglądane pod tym kątem:
> https://www.ghacks.net/2019/05/03/mozilla-updates-its-firefox-add-on-policy/

To akurat nic dziwnego, bo w tym przypadku zaciemnianie może co najwyżej
sugerować jakieś podejrzane działania. W tym przypadku czas pobierania nie
ma żadnego znaczenia.

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

[Borys Pogoreło]

Dnia Fri, 3 May 2019 17:04:01 +0200, Andrzej P. Wozniak napisał(a):

> Ale się nie chce. Zobacz, ile ładują portalowe systemy komentarzy, ile
> ładuje Youtube, Gmail czy inny webmail.

Fakt, to są kobyły, ale też naładowane funkcjami dla tych setek milionów
użytkowników. I nawet przy takim przeładowaniu nadal działają dość znośnie
(choćby GMail korzysta z ciekawych sztuczek aby opóźnić wykonywanie kodu i
tym samym blokowanie przeglądarki).

> Co ciekawe, to chyba smartfonowa apka Gmaila dołącza 400 KB CSS do każdej
> wiadomości, kiedy masz ustawione cytowanie poprzednika, choćbyś nawet wyciął
> cały cytat i pozostawił jedną linijkę odpowiedzi.

To faktycznie słabo z ich strony. Można gdzieś o tym poczytać? Na szybko
nie mogę znaleźć żadnej dyskusji na ten temat.

> A webmaile czy portale, w których kodzie ciągle ktoś dłubie? Nową wersję
> programu desktopowego pobierasz średnio raz na miesiąc, a w przeglądarce
> codziennie musisz od nowa ciągnąć megabajty CSS/JS.

Jw., sztuczki + cache. Odświeżenie strony YT to tylko 36KB JS do pobrania.

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

[Borys Pogoreło]

Dnia Sun, 5 May 2019 00:28:15 +0200, Marek S napisał(a):

> Ale teraz do rzeczy. Pomijając już wartości, to i tak w przypadku WP,
> oszczędność nawet rzędu 600kB (nie 300 - jak pisałem) jest kroplą w
> oceanie transferu. Przypomnę, że po 10s WP wysłał 12MB danych.

A ja przypomnę, że te javascriptowe kilobajty blokują przeglądarkę. Kolejne
10MB zdjęć już nie.

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

[Andrzej P. Wozniak]

Osoba podpisana jako Borys Pogoreło <bo...@pl.edu.leszno>

w artykule <news:1nt1w0xobtjj5$.13316ets...@40tude.net> pisze:

> Dnia Fri, 3 May 2019 17:16:54 +0200, Andrzej P. Wozniak napisał(a):
>
>> Na marginesie - Mozilla wyraziła się negatywnie na temat udziwniania
>> kodu, w szczególności przez zaciemnianie. Już niedługo dodatki do
>> Firefoxa mają być przeglądane pod tym kątem
>

> To akurat nic dziwnego, bo w tym przypadku zaciemnianie może co najwyżej
> sugerować jakieś podejrzane działania. W tym przypadku czas pobierania nie
> ma żadnego znaczenia.

Czas pobierania nie, ale czas wykonania jak najbardziej - do zaciemniania
mogą posłużyć zbędne wywołania funkcji w pętli. Optymalizacja czasu
wykonania bywa też sprzeczna z minifikacją.

A przy okazji Mozilla zabiła czasowo wszystkie WebExtensions, bo im się
certyfikaty przeterminowały.

[Andrzej P. Wozniak]

Osoba podpisana jako Borys Pogoreło <bo...@pl.edu.leszno>

w artykule <news:p25pbyqurl0h$.1aw7asxft37n1$.d...@40tude.net> pisze:

> Dnia Fri, 3 May 2019 17:04:01 +0200, Andrzej P. Wozniak napisał(a):
>
>> Co ciekawe, to chyba smartfonowa apka Gmaila dołącza 400 KB CSS do
>> każdej wiadomości, kiedy masz ustawione cytowanie poprzednika,
>> choćbyś nawet wyciął cały cytat i pozostawił jedną linijkę odpowiedzi.
> To faktycznie słabo z ich strony. Można gdzieś o tym poczytać? Na szybko
> nie mogę znaleźć żadnej dyskusji na ten temat.

Bo kto to widzi? Przecież webmaile teraz nie pokazują rozmiaru.
I kto się tym przejmuje, dopóki mu poczta nie zacznie trafiać do spamu?

Mogę podesłać po parze emaili (zwykły i przerośnięty) od dwóch różnych
użytkowników. Nie analizowałem tego bliżej, tylko zauważyłem ciekawostkę
na liście dyskusyjnej.

>> A webmaile czy portale, w których kodzie ciągle ktoś dłubie? Nową wersję
>> programu desktopowego pobierasz średnio raz na miesiąc, a w przeglądarce
>> codziennie musisz od nowa ciągnąć megabajty CSS/JS.
> Jw., sztuczki + cache. Odświeżenie strony YT to tylko 36KB JS do pobrania.

Nie mówię o odświeżeniu w trakcie sesji, tylko po tym jak z dnia na dzień
coś podłubią w kodzie. Czasami dłubią przez kilka dni i codziennie trzeba
wymuszać odświeżanie, bo automagicznie to działa na 100% tylko w
przeglądarce bez żadnych dodatków. A potem jeszcze trzeba czekać na
aktualizację dodatków, żeby radziły sobie ze zmienionym kodem…

Poza tym okazało się, że w Google celowo piszą kod (owe sztuczki) tak, by na
Firefoksie były problemy.

[Marek S]

W dniu 2019-05-06 o 14:06, Borys Pogoreło pisze:

> A ja przypomnę, że te javascriptowe kilobajty blokują przeglądarkę. Kolejne
> 10MB zdjęć już nie.

Może i w tym rzecz. Obserwując przenoszenie logiki aplikacji w coraz
większym stopniu na JS, gdzie 10MB kodu to nic niezwykłego ... przestaję
się dziwić, że serwisy WWW dławią się.

--
Pozdrawiam,
Marek