Trafił w moje ręce darmowy e-book poświęcony zagadnieniom wydajności stron WWW, Nie potrzebujesz frameworków Angular, React lub Vue.js! Stwórz dynamiczną stronę WWW BEZ ICH UŻYCIA w 1h! Bartłomieja Misia. E-book ma raptem 25 stron i ostrzega na pierwszej stronie, że zawiera mega przydatną treść
, więc stwierdziłem, że nie zaszkodzi do niego zajrzeć.
-
Główna treść zaczyna się od zaprezentowania kilku projektów, które stworzyła agencja Bigger Picture. Nie byłbym sobą, gdybym z ciekawości nie sprawdził, jakie wyniki wydajności mają te strony w Lighthouse. W tym celu wykorzystałem stronę web.dev:
- https://www.access-is.com/ – 70
- https://www.hampshirelight.net/ – 73
- https://www.happykitchens.uk/ – 30
- https://www.biggerpicture.agency/ – 69
Porównywalne wyniki (z wahaniem w granicach 3-5 punktów) można uzyskać w PageSpeed Insights oraz w lokalnym Lighthouse przy symulacji połączenia 3G i zwolnienia CPU. W repozytorium do tego artykułu znajdują się raporty wygenerowane przez web.dev.
Oczywiście fakt, że te strony otrzymują tyle punktów w żaden sposób nie świadczy o tym, że dalsza treść książki jest zła. Pokazuje jednak inny problem: jeśli powtórzyć te testy w lokalnym Lighthouse dla normalnej prędkości łącza i normalnego CPU, wyniki oscylują w granicach 100 punktów. Od razu nasuwa się problematyka związana z pewnym rozdźwiękiem między webdeveloperami a użytkownikami ich produktów, którzy pracując na nowym, wydajnym sprzęcie nie dostrzegają problemów trapiących część ich użytkowników. Dlatego też coraz częściej następuje wręcz przejście od tradycyjnego myślenia o wydajności jako po prostu jednej z funkcji aplikacji do myślenia o wydajności jako problemu moralnego. Być może takie przesunięcie oraz dalszy rozwój narzędzi pokroju Lighthouse pozwoli zminimalizować problemy związane z otyłością stron. Zwłaszcza, że przeglądarki coraz częściej przyglądają się budżetowaniu zasobów (i to od dość dawna, vide Budget API).
-
Wróćmy jednak do treści książki.
Jeżeli natomiast mamy do stworzenia stronę WWW, której głównym zadaniem jest – z technicznej perspektywy – wyświetlanie / prezentacja danych w atrakcyjny, animowany sposób, z celem osiągnięcia wysokich pozycji w wyszukiwarkach – stwórz front-end bez użycia jakiegokolwiek frameworka.
Niekoniecznie się z tym zgodzę, bo sensowne projektowanie aplikacji wymaga odpowiedniego poziomu abstrakcji. Dodatkowo od kilku lat pojawiają się głosy – moim zdaniem jak najbardziej słuszne – że oprócz użytkowników w tym równaniu są też developerzy, rozwijający i utrzymujący oprogramowanie. Sztuka zatem polega na zachowaniu odpowiedniej równowagi pomiędzy UX i DX. Wydaje się jednak, że developerzy są na z góry straconej pozycji, stojąc nie po tej (płacącej) stronie barykady, co trzeba.
Dlatego powtórzę się po raz kolejny: rozwiązania tego nierozwiązywalnego konfliktu upatrywałbym nie tyle w odrzuceniu frameworków, co w zamianie ich na kompilatory. Ta zmiana już powoli następuje – mamy w końcu Svelte czy eksperymenty pokroju rawacta. Tym sposobem aplikacje możemy tworzyć z tyloma warstwami abstrakcji, z iloma się nam podoba, równocześnie na końcu otrzymując zoptymalizowany, „surowy” kod JavaScript, przystosowany do jak najszybszego wykonania w przeglądarce. Użytkownicy dostają wydajną aplikację, developerzy zaś – ulubione abstrakcje. I po raz pierwszy wszyscy będą zadowoleni (w teorii…). Natomiast samo odrzucenie frameworków i przejście czy to na czysty JS, czy też mniejsze biblioteki, nie rozwiązuje problemu, a jedynie przesuwa go w inne miejsce.
-
Pojawia się następnie argument, że realizacja strony na frameworku zabiera więcej czasu i jest tam wspomniany Server Side Rendering (SSR). Jednakże kontekst wydaje mi się niefortunny:
[…] wygenerowałbym strony statyczne (opierając się na Server-Side renderingu) […] Generowanie statycznych stron generuje nam także problemy na przyszłość, jeśli np. klient zachce jednak mieć „coś dynamicznego”.
Tak po prawdzie generowanie stron statycznych i SSR wykluczają się wzajemnie z samego założenia. SSR polega na generowaniu strony na serwerze, który ma dostęp do aktualnego stanu aplikacji. Nic nie stoi na przeszkodzie, by strona generowana na serwerze przy każdym odświeżeniu była inna. Z kolei w przypadku generowania stron statycznych nie istnieje coś takiego jak serwer. Maszyna, która generuje takie strony, może być nawet prywatnym komputerem developera albo systemem CI/CD. Z tego też powodu obydwa te rozwiązania są dostosowane do zupełnie innej klasy problemów. SSR jest przeznaczony dla aplikacji z dynamicznym, zmiennym stanem, a generatory – dla statycznych stron, na których jest prezentowana niezmienna treść. Tego typu rozróżnienie jest podstawowe, więc fakt, że nie da się go przeprowadzić na etapie projektowania, wskazywałby, że klient nie dostarczył wszystkich danych lub w trakcie pracy całkowicie zmienił wymagania.
-
Na tej samej stronie pojawia się jeszcze jeden sporny fragment:
[…] dodatkowo podłączenie back-endu po API przez GraphQL zajmie o wiele więcej czasu aniżeli napisanie front-endu „po prostu” i dopiero jego późniejsza integracja z back-endem.
Nie bardzo rozumiem, czym różni się napisanie frontu „po prostu” od napisania go dla backendu mającego API. Przecież to właśnie API, będące jedynym punktem styku frontu z backendem, gwarantuje pełną izolację jednego od drugiego. W przypadku bardziej tradycyjnego modelu tworzenia aplikacji internetowej frontend zwykle pisze się dla konkretnego backendu, który generuje strony na własne potrzeby. W przypadku komunikacji wyłącznie przy pomocy API, frontend sam decyduje o całym swoim kształcie, łącznie nawet z adresami URL.
Prawdopodobnie nie rozumiem, czym jest
frontend po prostu
, i rozjaśnienie tego terminu mogłoby całkowicie zmienić znaczenie tego fragmentu. -
Przechodzimy następnie do porównania dwóch wersji tej samej strony. Jedna jest stworzona w „czystym” JS, a druga przy wykorzystaniu biblioteki Barba.js. Wydaje mi się jednak, że porównanie to jest nie do końca uczciwe, ponieważ w wersji „czystej” brakuje animacji przy przewijaniu. To sprawia, że wersja ta jest o wiele bardziej „surowa” i wydaje się mniej przyjemna w obcowaniu. A przecież za te animacje odpowiada zupełnie inna biblioteka, Waypoints, która bez problemu mogła być wykorzystana także w „czystej” wersji. Takie porównanie byłoby jak najbardziej sprawiedliwe, ponieważ wówczas główną różnicą byłoby to, co wnosi Barba.js – czyli płynne przejścia pomiędzy podstronami.
Inna rzecz jest taka, że przy szybkim łączu odczucia mogą być odwrotne od zamierzonych. Z racji tego, że „czysta” wersja jest naprawdę lekka, kliknięcie na link powoduje niemal natychmiastowe wczytanie nowej strony. W przypadku wersji z Barba.js wczytywanie może wydawać się paradoksalnie wolniejsze, z powodu potrzeby wykonania animacji.
-
Dalsza część e-booka to instrukcja korzystania z Barba.js. Oczywiście zaczyna się ona od instalacji, a w niej:
(a) Instalacja
npm install barba.js --save-dev
Wydaje mi się, że biblioteka Barba.js w tym wypadku nie powinna być potraktowana jako zależność developerska. Nie jest ona bowiem konieczna do budowania naszej strony, tylko do jej działania. A to sprawia, że jest zwykłą zależnością, bez której strona nie będzie działać.
Uznanie tej biblioteki za zależność developerską, moim zdaniem, miałoby sens tylko wówczas, gdybyśmy rozprowadzali naszą aplikację w wersji zbudowanej (np. webpackiem). W przypadku jednak, gdybyśmy tak nie robili, uznanie tej biblioteki za zależność developerską sprawi, że może zostać ona niezainstalowana. Chociaż całkiem możliwe, że są to rozważania bardziej akademickie, bo aplikacje jako takie raczej nie są rozprowadzane przez npm.
-
Bardzo szkoda, że kod w tej książce prezentowany jest przede wszystkim w formie obrazków, przez co jest niedostępny i niemożliwy do zaznaczenia.
-
Pojawiają się także sugestie, co można poprawić, a w tym sugestia dotycząca leniwego ładowania obrazków:
[…] Uważam, że powinna być to standardowa funkcjonalność wbudowana w przeglądarki. Mój kolega z zespołu znalazł nawet to – https://caniuse.com/#feat=lazyload.
Tak po prawdzie leniwe ładowanie obrazków jest w trakcie standaryzacji. W Can I Use? znajduje się link do jakiejś naprawdę prehistorycznej wersji atrybutu
[lazyload]
.Pojawia się także sugestia wstrzykiwania krytycznego CSS-a. Pytanie brzmi, na ile faktycznie pozwala to przyśpieszyć stronę, a na ile jest to sztuka dla sztuki – zwłaszcza w dobie takich rozwiązań, jak HTTP/2 server push.
-
W całej książce nie pojawiło się ani razu porównanie szybkości obydwu rozwiązań („czystego” i opartego na Barba.js). Postanowiłem zatem jeszcze raz wykorzystać web.dev. Okazało się, że według tego narzędzia obydwie strony są tak samo szybkie. A więc w tym wypadku istotna jest tzw. postrzegana wydajność, nie zaś – faktyczna. I tutaj właśnie mam dylemat, co będzie postrzegane jako szybsze: strona bez animacji, wczytująca nowe podstrony niemal od razu, czy strona z animacją, która musi się odtworzyć? W oderwaniu od siebie obydwie strony wydają się szybkie, ale w zestawieniu niekoniecznie wskazałbym stronę opartą o Barba.js jako tę lepszą.
Szczerze powiedziawszy po tytule książki spodziewałem się czegoś zupełnie innego. Wyobrażałem sobie ją raczej jako rozbudowane case study, w którym wychodzilibyśmy od projektu stworzonego w React czy Angularze, wskazywali punkty, w których wydajność nie jest taka, jaka być powinna, a następnie naprawiali te bolączki poprzez usunięcie frameworka. Tego jednak nie było. Tak naprawdę ten e-book był prostym tutorialem pokazującym jak stworzyć efektowną stronę przy pomocy biblioteki Barba.js, co automatycznie spłyciło temat zapowiadany przez tytuł. A szkoda.
Dziękuję za recenzję – przyznam, że merytoryczna 🙂 Nie mniej jednak musimy postawić sprawę jasno: ebook zorientowany jest na uzyskanie efektu dynamicznego ładowania między podstronami, z tranzycjami (przy założeniu nieużywania popularnych frameworków). 70% ebooka jest temu poświęcone, pozostała część to optymalizacja, która choć bardzo ważna, nie jest tematem przewodnim w tym PDFie. Pańska recenzja poświęcona jest w 70% na szybkości/performance i niewielka część traktuje o faktycznym celu tego ebooka 🙂 Nie mnie jednak mam nadzieję, że choć część front-end developerów znajdzie tam coś dla siebie. A co do optymalizacji – zarówno w ebooku jak i na głównej stronie mojego projektu zachęcam do zabrania głosu właśnie w sprawie optymalizacji front-endu i Pańska recenzja jest doskonałym zaczątkiem tego jakże ciekawego tematu, który zamierzam poruszyć w niedalekiej przyszłości. Dziękuję!
Tylko że z treści strony, która reklamuje tego e-booka można wywnioskować coś innego:
To sugeruje, że nacisk w tej pozycji będzie położony właśnie na optymalizację. Także we wstępie jest zaznaczone, że uzyskana strona będzie zoptymalizowana i szybka. Także jeden z punktów dotyczących wad frameworków podnosi, że są ciężke i przez to strona jest niezoptymalizowana. Poza tym samo słowo „dynamiczna” nasuwa skojarzenia z optymalizacją szybkości. Czemu strona jest dynamiczna? Bo jest szybka. Zresztą z innego punktu widzenia zamiana normalnych żądań na żądania ajaksowe średnio robi sensy.
Stąd też miałem takie a nie inne oczekiwania względem książki i stąd też taka opinia.
Tytuł eBooka równie dobrze moglibyśmy zinterpretować w sposób następujący (i taki był zamysł, co zresztą na tej samej stronie reklamowej jest widoczne poprzez chociażby pogrubienie): Jak stworzyć super zoptymalizowaną, **dynamiczną stronę WWW lub aplikację webową
bez użycia Angular, React lub Vue.js** w 1 godzinę.
Sądzę, że każdy indywidualnie ma swoje oczekiwania, sugerując się tytułem, przez co akurat Pana bardziej zaintrygował fragment „super zoptymalizowana”, dlatego też nie byłby Pan sobą, gdyby nie użył Pan Lighthouse’a do zmierzenia szybkości stron już na samym początku (i poświęcił temu lwią część recenzji) 🙂 Co do słowa „dynamiczna” i nasuwające się skojarzenia – kwestia dyskusyjna. Przyzna Pan, że nie możemy też uznać, że przedstawione rozwiązanie w ebooku jako demo nie są szybkie, gdyż nawet w recenzji padają słowa, że są 🙂
W dalszym ciągu uważam (i takie też trafiają do mnie sygnały), że część front-end developerów znajdzie w tym dokumencie coś dla siebie.
Oczywiście nie twierdzę, że nie znajdą, po prostu wydaje mi się, że gdyby publikacja poszła w nieco inną stronę, rzeczy do znalezienia byłoby jeszcze więcej 😉
Zostawię sobie zatem tę „inną stronę” na kolejne materiały. Nie ukrywam, że zainspirował mnie Pan do rozwoju kierunku tego dość rozległego ale jakże ciekawego tematu, za co jestem wdzięczny.
Wszystkiego dobrego!