23 sierpnia 2020 67:16 Odcinek 020

PWA – przyszłość e-Commerce czy chwilowy trend? – Maciej Harbuz

Branża IT bardzo polubiła różne 3-literowe skróty. Jednym z najnowszych jest wdrożenie PWA, które stało się nieodłącznym elementem spotkań dotyczących wdrożeń sklepów internetowych. Co w takim razie oznacza PWA i czy ten trend zostanie z nami na dłużej?

Według mojego gościa – zdecydowanie tak. A biorąc pod uwagę korzyści dla e-Commerce, jest to zdecydowanie trend, na który warto zwrócić szczególną uwagę przy podejmowaniu decyzji o wdrożeniu nowego sklepu internetowego lub większej rewolucji w istniejącej platformie. Jak wykorzystać PWA do zwiększania sprzedaży w e-Commerce? Posłuchaj wskazówek Maćka Harbuza.

Listen to „020 – PWA – przyszłość e-Commerce czy chwilowy trend? – Maciej Harbuz” on Spreaker.

Dodatkowe materiały

Jeśli chcesz zgłębić temat PWA, szczególnie warto zajrzeć tutaj:

Zestaw założeń, które musi spełniać Twój sklep, żebyś mógł mówić o pełnym wdrożeniu PWA
https://web.dev/lighthouse-pwa/
Case studies różnych wdrożeń PWA, o których rozmawialiśmy w odcinku. Możesz zainspirować się kilkunastoma wdrożeniami, poszukać to najbliżej Twojego biznesu i zobaczyć, jak to wyglądało w praktyce
https://developers.google.com/web/showcase
Tutaj trochę „mięcha” w postaci ciekawych statystyk
https://www.pwastats.com/
https://www.lambdatest.com/blog/wp-content/uploads/2018/04/PWA-1.jpg
https://smashingideas.com/pwa-statistics/
Możesz przeczytać też opracowanie „Comparing Progressive Web Applications with Native Android Applications” (uwaga: nastaw się na wiedzę naukową)
https://www.diva-portal.org/smash/get/diva2:1105475/FULLTEXT01.pdf
Maciej pisuje też czasami na blogu X-Coding IT Studio
https://x-coding.pl/blog/

Gdybyś chciał porozmawiać z Maciejem o PWA, zajrzyj na jego profil LinkedIn:

https://www.linkedin.com/in/maciej-harbuz/

Jedna z rzeczy, za które lubię e-Commerce, to zmiany. Co chwilę pojawia się coś nowego, czasami zostaje na dłużej, a czasami idzie w zapomnienie.

Od jakiegoś czasu takim trendem jest zdecydowanie PWA. Muszę przyznać, że naprawdę rzadko zdarza mi się rozmawiać z firmami, które, chociażby z ciekawości nie zapytały o wdrożenie PWA w swoich sklepach. To jest jednak tylko jedna strona medalu. Druga to ta stosunkowo mała świadomość, co to właściwie jest PWA. I to jest naprawdę wyczuwalne w rozmowie.

Dlatego w tym odcinku znajdziesz:

proste wyjaśnienie czym właściwie jest PWA,
co oznacza dla sklepu internetowego,
czy warto być zgodnym z wytycznymi,
kiedy w ogóle najlepiej myśleć o takim wdrożeniu.

No a przy okazji lepiej ocenisz, czy w ogóle to jest trend, za którym powinieneś się oglądać.

Trochę o moim dzisiejszym gościu. O sobie mówi, że rzadko odchodzi od komputera i po pracy zajmuje się uczeniem maszynowym i sztuczną inteligencją. Jak odpoczywa, to raczej aktywnie w górach albo na siłowni, ewentualnie na spokojnie przy szachach, do których wrócił po 20 latach przerwy. Ale ja wiem o nim o wiele więcej, bo minęło już prawie 10 lat, odkąd założyliśmy X-Coding IT Studio, a przecież poznaliśmy się jeszcze wcześniej na pierwszym roku studiów. Z tych wszystkich przygód, sukcesów, fakapów i wszystkich innych rzeczy, które przeżyliśmy przez cały ten czas, uzbierałoby się kilka naprawdę porządnych żyć. Zresztą na pewno o tym wszystkim jeszcze kiedyś też nagram kilka odcinków. Dzisiaj niech za rekomendację posłuży Ci jedna rzecz – mogę śmiało powiedzieć, że gdyby nie mój gość, na sto procent dzisiaj nie byłoby X-Coding.

Dlatego z nieskrywaną przyjemnością zapraszam Cię do wysłuchania mojej rozmowy z Maćkiem Harbuzem o tym, czy PWA będzie przyszłością w e-Commerce.

Cześć Maćku.

Cześć.

Dostałeś prawdopodobnie najdłuższe intro w historii podcastu i nie sądzę, żeby mi się dłuższe intro kiedyś udało na czyjś temat powiedzieć. Ale żeby słuchacze dowiedzieli się czegoś z twoich ust, to powiedz mi, czym zajmujesz się na co dzień w X-Coding IT Studio?

Jestem współwłaścicielem, więc tych różnych tematów na co dzień jest dużo. Natomiast głównie jestem odpowiedzialny za to, żeby projekty naszych klientów miały się dobrze, żeby wszystko przebiegało w dobry sposób. Oprócz tego jestem dyrektorem technologicznym i aktualnie jeszcze liderem project managerów. Więc na pewno blisko projektów, co pewnie się dzisiaj jakoś przyda.

Czyli taki one-man-army po stronie dowożenia projektów e-Commerce. Tak to można mniej więcej określić?

No już na pewno w pojedynkę nic nie robimy, ale tak, myślę, że większość takich tematów jest mi znanych.

Twoja wiedza na pewno się dzisiaj przyda, bo zaprosiłem Cię do dzisiejszego odcinka z tego powodu, że… uważam, że świat i rynek potrzebuje pomocy – z tego powodu, że jakiś czas temu przez rynek przeszła nowa fala. Ta fala nazywała się PWA i wszystko zwiastuje, że zostanie z nami na trochę dłużej. A przynajmniej utrzymała się do teraz, więc to jest temat, o którym warto rozmawiać. Natomiast samo PWA przez to, że jest stosunkowo świeżym tematem, budzi jeszcze wiele wątpliwości. Wiem, że nie wszyscy do końca rozumieją, co to jest. Pojawiają się takie miksowania PWA z RWD. Jedni mówią na to „technologia”, inni „podejście”. Jest dużo mitów, które, mam nadzieję, dzisiaj trochę rozkodujemy, a trochę obalimy i zostawimy słuchaczy z taką pigułką informacyjną – co to jest, do czego służy i czy to w ogóle jest fajne i na jak długo z nami zostanie. Z doświadczenia wiem, że taka wiedza przeciętnego użytkownika na temat PWA skończy się na tym, że potrafi rozwinąć skrót jako Progressive Web Apps i to jest właściwie tyle. Zacznijmy więc od podstawowych rzeczy. Jak ty opisałbyś, co to właściwie jest PWA?

Myślę, że trzeba by było zacząć od samego źródła. Przede wszystkim to pojęcie wprowadziło na rynek Google. To ono zapoczątkowało to podejście i rozwija je dalej. W początkowym okresie były inne warunki do tego, żeby nazwać jakąś aplikację zgodną z PWA albo niezgodną.

PWA to jest taki zestaw warunków, które powinna strona internetowa czy aplikacja webowa spełniać, żeby można było ją nazwać PWA. A to, po co ją nazywamy Progressive Web App, skupia się wokół tego, jak użytkownicy (i to głównie użytkownicy urządzeń mobilnych) będą miło wspominać doświadczenia, jakie mieli z naszą stroną internetową, sklepem czy po prostu jakąś aplikacją webową.

Dlatego najprościej rzecz ujmując, jest to raczej zestaw warunków, które pozwolą na to, żeby użytkownik przede wszystkim urządzenia mobilnego czuł się dobrze na naszej stronie.

Czyli to tak naprawdę niekoniecznie ma jakiś związek z technologią, tak? To jest bardziej podejście, wspomniałeś też o warunkach. I tych warunków i podejścia raczej powinniśmy się trzymać? To jest bardziej ideowe zagadnienie niż typowo techniczne czy technologiczne?

Tak, o ile uznajemy, że Google, powiedzmy, poświęcił na to dużo zasobów i bardzo mocno najpierw przemyślał temat, stwarzając listę tych warunków, no to powinniśmy się tego po prostu trzymać. Nie ma to związku bezpośrednio jakby z technologią, no ale jednak rozwój technologii sprzyja temu, żeby użytkownikowi coraz lepiej używało się tej naszej aplikacji.

To do mnie przemawia, natomiast chciałbym, żebyśmy jeszcze odmienili trochę PWA przez przypadki. Jednym z takich problemów, które spotykam, jest to, że nie do końca wiadomo, jak o tym PWA mówić. Już ustaliliśmy, że to jest podejście. Jak połączyć w zdaniu sklep internetowy i PWA? Spotkałem się, że sklep jest napisany w PWA, że sklep ma PWA, jest zrobiony na PWA. Jak ty byś te zwroty ze sobą połączył, żeby to faktycznie logicznie miało sens?

Myślę, że najbardziej poprawnie będzie wtedy, kiedy powiemy, że nasz sklep internetowy spełnia wszystkie wytyczne, jakie stawia Google, żeby coś nazwać PWA. To by było najbardziej rozsądne i unikamy takich niedopowiedzeń, że mamy coś tam w RWD, czy nasz sklep jest w PWA, czy coś takiego.

Po prostu spełniamy warunki.

Fajnie, że powiedziałeś o RWD, bo to też jest coś, co mi trochę chodzi po głowie. Ja z resztą sam się trochę gubię trochę w tej terminologii. Pewnie trochę dlatego, że z zewnątrz spływają do mnie różne określenie i mi się to też lubi pomiksować. Powiedziałeś o RWD i o PWA – jaka jest tak naprawdę zależność pomiędzy jednym a drugim? Już pomijając nomenklaturę, którą ustaliliśmy chwilę wcześniej, to słyszałem już takie zdanie, że sklep powinien mieć PWA i RWD. Z tego, co mówiłeś o wygodzie użytkowania, brzmi trochę jak „masło maślane”, albo że jedno zawiera się w drugim. Gdybyś mógł gdzieś ten znak porównania postawić – jaka jest współzależność między PWA a RWD?

Oczywiście, jeżeli mówimy o tym, żeby użytkownikowi się przyjemnie korzystało z naszej aplikacji na telefonie (ogólnie na urządzeniu mobilnym), to nie ma siły, żeby ta strona nie była w RWD. Także jednym z podpunktów, jakie Google stawia, jest na pewno zgodność na różnych ekranach, czyli czy layout dobrze się wyświetla na różnego rodzaju urządzeniach, czy to na dekstopie, czy urządzeniu mobilnym.

Także, jeśli nie jesteśmy RWD, to nie będziemy PWA. Ale to będzie nasz najmniejszy problem, bo nie jesteśmy wtedy przygotowani na obecny rynek. PWA jest oczywiście dużo większym pojęciem. Nie można być PWA, jeśli nie jest się RWD, ale można być RWD, ale w ogóle nie być PWA.

Takie może trochę inne pytanie, bo mówimy o RWD i to polega na tym, że strona się skaluje. Ale gdyby to była strona tylko dostosowana do urządzeń mobilnych, czyli strona, która się nie skaluje. Jest dopasowana do małych urządzeń, ale na dużym ekranie wygląda tak jak na małym, tylko szerzej. Czy to też spełnia warunki PWA? Mamy stronę tylko mobilną, nie skaluje się do wersji szerokiej, czyli nie do końca spełnia warunki RWD, bo po prostu wygląda jak duże przybliżenie. Czy taka strona ma szansę spełnić warunki na bycie PWA?

Myślę, że takich skrajnych przypadków to raczej pewnie nie będzie, bo po prostu dzisiejsza technologia umożliwia napisanie od razu tego dobrze, żeby jakoś tam się strona zeskalowała. Tym bardziej że nawet w samych interfejsach Google widzimy teraz, że to dobrze wygląda na telefonie i dobrze, chociaż może dla niektórych trochę dziwnie, wygląda na dużych ekranach, bo wszystkie te ikonki są spore.

Widać, że to jest robione mobile-first i po prostu przeportowane, jakoś ten layout się układa tak, że na dekstopie wygląda spoko, ale widać, że to bardziej jest robione pod kątem urządzeń mobilnych. To widać na przykład w Google Analytcics, Google Ads, czyli takich systemach, które w większości są używane nawet na desktopie.

Także, jeżeli mówimy, że niekoniecznie nasza aplikacja doskalowuje się do takich większych urządzeń, to nie znaczy, że na nich nie działa i nie znaczy, że na nich źle się tego używa. Po prostu można by było wycisnąć więcej z tego dużego ekranu. Na pewno nie będzie tak, że roboty czy programy sprawdzające naszą aplikację będą w stanie powiedzieć, że to nie jest PWA, bo źle się wyświetla na desktopie. W drugą stronę jest to prostsze, bo jeżeli duży naciapany layout będziemy próbowali zmieścić na małym ekranie, to będzie to trudne i po prostu zobaczymy, że mamy trzy guziki obok siebie, a nawet w trzy na raz byłoby ciężko trafić jednym palcem. Tu jest łatwo to powiedzieć, natomiast w drugą stronę po pierwsze nie ma tego problemu, a nawet jeżeli jest, to tylko to wygląda, powiedzmy trochę gorzej i na pewno trzeba coś z tym zrobić, żeby koncepcja była podtrzymana, ale nie jest to ogólnie duży problem.

Jak długo właściwie PWA jest już na rynku? To jest koncept, który powstał rok temu, dwa lata temu?

PWA tak, jak mówiliśmy, zostało wprowadzone przez Google i to akurat był 2015 rok.

Natomiast te wszystkie technologie, które pozwalają stworzyć taką aplikację, która faktycznie użytkownikowi daje te wszystkie doświadczenia, jakie PWA postuluje, no to już pojawiły się dużo wcześniej, ale dalej są też rozwijane. Czy możliwości przeglądarek, czy możliwości telefonów, czy nawet sprzęt, jaki jest w telefonie i możliwości tego sprzętu w telefonie są coraz lepsze, więc coraz więcej rzeczy można zrobić na telefonie.

To jakby nie jest przypadek, że teraz mówimy sobie o PWA, bo tak naprawdę pierwsze takie podejścia, które pozwalały zrobić aplikację, która będzie trochę rozdzielała frontend od backendu, powstawały już bardzo dawno temu. Z mojej perspektywy takim pierwszym tego typu podejściem też było narzędzie od Google – GWT, czyli skrót od Google Web Toolkit (podobieństwo z Google Webmasters Tools przypadkowe). Wtedy pisanie oprogramowania w czystej Javie pozwalało skompilować projekt do czegoś, co na frontendzie było JavaScriptem, a na backendzie Javą. No i to jest taki z mojej perspektywy pierwszy wstęp.

Później były różne technologie typu Angular, React, Vue.js i inne frameworki typowo JavaScriptowe / frontendowe. Ich użycie na pewno bardzo dobrze wpływa na to, jakie użytkownik ma wrażenia z używania naszej aplikacji.

No właśnie, 2015 rok. Czyli praktycznie od 5 lat PWA jakoś tam sobie raczkuje. Wcześniej były inne technologie, które w pewnym sensie sprowadzały się do podobnych efektów. A my dzisiaj mówimy o tym, że PWA jest nowym trendem. I faktycznie tak jest, że na rynku e-Commerce PWA pojawiło się mniej więcej 2 lata temu, czyli jeszcze na tyle niedawno, żeby jeszcze dzisiaj mówić o tym, że to jest coś nowego. To się pomału przeradza w modę, rzeczywiście rzadko się zdarza z mojego punktu widzenia takie zapytanie o sklep internetowy, które, chociaż nie zapyta nieśmiało, czy może nie warto spróbować PWA. Jak to zwykle bywa z nowymi trendami, aktualnie to, co łączy te wszystkie nowości, to najczęściej kosztowna implementacja, bo ktoś musi przetrzeć szlak. Natomiast to prowadzi do takiego pytania o twoją opinię, na ile PWA jest takim faktycznie chwilowym trendem, a na ile możemy mówić o tutaj o takim „big thing”, czyli rzeczy, która zmieni świat e-Commerce, Internet i wszystko po kolei? Czy rzeczywiście PWA ma z nami szansę zostać na dłużej i warto w ogóle dzisiaj wydawać trochę więcej pieniędzy na wdrożenie? I jeżeli uważasz, że tak i że to będzie duża rzecz, to z czego wynika taka opinia?

O ile samo pojęcie PWA jest faktycznie w miarę świeże i teraz bardzo nośne, to te wszystkie technologie, które składają się na to, żeby spełniać te warunki, pojawiały się dużo wcześniej.

Też prawdopodobnie trzeba wziąć pod uwagę, że e-Commerce istniał bardzo długo wcześniej, no i przez to, że kiedyś takich możliwości raczej nie było, bo dopiero te frameworki frontendowe powstawały, to te starsze sklepy nie mają po prostu tych rzeczy. No i jeżeli był dostawca naszego silnika sklepowego, to musiałby poświęcić bardzo dużo pracy, żeby przepisać to na aplikację, którą później dałoby się nazwać PWA.

Natomiast aplikacje, które były bardziej dedykowane – one już z tych technologii, które powiedzmy, PWA pozwoliły zaadaptować także do e-Commerce, używały dużo wcześniej, bo one były po prostu robione od zera i tam ludzie już zauważyli, że robienie tego w ten sposób właśnie, daje dużo możliwości, przyjemności z użytkowania, a wcale nie powoduje jakiegoś dużego narzutu w trakcie developmentu, bo i tak robimy to od zera.

Tak naprawdę można by było sobie wyobrazić, że wdrażamy jakiś bardzo skomplikowany frontendowo system, to użycie takiej nowoczesnej frontendowej technologii daje nam tyle narzędzi, że może to pomóc nawet zmniejszyć te koszty wdrożenia.

Dlatego PWA w swojej istocie nie jest niczym nowym, po prostu ktoś w końcu wyczuł dobry moment, zebrał to do kupy i powiedział, że teraz to już jest ten czas, w którym warto by było w to zainwestować, że użytkownicy sklepów internetowych są już wyposażeni w na tyle urządzenia, że po pierwsze jest to w stanie uciągnąć takie podejście. Bo nie jest wcale powiedziane, że w 2013 roku jakby ktoś zrobił taki sklep, jak teraz, no to prawdopodobnie telefony większości ludzi by nie dały sobie z tym rady, bo najpierw wychodzą flagowce, później trochę gorsze telefony, później dopiero użytkownicy, średnio po roku czy półtorej (zależnie od tego, jak ktoś miał umowę) sobie zmieniają te telefony. Więc wejście na rynek nowej technologii, która pozwala obsłużyć jakieś rzeczy, też trochę trwa.

Bardziej PWA i te wszystkie zasady, czy postulaty, zagościło w e-Commerce niż ogólnie w technologii internetowej. Tym samym nie wydaje mi się, żeby to było coś, co może szybko przeminąć. Po prostu się zadomowi i będzie standardem.

Gdybyśmy mieli to wszystko zobrazować. Mamy nomenklaturę, mamy technologię. Powiedzmy, że ja nawet kupuję, że to zostanie na dłużej. Pytanie brzmi: czy jest o co w ogóle kruszyć kopie? Ciągle mówimy o tym trendzie i o PWA jest głośno. Trzeba sobie oddać, że naprawdę rynek dobrze przyjął samo to określenie. Co prawda poziom zrozumienia mógłby być trochę lepszy, ale jako hasło przyjęło się znakomicie. Natomiast gdybyś miał to trochę zobrazować – czym różni się sklep internetowy zgodny z PWA od takiego, który został napisany niezgodnie z PWA. Inaczej mówiąc – co nam daje i czemu to się stało takim ciekawym tematem?

Google na etapie kreowania tej koncepcji doszło do wniosku, że aplikacje mobilne (takie natywne) są dla użytkownika przyjemniejsze, ale jednocześnie wymyślili sobie, że prawdopodobnie da się osiągnąć bardzo zbliżony poziom również na aplikacjach internetowych / webowych.

Okazało się to prawdą.

I teraz, jeżeli użytkownik korzysta ze standardowego sklepu, to musi trochę czekać na tę naszą aplikację. Nieważne jak ona by szybko działała, to gdzieś tam ta wrażenia będą takie, że na coś trzeba poczekać, coś się przeładowuje. Nawet Google to zbadało, ile to czekanie trwa, żeby użytkownik już widział, że coś się dzieje. I się okazuje, że już 150 milisekund to poziom, że użytkownik widzi, że na coś trzeba poczekać, a 400 milisekund to jest coś takiego, co wyraźnie użytkownikowi może nie przeszkadza, bo to nie jest długie oczekiwanie, ale to już jest takie coś, że to nie działa w stu procentach płynnie, tak jakbym się bawił czymś analogowym na swoim własnym stole.

No i teraz, jeżeli mamy taką aplikację w PWA, no to wszystko to ma na celu pomóc nam zachęcić tego użytkownika do korzystania z naszej aplikacji. No i można to trochę porównać do robienia wszystkiego, co w naszej mocy, żeby ten nasz sklep był intuicyjny, przejrzysty, użyteczny (np. zmieniamy nagłówek w procesie zakupowym, żeby użytkownik nie wychodził z procesu). I to jest rzecz właściwie na tym samym poziomie. Po to wdrażamy PWA, żeby jak najbardziej zachęcić użytkownika do korzystania z naszego sklepu.

I przechodząc do bardziej konkretnej wiedzy. Jak zobaczymy na aktualną listę wymagań od Google, to wszystkie te elementy da się wdrożyć na większości obecnych sklepów internetowych, oczywiście, jeżeli mamy pełną możliwość ingerencji w sklep. Więc nie ma takiego problemu, że musimy robić nie wiadomo co, żeby spełnić te warunki PWA. Tak naprawdę jest tylko jeden warunek, który niestety wymusza nam zrobienie takiego podejścia, że frontend jest osobno, backend jest osobno i to generuje nam największe koszty.

No ale, żeby mówić, że mamy pełne PWA, to nie ma innej możliwości i tak naprawdę tylko wtedy jesteśmy w stanie dostarczyć użytkownikowi taki stuprocentowo płynny i bardzo dynamiczne / responsywne wrażenia z używania naszej aplikacji.

Użyłeś stwierdzenia „pełne PWA”. Jeżeli spełnimy wszystkie punkty z listy, to mamy pełne PWA. Czy jest w takim razie coś takiego jak „niepełne PWA” w takim znaczeniu, że jest taka praktyka, że jeśli na przykład z jakiegoś powodu nie da się sklepu dostosować do wszystkich punktów na liście rekomendacji, to robi się część, bo to i tak znacząco poprawia feeling użytkownika?

Tak, jak najbardziej ma to sens. Tak samo, jakbyśmy projektowali nowy layout i okazałoby się, że wdrażamy wszystko do koszyka, a wdrożenie procesu zakupowego będzie czasochłonne, więc wrzucamy zmiany od strony głównej do koszyka. I jak najbardziej miałoby to sens, bo czemu mielibyśmy nie pokazać użytkownikowi tej połowy sklepu, czy nawet ponad połowy sklepu w zmienionej wersji.

Tak samo można powiedzieć, że realizując poszczególne punkty z tej listy wymagań od Google, na pewno dostarczymy użytkownikowi jakąś tam dodatkową wartość. W początkowym okresie istnienia PWA, gdzie jeszcze przeglądarki dopiero trochę się uczyły, trochę zaczynały spełniać te standardy, wystarczyło tak naprawdę dorzucić jeden plik i parę ikonek do serwisu i już można było wrzucić sobie aplikację webową do smartfona na ekran. Taka strona udawała na smartfonie aplikację natywną.

Nie ma żadnego powodu, żeby powiedzieć „dobra, jak nie robimy PWA w całości, bo to zbyt czasochłonne, nie mamy takich możliwości technologicznych, to nie zrobimy dodawania aplikacji do ekranu głównego”. To nie ma po prostu sensu, bo może jacyś użytkownicy będą mieli taką potrzebę, żeby sobie dodać i będą chętnie z tego korzystali. Telefon bardzo często w ciągu dnia sobie otwieramy, więc być może ktoś będzie 20-30 razy na dzień patrzył na logo naszego sklepu tylko dlatego, że to umożliwiliśmy.

Obecnie jest to trochę, powiedzmy bardziej skomplikowane, bo przeglądarki wiedzą, że samo dodanie ikony jeszcze nie zrobi aplikacji PWA ze zwykłej strony internetowej, więc trzeba troszkę więcej rzeczy zaimplementować, natomiast nadal wszystkie punkty oprócz jednego z tej listy rekomendacji są jak najbardziej możliwe do zaimplementowania w ramach obecnego sklepu stosunkowo niewielkim nakładem pracy.

Mógłbyś się przynajmniej tymi najważniejszymi punktami z tej listy podzielić? Już powiedzieliśmy sobie o tym krótkim czasie oczekiwania na przeładowanie się aplikacji. Nie wiem, jak długa jest ta lista, ale czy są tam jakieś takie kluczowe punkty, które na pewno warto wdrożyć czy od nich w ogóle warto zacząć?

Lista nie jest tak bardzo długa, przynajmniej tych podstawowych punktów. I może od góry.

Aplikacja musi być szybka, nawet jeżeli połączenie jest, powiedzmy kiepskie. To jest coś, co niekoniecznie uda nam się łatwo wdrożyć. Jeśli nasz sklep cierpi trochę na problemy wydajnościowe, czy to przy dużych obciążeniach, czy niekoniecznie, to te punkty mogą sprawić trochę problemów. Ale to jest jeden punkt.

Na pewno łatwo (w miarę) zrobimy coś takiego, żeby nasza aplikacja była dostępna, nawet jeżeli jesteśmy offline. To jest dosłownie kilka linijek w odpowiednim miejscu i mamy aplikację, która jakoś tam (powiedzmy, że niezbyt okazale) działa w offline.

Idąc dalej, musimy używać protokołu HTTPS. Teraz po prostu tak jest, że musimy tak czy inaczej. Przeglądarka, jeśli nie używamy tego protokołu, to nawet zaczyna „krzyczeć”, więc większość sklepów i tak już sobie to zaimplementowała już.

Później są bardziej techniczne rzeczy – na przykład manifest, który pozwoli nam dodać aplikację do ekranu głównego. Jeżeli już dodamy sobie ten manifest i dodamy aplikację do ekranu głównego, to fajnie, jeżeli zrobimy taki splash screen, czyli ktoś klika w ikonkę i trochę inaczej, niż po wpisaniu adresu w przeglądarce (bo teoretycznie efekt jest ten sam, że wejdziemy na naszą stronę), to nie mamy ładowania, w którym nic nie widzimy, tylko mamy jakieś nasze logo, czy inne coś, co sobie wymyślimy. Zazwyczaj sklep ma jakiś dominujący kolor, więc ustawiamy po prostu ten kolor, to dalej nic użytkownikowi wielkiego nie daje oprócz tego, że dobrze się czuje z naszą aplikacją – nie otwiera mu się najpierw czarna strona, a potem nasza zielona, tylko cały czas przeglądarka rozumie, że ta strona jest zielona.

Później jest kilka takich punktów o RWD. Po prostu layout musi się dopasowywać do naszego ekranu.

Później znowu kilka technicznych punktów (to je pominę), jakaś ikona Apple, musi działać na różnych przeglądarkach (dość oczywiste).

Był taki moment, że dużo prostszych czy biznesowych witryn było zrobione w modelu SPA, czyli jak klikaliśmy na jakiś element, to tak naprawdę być może było symulowane przejście między stronami, ale takiego przejścia nie było i wszystko ładowało się za jednym razem, co było po części dobre, bo jeśli to jest w miarę prosta strona biznesowa czy korporacyjna, to czemu mielibyśmy później czekać na załadowanie się takich prostych treści. No ale pod SEO było to trochę gorsze i tutaj też jest punkt, że każda strona musi mieć swój własny URL.

I to właściwie tyle, to kończy te wszystkie punkty.

No i ostatni – przejścia pomiędzy podstronami nie mogą wydawać się, jakby blokował je Internet.

I ten ostatni punkt to jest, rozumiem, że jest najtrudniejszy i to już stanowi taką barierę technologiczną, tak?

Tak, jeżeli mamy, jak to zazwyczaj do tej pory w e-Commerce bywa, połączony frontend i backend na jednym silniku, to będzie ciężkie do zrobienia. Można to pewnie jakoś próbować ominąć bez rozdzielania backendu od frontendu, natomiast faktyczne rozdzielenie pozwala nam, nie wiem, wchodzimy na listę produktów, mamy 40 produktów z dość okrojoną informacją – małe zdjęcie, nazwę, może podstawowe atrybuty, klikamy w konkretne produkt i teraz, jeśli mamy w standardowej wersji, to musimy poczekać, aż strona nam się załaduje.

Natomiast jeśli mamy rozdzielony frontend od backendu, to mamy morze możliwości.

Możemy pokazać taką stronę, która ma tylko zaślepki w odpowiednich miejscach (na przykład szare pola) i za chwilkę wszystko się doładuje, przy czym te dane, na które czekamy, nie są zbyt duże, bo tylko do jednego produktu, więc szybko się uzupełnią. Mogłoby być to trochę lepiej zrobione, czyli bierzemy te wszystkie dane, które mamy i powiedzmy, że nasz sklep działa w miarę sprawnie, więc na te dane o produkcie będziemy czekali 200ms, czyli nie dużo, ale już po wejściu na kartę produktu mamy zeskalowane zdjęcie stare, które było małe, a teraz jest rozciągnięte. Widać pikselozę, ale to będzie tylko moment. Mamy nazwę, podstawowe atrybuty i prawdopodobnie możemy zaprezentować cenę, guzik „dodaj do koszyka” i być może nawet okaże się, że wszystko, co widzimy na początku, jak wchodzimy sobie na kartę produktu, to już sobie wzięliśmy z listy produktów. Więc zanim użytkownik zescrolluje na dół, to pełne dane o produkcie przyjdą z serwera i dzięki temu użytkownik będzie myślał, że sklep załadował sobie wszystko na liście produktów. A tak naprawdę to jest tylko sztuczka.

Z tego, co mówisz, to jest zestaw reguł, bo Google sobie wymyśliło, że użytkownicy lubią mieć takie poczucie, że korzystają ze strony trochę tak, jak z aplikacji mobilnej. I na tej liście wymagań też trochę to wyszło, między innymi dodanie ikony do ekranu startowego. To aż się prosi o pytanie, czemu po prostu nie zrobić aplikacji mobilnej? Mam wrażenie, że robimy jakieś szpagaty technologiczne tylko po to, żeby udawać aplikację, a obok leży sobie aplikacja mobilna, którą można po prostu wdrożyć. Właściwie po co udawać?

Jest część użytkowników, którzy na pewno będą woleli aplikację natywną, ale mimo wszystko jest część użytkowników, która będzie wolała po prostu używanie stron internetowych.

Od użytkownika, żeby użył naszej aplikacji, wymagamy na początku trochę więcej zaangażowania, co niekoniecznie każdemu się podoba. Trochę więcej pracy wymaga też wypozycjonowanie takiej aplikacji, żeby użytkownicy się o niej dowiedzieli. Tutaj wystarczy adres albo klikniemy w reklamę czy link i otwiera nam się karta w przeglądarce z konkretną podstroną i już. Żeby to samo osiągnąć w aplikacji, to jak już mamy link do aplikacji, to otworzy się Google Play, czy sklep Apple, musimy kliknąć instalację, trochę to potrwa, pobieranie, instalacje, później trzeba aplikację otworzyć – widać, że to pierwsze zaangażowanie użytkownika dużo więcej trwa.

Są też badania pokazujące, że bardzo niewiele aplikacji, które zostaną zainstalowane, przetrwa przez dłuższy czas. Czyli użytkownik nawet zachęcony jakąś reklamą czy natrafiając na aplikację, on ją zainstaluje, ale już 1/4 z tych aplikacji zostanie odinstalowana. To są dane z zeszłego roku. 1/4 aplikacji zostanie odinstalowana po pierwszym użyciu, a tylko 20% z tych aplikacji przetrwa pierwszy tydzień od zainstalowania.

No a ta strona w Internecie jest zawsze, jest zawsze łatwo dostępna.

Chociaż dzięki PWA i dzięki następnemu wynalazkowi – TWA (ang. Trusted Web Activities) możemy trochę te dwa światy połączyć. Załóżmy, że mamy sklep, który jest zgodny z PWA i chcielibyśmy jednak dać użytkownikowi możliwość ściągnięcia także tej aplikacji. Mamy jakąś grupę mega zaangażowanych użytkowników i dla nich ta aplikacja była jak najbardziej w porządku. Dzięki właśnie TWA możemy sobie bez większego wysiłku osiągnąć na aplikacji to samo, co już mamy na naszym sklepie.

Nasz sklep jest responsywny, więc na telefonie będzie wyglądał dobrze i przygotowanie takiej aplikacji, jeśli mamy sklep w pełni zgodny z PWA, nie zajmie nam dużo czasu. Jest tak naprawdę dla kogoś, kto już to raz kiedyś zrobił i jest biegły w Androidzie, to będzie parę dni, może nawet mniej. Więcej czasu będzie musiał poświęcić marketing na przygotowanie treści promocyjnych i wszystkiego, co się ma wyświetlić w Google Play, niż zajmie przygotowanie samej aplikacji. W ten sposób mamy dokładnie jeden do jednego to, co mamy na sklepie w aplikacji.

Nie mamy wtedy takich problemów, jak zazwyczaj z aplikacjami są, czyli chcemy zaktualizować naszą natywną aplikację, no i musimy niestety poczekać, aż po pierwsze Google nam to zaakceptuje, a po drugie łaskawie musimy poczekać, aż każdy z użytkowników zaktualizuje sobie aplikację i oczywiści jest część użytkowników, którym aktualizuje się wszystko samo automatycznie, większość ma aktualizacje automatyczne tylko na WiFi, są tacy, co muszą kliknąć, żeby się zaktualizowało, a są tacy, którzy nigdy tego nie zrobią i potem możemy skończyć z bardzo szeroką rozpiętością aplikacji. Natomiast tutaj tego problemu nie będzie, bo wszystko, co sobie zaktualizujemy w ramach sklepu, będzie od razu aktualizowane także na telefonie.

Minus tego rozwiązania jest taki, że Apple jeszcze dobrze tego nie wspiera i w sumie nie wiadomo, czy kiedyś będzie. Są triki, żeby sobie z tym poradzić, ale dalej możemy się odbić i trafić na akurat taką osobę, która naszej aplikacji na Apple nie przepuści przez review i z tym niewiele jesteśmy w stanie zrobić.

Plusem tego rozwiązania jest też możliwość bardzo łatwego wprowadzenia funkcjonalności, których jeszcze w przeglądarce nie będziemy w stanie zaimplementować. Załóżmy, że mamy sklep, ale chcielibyśmy dodać jakiś VR. Obecnie w przeglądarce jest to raczej nie do zrobienia. Załóżmy, że mamy wszystko przygotowane od strony tego VR technologicznie, ale musimy to jakoś spiąć z naszą stroną. W obrębie aplikacji byłoby to niemożliwe, ale dzięki zastosowaniu TWA mamy cały sklep taki sam, jak mamy go w aplikacji internetowej, ale możemy dodać zupełnie natywną funkcjonalność VR i okazuje się, że mamy na przykład meble i możemy sobie je kupić na aplikacji lub w sklepie, ale w aplikacji mamy jeszcze taką funkcję, że te meble możemy zobaczyć w naszym własnym domu przez telefon. To wymaga tylko pracy z tym VR, a nie wymaga wdrażania całego sklepu na aplikacji mobilnej, co prawdopodobnie pożarłoby dużo więcej czasu.

Czyli tak naprawdę, ja widzę przynajmniej taką główną korzyść, że TWA na koniec dnia daje możliwość zrobienia ze strony internetowej takiej prawdziwej aplikacji, przynajmniej w tym środowisku Google, a odchodzi nam koszt pisania aplikacji natywnej i utrzymywania w jakimś stopniu dwóch sklepów jednocześnie, tak?

Tak, jak najbardziej. Nawet niepełne wdrożenie PWA daje nam możliwość skorzystania z TWA. Co prawda nie będziemy w pełni zgodni z regulaminem i trzeba by było mieć to na uwadze, natomiast w tym momencie Google nie ma żadnej korzyści z tego, żeby wywalać naszą aplikację ze swojego sklepu, a przez to, że będziemy TWA, to raczej będzie takim naszym „ambasadorem” tej aplikacji.

Więc myślę, że jest to coś, co warto rozważyć, nawet jeżeli nie jesteśmy w stanie wdrożyć pełnego PWA.

Wiesz, Maciek, my tak sobie omawiamy to zagadnienie jakieś pół godziny i na razie same superlatywy. Fantastyczne podejście daje dużo użytkownikowi, ostatecznie możemy mieć aplikację mobilną, jest szybko, jest UX-owo, zgodnie z wytycznymi Google. Nie uwierzę, że nie ma minusów. Czy są takie obiektywne minusy wdrożenia sklepu z PWA? Pytam o dzisiaj, bo może jest to technologia, która powinna dojrzeć. Czy dzisiaj jest jakieś zagrożenie?

Na pewno jednym z minusów jest to, że jest drożej. Nie ma co się oszukiwać, raczej ciężko będzie zrobić takie wdrożenie, że PWA i użycie technologii związanej z PWA, żeby spełniać wszystkie założenia, będzie raczej pociągało większe koszty. Szacuje się, że jest to około 20% więcej na całym wdrożeniu. No więc dla większości sklepów będzie to znaczący koszt.

Teoretycznie można to zawsze przeskoczyć, idziemy do inwestora czy właściciela, zdobywamy większy budżet i mamy.

Przez długi czas, mimo że to Google promuje PWA, była spora obawa, co z SEO, bo aplikacja PWA ma to do siebie, że jak w nią wejdziemy i zobaczymy sobie źródło strony, to nic mądrego tam nie zobaczymy. Źródło jest tak naprawdę tylko taką stroną startową, która później się rozbuduje w cały nasz mechanizm aplikacji webowej (w tym wypadku sklepu). No i Google oczywiście zapewniał, że nie ma problemu i nawet lepiej traktuje takie aplikacje PWA, bo są przyjemniejsze dla użytkownika, więc Google też zależy na tym, żeby te strony były wyżej w wynikach wyszukiwania, bo wtedy użytkownik będzie bardziej zadowolony z wyszukiwarki.

Natomiast Google Googlem, ale to nie jest jedyna wyszukiwarka internetowa. I ten temat SEO jak najbardziej był często podnoszonym dużym problemem pod kątem PWA, bo bez SEO to e-Commerce nie ma trochę sensu. Nawet jak mamy zaufane grono użytkowników, to pewnie by dalej kupowali u nas, ale nie o to chodzi. Natomiast wykreowały się takie dwa podejścia. Albo sobie robimy renderowanie tej treści po stronie serwera, co jest możliwe, ale trzeba o tym pamiętać od początku wdrożenia, bo później przepisanie tego w mojej ocenie jest po prostu niemożliwe, za trudne i lepiej to zrobić jeszcze raz, niż próbować dopisać. A druga rzecz, to rozdzielenie ruchu. Ruch standardowych użytkowników puszczamy standardową ścieżką, a ruch z robotów (Google / Bing / Yahoo i inne) puszczamy na też Googlowe narzędzie, które najpierw wyrenderuje tę stronę dla robota. I tutaj użytkownik nie ma żadnych minusów, bo jest tak samo obsługiwany, a roboty są zadowolne no bo dostają faktyczną zawartość strony.

Powiedziałeś o tych 20%, a mi się zapala lampka. Słuchaczom to podejrzewam, że nawet nie jedna. Bo to dużo. Wyobrażam sobie, że to jest inwestycja, która ma jak najbardziej prawo się zwrócić i są takie grupy docelowe, w których nawet nie ma chyba się co zastanawiać, bo to są użytkownicy, którzy mają telefon jako naturalne przedłużenie ręki i feeling aplikacji mobilnej może być dla nich bardzo istotny. Natomiast czy ty widzisz takie biznesy e-Commerce, które przynajmniej powinny się porządnie zastanowić, czy warto te 20% ekstra dorzucać?

W linkach do odcinka dorzucimy takie case study (też strona od Google) z różnymi aplikacjami. Niektóre firmy postanowiły się podzielić tym, co się stało po wdrożeniu PWA. Trzeba mieć też na uwadze, że często to nie była jedyna zmiana, że teraz mamy PWA, a wcześniej nie było, tylko przy okazji zmiany layoutów, drobnej lub bardziej zaawansowanej, te firmy wdrażały PWA.

I chyba nie ma sensu, żebyśmy teraz wszystko przytaczali. Każdy sobie weźmie jak najbliższy case study swojego podwórka i zobaczy. I wtedy może porównać, czy jeżeli na przykład będzie miał dwa razy gorszą poprawę ruchu, czy konwersji, czy czegokolwiek innego, to czy jeszcze wdrożenie się zwróci, czy nie. Jeśli ktoś stwierdzi, że bardzo mało prawdopodobne, że to się zwróci, to może nie ma sensu robić pełnego PWA, tylko te ficzery dla użytkownika, które pozwolą mu dużo lepiej korzystać z aplikacji i to nie będzie aż tak bardzo czasochłonne.

Na pewno, jeżeli jest taki biznes, który ma jednak mało ruchu mobilnego, to zazwyczaj na desktopie te strony nie cierpią na opóźnienia i dłuższe ładowanie, ale nie po stronie serwera, tylko po stronie właśnie przeglądarki. Tam raczej tego zysku wielkiego nie będzie, bo ci użytkownicy są przyzwyczajeni po prostu do korzystania tak, jak do tej pory, więc oni i tak kupią i tak kupią. Jeżeli jakiś użytkownik w B2B kupuje u nas dlatego, że albo ma bardzo dobre warunki, albo ma duży limit kredytowy, albo ma funkcjonalności typu import koszyka bezpośrednio z plików i przez to nie musi spędzać pół godziny w sklepie, tylko szybko to sobie załaduje – to dla niego PWA nie ma aż takiego znaczenia, bo on nie skorzysta z tych możliwości. On będzie zawsze ten plik ładował i będzie bardzo zadowolony z tego, że to zrobił szybko i szybko mu udało się zrobić zamówienie, tak? Albo ma dobre ceny, albo m ten swój limit kredytowy. Więc dodatkowe poświęcanie czasu na development PWA może nie być tutaj najlepszym pomysłem.

Ale zazwyczaj, jeśli to jest ruch mocno mieszany czy po prostu B2C – no raczej warto wziąć to pod uwagę i zobaczyć, ile tego ruchu jest obecnie, jak to może poprawić nam konwersję, jak to pomoże nam poprawić ruch, jak to może nam poprawić powracających użytkowników. Może trochę to wpłynie na rozpoznawalność marki. To już raczej indywidualnie trzeba się zastanowić.

Mamy już, kto powinien lub kto powinien się zastanowić, czy warto. W takim razie zostaje jeszcze pytanie „kiedy”. Kiedy jest najlepszy moment, żeby w ogóle myśleć o PWA? Każdy sklep ma jakiś swój cykl życia, mówi się o tym, że technologię się wymienia raz na ok. 5 lat, ale sklep się cały czas przez tych parę lat rozwija, coś dochodzi, coś się zmienia wizualnie i jest ten typowy rozwój. Który moment jest dobry na to, żeby w ogóle brać pod uwagę wdrażanie PWA?

Na pewno, jeżeli chcemy zrobić jakiś refresh czy redesign, to jest dobry moment, żeby się nad tym zastanowić. Bo jeżeli będziemy robić refresh, a za pół roku będziemy chcieli zastanowić się nad PWA, to robota do zrobienia dwa razy, chyba że refresh nie wyjdzie i będzie trzeba go zrobić jeszcze raz. Ale w momencie, kiedy zastanawiamy się nad odświeżeniem naszego sklepu, to na pewno warto wziąć to pod uwagę.

Jeżeli niedawno zrobiliśmy taką zmianę i wtedy nie robiliśmy tego PWA, to może na razie zróbmy po prostu wszystko, co da się uzyskać w miarę prosto, a przy następnej okazji, czyli przy tym, jak siądziemy jeszcze raz do redesignu systemu, to wtedy po prostu pamiętajmy o tym, żeby już nie przespać i wdrożyć PWA.

Można się zastanawiać, tylko to już raczej bardzo indywidualna kwestia – może takie PWA dałoby się wdrożyć nie na pełnym sklepie, tylko po prostu podstrona po podstronie, może jakieś grupy podstron wdrażać razem. Natomiast dalej to jednak będzie coś takiego, że nie będziemy w pełni zgodni z PWA, więc to taką bym zostawił skrajność do przemyślenia, jeżeli boimy się takich bardzo mocnych zmian na raz.

Wydaje mi się, że taki refresh jest naturalnym momentem, że po prostu mówimy sobie „to teraz zróbmy to w PWA”, chyba że robimy w ogóle nowy sklep czy przenosimy się na nową platformę, to jak najbardziej wtedy też.

Zaciekawiło mnie to, że to rozdzieliłeś, czyli z jednej strony mówisz o refreshu, z drugiej strony mówisz o zmianie sklepu internetowego, czyli tak trochę, jakby jedno z drugim nie miało na tyle związku, żeby zablokować wdrożenie PWA. To jest chyba dobry moment, żeby zadać to pytanie. W momencie, kiedy robimy redesign, może się zmienić tylko warstwa graficzna, a sklep zostać. Z drugiej strony mówiłeś wcześniej o tym, że do wdrożenia PWA jest potrzebne przełamanie pewnej bariery technologicznej, które pozwoli nam rozdzielić rzeczywiście tę część frontendową od backendowej. I w związku z tym – czy wdrożenie PWA nie oznacza tak naprawdę zmiany silnika sklepowego?

Zależy, co mamy teraz, ale raczej nie musi oznaczać takiej potężnej zmiany.

Główny wyznacznik tego, to czy nasz sklep obecnie pełni, albo przynajmniej w jakiejś tam części udostępnia nam logikę biznesową w postaci jakiegoś API, czy w formie REST, czy GraphQL, czy może trochę starszej technologii SOAP. Jeżeli mamy taką możliwość, to ten nowy frontend, który będzie w pełni zgodny z PWA, możemy budować na tym właśnie API.

Jeżeli tak nie jest, to właściwie widzę dwie możliwości. Albo ten sklep jest na tyle pod naszą kontrolą, że możemy to dorobić. Albo jest to poza naszą kontrolą i niestety nie będziemy w stanie tego dorobić na tym obecnym silniku. Wtedy nie mamy wyjścia, musimy po prostu zmieniać technologię.

W takim razie czy to wdrożenie sklepu albo wdrożenie PWA do sklepu w jakimś sensie czy stopniu różni się od takiego zwykłego wdrożenia? Mówimy ciągle o trendzie, widzę różnice i przewagi i jest to zupełnie inne podejście do frontendu. Czy ono pociąga za sobą w konsekwencji inny sposób wdrażania z punktu widzenia samego projektu czy klienta? Czy to trwa jakoś znacząco dłużej?

Z punktu widzenia powiedzmy dyrektora e-Commerce, to dla niego to jest tylko decyzja, że „tak, chcemy spróbować z PWA”. No i albo już wewnątrz firmy następuje wdrożenie i wtedy jakiś pewnie dyrektor technologiczny ma ból głowy, jak to zrobić, żeby jego zespół to umiał zrobić (chyba że już umie, to nie ma problemu).

Z perspektywy zewnętrznej firmy jest podobnie. Mówimy, że należałoby to zrobić razem z PWA i wtedy robimy to po prostu w tej formie, nie ma żadnego problemu. Nie musi to potrwać dłużej. Teoretycznie mogłoby nawet potrwać krócej przez to, że rozdzielamy całkowicie frontend od backendu, to możemy niezależne ze sobą dwa zespoły wrzucić do tego projektu i one będą pracowały bez większych kolizji. Oczywiście to w takim idealnym przypadku, normalnie tak trochę nie jest i zawsze będzie trochę tak, że frontend czeka na backend albo backend czeka na frontend. Te zespoły, które pracują na backendzie albo na frontendzie też nie mogą być nie wiadomo jak duże, bo po prostu tej pracy nie da się aż tak mocno rozdzielić. Też nie jest powiedziane, że w standardowym podejściu nie byłoby trochę podobnie, że ktoś jednak bardziej zajmuje się frontendem, a ktoś bardziej zajmuje się backendem i logiką biznesową. Natomiast jest tu gdzieś tam jakiś potencjał, że może faktycznie byłoby to trochę szybciej, mimo że będzie drożej.

A czy sam silnik sklepu internetowego jakoś wpływa na ten proces? Z tego, co mówisz, to jest na tyle rozdzielone, że o ile jest API, to w zasadzie jesteśmy w domu i możemy sobie spokojnie wdrażać. Natomiast czy te różne technologie na backendzie jakoś rzutują na wybór technologii, czy na sposób wdrożenia? Czy z jakimś sklepem idzie ograniczenie w tym, co możemy zrobić?

Na pewno bardzo dużo czasu możemy zaoszczędzić, jeśli wybierzemy taki silnik, którzy ma już przynajmniej zalążek takiego PWA frontendowego.

Są różne przykłady. Magento ma swoją własną technologię PWA i jest kilka technologii, które są do Magento dostosowane i współpracują z API Magento od ręki. Jest coś do SAP. Każdy system ma jakieś tam własne elementy.

Także, jeśli nie zrobimy tego na systemie, który w ogóle tego nie potrafi, a jedynie daje nam szansę na wykorzystanie API, które już istnieje, to wtedy wiadomo, że będzie krócej.

Pogadajmy chwilę jeszcze o efektach. Podzielę się z tobą historią, która mi się kiedyś przytrafiła. Otóż rozmawiałem z jednym klientem, który chwalił się wdrożonym sklepem w PWA i okazało się, że ten sklep nie był wdrożony w PWA. Mi to było dość łatwo sprawdzić i byłem zaskoczony, natomiast klient był dwa razy bardziej zaskoczony. Myślę, że to trochę efekt tego, że wydał te „20% więcej”, a dostał sklep, który nie jest w PWA. W związku z tym pytanie brzmi: jak można w ogóle zdiagnozować ten efekt? Czyli wejść na stronę i powiedzieć „ok, to jest takie PWA, jak miało być”?

Jeżeli jesteśmy obeznani z narzędziami deweloperskimi do Google Chrome, to nie ma żadnego problemu – odpalamy sobie Lighthouse i tam jednym z elementów tego raportu jest to, czy PWA działa, czy nie działa i też są podzielone na te wszystkie elementy, o których już sobie powiedzieliśmy. Więc możemy zdiagnozować, czy to PWA jest, czy go nie ma. Obecnie ten Lighthouse ma trochę problem z tym takim najtrudniejszym punktem, ale dalej w tej naszej konsoli deweloperskiej możemy sobie sprawdzić.

Jeżeli jesteśmy trochę mniej zaawansowani technologicznie, to możemy sobie wyszukać po prostu jakiś on-line checker PWA i wyskoczy nam parę linków, które zadziałają podobnie do tego Lighthouse.

Natomiast żeby mieć taką stuprocentową pewność, raczej potrzebowalibyśmy kogoś, kto zna się technologicznie i to sprawdzi. Ewentualnie jeżeli wejdziemy sobie na stronę i zobaczymy źródło (CTRL+U) i tam nie będzie nic mądrego, tylko parę tagów i wtyczka JavaScript, to znaczy, że prawdopodobnie to PWA jest po prostu dobrze zrobione.

Innym jeszcze miejscem, w którym łatwo to znaleźć, to dodawanie strony do ekranu głównego. To, że to działa, nie znaczy, że pełne PWA mamy wdrożone i wszystkie punkty spełniamy, natomiast jeżeli tego nie ma, to na pewno PWA nie ma.

Przejdźmy do tej ostatniej części takiej typowo inspiracyjnej. Fajne rzeczy sobie opowiadamy, natomiast wydaje mi się, że słuchacze mogliby chcieć trochę poklikać i zobaczyć ten efekt, czy rzeczywiście jest taki WOW, jak brzmi to z tego, co opowiadasz. Czy możesz podzielić się przykładem jakiegoś fajnego wdrożenia, które jest gdzieś on-line i można tam sobie wejść, żeby sprawdzić, jak to działa i są tam efekty biznesowe, żeby ktoś mógł sprawdzić, czy te 20% więcej do wydania jest warte faktycznie takiej inwestycji?

Może jeszcze wróćmy do tych 20%, bo tak sobie rzuciliśmy te 20%. To są szacunki różnych firm, które pracują z PWA i różnymi systemami e-Commerce. To w konkretnym projekcie może być trochę więcej, trochę mniej, także tutaj trzeba by było już na bazie swojego projektu te 20% szacować.

Ale wracając do pytania. Z polskiego podwórka – Morele.net. Mimo, że to nie jest pełne wdrożenie PWA, to można sobie zobaczyć trochę, jak to działa. I to jest aktualnie, myślę, że najbardziej znany przykład z Polski. Możemy podać inne linki i najprościej będzie, myślę do linków dorzucić ten zestaw case study od Google. Tam są firmy różnej maści i bardziej znane na polskim rynku i mniej znane na polskim rynku, ale większość jest on-line na pewno. I tak samo te firmy podzieliły się w tych case study swoimi wynikami, więc to będzie najbardziej miarodajne – zobaczymy, jak to działa, zobaczymy też, co takie PWA wniosło, natomiast trzeba mieć gdzieś tam z tyłu głowy, że samo PWA mogło nie zrobić tych wyników, być może większa zmiana jakiegoś UX czy UI też wpłynęła na ten wynik.

Innym przykładem z polskiego podwórka może być mobilna wersja systemu Raw-Pol. Jeżeli wejdziemy tam z urządzenia mobilnego, powinno przerzucić nas na stronę mobilną i tam jest już pełne wdrożenie PWA. Można zobaczyć, jak to działa, jakie są odczucia. Jest to sklep po polsku, rejestracja akurat jest wymagana, żeby zobaczyć coś konkretniejszego, ale poklikać po katalogu można bez rejestracji.

Ok, gdybym poza jakimś praktycznym przykładem chciał się trochę dokształcić teoretycznie. Co prawda wyobrażam sobie, że słuchacze z tej teorii mogą nie wynieść zbyt wiele, bo ja zazwyczaj proszę o takie inspiracje, ale one są też takie bardzo biznesowe, więc na przykład słuchacz może sobie wejść i poczytać o SEO, zrobić trochę SEO we własnym zakresie. Tutaj pewnie we własnym zakresie PWA sobie nie wydłubiemy w sklepie internetowym, no ale może ktoś spróbuje. Czy są jakieś fajne źródła w Internecie, które ty byś szczególnie polecił? Jakieś materiały, może książki, opracowania? Wszystko to, co pomogłoby zrozumieć lepiej PWA i w konsekwencji mieć tak naprawdę większą kontrolę nad tym, co się będzie działo w tym sklepie internetowym w przyszłości.

Tu chyba bym znowu wrócił do tych linków do Google. Tam jest raczej dosyć jasno i intuicyjnie wyjaśnione, co to jest PWA i nawet z mniej technicznej strony, niż my to sobie dzisiaj powiedzieliśmy. Google skupia się jednak bardziej na użytkownikach i na wartości, jaką PWA daje użytkownikowi. My powiedzieliśmy trochę o takiej technologicznej wersji wdrożenia. W tych linkach będzie, myślę sporo ciekawej wiedzy. Google jako orędownik tego podejścia zadbał o to, żeby osoby decyzyjne też zrozumiały, że to ma sens.

Maćku ostatnie pytanie natury inspiracyjnej i trochę osobistej, które zadaję na końcu wszystkim. Gdybyś miał zostawić słuchaczy z taką jedną myślą, apelem, hasłem, przekazem, czyli innymi słowy, gdyby nasi słuchacze mieli z jedną rzeczą wyjść dzisiaj z tego odcinka, co byś im powiedział?

Jeżeli ktoś wcześniej nie rozważał w ogóle wdrożenia PWA w swoim sklepie, no to na pewno powinien się chociaż zapoznać z tym, co to jest, przeczytać parę case study i to najlepiej takie, które są w firmach najbliżej jego działalności, no i zastanowić się, może popytać, jakie by były te magiczne 20% w jego projekcie i ile by to kosztowało, zastanowić się, gdzie ma u siebie w aplikacji jakieś miejsce, gdzie uważa, że stoi trochę niżej, niż średnia na rynku i może faktycznie przy wdrożeniu PWA dałoby się to miejsce też poprawić. Może ma jakiś pomysł na super rozbudowaną funkcję, VR czy inną dla swojego użytkownika, ale niestety web go blokuje i potrzebuje natywnej, ale zrobienie aplikacji natywnej od zera jest poza jego zasięgiem, to nie bać się tego PWA, zrozumieć, co to jest no i spróbować może wdrożyć to u siebie w e-Commerce.

No a twoja wiedza, którą się dzisiaj podzieliłeś, na pewno w tym wszystkim pomoże. Maćku, dzięki za tę wiedzę w takim razie. Trzymaj się i do następnego razu.

Dziękuję bardzo za dzisiaj, cześć!