Все, что вам нужно знать об ускоренных мобильных страницах Google

В мае 2015 года Facebook представила новую платформу для публикации в приложениях Instant Articles. Месяц спустя Apple объявила, что старый опыт работы с Newsstand (по сути, причудливая папка, полная новостных приложений) будет заменен в iOS 9 совершенно новой платформой для сбора и поиска новостей под названием Apple News.

Дальнейшее чтение о Smashing:

• Воспринимаемая производительность
• Предварительная загрузка: для чего она нужна?
• Подготовка к HTTP/2
• Прогрессивное улучшение
• Прогрессивные веб-AMP

Четыре месяца спустя настала очередь Google объявить о своем собственном, несколько запоздалом, но не менее амбициозном плане революционизировать потребление мобильных новостей с помощью веб-решения с открытым исходным кодом под названием Accelerated Mobile Pages или AMP. Всего за несколько месяцев мы стали свидетелями того, как относительное спокойствие мобильной цифровой публикации переросло в еще одну полномасштабную войну платформ, поскольку Facebook, Apple, а теперь и Google соревнуются как за лояльность издателей, так и за внимание читателей.

В то время как Facebook и Apple значительно опережают Google, есть все основания полагать, что AMP быстро догонит их (и может даже превзойти одного или обоих своих конкурентов). Если вы разработчик или издатель, которому необходимо как можно быстрее и эффективнее узнать, почему, что и как использовать ускоренные мобильные страницы Google, вы обратились по адресу.

Но в чем проблема?

Прежде чем мы обсудим решения, стоит уделить немного времени изучению проблемы. Если вы много читаете на мобильных устройствах, вполне вероятно, что вы уже слишком хорошо осведомлены о том, что взаимодействие с веб-контентом на телефоне или планшете варьируется от едва приемлемого до ужасающего. Страницы часто загружаются медленно, отображаются хаотично и ведут себя непредсказуемо по двум основным причинам:

• вмешательство третьих лиц . Рекламные объявления и связанные с ними методы отслеживания не только добавляют объем и дополнительные запросы к устройству, которое и без того ограничено пропускной способностью и ЦП, но и страницы часто ведут себя так, как будто они одержимы, поскольку они конвульсивно конвульсируют вокруг многочисленных вызовов document.write() . The New York Times недавно провела тест, который показал значительное уменьшение размеров страниц и увеличение времени автономной работы после установки блокировщика контента iOS.
• побочный ущерб от адаптивного дизайна . Хотя большинство веб-сайтов с адаптивным дизайном хорошо выглядят на экранах любого размера, они часто содержат много багажа веб-сайтов для настольных компьютеров при просмотре на мобильных устройствах. Когда Пол Айриш провел аудит производительности Reddit, он обнаружил, что большая часть накладных расходов может быть связана с активом под названием SnooIcon, талисманом Reddit, отображаемым в SVG, чтобы его можно было анимировать (сторонней библиотекой, то есть больше накладных расходов) при наведении курсора — не та ситуация, в которой активы часто оказываются на мобильных устройствах.

Мгновенные статьи Facebook, новости Apple и ускоренные мобильные страницы — наши спасители из мира, где, по данным Facebook (PDF, 3,4 МБ), среднее время загрузки статьи на мобильных устройствах составляет 8 секунд. Хотя называть 8 секунд вечностью — это, очевидно, преувеличение, учитывая, что за это время вы могли бы хорошо просмотреть свое второе видео на Vine, вероятно, будет справедливо сказать, что по сегодняшним меркам это как минимум целая эпоха.

Короткая демонстрация мгновенных статей Facebook, Apple News и ускоренных мобильных страниц. Обратите внимание, что Facebook Instant Articles и Apple News — это возможности приложений, тогда как AMP полностью основан на браузере.

Чем отличается AMP?

Некоторый контекст того, чем AMP отличается от Facebook Instant Articles и Apple News, прояснит некоторые решения, принятые Google для своей новой инициативы цифровых публикаций.

Facebook Instant Articles и Apple News имеют несколько общих характеристик:

• опыт в приложении . Читатели получают доступ к мгновенным статьям Facebook через Facebook на мобильных устройствах, а Apple News — это отдельное приложение, поставляемое с iOS 9. В настоящее время ни одна из платформ не позволяет пользователям просматривать статьи в их конкретных форматах вне соответствующего приложения. Думайте об обоих как об обновлении RSS для конкретного приложения.
• на основе синдикации . В то время как Facebook Instant Articles и Apple News используют очень разные форматы синдикации (формат Apple News основан на JSON, а Instant Article Markup — это более или менее HTML, обернутый в RSS-канал), они основаны на схожих принципах: уговорите вашу CMS генерировать необходимые форматы синдикации, а Facebook или Apple News проглотят их, проанализируют и сделают красивыми и быстрыми с помощью настраиваемых и оптимизированных средств визуализации.
• ориентированный на опыт . Хотя Facebook Instant Articles и Apple News ориентированы на производительность, они в равной степени заботятся о том, чтобы статьи выглядели и чувствовались современно. Обе платформы имеют компоненты, обеспечивающие гладкое и гладкое взаимодействие, которое мы обычно ассоциируем с индивидуальными, созданными вручную впечатлениями от чтения.

Напротив, ускоренные мобильные страницы имеют четкую направленность:

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

Что такое AMP?

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

• Нет простой модели для сравнения. Когда RSS был новым, мы все восхищались его мощью, писали бесчисленные статьи и сообщения в блогах о его разрушительном потенциале, объявляли домашнюю страницу мертвой (еще раз), а затем продолжали забывать о ней. Facebook Instant Articles и Apple News — это, по сути, перезагрузка RSS, за исключением того, что они избавлены от всех неудобств стандартов, и каждый из них работает только в одном приложении.
• AMP не является клиентом. . В то время как Facebook Instant Articles, Apple News и AMP имеют несколько общих элементов, таких как проприетарные форматы синдикации и настраиваемые средства визуализации, AMP является единственным без специального клиента (кроме браузера). В большей степени, чем его собратья, AMP представляет собой набор спецификаций, соглашений и технологий, которые можно объединить в решение, а не комплексное решение (от издателя к читателю) само по себе.

Теперь, когда мы знаем, что AMP можно рассматривать как набор ингредиентов, а не как полностью испеченный торт, давайте посмотрим, что представляют собой эти отдельные компоненты:

• AMP HTML,
• среда выполнения AMP,
• кэш AMP.

AMP HTML

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

Поскольку AMP HTML разработан для обеспечения оптимальной производительности, чтобы понять и оценить его ценность, нам необходимо понять проблемы, которые он решает. Вот три самые большие вещи, которые ухудшают загрузку и отображение веб-страниц на мобильных устройствах:

• размер полезной нагрузки . Адаптивный веб-дизайн сослужил нам хорошую службу, потому что он позволяет нам создавать единый веб-сайт для каждого устройства и экрана. Но это также иногда означает доставку полезной нагрузки размером с настольный компьютер (HTML, JavaScript, CSS и ресурсы) на мобильные устройства с чрезвычайно ограниченной пропускной способностью и ЦП. (Те, кто думает о своих телефонах как о маленьких настольных компьютерах, слишком высоко оценивают мобильное оборудование. У вашего iPhone 6s 2 ГБ оперативной памяти, а у вашего ноутбука, вероятно, 8 или 16.)
• загрузка ресурсов . Ресурсы не всегда загружаются в оптимальном порядке, а это означает, что пропускная способность, ЦП и ОЗУ часто используются для ресурсов, которые пользователи могут даже не увидеть. Кроме того, ресурсы часто не объявляют свою ширину и высоту (особенно когда они обслуживаются через рекламные сети или внедряются через вызовы document.write() ), что не только приводит к изменению размера страницы, поскольку размеры ресурсов определяются лениво, но и вызывает ненужные и дорогие перерасчеты компоновки. Вот что заставляет веб-страницы прыгать, как котята, гоняющиеся за лазером, когда они так медленно проявляются.
• Выполнение JavaScript . Я не собираюсь затрагивать здесь тему производительности JavaScript, но современные веб-сайты часто нагромождают его мегабайтами, и хотя на настольных компьютерах он может выполняться без каких-либо заметных задержек, мобильные устройства — это все же совсем другая среда, где, как мне кажется, мы все можем согласиться, JavaScript лучше свести к минимуму.

Учитывая эти три барьера для гибкого веб-интерфейса на мобильных устройствах, AMP HTML в основном существует для трех целей:

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

HTML-теги AMP

Ниже приведен список тегов, которые полностью запрещены в AMP HTML:

• script Это, очевидно, большой. Ниже я расскажу более подробно о позиции AMP в отношении JavaScript; на данный момент просто предположим, что единственные теги script , которые у вас будут в документах AMP, — это те, которые загружают среду выполнения AMP, и, при необходимости, тег для связанных данных на основе JSON.
• base Тег base , по-видимому, запрещен из соображений предосторожности, и он может оказаться в белом списке, если сообщество пожалуется. (Я предполагаю, что никого это не волнует так или иначе.)
• frame и frameset В любом случае не совсем удачное использование мобильной недвижимости, так что скатертью дорога.
• object , param , applet и embed К сожалению, ваши документы AMP не будут содержать аплетов Flash или Java. (Это был сарказм, если не совсем очевидно.)
• form и элементы input (за исключением тега button ). Поддержка форм, вероятно, в конечном итоге будет реализована в виде инкапсулированных компонентов, поскольку их использование без сценариев ограничено.

Вот список тегов, которые заменяют свои HTML-аналоги, чтобы оптимизировать загрузку ресурсов и обеспечить соблюдение передовых методов безопасности:

• [amp-img](https://www.ampproject.org/docs/reference/amp-img.html) Заменяет тег img и оптимизирует загрузку ресурсов, принимая во внимание такие факторы, как положение окна просмотра, системные ресурсы и возможности подключения.
• [amp-video](https://www.ampproject.org/docs/reference/amp-video.html) Заменяет тег video HTML5, чтобы видеоконтент мог загружаться лениво (с учетом области просмотра).
• [amp-audio](https://www.ampproject.org/docs/reference/extended/amp-audio.html) Заменяет audio HTML5, чтобы можно было лениво загружать аудиоконтент (с учетом области просмотра).
• [amp-iframe](https://www.ampproject.org/docs/reference/extended/amp-iframe.html) Тег amp-iframe обеспечивает соблюдение передовых методов безопасности, выполняя такие действия, как изолирование содержимого по умолчанию и накладывая ограничения на где могут появляться фреймы, чтобы гарантировать, что они не будут доминировать в документе AMP.

Наконец, вот все теги, которые вводит AMP HTML для добавления функциональности или интерактивности в ваши документы, не требуя от вас написания JavaScript:

• [amp-ad](https://www.ampproject.org/docs/reference/amp-ad.html) . Тег amp-ad позволяет среде выполнения AMP управлять загрузкой рекламы так же, как и всеми другими загружаемыми извне ресурсами (в настоящее время , реклама загружается последней), и это гарантирует, что JavaScript из рекламных сетей не сможет выполняться внутри родительского документа AMP или запускать ненужные вычисления макета. (До свидания, document.write() !)
• [amp-analytics](https://www.ampproject.org/docs/reference/extended/amp-analytics.html) Этот миниатюрный фреймворк упаковывает аналитические данные и отправляет их сторонним поставщикам. На сегодняшний день поддержка AMP обеспечивается Adobe Analytics, Chartbeat, ClickTale, comScore, Google Analytics, Nielsen и Parse.ly.
• [amp-pixel](https://www.ampproject.org/docs/reference/amp-pixel.html) Используется для встраивания веб-маяков и поддерживает токены для отправки нескольких клиентских переменных на сервер.
• [amp-carousel](https://www.ampproject.org/docs/reference/extended/amp-carousel.html) Этот оптимизированный компонент отображает дочерние изображения в интерактивной горизонтальной ориентации.
• [amp-lightbox](https://www.ampproject.org/docs/reference/extended/amp-lightbox.html) Это позволяет читателям открывать изображения в полноэкранном режиме «лайтбокс». Он поддерживает спецификацию как миниатюрных, так и полноразмерных изображений.
• [amp-anim](https://www.ampproject.org/docs/reference/extended/amp-anim.html) . Он загружает анимированные GIF-файлы и предоставляет столь необходимые функции заполнителя.
• [amp-font](https://www.ampproject.org/docs/reference/extended/amp-font.html) Установите время ожидания загрузки для пользовательских шрифтов и укажите резервные шрифты, если ваши пользовательские шрифты не загрузятся в отведенное время. .
• [amp-fit-text](https://www.ampproject.org/docs/reference/extended/amp-fit-text.html) Тексту внутри тега amp-fit-text будет автоматически назначен размер шрифта, оптимизированный для доступное пространство. Думайте об этом как о небольшой готовой отзывчивости.
• [amp-list](https://www.ampproject.org/docs/reference/extended/amp-list.html) С помощью тега amp-list вы можете загружать динамические повторяющиеся данные JSON, а затем отображать их с помощью HTML. шаблон. (См. тег amp-mustache ниже.)
• [amp-mustache](https://www.ampproject.org/docs/reference/extended/amp-mustache.html) Это поддерживает рендеринг HTML-шаблонов Mustache.
• [amp-install-serviceworker](https://www.ampproject.org/docs/reference/extended/amp-install-serviceworker.html) Если вы решите не использовать кэш AMP (подробнее о кэшировании ниже), Тег amp-install-serviceworker загружает и устанавливает сервис-воркер для текущей страницы. Сервисные работники шустрые, но, на мой взгляд, пока рано на них полагаться.
• [amp-youtube](https://www.ampproject.org/docs/reference/extended/amp-youtube.html) . Как и ожидалось, это встраивает видео YouTube с указанным идентификатором видео.
• [amp-twitter](https://www.ampproject.org/docs/reference/extended/amp-twitter.html) Встраивайте твиты (карточки Twitter необязательны).
• [amp-instagram](https://www.ampproject.org/docs/reference/extended/amp-instagram.html) Встраивайте изображения из Instagram.
• [amp-brightcove](https://www.ampproject.org/docs/reference/extended/amp-brightcove.html) Этот компонент загружает и отображает видео (и видеоплеер) из Brightcove.
• [amp-pinterest](https://www.ampproject.org/docs/reference/extended/amp-pinterest.html) виджет Pinterest или кнопку «Прикрепить» в свой документ AMP.
• [amp-vine](https://www.ampproject.org/docs/reference/extended/amp-vine.html) Вставьте указанное видео Vine в свой документ AMP.

Обратите внимание, что, хотя теги с префиксом amp- не совсем соответствуют стандарту HTML, они также не являются собственностью. Скорее, это легитимные пользовательские элементы с реализациями JavaScript, которые выполняют такие функции, как применение лучших методов безопасности и определение приоритета загрузки удаленных ресурсов (подробнее об этом в разделе «Среда выполнения AMP» ниже). Другими словами, хотя AMP HTML может подозрительно походить на стратегию охвата, расширения и уничтожения, на самом деле это просто умное применение веб-стандартов и не так уж сильно отличается от пользовательских атрибутов data- .

Стилизация AMP HTML

Стилизация документов AMP выполняется с помощью стандартного CSS и не сильно отличается от того, как вы уже оформляете контент. Однако имейте в виду несколько вещей:

• Все стили должны выполняться с помощью встроенной таблицы стилей — без внешних связанных таблиц стилей и встроенных стилей на уровне элемента. (Внешне связанная таблица стилей потребует загрузки дополнительного документа, прежде чем можно будет рассчитать макет, а встроенные стили на уровне элементов могут раздуть документ.)
• Размер стилей ограничен 50 КБ. Философия Google заключается в том, что 50 КБ достаточно для хорошего документа или статьи, но недостаточно для хорошего веб-сайта.
• Ваша встроенная таблица стилей должна иметь атрибут amp-custom (например <style amp-custom> ).
• Правила @ — @font-face (подробнее о шрифтах ниже), @keyframes и @media — разрешены.
• Некоторые селекторы имеют ограничения, которые, как известно, снижают производительность, например универсальный селектор ( * ) и селектор :not() .
• Квалификатор !important запрещен, чтобы гарантировать, что среда выполнения AMP имеет последнее слово в отношении размеров элементов.
• Стилизация пользовательских компонентов AMP, таких как amp-carousel , выполняется путем переопределения классов по умолчанию, таких как .amp-carousel-button-prev , или с помощью предопределенного набора пользовательских свойств CSS, таких как --arrow-color .
• Все загружаемые извне ресурсы должны иметь указанные свойства ширины, высоты и макета (подробнее о макете ниже), чтобы свести к минимуму дорогостоящие пересчеты макета DOM.
• Разрешены переходы и анимация, которые могут быть ускорены с помощью графического процессора (и которые не вызывают повторных вычислений). В настоящее время opacity и transform занесены в белый список.

Дополнительные сведения о стилях документов см. в спецификации AMP HTML.

Шрифты

AMP с радостью поддерживает пользовательские шрифты с некоторыми оговорками:

• Шрифты должны быть загружены с помощью тега ссылки или правила CSS @font-face . Другими словами, вы не можете загружать шрифты с помощью JavaScript.
• Все шрифты должны передаваться через HTTPS.
• Поставщики шрифтов должны быть внесены в белый список. В настоящее время единственными поставщиками из белого списка являются fonts.googleapis.com и fast.fonts.net . Но, учитывая, как быстро издатели, рекламодатели и поставщики аналитики добавляют поддержку AMP, я подозреваю, что скоро их станет больше.

Макет

Подход AMP к макету был задуман вокруг двух основных целей:

• Среда выполнения должна иметь возможность определить размер всех внешних загружаемых ресурсов до того, как они будут фактически загружены, чтобы окончательный макет можно было рассчитать как можно быстрее. После расчета макета статья может быть отображена, и читатели могут начать взаимодействовать с ней, даже если реклама, изображения, аудио и видео еще не завершили загрузку. (И по мере загрузки этих ресурсов они будут отображаться плавно, не нарушая процесс чтения за счет обновления макета документа.)
• Статьи AMP должны быть адаптивными. Как следует из названия «Ускоренные мобильные страницы», документы AMP специально предназначены для мобильных устройств; поэтому в этом контексте «отзывчивый» не включает разрешения рабочего стола. Скорее, документы AMP должны хорошо выглядеть на всех мобильных устройствах, от тех крошечных старых реликвий iPhone 4, которые люди все еще используют, до относительно гигантских iPad Pro.

Первая цель в первую очередь достигается требованием, чтобы все загружаемые извне ресурсы имели атрибуты width и height (и это дополнительно усиливается за счет ограничения сценариев, что гарантирует, что новые ресурсы не могут быть загружены). Последнее достигается с помощью стандартных медиа-запросов, атрибута media , атрибута sizes и атрибута layout , характерного для AMP.

Ниже приводится обзор макетов, которые в настоящее время поддерживает AMP:

• nodisplay Элемент изначально не отображается, но отображение может быть вызвано действием пользователя. (Это используется в сочетании с такими компонентами, как amp-lightbox .)
• fixed Элемент имеет фиксированную ширину и высоту, что означает, что среда выполнения не может применять какое-либо адаптивное поведение.
• responsive На мой взгляд, это самый полезный и волшебный вариант макета AMP. Элемент использует все выделенное пространство, сохраняя соотношение сторон. (По сути, «Сделайте так, чтобы эта штука хорошо выглядела в любом разрешении, пожалуйста и спасибо».)
• fixed-height Элемент использует выделенное пространство, но сохраняет фиксированную высоту (масштабируется по горизонтали).
• fill Элемент заполняет контейнер, в котором он находится, независимо от соотношения сторон. (Думаю, width: 100% и height: 100% .)
• container Элемент является контейнером и, следовательно, позволяет своим дочерним элементам (в отличие от родителя) определять свой размер точно так же, как стандартный элемент div .

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

Что насчет SVG?

Поддерживается! Базовый SVG имеет всестороннюю поддержку как в настольных, так и в мобильных браузерах, а графика не становится намного более отзывчивой, чем векторы, поэтому AMP и SVG составляют очень хорошую команду. Самое большое ограничение заключается в том, что из-за ограничений сценариев вы не сможете анимировать свои векторы с помощью JavaScript — что, если быть честным, вам, вероятно, в любом случае не следует делать на мобильных устройствах. Однако, если вам действительно необходимо вдохнуть немного жизни в свой SVG, вы все равно можете сделать это с помощью CSS-анимации в соответствии с теми же ограничениями, изложенными в разделе о стилях выше. Помните, что SVG является частью DOM, поэтому его можно стилизовать и анимировать так же легко, как и любой другой элемент.

Философия AMP в JavaScript

Хорошие новости и плохие новости здесь. Плохая новость заключается в том, что в ближайшее время вы не будете писать JavaScript для своих AMP-документов. Но в каком-то смысле это и хорошая новость. Имейте в виду, что AMP — это не фреймворк для мобильных приложений . Скорее, это мобильная структура статей , и, поскольку статьи должны быть оптимизированы для плавного и плавного чтения, на самом деле не так много хороших вариантов использования тяжелых сценариев на стороне клиента.

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

Признавая как нагрузку, которую налагает произвольный написанный пользователем JavaScript на гарантии производительности, так и вездесущность и неизбежность JavaScript в современной веб-среде, команда AMP разработала следующие принципы написания сценариев:

• В настоящее время пользовательский JavaScript не поддерживается и не разрешен. В ваших документах AMP может быть только два типа тегов сценария: теги связанных данных (тип которых — application/ld+json ) и теги для включения как среды выполнения AMP, так и расширенных компонентов AMP.
• Авторы проекта AMP предвидели большую часть потребностей в JavaScript в контексте потребления мобильных статей, поэтому AMP либо поддерживает альтернативы ( amp-pixel , включая пользовательские шрифты с тегами ссылок или правила @font-face и т. д.), либо предоставляет реализации, совместимые со средой выполнения AMP и, следовательно, гарантирующие как безопасность, так и производительность ( amp-ad , amp-analytics , amp-carousel и т. д.).
• Если вам действительно необходимо использовать JavaScript для чего-то вроде интерактивной функции, вы можете создать эту функцию самостоятельно, а затем включить ее в [amp-iframe](https://www.ampproject.org/docs/reference/extended/amp-iframe.html) . [amp-iframe](https://www.ampproject.org/docs/reference/extended/amp-iframe.html) тег. Содержимому, включенному в amp-iframe , разрешено даже ограниченное взаимодействие с родительским документом для таких вещей, как запросы на изменение размера.
• Компоненты AMP имеют открытый исходный код (Apache 2) и открыты для участия, поэтому со временем будут появляться новые компоненты (на самом деле, в ходе написания и редактирования этой статьи появилось несколько новых компонентов, поэтому я уже несколько раз обновлял ее). Хотя команда AMP будет отдавать приоритет обобщенным компонентам, а не функциям, специфичным для службы (например, виджет специально для вашего социального стартапа), она также стремится обеспечить достаточное разнообразие для размещения максимально широкого спектра контента.
• Наконец, все эти политики могут быть изменены. По мере того, как функции браузера, такие как веб-воркеры, пользовательские элементы и теневая модель DOM, будут поддерживаться все шире, возможности для поддержки написанного пользователем JavaScript и пользовательских компонентов — при сохранении гарантии безопасности и производительности — будут значительно расширяться.

Дополнительные сведения о будущем компонентов AMP см. в разделе «Расширенные компоненты» спецификации «Компоненты AMP HTML».

Анатомия документа AMP

Теперь, когда у вас есть довольно четкое представление об AMP HTML, давайте разберем шаблон.

Конечно, вы начнете свои документы doctype с объявления типа документа:

 <!doctype html>

Затем обозначьте свой HTML-документ как AMP HTML, что, хотите верьте, хотите нет, вы делаете, используя эмодзи высокого напряжения в качестве атрибута в теге html :

 <html >

Или, если вы старомодный скряга и недовольны идеей украсить свой код очаровательными смайликами, вместо этого вы можете использовать гораздо более консервативный атрибут amp :

 <html amp> <!-- A good sign that you're boring! -->

В теге head не забудьте инструкции по кодировке символов utf-8 :

 <meta charset="utf-8">

И ссылку на не-AMP-версию вашего документа (помеченную как canonical , чтобы она не отображалась как дублирующийся контент):

 <link rel="canonical" href="my-non-amp-index.html">

И наоборот, ваша версия без AMP должна содержать ссылку на документ AMPlified:

 <link rel="amphtml" href="my-amp-index.html">

Поскольку страницы AMP предназначены для мобильных устройств (и вам также нужна растеризация с помощью графического процессора), обязательно включите метатег viewport :

 <meta name="viewport" content="width=device-width,minimum-scale=1,initial-scale=1">

Следующая строка кода покажется немного странной, и это потому, что так оно и есть. Вы знаете, как иногда вы видите, как веб-страница на короткое время отображает текст до того, как шрифты будут загружены и применены, затем мерцает и снова отображается так, как задумал дизайнер? Тег ниже сохраняет непрозрачность страницы равной 0 (невидимая), пока она не будет правильно оформлена.

 <style> body { opacity: 0 } </style> <noscript> <style> body { opacity: 1 } </style> </noscript>

Проблема с этим подходом заключается в том, что если среда выполнения AMP не загружается, технически возможно, что непрозрачность страницы никогда не изменится с 0 до 1 . Чтобы компенсировать такие непредвиденные обстоятельства, приведенный выше код, вероятно, будет изменен на что-то более близкое к этому:

 <style> body { animation: amp-timeout 0x 5s 1 normal forwards; } @keyframes amp-timeout { 0% {opacity: 0;} 100% {opacity: 1;} } </style>

Следующее, что нужно сделать, это включить среду выполнения AMP JavaScript:

 <script async src="https://cdn.ampproject.org/v0.js"></script>

И включите реализации JavaScript для любых расширенных компонентов, которые вам нужны:

 <script async custom-element="amp-youtube" src="https://cdn.ampproject.org/v0/amp-youtube-0.1.js"></script> <script async custom-element="amp-audio" src="https://cdn.ampproject.org/v0/amp-audio-0.1.js"></script> <script async custom-element="amp-carousel" src="https://cdn.ampproject.org/v0/amp-carousel-0.1.js"></script> <script async custom-element="amp-lightbox" src="https://cdn.ampproject.org/v0/amp-lightbox-0.1.js"></script> <script async custom-element="amp-anim" src="https://cdn.ampproject.org/v0/amp-anim-0.1.js"></script> <script async custom-element="amp-twitter" src="https://cdn.ampproject.org/v0/amp-twitter-0.1.js"></script> <!-- etc. -->

(Обратите внимание на использование атрибута async . Это необязательно — чем меньше блокировки, тем лучше.)

При желании вы можете добавить немного связанных данных, например:

 <script type="application/ld+json"> { "@context": "https://schema.org", "@type": "NewsArticle", "headline": "Turn Your AMP up to 11!", "image": [ "img/cover-opt.jpg" ], "datePublished": "2015-01-11T08:00:00+08:00" } </script>

Теперь давайте добавим несколько шрифтов, используя либо теги link , либо правила @font-face в вашем CSS:

 <link href='https://fonts.googleapis.com/css?family=Roboto+Condensed:300,700' rel='stylesheet' type='text/css'> <link href='https://fonts.googleapis.com/css?family=Lora:400,700,400italic,700italic' rel='stylesheet' type='text/css'>

А затем мы добавим несколько стилей (не более 50 КБ) с обязательным атрибутом amp-custom :

 <style amp-custom>

Теперь вы готовы создать более или менее стандартный HTML-документ, используя все, что вы только что узнали об AMP HTML.

Среда выполнения AMP

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

Среда выполнения AMP полностью реализована на JavaScript и инициируется ее включением в документ AMP, как и любой внешний файл JavaScript:

 <script async src="https://cdn.ampproject.org/v0.js"></script>

Оттуда среда выполнения AMP в основном делает три вещи:

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

Валидатор имеет решающее значение для создания документов, совместимых с AMP. Его можно включить, просто добавив #development=1 к URL-адресу документа. Затем все, что вам нужно сделать, это открыть консоль, чтобы увидеть свой табель успеваемости.

Ошибки выглядят так:

Красивый, чистый, совместимый документ AMP выглядит примерно так:

Кэш AMP (необязательно)

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

• Ссылки на изображения могут быть заменены изображениями, размер которых соответствует области просмотра зрителя.
• Изображения над сгибом можно встроить, чтобы сохранить дополнительные HTTP-запросы.
• Переменные CSS могут быть встроены, чтобы уменьшить накладные расходы на стороне клиента.
• Расширенные реализации компонентов AMP могут быть предварительно загружены.
• HTML и CSS можно минимизировать, чтобы уменьшить количество байтов, отправляемых по сети (или, в данном случае, по эфиру).

Любой может запустить свой собственный кеш AMP на своей собственной CDN, или издатели могут бесплатно использовать Google. Учитывая, что Google, кажется, знает кое-что о масштабируемости, я предполагаю, что большинство пользователей AMP будут рады принять это предложение. (Documentation on how to opt in to Google's cache is forthcoming, but given that Google already indexes and caches the Internet, it's a safe bet that it will revolve around your link tags and perhaps an additional meta tag.)

How Do Readers Find AMP Content?

The fact that AMP document are more or less standard HTML that will render in any modern browser is, in my opinion, a huge advantage (AMP is far more open and inclusive than Facebook Instant Articles or Apple News). But from a practical perspective, it also raises the question of how audiences will find AMP content.

If readers use Google to search from a mobile device, Google can link directly to AMP versions of articles (Google has not said that it will prioritize AMP documents over non-AMP documents, but it has said that it will use “mobile friendliness” as a mobile search signal, so you do the math). In fact, Google has indicated that it will begin sending traffic to AMP pages from Google Search on mobile as early as late February 2016. Discovery and curation engines such as Pinterest may also choose to start directing mobile traffic to AMP pages (with a few infrastructure changes). Finally, websites can redirect their own mobile traffic from responsive versions of articles to their AMP counterparts. But from my perspective, a few pieces of the puzzle are still missing.

Will other search engines direct mobile traffic to AMP articles? (Perhaps not search engines that want to do business with Apple.) Will social networking apps preload AMP documents when users post links to articles, in order to make rendering nearly instantaneous? (Probably not Facebook.) Will mobile browsers start looking for link tags with amphtml relationships? (Chrome, maybe, but probably not mobile Safari.) And will aggregators and news readers out there build specifically for lightning-fast AMP content? (Time to resurrect Google Reader!)

At this point, the answers to most of these questions are the same: to be determined.

See AMP In Action

The easiest way to see AMP in action is to check out Google's search demo. If you're the trusting type, you can watch the video and just assume it all works as well as it's depicted. If you're more the trust-but-verify type, you can go to g.co/ampdemo on your mobile device and try out some AMP pages for yourself (QR code below).

You can also check out the AMP experience through desktop Chrome using Chrome's Developer Tools. All you have to do is this:

1. Go to g.co/ampdemo in Chrome.
2. Open the Developer Tools by going to “View” → “Developer” → “Developer Tools.”
3. Go into device mode by clicking on the little phone icon in the top-left corner.
4. Pick your favorite device to emulate. (For best results, reload the page in the emulator.)

Who's Adopting AMP?

It's still relatively early days for AMP, so it's hard to tell exactly who is adopting the new format in earnest, and to what extent. That being said, I've already seen several implementations out there in the wild, and according to the AMP FAQ and AMP blog, it's being taken seriously by many major publishers (metered content and subscription access is currently under review), CMS developers, advertisers, and analytics providers. I won't list them all here because I'm sure the landscape will change almost daily, but you can keep an eye on the AMP project's home page and/or the AMP blog for news.

What Do I Think?

I'm glad you asked. My guess is that just about all publishers will eventually adopt it. If companies like BuzzFeed have taught the industry anything, it's the importance of being in as many places as possible, and that digital publishing should be a technology platform capable of getting content in front of readers wherever they are, as opposed to being a singular destination waiting for readers to come to it.

The investment required to support AMP is also relatively minimal. If a publisher already supports — or plans to support — Facebook Instant Articles and Apple News, then they might as well implement support for AMP as well. While CMS strategies vary widely across the publishing industry, most CMS' have a concept of templates and/or plugins that, once implemented, would do most of the work of converting articles into AMP HTML. (WordPress, the closest thing we have to an industry leader, already has a plugin and plans on supporting AMP for all publishers in January 2016.) And because AMP is far less proprietary than its competition (meaning that it is open source, open to contributions, based on web technologies and client-agnostic), I would expect publishers to feel more comfortable distributing their content in a format that they feel they will have more control over long-term.

The reality is that publishers will back whatever syndication formats and partners will help get their content in front of the maximum number of readers with the least amount of overhead and investment. Right now, we are in the very early stages of a new type of war that is part platform, part format and in which each party will leverage its unique strengths to maneuver itself into the best possible position. At this point, it's far too early to say which will endure and which will become the RSS of tomorrow.

Дополнительные ресурсы

• “Introducing the Accelerated Mobile Pages Project, for a Faster, Open Mobile Web” Google Official Blog
• Accelerated Mobile Pages Project, official website
• Accelerated Mobile Pages, blog
• AMP HTML, GitHub
• Docs, Accelerated Mobile Pages Project
• Nigel Tufnel explaining why his amp goes to 11