Choroba cywilizacyjna

https://xpil.eu/0mlFU 📋

Wszyscy doskonale wiemy, że otyłość jest chorobą społeczeństw tzw. "wysoko rozwiniętych"

Piszę "tzw" ponieważ gdyby były one faktycznie wysoko rozwinięte, poradziłyby sobie z taką "chorobą" w trymiga, więc chyba nie o rozwój tu chodzi - a przynajmniej nie o taki rozwój, jak się go powszechnie rozumie.

No więc okazuje się, że podobny problem dotyczy "nowoczesnych" stron internetowych.

Są one utuczone ponad miarę, ponad wszelkie rationale. Głównie za sprawą dwóch czynników:

1. Reklamy
2. Strzelanie z armaty do much

O ile z pierwszym powodem otyłości walczyć nie zamierzam (wszyscy kochamy reklamy, prawda?), o tyle drugi jest dość istotny. Okazuje się, że z jakichś niewiadomych powodów twórcy stron www ładują "pod maskę" takie ilości dodatkowych zbędnych technologii, że najprostsza strona z niewielką ilością informacji puchnie do megabajtów, dziesiątków megabajtów albo i gorzej.

Weźmy na przykład taki artykuł: http://motherboard.vice.com/read/i-built-a-botnet-that-could-destroy-spotify-with-fake-listens

Strona ma pięć megabajtów, z czego większość jest zmarnowana na jeden wielki obrazek ze słuchawkami oraz kupę skryptów JS. A przecież jedynym celem tego artykułu jest przekazanie czytelnikowi informacji o tym, jak sztucznie nabijać kasę za pomocą Spotify oraz prostego botnetu. Sam tekst w tym artykule to około osiem tysięcy bajtów. Trzy rzędy wielkości mniej! Strona ładuje się prawie trzy i pół sekundy, tylko po to, żeby przekazać czytelnikowi informacje, które dałoby się przekazać w jedną dziesiątą sekundy.

Jeszcze jeden przykład: artykuł na temat zegarka Apple: http://www.theverge.com/a/apple-watch-review. Ponad 7 MB danych do przepchnięcia przez łącza, zajmuje to między 2 a 3 sekundy, a użytecznych informacji jest tam jak na lekarstwo. 80% miejsca skonsumowane przez obrazki (w tym obrazki tła, które pogarszają czytelność treści) oraz skrypty JS odpowiedzialne za "piękne" efekty wizualne, które moim zdaniem są jak strzelanie z armaty do much.

A skąd się to bierze?

Bierze się to z przeszacowania potrzeb i wymagań. Jeżeli ktoś ma małą, prywatną stronę www, która mu się nagle zaczyna rozrastać ponad wszelkie wyobrażenie, zacznie szukać rozwiązań, które się dobrze skalują, dadzą więcej elastyczności i tak dalej i tak dalej. Niechybnie prędzej czy później trafi na speców od sprzedaży, którzy namówią go na przejście na jakiś "dojrzały" framework. Tylko że nikt nie wspomni, że ów framework będzie dostarczał z pięć tysięcy innych funkcji, które naszemu domorosłemu webmasterowi będą całkiem zbędne, a które będą się - chociaż nieużywane - ładować w tle za każdym razem, kiedy czytelnik strony puści bąka.

Dobra analogia to słynny artykuł pokazujący, w jaki sposób można za pomocą niewielkich środków zrealizować całkiem niebanalne przedsięwzięcie, jakim jest analiza dwóch milionów partii szachów. Zamiast angażować do tego silniki baz danych, Hadoopy z dupy czy inne wielkie serwery i inne etcetery, można to przeprowadzić o wiele wydajniej na pojedynczym laptopie, przy użyciu wyłącznie linuksowego wiersza poleceń: http://aadrake.com/command-line-tools-can-be-235x-faster-than-your-hadoop-cluster.html

(nawiasem mówiąc artykuł ów to około 10 KB tekstu, a strona z artykułem waży ponad ćwierć megabajta)

Strona główna PayPal-a to ponad 12 MB (!) danych, głównie bezwartościowe wideo w tle. Dlaczego ktoś, kto chce wykonać płatność on-line, musi najpierw ładować przez przeglądarkę dwunastomegabajtowe wideo?

Inna przyczyna puchnięcia stron www to organizacja pracy w organizacjach zajmujących się produkowaniem oprogramowania. Jeżeli jestem managerem, który ma do skończenia projekt, i ten projekt się wreszcie skończy (a więc osiągnie fazę gotowego produktu, dostarczonego do szczęśliwych użytkowników końcowych), nagle okaże się, że dla moich ludzi nie ma nic więcej do roboty. Trzeba będzie zmniejszyć team, co z kolei zmniejszy prestiż mojego stanowiska! Tak nie może być! Musimy szybciutko wykombinować coś, czego "brakuje" naszemu produktowi, a co da zajęcie ludziom na kolejne miesiące.

Idealnym przykładem jest tu WinAmp - produkt był w zasadzie gotowy, idealny, perfekcyjny, w okolicach wersji 2.0. Tymczasem jednak trzeba było znaleźć zajęcie programistom, więc po wersjach 3, 4 i 5 WinAmp rozrósł się do takiego monstrum, że ledwie był w stanie odtwarzać muzykę, o ile użytkownikowi udało się jakoś znaleźć właściwe ku temu okienko. I co? I dupa, produkt zdechł, bo się był przeżarł niepotrzebnymi opcjami... Na tej samej zasadzie programiści webowi dodają coraz to nowe opcje do serwisów, które idealnie spełniają swoją funkcję - próbują zrobić z nich kombajny do wszystkiego. A jak coś jest do wszystkiego... wiadomo. Efekt jest taki, że przeczytanie jednego zdania on-line wymaga nagle załadowania pięciu warstw logicznych software-u, milionów skryptów, a to wszystko z jakiejś gigantycznej chmury.

Można na zagadnienie spojrzeć z jeszcze innej strony: często jest tak, że jak nam strona www działa za wolno, kupujemy szybsze łącze, lepszy serwer, większą chmurę. I przez jakiś czas cieszymy się, że zaczęło chodzić trochę szybciej, ale potem kółko się zamyka, więc znów dokupujemy przestrzeni dyskowej, megabitów na sekundę, teraflopsów itd. Aż wreszcie dochodzi do paradoksalnej sytuacji, że utrzymanie usługi przynoszącej nam, dajmy na to, 5000 dolarów miesięcznie, kosztuje nas 6000 dolarów w samej infrastrukturze. A dałoby się przecież - zamiast inwestować w coraz to większe serwery i łącza, po prostu zoptymalizować to, co już mamy. Jeżeli napiszę kiepskie zapytanie SQL, to zdziesięciokrotnienie serwerów nie pomoże bardziej, niż modlitwy o deszcz. Należy zainwestować w poprawienie samego zapytania, a nie infrastruktury.

Oczywiście gówniana infrastruktura może zaszkodzić, ale nie o to chodzi.

Końcowy wniosek jest taki, żeby zawsze liczyć siły na zamiary (bądź też na wymiary, jak mawiał komandor McPig - pamięta ktoś?) i robić rzeczy z głową.

Na zakończenie przykład z własnego podwórka: złapałem się dziś na tym, że ponad połowa pojemności każdego artykułu na tym blogu jest (a raczej była) pożarta przez durne ikonki w menu. Usunięcie ikonek spowodowało skrócenie czasu ładowania o połowę bez jakościowej utraty funkcjonalności.

Ha.

https://xpil.eu/0mlFU 📋