Wszystko, co musisz wiedzieć o przyspieszonych stronach mobilnych Google

W maju 2015 r. Facebook zaprezentował nową platformę do publikowania w aplikacji, Instant Articles. Miesiąc później Apple ogłosił, że stare środowisko Kiosku (zasadniczo fantazyjny folder pełen aplikacji z wiadomościami) zostanie zastąpione w iOS 9 przez zupełnie nową platformę do agregacji i odkrywania wiadomości o nazwie Apple News.

Dalsza lektura na temat rozbijania:

• Postrzegana wydajność
• Wstępne ładowanie: do czego to służy?
• Przygotowanie do HTTP/2
• Progresywne ulepszanie
• Progresywne internetowe AMP

Cztery miesiące później przyszła kolej na Google, aby ogłosił swój własny, nieco spóźniony, ale nie mniej ambitny, plan zrewolucjonizowania mobilnego korzystania z wiadomości za pomocą rozwiązania internetowego typu open source o nazwie Accelerated Mobile Pages lub AMP. W ciągu zaledwie kilku miesięcy byliśmy świadkami, jak względny spokój mobilnego wydawnictwa cyfrowego wybuchł, gdy Facebook, Apple, a teraz Google, konkurują zarówno o lojalność wydawców, jak io uwagę czytelników, kolejną pełnowymiarową wojnę platformową.

Chociaż Facebook i Apple mają znaczny start w Google, istnieją wszelkie powody, by sądzić, że AMP szybko nadrobi zaległości (a może nawet przewyższyć jednego lub obu konkurentów). Jeśli jesteś programistą lub wydawcą i chcesz jak najszybciej i jak najskuteczniej dowiedzieć się, dlaczego, co i jak korzystać z przyspieszonych stron mobilnych Google, jesteś we właściwym miejscu.

Ale w czym problem?

Zanim omówimy rozwiązania, warto poświęcić chwilę na zbadanie problemu. Jeśli dużo czytasz na urządzeniach mobilnych, są całkiem spore, że jesteś już zbyt świadomy, że interakcja z treściami internetowymi na telefonie lub tablecie waha się od ledwo akceptowalnych do przerażających. Strony często ładują się wolno, renderują nieregularnie i zachowują się nieprzewidywalnie z dwóch głównych powodów:

• ingerencja osób trzecich . Reklamy i powiązane techniki śledzenia nie tylko dodają masowe i dodatkowe żądania do urządzenia o ograniczonej przepustowości i procesorze, ale strony często zachowują się tak, jakby były opętane, gdy poruszają się wokół wielu wywołań document.write() . New York Times niedawno przeprowadził test, który wykazał znaczne zmniejszenie rozmiarów stron i wydłużenie czasu pracy baterii po zainstalowaniu blokera treści dla systemu iOS.
• szkody uboczne spowodowane responsywnym projektem . Podczas gdy większość responsywnych witryn internetowych wygląda dobrze na ekranach wszystkich rozmiarów, często zawierają one dużo bagażu witryn na komputery, gdy są przeglądane na urządzeniach mobilnych. Kiedy Paul Irish przeprowadził audyt wydajności Reddita, odkrył, że znaczna część kosztów można przypisać zasobowi o nazwie SnooIcon, maskotka Reddita renderowana w SVG, aby można było ją animować (przez bibliotekę innej firmy, co oznacza więcej narzutu) po najechaniu myszą — nie jest to sytuacja, w której zasoby często znajdują się na urządzeniach mobilnych.

Wejdź na Facebook Instant Artykuły, Apple News i Accelerated Mobile Pages — naszych zbawicieli ze świata, w którym według Facebooka (PDF, 3,4 MB) średni czas ładowania artykułu na urządzeniach mobilnych wynosi 8 sekund. Chociaż nazywanie 8 sekund wiecznością jest oczywiście hiperbolą, biorąc pod uwagę, że w tym czasie możesz być dobrze na swoim drugim filmie z Vine, prawdopodobnie można uczciwie powiedzieć, że według dzisiejszych standardów to co najmniej eon.

Krótkie demo artykułów błyskawicznych na Facebooku, Apple News i Accelerated Mobile Pages. Pamiętaj, że artykuły błyskawiczne na Facebooku i wiadomości Apple to doświadczenia w aplikacji, podczas gdy AMP jest całkowicie oparty na przeglądarce.

Czym różni się AMP?

Pewien kontekst tego, w jaki sposób AMP różni się od błyskawicznych artykułów na Facebooku i Apple News, wyjaśni niektóre decyzje podjęte przez Google w związku z nową inicjatywą publikacji cyfrowych.

Artykuły błyskawiczne na Facebooku i Apple News mają kilka wspólnych cech:

• doświadczenia w aplikacji . Czytelnicy uzyskują dostęp do artykułów błyskawicznych na Facebooku za pośrednictwem Facebooka na urządzeniach mobilnych, a Apple News to samodzielna aplikacja dostarczana z systemem iOS 9. Żadna z platform nie pozwala obecnie użytkownikom wyświetlać artykułów w ich określonych formatach poza odpowiednią aplikacją. Pomyśl o obu jako o odświeżeniu RSS dla określonej aplikacji.
• oparte na syndykacji . Chociaż Facebook Instant Article i Apple News używają bardzo różnych formatów syndykacji (Apple News Format jest oparty na JSON, a Instant Article Markup jest mniej więcej HTML opakowany w kanał RSS), są one oparte na podobnych zasadach: Nakłonić swój CMS do generowania niezbędne formaty syndykacji, a Facebook lub Apple News pochłoną je, przeanalizują i sprawią, że będą piękne i szybkie dzięki dostosowanym i zoptymalizowanym rendererom.
• zorientowany na doświadczenie . Chociaż artykuły Facebook Instant i Apple News koncentrują się na wydajności, w równym stopniu dbają o to, aby artykuły wyglądały i były nowoczesne. Obie platformy mają komponenty, które pozwalają na płynną i płynną interakcję, którą zwykle kojarzymy z robionymi na zamówienie, ręcznie tworzonymi doświadczeniami z czytania.

Z kolei przyspieszone strony mobilne skupiają się na:

• doświadczenie internetowe . Dokumenty AMP są przeznaczone do renderowania w przeglądarce lub w WebViews.
• dokumenty atomowe . Chociaż dokumenty AMP są sprawdzane, analizowane i częściowo renderowane przez środowisko wykonawcze AMP (więcej na ten temat poniżej), są one kompletnymi i niezależnymi dokumentami, które znajdują się na Twoim własnym serwerze internetowym (i opcjonalnie w pamięci podręcznej CDN), a nie zbiorach metadane, które w pewnym momencie zostaną przekształcone w artykuły i wyrenderowane w aplikacjach.
• zorientowany na wydajność . AMP dużo bardziej dba o wydajność dokumentów AMP niż o estetykę czy wzorce interakcji. Nie oznacza to, że dokumenty AMP są z natury domowe (mogą być tak samo atrakcyjne jak artykuły na Facebooku czy artykuły Apple News z odpowiednią stylizacją), ale środowisko wykonawcze jest znacznie bardziej skupione na szybkim renderowaniu artykułu niż na dostarczaniu fantazyjnych efektów wizualnych, takich jak szalone, małe, drżące rzeczy.

Czym dokładnie jest AMP?

Dość filozofowania i machania ręką na wysokim poziomie. Przejdźmy do konkretów. Chociaż poruszanie się po artykułach błyskawicznych na Facebooku i wiadomościach Apple jest dość łatwe (są to w zasadzie fantazyjne agregatory wiadomości z niestandardowymi rendererami zbudowanymi na zastrzeżonych formatach syndykacji), AMP jest odstającym. Trochę trudniej to ogarnąć z dwóch powodów:

• Nie ma prostego modelu, z którym można by to porównać. Kiedy RSS był nowy, wszyscy zachwycaliśmy się jego mocą, pisaliśmy niezliczone artykuły i posty na blogach o jego destrukcyjnym potencjale, ogłaszaliśmy, że strona główna jest martwa (po raz kolejny), a potem wszystko o niej zapominaliśmy. Facebook Instant Artykuły i Apple News to zasadniczo ponowne uruchomienie RSS, z wyjątkiem tego, że eliminują wszystkie niedogodności związane ze standardami, a każdy z nich działa tylko w jednej aplikacji.
• AMP nie jest klientem. . Podczas gdy artykuły błyskawiczne na Facebooku, Apple News i AMP mają kilka wspólnych elementów, takich jak zastrzeżone formaty syndykacji i niestandardowe renderery, AMP jako jedyny nie ma dedykowanego klienta (innego niż przeglądarka). Bardziej niż jego bracia, AMP to zestaw specyfikacji, konwencji i technologii, które można łączyć w rozwiązanie, a nie być rozwiązaniem typu end-to-end (od wydawcy do czytelnika) samym w sobie.

Teraz, gdy wiemy, że AMP należy traktować jako zbiór składników, a nie w pełni upieczone ciasto, przyjrzyjmy się, czym są te poszczególne składniki:

• AMP HTML,
• środowisko wykonawcze AMP,
• pamięć podręczna AMP.

AMP HTML

Dokumenty AMP są napisane w HTML, ale nie w dowolnym HTML. Niektóre tagi są zbanowane, podczas gdy wprowadzono kilka nowych (częściowo w celu zastąpienia zbanowanych, a częściowo w celu enkapsulacji interaktywnej funkcjonalności). Możesz myśleć o AMP HTML jako o tym, jak wyglądałby HTML, gdyby został zaprojektowany wyłącznie z myślą o wydajności mobilnej (w przeciwieństwie do wprowadzenia go na całe 14 lat przed wprowadzeniem iPhone'a).

Ponieważ AMP HTML został zaprojektowany z myślą o optymalnej wydajności, aby zrozumieć i docenić jego wartość, musimy zrozumieć problemy, które rozwiązuje. Oto trzy największe rzeczy, które utrudniają ładowanie i renderowanie stron internetowych na urządzeniach mobilnych:

• wielkość ładunku . Responsywne projektowanie stron internetowych dobrze nam służyło, ponieważ pozwala nam zbudować jedną stronę internetową dla każdego urządzenia i ekranu. Ale czasami oznacza to również dostarczanie ładunków wielkości komputera stacjonarnego (HTML, JavaScript, CSS i zasobów) do urządzeń mobilnych o ekstremalnie ograniczonych przepustowościach i procesorach. (Ci, którzy myślą o swoich telefonach jako o małych komputerach stacjonarnych, przypisują sprzętowi mobilnemu zbyt wiele uznania. Twój iPhone 6s ma 2 GB pamięci RAM, podczas gdy Twój laptop prawdopodobnie ma 8 lub 16.)
• ładowanie zasobów . Zasoby nie zawsze są ładowane w optymalnej kolejności, co oznacza, że ​​przepustowość, procesor i pamięć RAM są często dedykowane zasobom, których użytkownicy mogą nigdy nawet nie zobaczyć. Ponadto zasoby często nie deklarują swojej szerokości i wysokości (zwłaszcza gdy są udostępniane przez sieci reklamowe lub wstrzykiwane za pośrednictwem wywołań document.write() ), co nie tylko powoduje zmianę rozmiaru strony, ponieważ wymiary zasobów są określane w leniwy sposób, ale także powoduje niepotrzebne i kosztowne przeliczenia układu. To właśnie powoduje, że strony internetowe skaczą jak goniące laserem kocięta, ponieważ manifestują się bardzo wolno.
• Wykonanie JavaScript . Nie będę tu poruszał tematu wydajności JavaScriptu, ale nowoczesne strony internetowe często nakładają go na megabajty i chociaż może działać bez zauważalnych opóźnień na komputerach stacjonarnych, mobilność to wciąż zupełnie inne środowisko, w którym, jak sądzę wszyscy możemy się zgodzić, że JavaScript najlepiej ograniczyć do minimum.

Biorąc pod uwagę te trzy bariery utrudniające płynne korzystanie z internetu na urządzeniach mobilnych, AMP HTML służy przede wszystkim do trzech celów:

• zachęcać do zwięzłości . Dokumenty AMP nie są responsywnymi wersjami witryn na komputery. Chociaż dokumenty AMP mogą być (i zwykle są) responsywne, są responsywne w kontekście mobilnym. Innymi słowy, zamiast jednej strony działającej absolutnie wszędzie (na komputerze i urządzeniu mobilnym), dokumenty AMP są zaprojektowane specjalnie do pracy na urządzeniach mobilnych.
• kontrolować ładowanie zasobów zewnętrznych . Środowisko wykonawcze AMP kontroluje ładowanie zasobów zewnętrznych, aby zapewnić wysoką wydajność procesu, dzięki czemu treści pojawiają się na ekranach użytkowników tak szybko i inteligentnie, jak to możliwe.
• hermetyzować interaktywną funkcjonalność . Chociaż dokumenty AMP zwykle sprowadzają się do prezentowania czytelnikom prostych doświadczeń związanych z czytaniem, nie oznacza to, że nie mogą być nowoczesne i interaktywne. Środowisko wykonawcze AMP zapewnia hermetyzowaną funkcjonalność dzięki wysoce zoptymalizowanemu JavaScriptowi, dzięki czemu programiści nie ryzykują obniżenia wydajności, pisząc własne.

Tagi AMP HTML

Poniżej znajduje się lista tagów, które są całkowicie zakazane w AMP HTML:

• script To oczywiście duży. Poniżej przedstawię więcej szczegółów na temat pozycji AMP w JavaScript; na razie załóżmy, że jedyne tagi script , które będziesz mieć w dokumentach AMP, to te, które ładują środowisko wykonawcze AMP i opcjonalnie tag dla połączonych danych opartych na JSON.
• base Tag base wydaje się być zabroniony z dużej ostrożności i może trafić na białą listę, jeśli społeczność złoży skargę. (Domyślam się, że nikogo tak naprawdę nie obchodzi.)
• frame and frameset I tak nie do końca dobre wykorzystanie mobilnej nieruchomości, więc dobrze się pozbyć.
• object , param , applet and embed Niestety, dokumenty AMP nie będą zawierać apletów Flash ani Java. (To był sarkazm, na wypadek, gdyby nie był do końca oczywisty.)
• form i elementy input (z wyjątkiem znacznika button ) Obsługa formularzy prawdopodobnie zostanie ostatecznie zaimplementowana jako komponenty hermetyzowane, ponieważ mają ograniczone zastosowanie bez skryptów.

Oto lista tagów, które zastępują swoje odpowiedniki HTML, aby zoptymalizować ładowanie zasobów i wymusić najlepsze praktyki bezpieczeństwa:

• [amp-img](https://www.ampproject.org/docs/reference/amp-img.html) Zastępuje tag img i optymalizuje ładowanie zasobów, biorąc pod uwagę takie czynniki, jak położenie widocznego obszaru, zasoby systemowe i łączność.
• [amp-video](https://www.ampproject.org/docs/reference/amp-video.html) Zastępuje tag video HTML5, aby można było leniwie wczytywać treści wideo (biorąc pod uwagę widoczny obszar).
• [amp-audio](https://www.ampproject.org/docs/reference/extended/amp-audio.html) Zastępuje tag audio HTML5, aby można było leniwie ładować zawartość audio (biorąc pod uwagę widoczny obszar).
• [amp-iframe](https://www.ampproject.org/docs/reference/extended/amp-iframe.html) Tag amp-iframe wymusza najlepsze praktyki bezpieczeństwa, na przykład domyślnie umieszczając treści w piaskownicy i nakładając ograniczenia na gdzie mogą pojawiać się elementy iframe, aby upewnić się, że nie zdominują dokumentu AMP.

Na koniec, oto wszystkie tagi, które AMP HTML wprowadza, aby dodać funkcjonalność lub interaktywność do twoich dokumentów, bez konieczności pisania JavaScript:

• [amp-ad](https://www.ampproject.org/docs/reference/amp-ad.html) Tag amp-ad umożliwia środowisku wykonawczemu AMP zarządzanie ładowaniem reklam tak samo jak wszystkie inne zasoby ładowane zewnętrznie (obecnie , reklamy są ładowane jako ostatnie) i gwarantuje, że kod JavaScript z sieci reklamowych nie może zostać wykonany w nadrzędnym dokumencie AMP ani nie wywołać niepotrzebnych obliczeń układu. (Do widzenia, document.write() !)
• [amp-analytics](https://www.ampproject.org/docs/reference/extended/amp-analytics.html) Ta miniaturowa platforma pakuje dane analityczne i wysyła je do dostawców zewnętrznych. Na dzień dzisiejszy wsparcie AMP pochodzi z Adobe Analytics, Chartbeat, ClickTale, comScore, Google Analytics, Nielsen i Parse.ly.
• [amp-pixel](https://www.ampproject.org/docs/reference/amp-pixel.html) Służy do osadzania sygnałów nawigacyjnych i obsługuje tokeny do wysyłania kilku zmiennych klienta na serwer.
• [amp-carousel](https://www.ampproject.org/docs/reference/extended/amp-carousel.html) Ten zoptymalizowany komponent wyświetla obrazy podrzędne w interaktywnej, poziomej orientacji.
• [amp-lightbox](https://www.ampproject.org/docs/reference/extended/amp-lightbox.html) Pozwala to czytelnikom otwierać obrazy w pełnoekranowym widoku „lightbox”. Obsługuje specyfikację zarówno miniatur, jak i pełnowymiarowych obrazów.
• [amp-anim](https://www.ampproject.org/docs/reference/extended/amp-anim.html) To ładuje animowane GIF-y i zapewnia bardzo potrzebną funkcję zastępczą.
• [amp-font](https://www.ampproject.org/docs/reference/extended/amp-font.html) Ustaw limit czasu ładowania niestandardowych czcionek i określ czcionki zastępcze, jeśli niestandardowe czcionki nie zostaną załadowane w wyznaczonym czasie .
• [amp-fit-text](https://www.ampproject.org/docs/reference/extended/amp-fit-text.html) Tekstowi w tagu amp-fit-text zostanie automatycznie przypisany rozmiar czcionki zoptymalizowany pod kątem dostępnej przestrzeni. Pomyśl o tym jako o trochę gotowej reakcji.
• [amp-list](https://www.ampproject.org/docs/reference/extended/amp-list.html) Dzięki amp-list możesz wczytać dynamiczne, powtarzające się dane JSON, a następnie wyrenderować je za pomocą kodu HTML szablon. (Patrz etykieta amp-mustache poniżej).
• [amp-mustache](https://www.ampproject.org/docs/reference/extended/amp-mustache.html) Obsługuje renderowanie szablonów HTML Mustache.
• [amp-install-serviceworker](https://www.ampproject.org/docs/reference/extended/amp-install-serviceworker.html) Jeśli zdecydujesz się nie używać pamięci podręcznej AMP (znacznie więcej o pamięci podręcznej poniżej), tag amp-install-serviceworker ładuje i instaluje usługę Service Worker dla bieżącej strony. Serwisanci są sprytni, ale moim zdaniem trochę za wcześnie, żeby na nich polegać.
• [amp-youtube](https://www.ampproject.org/docs/reference/extended/amp-youtube.html) Zgodnie z przewidywaniami, film z YouTube jest umieszczany z określonym identyfikatorem filmu.
• [amp-twitter](https://www.ampproject.org/docs/reference/extended/amp-twitter.html) Osadzaj tweety (karty Twittera są opcjonalne).
• [amp-instagram](https://www.ampproject.org/docs/reference/extended/amp-instagram.html) Osadź obrazy z Instagrama.
• [amp-brightcove](https://www.ampproject.org/docs/reference/extended/amp-brightcove.html) Ten komponent ładuje i wyświetla filmy (i odtwarzacz wideo) z Brightcove.
• [amp-pinterest](https://www.ampproject.org/docs/reference/extended/amp-pinterest.html) Umieść widżet Pinteresta lub przycisk „Przypnij” w dokumencie AMP.
• [amp-vine](https://www.ampproject.org/docs/reference/extended/amp-vine.html) Umieść określony film Vine w swoim dokumencie AMP.

Zauważ, że chociaż znaczniki amp- nie są dokładnie standardowym kodem HTML, nie są również zastrzeżone. Są to raczej legalne elementy niestandardowe z implementacjami JavaScript, które wykonują takie czynności, jak egzekwowanie najlepszych praktyk bezpieczeństwa i nadawanie priorytetu ładowaniu zasobów zdalnych (więcej na ten temat w sekcji „Środowisko wykonawcze AMP” poniżej). Innymi słowy, chociaż AMP HTML może podejrzanie przypominać strategię objęcia, rozszerzenia i wygaszenia, tak naprawdę jest to tylko sprytne zastosowanie standardów internetowych i niewiele różni się od niestandardowych atrybutów data- .

Stylizacja AMP HTML

Stylizacja dokumentów AMP odbywa się za pomocą standardowego CSS i nie różni się zbytnio od tego, jak już stylizujesz treść. Pamiętaj jednak o kilku rzeczach:

• Wszystkie style muszą być wykonane za pomocą wbudowanego arkusza stylów — bez zewnętrznie połączonych arkuszy stylów i bez wbudowanych stylów na poziomie elementu. (Zewnętrznie połączony arkusz stylów wymagałby pobrania dodatkowego dokumentu przed obliczeniem układu, a wbudowane style na poziomie elementu mogłyby nadwyrężyć dokument).
• Style są ograniczone do 50 KB. Filozofia Google jest taka, że ​​50 KB wystarczy na ładny dokument lub artykuł, ale nie wystarczy na ładną stronę internetową.
• Twój wbudowany arkusz stylów musi mieć atrybut amp-custom (tj. <style amp-custom> ).
• Zasady @ — @font-face (więcej o czcionkach poniżej), @keyframes i @media — są dozwolone.
• Niektóre selektory mają ograniczenia, o których wiadomo, że utrudniają wydajność, takie jak selektor uniwersalny ( * ) i selektor :not() .
• Kwalifikator !important jest zabroniony, aby zapewnić, że środowisko wykonawcze AMP ma ostatnie słowo dotyczące rozmiaru elementu.
• Stylizacja niestandardowych komponentów AMP, takich jak amp-carousel , polega na zastąpieniu klas domyślnych, takich jak .amp-carousel-button-prev , lub przy użyciu predefiniowanego zestawu niestandardowych właściwości CSS, takich jak --arrow-color .
• Wszystkie ładowane zewnętrznie zasoby muszą mieć określone właściwości szerokości, wysokości i układu (więcej o układzie poniżej), aby zminimalizować kosztowne ponowne obliczenia układu DOM.
• Dozwolone są przejścia i animacje, które mogą być akcelerowane przez GPU (i które nie wywołują ponownych obliczeń). Obecnie opacity i transform znajdują się na białej liście.

Więcej informacji o stylizacji dokumentów znajdziesz w specyfikacji AMP HTML.

Czcionki

AMP szczęśliwie obsługuje niestandardowe czcionki, z kilkoma kwalifikacjami:

• Czcionki muszą być załadowane tagiem linku lub regułą CSS @font-face . Innymi słowy, nie możesz ładować czcionek za pomocą JavaScript.
• Wszystkie czcionki muszą być obsługiwane przez HTTPS.
• Dostawcy czcionek muszą znajdować się na białej liście. Obecnie jedynymi dostawcami na białej liście są fonts.googleapis.com i fast.fonts.net . Ale biorąc pod uwagę, jak szybko wydawcy, reklamodawcy i dostawcy analiz dodają obsługę AMP, podejrzewam, że wkrótce pojawi się więcej.

Układ

Podejście AMP do układu zostało stworzone wokół dwóch głównych celów:

• Środowisko wykonawcze musi być w stanie wywnioskować rozmiar wszystkich ładowanych zewnętrznie zasobów przed ich faktycznym załadowaniem, aby ostateczny układ można było obliczyć tak szybko, jak to możliwe. Po obliczeniu układu artykuł można wyrenderować, a czytelnicy mogą rozpocząć interakcję z nim, nawet jeśli reklamy, obrazy, dźwięki i wideo nie zostały jeszcze wczytane. (A gdy te zasoby się ładują, będą renderować się płynnie, bez zakłócania czytania poprzez aktualizację układu dokumentu).
• Artykuły AMP powinny być responsywne. Jak sugeruje nazwa „Przyspieszone strony mobilne”, dokumenty AMP są specjalnie przeznaczone dla urządzeń mobilnych; więc w tym kontekście „responsywny” nie obejmuje rozdzielczości pulpitu. Dokumenty AMP powinny raczej wyglądać dobrze na wszystkich urządzeniach mobilnych, od tych małych starych reliktów iPhone'a 4, których ludzie wciąż używają, aż po stosunkowo gigantyczne iPady Pro.

Pierwszy cel jest osiągany przede wszystkim przez wymaganie, aby wszystkie zewnętrznie ładowane zasoby miały atrybuty width i height (i jest to dodatkowo wymuszane przez ograniczające skrypty, co zapewnia, że ​​nowych zasobów nie będzie można podkuć). Ten ostatni jest osiągany za pomocą standardowych zapytań o media , atrybutu media, atrybutu sizes i atrybutu layout specyficznego dla AMP.

Poniżej znajduje się przegląd układów aktualnie obsługiwanych przez AMP:

• nodisplay Element nie jest początkowo wyświetlany, ale wyświetlanie może zostać wywołane przez akcję użytkownika. (Jest używany w połączeniu z komponentami, takimi jak amp-lightbox .)
• fixed Element ma ustaloną szerokość i wysokość, co oznacza, że ​​środowisko wykonawcze nie może zastosować żadnego zachowania responsywnego.
• responsive Moim zdaniem jest to najbardziej użyteczna i magiczna z opcji układu AMP. Element wykorzystuje przydzieloną przestrzeń, zachowując proporcje. (Zasadniczo: „Spraw, aby ta rzecz wyglądała dobrze w każdym rozwiązaniu, proszę i dziękuję”).
• fixed-height Element wykorzystuje przydzieloną przestrzeń, ale zachowuje stałą wysokość (skalowanie w poziomie).
• fill Element wypełnia pojemnik, w którym się znajduje, bez względu na proporcje. (Pomyśl width: 100% i height: 100% .)
• container Element jest kontenerem i dlatego pozwala swoim dzieciom (w przeciwieństwie do rodzica) określić swój rozmiar, dokładnie tak jak standardowy element div .

Osiągnięcie funkcjonalnego i prostego układu dokumentu za pomocą systemu układu AMP jest stosunkowo łatwe, ale biorąc pod uwagę wszystko, co obsługuje i sposób, w jaki wartości odnoszą się do różnych typów elementów, jest sporo niuansów. Bardziej szczegółowy podział znajdziesz w specyfikacji układu AMP.

A co z SVG?

Utrzymany! Podstawowe SVG cieszy się kompleksową obsługą zarówno w przeglądarkach stacjonarnych, jak i mobilnych, a grafika nie jest znacznie bardziej responsywna niż wektory, więc AMP i SVG tworzą bardzo dobry zespół. Największym ograniczeniem jest to, że ze względu na ograniczenia dotyczące skryptów nie będziesz w stanie animować wektorów za pomocą JavaScript — czego, szczerze mówiąc, prawdopodobnie nie powinieneś robić na urządzeniach mobilnych. Jeśli jednak naprawdę musisz tchnąć trochę życia w swój SVG, nadal możesz to zrobić za pomocą animacji CSS, zgodnie z tymi samymi ograniczeniami, które opisano w sekcji dotyczącej stylów powyżej. Pamiętaj, że SVG jest częścią DOM, więc można go stylizować — i animować — równie łatwo, jak każdy inny element.

Filozofia AMP dotycząca JavaScript

Tutaj dobre i złe wieści. Zła wiadomość jest taka, że ​​w najbliższym czasie nie będziesz pisać żadnego JavaScriptu dla swoich dokumentów AMP. Ale w pewnym sensie to także dobra wiadomość. Pamiętaj, że AMP nie jest frameworkiem aplikacji mobilnych. Jest to raczej struktura artykułów mobilnych, a ponieważ artykuły powinny być zoptymalizowane pod kątem bezproblemowego i płynnego czytania, tak naprawdę nie ma wielu dobrych przypadków użycia dla ciężkich skryptów po stronie klienta.

Biorąc to pod uwagę, zablokowanie całego JavaScriptu na zawsze jest zarówno nierealne, jak i trochę drakońskie. W rzeczywistości sieć od pewnego czasu polega na JavaScript — nawet w kontekście prostych i stosunkowo nijakich doświadczeń związanych z czytaniem — w przypadku reklam, analiz i funkcji interaktywnych. Dodatkowo jedną z najlepszych rzeczy w sieci jest jej otwartość i pozornie nieskończona zdolność do eksperymentowania, ekspresyjności i kreatywności — z których wiele jest zasilanych przez JavaScript.

Uznając ciężar, jaki arbitralny, napisany przez użytkownika JavaScript nakłada na gwarancje wydajności, a także wszechobecność i nieuchronność JavaScript w nowoczesnym środowisku internetowym, zespół AMP opracował następujące zasady tworzenia skryptów:

• Obecnie żaden skrypt JavaScript pisany przez użytkownika nie jest obsługiwany ani dozwolony. W dokumentach AMP możesz mieć tylko dwa typy tagów skryptu: połączone tagi danych (którego typ to application/ld+json ) oraz tagi zawierające zarówno środowisko wykonawcze AMP, jak i rozszerzone komponenty AMP.
• Autorzy projektu AMP przewidzieli większość potrzeb JavaScript w kontekście konsumpcji artykułów mobilnych, więc AMP albo obsługuje alternatywy ( amp-pixel , w tym niestandardowe czcionki z tagami linków lub regułami @font-face itp.) lub dostarcza implementacje, które są kompatybilne ze środowiskiem wykonawczym AMP, a zatem gwarantują zarówno bezpieczeństwo, jak i wydajność ( amp-ad , amp-analytics , amp-carousel itp.).
• Jeśli naprawdę musisz używać JavaScript do czegoś takiego jak funkcja interaktywna, możesz utworzyć tę funkcję niezależnie, a następnie dołączyć ją do [amp-iframe](https://www.ampproject.org/docs/reference/extended/amp-iframe.html) . Treści zawarte w amp-iframe mają nawet ograniczoną komunikację z dokumentem nadrzędnym, np. w przypadku żądań zmiany rozmiaru.
• Komponenty AMP są open source (Apache 2) i są otwarte na wkłady, więc z czasem pojawią się nowe komponenty (w rzeczywistości kilka nowych komponentów pojawiło się w trakcie pisania i edytowania tego artykułu, więc już kilka razy aktualizowałem). Chociaż zespół AMP nada priorytet uogólnionym komponentom nad funkcjonalnością specyficzną dla usługi (na przykład widżet specjalnie dla Twojego startupu społecznościowego), jest również zaangażowany w zapewnienie wystarczającej różnorodności, aby pomieścić jak najszerszy zakres treści.
• Wreszcie, wszystkie te zasady mogą ulec zmianie. W miarę jak funkcje przeglądarki, takie jak pracownicy sieciowi, elementy niestandardowe i shadow DOM stają się coraz szerzej obsługiwane, opcje obsługi pisanego przez użytkownika JavaScript i niestandardowych komponentów — przy jednoczesnym zapewnieniu bezpieczeństwa i wydajności — znacznie się rozszerzą.

Więcej informacji na temat przyszłości komponentów AMP można znaleźć w sekcji „Rozszerzone komponenty” specyfikacji „Składniki AMP HTML”.

Anatomia dokumentu AMP

Teraz, gdy masz dość solidną wiedzę na temat AMP HTML, podzielmy schemat.

Oczywiście dokumenty AMP zaczniesz od deklaracji typu doctype :

 <!doctype html>

Następnie oznacz swój dokument HTML jako AMP HTML, co, wierz lub nie, używasz emoji wysokiego napięcia jako atrybutu w tagu html :

 <html >

Lub, jeśli jesteś staromodnym zrzędą i najeżysz się na pomysł ozdobienia swojego kodu uroczymi emotikonami, możesz zamiast tego użyć znacznie bardziej konserwatywnego atrybutu amp :

 <html amp> <!-- A good sign that you're boring! -->

W tagu head nie zapomnij o instrukcji kodowania znaków utf-8 :

 <meta charset="utf-8">

I link do wersji dokumentu innej niż AMP (oznaczonej jako canonical , aby nie pojawiała się jako zduplikowana treść):

 <link rel="canonical" href="my-non-amp-index.html">

I odwrotnie, Twoja wersja inna niż AMP powinna zawierać odniesienie do dokumentu AMPlified:

 <link rel="amphtml" href="my-amp-index.html">

Ponieważ strony AMP są przeznaczone dla urządzeń mobilnych (i chcesz również rasteryzacji GPU), pamiętaj o dołączeniu metatagu viewport obszaru:

 <meta name="viewport" content="width=device-width,minimum-scale=1,initial-scale=1">

Następna linia kodu będzie wydawać się trochę dziwna, a to dlatego, że tak jest. Wiesz, jak czasami widzisz, że strona internetowa krótko renderuje tekst, zanim czcionki zostaną załadowane i zastosowane, a następnie migoczą i ponownie wyglądają tak, jak zamierzył projektant? Poniższy tag utrzymuje przezroczystość strony na poziomie 0 (niewidocznym), dopóki nie zostanie odpowiednio stylizowany.

 <style> body { opacity: 0 } </style> <noscript> <style> body { opacity: 1 } </style> </noscript>

Problem z tym podejściem polega na tym, że jeśli środowisko wykonawcze AMP nie zostanie załadowane, technicznie możliwe jest, że przezroczystość strony nigdy nie zmieni się z 0 na 1 . Aby zrekompensować takie nieprzewidziane okoliczności, powyższy kod zostanie prawdopodobnie zmieniony na coś bliższego temu:

 <style> body { animation: amp-timeout 0x 5s 1 normal forwards; } @keyframes amp-timeout { 0% {opacity: 0;} 100% {opacity: 1;} } </style>

Następną rzeczą do zrobienia jest włączenie środowiska wykonawczego AMP JavaScript:

 <script async src="https://cdn.ampproject.org/v0.js"></script>

I dołącz implementacje JavaScript dla dowolnych rozszerzonych komponentów, których potrzebujesz:

 <script async custom-element="amp-youtube" src="https://cdn.ampproject.org/v0/amp-youtube-0.1.js"></script> <script async custom-element="amp-audio" src="https://cdn.ampproject.org/v0/amp-audio-0.1.js"></script> <script async custom-element="amp-carousel" src="https://cdn.ampproject.org/v0/amp-carousel-0.1.js"></script> <script async custom-element="amp-lightbox" src="https://cdn.ampproject.org/v0/amp-lightbox-0.1.js"></script> <script async custom-element="amp-anim" src="https://cdn.ampproject.org/v0/amp-anim-0.1.js"></script> <script async custom-element="amp-twitter" src="https://cdn.ampproject.org/v0/amp-twitter-0.1.js"></script> <!-- etc. -->

(Zwróć uwagę na użycie atrybutu async . Nie jest to opcjonalne — im mniej blokowania, tym lepiej).

Opcjonalnie możesz dodać trochę połączonych danych, tak jak poniżej:

 <script type="application/ld+json"> { "@context": "https://schema.org", "@type": "NewsArticle", "headline": "Turn Your AMP up to 11!", "image": [ "img/cover-opt.jpg" ], "datePublished": "2015-01-11T08:00:00+08:00" } </script>

Teraz dodajmy kilka czcionek, używając tagów link lub reguł @font-face w CSS:

 <link href='https://fonts.googleapis.com/css?family=Roboto+Condensed:300,700' rel='stylesheet' type='text/css'> <link href='https://fonts.googleapis.com/css?family=Lora:400,700,400italic,700italic' rel='stylesheet' type='text/css'>

A potem kilka stylów (o wartości nie większej niż 50 KB), z wymaganym atrybutem amp-custom :

 <style amp-custom>

Możesz teraz utworzyć mniej lub bardziej standardowy dokument HTML, korzystając ze wszystkiego, czego właśnie nauczyłeś się o AMP HTML.

Środowisko wykonawcze AMP

Nie będę spędzał dużo czasu na środowisku uruchomieniowym AMP, ponieważ, jak wszystkie środowiska uruchomieniowe, jest to trochę czarna skrzynka. Nie oznacza to, że środowisko wykonawcze AMP jest niedostępne (jest to oprogramowanie typu open source, podobnie jak reszta projektu). Raczej, jak w przypadku wszystkich dobrych środowisk wykonawczych, programiści nie muszą dokładnie wiedzieć, jak to działa, aby z niego skorzystać, o ile ogólnie rozumieją, co robi.

Środowisko wykonawcze AMP jest w całości zaimplementowane w języku JavaScript i jest inicjowane przez uwzględnienie go w dokumencie AMP, tak jak każdy zewnętrzny plik JavaScript:

 <script async src="https://cdn.ampproject.org/v0.js"></script>

Od tego momentu środowisko wykonawcze AMP robi przede wszystkim trzy rzeczy:

• zarządza ładowaniem i priorytetyzacją zasobów,
• wdraża komponenty AMP,
• opcjonalnie zawiera walidator środowiska wykonawczego dla AMP HTML.

Walidator ma kluczowe znaczenie dla tworzenia dokumentów zgodnych z AMP. Można go włączyć po prostu dodając #development=1 do adresu URL dokumentu. Następnie wszystko, co musisz zrobić, to otworzyć konsolę, aby zobaczyć swoją kartę raportu.

Błędy wyglądają tak:

Ładny, przejrzysty i zgodny dokument AMP wygląda mniej więcej tak:

(Opcjonalna) pamięć podręczna AMP

Dokumenty AMP mogą być udostępniane z serwera internetowego, tak jak każdy inny dokument HTML, ale można je również wyświetlać ze specjalnej pamięci podręcznej AMP. Opcjonalna pamięć podręczna wykorzystuje kilka technik, aby jeszcze bardziej zoptymalizować dokument AMP:

• Odniesienia do obrazów można zastąpić obrazami o rozmiarze dostosowanym do widoku użytkownika.
• Obrazy w części strony widocznej na ekranie mogą być wstawiane, aby zapisać dodatkowe żądania HTTP.
• Zmienne CSS mogą być wbudowane, aby zmniejszyć obciążenie po stronie klienta.
• Rozszerzone implementacje komponentów AMP można wstępnie wczytać.
• HTML i CSS można zminimalizować, aby zmniejszyć liczbę bajtów przesyłanych przez przewód (lub w tym przypadku fale radiowe).

Każdy może uruchomić własną pamięć podręczną AMP we własnym CDN lub wydawcy mogą korzystać z Google za darmo. Biorąc pod uwagę, że Google wydaje się wiedzieć co nieco o skalowalności, domyślam się, że większość użytkowników AMP chętnie skorzysta z tej oferty. (Documentation on how to opt in to Google's cache is forthcoming, but given that Google already indexes and caches the Internet, it's a safe bet that it will revolve around your link tags and perhaps an additional meta tag.)

How Do Readers Find AMP Content?

The fact that AMP document are more or less standard HTML that will render in any modern browser is, in my opinion, a huge advantage (AMP is far more open and inclusive than Facebook Instant Articles or Apple News). But from a practical perspective, it also raises the question of how audiences will find AMP content.

If readers use Google to search from a mobile device, Google can link directly to AMP versions of articles (Google has not said that it will prioritize AMP documents over non-AMP documents, but it has said that it will use “mobile friendliness” as a mobile search signal, so you do the math). In fact, Google has indicated that it will begin sending traffic to AMP pages from Google Search on mobile as early as late February 2016. Discovery and curation engines such as Pinterest may also choose to start directing mobile traffic to AMP pages (with a few infrastructure changes). Finally, websites can redirect their own mobile traffic from responsive versions of articles to their AMP counterparts. But from my perspective, a few pieces of the puzzle are still missing.

Will other search engines direct mobile traffic to AMP articles? (Perhaps not search engines that want to do business with Apple.) Will social networking apps preload AMP documents when users post links to articles, in order to make rendering nearly instantaneous? (Probably not Facebook.) Will mobile browsers start looking for link tags with amphtml relationships? (Chrome, maybe, but probably not mobile Safari.) And will aggregators and news readers out there build specifically for lightning-fast AMP content? (Time to resurrect Google Reader!)

At this point, the answers to most of these questions are the same: to be determined.

See AMP In Action

The easiest way to see AMP in action is to check out Google's search demo. If you're the trusting type, you can watch the video and just assume it all works as well as it's depicted. If you're more the trust-but-verify type, you can go to g.co/ampdemo on your mobile device and try out some AMP pages for yourself (QR code below).

You can also check out the AMP experience through desktop Chrome using Chrome's Developer Tools. All you have to do is this:

1. Go to g.co/ampdemo in Chrome.
2. Open the Developer Tools by going to “View” → “Developer” → “Developer Tools.”
3. Go into device mode by clicking on the little phone icon in the top-left corner.
4. Pick your favorite device to emulate. (For best results, reload the page in the emulator.)

Who's Adopting AMP?

It's still relatively early days for AMP, so it's hard to tell exactly who is adopting the new format in earnest, and to what extent. That being said, I've already seen several implementations out there in the wild, and according to the AMP FAQ and AMP blog, it's being taken seriously by many major publishers (metered content and subscription access is currently under review), CMS developers, advertisers, and analytics providers. I won't list them all here because I'm sure the landscape will change almost daily, but you can keep an eye on the AMP project's home page and/or the AMP blog for news.

What Do I Think?

I'm glad you asked. My guess is that just about all publishers will eventually adopt it. If companies like BuzzFeed have taught the industry anything, it's the importance of being in as many places as possible, and that digital publishing should be a technology platform capable of getting content in front of readers wherever they are, as opposed to being a singular destination waiting for readers to come to it.

The investment required to support AMP is also relatively minimal. If a publisher already supports — or plans to support — Facebook Instant Articles and Apple News, then they might as well implement support for AMP as well. While CMS strategies vary widely across the publishing industry, most CMS' have a concept of templates and/or plugins that, once implemented, would do most of the work of converting articles into AMP HTML. (WordPress, the closest thing we have to an industry leader, already has a plugin and plans on supporting AMP for all publishers in January 2016.) And because AMP is far less proprietary than its competition (meaning that it is open source, open to contributions, based on web technologies and client-agnostic), I would expect publishers to feel more comfortable distributing their content in a format that they feel they will have more control over long-term.

The reality is that publishers will back whatever syndication formats and partners will help get their content in front of the maximum number of readers with the least amount of overhead and investment. Right now, we are in the very early stages of a new type of war that is part platform, part format and in which each party will leverage its unique strengths to maneuver itself into the best possible position. At this point, it's far too early to say which will endure and which will become the RSS of tomorrow.

Dodatkowe zasoby

• “Introducing the Accelerated Mobile Pages Project, for a Faster, Open Mobile Web” Google Official Blog
• Accelerated Mobile Pages Project, official website
• Accelerated Mobile Pages, blog
• AMP HTML, GitHub
• Docs, Accelerated Mobile Pages Project
• Nigel Tufnel explaining why his amp goes to 11