По состоянию на 24 февраля результаты поиска Google начали включать ссылки на версии мобильных страниц, созданные с помощью Accelerated Mobile Pages , также известной как «AMP», проект с открытым исходным кодом, который он поддерживал . Целью AMP является ускорение загрузки мобильных сайтов и повышение удобства работы пользователей.
Google и проект AMP прилагают большие усилия, чтобы внедрить AMP в Интернете, и они уже преуспевают. Automattic добавляет поддержку AMP на WordPress.com , Pinterest усиливает свою поддержку , Twitter обещает поддержку, как Chartbeat, Parse.ly, Adobe Analytics & LinkedIn, и мы видим, что версии AMP входят в комбинацию для популярных сайтов Wall Street Журнал, Buzzfeed, The Guardian, BBC News, The New York Times и ряд других.
Причина, по которой все эти компании попадают на борт, проста: скорость загрузки . Нет никаких сомнений в том, что более быстрые сайты лучше, поэтому в этой статье я не буду проповедовать хору, рассматривая все причины, почему это так. Я также собираюсь избегать слишком большого внимания к информации, которую вы можете легко получить, просто посетив веб-сайт AMP Project или просмотрев их рекламный фильм.
Скорее, мы собираемся перейти к осознанию того, что именно AMP означает для вас, когда вы на самом деле кодируете сайты. Мы собираемся прямо рассказать о том, что именно AMP потребует от вас на практике, какие потенциальные выгоды и недостатки вы можете ожидать, и самое главное, будет ли это делать ваши сайты быстрее.
Почему это должно меня волновать?
Ну, чтобы быть прямым, потому что это Google. Как и в большинстве случаев, связанных с Google, хорошей идеей будет познакомиться с новыми разработками на ранней стадии, потому что вы никогда не знаете, когда или как их существование может повлиять на эффективность ваших сайтов в поисковых системах. Вполне возможно, что сайты, использующие AMP, могут установить планку для требований к скорости и производительности, ожидаемых Google, если вы хотите преуспеть в поисковом рейтинге.
Как заявил Ричард Гинграс, старший директор Google по новостям и социальным продуктам, говоря о AMP :
«… Если бы у нас было две статьи, которые с точки зрения сигнализации оценивали одинаково по всем другим характеристикам, кроме скорости, тогда да, мы сделаем акцент на скорости …»
Поэтому, даже если вы не планируете использовать AMP, вам все равно стоит посоветовать его изучить и постараться обеспечить, чтобы ваши мобильные сайты были оптимизированы в сопоставимой степени.
⚡ Подсветка в результатах поиска
Прямо сейчас, сайты AMP, которые перечислены в результатах поиска, получают небольшую подсветку. Вы не можете не представить, что эти сайты будут выделяться больше, чем другие.
Это будут только крупные новостные сайты, которые будут демонстрироваться таким образом? Пока еще рано говорить. Но это вполне может быть фактором, на который стоит обратить внимание.
Будет ли использование AMP сделать мои сайты быстрее?
Вот прямой и честный ответ: возможно, но не обязательно.
Это потому, что встречный вопрос, который нужно задать: «Быстрее, чем что?»
Быстрее, чем тяжеловесный сайт со стандартным, запустить мельницу оптимизации? Возможно .
Быстрее ли сайт с минимальным стилем дизайна и продвинутой оптимизацией? Не обязательно
Правда в AMP нет ничего, что могло бы стать волшебной пулей. Это не новый тип HTML (как его описали некоторые комментаторы) или невиданная ранее технология, которая гарантированно сделает ваши сайты быстрее. По словам самого Google, это:
«… полностью построен на основе существующих веб-технологий, что позволяет веб-сайтам создавать легкие веб-страницы».
Если вы знакомы с абсолютным ультрасовременным потенциалом оптимизации и обладаете высоким техническим уровнем понимания того, как заставить сайты работать безумно быстро, AMP может вам вообще не помочь. На самом деле, можно даже увидеть потери скорости в определенных обстоятельствах, хотя это может измениться по мере развития проекта.
AMP не идеален, он не является автоматическим исправлением всех проблем и не претендует на это. Пол Бакаус, адвокат разработчика для Chrome и Open Web в Google, говорит в презентации на AMP :
«Теперь, конечно, если вы создаете свой собственный сайт, и вы знаете, что делаете, и это здорово, это быстро и все, AMP может не сделать ваш сайт лучше, верно. Чтобы было ясно, это может не сделать ваш сайт лучше ».
Что на самом деле представляет собой AMP — это набор относительно сложных методов оптимизации, связанных для удобства, таким образом, что вам не нужно думать обо всех движущихся частях за кулисами. Это дает вам строгий набор правил, и если вы будете следовать им, у вас будет более быстрый сайт, чем тот, который либо не оптимизирован, либо не оптимизирован в той же степени.
В то же время, если вы предпочитаете работать с каждым элементом вашего рабочего процесса оптимизации, вы можете собрать собственные сопоставимые методы без использования AMP. Использование AMP, по крайней мере, на данный момент, не является обязательным — но знание того, как оптимизировать до эквивалентного уровня, может быть очень скоро.
Давайте углубимся в то, что такое AMP, как он работает, и посмотрим на некоторые результаты теста скорости, а затем вернемся к вопросу «Будет ли это ускорять работу моих сайтов?» в конце статьи.
Что такое AMP для разработчика
AMP официально описывается как сочетание трех вещей: AMP HTML, AMP JS и AMP CDN. Это, конечно, правда, однако, с точки зрения разработчика, я чувствую три вещи, которые будут наиболее важны для вас при кодировании:
- Правила лучшей практики AMP для кодирования
- Пользовательские HTML-элементы AMP
- Валидатор AMP, чтобы убедиться, что вы реализуете два выше
Короче говоря, вы начнете создавать документ AMP, скопировав и вставив код, который вы найдете на странице примера в документации AMP . Оттуда вы начинаете заполнять свои страницы, используя три элемента в этом списке, которые все работают на AMP HTML и AMP JS.
Примечание : AMP CDN может использоваться автоматически и бесплатно пользователями AMP, однако возможно, что вы могли бы одинаково хорошо использовать другой CDN, такой как CloudFlare. Из-за этого и того факта, что CDN не является частью процесса кодирования, я исключил его из списка трех наиболее важных аспектов AMP для разработчиков.
Позвольте мне обобщить каждый из трех.
1. Правила AMP для CSS, HTML и JS
С самого начала есть правила работы с AMP, которые помогут оптимизировать любую страницу, поэтому стоит ознакомиться с тем, используете ли вы AMP или нет. Они довольно строгие, и есть некоторые вещи, которые вы, вероятно, будете использовать, без которых вам придется обойтись, так что будьте готовы к кодированию, чтобы чувствовать себя немного неловко с самого начала.
Например, весь CSS должен быть встроен внутри раздела head , обернут в теги <style amp-custom>...</style> — чтобы больше не было ссылок на какие-либо внешние таблицы стилей. Вы вряд ли захотите вписать свой CSS прямо в ваши HTML-документы, поэтому вам нужно подумать об использовании чего-то вроде Jade или о том, чтобы PHP выводил содержимое вашей таблицы стилей в строку.
Ваш CSS также может быть не больше чем 50 КБ. Чтобы поместить это в перспективу, минимизированный стандартный CSS Bootstrap без темы — 121kb . Тема добавила бы примерно 23 КБ, в результате чего ее общее количество составит 144 КБ, что почти в три раза больше разрешенного количества. Таким образом, вы должны быть очень эффективны при использовании кода стиля.
Кроме того, существуют запрещенные селекторы CSS, такие как, например, * , поэтому больше не будет использоваться * { box-sizing: border-box } для управления расстоянием по всему сайту. Таким же образом есть запрещенные элементы HTML, такие как base , frame , embed и некоторые другие. Поддержка форм в настоящее время находится в разработке, поэтому в настоящее время также нет использования элемента form или каких-либо элементов ввода.
Вы можете загружать внешние веб-шрифты , но только из Google Fonts или Fonts.com через источники https://fonts.googleapis.com и https://fast.fonts.net соответственно.
Для полного изложения того, что вы можете и не можете делать в своих CSS и HTML, ознакомьтесь со спецификацией AMP HTML .
«Большой принцип» в правилах AMP заключается в том, что абсолютно никакой пользовательский JavaScript не допускается . Если вы привыкли к тому, что JavaScript поддерживает ваши адаптивные меню или что-то еще, вам не повезло, и вам придется искать другой путь. Однако это в некоторой степени сбалансировано благодаря наличию встроенных компонентов AMP, таких как лайтбокс и карусель, среди прочего, что приводит нас к следующему разделу: пользовательские элементы.
2. Пользовательские элементы HTML
AMP включает в себя набор пользовательских HTML-элементов, ориентированных на медиа, каждый с префиксом amp- . Существуют компоненты для замены некоторых стандартных элементов HTML, а также дополнительные функции, которые добавляют функциональность, для которой обычно требуется JavaScript.
Стандартные теги img , video , audio и iframe заменяются соответственно на amp-img , amp-video , amp-audio и amp-iframe .
Существует также ряд элементов, предназначенных для встраивания стороннего контента, таких как amp-ad , amp-analytics , amp-pinterest , amp-twitter и amp-youtube .
И, наконец, есть то, что я бы назвал элементами добавления функций, такими как amp-lightbox , amp-carousel и amp-anim .
Для полного изложения ознакомьтесь со спецификацией AMP HTML-компонентов .
Пользовательские элементы AMP предназначены для выполнения двух основных задач:
- Убедитесь, что оптимизированный код
- Содействовать загрузке приоритетов и оптимизации
Ранее я упоминал, что три наиболее важных аспекта AMP для разработчиков — это правила передового опыта, пользовательские элементы и средство проверки для обеспечения их соблюдения. Имея это в виду, учитывая, что возможно следовать правилам наилучшей практики, независимо от того, используете вы AMP или нет, я чувствую, что решающим фактором того, стоит ли вам использовать AMP, является степень использования вашим сайтом пользовательских элементов, которые он предоставляет.
Если вы считаете, что ваш сайт часто их использует, вероятно, AMP поможет вам с быстрой и эффективной загрузкой мультимедиа.
Если вы считаете, что ваш сайт будет использовать их только в редких случаях, ваши результаты могут быть такими же хорошими, если не учитывать AMP и применять правила передовой практики без него.
Одним из аспектов балансировки того, даст ли AMP улучшение, является тот факт, что для работы JavaScript требуется 44 КБ. Таким образом, на вашей странице должно быть достаточно мультимедийных данных, чтобы эффективная загрузка AMP-координат компенсировала собственное добавление 44 КБ, а затем дала вам дополнительные преимущества. Некоторые пользовательские элементы, такие как элементы Twitter и YouTube, также требуют загрузки дополнительных сценариев.
В моих тестах JavaScript AMP загружался около 779 мс — 932 мс при симулированном 3G-соединении 750 кбит / с, скрипт Twitter загружался около 367 мс — 468 мс, а YouTube — 318 мс — 386 мс.
Важность элемента amp-ad
Одна из главных причин, по которой существует проект AMP, заключается в том, чтобы дать издателям возможность монетизировать свои сайты с помощью рекламы, которая не является ужасно медленной и неприятной для посетителей.
Проект AMP пытается устранить такие события, как посещение веб-сайта и ожидание пяти секунд, пока полноэкранное объявление не блокирует ваш путь к статье. Или пытаться прочитать какой-то текст и едва видеть что-либо, потому что гигантский баннер занимает четыре пятых доступного пространства.
Тем не менее, они хотят избавиться от подобных проблем, обеспечивая при этом издателям возможность зарабатывать достаточно денег на своей рекламе для поддержки своего бизнеса. Именно здесь в игру вступает элемент amp-ad .
Теги <amp-ad>...</amp-ad> выглядят странно с самого начала, но на самом деле они представляют собой унифицированный и эффективный способ показа рекламы из солидного списка основных поставщиков:
- A9
- Adform
- AdReactor
- AdSense
- AdTech
- Dot and Media
- Двойной клик
- Flite
- plista
- Smart AdServer
- Yieldmo
- Revcontent
Если показ рекламы является основной частью ваших сайтов, AMP стоит проверить только для элемента amp-ad .
Для получения дополнительной информации о том, как использовать это, посетите: https://www.ampproject.org/docs/reference/amp-ad.html
3. Валидатор
Валидатор AMP существует, чтобы убедиться, что вы придерживаетесь правил AMP. Он сообщит вам, пишете ли вы код, который не соответствует рекомендациям, и используете ли вы собственный элемент, который должен быть заменен пользовательским элементом.
Когда вы начинаете работать над страницей AMP, использование валидатора — это просто добавление #development=1 в конец URL-адреса предварительного просмотра, а затем просмотр консоли в Chrome Developer Tools.
Если вы делаете что-то не так, валидатор сообщит вам.
Особенно учитывая, что кодирование для AMP может потребовать некоторой корректировки, рекомендуется держать этот валидатор открытым все время, чтобы вы могли выявлять любые проблемы в момент их появления.
Как AMP генерирует скорость
Лучшее изложение технических особенностей методов оптимизации AMP можно найти в официальном блоге . Тем не менее, я обещал вам простой английский, поэтому вот оно:
Код, которого нет
Огромный кусок того, как страницы AMP работают быстрее, — это весь код, которого просто нет.
У вас не больше 50 КБ CSS, и это код, который не требует загрузки своего собственного http запроса. У вас нет определенного CSS, и у вас нет определенного HTML. У вас нет своего собственного JavaScript, что, в свою очередь, означает, что у вас нет таких вещей, как модалы на JS, вкладки, всплывающие подсказки, оповещения и так далее. Кроме того, у вас нет кода для пяти разных поставщиков рекламы и трех разных аналитических служб.
Отсутствие всех этих элементов дает вам преимущество сразу же. Код, которого вообще нет, имеет нулевое время загрузки. Конечно, вам не нужен AMP для пропуска кода, так что нужно помнить, решите ли вы использовать AMP или нет.
Загрузка приоритетов и оптимизации
Мы уже коснулись пользовательских элементов AMP и того факта, что они облегчают определение приоритетов и оптимизацию загрузки.
На практике это происходит, когда вы помещаете на страницу AMP носитель, видимый на экране («над сгибом»), сначала загружается, позволяя начать просмотр, а затем загружается любой оставшийся носитель. Есть также случаи, когда страница может быть загружена до того, как пользователь перейдет к ней, что может привести к ее мгновенной загрузке.
Все это происходит с помощью нескольких различных методов, включая ленивую загрузку , предварительную визуализацию , предварительное подключение и предварительную выборку . Вы можете реализовать эти методы самостоятельно, если решите не использовать AMP. В статье в блоге AMP, о которой я упоминал выше, говорится:
«Каждая веб-страница может иметь эти оптимизации, но страницы AMP не могут их иметь. Хотя эта статья посвящена оптимизации в AMP, она также может быть полезна в качестве своего рода списка задач для оптимизации веб-сайтов сторонних разработчиков ».
Так что, если ничего другого, посмотрите, как AMP обрабатывает загрузку, чтобы получить новые идеи о том, что вы можете сделать для своих сайтов.
Эффективность макета
Для всех мультимедийных файлов, добавляемых на страницу AMP, должны быть указаны свойства высоты и ширины. Это означает, что даже при том, что все еще возможно иметь изменяемые размеры и адаптивные элементы, AMP будет знать, как он должен расположить страницу перед загрузкой указанного носителя. Это избавляет от необходимости ждать, пока изображение будет загружено, а затем пересчитывать макет страницы, экономя время рендеринга в процессе.
Некоторые тесты скорости
Если вы следили за слухами об AMP, вы слышали, что Google делится результатами своих тестов по увеличению скорости до 85% со страницами ранних партнеров. Pinterest недавно провела тесты и обнаружила, что « страницы AMP загружаются в четыре раза быстрее и используют в восемь раз меньше данных, чем традиционные страницы, оптимизированные для мобильных устройств ».
Это довольно значимые цифры, поэтому я хотел точно знать, что стоит за этими различиями в скорости. Как я уже упоминал ранее, главный вопрос: «Быстрее, чем что?»
Чтобы выяснить это, я начал с нуля, не имея ничего, кроме кода стартовой страницы, предоставленного документами AMP, и эквивалентной страницы, выполненной в простом HTML. Я хотел посмотреть, что произойдет, когда я добавлю контент на одну страницу способом AMP, а на другой — обычным способом.
В каждом из этих тестов я использовал Chrome Developer Tools для эмуляции iPhone 6 с «обычным» 3G-соединением со скоростью 750 Кбит / с. В собственных тестах Google использовался практически тот же подход с « симулированным 3G-соединением и симулированным устройством Nexus 5 ».
Я повторил тесты несколько раз, чтобы исключить случайный сбой, вызывающий задержку загрузки. В результатах я также всегда показываю вам самое низкое время загрузки в каждом тесте. В тестах использовался метод обновления страницы «Empty Cache and Hard Reload», чтобы имитировать посадку на контент в первый раз.
Тест 1: одиночное изображение
Во-первых, я начал с базового, включая одно изображение размером 500 КБ (из Unsplash ) на каждой странице.
Результаты
- AMP: 6,23 секунды
- Обычный: 5,48 секунд
В этом первом тесте AMP оказался чуть медленнее, и если вы посмотрите на сетевую панель на скриншотах, вы увидите, что это произошло из-за необходимости загрузки AMP JS плюс немного больший размер HTML-страницы. Больший размер HTML-файла был вызван требованием для некоторого стандартного CSS предотвращать FOUT (флэш-стиль нестандартного текста), пока AMP JS выполняет его обработку.
Примечание: в этом первом тесте я показал скриншот всей тестируемой страницы, чтобы вы могли увидеть настройки, которые я использовал. В следующих нескольких тестах я просто опишу то, что я сделал, и покажу вам сетевую панель, так как в противном случае будет слишком много больших изображений, чтобы вы могли загружаться.
Тест 2: два изображения
Я знал, что идея в том, что AMP начнет выходить вперед, когда будет добавлено больше СМИ. Поэтому я начал делать это во втором тесте, добавив еще одно изображение размером 500 КБ.
Результаты
- AMP: 11,14 секунды
- Регулярно: 10,44 секунды
Опять же, в этом тесте AMP оказался чуть медленнее примерно с той же разницей по той же причине.
Тест 3: пять изображений
До сих пор в тестах дополнительная разметка и JS вызывали незначительное отставание AMP, но теперь пришло время увидеть эффект приоритетов загрузки AMP, в результате чего загрузка контента ниже сгиба откладывается. На этот раз я добавил еще три 500-килобайтных изображения, в результате чего их стало пять.
Результаты
- AMP: 16,14 секунды
- Регулярно: 26,08 секунды
Здесь мы видим, что AMP продвигается вперед с существенным отрывом. Если вы внимательно посмотрите на сетевой график загрузки AMP, вы увидите, что он загружает первые три изображения за 16,14 секунды, а затем позволяет пользователю начать просмотр. После этого он загружает оставшиеся два изображения, что, как вы видите, происходит между 22 и 34 секундной меткой.
С другой стороны, в обычной версии все пять изображений должны быть загружены одновременно, что занимает 26,08 секунды.
Тест 4: пять изображений с прокруткой страницы
В этом тесте я хотел посмотреть, как сравнивается AMP, если страница прокручивалась во время загрузки, что время от времени могут делать заинтересованные посетители.
Результаты
- AMP: 26,87 секунд
- Регулярно: 26,09 секунд
В этом тесте прокрутка препятствовала тому, чтобы любой контент был идентифицирован как ниже сгиба, который выкупил время загрузки до того же самого приблизительного уровня как обычная версия. Обычная версия, как и следовало ожидать, имела время загрузки неизменным путем прокрутки во время загрузки.
Тест 5: Пять изображений с ленивым скриптом загрузки
Поскольку преимущество AMP в скорости в «Тесте 2» было связано с некой ленивой техникой загрузки, я хотел посмотреть, как она будет конкурировать со сценарием, предлагающим сопоставимую функциональность. Чтобы проверить это, я загрузил jQuery и плагин Lazy Load , оба уменьшены, в обычную версию HTML, и установил Lazy Load для запуска по умолчанию.
Результаты
- AMP: 16,14 секунды
- Обычный: 6,59 секунд
Как и ожидалось, скорость загрузки AMP была такой же, как в «Тесте 2». Обычная страница, однако, сократилась с 26,08 секунды до 6,59 секунды с помощью скрипта jQuery Lazy Load.
Здесь важно отметить, однако, что при настройках по умолчанию jQuery Lazy Load извлекает только первое изображение, которое было видно в окне просмотра. AMP, с другой стороны, также загрузил следующие два изображения, которые, как он думал, вы увидите.
Тест 6: изменение порога отложенной нагрузки
Чтобы сделать сравнение еще более четким, я хотел убедиться, что jQuery Lazy Load извлекает первые три изображения, как и AMP. Поэтому я изменил настройку threshold для сценария на 1400 , что означает, что любое изображение размером 1400px за пределами области просмотра также будет загружаться, следовательно, оно будет загружать первые три изображения.
Результаты
- AMP: 16,14 секунды
- Регулярно: 16,51 секунд
Здесь, с обеих страниц, загружающих три изображения, AMP продвинулись вперед с небольшим отрывом.
Загрузка одного и того же количества изображений привела к тому, что два этих файла были приблизительно встроены, что, как мне показалось, один подход не обязательно был лучше, чем другой, скорее, вариант jQuery был более настраиваемым, в то время как AMP был автоматизирован и свободен.
Тест 7: встраивание Twitter и YouTube
В этом тесте я хотел увидеть, как настраиваемые элементы amp-twitter и amp-youtube реализованы «из коробки» по сравнению с собственным встроенным кодом для каждой службы. Я вставил видео и твит на каждой странице, используя каждый метод.
Результаты
- AMP: 11,22 секунды
- Регулярно: 9,56 секунд
В этом тесте пользовательские элементы AMP вышли немного медленнее, чем при использовании встроенного кода. Однако в этом тесте я не использовал несколько видео и твитов друг над другом, чтобы увидеть, как AMO работает с приоритетом загрузки AMP.
С изображениями мы увидели выгоды только после того, как на странице было достаточно контента, что помогло расставить приоритеты при загрузке, поэтому, вероятно, то же самое произойдет и с видео YouTube и твитами.
Тест 8: AMP CDN против GitHub
Следующее, что я хотел попробовать, это посмотреть, какой потенциальный прирост скорости может получиться при подаче страницы с пятью изображениями, которые я использовал в «Тесте 3», из CDP AMP.
Если вы хотите протестировать любую страницу AMP, которая находится в сети, чтобы увидеть, как она обслуживается из CDN, просто добавьте cdn.ampproject.org/c/ перед ее URL-адресом или cdn.ampproject/c/s/ если она загружается поверх HTTPS. Например:
- http://myampsite.com → http://cdn.ampproject.org/c/myampsite.com
- https://myampsite.com → https://cdn.ampproject.org/c/s/myampsite.com
Практика работы CDN заключается в том, что обычная версия страницы будет содержать ссылку на версию AMP в своем разделе заголовка. Google перейдет по этой ссылке, и, распознав новую страницу в качестве сайта AMP, автоматически сохранит ее в CDP AMP.
При тестировании AMP CDN для себя, не забудьте разрешить более длительную загрузку в первый раз, когда страница проходит кеширование, а затем проверьте время загрузки после этого.
Я загрузил свою тестовую страницу на хостинг страниц GitHub, а затем загрузил версию в AMP CDN. Сравнительные времена загрузки, все еще с симулированным соединением iPhone 3G, были следующими.
Результаты
- AMP через CDN: 16,71 секунды
- AMP через GitHub: 16.50 секунд
Два результата были в основном одинаковыми, страницы GitHub работали на одну пятую секунды быстрее.
Тест 9: AMP CDN против личного хоста
Я не был уверен, что GitHub может делать какое-то вуду, чтобы заставить его обслуживать страницы так же быстро, как AMP CDN, поэтому следующий тест, который я провел, сравнил его с моим личным хостингом, который, как я знал, на самом деле не имел необычная оптимизация скорости загрузки.
Результаты
- AMP через CDN: 17,28 секунды
- AMP через персональный хост: 16,33 секунды
Удивительно, но мой личный хостинг обслуживал страницу так же быстро, как и CDN. В этом тесте CDN фактически опустился чуть больше семнадцати секунд.
К сожалению, я не смог создать тест, где AMP CDN показывал страницу быстрее всего. Тем не менее, моя жизнь в Австралии и нахождение за пределами столицы может быть связано с этим. Ваши результаты могут отличаться.
Тест 10: Хранитель до и после AMP
До сих пор во всех тестах я использовал страницы без CSS, только с необработанным контентом. Но ведь мы не так проектируем сайты? Мы усердно работаем над совершенствованием стиля и макета, добавляем немного JavaScript для дополнительных функций, и не все, что необычно, мы можем быть склонны использовать больше кода, чем это абсолютно необходимо.
Кроме того, выполнение нескольких тестов с базовым контентом — это не то же самое, что тестирование полных сайтов с живым, реальным контентом. В этом контексте реальный тест, вероятно, исходит из тестирования живых сайтов до и после оптимизации AMP.
Вот что я сделал дальше, начиная со статьи в The Guardian. Сначала я протестировал обычную HTML-версию статьи, а затем AMP-версию той же самой статьи.
Результаты
- Предварительно AMP: 5,05 секунды
- Сообщение AMP: 3,87 секунды
Здесь мы начинаем видеть значительное улучшение между версиями до и после AMP, сокращая время загрузки на 1,18 секунды. Это улучшение на 23%, довольно солидно!
Тест 11: BBC News до и после AMP
В следующем тесте, последнем, о котором я буду говорить, я сравнил версию по умолчанию для новостной статьи BBC с ее версией AMP. Как и в тесте на The Guardian, одна и та же статья тестируется в каждом из ее форматов.
Результаты
- Предварительно AMP: 20,44 секунды
- Сообщение AMP: 2,74 секунды
Хорошо, теперь мы говорим. Это увеличение скорости огромно . Переход с 20,44 секунды до 2,74 секунды — это даже немного больше, чем 85% -ное улучшение по сравнению с ранними тестами AMP. На самом деле это улучшение на 86% .
Внимательно посмотрите на скриншоты, в частности диаграммы, изображающие загрузку каждого отдельного ресурса с зеленой / красной / синей горизонтальной полосой. Количество ресурсов, загружаемых в предварительной версии AMP, составляет бананы. Сравните это с диаграммой в пост-версии AMP, где количество ресурсов было определено. Неудивительно, что оптимизация смогла создать такое большое улучшение.
Здесь на ум приходят два вопроса.
Во-первых, можно ли достичь такой степени оптимизации без AMP? Да, я думаю, что это возможно.
Второе, была бы достигнута такая степень оптимизации без AMP? Нет, по всей вероятности, этого не произойдет.
За пределами контролируемого тестирования, в реальной организации разработчики могут захотеть оптимизировать производственный сайт, но они не могут быть в состоянии оттолкнуться от коллег, которым необходимо сосредоточиться на монетизации и аналитике. Обе стороны пытаются выполнить свою работу, и, возможно, они не смогут найти общий язык.
Вот где AMP стремится вмешаться и преодолеть разрыв. Они создают строгую структуру оптимизации, которой необходимо придерживаться, если вы хотите получить одобрение AMP, что делает разработчиков счастливыми. Но они также обеспечивают интегрированную монетизацию, аналитику и, возможно, большую доступность в Google, что радует людей, ответственных за потоки доходов.
Если вы разработчик, оказавшийся в такой ситуации, эти результаты показывают, что AMP может быть именно тем, что доктор прописал.
Итак, AMP сделает мои сайты быстрее?
В этой статье мы многое изучили, и все с целью выяснить, сможет ли в конечном итоге AMP сделать ваши сайты быстрее. Кажется, что ответ зависит не только от технических соображений ваших сайтов, но и от практических потребностей компаний, которые эти сайты поддерживают.
Если вы принимаете все решения о том, как создаются ваши сайты, AMP может сделать ваши сайты быстрее, если:
- Вы используете достаточно носителей, чтобы воспользоваться оптимизированными процессами загрузки.
- Вы бы предпочли, чтобы AMP направлял процесс оптимизации, а не выполнял его вручную.
В то же время, если вы можете оптимизировать свои сайты в соответствии с вашими полномочиями по принятию решений, вы можете получить столь же хорошие или, возможно, лучшие результаты, используя собственные методы оптимизации, если они находятся на уровне, сопоставимом с тем, что AMP делает.
Если вы не можете принять все решения о том, как создаются ваши сайты, AMP может сделать ваши сайты быстрее, если:
- Это позволяет вам убедить ваших коллег одобрить его реализацию, и, следовательно, дает вам возможность применять оптимизации, для которых вы не получили бы зеленый свет.
Я думаю, что суть в том, что сам AMP не быстр — это неправильный способ выразить это.
AMP дает вам способ сделать ваши сайты быстрыми.
Вам не обязательно использовать этот метод, но если вам нужен удобный или тот подход, который примут ваши коллеги, AMP может быть правильным выбором для вас.
Завершение
AMP — все еще очень новый проект, так что это хорошая идея, чтобы внимательно следить за ним по мере его развития. То, что это значит для вашего рейтинга в поисковых системах, может измениться в любое время, как и требования использования AMP или его производительности.
В тестах, которые я запускал, AMP был немного медленнее в определенных обстоятельствах, но, поскольку проект продолжается, я уверен, что он станет более эффективным, и мы могли бы увидеть, что эти результаты станут неактуальными. В то же время, вне контролируемых тестов, было ясно, что на крупных живых сайтах применение оптимизации AMP иногда приводило к значительному увеличению производительности.
Я чувствую, что независимо от того, решите ли вы на самом деле использовать AMP или нет, каждый должен, по крайней мере, очень внимательно посмотреть на это. Это потенциально отличный источник идей для разработчиков о том, как они могут повысить оптимизацию своих сайтов, если ничего больше.
С новым внедрением страниц AMP в результаты поиска Google будет очень интересно следить за отзывами первых пользователей AMP. Причина, по которой я говорю это, состоит в том, что можно предположить, что они будут продолжать использовать AMP, только если это приведет к увеличению удержания трафика и доходов. То, что происходит в этом отношении, вполне может стать причиной или разрушением AMP.
До тех пор, возможно, самым большим выводом из появления AMP является то, что оптимизация сайтов в максимально возможной степени, вероятно, станет все более важной. Дни раздутых таблиц стилей и чрезмерного JavaScript, не говоря уже о властной рекламе, могут вскоре отойти от нас, как заставки Flash-анимированных сайтов.
И это то, что мы все можем быть счастливы.
Ссылки по теме:
- Представляем проект «Ускоренные мобильные страницы» в официальном блоге Google
- www.ampproject.org
- Проект AMP на Github
- AMP WordPress плагин
- Ускоренные мобильные страницы (AMP) для WordPress на Envato Market