Jak działa AMP
Połączenie wskazanych optymalizacji sprawia, że strony AMP sprawiają wrażenie ładowanych natychmiast. Tych powodów jest łącznie 7. To za dużo czytania? Obejrzyj ten film:
Asynchroniczne wykonywanie całego kodu AMP JavaScript
JavaScript jest potężny. Można nim modyfikować prawie każdy aspekt strony — ale także zablokować budowę modelu DOM i opóźnić wyświetlenie strony (patrz też Dodawanie funkcji interaktywnych w JavaScripcie). Aby JavaScript nie opóźniał wyświetlania strony, AMP zezwala tylko na asynchroniczny JavaScript.
Składniki AMP mogą zawierać kod JavaScript, ale są starannie zaprojektowane tak, aby nie pogarszało to wydajności.
Choć w składniku amp-script jest dozwolony niestandardowy kod JS, a w elementach iframe — kod JS innych firm, to nie może on zablokować wyświetlania. Jeśli na przykład kod JS innej firmy stosuje niezwykle-pogarszającą-wydajność instrukcję document.write z interfejsu API, nie zablokuje to wyświetlania głównej strony.
Statyczne rozmiary wszystkich zasobów
Zasoby zewnętrzne, takie jak obrazy, reklamy lub ramki iframe, muszą mieć w kodzie HTML określony swój rozmiar. Pozwoli to standardowi AMP na określenie rozmiaru i umiejscowienia każdego elementu przed pobraniem zasobów. AMP ładuje układ strony bez oczekiwania na pobranie jakichkolwiek zasobów.
AMP oddziela układ dokumentu od układu zasobów. Do wygenerowania układu całego dokumentu potrzebne jest tylko jedno żądanie HTTP (i czcionki). Jako że AMP jest zoptymalizowany tak, aby uniknąć kosztownych ponownych obliczeń stylów i generowania układów w przeglądarce, nie jest wykonywane ponowne generowanie układu podczas ładowania zasobów.
Niedopuszczanie do blokowania wyświetlania przez mechanizmy rozszerzeń
AMP nie pozwala mechanizmom rozszerzeń na blokowanie wyświetlania strony. Choć AMP obsługuje rozszerzenia dla elementów takich jak lightboksy, osadzane wpisy z Instagrama, tweety itd., które wymagają dodatkowych żądań HTTP, to żądania te nie blokują generowania układu strony ani jej wyświetlania.
Każda strona korzystająca ze skryptu niestandardowego musi poinformować system AMP, że w końcu będzie zawierać znacznik niestandardowy. Na przykład skrypt amp-iframe informuje system, że będzie zawierać znacznik amp-iframe. AMP tworzy pole iframe, zanim jeszcze dowie się, co będzie ono zawierać:
<script async custom-element="amp-iframe" src="https://cdn.ampproject.org/v0/amp-iframe-0.1.js"></script>
Utrzymywanie całego zewnętrznego kodu JavaScript z dala od ścieżki krytycznej
W kodzie JS innych firm często stosowane jest synchroniczne ładowanie skryptów JS. Nierzadko do ładowania dodatkowych skryptów synchronicznych stosowana jest również instrukcja document.write. Jeśli na przykład na stronie jest pięć reklam, a każda z nich powoduje synchroniczne ładowanie trzech skryptów z 1-sekundowym czasem oczekiwania łącza, skutkuje to 15 sekundami ładowania samych tylko skryptów JS.
Strony AMP dopuszczają skrypty JavaScript innych firm, ale tylko w izolowanych elementach iframe. Dzięki temu nie mogą one blokować wykonywania głównej strony. Nawet jeśli uruchamiane są wielokrotne ponowne obliczenia stylu, bardzo małe elementy iframe mają równie mały model DOM.
Czas niezbędny na wykonanie ponownych obliczeń stylu i układów jest ograniczony rozmiarem modelu DOM, więc ponowne obliczenia elementu iframe są bardzo szybkie w porównaniu z ponownym obliczaniem stylów i układu strony.
Cały CSS musi być lokalny i powiązany z rozmiarem
CSS blokuje wszelkie wyświetlanie, blokuje ładowanie strony i ma tendencję do rozdymania się. Na stronach AMP HTML dozwolone są tylko style lokalne. Dzięki temu z krytycznej ścieżki wyświetlania usuwane jest wiele żądań HTTP w porównaniu do większości stron internetowych.
Maksymalny rozmiar wbudowanego arkusza stylów wynosi 50 kilobajtów. Chociaż rozmiar ten jest wystarczająco duży dla bardzo zaawansowanych stron, nadal wymaga od autora strony zachowania zasad higieny CSS.
Wyzwalanie czcionek musi być sprawne
Czcionki internetowe są bardzo duże. Dlatego dla wydajności kluczowe znaczenie ma optymalizacja czcionek sieci Web. Na typowej stronie z kilkoma skryptami synchronicznymi i kilkoma zewnętrznymi arkuszami stylów przeglądarka czeka i czeka aż to wszystko się zdarzy, aby rozpocząć pobieranie tych ogromnych czcionek.
System AMP nie wysyła żadnych żądań HTTP dopóki nie rozpocznie się pobieranie czcionek. Jest to możliwe tylko dlatego, że cały kod JS w AMP ma atrybut async i dozwolone są tylko style lokalne; nie występują żądania HTTP blokujące pobieranie czcionek przez przeglądarkę.
Minimalizowanie przeliczania stylu
Każdy pomiar uruchamia ponowne obliczenia stylu, które są kosztowne, ponieważ przeglądarka musi wygenerować układ całej strony. Na stronach AMP wszystkie odczyty modelu DOM odbywają się przed wszystkimi zapisami. Ogranicza to ponowne obliczanie stylów do jednego na każdą ramkę.
Dowiedz się więcej o wpływie ponownych obliczeń stylu i układu na wydajność wyświetlania.
Uruchamianie tylko animacji akcelerowanych przez GPU
Jedyną metodą szybkich optymalizacji jest uruchamianie ich na GPU. Procesor graficzny obsługuje warstwy, wie, jak wykonać pewne działania na tych warstwach, może je przenosić i stopniowo zmniejszać ich widoczność, ale nie potrafi zaktualizować układu strony — przekazuje to zadanie przeglądarce, a to niedobrze.
Reguły CSS związane z animacjami zapewniają, że animacje mogą być akcelerowane przez GPU. W szczególności AMP zezwala na animację i przejścia tylko za pomocą transformacji i krycia, więc układ strony nie jest wymagany. Dowiedz się więcej o stosowaniu transformacji i krycia do zmian animacji.
Priorytety ładowania zasobów
AMP steruje pobieraniem wszystkich zasobów: nadaje priorytety ładowaniu zasobów, ładuje tylko to, co jest potrzebne i pobiera zasoby leniwie ładowane.
AMP optymalizuje pobieranie zasobów tak, aby najpierw pobrać te najważniejsze. Obrazy i reklamy są pobierane tylko wtedy, gdy użytkownik może je zobaczyć — są na ekranie lub użytkownik prawdopodobnie szybko do nich przejdzie.
AMP pobiera również z wyprzedzeniem zasoby leniwie ładowane. Zasoby są ładowane jak najpóźniej, ale wstępnie pobierane są tak wcześnie, jak to możliwe. Dzięki temu ładowanie jest bardzo szybkie, ale procesor jest wykorzystywany tylko wtedy, gdy zasoby są pokazywane użytkownikom.
Błyskawiczne ładowanie stron
Intensywne stosowanie nowego interfejsu API preconnect zapewnia jak najszybsze wykonywanie żądań HTTP poprzez nawiązywanie połączeń z wyprzedzeniem. Dzięki temu można wyświetlić stronę zanim użytkownik jednoznacznie wskaże, że chce do niej przejść; strona będzie dostępna, nim jeszcze użytkownik faktycznie ją wybierze, co prowadzi do błyskawicznego załadowania.
Wyświetlanie z wyprzedzeniem można stosować do wszystkich treści internetowych, ale może to skutkować dużym obciążeniem łącza i procesora. AMP jest zoptymalizowany w celu zmniejszenia wpływu obu tych czynników. W celu wyświetlania z wyprzedzeniem pobierane są tylko zasoby widoczne na ekranie i nie są wyświetlane elementy znacznie obciążające procesor.
Gdy dokumenty AMP są wyświetlane z wyprzedzeniem dla błyskawicznego załadowania, faktycznie pobierane są tylko zasoby widoczne na ekranie. Zasoby mogące znacznie obciążać procesor (takie jak zewnętrzne ramki iframe) nie są wówczaspobierane.
Dowiedz się więcej o tym, dlaczego AMPHTML nie wykorzystuje w pełni funkcji wstępnego ładowania.