Nadchodzi AMP HTML ⚡


Wielkimi krokami zbliża się dzień, w którym na ranking organiczny będzie wpływać kolejny element, czyli serwowanie treści witryny w AMP HTML. Póki co Google nie ujawnia liczb na temat adopcji tego nowego, otwartego standardu, ale podobno podoba się im kierunek, w którym zmierza. Tak czy siak warto wiedzieć kto zacz ten cały HTML ⚡ - zapraszam do lektury.

Co to jest AMP HTML?

AMP HTML to odchudzona wersja zwykłego HTML. Specyfikacja bardzo ściśle wykrawa tylko określone znaczniki, z których można korzystać tworząc AMPowe dokumenty. W ujęciu całościowym, AMP składa się z trzech zasadniczych części:

  • AMP HMTL
  • AMP JS
  • AMP CDN

Najprostszy dokument wygląda tak:

<!doctype html>
<html >
 <head>
   <meta charset="utf-8">
   <link rel="canonical" href="hello-world.html">
   <meta name="viewport" content="width=device-width,minimum-scale=1,initial-scale=1">
   <style>body {opacity: 0}</style><noscript><style>body {opacity: 1}</style></noscript>
   <script async src="https://cdn.ampproject.org/v0.js"></script>
 </head>
 <body>Hello World!</body>
</html>

Natomiast gdyby ktoś chciał zobaczyć jak to się sprawuje wdrożone na dużym serwisie - można odwiedzić Guardiana i do jakiegokolwiek linku dopisać /amp, na przykład:

AMPowe tagi HTML napędzane są przez bibliotekę AMP JS, która implementuje wszystkie najlepsze praktyki odnośnie efektywności. Tak przynajmniej twierdzą twórcy, jako główny argument podając wczytywanie asynchroniczne, czyli nie blokujące/opóźniające renderowania się elementów dokumentu.

Ostatnim kawałkiem układanki jest dedykowany CDN. Pobiera AMPowy content i proxuje go, czyniąc tym samym szybszym do pobierania. Tutaj twórcy standardu uwypuklają obecność HTTP/2 dla maksymalizacji szybkości ładowania się zasobów.

Skąd AMP HMTL się wziął?

Jak nie wiadomo o co chodzi, to chodzi o pieniądze, prawda? Oficjalnie, FAQ projektu mówi:

What are the benefits of Accelerated Mobile Pages?

Speed matters and instant is the ideal. Research shows that the bounce rate can be as high as 58% for web pages that take nearly ten seconds to load. Using the AMP format will make it far more compelling for people to consume and engage with more content. But this isn’t just about speed and performance. We also want to promote enhanced distribution so that publishers can take advantage of the open web’s potential for their content to appear everywhere quickly – across all platforms and apps – which can lead to more revenue via ads and subscriptions.

Zatem: szybkość i komfort użytkownika co przyniesie więcej zysków z reklam i subskrybcji. Niby fajnie brzmi. W istocie jednak Google chce tu osiągnąć przynajmniej dwa cele.

Po pierwsze - zabezpieczyć się na froncie walki z Facebookiem i Apple - obie te organizacje lansują swoje własne formaty, oferujące w gruncie rzeczy mniej więcej to samo, aczkolwiek z zupełnie innych pobudek.

Po drugie - zrobić porządek z niewyobrażalnym bajzlem, jaki branża wydawców internetowych do spółki z branżą reklamy nam wszystkim zafundowała. Strony dużych serwisów są ohydne. Efektem tego malowniczego stanu rzeczy jest oczywiście blokowanie reklam. Częstokroć bez adbloka stron dużych witryn po prostu nie da przeglądać przy jakimkolwiek zakresie komfortu.

Jak to wdrożyć?

Szansę wdrożenia HTML ⚡ ma praktycznie każdy, kto posiada witrynę internetową. Już teraz dostępne są wtyczki tworzące odpowiednie wersje stron dla CMSów takich jak WordPress, Drupal czy nawet Jekyll. Platformy działające w chmurze, typu Blogger czy Medium, zapewne dołożą wparcie niebawem. Duzi wydawcy, operujący na dedykowanych systemach, będą musieli sobie dopisać taką funkcjonalność samodzielnie, jak wzmiankowany wcześniej Guardian.

Dlaczego?

Na AMPie i jego szerokiej adopcji skorzysta najbardziej oczywiście Google ze swoimi reklamami i ewentualnie użytkownicy końcowi. Wydawcy moim zdaniem skazani są na stratę. Kolejną.

Monopoly is just a game

Dla Google to no brainer - Facebook rozpycha się cały czas i wie, że żeby trzymać użytkowników w swojej piaskownicy przydałoby się coś więcej niż seria statusów z informacjami co tam u kota znajomego czy kolejnymi zdjęciami kubka kawy. Stąd inicjatywy takie jak Instant Articles czy niedawny Sports Stadium.

Monopoly is just a game, senator. I’m trying to control the fucking world. — Robin Williams jako Bill Gates

Tworząc otwarty standard, który tak naprawdę nie jest niczym innym jak forkiem języka HTML, Google dzieli i rządzi co będzie w owym standardzie działać. Przykład? Z AMPa na twardo wycięty jest cały JS oprócz biblioteki pobłogosławionej przez Google, nie ma zbyt wielu tagów HTML, a wsparcie dla CSS jest ograniczone.

Kiedy jeszcze dinozaury chodziły po ziemi, w sieci można było spotkać witryny posiadające w stopkach obrazki z napisem best viewed in Internet Explorer - #truestorybro, tak było. Internet od dwóch dekad walczy z zapędami dużych firm technologicznych, które mniej lub bardziej starały się, aby wszystko ogólnie dostępne najlepiej działało w ramach ich własnych produktów.

Teraz Google robi to samo, zmuszając wydawców do publikowania jednej wersji witryny dla póki co jeszcze normalnego internetu i drugiej, dla stworzonego sztucznie mikrokosmosu AMP HTML.

Wzmiankowany wcześniej Microsoft miał lewarek w postaci umów korporacyjnych i preinstalowania IE na takich systemach - trudno jednak było to utrzymać na komputerach prywatnych użytkowników. Google jednak ma lewar bardziej bolesny - swój własny indeks.

Oczywiście posiadanie AMPowych wersji stron nie musi być warunkiem do rankowania się - znając Google zapewne nie będzie to powiedziane wprost w taki sposób. Ale od dawna słyszymy już o szybkości jako o bardzo ważnym elemencie, więc połączcie sobie kropki samodzielnie.

Wydawcy zostaną raczej w sytuacji bez wyjścia, bo użytkownikom będzie wszystko jedno że ich nie ma - jak mieliby się upomnieć i pomyśleć głupie Google nie działa, skoro nie uświadomią sobie że jakiegoś contentu brakuje w wynikach bo po prostu nie wiedzą o jego istnieniu?

Z tej perspektywy AMP HTML to nic innego jak:

Indeks Google i mobile

Strony AMPowe mają się zacząć pokazywać w indeksie już w lutym tego roku. To znaczy, że dojdzie do zmiany w sposobie działania stron z wynikami wyszukiwania, szczególnie w ujęciu wyników na urządzeniach mobilnych. To właśnie nacisk na szybkość w mobile jest jednym z głównych argumentów dla tej propozycji.

Oczywiście trochę racji w tym jest - nie wszystkie serwisy są zrobione jak należy, ale twierdzenie, że mamy problem z szybkością na mobile jest wyssane z palca. Świetnie rozłożył ten konkretny aspekt Thomas Baekdal w swojej analizie AMP HTML. Dla zilustrowania dwa video z jego tekstu.

Na pierwszym widać ładowanie się jego witryny przy korzystaniu z normalnej przeglądarki na starszym modelu iPada. Na drugim dokładnie to samo, z tą różnicą, że źródłem wejścia jest aplikacja Facebooka. Różnica w szybkości ładowania jest drastyczna ale nie wynika z szybkości witryny czy połączenia. Problem tkwi w sposobie działania mobilnych systemów operacyjnych.

Google próbuje zaadresować ten problem udostępniając w Androidzie Chrome custom tabs w wersji Chrome 45:

Crepe

Jak widać jest więc inna droga. Gdyby dodać do tego jakieś otrzeźwienie wśród wydawców internetowych w zakresie projektowania witryn i agencji reklamowych/domów mediowych w kwestii jak wyglądają reklamy (które moim zdaniem powinno brać się z wypracowywania dobrych praktyk tudzież standardów przez takie organizacje jak rozdzierająca szaty nad adblokami IAB) to moglibyśmy mieć zarówno szybkość na mobile jak i jeden standard tworzenia witryn w duchu prawdziwie otwartego internetu.

Póki co czeka nas wzmiankowany fork HTMLa, za którym czai się maczuga wdrożenia i dostosowania kontra po prostu istnienie w SERPach - przynajmniej dla wydawców treści zarabiających na reklamach. Google rozgrywa to pięknie - schema dla wszystkich, budowanie knowledge graph na własne potrzeby i teraz AMP dla wydawców żeby pozyskać ich content jako strukturyzowany towar, dokładnie tak samo opakowany, gotowy do wykorzystania według własnego uznania. Bardzo, bardzo chciałbym się mylić.