Cześć, z tej strony Kuba.

Przez większość życia po backendowej stronie barykady człowiek przyzwyczaja się do pewnego luksusu.

Jeżeli coś zaczyna chodzić za wolno, zawsze gdzieś z tyłu głowy istnieje bardzo eleganckie rozwiązanie:

więcej zasobów.

Więcej RAM-u.

Więcej CPU.

Większy VPS.

Potem oczywiście mówimy:

„trzeba będzie to kiedyś zoptymalizować”.

I wszyscy wiemy, jak często następuje to „kiedyś”.

A później człowiek wpada na pomysł, żeby zrobić coś efektownego na froncie.

I nagle odkrywa, że użytkownik nie pozwala dołożyć RAM-u do swojego telefonu.

Skandal.

Wszystko zaczęło się od lodowiska

Przy nowej stronie lodowiska Hit2Fit chciałem zrobić coś, co będzie bardziej doświadczeniem niż zwykłym hero z dużym zdjęciem.

Powstał pomysł animacji cząsteczkowej.

Kilka tysięcy punktów renderowanych na żywo w canvas, które mogą układać się w określone kształty.

Na przykład:

łyżwę.

Potem logo.

A potem — jak zwykle — pojawiło się kilka kolejnych pomysłów, które dla bezpieczeństwa projektu przemilczę.

Najważniejsze jest jedno:

to nie jest GIF.

Nie jest to MP4.

Nie jest to wcześniej wyrenderowana animacja.

Każda cząsteczka jest liczona i renderowana w czasie rzeczywistym.

I właśnie tutaj zaczęła się zabawa.

Fullscreen był świetnym pomysłem

Przez mniej więcej pięć minut.

Pierwsza wersja oczywiście zajmowała cały ekran.

Bo skoro coś może być duże, to dlaczego miałoby być rozsądne?

Efekt wyglądał dobrze.

GPU miało natomiast inne zdanie.

Wentylatory w laptopie rozpoczęły procedurę startową, temperatura zaczęła przypominać urządzenie gastronomiczne, a przeglądarka bardzo wyraźnie sugerowała zakończenie eksperymentu.

I tutaj backendowy odruch mówi:

dorzucamy zasoby.

Tylko frontend odpowiada:

nie.

Bo stronę może otworzyć ktoś na nowym MacBooku.

Ale może ją również otworzyć na kilkuletnim telefonie, mając w tle Spotify, komunikator i trzydzieści innych kart.

I projekt musi przetrwać oba przypadki.

Więcej FPS. Mniej romantyzmu.

Rozwiązanie okazało się znacznie mniej widowiskowe niż problem.

Zmniejszyłem roboczą rozdzielczość canvasa.

Ograniczyłem powierzchnię, którą trzeba przeliczać.

Animacja przestała walczyć o życie.

GPU się uspokoiło.

A całość zaczęła trzymać płynność.

Czyli klasyczna optymalizacja:

zamiast zastanawiać się, jak policzyć więcej — sprawdzamy, czy naprawdę musimy liczyć aż tyle.

I właśnie to jest jedna z tych rzeczy, które brzmią banalnie dopiero po znalezieniu rozwiązania.

Frontend ma trochę inne zasady gry

Backend działa w kontrolowanym środowisku.

W dużej mierze sami decydujemy:

na czym,

z jakimi zasobami,

w jakiej konfiguracji

uruchomimy aplikację.

Frontend trafia w dzicz.

Nie wiemy, jaki użytkownik ma procesor.

Nie wiemy, jaką kartę graficzną.

Nie wiemy, ile kart ma otwartych.

Nie wiemy nawet, czy jego przeglądarka dostała aktualizację w tym dziesięcioleciu.

Dlatego efekt wizualny może być piękny w naszym środowisku developerskim i jednocześnie kompletnie nie nadawać się do produkcji.

Ładne nie wystarczy. Musi jeszcze działać.

Po co w ogóle robić takie rzeczy?

Przecież można wrzucić zdjęcie lodowiska.

Duży napis.

Przycisk.

I koniec.

Można.

Tylko że czasami technologia może być częścią opowieści o miejscu.

Lodowisko może mieć stronę, która zachowuje się inaczej niż strona kancelarii prawnej.

Park trampolin może mieć inną dynamikę niż klinika neurologiczna.

Laser tag może wizualnie reagować na użytkownika jeszcze zanim ten pojawi się na miejscu.

Interakcja nie powinna istnieć tylko dlatego, że programista nauczył się nowej sztuczki.

Ale jeżeli pomaga przenieść charakter marki do przeglądarki — zaczyna mieć sens.

R&D, czyli elegancka nazwa na „sprawdźmy, czy się da”

Tak właśnie traktuję ten projekt.

Nie jako gotowy produkt, który powstał z perfekcyjnej specyfikacji.

Tylko jako małe R&D.

Pomysł.

Prototyp.

Katowanie GPU.

Optymalizacja.

Kolejny prototyp.

I stopniowe dojście do rozwiązania, które może już spokojnie trafić na produkcję.

Przy okazji powstaje mechanizm, który później można wykorzystać ponownie.

Bo jeżeli już raz rozwiązaliśmy problem kilku tysięcy cząsteczek układających się w obiekt, nie ma większego sensu pisać całego silnika drugi raz.

Budujemy klocek. Potem używamy go ponownie.

To samo robimy z automatyzacjami, integracjami i naszymi Zwykolakami.

Mniej mocy. Lepszy efekt.

I chyba właśnie to jest najciekawsza lekcja z całego eksperymentu.

Optymalizacja nie zawsze oznacza napisanie bardziej inteligentnego algorytmu.

Czasami oznacza:

zrób mniej.

Renderuj mniej.

Przeliczaj mniej.

Nie używaj technologii, której nie potrzebujesz.

Nie próbuj wygrać siłą obliczeniową problemu, który można usunąć zmianą założenia.

A potem dodaj obok tekst i powiedz, że dokładnie tak miało być od początku. 😄

Nowa strona lodowiska Hit2Fit jeszcze powstaje.

Animacja już żyje.

GPU również.

Czyli uznaję etap za sukces.

Saku Media
WWW × technologia × R&D × trochę niepotrzebnych pomysłów, z których czasami wychodzi coś bardzo potrzebnego.