Optymalizacja hostowanych stron AMP
Important: this documentation is not applicable to your currently selected format email!
Ten przewodnik zawiera porady i wskazówki dla webmasterów dotyczące optymalizowania stron AMP.
Czy AMP nie jest domyślnie szybki?
Środowisko uruchomieniowe AMP jest zoptymalizowane pod względem szybkości, jeśli więc strony AMP są serwowane przez serwer buforujący AMP, są one w pełni zoptymalizowane i oferują najwyższą wydajność ładowania. Na przykład, jeśli użytkownicy przechodzą do stron AMP z wyszukiwarki Google na telefonie komórkowym, domyślnie strony są serwowane przez serwer buforujący AMP.
Strony AMP nie zawsze jednak są serwowane z serwera buforującego AMP. Witryna może zdecydować się na wyświetlanie innym źródłom ruchu stron AMP z własnych serwerów. Najczęstszym przypadkiem użycia są strony utworzone w całości z AMP, takie jak tasty.co, gdzie użytkownicy przechodzą bezpośrednio do witryny. Innym źródłem ruchu jest Twitter, który zaczął tworzyć linki do stron AMP, zamiast dostarczać standardową wersję mobilną. To znaczy, że jeśli użytkownik kliknie link w jednej z aplikacji mobilnych Twittera, link spowoduje przejście do wersji AMP Twojej strony w Twoim własnym źródle (jeśli jest dostępna).
W związku z tym nie zawsze można mieć pewność, że strony AMP są serwowane tylko z serwera buforującego AMP. W przypadkach, gdy strony AMP są serwowane z własnych serwerów ważne jest, aby upewnić się, że strony AMP oferują optymalną wydajność ładowania.
Domyślnie strony AMP są ładowane szybko, ale jest kilka dodatkowych optymalizacji wydajności, które można zaimplementować, aby pomóc przeglądarce ładować strony AMP jeszcze szybciej. Ten przewodnik opisuje kilka optymalizacji, które warto wziąć pod uwagę w razie publikowania stron AMP. Zanim jednak zaczniesz czytać ten przewodnik, upewnij się, że znasz już wszystkie podstawowe najlepsze praktyki dotyczące wydajności stron www. Na wydajność ładowania szczególnie duży wpływ ma optymalizacja obrazów.
Na przykład dzięki zastosowaniu następujących technik optymalizacji:
- Zoptymalizowane ładowanie środowiska uruchomieniowego AMP
- Wstępne załadowanie obrazu hero image (rozmiar/kodowanie samego zdjęcia nie zostało zmienione)
- Optymalizacja czcionek niestandardowych (w tym przypadku czcionek Google)
szablon „The Scenic” jest ładowany o dwie sekundy szybciej na łączu 3G.
Jeśli chcesz pominąć szczegóły, sprawdź generator kodu standadowego AMP, którego możesz użyć do wygenerowania własnych, zoptymalizowanych stron AMP.
Optymalizacja ładowania środowiska uruchomieniowego AMP
Choć AMP jest dość restrykcyjny co do znaczników dozwolonych w sekcji <head>, nadal jest miejsce na optymalizację. Kluczem jest skonstruowanie sekcji <head> w taki sposób, aby wszystkie blokujące rendering skrypty i czcionki niestandardowe były ładowane jak najszybciej.
Oto zalecana kolejność dla sekcji <head> strony AMP:
<!doctype html> <html ⚡ lang="en"><br> <head><br> <meta charset="utf-8"><br> <meta name="viewport" content="width=device-width"><br> <meta name="description" content="This is the AMP Boilerplate."><br> <link rel="preload" as="script" href="https://cdn.ampproject.org/v0.js"><br> <link rel="preload" as="script" href="https://cdn.ampproject.org/v0/amp-experiment-0.1.js"><br> <link rel="preconnect dns-prefetch" href="https://fonts.gstatic.com/" crossorigin><br> <script async src="https://cdn.ampproject.org/v0.js"></script><br> <script async custom-element="amp-experiment" src="https://cdn.ampproject.org/v0/amp-experiment-0.1.js"></script><br> <!-- Import other AMP Extensions here --><br> <style amp-custom><br> /* Add your styles here */<br> </style><br> <link href="https://fonts.googleapis.com/css?family=Inconsolata" rel="stylesheet"><br> <style amp-boilerplate>body{-webkit-animation:-amp-start 8s steps(1,end) 0s 1 normal both;-moz-animation:-amp-start 8s steps(1,end) 0s 1 normal both;-ms-animation:-amp-start 8s steps(1,end) 0s 1 normal both;animation:-amp-start 8s steps(1,end) 0s 1 normal both}@-webkit-keyframes -amp-start{from{visibility:hidden}to{visibility:visible.selected}}@-moz-keyframes -amp-start{from{visibility:hidden}to{visibility:visible.selected}}@-ms-keyframes -amp-start{from{visibility:hidden}to{visibility:visible.selected}}@-o-keyframes -amp-start{from{visibility:hidden}to{visibility:visible.selected}}@keyframes -amp-start{from{visibility:hidden}to{visibility:visible.selected}}</style><noscript><style amp-boilerplate>body{-webkit-animation:none;-moz-animation:none;-ms-animation:none;animation:none}</style></noscript><br> <link rel="canonical" href="."><br> <title>My AMP Page</title><br> </head><br> <body><br> <h1>Hello World</h1><br> </body><br></html><br>
Omówmy to krok po kroku:
-
Pierwszym znacznikiem powinien być
meta charset, a następnie należy wstawić wszystkie pozostałe znacznikimeta. -
Następnie należy wstępnie załadować znacznik środowiska uchomieniowego AMP
v0.js<script>z parametrem<link as=script href=https://cdn.ampproject.org/v0.js rel=preload>. Pobieranie środowiska uruchomienioiwego AMP powinno rozpocząć się tak szybko, jak to możliwe, ponieważ kod standardowy AMP ukrywa dokument za pomocą instrukcjibody { visibility:hidden }do chwili załadowania AMP. Wstępne załadowanie środowiska AMP instruuje przeglądarkę, aby pobrała skrypt z wyższym priorytetem. W sekcji renderowanie po stronie serwera opisano jak tego uniknąć. {amp-img6} {/amp-img6} -
Jeśli strona zawiera rozszerzenia opóźniające renderowanie (np. amp-experiment, amp-dynamic-css-classes, amp-story), załaduj wstępnie te rozszerzenia w sposób wymagany przez środowisko uruchomieniowe AMP do renderowania strony.
<link as="script" rel="preload" href="https://cdn.ampproject.org/v0/amp-custom-css-0.1.js"> <link as="script" rel="preload" href="https://cdn.ampproject.org/v0/amp-experiment-0.1.js"> <link as="script" rel="preload" href="https://cdn.ampproject.org/v0/story-1.0.js">
- Use preconnect to speedup the connection to other origin where the full resource URL is not known ahead of time, for example, when using Google Fonts:
&lt;link rel="preconnect dns-prefetch" href="https://fonts.gstatic.com/" crossorigin&gt;
- Load the AMP runtime:
&lt;script async src="https://cdn.ampproject.org/v0.js"&gt;&lt;/script&gt;
- Specify the
<script>tags for render-delaying extensions (e.g.,amp-experimentamp-dynamic-css-classesandamp-story - Specify the
<script>tags for remaining extensions (e.g.,amp-bind...). These extensions are not render-delaying and therefore should not be preloaded as they might take away important bandwidth for the initial render. - Specify any custom styles by using the
<style amp-custom>tag. - Add any other tags allowed in the
<head>section. In particular, any external fonts should go last since they block rendering. - Finally, specify the AMP boilerplate code. By putting the boilerplate code last, it prevents custom styles from accidentally overriding the boilerplate css rules.
Wstępne załadowanie obrazów hero image
AMP HTML stosuje swój własny element obrazu: amp-img. Choć składnik amp-img ma liczne przewagi nad tradycyjnym znacznikiem HTML img, jedną z wad jest to, że środowisko uruchomieniowe musi zostać załadowane przed rozpoczęciem pobierania obrazu. Niektóre obrazy, takie jak obrazy hero image na stronie produktu należy załadować jak najszybciej. W takich przypadkach najlepiej jest wstępnie ładować obraz, aby upewnić się, że przeglądarka rozpocznie pobieranie obrazu jak najszybciej i nie będzie musiała czekać na załadowanie środowiska uruchomieniowego AMP.
<link rel="preload" href="/images/elephants.png" as="image"> ... {amp-img1} {/amp-img1}
Co jednak zrobić, jeśli dany układ responsywny wymaga różnych obrazów hero image w zależności od szerokości ekranu? Na przykład szeroki obrazek dla komputera i wąski obrazek dla telefonu komórkowego, jak tutaj:
{amp-img0} {/amp-img0} {amp-img1} {/amp-img1}
Dobrze, że instrukcja link rel=preload obsługuje również zapytania o media. Możemy dzięki temu użyć tych samych zapytań o media w naszych instrukcjach wstępnego ładowania, jak tutaj:
<link rel="preload" as="image" href="/images/elephants_narrow.png" media="(max-width: 415px)"> <link rel="preload" as="image" href="/images/elephants_wide.jpg" media="(min-width: 416px)">
Przy okazji, to samo podejście działa w przypadku obrazów plakatów składnika amp-video:
<link rel="preload" href="/images/poster.jpg" as="image"> ... {amp-video1} ... {/amp-video1}
Upewnij się tylko, że instrukcje preload są umieszczone za deklaracją okienka na ekranie, ponieważ przeglądarka wymaga wymiarów okienka na ekranie do określenia szerokości ekranu:
<meta name="viewport" content="width=device-width">(max-width: 415px)" ...="">
Rozważ użycie skryptu service worker
Teraz, gdy wszystkie główne przeglądarki obsługują skrypty service worker, warto ocenić, czy dodanie takiego skryptu do danej strony ma sens.
Są dwa różne wzorce architektury, które z pewnością zapewnią niezawodną i szybką nawigację:
- W przypadku aplikacji jednostronicowych: model powłoki aplikacji App Shell (w kontekście AMP określany jako AMP-w-PWA). Wzorzec ten wymaga od skryptu service worker uaktualnienia dokumentu AMP do PWA opartej na powłoce aplikacji.
- W przypadku aplikacji wielostronicowych: transmisja strumieniowa złożonych zasobów. Skrypt service worker buforuje statyczny nagłówek i stopkę, a następnie wykorzystuje strumieniowanie do natychmiastowego zwrócenia zbuforowanej, częściowej odpowiedzi podczas ładowania zawartości.
Jeśli nie jest używany żaden z tych wzorców i nie jest możliwe buforowanie całej witryny (co ma sens tylko w przypadku bardzo małych witryn), skrypt service worker może mieć negatywny wpływ na wydajność. W tym przypadku najlepiej nie stosować skryptu service worker.
Jeśli jednak chcesz, aby Twoja witryna była instalowana z ekranu głównego lub dostępna w trybie offline, konieczne będzie użycie skryptu service worker. W tym przypadku ważne jest, aby użyć wstępnego ładowania nawigacji w celu złagodzenia potencjalnego spowolnienia (uwaga: obecnie wstępne ładowanie nawigacji jest obsługiwane tylko w Chrome).
Jeśli Twoja strona AMP używa skryptu service worker, oto kilka najlepszych praktyk:
- Wstępnie buforuj środowisko uruchomieniowe AMP i rozszerzenia (np.
amp-carousel). - Wstępnie buforuj logotypy, czcionki i inną statyczną zawartość, która jest używana na większości Twoich stron.
- Serwuj logotypy, czcionki i obrazy, stosując strategię cache-first.
- Serwuj środowisko uruchomieniowe AMP i roszerzenia, stosując strategię stale-while-revalidate.
- W przypadku stosowania strategii network-first do żądań nawigacji włącz wstępne ładowanie nawigacji.
Jeśli szukasz sposobu rozpoczęcia stosowania mechanizmu service worker w witrynie AMP, sprawdź ten przykład skryptu service worker realizującego wszystkie powyższe najlepsze praktyki.
Buforowanie wstępne jest istotne nie tylko przy przechodzeniu ze zbuforowanych stron AMP do stron bez AMP we własnym źródle, ale także przy przechodzeniu ze zbuforowanych stron AMP do stron AMP we własnym źródle. Wynika to z tego, że serwer buforujący AMP wykonuje na podstawie niezmiennego adresu URL ponowny zapis adresów URL środowiska uruchomieniowego AMP o najnowszej wydanej wersji, na przykład:
https://cdn.ampproject.org/v0.js -> https://cdn.ampproject.org/rtv/001515617716922/v0.js.
Wskutek tego strona AMP serwowana z własnego źródła nie korzysta z pamięci podręcznej przeglądarki i w tym przypadku musi ponownie pobrać środowisko uruchomieniowe AMP (bez wersji). Za pomocą skryptu service worker można wstępnie zbuforować środowisko uruchomieniowe AMP bez wersji i przyspieszyć przejście. Aby dowiedzieć się więcej o tym, dlaczego serwer buforujący AMP określa wersje środowiska uruchomieniowego AMP w adresach URL, przeczytaj ten dokument.
Optymalizacja czcionek niestandardowych
W przypadku AMP można zoptymalizować ładowanie czcionek na kilka sposóbów (większość z nich nie jest specyficzna dla AMP):
- Jeśli to możliwe, używaj deklaracji font-display: optional: dzięki temu czcionka zostanie użyta tylko wtedy, gdy jest już w pamięci podręcznej, a jeśli nie została jeszcze załadowana, użyta zostanie czcionka systemowa.
- Zoptymalizuj swoje czcionki internetowe (na przykład serwuj czcionki niestandardowe za pomocą WOFF2).
- Wstępniee ładuj czcionki niestandardowe:
<link rel="preload" as="font" href="/bundles/app/fonts/helveticaneue-roman-webfont.woff2">
- Jeśli używasz czcionek Google lub innego dostawcy czcionek z nieznanymi adresami URL czcionek, łącz się z wyprzedzeniem z odpowiednim serwerem czcionek:
<link rel="preconnect dns-prefetch" href="https://fonts.gstatic.com/" crossorigin>
Spróbuj też zminimalizować liczbę niestandardowych czcionek, których używasz na stronie. Jeśli możesz, użyj czcionek systemowych zamiast niestandardowych, ponieważ czcionki systemowe zapewniają zgodność witryny z systemem operacyjnym użytkownika, a to pozwala uniknąć ładowania większej ilości zasobów.
Renderowanie układów AMP po stronie serwera
Renderowanie układów AMP po stronie serwera to technika, którą wykorzystują serwery buforujące AMP, aby jeszcze bardziej skróćić czas ładowania. Dzięki renderowaniu po stronie serwera możliwe jest usunięcie kodu standardowego AMP, aby generować dokument AMP bez konieczności uruchamiania kodu JavaScript środowiska uruchamieniowego AMP. Na przykład renderowana po stronie serwera wersja generatora kodu standardowego AMP jest renderowana dwa razy szybciej niż zwykła wersja AMP!
Jeśli publikujesz stronę AMP, zdecydowanie warto rozważyć użycie optymalizatora AMP. Optymalizatory AMP pozwalają na serwowanie zoptymalizowanych stron AMP z własnego serwera zaplecza, co zapewnia renderowanie układów AMP po stronie serwera. Optymalizator AMP automatycznie wykonuje również wiele innych optymalizacji opisanych w tym dokumencie.
Podstawowe optymalizacje
Oczywiście wszystkie podstawy optymalizacji wydajności stron internetowych odnoszą się również do stron AMP:
- Optymalizuj obrazy i filmy. Optymalizacja obrazów może mieć ogromny wpływ na wydajność ładowania.
- Kompresuj i minimalizuj kod CSS i HTML. Cały CSS na stronach AMP jest wprowadzany inline, warto więc użyć czegoś w rodzaju purifycss do usunięcia nieużywanego kodu CSS.
- Stosuj buforowanie HTTP
- ...itd.
-