SEOПродвижениеРазработка и дизайн

AMP — это ложь

Ускоренные мобильные страницы (AMP) сейчас являются горячей темой, но действительно ли они являются ответом на ваши проблемы со скоростью загрузки мобильной версии страницы? Обозреватель Патрик Стокс отвечает.

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

Единственное, что все знают, это то, что AMP — это быстро, но почему?

На странице Как работает AMP, мы видим причины, по которым AMP работает быстро:

  • Выполняйте все AMP JavaScript асинхронно
  • Калибруйте все ресурсы в статический вид
  • Не позволяйте механизмам расширения блокировать рендеринг
  • Извлекайте весь сторонний JavaScript из критического пути
  • Все CSS делайте строчными и связанными по размеру
  • Переключайте шрифт более эффективно
  • Минимизируйте перерасчет стиля
  • Выполняйте только анимацию с ускорением GPU
  • Приоритезируйте загрузку ресурсов
  • Загружайте страницы в одно мгновение

Вам нужен AMP?

Я бы добавил еще одно важное замечание: контент загружается через HTTP / 2, когда большая часть веб-страниц по-прежнему отсутствует. Почти все в приведенном выше списке можно сделать без AMP. Если вы знаете, что ваш сайт имеет проблемы, почему игнорировать основной сайт и перейти на отдельную базу кода вместо того, чтобы исправить свои проблемы? Если вы хотите предоставить более быстрый веб-сайт своим мобильным пользователям, сделайте это. Это требует столько же работы по внедрению AMP, как и улучшение вашего сайта без AMP. Улучшите свой сайт так, как вы вынуждены для AMP, и вы получите сайт с такой же скоростью.

Я говорю «почти так же быстро», потому что секретный соус AMP действительно находится в предварительной передаче (пререндеринге). Загрузка частей заблаговременно снижает ощущаемую скорость загрузки. Предпочитаете ли вы, чтобы веб-сайт, который, как ощущается, загружался быстрее пользователями, но фактически занимал больше времени, или веб-сайт, который на фактически загружался быстрее, но ощущался, что он загружается медленнее для пользователей? Я бы сказал, что более важно ощущение быстроты, чем фактическая быстрота.

Я случайным образом проверил около 50 различных статей с помощью Chrome DevTools, имитирующих мобильные и загруженные страницы с предварительной передачей (пререндерингом) (AMP), без предварительной передачи (без пререндеринга) (напрямую с AMP) и мобильного веб-сайта (не AMP). Я обнаружил, что предварительная передача (пререндеринг) убрала от 0,5-5,5 секунды от времени загрузки страницы, и большинство веб-сайтов, похоже, выиграли от 1-секундной разницы в фактической скорости загрузки, но разница в воспринимаемой скорости еще больше. Вот несколько таймингов, которые я получил от Search Engine Land в тех статьях (фактическое время):

Статья 1:

  • 1.3 с. c предварительной передачей (с пререндерингом) (AMP)
  • 2.0 с. без предварительной передачи (без пререндеринга) (напрямую с AMP)
  • 4.9 с. мобильная версия (без AMP)

Статья 2:

  • 1 с. c предварительной передачей (с пререндерингом) (AMP)
  • 2.1 с. без предварительной передачи (без пререндеринга) (напрямую с AMP)
  • 1.9 с. мобильная версия (без AMP)

Правильно — во второй статье мобильный сайт был на самом деле быстрее, чем страница без предварительной передачи (без пререндеринга) (напрямую с AMP) касательно фактического времени загрузки. Но ощущаемая загрузка отличается, и страница AMP определенно появилась быстрее. Страницы AMP также могут быть медленнее, чем страницы без AMP. Худший нарушитель на страницах, которые я проверил, был в The Guardian, где фактическое время загрузки составляло на 10 полных секунд дольше для страницы AMP с предварительной передачей (с пререндерингом), чем мобильный сайт.

12.8 c. c предварительной передачей (с пререндерингом) (AMP)

18.3 с. без предварительной передачи (без пререндеринга) (напрямую с AMP)

2.8 с. мобильная версия (без AMP)

Что удивительно для меня, так это то, что если бы мне пришлось посмотреть и угадать, какой из них загружен быстрее, я бы сказал, что страница AMP с предварительным просмотром. В разделе «Основные характеристики производительности Apple» есть раздел, в котором говорится: «Восприятие производительности так же эффективно, как и фактическая производительность во многих случаях». Эта воспринимаемая скорость, более чем что-либо другое, дает AMP реальное преимущество, которое вы не можете получить на странице без AMP.

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

Теги

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Close