POIT #104: Optymalizacja front-endu

Witam w sto czwartym odcinku podcastu „Porozmawiajmy o IT”. Tematem dzisiejszej rozmowy jest optymalizacja front-endu aplikacji webowych.

Dziś moim gościem jest Bartek Miś, frontend developer z wieloletnim doświadczeniem, programista PHP, DevOps i mentor. Co-Founder oraz CTO w agencji i software house’ie Studio Sidekicks / Bigger Picture. Pod szyldem Web Dev Insider dzieli się wiedzą z zakresu optymalizacji webowej. Prowadzi kanał na YouTube i bloga o tej samej nazwie.

W tym odcinku o optymalizacji front-endu rozmawiamy w następujących kontekstach:

  • czym jest optymalizacja front-endu?
  • po co optymalizować front-end?
  • jak przekonać biznes do optymalizacji front-endu?
  • czym jest Web Core Vitals?
  • od czego zacząć optymalizację?
  • jakie elementy front-endu najlepiej optymalizować?
  • jak rozumieć i wdrażać optymalizację front-endu jako proces?
  • jak w codziennej pracy developera znaleźć czas na optymalizację?
  • jakie wyznaczniki optymalizacyjne warto kontrolować?
  • jakie narzędzia mamy do dyspozycji?

Subskrypcja podcastu:

Linki:

Wsparcie na Patronite:

Wierzę, że dobro wraca i że zawsze znajdą się osoby w bliższym lub dalszym gronie, którym przydaje się to co robię i które zechcą mnie wesprzeć w misji poszerzania horyzontów ludzi z branży IT.

Patronite to tak platforma, na której możesz wspierać twórców internetowych w ich działalności. Mnie możesz wesprzeć kwotą już od 5 zł miesięcznie. Chciałbym oddelegować kilka rzeczy, która wykonuję przy każdym podcaście a zaoszczędzony czas wykorzystać na przygotowanie jeszcze lepszych treści dla Ciebie. Sam jestem patronem kilku twórców internetowych i widzę, że taka pomoc daje dużą satysfakcję obu stronom.

👉Mój profil znajdziesz pod adresem: patronite.pl/porozmawiajmyoit

Pozostańmy w kontakcie:

 

Muzyka użyta w podcaście: „Endless Inspiration” Alex Stoner  (posłuchaj)

Transkrypcja podcastu

To jest 104. odcinek podcastu Porozmawiajmy o IT, w którym z moim gościem rozmawiam o optymalizacji frontendu. Przypominam, że w poprzednim odcinku rozmawiałem o low code, no code.  

Wszystkie linki oraz transkrypcję dzisiejszej rozmowy znajdziesz pod adresem porozmawiajmyoit.pl/104

Ocena lub recenzja podcastu w Twojej aplikacji jest bardzo cenna, więc nie zapomnij poświęcić na to kilku minut. 

Nazywam się Krzysztof Kempiński a moją misją jest poszerzanie horyzontów ludzi z branży IT. Środkiem do tego jest między innymi ten podcast. 

Zostając patronem na platformie Patronite możesz mi w tym pomóc już dziś. Wejdź na porozmawiajmyoit.pl/wspieram i sprawdź szczegóły!

Jednocześnie bardzo dziękuję moim obecnym patronom. 

Teraz życzę Ci miłego słuchania! 

Odpalamy! 

 

Cześć! Moim i Waszym gościem jest frontend developer z wieloletnim doświadczeniem, programista PHP, DeVOps i mentor, co-founder oraz CTO w agencji i software housie Studio Sidekicks/Bigger Picture pod szyldem Web Dev Insider dzieli się wiedzą z zakresu optymalizacji webowej. Prowadzi kanał na YouTube i bloga właśnie o tej samej nazwie.

Moim i Waszym gościem jest Bartek Miś.

Cześć, Bartku! Bardzo miło mi gościć Cię w podcaście! 

 

Cześć, Krzysztof! Dzięki za zaproszenie, bardzo mi miło, że mogę być gościem twojego podcastu! 

 

Cieszę się bardzo!  W tej zapowiedzi powiedziałem, że zajmujesz się optymalizacją webową, że dzielisz się wiedzą właśnie z tych obszarów i właśnie o tym temacie chciałbym dziś z tobą porozmawiać. O optymalizacji, powiedzmy, frontendu, ale właśnie z takim nastawieniem na tę część webową. Mam nadzieję, że nie masz nic przeciwko. 

 

Jak najbardziej. Wydaje mi się, że powinniśmy właśnie się na tym temacie skupić, gdyż jest on szczególnie istotny w mojej opinii. 

 

Dokładnie. Właśnie o tym będę chciał dzisiaj z tobą porozmawiać, o takiej perspektywie i technicznej, ale też biznesowej – o tym co użytkownik rozumie pod pojęciem optymalizacji webowej, co to właściwie dla niego znaczy. 

Ale żeby wszystkim formalnościom stało się zadość, no to zapytam się oczywiście czy słuchasz podcastów, jeśli tak to może masz jakieś swoje ulubione?

 

Wiesz co, jakoś nie nazwałbym siebie może jakimś nałogowym słuchaczem podcastów, ale zdarza mi się od czasu do czasu po prostu posłuchać tego, co akurat właśnie wyszło i mnie zainteresowało. Natomiast nie mam tak, że codziennie muszę słuchać jakiegoś tam podcastu i że jest to moja rutyna, natomiast rzeczywiście mam tutaj kilka tak naprawdę takich propozycji podcastowych, które też może właśnie słuchaczy tego podcastu zainteresują. 

Pierwszy podcast, który chciałbym polecić to jest Syntax.fm, to jest podcast, którego autorami są West Bos i Scott Tolinski. Jest to podcast, który jest kierowany przede wszystkim do web developerów i tutaj tematami, które są podejmowane na tym podcaście to przede wszystkim jest to taki modernistyczny web development. Czyli wszystko, co jest związane z nowinkami o CSS-ie, o JavaScriptcie i tak dalej, czyli takie nowoczesne podejście do web developmentu, z nowoczesnymi rozwiązaniami. Bardzo fajny podcast i bardzo polecam. Właśnie zdarza mi się najczęściej właśnie tego podcastu słuchać. To jest bodajże amerykański podcast. 

Natomiast jeśli chodzi o polskie podwórko, to tutaj nie do końca chcę cukrować, ale zdarza mi się przede wszystkim słuchać Twojego podcastu, czyli Porozmawiajmy o IT, natomiast chciałbym zwrócić uwagę, że szczególnie interesują mnie te odcinki, które są o tematach około IT. 

Na przykład ostatnim bardzo fajnym odcinkiem w Twoim podcaście był odcinek z Kamilem Lelonkiem o efektywności pracy mózgu i tak dalej. Bardzo fajny podcast, bardzo fajny odcinek. Polecam!

Oprócz tego – nie wiem, czy możemy to zakwalifikować do kategorii podcastów, natomiast ostatnimi czasy dużą popularność zyskuje aplikacja ClubHouse. I nie wie, czy możemy to tutaj tak zakwalifikować, natomiast wydaje mi się, że jest to trochę taki rodzaj interaktywnego podcastu, w którym również my jako słuchacze możemy brać udział jako mówcy i nie ukrywam, że ostatnimi czasy nawet telefon leży sobie z boku i w tle słucham sobie co tam leci ciekawego w jakichś poszczególnych pokojach i na razie nie biorę aktywnego udziału, raczej jest to słuchanie bierne. Natomiast też mam w planach kiedyś wejść jako speaker. 

Także moim zdaniem to też jest taki rodzaj podcastu, który aktualnie przybiera duże znaczenie na rynku. 

 

Dzięki za podzielenie się tą listą. Też polecam wszystko to, o czym przed chwilą powiedziałeś! Do Clubhouse’a też mam takie ambiwalentne podejście, w sensie: niektórzy mówią faktycznie, że to są takie podcasty live, takie rozmowy, którymi się można utożsamiać, przysłuchiwać, udzielać się, różne są podejścia. Natomiast można też z tym czasem trochę tam popłynąć. Ten efekt FOMO jest tam dopracowany do perfekcji. Niemniej jednak dla branży audio jako takiej też poczuwam się trochę jej częścią – jest to faktycznie jakiś krok do przodu. Jestem ciekaw, w którym kierunku to będzie szło. Zobaczymy. 

 

Dokładnie. 

 

Przejdźmy do meritum. Zacznijmy może od tego, czym właściwie jest optymalizacja frontendu, myślę tutaj głównie o tym nastawieniu na webową część. Czyli właściwie co to jest za proces, co chcemy optymalizować, czy to jest taka wisienka na torcie po zrealizowaniu projektu czy może jakiś element, który wchodzi w skład? Jestem ciekaw właśnie, jak ty definiujesz optymalizację webową, frontendową. 

 

Na samym początku mielibyśmy powiedzieć, że kiedy tworzymy daną stronę albo aplikację webową, to to już jest proces sam w sobie. Natomiast optymalizacja frontendowa to jest element tego właśnie procesu. To jest element polegający na stosowaniu odpowiedniego podejścia w zespole IT, wśród developerów, ale także wśród klienta, wśród biznesu, z którym współpracujemy no i rzecz jasna stosowanie odpowiednich praktyk w kodzie, celem, aby dana strona czy aplikacja była po prostu wydajna. Mam tu na myśli to, żeby po prostu szybko się ładowała, nie powodowała frustracji wśród użytkowników, zwłaszcza na urządzeniach mobilnych i to jest właśnie to, na co ja zwracam szczególną uwagę – na urządzenia mobilne, na ten mobilny internet, gdzie ten rynek jest obecnie tak duży, że ludzie odchodzą od komputerów stacjonarnych, od laptopów nawet. Wszystko się odbywa za pośrednictwem smartfona. 

Zauważyłem z moich obserwacji, że ta optymalizacja na wielu, wielu stronach leży i powoduje mega frustrację, zwłaszcza kiedy gdzieś się zdarza, że mamy ten internet o słabszym połączeniu albo też po prostu smartfon o gorszych parametrach. To wszystko powoduje, że odwiedzając daną stronę, zwłaszcza taką nowoczesną, gdzie te wszystkie nowoczesne nowinki, technologie są stosowane to powoduje mega frustrację, gdyż użytkownik musi dłuższy czas spędzić na samym czekaniu na tej pasywnej fazie czekania, która jest najbardziej frustrująca, gdyż nie można w tym momencie nic zrobić. To bezpośrednio przekłada się też na szereg różnych czynników. 

I tutaj chciałem też nakreślić od samego początku, że to jest optymalizacja frontendu. Czyli skupiamy się na tej warstwie frontendowej. Dziś wydaje mi się, że jeżeli mówimy zazwyczaj w świecie webowym o optymalizacji, to mowa przede wszystkim jest o tym świecie backendowym, czyli jakieś zapytania do bazy, czy coś jest nie tak z serwerem, te wszystkie rzeczy pod spodem, co się dzieją, natomiast rzadko kto zwraca uwagę na to, co się dzieje na tej warstwie wizualnej, frontendowej już po stronie przeglądarki, gdyż to jest bardzo istotne i niejednokrotnie, nawet jeżeli mamy serwer o wysokich parametrach, mamy zastosowanie CDN-a, mamy super zoptymalizowane zapytania do bazy, ale na przykład stosujemy jakiś plug in, chociażby w WordPressie, który powoduje ładowanie na przykład 5 różnych tików JavaScriptowych, to suma summarum wyjdzie na to, że użytkownik naprawdę spędzi długi czas na czekaniu, zanim ta strona się otworzy. 

Także tutaj poruszyłem takie kwestie właśnie użyteczne. Chodzi o to, że kiedy użytkownik odwiedza daną stronę to żeby się nie frustrował i żeby chociażby ścieżka zakupowa na jakiejś danej platformie e-commerce albo sklepie e-commerce przebiegała z łatwością. Także wydajność to UX moim zdaniem i to jakie są właśnie wrażenia od użytkownika korzystając z danej strony, jakie one są i to wszystko przekłada się na szereg różnych rzeczy, takie jak chociażby zaufanie albo przywiązanie do marki, co jest niezwykle istotną sprawą. 

 

Chodzi o to, że kiedy użytkownik odwiedza daną stronę to żeby się nie frustrował i żeby chociażby ścieżka zakupowa na jakiejś danej platformie e-commerce albo sklepie e-commerce przebiegała z łatwością. Także wydajność to UX moim zdaniem i to jakie są właśnie wrażenia od użytkownika korzystając z danej strony, jakie one są i to wszystko przekłada się na szereg różnych rzeczy, takie jak chociażby zaufanie albo przywiązanie do marki, co jest niezwykle istotną sprawą.

 

Tutaj też ta pierwsza wizyta jest bardzo istotna – wyobraźmy sobie, kiedy wchodzimy na przykład do wyszukiwarki Google i wyszukujemy jakiś produkt, który nas interesuje i wchodzimy na jakiś sklep internetowy, na którym nigdy w życiu nie byliśmy. Jeżeli ten sklep wolno się ładuje, to tym sposobem raczej od razu wyjdziemy z tej strony, czyli ten współczynnik odrzuceń będzie wysoki i będziemy starać się znaleźć jakąś alternatywę do tego sklepu, żeby móc kupić ten produkt. Jeżeli nasze wrażenia tam są pozytywne, to w tym momencie tam dopiero dokonamy tego zakupu. 

Temat szeroki, moim zdaniem jest to temat traktowany po macoszemu, jeśli mówimy o optymalizacji frontendu, gdzieś tam developerzy i biznes raczej kładą nacisk na to, żeby coś działało, natomiast rzadko kto myśli o tym, jak to działa. A to jest bardzo istotna sprawa, gdyż to właśnie wzmaga to, czy użytkownik jest zadowolony, czy przywiązuje się do marki, czy ufa tej marce i czy później na przykład wjedzie na daną stronę jeszcze raz czy na przykład poleci też znajomym, co też bezpośrednio przełoży się, chociażby na wyniki finansowe. 

 

Nie wydaje ci się, że to trochę jest efekt większego nacisku, większego ciężaru, który obecnie spoczywa na frontendzie? I to nie tylko myślę o ilości plików, jaka jest ładowana, także ich mnogości, a także o tym, że na przykład duża część UI i tych interakcji z użytkownikiem jest właśnie przejmowana przez aplikacje frontendowe i o ile kiedyś był tam może 1, 2 pliki js-owe, plik CSS i nic się wielkiego nie działo, jeśli nawet wysyłaliśmy jakieś wielkie obrazki, bo ten efekt gdzieś tutaj nie był na tyle dotkliwy. Natomiast obecnie frontend jest bardzo duży i w związku z tym zauważyliśmy te braki, brak tej optymalizacji, że to nas uderza.

Zmierzam do tego, żeby cię zapytać, czy to nie jest przypadkiem tak, że frontend rośnie, więc uwypuklały się, uwypuklają się coraz bardziej braki związane z optymalizacją?

 

Wydaje mi się, że po części masz rację, czyli że rzeczywiście ten frontend development jest aktualnie tak szerokim spektrum tematów i szerokim tematem z różnymi technologiami, i to, co możemy zrobić tak naprawdę za pośrednictwem frontendu w dzisiejszych czasach, że rzeczywiście te zmieniające się technologie, coraz nowsze frameworki, jakieś rozwiązania, coraz szybszy internet, coraz lepsze parametrowo sprzęty, to spowodowało, że chce się więcej osiągnąć na frontendzie.

Upycha się rozwiązania, skrypty, animacje cięższe, gdyż jesteśmy przekonani, że ten nowy sprzęt i wszystko, co się dzieje na miarę 2021 roku chociażby, to przeglądarki powinny być w stanie to udźwignąć.

Natomiast niejednokrotnie tak nie jest. Także jest to szeroki temat, frontend i zwracam uwagę na to, żeby też zwrócić uwagę na tę optymalizację – że to nie zawsze tak jest, że wszystko będziemy w stanie po tej przeglądarce zrobić w sposób łatwy i płynny, i powinniśmy właśnie zwrócić uwagę na to, żeby zrobić to w jak najlepszy sposób.

Poniekąd, nie wiem, czy moja odpowiedź będzie odpowiadająca na twoje pytanie, natomiast stwierdziłeś w pewnym momencie, że ten nacisk na frontend developera jest coraz większy. Że to właśnie frontend developer poniekąd jest osobą, która jest odpowiedzialna za coraz większą ilość spraw dotyczącą tego, co się dzieje po stronie przeglądarki. I z tym się zgodzę, natomiast jestem też takiego zdania, żeby w danym zespole IT stworzyć sobie swojego rodzaju kulturę wydajności. Chodzi tutaj o to, że ta kultura wydajności w tym momencie powoduje, że to nie tylko frontend developer jest za to odpowiedzialny, ale też szereg innych osób, które z nim współpracują. I backend deweloperzy, i UI designerzy – ogólnie, cała otoczka strategiczna danej strony, danej aplikacji, chociażby.

Żeby wszyscy ludzie byli zaangażowani w tym temacie i żebyśmy wspólnie jako zespół mili jeden cel, że ta strona ma szybko się ładować w sposób zoptymalizowany, wydajny i po prostu te wrażenia dla użytkownika końcowego były jak najlepsze.

 

Powiedziałeś o kilku takich zaletach posiadania aplikacji, która działa w sposób płynny, mocno uwypukliłeś to znaczenia UX-a i tego, co tak naprawdę użytkownik czuje, jakie ma doznania w obcowaniu z aplikacją webową, którą stworzyliśmy, ale chciałem szerzej zapytać, po co właściwie ten frontend optymalizować?

Oczywiście – może to być połechtanie ego developerów, którzy są w stanie sobie wewnętrznie w jakichś benchmarkach pokazać pewien wzrost czy właściwie skrócenie czasu ładowania, zmniejszenie wielkości sumarycznej i tak dalej, ale to chyba nie do końca tylko o to chodzi prawda?

Jakie byś wyróżnił takie podstawowe powody, dla których warto się zabierać za optymalizację frontendu?

 

Jeżeli tworzymy daną stronę albo aplikację, no to za daną stroną czy aplikacją staje biznes. Ten wątek biznesowy jest w moim mniemaniu tym największym powodem, dla którego powinniśmy optymalizować daną stronę i optymalizować ten frontend. Tutaj najwięksi gracze już dawno zauważyli, że optymalizacja frontendu bezpośrednio przekłada się na zyski. Tu mógłbym wymienić przykład Amazona albo Walmarta, gdzie obydwie firmy, zgodnie, już wiele lat temu stwierdziły, że każde sto milisekund opóźnienia w ładowaniu ich strony, frontendu de facto, bo właśnie o to chodzi przynosi średnio 1% mniej sprzedaży online dla tych wielkich sklepów.

Tutaj wiadomo – możemy sobie tutaj pomyśleć, że my nie jesteśmy Walmartem albo Amazonem, jesteśmy dużo mniejszym sklepem albo aplikacją, w porządku, natomiast to jest po prostu skala. Jeżeli ktoś zarabia 10 miliardów a my milion, to i tak da nam sumarycznie jakiś większy zysk po prostu skali – lub mniejszy – natomiast to nadal jest zysk, o który powinniśmy, moim zdaniem, walczyć.

Także tutaj ten wątek biznesowy moim zdaniem jest tym brakującym ogniwem na wielu stronach albo sklepach, gdyż bardzo często marketerzy zastanawiając się, czy dany produkt albo usługa jest w sposób odpowiedni zaprezentowany na danej stronie. Na przykład ten współczynnik odrzuceń jest wysoki – ta konwersja nie jest na odpowiednim poziomie, wszyscy się głowią, jakby tu jeszcze można było lepiej ten produkt bądź usługę zaprezentować, a bardzo często nie bierze się pod uwagę tego, że sama ta strona wolno się ładuje. I to może być powodem, dla którego właśnie współczynnik odrzuceń jest wysoki.

I wystarczyłoby czasem właśnie zoptymalizować frontend, pokusić się o jakieś takie bardzo podstawowe zmiany na stronach, żeby dana strona ładowała się w sposób szybki i to już realnie może przynieść naprawdę duże korzyści.

Ten wątek biznesowy moim zdaniem jest szeroki i w wielu stronach, na wielu sklepach jest to brakujące ogniwo w całym procesie marketingowym. Wydajemy pieniądze na reklamy, na SEO, a na podstawie tego podcastu poruszymy sobie ten temat, że SEO jest coraz ważniejszym tematem, jeśli mówimy o optymalizacji, gdyż te szybko ładujące się strony zoptymalizowane będą teraz najprawdopodobniej wyżej właśnie rankingowane, chociażby w wynikach wyszukiwania Google. Teraz takie brakujące ogniwo, o które warto zadbać, które szybko może przynieść nam wymierne korzyści.

Oprócz tego wątku biznesowego mam jeszcze inne – to zaufanie do marki, o którym powiedziałem. To też jest bardzo istotny temat. A skończyć możemy, chociażby na taki bardzo prozaicznym poziomie, że kiedy mniejszą ilość assetów, ale bardziej zoptymalizowanych będziemy ładowali w naszą stronę, to też nasz serwer będzie mniej obciążony. Także też poniekąd taki wątek ekologiczny można tutaj dostrzec, być może trochę na wyrost, natomiast też jest to coś, o czym powinniśmy pamiętać, że też obniżenie kosztów, chociażby obsługi naszej infrastruktury serwerowej też może tutaj wchodzić w grę.

 

Jasne. Czyli tych powodów faktycznie jest trochę – i biznesowe, i UX-owe, i techniczne. Myślę, że całkiem duży zbiór.

Myślę sobie, że nowoczesne firmy – mam nadzieję, że każdy z nas ma możliwość pracowania w takich albo z takimi, bazują obecnie mocno na danych. Chcą być data driven, driveny chcą też mierzyć wiele rzeczy. Najczęściej do takich KPI-ów, wskaźników należą różne techniczne elementy określające prędkość działania stron. Może inaczej – zazwyczaj do tego typu danych ma dostęp zespół produktowo-developerski, który potrafi na przykład odczytać jakieś tam aspekty i być może przekazać je dalej. Dlatego myślę, że jest tutaj całkiem duża rola developerów w tym, aby przekonywać ogólnie rozumiany biznes do tego, że warto frontend optymalizować. Jak można to zrobić? Jak można przekonać biznes, że warto zainwestować czas, może pieniądze w to, żeby nasza aplikacja po prostu działała szybciej, lepiej?

 

Wydaje mi się, że aby przekonać biznes do tej optymalizacji frontendu, tutaj na każdy biznes zadziałają odpowiednie dane i statystyki, o których wspomniałeś. Biznes bardzo lubi wykresy, jakieś dane w tabelach i tak dalej. Tutaj bardzo prosta sprawa – wydaje mi się, że dana strona, która reprezentuje jakąś usługę albo dany sklep internetowy ma jakąś konkurencję na rynku. Najczęściej ten biznes wie o tej konkurencji, zna adresy tych stron i tutaj w bardzo prosty sposób możemy za pośrednictwem różnych narzędzi typu PageSpeed insights, Lighthouse i tak dalej stwierdzić, jak szybko ładują się ich strony i chociażby bazując na ich wynikach sprzedażowych, firmowych, to też jesteśmy w stanie takie dane często pozyskać.

Ocenić – jak radzi sobie ten biznes jako nasz konkurent, jak lepiej jest zoptymalizowana ich strona i powiedzmy, że ja jestem wyznawcą takiej zasady, że jeżeli dana strona waszej konkurencji ładuje się w czasie XY, to nasza strona powinna się ładować przynajmniej o 20% szybciej, żebyśmy byli o jeden krok przed konkurencją.

 

Ocenić – jak radzi sobie ten biznes jako nasz konkurent, jak lepiej jest zoptymalizowana ich strona i powiedzmy, że ja jestem wyznawcą takiej zasady, że jeżeli dana strona waszej konkurencji ładuje się w czasie XY, to nasza strona powinna się ładować przynajmniej o 20% szybciej, żebyśmy byli o jeden krok przed konkurencją.

 

To wydaje mi się słusznym podejściem, chociaż z drugiej strony jestem wyznawca takiej zasady, że nawet jeśli będziemy o 20% lepsi od samych siebie na samym początku, to już da nam dużą różnicę. Ale lepiej, jeżeli porównamy się z konkurencją i jeżeli będziemy naprawdę o tych kilka albo jeden krok przed konkurencją to już pozwoli nam dać jakieś lepsze korzyści biznesowe.

To nie jest też taka jednorazowa akcja z tą optymalizacją. Tak, że jednorazowo zoptymalizujemy naszą stronę i to już tak będzie zawsze. Nie – tutaj polecam takie podejście, żeby tą optymalizacją zajmować się od początku do końca, a w momencie, kiedy rzeczywiście osiągnęliśmy ten pułap, czyli jesteśmy o te 20% szybsi od konkurencji, to powinniśmy w sposób ciągły to monitorować. Przede wszystkim siebie, ale potencjalnie też konkurencję.

W momencie, kiedy konkurencja ma jeszcze jakieś lepsze wyniki albo u nas zdarzyła się jakaś regresja względem wypuszczenia jakiegoś nowego feature’a w naszej nowej aplikacji albo na stronie, no to to już powinien być dla nas znak, że powinniśmy and tym tematem się trochę pochylić bardziej.

 

Powiedziałeś, że duzi gracze, duże wyszukiwarki nie od dzisiaj już spoglądają właśnie na optymalizację, na szybkość ładowania, także będą najprawdopodobniej gdzieś punktowały wyżej te strony, które ładują się szybciej, które w efekcie mają lepszy UX dla użytkowników.

Chciałbym cię zapytać o taką inicjatywę Google’a, a także o potencjalny wpływ tej inicjatywy na aktualizację silnika wyszukiwania Google’a planowaną niedługo, mianowicie Web Core Vitals. Czym ona jest, jakie zmiany może wprowadzić?

 

To jest bardzo fajny krok Google’a, który został zrobiony – w zeszłym roku, bodajże, gdzie Google wymyślił sobie, że stworzy wskaźniki internetowe, czyli mówiąc po ludzku kolejne metryki, dzięki którym będziemy w stanie bardziej precyzyjnie określać problemy na stronach związanych z wydajnością. Czyli są to po prostu takie wskaźniki internetowe określające wydajność naszej strony i tym samym poziom UX – to jest ważna sprawa, że te wskaźniki bezpośrednio są zorientowane na ten User Experience. Jakie wrażenia, pozytywne bądź negatywne ma użytkownik podczas korzystania z danej strony.

To są takie 3 najważniejsze wskaźniki, pod którymi kryje się dużo bardzo istotnych kwestii, nie tylko względem jego ładowania, ale też, w jaki sposób użytkownik może tę stronę obsługiwać i bezpośrednio jakie ma też wrażenia. Tutaj te 3 wskaźniki, które chciałbym tutaj wymienić, przede wszystkim largest contentful paint, to jest pierwsza metryka, która mierzy wydajność ładowania. To jest metryka skupiająca się przede wszystkim na tej przestrzeni above the fold, czyli to, co widzimy na samym początku na górze strony, na smartfonie, gdzie mamy viewport i wchodzimy na daną stronę, i to, co jest w tej przestrzeni od razu na samej górze, to to jest właśnie przestrzeń above the fold i mierzy bezpośrednio, jak szybko najważniejsza część contentowa w tej przestrzeni jest ładowana.

To może być obrazek, nagłówek, w zależności do tego, jak rozmiar tego elementu wygląda. Ma takie przełożenie dla użytkownika, że im szybciej ten element jest ładowany i prezentowany dla użytkownika, tym lepiej, gdyż użytkownik będzie to postrzegał, że strona rzeczywiście dobrze i szybko się ładuje.

Kolejna metryka to first input delay, która mierzy bezpośrednio interaktywność.  Tutaj największą zmorą wielu stron są sklepy zewnętrzne JavaScriptowe, które są bardzo kosztowne. JavaScript sam w sobie jest kosztem dla przeglądarki, bo jest to język kompilowany, przeglądarka najpierw musi zrozumieć, chce się przetranspilować ten kod javascriptowy, który my piszemy jako programiści na ten kod zrozumiały przez przeglądarkę. I oprócz tego, jeśli piszemy ten JavaScript w sposób nieumiejętny, no to też ten główny wątek, który jest główną gwiazdą każdej przeglądarki odpowiedzialny za to, co się dzieje w przeglądarce i jak się to wyświetla na stronie. Jeżeli ten główny wątek jest przyblokowany zbyt długo i JavaScript jest najczęściej tym winowajcą, to w tym momencie strona jest nieinteraktywna. Interface całej strony lub aplikacji jest totalnie przyblokowany.

Skrypty zewnętrzne, chociażby Google Ad Manager – tutaj inna kwestia, bo Google Ad Managera to jest jeden skrypt, który umieszczamy w dokumencie HTML, natomiast centrum zarządzania, co się jeszcze może ładować spoczywa bardzo często na marketerach albo osobach po prostu nietechnicznych. Im większa jest ilość skryptów, gdyż znaleźli sobie jakąś javascriptową zabawkę na stronie do instalacji, co potencjalnie mogłoby coś udoskonalić na stronie, a tak naprawdę działa w odwrotnym kierunku, bo blokuje ten główny wątek, strona jest nieinteraktywna, użytkownik musi więcej czasu spędzić na czekaniu, co jest najgorszą sprawą.

Tutaj też ten wątek frameworkowy – frameworki JavaScriptowe, które są bardzo popularne, każdy frontend developer aktualnie z nich korzysta, wszyscy tworzą w Reactcie, w Vue aktualnie i tak dalej, natomiast rzadko kto zdaje sobie sprawę, jak bardzo jest to obciążające dla przeglądarki. Sposób chociażby renderingu tej aplikacji jest niezwykle istotny, natomiast nawet jeżeli zastosujemy server side rendering albo właśnie jakiś serwer side rendering połączony z pre renderingiem, statycznie tutaj też ta hydracja, chociażby będzie wchodziła w grę, gdzie też ta interaktywność – użytkownik będzie musiał dłużej czekać, żeby strona była interaktywna.

Tutaj ten first input delay, wracając do tego wątku core web vitals, first input delay to metryka mierząca bezpośrednio tę interaktywność na stronie – bardzo ważna sprawa. 

I trzeci wskaźnik z tego core web vitals to jest cumulative layout shift. To jest taka metryka, która mierzy wizualną stabilność strony. Mam tu na myśli taką sytuację bardzo częstą w mojej opinii, chociażby na portalach internetowych, polskich – kiedy wchodzimy na stronę danego portalu, czytamy jakiś nagłówek jakiegoś newsa, a tu nagle wszystko nam się przesunęło. Reklamy są tutaj tym głównym powodem, bo one są doładowywane w locie, asynchronicznie i przesuwają nam totalnie content strony. Poniekąd uważam, że jest to robione celowo, bo w momencie, kiedy my już decydujemy się jako użytkownik, aby kliknąć dany link a dosłownie w tym czasie nam się ten content przesunie poprzez reklamę, bardzo często nasz kursor jest na nią nakierowany. Tym samym nie wchodzimy bezpośrednio na tę stronę, do której chcieliśmy, tylko klikamy w reklamę i ktoś na tym zarabia. 

 

I trzeci wskaźnik z tego core web vitals to jest cumulative layout shift. To jest taka metryka, która mierzy wizualną stabilność strony. Mam tu na myśli taką sytuację bardzo częstą w mojej opinii, chociażby na portalach internetowych, polskich – kiedy wchodzimy na stronę danego portalu, czytamy jakiś nagłówek jakiegoś newsa, a tu nagle wszystko nam się przesunęło. Reklamy są tutaj tym głównym powodem, bo one są doładowywane w locie, asynchronicznie i przesuwają nam totalnie content strony.

 

Nie wiem, czy to jest słuszna opinia, nie mniej jednak, cumulative layout shift –  rzeczywiście ta wizualna stabilność jest bardzo istotna i też jest to metryka z tego core web vitals, która zwraca uwagę i co powoduje, że jeżeli zadbamy o to, to w tym momencie jako użytkownik będzie szczęśliwszy, gdyż nic się nie przesunie, te wrażenia z obcowania ze stroną będą naprawdę na wysokim poziomie. 

Core web vitals – bardzo fajna inicjatywa, cieszę się, że Google poszedł w tym kierunku, bo nie jako twórcy internetowi, biznes zostaliśmy zmuszeni, żeby się z tym tematem zapoznać i też ten temat został trochę naznaczony. Wiemy, że taki problem optymalizacji i braku wydajności istnieje i że jest to coś, na czym powinniśmy się pochylić, spędzić czas, bo rzeczywiście jest to coś bardzo istotnego. 

 

Okej, dzięki za to kompleksowe przedstawienie. Powiedz: jak Google ma zamiar z tego korzystać? Jak rozumiem, została jakaś praca włożona w stworzenie tych metryk, w określenie tego i myślisz, że to będzie faktycznie używane przez Google w jakiś sposób, żeby mierzyć strony indeksowane przez boty? 

 

Tak, aktualnie Google już od dawna ma coś w sobie takiego, a tak naprawdę mówimy o przeglądarce Chrome, bo musimy od tego zacząć. Nie wiem, czy słuchacze są świadomi tego, natomiast wielu z nas nieświadomie wysyła dane analityczne z danych stron na serwery Google’a pod kątem wydajności już od dłuższego czasu. Google tworzy coś takiego jak Chrome UX Report, gdzie przede wszystkim te core web vitals ostatnimi czasy też są wysyłane i jakie właśnie czasy lub wartości dla tych metryk są po prostu na danej stronie to wszystko jest sterowane na serwerach Google i na tej podstawie Google będzie najprawdopodobniej – już w maju 2021, więc już niebawem – korzystał pod kątem rankingowania, w sensie, na jakiej pozycji w rankingach wyszukiwania dana strona będzie. Także tutaj dla świata SEO może być to ważny temat zwłaszcza, gdyż być może okaże się, że te strony, które rzeczywiście notują słabe czasy, słabe wyniki zwłaszcza pod kątem core web vitals będą pozycjonowane na niższych pozycjach niż dotychczas. 

Natomiast nikt z nas nie wie jak to będzie w rzeczywistości, czas pokaże. Maj 2021 będzie rzeczywiście takim momentem, że coś ciekawego może się wydarzyć, Google też lubi zaskakiwać. Widzieliśmy to już na przestrzeni poprzednich lat, że rzeczywiście coś, co było zapowiadane, co miało się wydarzyć, a zadziałało trochę inaczej wywróciło ten świat SEO, zwłaszcza na drugą stronę. Nie mniej jednak nawet jeżeli ten jeden z sygnałów dla rankingowania danej strony, czyli core web vitals nie będzie miał aż tak dużego znaczenia, to w dalszym ciągu moim zdaniem jest to temat, nad którym powinniśmy się pochylić, bo nadal daje to wymierne korzyści – właśnie biznesowe, użyteczne, zaufania do marki pod kątem użytkownika dla danej strony, danej marki, także zobaczymy co tu się wydarzy, jeżeli mówimy o Google, natomiast, tak czy siak, jest to temat ważny i zawsze powinniśmy o tym pamiętać. 

 

Okej, czyli jakieś potencjalne trzęsienie ziemi w świecie SEO się szykuje, a skoro tak, to może się to, a wręcz na pewno przełoży się to na jakieś aspekty biznesowe, na możliwość zarabiania przez platformy e-commerce, a na koniec dnia na pieniądze. 

Jak powiedziałeś na początku: temat ważny, trzeba o niego zadbać. Może przejdźmy teraz do odpowiedzi na pytanie: jak się za to zabrać? Od czego zacząć optymalizację webową? 

 

Na samym początku polecam każdemu, żeby po prostu zrozumieć ten temat i jak ten temat jest ważny. Czyli ta świadomość i znaczenie tego tematu jest niezwykle istotna. Tutaj, jeżeli pracujemy w jakimś zespole IT albo nawet jeżeli pracujemy w pojedynkę i obsługujemy jakiegoś klienta, no to warto sobie ustalić swego rodzaju kulturę wydajności. Każdy krok, który będziemy podejmować w projekcie będzie rozpatrywany również pod kątem wydajności. 

To jest też ważna informacja dla klienta, bo pozwoli to nam jako deweloperom albo danej firmie, w której pracujemy być bliżej tego biznesu, z którym współpracujemy. Ten biznes, ten klient rzeczywiście będzie czuł, że my dbamy o biznes, o jego wyniki finansowe i to jest tak naprawdę bardzo ważna sprawa. 

Ta kultura wydajności, tak jak powiedziałem, będzie polegać na tym, że będziemy o tym pamiętać cały czas i zwracać na to uwagę, natomiast też na samym początku projektu ustalimy sobie po prostu, jakie mamy cele do osiągnięcia. 

Tak jak powiedziałem – chociażby postanowienie sobie tego, że powinniśmy być 20% szybszymi od naszej konkurencji jest już swego rodzaju ustanowieniem kultury wydajności i do tego należy skorelować odpowiednie metryki. Tutaj już ta wiedza o tych metrykach, wszystkich zasadach panujących na frontendzie jest bardzo istotna i frontend developerzy już powinni taką wiedzę posiadać i też przekazywać innym i się nią dzielić. 

Także zrozumienie tego tematu, świadomość jest niezwykle istotna na samym początku i każdy ruch, każda decyzja powinna być wykonywana pod tym kątem. Tak jak powiedziałem, frontend developer musi mieć swojego rodzaju wiedzę – o HTML-u, o JavaScriptcie, o CSS, a przede wszystkim na samym początku: jak działa przeglądarka? Gdyż to jest bardzo istotne!

Jeżeli zrozumiemy jak działa przeglądarka, jakie procesy muszą zajść, zanim dana strona zostanie wyrenderowana, to już naprawdę pozwoli nam szybciej ogarnąć ten temat już technicznie, bo sami będziemy wiedzieli, w jaki sposób przeglądarka sobie poradzi z interpretacją danego zasobu albo z wyświetlaniem. Także to już bardzo pomaga. 

 

Jeżeli zrozumiemy jak działa przeglądarka, jakie procesy muszą zajść, zanim dana strona zostanie wyrenderowana, to już naprawdę pozwoli nam szybciej ogarnąć ten temat już technicznie, bo sami będziemy wiedzieli, w jaki sposób przeglądarka sobie poradzi z interpretacją danego zasobu albo z wyświetlaniem.

 

Kolejna sprawa, od czego zacząć to optymalizacje – już stricte technicznie będąc na danej stronie ja zawsze polecam, żeby zawsze skupiać się na tej przestrzeni above the fold, czyli to, co się wyświetla na samej górze. Żeby skupić się na tym, żeby ta przestrzeń wyrenderowana była jak najszybciej, natomiast to, co jest poniżej albo to, czego użytkownik nie widzi od razu, żeby było doładowywane asynchronicznie, czyli w tle po tym, jak właśnie ta górna część strony jest załadowana, albo totalnie na życzenie, czyli kiedy użytkownik coś kliknie i dopiero wtedy się to załaduje, a nie od razu ładować wszystko na raz, nawet to, czego użytkownik też nie widzi albo nigdy nie zobaczy, bo nie zeskroluje do samego dołu strony. To powoduje, że ta strona ładuje się podwójnie wolno, a my powinniśmy się skupić na tej przestrzeni na samej górze.

Tak bym to ujął, od czego zacząć optymalizację. Ta świadomość tematu jest bardzo istotna, ustawienie kultury wydajności, a później skupienie się po prostu na tym, to co się dzieje na samej górze strony, a reszta się już ułoży. 

 

Bardzo fajny przepis na sukces! Tych obszarów jest całkiem sporo, o których powiedziałeś i optymalnie najlepiej by się było zająć nimi wszystkimi, ale wiadomo, jak to w życiu – niestety nie mamy zawsze takiego komfortu. Dlatego chcę zapytać, czy tutaj w tej optymalizacji webowej też zasada Pareto, która mówi, że 20% pracy przekłada się na 80% sukcesu również obowiązuje. Czy jest takie minimum, które najszybciej, najlepiej nam się przełoży na tę optymalizację finalną. Jeśli tak – to jakie to są obszary? 

 

Jak najbardziej ta zasada Pareto istnieje, natomiast nie jesteśmy w stanie podać takiego prostego przepisu albo przykładu takiej zasady, która by się zawsze przełożyła na każdej stronie. Z tego względu, że każda strona jest inna. Na każdej stronie te problemy mogą być różne. Ilość zasobów, typ tych zasobów, to wszystko powoduje, że rzeczywiście miejsce tego problemu może być różne na danej stronie. Nie mniej jednak z moich obserwacji, z mojego doświadczenia wynika, że to właśnie te skrypty zewnętrzne, JavaScript, są tym głównym winowajcą. Tutaj, chociażby jeżeli pomyślimy sobie w ten sposób, że jeżeli JavaScript nawet stanowi 20% wszystkich zasobów oferowanych na stronie, to jeżeli w odpowiedni sposób zadbamy o ich ładowanie, bo już ładowanie na życzenie na przykład na danej stronie, gdzie ta interaktywność będzie na wysokim poziomie i też szybkość ładowania bezpośrednio też, to spowoduje, że strona może nam przyspieszyć nawet o 80%. W takim ujęciu bym to widział, nie mniej jednak te skrypty zewnętrzne są jednym z przykładów. I też na każdej stornie ten przykład może być inny. Na danej stronie, chociażby obrazki mogą być głównym powodem niewydajnego działania. Tutaj wystarczyłoby dobrać odpowiedni rozmiar albo ładować je za pośrednictwem CDN albo w nowoczesnych formatach typu WebP albo AVIF.

Także wachlarz tych tematów i powodów, dla których strona ładuje się wolno jest sporo i nikt nie jest w stanie tak naprawdę podać jakiegoś takiego jednego przykładu, który rzeczywiście polegałby na tym, że ta zasada Pareto miałaby tutaj miejsce, nie mniej jednak czasem ten jeden typ zasobu, nawet w małej ilości, jak chociażby skrypty zewnętrzne mogą powodować, że strona ładuje się wolno i optymalizacja tego jednego elementu spowoduje, że będzie się to wszystko ładowało nawet 80% szybciej. 

 

Rozumiem. Według mnie najprostszy przepis na frontend to jest trochę HTML, trochę CSS, trochę JavaScript – może trochę więcej JavaScript – i różne multimedia. 

Jakie takie najczęstsze techniki optymalizacyjne w każdej z tej kategorii mógłbyś zaproponować? 

 

Jeżeli zaczniemy w takim razie od HTML, to tutaj przede wszystkim prosta i semantyczna struktura tego HTML-a będzie miała największe znaczenie. Mowa tutaj przede wszystkim o tym, żeby unikać jakiegoś wielokrotnego zagnieżdżania, chociażby diva w divie, w divie, w divie i tak dalej, gdyż to spowoduje, że ta struktura DOM chociażby będzie bardzo zaawansowana i tym sposobem też kalkulacja stylów CSS-owych dla tej struktury DOM będzie odpowiednio dłużej zajmowała. 

Nie mniej jednak jest to dość szybki proces dla każdej przeglądarki, więc nie powinniśmy się tym aż tak przejmować, nie mniej jednak im bardziej skomplikowany i zaawansowany nasz HTML jest, im bardziej ta struktura tego DOM-a jest zaawansowana, tym gorzej dla przeglądarki, gdyż będzie musiała optymalnie więcej czasu spędzić na tym, żeby ją zinterpretować. 

Jeżeli mówimy o HTML-u i tej semantycznej strukturze, to oczywiście w tym podcaście skupiamy się przede wszystkim na optymalizacji frontendu pod kątem wydajności, czyli jak szybko się to ładuje. Natomiast nie zapominajmy też w HTML-u, że jeżeli nasza struktura HTML-a będzie semantyczna, to tym sposobem accessibility, ta dostępność dla czytników ekranowych pod kątem osób właśnie niepełnosprawnych też przełoży się na ich komfort działania na danej stronie. Powinniśmy też pamiętać o tym pod tym kątem. 

Także nie tylko wydajność i szybkość ładowania, jeżeli mówimy o HTML-u, ale też ten wątek czytników ekranowych i ogólnie technologii asystujących dla użytkowników niepełnosprawnych. 

Pamiętajmy też, że HTML to jest ten pierwszy punkt, czyli jeżeli wchodzimy na daną stronę i serwer zwraca nam odpowiedź, chociażby ten indeks HTML, to w nim zawarte są odnośniki do innych zasobów. Do CSS-a, JavaScripta, do obrazków i tak dalej i też jak bardzo zminifikujemy sobie ten HTML to też ma dużą rolę, bo serwer będzie szybciej zwracał nam w round tripach, jeśli mówimy o zasadzie 14 kb i jak wygląda ten proces wymiany danych pomiędzy przeglądarką a serwerem, będzie to miało znaczenie jak szybko kolejne requesty będą ładowane. Także, jeżeli mówimy o HTML-u: prosta struktura i niezbyt zaawansowana, pamiętajmy też o tym accesibility. To powinno nam naprawdę wystarczyć, jeżeli mówimy o optymalizacji. 

Kolejna sprawa, jeżeli mówimy o CSS-ie. Tutaj ta struktura DOM-u będzie miała też znaczenie, tak jak powiedziałem, czyli im bardziej będziemy coś zagnieżdżać, tym gorzej, nie mniej jednak z tym CSS-em jest, tak, że to jest szybka operacja dla przeglądarki. Nie skupiałbym się na tym, jak piać ten CSS, ale jak go ładować. Wydaje mi się, że to jest najistotniejszy punkt tej całej historii. 

Znowu: Powinniśmy się przede wszystkim skupić na tej przestrzeni above the fold, czyli chociażby serwować użytkownikowi w przeglądarce tylko ten CSS odpowiedzialny za tę przestrzeń, a całą resztę dla tych elementów poniżej, które nie są widoczne dla użytkownika od razu ładować w jakiś sposób asynchronicznie albo z opóźnieniem, tutaj zastosowanie tego krytycznego CCS-a będzie miało jak najbardziej sens, chociaż też nie w każdym przypadku. Tutaj też jest dużo tzw. „to zależy”, natomiast w wielu przypadkach ten krytyczny CSS naprawdę pomaga. Albo też inna technika ładowania CSS-a do odpowiednich rozdzielczości, tak? Znowu tutaj ta technika mobile first będzie miała duże znaczenie, żebyśmy ładowali tylko CSS-ami pod kątem użytkowników mobilnych, na urządzeniach mobilnych, a całą resztę stylów ładowali również, natomiast z niskim priorytetem. Priorytetyzujemy tylko tę rozdzielczość, na której aktualnie jesteśmy z największym uwzględnieniem urządzeń mobilnych i mobilnego internetu. 

Kolejność ładowania zasobów to też jest coś bardzo istotnego, jeżeli mówimy o CSS, zwłaszcza jeżeli skorelujemy to z JavaScriptem. CSS i JavaScript na siebie mogą oddziaływać i to, w jaki sposób przeglądarka właśnie interpretuje te dwa zasoby i w jak różny sposób może je priorytetyzować, także to jest bardzo istotna sprawa. 

Jeżeli mówimy o JavaScript, to jak już wielokrotnie wspomniałem, chociaż nie chcę być hejterem, bo absolutnie nie jestem – powiedzieliśmy sobie, że JavaScript jest kosztownym zasobem – jest to prawda. Jeżeli korzystamy z jakiegoś frameworka, to korzystajmy z niego, gdyż bardzo często nam to pomaga po prostu dowieźć daną funkcjonalność albo po prostu cały projekt w sposób szybszy, też musimy wyważyć ten temat biznesowy, czas dostarczenia, a też optymalizacyjny. Może czasem warto zastanowić się, czy dany framework taki popularny, w stylu React, Vue, Angular nie może być zastąpiony jakąś lżejszą alternatywą. Jest wiele frameworków, które oferują dokładnie taki sam wachlarz możliwości, ale są napisane w sposób bardziej optymalny i też wagowo, jeżeli mówimy o wagę danego pliku wychodzi to dużo korzystniej. Także taka alternatywa dla tych, nazwijmy to kombajnów javascriptowych może też ma tutaj sens.

Te skrypty zewnętrzne, tak jak powiedziałem – tutaj chociażby jednym z przykładów, bardzo newralgicznych na wielu stronach to jest, chociażby zastosowanie czatu, gdzie po prostu korzystają z jakiegoś rozwiązania szumnie ostatnio nazywanego no-code albo low-code, które są umieszczane na stronie, a co powoduje, że ta interaktywność na stronie, głównie czas ładowania danej strony jest bardzo wysoki i na bardzo złym poziomie.

Sam na przykład jestem też autorem takiego rozwiązania, gdzie te skrypty jesteśmy w stanie załadować z opóźnieniem. To jest technika, która została przeze mnie zaadaptowana z rozwiązania Gatsby, gdzie ją zauważyłem. Polega to na tym, że dany skrypt będzie załadowany dopiero w tym momencie, kiedy użytkownik wykona jakąś interakcję na stronie. Czyli wchodzimy na daną stronę, skupiamy się na tym, żeby ta przestrzeń above the fold była jak najwcześniej wyrenderowana, dopiero kiedy zaczniemy lekko scrollować albo coś klikniemy, to dopiero wtedy załadujemy ten skrypt zewnętrzny, chociażby właśnie ten czat. Czyli minimalizujemy czas potrzebny do załadowania, wyświetlenia czegoś istotnego dla użytkownika, czyli przestrzeni above the fold, a doładowujemy te dodatkowe rzeczy, jak chociażby czat dopiero w tym momencie, kiedy użytkownik zescrolluje.

 

Sam na przykład jestem też autorem takiego rozwiązania, gdzie te skrypty jesteśmy w stanie załadować z opóźnieniem. To jest technika, która została przeze mnie zaadaptowana z rozwiązania Gatsby, gdzie ją zauważyłem. Polega to na tym, że dany skrypt będzie załadowany dopiero w tym momencie, kiedy użytkownik wykona jakąś interakcję na stronie. 

 

Inna technika to jest, chociażby ładowanie na żądanie, gdzie stworzymy sobie tzw. fake button tego czatu i dopiero po kliknięciu – czyli na tej interakcji, dopiero wtedy załadujemy ten skrypt. Tym sposobem użytkownik ma nadal tę funkcjonalność, która też jest z punktu biznesowego bardzo istotna, gdyż przyspiesza komunikację między biznesem a użytkownikiem, czyli ten czat, natomiast ładujemy to wtedy, kiedy użytkownik rzeczywiście chce.

Jeżeli mówimy, chociażby o multimediach, jako kolejnej kategorii plików, które wyświetlamy i ładujemy na stronach, to tutaj, jeżeli mówimy o obrazkach, no to przede wszystkim radziłbym stosować te nowoczesne formaty obrazków, czyli typu właśnie WebP albo AVIF, natomiast zdaje sobie sprawę, że może być to trochę trudne do implementacji, że będziemy musieli trochę czasu spędzić nad tym, żeby w odpowiedni sposób zaimplementować, a jestem wielkim fanem takiego szybkiego podejścia. Żeby to zrobić jak najniższym kosztem, a żeby dało nam maksymalnie dużo efektów. Tutaj, chociażby zastosowanie takich gotowych procesorów obrazkowych w locie, gdzie też one pełnią swego rodzaju funkcjonalność CDN-a, gdzie dany obrazek dostępny na naszym, fizycznym serwerze, pod jakimś fizycznym adresem jesteśmy w stanie serwować na przestrzeni takiego proxy zewnętrzne usługi, która też ma w sobie właśnie cechy CDN-a, które będzie w stanie nam wyświetlać, ładować te obrazy w nowoczesnych formach i bardzo często też mniejsze rozmiarowo. Jesteśmy w stanie manipulować tymi obrazkami w locie.

Bardzo fajnie się to sprawdza – stosujemy w naszej agencji wielokrotnie, na wielu projektach i naprawdę daje to wymierne korzyści i przede wszystkim ten czas integracji, wdrożenia, nawet na stronach typu WordPress jest to możliwe do zrobienia w bardzo szybki sposób i da nam naprawdę dużo korzyści.

Fajna sprawa z tymi obrazkami, wideo – ładowanie ich na żądanie. Nie wiem czy zauważyłeś taką ogólną zasadę, o której mówię, żebyśmy skupili się na tym, co jest najważniejsze na samej górze, a całą resztę doładowywali w locie na żądanie, kiedy jest to potrzebne. Technika lazy loading do obrazków, do wideo, do animacji, które mają być wyświetlone poniżej, to jest bardzo fajna technika, która pozwoli nam zaoszczędzić czas potrzebny do wyrenderowania tej najważniejszej części strony, czyli na samej górze, a ładować kolejne rzeczy, kolejne rzeczy, kolejne assety w tym momencie, kiedy one rzeczywiście są potrzebne.

Czyli ten lazy loading, ładowanie na żądanie to jest kolejna, bardzo ważna sprawa. Tych technik jest ma, a jednak są proste do wdrożenia – wystarczy je zrozumieć i mieć wiedzę, jak to robić, żeby w każdej z tych kategorii osiągnąć jak najlepszy czas ładowania danego zasobu. Tak bym powiedział, jeśli mówimy o optymalizacji i kategoriach poszczególnych typów plików.

 

Jasne! Jak opowiadałeś o tych różnych technikach, to sobie pomyślałem, że to zajmuje mnóstwo czasu! Czy nie dałoby się tak zrobić, że zamykamy się raz w roku, na początku stycznia, mówimy „drogi biznesie, teraz nie będziemy wam dowozić feature’ów, bo my robimy optymalizację”. Siadamy raz, rozwiązujemy problem, mamy cały rok z głowy.

Czy to w ogóle ma rację bytu czy takie podejście się po prostu nie sprawdzi?

 

Absolutnie nie. W tym momencie, kiedy biznes widzi, że strona jest wolno ładująca się i dopiero wtedy chce poświęcić raz w roku czas na optymalizację, w tym momencie rodzą się największe problemy. Dana strona, która jest już skonstruowana w sposób nieodpowiedni od samego początku, gdzie doładowywana jest masa różnych assetów, różnych zasobów, w tym momencie jest to dość trudne do odkręcenia w wielu przypadkach. Nie mówię, że to nie jest możliwe, natomiast będzie to trudne do osiągnięcia i statystycznie zajmie nam więcej czasu, aniżeli jeśli poświęcilibyśmy nad tym tematem trochę czasu na samym początku przed stworzeniem projektu i kierowali się swego rodzaju zasadami podczas tworzenia kolejnych feature’ów.

W tym momencie rzeczywiście, jeżeli będziemy robić to od samego początku z odpowiednią wiedzą i z ustanowieniem sobie swego rodzaju kultury wydajności, będziemy w stanie dostarczać te funkcjonalności w sposób szybki na odpowiednim poziomie, jeżeli mówimy o tej wydajności. To nie jest raczej jednorazowa akcja, którą powinniśmy się na samym końcu tworzenia projektu albo dopiero wtedy, kiedy zorientujemy się, że nasza storna jest wolno ładująca się, gdyż statystycznie to zajmie dużo czasu.

Natomiast powiedziałeś, że te techniki, o których opowiadam, że one zajmują dużo czasu, że czas wdrożenia odpowiednich technik optymalizacyjnych jest czasochłonny i że to dla biznesu może być problem. Nie zgodzę się z tą tezą – frontend developer i zespół, który zajmuje się dostarczaniem jakiegoś projektu webowego mając odpowiednią wiedzę jest w stanie zrobić to szybko.

To nie są bardzo trudne rzeczy, które powodują, że po prostu to będzie dużo zajmowało – absolutnie nie. To są proste triki. Chodzi o to, żeby zrozumieć, jak przeglądarka działa i kierować się tą zasadą. W tym momencie naprawdę w sposób szybki jesteśmy w stanie daną stronę dostarczyć. Natomiast jeżeli będziemy podczas tego procesu tworzenia danej strony zapominać o tych wszystkich kwestiach, to w tym momencie na samym końcu skumuluje się nam ta ilość ogólna wszystkich zasobów połączonych w odpowiedni bądź nieodpowiedni sposób, co spowoduje, że odkręcenie tego wszystkiego zajmie nam naprawdę dużo więcej czasu. Także polecałbym, żeby tę optymalizacją zajmować się cały czas, nie mówię, żeby spędzać nad tym wieków, tylko żeby rzeczywiście pamiętać o tym od samego początku już również z takimi strategicznymi założeniami danego projektu na samym początku, żeby potem tym się kierować i tym sposobem naprawdę nasz projekt będzie ładował się wydajnie, dostarczał pozytywnych emocji użytkownikom.

 

Pewnie, o to chodzi! Czyli optymalizacja na poziomie procesu, pewnego strategicznego podejścia, na poziomie planowania. Natomiast zastanawiam się jak to przełożyć na taką codzienną pracę developera. Czy mimo wszystko on to powinien wplatać czy powinien myśleć od początku o już optymalnym rozwiązaniu, czy raczej po zamknięciu jakiegoś feature’a, mniejszej funkcjonalności próbować to optymalizować? Jaka strategia według ciebie jest najlepsza?

 

Wydaje mi się, że powinniśmy już od samego początku jako frontend developerzy pamiętać o tych technikach optymalizacyjnych, nie mniej jednak też pracuję w branży, też jestem frontend developerem od wielu lat i zdaję sobie sprawę, że czasem może być to nie do końca możliwe do zrobienia na takim poziomie, na jakim byśmy oczekiwali. W sensie że oczekiwalibyśmy, żeby poświęcić na to więcej czasu, a czasami właśnie czas dowiezienia danego projektu nas goni i to może nam powodować swego rodzaju blokadę, dlatego radziłbym, żeby kierować się kulturą wydajności, natomiast biznes i dostarczenie danego projektu również jest ważne. Mam tu na myśli to, żeby unikać tej tzw. premature optimization, czyli żeby te techniki optymalizacyjne, ogólnie ta optymalizacja nas jakoś nie przyblokowała totalnie, jeżeli mówimy o frontend developerach. Żebyśmy po prostu tylko na tym temacie się zafiksowali i nie potrafili napisać ani jednej linijki kodu w sposób szybki, gdyż cały czas tylko o tej optymalizacji myślimy.

Absolutnie nie! Nie mniej, jednak jeżeli poznamy te zależności, jak działa przeglądarka i odpowiednie techniki optymalizacyjne, to będziemy w stanie już pisać ten kod automatycznie, z głowy po prostu, kierując się tymi odpowiednimi zasadami, nie będzie to miało żadnego znaczenia.

Czasem może zdarzyć się tak, że ten czas dostarczenia jest ważniejszy dla biznesu, rzeczywiście i w tym momencie będziemy zmuszeni poniekąd o opuszczenie jakiejś techniki albo zastosowanie jakiejś techniki optymalizacyjnej, ale warto w tym momencie mieć swego rodzaju furtkę w głowie, jak to powinniśmy dostarczyć, chociażby w drugiej fazie projektu.

Cały czas jestem zdania, że mając tę odpowiednią wiedzę w sposób łatwy i szybki jesteśmy w stanie dostarczyć dany projekt od samego początku już w odpowiedni sposób.

Także codzienna praca developera powinna się nad tym tematem skupiać, ale nie w taki sposób, żeby to przeszkadzało w dostarczeniu danego projektu. Jeżeli czasami nie jesteśmy w stanie czegoś zaplanować od samego początku, dokonać tego w łatwy sposób, gdyż mamy jakiś JavaScript o bardzo zaawansowanej logice, to wystarczy po prostu to, co jest ważne, a biznes jest najważniejszy – a po prostu zróbmy sobie taki plan w głowie, jak to zrobić w drugiej fazie, żebyśmy dokonali tego po prostu w późniejszym czasie.

 

Mówi się, że to, na co zwracamy uwagę, to co mierzymy to rośnie. Co według ciebie warto mierzyć, jeśli chodzi o optymalizację frontendu i też jak do tego podejść pragmatycznie, praktycznie – czy żeby faktycznie mierzyć to, co nam się może przydać, a nie wszystko, co się da?

 

Wydaje mi się, że na samym początku warto zwrócić uwagę na metrykę typu time to first byte, która związana jest bezpośrednio z serwerem, natomiast zwracam uwagę, że jej nazwa nie do końca mówi nam, że coś jest z serwerem nie tak – to bardzo często jest coś po stronie backendowej, w logice naszej aplikacji coś związanego z zapytaniem do bazy, co z kolei może przekładać się ogólnie na wykorzystanie zasobów danego serwera i przekładać się też na czas ładowania innych zasobów, statycznych – czyli jakiś JavaScript, jakiś CSS, jakieś obrazki.

Także ten backend też jest tutaj istotną sprawą i ta metryka zawsze będzie moim zdaniem czymś ważnym do wzięcia pod uwagę na samym początku, żeby też ten serwer i jak bardzo jest on obciążony sprawdzić, żeby to też nie przekładało się w sposób negatywny na inne metryki.

Kolejny zestaw metryk to jest właśnie core web vitals, gdzie usprawniając i skupiając się tak naprawdę tylko na tych metrykach jesteśmy w stanie tak naprawdę aktualnie uzyskać naprawdę wydajną stronę – usprawniajac trzy metryki i ich wartości, mamy automatycznie usprawniony również szereg innych metryk, które też są dostępne na rynku.

Także te core web vitals są bardzo fajną inicjatywą i pozwolą nam uczynić naszą stronę szybką i wydajną, tylko skupiać się na tym. Także to są takie podstawowe właśnie kwestie, na które zwrócimy uwagę i które zawsze, w każdym projekcie powinny być brane pod uwagę, żeby strona była wydajna.

 

Okej. Na koniec zerknijmy sobie do tool boxa, czyli narzędziownika. Co byś polecił w kontekście narzędzi, z jakich możemy skorzystać myśląc o optymalizacji frontendu. Myślę tu i o monitorowaniu, bo powiedziałeś, że te metryki są istotne w takiej pracy developerskiej, która ma polepszać status, stan serwisu pod kątem optymalizacji?

 

Wydaje mi się, że takim niezbędnikiem każdego frontend developera w dzisiejszych czasach powinny być przede wszystkim DevToolsy, chociażby w przeglądarce Chrome i zakładka „performance”, dzięki której jesteśmy w stanie nagrać ten load time performance, czyli jak szybko ładują się dane zasoby, w jakiej kolejności, ale też na tzw. run-time performance, czyli kiedy strona jest już de facto załadowana, a kiedy wykonujemy jakąś interakcję na stronie – coś klikamy, skrolujemy i to nam pięknie stworzy taki wykres jak ta strona się zachowuje w przeglądarce i czy nie powoduje, chociażby wykorzystania zbyt dużej ilości zasobów naszego urządzenia. 

Ta zakładka performance, żeby ją zrozumieć – ja wiem, że dla wielu front end developerów, w tym mnie na samym początku przeraża ten ogrom danych, wszystkich tych wykresów, jak to wszystko zrozumieć i tak dalej, natomiast nie jest to nic strasznego, kiedy podejdziemy do tego w spokojny sposób i po prostu dowiemy się, jak interpretować dane metryki, gdzie szukać informacji, gdyż też mnogość wszystkich opcji w tym narzędziu jest bardzo, bardzo dużo, daje jednak naprawdę duży pogląd na to, co się dzieje na naszej stronie i gdzie szukać potencjalnie wąskich gardeł w wydajności naszej strony. Także DevTools i zakładka „performance” jest takim absolutnym must have podczas już samego developementu danej strony.

Kolejnymi narzędziami, które bym polecał, to przede wszystkim pagespeed insights, które też obecnie bazuje już na lighthousie, czyli drugim narzędziu, które też właśnie zwracam uwagę na odpowiednie metryki, ich czasy, ich wartości i też podpowiada nam de facto co powinniśmy zrobić, gdzie potencjalnie na naszej stronie jest problem i na czym powinniśmy się skupić, żeby daną stronę zoptymalizować.

Kolejna sprawa to web page test –  bardzo fajne narzędzie, dzięki któremu również jesteśmy w stanie przetestować naszą stronę pod kątem wydajności z różnych też zakątków świata – możemy zaajmulować urządzenie mobilne i uzyskać połączenie z Londynu albo ze Stanów Zjednoczonych, zwłaszcza kiedy tworzymy jakąś stronę, która ma być dostępna globalnie. 

Da nam to naprawdę szereg fajnych informacji, nagra nam też ten performance w postaci takiego video, gdzie widzimy poszczególne klatki, jak dana strona się ładuje, nie mniej jednak te wszystkie opcje, te narzędzia, o których właśnie opowiedziałem bazują na testach syntetycznych. Czyli to jest jakaś emulacja po prostu połączenia internetowego, emulacja danego urządzenia w takich warunkach, które nie do końca czasem mogą odzwierciedlać to, jak rzeczywiście dany użytkownik obsługuje daną stronę.

Mam tutaj na myśli, że powinniśmy oprócz tych testów syntetycznych, które dają bardzo ważne i cenne informacje, które zawsze będą pomocne, natomiast taką kolejną grupą testów, w które radziłbym każdemu twórcy internetowemu się zaopatrzyć, to po prostu pozyskali informacje od naszych rzeczywistych użytkowników, czyli po prostu chodzi o tzw. RUM, czyli real user monitoring, gdzie po prostu, jeżeli zainstalujemy dany skrypt, jest bardzo fajne narzędzie jak SpeedCurve, gdzie będzie nam pozyskiwało informacje na temat wydajności frontendu od naszych rzeczywistych użytkowników będziemy w stanie stwierdzić, jak rzeczywiście ta strona się ładuje i zachowuje dla rzeczywistych ludzi. 

Nie testy syntetyczne, czyli jakaś emulacja połączenia albo jakiegoś urządzenia, tylko dla danego użytkownika w sposób rzeczywisty. I tutaj ten SpeedCurve jest bardzo fajnym narzędziem. Niestety jest płatne, ale jeżeli nasza strona rzeczywiście jest zorientowana na tę wydajność, optymalizację, to polecam zainwestować te kilka groszy, żeby to narzędzie zaistniało w naszych projektach.

I jak powiedziałem – przeglądarka Chrome też będzie wysyłała informacje o wydajności frontendu na ich serwery i ten chrome user experience report będzie tutaj tworzony i dane sparowane.

Google Analytics też jest narzędziem, które się fajnie sprawdzi – tam też mamy zakładki, gdzie mamy informacje w jak szybki sposób strona się ładowała dla użytkowników rzeczywistych, którzy odwiedzili naszą stronę. To jest też bardzo fajna kwestia.

Zwracam też uwagę, że te metryki, które mamy do dyspozycji, te narzędzia, które mamy do dyspozycji bazują na metrykach, które są istotne, ważne i reprezentują odpowiednie czasy i wartości, ale nic nie stoi na przeszkodzie, żebyśmy tworzyli też swoje własne metryki. Też mamy ku temu możliwości aktualnie stosując odpowiedni user timing API, które są dostępne natywnie z poziomu przeglądarki, jesteśmy w stanie mierzyć czas, chociażby jak szybko jest załadowany jakiś obrazek, na którym nam najbardziej zależy. 

I tego typu czas jesteśmy w stanie w tym momencie wysyłać, chociażby do Google Analytics albo do wspomnianego już wcześniej Speed Curve’a, gdzie będą tworzone po prostu customowe metryki dla danego projektu, dla danych elementów, które są już w sposób bardzo istotny dla nas, dla naszej strony pod kątem rzeczywistych użytkowników.

Także taki tool box bym widział, nie mniej jednak podczas developmentu DevToolsy i ta zakładka „performance” wydaje mi się najważniejszym narzędziem.

 

Super, Bartku! Wielkie dzięki za ciekawą rozmowę. Dzięki za naświetlenie tematu optymalizacji i właśnie frontendu aplikacji webowej. Muszę przyznać, że sam się też sporo dowiedziałem, także dziękuję za ten poświęcony czas!

Powiedz proszę, gdzie można cię znaleźć w internecie, jak można trafić na e-materiały, którymi się dzielisz?

 

Przede wszystkim aktywnie działam na Instagramie, można mnie znaleźć wpisując Web Dev Insider w wyszukiwarkę Instagrama – to medium jest moim ulubionym narzędziem, na którym działam dośc prężnie, przede wszystkim w InstaStories. Często wchodzę w interakcję z użytkownikami, którzy po prostu piszą do mnie na podstawie mojego InstaStory i też z tego tytułu wyciągane są różne, ciekawe historie, tworzone są po prostu kolejne i kolejne fajne materiały, także Instagram jest przede wszystkim takim medium, na którym działam. Jest też strona webdevinsider.pl/, na której znajdziecie blog – choć Instagram jest głównym medium, natomiast na webdevinsider.pl/ możecie też zapisac się do mojego newslettera, gdzie w cykliczny sposób wysyłam interesujące materiały i w taki sposób można mnie tam spotkać.

Jestem też twórca kursu online Zoptymalizowany Frontend, gdzies tam też na webdevinsider.pl/możecie zobaczyć. Ale przede wszystkim Instagram – to jest miejsce, gdzie dużo produkuję i fajna interakcja z widzami jest tworzona.

 

Świetnie, oczywiście zapraszamy – wszystkie linki będą w notatce do odcinka. Z mojej strony jeszcze raz bardzo dziękuję. Do usłyszenia. Cześć!

 

Dziękuję, cześć!

 

To na tyle z tego, co przygotowałem dla Ciebie na dzisiaj. Jako użytkownicy serwisów internetowych jesteśmy coraz bardziej wymagający, jeśli chodzi o szybkość ładowania tych stron. Również największe wyszukiwarki świata zaczęły zwracać na ten czynnik uwagę. Warto zatem, zajmując się frontendem aplikacji zadbać o jego optymalizację pod kątem wydajności.

Jeśli ten odcinek był dla ciebie interesujący i przydatny, odwdzięcz się proszę recenzją, oceną lub komentarzem w social mediach. 

Jeśli masz jakieś pytania, pisz śmiało na krzysztof@porozmawiajmyoit.pl

Zapraszam też do moich mediów społecznościowych.

Nazywam się Krzysztof Kempiński, a to był odcinek podcastu Porozmawiajmy o IT o optymalizacji frontendu.

Zapraszam do kolejnego odcinka już za tydzień! 

Cześć!

 

+ Pokaż całą transkrypcję
– Schowaj transkrypcję
Tags:
mm
Krzysztof Kempiński
krzysztof@porozmawiajmyoit.pl

Jestem ekspertem w branży IT, w której działam od 2005 roku. Zawodowo zajmuję się web-developmentem i zarządzaniem działami IT. Dodatkowo prowadzę podcast, kanał na YouTube i blog programistyczny. Moją misją jest inspirowanie ludzi do poszerzania swoich horyzontów poprzez publikowanie wywiadów o trendach, technologiach i zjawiskach występujących w IT.