PWA w praktyce. Na co seowiec powinien zwrócić uwagę podczas wdrażania Progressive Web Apps?

Coraz częściej do przeglądania internetu korzystamy z urządzeń mobilnych. Normalnym stało się więc dostosowanie do nich swojej strony www. Od 1 lipca 2019 r. Google oficjalnie poinformowało o uruchomieniu mobile-first indexing, co pokazało, że również gigant z Mountain View zaczyna przykładać znaczną uwagę do witryn przystosowanych na smartfony czy tablety. Trzeba więc pilnować, by to, co jest na wersji desktop, było tym samym na mobile.

Ale to nie wszystko. Era smartfonów daje nam kolejną możliwość - aplikacje. Jednak nie jest to takie proste - Android, iOS, ciągle nowe wersje systemów, konieczność posiadania dodatkowych deweloperów i znowu pilnowanie, by wszystko pokrywało się z tym, co chcemy zaprezentować użytkownikowi na stronie internetowej. Pojawiają się kolejne obszary, które wymagają od nas podjęcia akcji. Czy nie można więc stworzyć stronę raz, by sprostała oczekiwaniom wszystkich urządzeń? Tak! Z pomocą przychodzi Progressive Web Apps, w skrócie PWA.

Czym jest PWA? Główne cechy

Najprościej mówiąc, Progressive Web Apps jest stroną internetową działającą na wszystkich urządzeniach i dającą możliwości interakcji z użytkownikiem zupełnie jak aplikacja. Technologia jest oparta o Javascript (tak, tak, już widzę Twoją przerażoną twarz), ale łatwo można sobie z tym poradzić, o czym opowiem w późniejszych częściach.

Głównymi charakterystykami PWA są:

• Działanie oraz skalowalność do wszystkich urządzeń

PWA jest progresywne oraz responsywne, nie ma problemu z działaniem na androidowym smartfonie z małym ekranem, najnowszym tablecie od Apple czy laptopie z Chrome OS. Ważne, aby była obsługa Javascript.

• Szybkość działania

Czas załadowania strony od momentu jej uruchomienia do załadowania pierwszego fragmentu zawartości (First Contentful Paint) jest znacznie mniejszy niż tradycyjnych stron internetowych. I to nawet przy połączeniach 3G.

• Możliwość przypięcia do pulpitu (bez instalacji aplikacji)

Użytkownikowi pojawia się stosowna informacja o możliwości przypięcia strony do ekranu. Dzięki temu będzie można ją odwiedzać bez użycia przeglądarki (wyświetlana jest na całym ekranie). Dodatkowo Progressive Web Apps można umieścić w sklepach z aplikacjami.

• Możliwość wysyłania powiadomień do użytkownika

Jak w tradycyjnej aplikacji możemy przypomnieć użytkownikowi o niedokończonych zakupach, zbliżającym się wydarzeniu, promocjach itp.

• Możliwość dostępu do kalendarza, aparatu czy lokalizacji użytkownika

Również jak w tradycyjnej aplikacji można mieć dostęp do zasobów urządzenia i np. dodawać wydarzenia do kalendarza.

• Każda strona posiada swój adres URL

Jak na normalnej stronie opartej o HTML, tak i tutaj każdy zasób ma swój adres URL.

• Dostępność offline

Przeglądanie stron opartych o PWA po ich załadowaniu jest możliwe bez dostępu do internetu.

Wdrażanie PWA w praktyce - 7 punktów, na które warto zwrócić uwagę

1 SSR dla robotów Google

Najpierw bardzo krótko i bez zbędnych szczegółów, jak można rozwiązać renderowanie Javascriptu:

• CSR (Customer Side Rendering) - cały Javascript wysyłany jest do „klienta” i renderowanie odbywa się przez przeglądarkę użytkownika. Wyświetlając źródło strony w body, zobaczymy skrypty JS, lecz badając poszczególne elementy, przeglądarka pokaże wyrenderowany HTML.
• SSR (Server Side Rendering) - renderowanie odbywa się przez serwer, a użytkownik dostaje gotowy HTML bez straty dla wszystkich cech PWA.
• Hybrid Rendering - wybrane przez nas zasoby renderuje przeglądarka, a pozostałe serwer.
• Dynamic Rendering - dla wybranych agentów (np. Googlebotów) renderowanie odbywa się przez serwer (SSR), a pozostali muszą radzić sobie sami (CSR).

Google zaleca tę ostatnią metodę lub całość po SSR. I przy okazji pokazuje pewien paradoks - twierdzi, że radzi sobie z JS (Chromium 74), jednocześnie zalecając, by stosować SSR dla Googlebotów, aby uniknąć problemów. I tak też należy postąpić w praktyce. W Google Search Console strona wysłana w całości w JS wygląda tak:

W kodzie HTML również zobaczymy wyłącznie Javascript.

Decydując się na renderowanie dynamiczne, warto również dodać do wyjątków boty innych używanych przez nas narzędzi, o których wiemy, że nie poradzą sobie z renderowaniem JS-a.

2. Najważniejsze „seowe” znaczniki bez renderowania

Punkt ten nie dotyczy właściwie tylko SSR. W pozostałych przypadkach warto pozostawić na stałe w head najważniejsze dla SEO znaczniki:

• Title,
• Description,
• Meta robots,
• Canonical,
• Hreflang.

Bardziej nadgorliwi mogą również „wyciągnąć” całe treści (szczególnie, jeśli uprzemy się na CSR).

Cała ta operacja jest swoistym zabezpieczeniem. Czasem coś może pójść nie tak i Google dostanie wtedy JS-a, czyli pustą stronę. Zanim programista połączy fakty i zrozumie, że u niego jednak też nie działa, to Google otrzyma przynajmniej część najważniejszych informacji.

3. Sprawdzaj renderowanie

Sprawdzaj adres URL w Google Search Console. I to często. Zarówno wygląd strony, jak i kod HTML. Każdy element powinien być taki sam, jak widzisz w przeglądarce, więc może przydać się narzędzie do porównania treści. A ważny jest każdy szczegół, bo na pierwszy rzut oka nie widać, np. czy rozwijane menu rzeczywiście ma jakieś pozycje 😉

Poza GSC warto również przeprowadzać test optymalizacji mobilnej, czy użyć narzędzia do testowania danych uporządkowanych.

Dobrą praktyką jest również zainstalowanie wtyczki do zmiany agenta, np. User-Agent Switcher for Chrome i dodanie dwóch pozycji:

• Googlebot: User-Agent String: Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html),
• Googlebot Mobile: Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.96 Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html).

Dzięki temu będzie można oszukać serwer i podszywać się pod Googleboty. W źródle strony powinniśmy wtedy zamiast skryptów otrzymać gotowy HTML (nie dotyczy SSR, tam zawsze powinien być HTML).

4. Porównaj stronę przed i po

Punkt w zasadzie dotyczy każdej migracji - dobrze jest zapisać wygląd i kod różnych typów stron (jak główna, produkty, kategorie, wpisy blogowe czy ważniejsze strony statyczne) i porównać je przed i po zmianach. Czasem możemy przeoczyć jakąś drobną rzecz, jak np. brak OG Tagów, czy inną kolejność elementów w kodzie strony.

5. Lighthouse oraz konsola błędów

Jeżeli wszystko zostanie poprawnie zaimplementowane, to w Lighthouse pojawi się taka ikona:

W raporcie ukażą się również podpowiedzi oraz błędy. Gdy okaże się, że są jeszcze pewne elementy do poprawy, to wszystko zostanie dodatkowo opisane. Poniżej zrzut ekranu, jak to wygląda dla strony mediaexpert.pl:

Poza Lighthouse warto również sprawdzać konsolę błędów w Chrome pod kątem ewentualnych problemów.

6. Weryfikuj indeksację treści w Google

By sprawdzić, czy treści są widoczne przez roboty skanujące, warto nanieść drobne zmiany w treści oraz sprawdzić ich indeksację w Google poprzez wpisanie komendy: site:naszastrona.pl „nowa treść”. Podobnie dobrze jest postąpić ze znacznikami Title czy Description. Pozwoli nam to na szybsze wykrycie ewentualnych nieprawidłowości.

7. Crawl jako Googlebot

Warto również masowo sprawdzić poprawność pobierania strony przez Google. W tym celu można użyć np. Screaming Froga oraz zmienić agenta na Google, by wyłapać ewentualne problematyczne strony.

Czy warto zainwestować w PWA? Podsumowanie

Ulubiona odpowiedź seowca - to zależy. Głównie od zasobności portfela. Myśląc o PWA, na pewno trzeba nastawić się na duże wydatki, szczególnie jeżeli wybierzemy SSR, który jest najbardziej pracochłonną opcją. Poza nakładami na prace programistyczne należy również przeznaczyć czas na sporą liczbę testów w firmie. Najlepiej gdy robią to pracownicy z różnych działów, bo może przykładowo okazać się, że występują problemy z dodawaniem reklam Ads. W zamian za to będziemy mogli cieszyć się szybką, nowoczesną stroną internetową z możliwościami aplikacji.

Zainteresowanych odsyłam do sprawdzenia działania Progressive Web Apps w praktyce:

• app.ft.com,
• twitter.com,
• wikihoops.com.