Makabryczny bloat stron WWW...

Odpowiedz Nowy wątek
2019-07-14 20:36
7

<rant>

I znowu jestem w wakacje w takim miejscu Polski, gdzie internet mobilny działa marnie. Strony ładują się w czasie liczonym niekiedy w minutach, a co gorsza często się po prostu rozłącza.

By przyspieszyć ładowanie wyłączam sobie w przeglądarce obrazki i Javascript. Wróć, JS sobie nie wyłączam, bo wiele stron bez niego po prostu nie działa. I nie wyświetla tekstu.

Sprawdziłem sobie w narzędziach developerskich FF.. Załadownie jednej strony to nierzadko wymaga pobrania MEGABAJTÓW danych?! BEZ obrazków?!

Niepojęte - wchodzę na stronę dla artykułu, który tam jest, albo dyskusji (np Reddit). SAM TEKST (dla którego tam wchodzę) to przecież o KILKA RZĘDÓW WIELKOŚCI mniej bajtów.

Ale nie, ponieważ strona musi być wizualnie atraktycjna i ponieważ musi robić pierdyliard rzeczy oprócz wyświetlenia tekstu (np. usera szpiegować i profilować, jak mniemam), to muszę pobierać MEGABAJTY mi nijak nie potrzebnych danych, co utrudnia mi istotnie dostanie się do tych kilku KILObajtów (co najwyżej) tekstu, da których tam przyszedłem.

<\rant>

edytowany 3x, ostatnio: kmph, 2019-07-14 20:37

Pozostało 580 znaków

2019-07-15 16:41
3

Większość narzekających nie zauważa jednej rzeczy - w 99% to klient chce by strona była taka. Poza tym chociażby animacje to jest często wymóg, pamiętaj jak znajomy coś mówił, że miał zrobić stronę i klient chciał by po całej stronie skakały zające. Po dłużej rozmowie udało mu się ograniczyć te żądania ale nadal miały skakać gdzieś w tle.

Pokaż pozostałe 6 komentarzy
Ale dalej można to zrobić używając zdecydowanie mniej zasobów. Ja osobiście liczę, że podejścia jak Phoenix.LiveView przyjmą się szerzej i nie będzie już potrzeba tak dużo danych pchać na dzień dobry. - hauleth 2019-07-15 17:16
Skąd wy tych klientów bierzecie? Z Pakistanu? - axde 2019-07-15 17:39
Tylko, ze jesli nowoczesny komputer jest w stanie przeprowadzać skomplikowane obliczenia, odtwarzać filmy fullhd/4k, grać w realistyczne gry 3D, a „zamula” na stronie www gdzie samej treści jest kilka kilobajtów, tzn. że technologia web poszła w złym kierunku;-) - Kristof 2019-07-15 18:29
@axde: rozejrzyj się po internecie a się dowiesz, @Kristof to nie tak, to ludzie odczuwają microprzycinanie na przeglądarce, jakby aplikacja działała tak samo to nikt by nie narzekał, ale że to przeglądarka to łooooo - mr_jaro 2019-07-15 18:59
tak, pisałem to w bodaj pierwszym poście, ale też widzę coraz większą świadomość, że prędkość strony ma wpływ na pozycjonowanie - czysteskarpety 2019-07-15 20:24

Pozostało 580 znaków

2019-07-15 20:09
0
axde napisał(a):

Praktycznie każda strona stojąca na jakimś frameworku przy każdej wizycie zasysa kilkanaście mb danych. Co ma do tego cache? Nic niej jest ciężkie do zrwalizowania. Zwykle to tylko niewiedza lub lenistwo. Siedziałem w projekcie w którym zdecydowano, że nie będziemy zaprzęgać jakiegokolwiek frameworka tylko czysty JS.

No ale przecież nie ma sensu za każdym wejściem na stronę zasysać tych samych plików css, javascript czy obrazków. Co do frameworków czy bibliotek, to daje przede wszystkim wygodę. Np. tak jak realizowałem dość zaawansowane formularze, ukrywanie i pojawianie się pewnych części formularza, przechodzenie bez przeładowania strony pomiędzy zakładkami, procedury AJAX czy inne rzeczy to takie połączenie Knockout.js + jQuery i bindowanie, no i MVVM vs. Vanilla JS znakomicie ułatwiało realizację tych zadań. Coraz większe wymagania klientów z którymi trzeba się uporać, dlatego są frameworki i biblioteki. Oczywiście nie ma problemu, wszystko mógłbym w projekcie który nie tak dawno robiłem obsłużyć wszystko w czystym JS, pytanie ile by to wszystko zajęło i jak to przełożyłoby się na akceptowalną cenę przez klienta końcowego.

Pozostało 580 znaków

2019-07-15 21:11
1
drorat1 napisał(a):
axde napisał(a):

Praktycznie każda strona stojąca na jakimś frameworku przy każdej wizycie zasysa kilkanaście mb danych. Co ma do tego cache? Nic niej jest ciężkie do zrwalizowania. Zwykle to tylko niewiedza lub lenistwo. Siedziałem w projekcie w którym zdecydowano, że nie będziemy zaprzęgać jakiegokolwiek frameworka tylko czysty JS.

No ale przecież nie ma sensu za każdym wejściem na stronę zasysać tych samych plików css, javascript czy obrazków.

Oczywiście, że nie ma sensu. Ale dlaczego jest to bardzo częste zjawisko? Wychodzę ze strony, wchodzę za jakiś czas tego samego dnia, i pobieram cały pakiet od nowa. Niewiedza czy lenistwo?

drorat1 napisał(a):

Co do frameworków czy bibliotek, to daje przede wszystkim wygodę. Np. tak jak realizowałem dość zaawansowane formularze, ukrywanie i pojawianie się pewnych części formularza, przechodzenie bez przeładowania strony pomiędzy zakładkami, procedury AJAX czy inne rzeczy to takie połączenie Knockout.js + jQuery i bindowanie, no i MVVM vs. Vanilla JS znakomicie ułatwiało realizację tych zadań.

Takie ich założenie. Często słyszę, że można za ich pomocą zbudować raz element, i powielić bez pisania kodu ponownie. Szkoda, że jest dużo projektów, które rzadko kiedy powiela jakiś element, a mimo to pcha się tam dużą kobyłę. Inna sprawa, że ten sam efekt można osiągnąć bez wspomagaczy, i nie musi to być dużo większy koszt nakładu pracy.

drorat1 napisał(a):

Coraz większe wymagania klientów z którymi trzeba się uporać, dlatego są frameworki i biblioteki. Oczywiście nie ma problemu, wszystko mógłbym w projekcie który nie tak dawno robiłem obsłużyć wszystko w czystym JS, pytanie ile by to wszystko zajęło i jak to przełożyłoby się na akceptowalną cenę przez klienta końcowego.

Pytanie jak to się przełoży kiedy projekt się rozrośnie. Jak to się będzie skalować. Co gdy okaże się, że zaciąganie setek zależności powoduje zamulenie projektu przy większym ruchu? Winę zgonimy na backend jak to zawsze ma miejsce.
Byłem raz w takim projekcie. Chłopaki przejęli rzeźbiony Angular z Reactem, i przepisywali na nowo bez frameworków. Zaciąganie 10kb biblioteki do animacji jednego elementu to nie jest najlepszy pomysł, a gdy takich kwiatków jest kilkanaście to bardzo kiepsko.

Pozostało 580 znaków

2019-07-15 21:20
2

Weźcie pod uwagę, że nawet jak strona dociąga 2 MB po każdym przejściu do następnej strony to i tak na łączu 5 MB/s trwa to pół sekundy. Kiedyś stronki ważyły < 100 KB, ale na łączu np 33 kbps czyli 4 KB/s stronka taka ładowała się np pół minuty. I tak jest postęp :] Mamy dzisiaj 1000x szybszy dostęp do Internetu (biorąc pod uwagę przepustowość) niż w czasach dostępu wdzwanianego. Stronki nie ważą 1000x więcej tylko np 100x więcej niż wtedy, więc i tak jest 10x szybciej.


"Programs must be written for people to read, and only incidentally for machines to execute." - Abelson & Sussman, SICP, preface to the first edition
"Ci, co najbardziej pragną planować życie społeczne, gdyby im na to pozwolić, staliby się w najwyższym stopniu niebezpieczni i nietolerancyjni wobec planów życiowych innych ludzi. Często, tchnącego dobrocią i oddanego jakiejś sprawie idealistę, dzieli od fanatyka tylko mały krok."
Demokracja jest fajna, dopóki wygrywa twoja ulubiona partia.
edytowany 1x, ostatnio: Wibowit, 2019-07-15 21:20
Wyłącz uBlock, Adblock, i sprawdź te czasy ponownie. - axde 2019-07-16 05:42

Pozostało 580 znaków

2019-07-15 21:44
2
Wibowit napisał(a):

Weźcie pod uwagę, że nawet jak strona dociąga 2 MB po każdym przejściu do następnej strony to i tak na łączu 5 MB/s trwa to pół sekundy.

Nie koniecznie, zależne od opóźnienia serwera, rodzaju plików, sprzętu klienta (cpu, przeglądarka, plan energii w lapku, ustawień karty sieciowej), lokalizacji, itp. 2MB to bardzo dużo jest, a transfery nadal kosztują sporo.


Pozostało 580 znaków

2019-07-15 21:54
5

Dobra, nikt nie chce wzbudzić nostalgii to ja ją wzbudzę...


Ten dźwięk z jednej strony mnie przerażał, z drugiej wiedziałem, że zaraz będzie internet.

Pokaż pozostałe 18 komentarzy
Fajnie się słucha takich opowieści :) - Silv 2019-07-20 21:11
Tak.. gorzej, że teraz ja (oraz pewnie kilka innych osób z tego wątku) czuję się jak dinozaur, element składowy historii polskiej internetyzacji. Jesteśmy jak Cobol albo karty perforowane :( - cerrato 2019-07-20 21:15
@cerrato: Jak to? Ktoś wkłada ci igłę w dziurkę? ;) - PerlMonk 2019-07-20 22:36
wkładał, bo teraz już jestem przestarzały i zabytkowy - cerrato 2019-07-20 22:43

Pozostało 580 znaków

2019-07-17 22:59
0

Narzekacie na spory js a zaraz będzie jeszcze gorzej :D Co prawda link do portalu gdzie nie ma za wiele dobrych technicznie tekstów ale no przynajmniej złapiecie o co chodzi :) https://www.dobreprogramy.pl/[...]ikacjach-SPA,News,102659.html

Pokaż pozostałe 61 komentarzy
W ogóle napisałeś Jaki będzie narzut na synchronizację między częścią JSową, a WASMową? a później wyszło, że chodziło o DOM, to było pisać, że DOM. - no pisałem, że o DOM chodzi. Pokazywałem już dużo wcześniej diagram z architekturą Blazora, gdzie jest Shadow DOM i prawdziwy DOM, które są synchronizowane. - Wibowit 2019-07-18 21:25
@LukeJL: zrobiłem swój pro benchmark (zsumowałem wyniki z twojego :D) i wyszło mi js/wasm -> 3413/3316, czyli praktycznie to samo. Powiedz jak u ciebie na Chromie. - WeiXiao 2019-07-18 21:30
MultiplyInt jest przypadkiem sprzyjającym dla WASMa, bo 1) JS używa double'i a nie intów 2) ten benchmark nie odwołuje się w ogóle do żadnych tablic czy referencji. Weź benchmark, który odwołuje się do tablic i przewaga WASMa stopnieje. Poza tym jak porównasz wyniki MultiplyInt i MultiplyDouble to wyjdzie ładnie, że w JS nie ma różnicy (bo skopali benchmark i operują w obu na double'ach), a w WASMie różnica jest > 3x (bo rzeczywiście używają różnych typów, a WASM ma wbudowane wsparcie dla innych typów liczbowych niż double). - Wibowit 2019-07-18 21:32
@WeiXiao multiplyInt wyszło mi, że WA jest lepszy JavaScript: 1289.0770 WebAssembly: 275.2390 JavaScript/WebAssembly: 4.6835 ale już multiplyDoubleVec mi wyszło, że WA jest gorszy JavaScript: 92.0500 WebAssembly: 173.8465 JavaScript/WebAssembly: 0.5295 - LukeJL 2019-07-18 21:37
a sumarycznie wszystkie testy poza video? - WeiXiao 2019-07-18 21:37

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0