Środa, 9 listopada 2016 r.
Progresywne aplikacje internetowe (Progressive Web App – PWA) zapewniają użytkownikom optymalny komfort obsługi witryn mobilnych i aplikacji natywnych przez zastosowanie najnowszych technologii. To jeden z najbardziej innowacyjnych pomysłów w dziedzinie technik internetowych. Aby ich stosowanie było skuteczne, aplikacje te muszą być łatwe w indeksowaniu i powinny dobrze się linkować. Każda rekomendacja przedstawiona w tym artykule to dotychczasowa sprawdzona metoda dotycząca indeksowalności, niezależnie od tego, czy tworzysz progresywną aplikację internetową, czy prostą witrynę statyczną. Zebraliśmy te sprawdzone metody w jednym miejscu.
Łatwe indeksowanie treści
Dlaczego? Kiedyś witryny generowały lub renderowały kod HTML na serwerze, co stanowi najprostszy sposób na bezpośrednie linkowanie treści. Dzięki aplikacjom internetowym koncepcja renderowania po stronie klienta stała się bardziej popularna. W tym modelu treści są aktualizowane dynamicznie w trakcie przeglądania strony przez użytkownika, a odświeżanie strony nie jest konieczne.
Nowym rozwiązaniem jest renderowanie hybrydowe. Obejmuje ono renderowanie po stronie serwera, gdy użytkownik przechodzi bezpośrednio do adresu URL, oraz renderowanie po stronie klienta, gdy strona jest już wczytana. Takie podejście ułatwia nawigację i realizowanie żądań asynchronicznych.
Nasza przykładowa aplikacja PWA po stronie serwera pokazuje tylko renderowanie po stronie serwera, a hybrydowa aplikacja PWA pokazuje zastosowanie obu technik.
Więcej informacji na temat technologii renderowania po stronie serwera i po stronie klienta zawierają te artykuły na temat renderowania po stronie klienta i po stronie serwera oraz renderowania po stronie serwera w środowisku React i Node.js.
Sprawdzone metody:
Stosuj renderowanie po stronie serwera lub renderowanie hybrydowe, aby użytkownicy uzyskiwali dostęp do treści w wyniku pierwotnego żądania strony.
Upewnij się, że adresy URL są dostępne w sposób niezależny:
https://www.example.com/product/25/
Powyższy adres powinien być precyzyjnym linkiem do konkretnego zasobu.
Jeśli Twoja progresywna aplikacja internetowa nie obsługuje renderowania po stronie serwera ani renderowania hybrydowego, a zdecydujesz się na renderowanie po stronie klienta, zalecamy sprawdzenie renderowania treści w przypadku robota wyszukiwarki za pomocą dostępnego w Google Search Console narzędzia „Pobierz jako Google”.
Nie przekierowuj użytkowników klikających precyzyjne linki z powrotem do strony głównej aplikacji.
Warto też zadbać o to, by zamiast strony błędu pokazywał się użytkownikom link precyzyjny.
Czytelne adresy URL
Dlaczego? Identyfikatory fragmentów (#user/24601/ lub #!user/24601/) były skutecznym obejściem umożliwiającym przeglądarkom pobieranie nowych treści z serwera przy użyciu protokołu AJAX bez potrzeby ponownego wczytywania strony.
Ta metoda nosi teraz nazwę renderowania po stronie klienta.
Składnia obejmująca identyfikatory fragmentów może jednak nie działać w przypadku niektórych narzędzi internetowych, platform i protokołów takich jak stosowany na Facebooku protokół Open Graph.
Interfejs History API umożliwia aktualizowanie adresu URL bez użycia identyfikatorów fragmentów, a jednocześnie umożliwia też pobieranie zasobów w sposób asynchroniczny. Dzięki temu ponowne ładowanie strony nie jest konieczne. Ta metoda łączy najlepsze aspekty obu technik. Indeksowanie przy użyciu protokołu AJAX (czyli stosowanie adresów URL z fragmentami oddzielonymi znakami zmiany znaczenia / #!) miało wtedy sens, ale nie jest już zalecane.
Nasze przykłady aplikacji PWA z renderowaniem hybrydowym i po stronie klienta pokazują działanie interfejsu History API.
Sprawdzone metody:
Upewnij się, że adresy URL są czytelne i nie zawierają identyfikatorów fragmentów (# ani #!), takich jak:
https://www.example.com/product/25/
Jeśli chcesz użyć renderowania po stronie klienta lub renderowania hybrydowego, użyj interfejsu History API w celu usprawnienia nawigacji w przeglądarce.
Czego unikać:
Odradzamy używania struktury adresów URL #! do generowania unikalnych adresów URL:
https://www.example.com/#!product/25/
Ta metoda była stosowana w celu obejścia problemów, zanim interfejs History API stał się popularny. Taki rodzaj zapisu jest uznawany za oddzielny względem adresów URL wykorzystujących tylko fragment #.
Struktura adresu URL wykorzystująca fragment # bez towarzyszącego mu znaku ! nie jest obsługiwana:
https://www.example.com/#product/25/
Taka struktura URL jest już rozpoznawana w internecie i dotyczy tworzenia precyzyjnych linków do treści na wybranej stronie.
Określanie kanonicznych adresów URL
Dlaczego? Aby ułatwić indeksowanie tych samych treści dostępnych pod różnymi adresami URL (w tej samej domenie lub w różnych domenach), jedną ze stron warto określić jako kanoniczną. Dzięki temu wszystkie inne strony zawierające te same treści będą się do niej odnosić.
Sprawdzone metody:
Na wszystkich stronach obejmujących wybraną treść umieść ten tag:
<link rel="canonical" href="https://www.example.com/your-url/" />
Jeśli strony są zgodne ze standardem AMP, użyj także odpowiednika tej instrukcji, czyli rel="amphtml".
Czego unikać:
Staraj się nie duplikować treści pod różnymi adresami URL, jeśli nie planujesz użyć w linku elementu rel="canonical".
Element rel="canonical" w linku pomaga na przykład w rozróżnianiu adresów URL z parametrami śledzenia.
Unikaj tworzenia sprzecznych odniesień kanonicznych pomiędzy stronami.
Obsługa różnych urządzeń
Dlaczego? Łatwe przeglądanie stron – bez względu na urządzenie, z którego korzysta użytkownik – jest sprawą kluczową.
Witryna powinna być zaprojektowana w sposób elastyczny. Czcionki, marginesy, dopełnienie, przyciski i ogólny wygląd witryny powinny dynamicznie dopasowywać się zależnie od rozdzielczości ekranu i widocznego obszaru urządzenia.
Niewielkie obrazy, powiększane w celu wyświetlenia na komputerze lub tablecie, kiepsko się prezentują. Natomiast obrazy o bardzo wysokiej rozdzielczości długo się wczytują na telefonach komórkowych i mogą utrudnić przewijanie ekranu na urządzeniu mobilnym.
Dowiedz się więcej o UX w przypadku PWA.
Sprawdzone metody:
Używaj atrybutu srcset do pobierania obrazów o różnych rozdzielczościach odpowiednich dla ekranów o różnych gęstościach, aby uniknąć pobierania obrazów większych, niż można wyświetlić na ekranie urządzenia.
Zadbaj o to, aby rozmiar czcionki i wysokość wiersza zapewniały czytelność tekst bez względu na rozmiar ekranu urządzenia. Upewnij się też, że dopełnienie i marginesy elementów są odpowiednio skalowane.
Przetestuj różne rozdzielczości ekranu za pomocą Trybu urządzenia w Narzędziach deweloperskich w Chrome i narzędzia do testowania optymalizacji mobilnej.
Nie pokazuj użytkownikom innych treści niż robotowi Google. Jeśli korzystasz z przekierowań lub wykrywania klienta użytkownika (tzw. wykrywania przeglądarki lub dynamicznego wyświetlania treści), aby zmieniać projekt witryny w zależności od urządzeń, ważne jest, aby treść pozostała taka sama.
Użyj dostępnego w Search Console narzędzia „Pobierz jako Google”, aby sprawdzić, czy treści pobierane przez Google są takie same jak treści, które widzi użytkownik.
W trosce o użyteczność unikaj stosowania czcionek o stałych rozmiarach.
Programowanie iteracyjne
Dlaczego? Jedną z najbezpieczniejszych metod poszerzenia aplikacji internetowej o nowe funkcje jest iteracyjne wprowadzanie zmian. Jeśli dodajesz nowe funkcje pojedynczo, możesz sprawdzić wpływ każdej zmiany.
Niektórzy deweloperzy uważają, że tworzenie aplikacji PWA jest okazją do przerobienia całej witryny mobilnej za jednym zamachem. Opracowują oni taką aplikację w odizolowanym środowisku, a następnie zastępują dotychczasową witrynę gotową aplikacją mobilną.
Staraj się dzielić planowane iteracje udoskonaleń na poszczególne etapy. Jeśli chcesz na przykład przejść z renderowania po stronie klienta na renderowanie hybrydowe, zrób to w ramach jednej iteracji. Takiej zmiany lepiej nie łączyć z wprowadzaniem nowych funkcji.
Oba podejścia mają swoje plusy i minusy. Zmiany iteracyjne ograniczają problemy z indeksowaniem, ponieważ modyfikacje są wprowadzane w sposób ciągły. Jeśli jednak witryna nie powstaje od podstaw, podejście iteracyjne może spowolnić proces jej rozwoju i potencjalnie ograniczyć innowacyjność zmian.
W każdym przypadku zwróć uwagę na kanoniczne adresy URL i konfigurację pliku robots.txt witryny.
Sprawdzone metody:
Zmiany w witrynie wprowadzaj metodą iteracyjną, dodając nowe funkcje jedna po drugiej.
Jeśli na przykład nie korzystasz jeszcze z protokołu HTTPS, najpierw przenieś treści do bezpiecznej witryny.
Czego unikać:
Jeśli Twoja progresywna aplikacja internetowa powstała w odizolowanym środowisku, unikaj uruchamiania jej bez sprawdzania, czy linki rel-canonical i plik robots.txt są prawidłowo skonfigurowane.
Upewnij się, że linki rel-canonical wskazują prawidłową witrynę, a polecenia w pliku robots.txt nie blokują indeksowania nowej witryny.
Blokowanie dostępu robotów do witryny, która jeszcze powstaje, to właściwe posunięcie. Pamiętaj tylko, aby umożliwić indeksowanie witryny, gdy już będzie gotowa.
Stopniowe udoskonalenia
Dlaczego? Jeśli jest to możliwe, warto wykrywać funkcje przeglądarki przed ich użyciem. Wykrywanie funkcji jest lepszą metodą, niż testowanie obecności przeglądarek, które mogą wybraną funkcję obsługiwać.
W przeszłości stosowano nie najlepszą metodę, która polegała na włączaniu i wyłączaniu funkcji na podstawie zidentyfikowanej przeglądarki na urządzeniu użytkownika. Ponieważ funkcje obecnych przeglądarek szybko ulegają zmianom, zdecydowanie odradzamy stosowanie tej techniki.
Skrypt service workerstanowi dość nowoczesne rozwiązanie, które pomaga zachować zgodność z przeglądarkami w obliczu wciąż opracowywanych udoskonaleń – to doskonały przykład tego, kiedy warto zastosować progresywne ulepszanie.
Sprawdzone metody:
Zanim zastosujesz skrypt service worker, upewnij się, że jego interfejs API jest dostępny:
if ('serviceWorker' in navigator) {
...
Stosuj metodę wykrywania interfejsów API wykorzystywanych do obsługi funkcji witryny.
Nigdy nie stosuj klienta użytkownika przeglądarki w celu włączenia lub wyłączenia funkcji w aplikacji internetowej. Zawsze sprawdzaj, czy jest dostępny interfejs API obsługujący wybraną funkcję i przeprowadź łagodną degradację, jeśli takiego interfejsu nie uda się wykryć.
Najpierw przetestuj w różnych przeglądarkach działanie witryny, którą chcesz opublikować lub zmodyfikować. Sprawdź statystyki witryny, aby określić przeglądarki najczęściej używane do jej wyświetlania.
Testowanie w Search Console
Dlaczego? Warto przyjrzeć się, w jaki sposób przeglądarka Google przegląda treść Twojej witryny. Przy użyciu Search Console możesz pobrać poszczególne strony swojej witryny i sprawdzić, jak będą wyświetlane w wyszukiwarce Google. W tym celu użyj opcji Indeksowanie > Pobierz jako Google. Jeśli zaznaczysz odpowiednią opcję, Search Console wyrenderuje stronę z zastosowaniem JavaScriptu. W przeciwnym razie wyświetli się tylko wynik renderowania HTML.
Google Search Console analizuje treści zamieszczone na stronie na wiele sposobów. Między innymi wykrywa obecność danych strukturalnych, kart informacyjnych, linków do podstron i stron AMP.
Sprawdzone metody:
Korzystaj z narzędzi dostępnych w Search Console , w tym również z „Pobierz jako Google”, w celu monitorowania działania swojej witryny.
Prześlij do Search Console mapę swojej witryny za pomocą opcji Indeksowanie > Mapy witryn. W ten sposób możesz się upewnić, że wyszukiwarka Google odczytuje wszystkie strony Twojej witryny.
Stosowanie danych strukturalnych Schema.org
Dlaczego? Uporządkowane dane Schema.org to elastyczne elementy składni, które podsumowują kluczowe elementy Twojej strony w postaci danych odczytywanych przez roboty. Może to być informacja ogólna, na przykład o tym, że Twoja strona to NewsArticle. Może to również być informacja szczegółowa określająca lokalizację, nazwę zespołu muzycznego, lokal i dostawcę biletów na koncert albo spis składników wraz z przepisem kulinarnym.
Stosowanie tego rodzaju metadanych nie jest konieczne dla każdej strony Twojej aplikacji internetowej, ale jest zalecane w niektórych sytuacjach. Google wyodrębnia je po wyrenderowaniu strony.
Istnieje wiele typów danych, np. NewsArticle, Recipe i Product. Więcej informacji na temat obsługiwanych typów danych znajdziesz tutaj.
Sprawdzone metody:
Sprawdź, czy metadane Schema.org są prawidłowe. W tym celu użyj Narzędzia Google do testowania uporządkowanych danych.
Upewnij się, że określone dane się wyświetlają i nie zawierają błędów.
Unikaj stosowania typu danych, który nie odpowiada faktycznej treści Twojej strony. Na przykład nie stosuj typu Recipe, jeśli strona umożliwia sprzedaż koszulek. W takim przypadku zastosuj typ Product.
Stosowanie protokołu Open Graph i kart Twittera
Dlaczego? Oprócz metadanych Schema.org warto umożliwić obsługę protokołu Open Graph stosowanego na Facebooku oraz kart informacyjnych Twittera.
Tego rodzaju metadane pozytywnie wpływają na wrażenia użytkownika, gdy treści są również dostępne w odpowiednich sieciach społecznościowych.
Jeśli stosujesz tego typu formaty w dotychczasowej witrynie lub aplikacji internetowej, upewnij się, że będą one również ujęte w Twojej aplikacji PWA. Dzięki temu jej popularność będzie optymalna.
Sprawdzone metody:
Sprawdź znaczniki protokołu Open Graph za pomocą Narzędzia do usuwania błędów związanych z obiektami Facebooka.
Zapoznaj się z obsługą formatu metadanych Twittera.
Nie pomijaj tych formatów danych, jeśli Twoja witryna je obsługuje.
Testowanie w różnych przeglądarkach
Dlaczego? Z perspektywy użytkownika ważne jest, aby na wszystkich przeglądarkach witryna działała w ten sam sposób. Pewne elementy mogą się zmieniać w zależności od wielkości ekranu, jednak strona mobilna powinna zachowywać się identycznie na iPhonie i na telefonie z Androidem, jeśli oba urządzenia mają podobne rozmiary.
Internet może się wydawać podzielony ze względu na różnice w przeglądarkach stosowanych w różnych zakątkach świata. To zróżnicowanie i wynikająca z niego konkurencja sprawiają, że internet jest tak innowacyjną platformą. Na szczęście standardy internetowe są teraz świetnie dopracowane, a nowoczesne narzędzia umożliwiają deweloperom śmiałe tworzenie atrakcyjnych stron, które świetnie działają na różnych przeglądarkach.
Sprawdzone metody:
Stosuj narzędzia do testowania obsługi na różnych przeglądarkach, takie jak BrowserStack.com, Browserling.com czy BrowserShots.org, aby upewnić się, że Twoja aplikacja PWA będzie na nich działać.
Mierzenie wydajności wczytywania stron
Dlaczego? Szybsze wczytywanie witryny to większy komfort użytkownika, który z niej korzysta. Optymalizowanie prędkości wczytywania stron to popularny temat poruszany przez webmasterów. Jednak w trakcie opracowywania nowej wersji witryny kluczowe usprawnienia czasem trafiają na koniec listy rzeczy do zrobienia.
Opracowując aplikację PWA, pamiętaj, aby zmierzyć prędkość wczytywania stron i odpowiednio ją zoptymalizować. Pomoże to zapewnić większą popularność gotowej witryny.
Sprawdzone metody:
Korzystaj z narzędzi takich jak PageSpeed Insights i Web Page Test, aby mierzyć szybkość wczytywania stron witryny. Googlebot cierpliwie czeka na wyrenderowanie strony. Badania wskazują jednak, że 40% użytkowników opuszcza stronę, która wczytuje się dłużej niż 3 sekundy.
Więcej informacji na temat zalecanej prędkości działania witryn oraz kluczowych etapów renderowania znajdziesz tutaj.
Witrynę lepiej jest optymalizować przed jej opublikowaniem. Jeśli treść witryny szybko się wczytuje, to taki sam standard optymalizacji powinna spełniać również Twoja aplikacja PWA.
Wskazówki i informacje zawarte na powyższej liście mogą się przydać, jeśli chcesz zadbać o optymalne indeksowanie swojej aplikacji PWA.
Przystępując do prac nad własną progresywną aplikacją internetowa, przyjrzyj się naszym przykładom aplikacji PWA wykorzystującym renderowanie po stronie klienta, po stronie serwera oraz renderowanie hybrydowe. Jeśli masz jakieś pytania, odwiedź nasze fora dla webmasterów.