Ta strona używa cookies
sprawdź politykę prywatności

Rozumiem

Progressive Web App i WordPress – Teoria, Środowisko i Lighthouse

6/2/2019
Bartek Cis

Ten wpis jest wstępem do tematu PWA czyli super szybkich aplikacji internetowych działających offline. Opiszę tu jak ją zbudować w oparciu o WordPress.

Czego się dzisiaj dowiesz?

Generalnie będzie trochę teorii, wprowadzenie do całej koncepcji, ustawienie środowiska developerskiego i przegląd najważniejszych narzędzi. Jest to pierwszy wpis z serii.

Po tej lekturze będziesz wiedział/a jak działają aplikacje progresywne czyli Progressive Web App – PWA. Dowiesz się też czego potrzebujesz aby zacząć pracę nad własnym projektem opartym na WordPressie. Przyda Ci się ogólna wiedza na temat działania WordPress’a. Ten wpis tego nie zawiera.

Plan działania:

  1. Czym jest PWA i co potrafi?
  2. Jak ustawić lokalne środowisko developerskie z https?
  3. Google Lighthouse – kombajn do analizy internetu.

Dlaczego to piszę?

PWA pojawiły się jakieś 3-4 lata temu. Wprowadziły pewne zamieszanie w branży. Wręcz rewolucję. Dzisiaj już ma szerokie wsparcie w przeglądarkach i coraz więcej internetu wykorzystuje tą technologię. Bardzo dobrze.

O ile w internecie jest trochę materiałów na temat PWA w odniesieniu do nowoczesnych frameworków jak Angular, React czy Vue to już “tuning” starego dobrego WordPressa nie jest już tak popularny. Nie wiem czy w ogóle w polskim internecie jest porządna seria na ten temat…

Pytasz po co w ogóle mam się brandzlować z WordPressem jak mogę po prostu zainstalować odpowiednią wtyczkę? Racja… Ale Web Dev nie zachowuje się w ten sposób… Przynajmniej nie w każdej sytuacji 🙂

Seria Progressive Web App

Opisuje tutaj czym jest PWA i  jak stworzyć ją na WordPressie. Kolejne artykuły będą na bieżąco uzupełniane:

  1. Progressive Web App na WordPress – Teoria, Środowisko i Lighthouse

Progressive Web App – wstęp

Zgadnij gdzie powstał termin PWA? Hmm… hmm… (moja głowa pęka na pół próbując przeniknąć to pytanie). Nie wiem. Sprawdzę w wikipedii… Ooo… Ale jaja! W Google!

Kolejne pytanie: co potrafi taka aplikacja webowa? Posiada kilka funkcji charakterystycznych dla aplikacji natywnych pod np. Androida lub iOS’a (o tym później) do tego jest dużo szybsza od konwencjonalnych aplikacji dzięki specjalnemu mechanizmowi cache. Nie można też zapomnieć to tym, że taka strona internetowa działa offline czyli bez dostępu do internetu 🙂

Wszystko jest możliwe dzięki Service Worker’owi i specjalnym interfejsom API dającym mu wręcz magiczne moce. Service Worker jest swojego rodzaju pośrednikiem (proxy) między przeglądarką/aplikacją a serwerem który odpowiednio przetwarza przepływające między nimi dane. Dzisiaj opiszę ogólną teorię. Szczegóły i kod (w odniesieniu do WordPressa) w kolejnym wpisie serii.

Service Worker jest specjalnym rodzajem Web Worker’a czyli skryptu działającego niezależnie od głównego skryptu kontrolującego aplikację. Może on wykonywać operacje w tle które nie są bezpośrednio skorelowane z aktywnością użytkownika.

Schemat działania Service Worker’a wygląda tak:

HTTPS, przeglądarka i cache

Ten akapit będzie w zasadzie pytaniem i jeśli czyta to ktoś kto będzie w stanie wyklarować tą kwestie to będzie mistrzem tego wpisu 🙂

Kiedy dane są przesyłane przez zaszyfrowane połączenie, przeglądarka rozpoczynając sesję z HTTPS nie powinna ufać zasobom w swoim cache (bo mogłyby być przez kogoś zmodyfikowane) i renderować wszystko bezpośrednio z serwera. W skrócie domyślny mechanizm cache nie powinien działać.

Kiedy jednak sprawdzam różne strony używające HTTPS to przy kolejnych ładowaniach strony dane są pobierane z cache! Dlaczego tak się dzieje?

W Chromie znalazłem opcję `Use a prediction service to load pages more quickly` więc pomyślałem, że używa jakiś domyślnych Service Workerów ale gdy to wyłączyłem cache dalej działa.

Dlaczego to cache działa?

Service Worker i HTTPS

A więc brak(?) domyślnego mechanizmu cache przy komunikacji przez HTTPS (która ze względów bezpieczeństwa w zasadzie jest dzisiaj standardem) powoduje spadek wydajności aplikacji webowych. Po prostu zasoby są pobierane przy każdej sesji. Teoretycznie…

Service Worker do działania wymaga protokołu HTTPS i jest w stanie przechowywać komunikację z serwerem zastępując tradycyjny mechanizm cache. Posiada on interfejs sterujący cache. To jeden z elementów przyspieszających aplikację.

Service Worker i Predictive caching

Ale gdyby cache była jedyną sztuczką Service Worker’a nie byłby niczym wyjątkowym. On w zasadzie kontroluje przepływ danych między aplikacją a serwerem i żyje niezależnie od samej aplikacji.

Jest w stanie pobrać odpowiednie dane z wyprzedzeniem zanim użytkownik podejmie decyzję o wybranej akcji np. sprawdź stronę “O Blogu”. Dzięki temu po kliknięciu w daną sekcję dane ładują się niemal natychmiastowo.

Service Worker i offline

Skoro prowadzi on niezależną komunikację z serwerem i jest w stanie kontrolować cache to może w pewnym momencie zastąpić serwer kiedy jest taka potrzeba. Aplikacja i tak komunikuje się bezpośrednio z Service Workerem więc skoro jest on w stanie wykonać dane operacje bez serwera to w zasadzie działa offline. Więc kiedy stracisz zasięg PWA może dalej działać. Ale nie stanie się tak przy pierwszej wizycie na danej stronie.

Service Worker i push notification

Czyli jedna z funkcji które cechują aplikacje natywne. Service Worker jest w stanie w czasie rzeczywistym odbierać nowe komunikaty z serwera i wyświetlać je użytkownikowi. Oczywiście dzięki specjalnemu interfejsowi.

Service Worker i Background Notification

Kolejnym świetnym perkiem PWA jest możliwość wysyłania formularzy i innych danych na serwer gdy… jesteśmy offline! Po prostu Service Worker przechowuje je do czasu gdy znowu będzie w zasięgu internetu.

Service Worker i IndexedDB

Jak widać mamy do czynienia ze sporą ilością danych które muszą być przechowywane w jakiejś formie. Zwykłe cookies lub Web Storage to za mało. Bardziej wyszukaną metodą która lubi się z Service Workerem jest IndexedDB.

Ja chce kod!

W linkach które pojawiły się w między czasie jest go sporo ale ja przejdę do tego w kolejnym wpisie gdzie będę tworzył PWA na WordPressie. To miał być tylko taki wstęp do tematu 🙂

Jak ustawić lokalne środowisko developerskie z https?

Dobrze to zanim zaczniesz budować Service Worker’a na Wordpresie trzeba ustawić lokalne środowisko i serwer który będzie obsługiwał https.

Tutaj jest w sumie ciekawa (?) historia. Zazwyczaj jak robiłem coś z WordPressem to używałem MAMP’a. Jest ok ale jeśli potrzeba https to trochę się trzeba napocić żeby to ustawić.

Plan był taki, że do PWA użyje Valeta. Jak już ustawione to w zasadzie bezobsługowe środowisko. Spędziłem zdecydowanie za dużo czasu na instalacje wszystkiego co się z tym wiąże i upewnieniem się, że wszystko jest dobrze podpięte.

Nawet napisałem ładną instrukcję krok po kroku na potrzeby tego wpisu.

Kiedy WP już prawie hulał trzeba było podpiąć bazę danych. Z jakiego powodu instalator WP nie mógł się połączyć z bazą którą stworzyłem… Ja się z nią elegancko łączyłem a WP już nie. Tego było za wiele. Dlaczego tracę tyle czasu na ustawienie tego środowiska? Przecież to absurdalne!

Objawienie

Frustracja była ewidentna. Zamiast tworzyć moje cudowne PWA siedziałem nad środowiskiem…

Znalazłem narzędzie które się nazywa Local. To lokalne środowisko dla WordPressa. Pobrałem, zainstalowałem, utworzyłem projekt… Może z 5 minut to zajęło. Po prostu cudowne doświadczenie! Gorąco polecam!

Przekierowanie na HTTPS

O ile samo postawienie WordPressa jest bajecznie proste na Localu to musimy zadbać o to, aby był on domyślnie przekierowywany na bezpieczny protokół HTTPS. To wymaga uwagi.

Kiedy tworzysz nową stronę w kroku 2 ważne aby wybrać opcję “Custom” gdzie będziemy mogli ustawić przekierowanie.

Na tym etapie możesz wybrać jaki chcesz serwer nginx czy Apache. Potem można to zmienić ale ważne aby mieć na uwadze, że każdy serwer będzie wymagał innego podejścia.

Apache

W folderze public /wp-pwa/app/public należy stworzyć plik .htaccess. Jeśli nie wiesz czym on jest to przeczytaj mój artykuł. W tym pliku należy wkleić następującą regułę:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase / 

RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301] 

# BEGIN WordPress
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

nginx

W tym wypadku należy edytować plik site.conf który znajduje się w folderze /wp-pwa/conf/nginx/site.conf .

W pliku poniżej linii root /app/public/; należy wstawić:

if ($http_x_forwarded_proto != "https") {
        rewrite ^(.*)$ https://TWOJADOMENA$1 permanent;
    }

Możesz też skorzystać z tego wątku na oficjalnym forum.

Jak przekierowanie działa to będziesz mógł trzaskać PWA 🙂

Google Lighthouse – kombajn do analizy internetu.

Tutaj trochę na temat niesamowitego narzędzia do analizy aplikacji w internecie. Jeśli jeszcze go nie znasz to zdecydowanie je polubisz!

Jest to kolejny prezent od Google. Najpierw działało jako niezależny plugin ale jeśli używasz Chrome’a to możesz go używać z poziomu DevTools’ów 🙂

Jak działa Lighthouse?

Za jego pomocą możesz przeanalizować daną stronę pod kątem mobilności, PWA, użycia najlepszych praktyk, accessibility i SEO.

Dobre jest to, że nie tylko dostajesz ranking z oceną ale też masę wskazówek co i jak należy poprawić aby apka była po prostu lepsza.

Żeby jej użyć wejdź na stronę która Cię interesuje i w DevTools’ach idź do zakładki Audyt.

Bedekodzić w Lighthouse

To żeby pokazać jak fajny jest Lighthouse przeprowadzę kompletny audyt dla bedekodzić.pl!

Ten blog jest klasycznym przykładem WordPress’a więc poza SEO wypada dość blado… Co tu dużo mówić, gdyby WordPress startował w F1 to jedyny kontakt z pole-position miałby kiedy nikogo innego nie ma na torze a on po prostu przyszedł sobie dotknąć linie startowe.

Bedekodzić i PWA

Na tym etapie nie ma tu jeszcze żadnego Service Worker’a a mimo to już mam 58 punktów!

Ale jak to? Skąd te 58?

I na tym właśnie polega fenomen tego narzędzia! Wszystko pięknie tłumaczy. Google jak zwykle wymiata…

Podsumowanie

W zasadzie na dzisiejszy wpis to tyle. Mam nadzieję, że cała koncepcja PWA i Service Worker’ów jest dla Ciebie mniej więcej jasna. Jeśli nie to w tym wpisie znajdziesz sporo linków do pierwszorzędnych źródeł czyli Google, MDN i oficjalna dokumentacja.

Masz już też narzędzia które Ci się przydadzą do pracy nad PWA na WordPressie. Wszystko jest gotowe aby ruszyć z kopyta z developmentem!

W następnym wpisie z serii Twój WordPress kompletnie zmieni swoje oblicze by za 2-3 wpisy z być super-nowoczesną aplikacją 🙂

Podziel się z innymi 🙂

Piszę dla was tego bloga bo lubię aplikacje internetowe. Mogę je projektować, kodować a potem o nich pisać czując dreszczyk ekscytacji za każdym razem gdy trafię na coś nowego. Bo uczymy się całe życie. Prawda?

Cześć jestem Bartek.

Na tym blogu wprowadzę Cię w tajniki Front-Endu i programowania webowego.

Warto
Social media & sharing icons powered by UltimatelySocial