🚀 go-pugleaf

nie włączyć kompresję?

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


Użytkownik "Marek S" <precz@spamowi.com> napisał w wiadomości 
news:q9kc84$v0d$1@node2.news.atman.pl...
> 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 

On 22/04/2019 14:31, Marek S wrote:
> 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?

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/

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

On 23/04/2019 12:54, Borys Pogoreło wrote:
> 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?

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

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

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

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

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

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

On 23/04/2019 19:52, Marek S wrote:
> 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?

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
http://www.ctomczyk.pl/

On 23/04/2019 18:57, Borys Pogoreło wrote:
> 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?

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

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

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

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

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

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

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

On 25/04/2019 21:33, Marek S wrote:
> 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?
> 

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.

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

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

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

> Dnia Sat, 27 Apr 2019 16:35:46 +0200, Marek S 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%.

-- 
Andrzej P. Woźniak  uszer@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

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

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

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

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

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/

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

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

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

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

Osoba podpisana jako Borys Pogoreło <borys@pl.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  uszer@pochta.onet.pl  (zamień miejscami z<->h w adresie) 

Osoba podpisana jako Borys Pogoreło <borys@pl.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  uszer@pochta.onet.pl  (zamień miejscami z<->h w adresie) 

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

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

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

Osoba podpisana jako Borys Pogoreło <borys@pl.edu.leszno>
w artykule <news:1u91t0bbknroh.gn0ww7c7lmku.dlg@40tude.net> pisze:

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

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. Woźniak  uszer@pochta.onet.pl  (zamień miejscami z<->h w adresie)

Osoba podpisana jako Borys Pogoreło <borys@pl.edu.leszno>
w artykule <news:bk22hz3r3qjy$.1v76b0udq0rjy$.dlg@40tude.net> pisze:

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

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

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

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

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

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

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

Osoba podpisana jako Borys Pogoreło <borys@pl.edu.leszno>
w artykule <news:1nt1w0xobtjj5$.13316etsfhno3.dlg@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. Woźniak  uszer@pochta.onet.pl  (zamień miejscami z<->h w adresie) 

Osoba podpisana jako Borys Pogoreło <borys@pl.edu.leszno>
w artykule <news:p25pbyqurl0h$.1aw7asxft37n1$.dlg@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.

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

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