Optymalizacja front-endu aplikacji webowych

Krzysztof Kempiński
Feb 23 · 16 min read

W ramach podcastu “Porozmawiajmy o IT” miałem okazję porozmawiać z Bartkiem Misiem o optymalizacji front-endu aplikacji webowych.

Posłuchaj naszej rozmowy w wersji audio 🎧 👇

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 , 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 , 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ą.

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ą.

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.

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.

👉 Czytaj dalej na: https://porozmawiajmyoit.pl/poit-104-optymalizacja-front-endu/

kkempin’s dev blog

Dev and life blog.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store