Одним из наиболее спорных дизайнерских решений в AMP HTML является то, что он загружает все внешние ресурсы через пользовательские элементы. Хотя у этого есть некоторые преимущества (подробнее об этом позже), у него есть одна серьезная проблема: сканер предварительной загрузки браузера больше не может начать загрузку этих ресурсов на очень ранней стадии жизненного цикла документа и, что еще хуже: браузеру необходимо загрузить файл JavaScript в чтобы иметь возможность делать эти загрузки.

Математика здесь проста: чем раньше начинается загрузка ресурсов, тем раньше они появятся. Очень простой документ с одним изображением и ничем другим будет намного быстрее, если это не файл AMP.

Итак, почему AMP HTML отключил этот очень важный компонент скорости браузера? - Есть 2 основные причины:

Причина 1. В AMP снижена эффективность сканера предварительной загрузки.

Одним из его основных преимуществ является то, что он может начать загрузку ресурсов до того, как будут загружены внешние таблицы стилей документа и синхронные файлы JavaScript, расположенные над ресурсом в иерархии документа. AMP на самом деле не позволяет этого, поэтому выгода исчезает.

Кроме того, поскольку в AMP HTML пространство, которое будет занимать изображение, всегда известно без его загрузки, устраняется эффект, когда запоздалое изображение может повлиять на макет страницы.

Причина 2: эффективная предварительная отрисовка [1]

Хотя голое время загрузки важно, AMP стремится поддерживать мгновенную загрузку. Это достигается предварительным оформлением документов. Для предварительной отрисовки приложение может загрузить и отобразить документ до того, как пользователь фактически выразит намерение (также называемое касанием, щелчком или нажатием), что он хочет увидеть документ. Для этого необходимо, чтобы приложение угадало, какой документ пользователь захочет увидеть. Гадать становится значительно легче, когда можно делать больше предположений. В лучшем случае все доступные документы можно предварительно оформить.

Гадать становится намного легче, когда можно делать больше предположений.

Основная проблема с предварительным рендерингом заключается в том, что он требует ресурсов: как полосы пропускания, так и процессора. AMP HTML поддерживает специальный режим предварительной визуализации для документов, в которых загружаются только изображения, но нет других ресурсов, а также только те изображения, которые фактически видны, когда пользователь впервые видит документ (также известный как верхняя часть сгиба). Некоторое время игнорируя ЦП (и это на самом деле более важно, но с ним труднее делать математику), можно сделать следующий расчет: скажем, в документе обычно есть 4 больших изображения, но только одно из них видно над сгибом, и размер загрузки преобладает. по этим изображениям (поскольку документы малы), то в режиме предварительной визуализации AMP браузер может загрузить и выполнить предварительную визуализацию 4 документов, используя полосу пропускания, которая потребовалась бы для предварительной визуализации одного документа, не относящегося к AMP.

Следствием этого является то, что приложения могут выполнять предварительную визуализацию HTML-документов AMP гораздо более агрессивно, чем они могут выполнять предварительную визуализацию обычных HTML-документов.

Резюме

AMP HTML работает со сканером предварительной загрузки, потому что он, как ни парадоксально, позволяет достичь желаемого эффекта мгновенной загрузки. Даже если не выполнять предварительную визуализацию, структура документа AMP HTML значительно сводит на нет преимущества сканера предварительной загрузки, поэтому загрузка выполняется быстро, даже если не выполняется предварительная визуализация.

  • [1] Предварительная визуализация в AMP относится к концепции приложения, а не к функции ‹ link rel = prerender ›, доступной в некоторых браузерах. Это может быть реализовано с помощью скрытого iframe, который отображает документ и отображается, когда пользователь запрашивает его.