Как работает AMP
Ниже описаны решения, благодаря которым AMP-страницы работают так быстро, что кажется, будто они загружаются мгновенно. Здесь всего 7 пунктов, но если читать об этом кажется вам утомительным, просто посмотрите видео с объяснением:
Весь JavaScript-код в AMP выполняется асинхронно
JavaScript имеет огромные возможности. С его помощью можно изменить практически любой аспект страницы, но это может задерживать построение DOM и замедлять рендеринг страницы (см. также Оптимизация JavaScript для быстрой визуализации страницы). Чтобы предотвратить задержку рендеринга страниц из-за JavaScript, AMP допускает только его асинхронные вызовы.
Внутри AMP-компонентов может содержаться JavaScript, однако они спроектированы достаточно тщательно, чтобы не ухудшать производительность.
При том, что пользовательский JS разрешен в amp-script, а сторонний JS разрешен в элементах iframe, это не задерживает рендеринг. Например, если сторонний JS использует убийственный для производительности API document.write, это не заблокирует рендеринг главной страницы.
Размер всех ресурсов задается статически
Внешние ресурсы, такие как изображения, реклама или элементы iframe, должны иметь статически указанный размер в HTML, чтобы AMP мог определить масштаб и координаты расположения каждого элемента до начала загрузки ресурсов. AMP загружает макет страницы, не дожидаясь загрузки самих ресурсов.
AMP разделяет отображение документа и отображение ресурсов. Для разметки всего документа требуется только один HTTP-запрос (а также шрифты). Поскольку AMP оптимизирован так, чтобы ресурсоемкие повторные вычисления стилей и макетирование страниц не выполнялись в браузере, при загрузке ресурсов повторная разметка не выполняется.
Расширения не препятствуют рендерингу
AMP не позволяет механизмам расширений блокировать рендеринг страниц. AMP поддерживает расширения для таких вещей, как лайтбоксы, вставки из instagram, твиты и так далее. Несмотря на то, что для подобных элементов требуется выполнение дополнительных HTTP-запросов, они не заблокируют макет страницы и ее рендеринг.
Любая страница, использующая пользовательский скрипт, должна сообщать системе AMP, что в конечном итоге она будет иметь пользовательский тег. Например, скрипт amp-iframe сообщает системе, что появится тег amp-iframe. AMP создает элемент iframe еще до того, как станет известно, что именно этот iframe будет в себя включать:
<script async custom-element="amp-iframe" src="https://cdn.ampproject.org/v0/amp-iframe-0.1.js"></script>
Весь сторонний JavaScript размещается вне критического пути
В JS-коде от сторонних разработчиков часто используется синхронная загрузка. Также часто можно встретить добавление в код страницы новых синхронных вызовов с помощью document.write. Например, если у вас на странице пять рекламных блоков, и каждый из них вызывает синхронную загрузку трех ресурсов с задержкой подключения в 1 секунду, то у вас уйдет 15 секунд только на загрузку JS.
AMP-страницы допускают сторонний JavaScript, но только в изолированных объектах iframe. Ограниченный iframe, этот код не может блокировать отрисовку главной страницы. Даже если в iframе запускается обработка нескольких стилей, DOM-дерево такого iframe будет небольшим.
Время, необходимое для обработки стилей и компоновки страницы, зависит от размера DOM, поэтому обработка данных в iframe выполняется гораздо быстрее по сравнению с обработкой стилей и отрисовкой всей страницы.
Использование только встраиваемых CSS-элементов с фиксированным размером
CSS блокирует весь рендеринг, задерживает загрузку страницы и имеет тенденцию к постоянному увеличению. На AMP HTML-страницах разрешены только встроенные стили. Это удаляет как минимум один, а чаще и больше дополнительных HTTP-запросов из критического пути рендеринга в сравнении с большинством веб-страниц.
Кроме того, встроенные таблицы стилей могут быть размером не более 50 килобайт. Хотя это достаточный размер для отображения очень сложных страниц, он все же требует от автора страницы соблюдения правил чистоты CSS.
Эффективный запуск шрифтов
Веб-шрифты очень ресурсоемки, поэтому оптимизация веб-шрифтов имеет решающее значение для производительности. На типичной странице, где есть несколько синхронных скриптов и внешних таблиц стилей, пока все они не отработают, браузер будет ждать и ждать загрузки этих тяжелых шрифтов.
Система AMP не выполняет никаких HTTP-запросов, пока не начнется загрузка шрифтов. Это возможно благодаря тому, что все вставки JS-кода в AMP имеют атрибут async и разрешены только встроенные таблицы стилей. Таким образом, отсутствуют HTTP-запросы, задерживающие загрузку шрифтов браузером.
Минимизация повторной обработки стилей
Каждый раз, когда вы собираете какую-либо статистику, стили вычисляются повторно, а это дорогостоящая для производительности операция, поскольку браузеру приходится повторно разметить всю страницу. На AMP-страницах все операции чтения DOM выполняются перед записью. Таким образом стили вычисляются повторно не более одного раза на каждый фрейм.
Узнайте подробности влияния повторной обработки стилей и разметки на странице Производительность визуализации.
Запуск только анимации, ускоренной при помощи видеокарты
Единственный способ выполнить быструю оптимизацию — запустить ее на видеокарте. Графический процессор понимает механизм компоновки, знает, как выполнять некоторые действия на разных слоях, может перемещать и постепенно проявлять их, но не может обновлять макет страницы. Задачу по обновлению макета он передает браузеру, а это плохо.
CSS-правила, относящиеся к анимации, позволяют ускорять ее на графическом процессоре. В частности, AMP позволяет анимировать и выполнять только переходы, связанные с трансформацией и прозрачностью, а для этого размечать страницу не требуется. Узнайте больше об использовании трансформаций и прозрачности в анимации.
Определение приоритета загрузки ресурсов
AMP контролирует весь процесс загрузки ресурсов: он определяет их приоритет, загружая только необходимые, а также заранее вызывает ресурсы с отложенной загрузкой.
Когда AMP загружает ресурсы, он оптимизирует загрузку так, что наиболее важные на данный момент ресурсы загружаются первыми. Изображения и рекламные объявления загружаются только в том случае, если пользователь сможет просмотреть их без прокрутки или быстро прокрутить до них страницу.
AMP также заранее вызывает ресурсы с отложенной загрузкой. Ресурсы загружаются как можно позже, при этом их вызов осуществляется как можно раньше. Таким образом, все загружается очень быстро, но процессор используется только при непосредственном показе ресурсов пользователям.
Моментальная загрузка страниц
Новый API для предварительного соединения интенсивно используется для обеспечения максимально быстрого выполнения HTTP-запросов. При этом страница может быть предзагружена еще до того, как пользователь явно заявит, что он хотел бы к ней перейти. К тому моменту, когда пользователь непосредственно выберет эту страницу, она будет уже полностью доступна и загрузится мгновенно.
Предварительный рендеринг можно применить ко всему контенту, но это может существенно увеличить нагрузку на сеть и центральный процессор. AMP оптимизирован для уменьшения обоих факторов. При предварительном рендеринге загружаются только те ресурсы, которые пользователь увидит в первую очередь. Ресурсы, которые активно задействуют процессор, не загружаются заранее.
Когда выполняется предварительный рендеринг документов AMP для их последующей мгновенной загрузки, фактически загружаются только ресурсы, отображаемые на первом экране. Элементы, которые активно задействуют процессор (например, сторонние объекты iframe), не загружаются.
Узнать подробности о том, почему AMP HTML не использует все преимущества сканера предварительной загрузки.