AMP — MEDIATRONE

Определение опирается на спецификацию AMP HTML: она описывает ограничения разметки, компоненты и работу среды выполнения. Google применяет к AMP те же общие требования, что и к страницам, созданным другими средствами. ^{[1; 2]}

Кратко

AMP задаёт технические правила документа; это не название любого быстро работающего мобильного сайта. ^[1]
Страница может быть самостоятельной или дополнительным представлением обычной страницы. ^{[1; 2]}
Историческое требование AMP для Top Stories нельзя переносить на современный поиск. ^{[2; 4]}
Валидность, производительность и успешное действие читателя проверяются отдельно. ^{[1; 2; 5]}

Происхождение и история

Седьмого октября 2015 года Google объявил о проекте Accelerated Mobile Pages после обсуждений с издателями и технологическими компаниями. В исходном анонсе речь шла о мобильном вебе, где тяжёлые страницы мешали чтению, и об открытом подходе на основе существующих веб-технологий. Общие компоненты и возможность кэширования, то есть хранения подготовленных копий страниц, составляли часть предложенного решения. ^[3]

История формата связана с поиском, но не сводится к нему. Девятнадцатого апреля 2021 года Google объявил, что в рамках обновления page experience формат AMP перестанет быть обязательным условием допуска новостей в карусель Top Stories. Начало постепенного внедрения тогда планировалось на середину июня. Допуск не означал гарантированного появления: сохранялось требование соответствовать правилам Google News. ^[4]

В справке Google, обновлённой первого июля 2026 года, AMP описан как технология страниц, индексируемых по общим правилам. Поэтому прежний аргумент «без AMP новость не попадёт в нужный блок» больше не служит достаточным основанием для внедрения. Решение требует проверки текущих задач сайта. ^{[2; 4]}

Суть и механизм

HTML задаёт структуру документа: заголовки, абзацы, ссылки и другие элементы. AMP добавляет к нему ограничения и компоненты для типовых задач. Среда выполнения — подключаемый JavaScript-код — реализует компоненты и управляет очередностью загрузки ресурсов. Например, место для изображения можно определить до получения самого файла, чтобы заранее построить макет. ^[1]

Спецификация требует обозначить документ как AMP, подключить среду выполнения и указать канонический адрес через rel="canonical". Это адрес основного представления материала. Если обычной версии нет, ссылка указывает на саму AMP-страницу. Следовательно, AMP не обязательно означает отдельный мобильный дубль. ^[1]

Страница может обслуживаться собственным сервером; специализированный кэш не является обязательным условием существования AMP-документа. Кэш и формат — разные части доставки: первый хранит и может оптимизировать копию, второй определяет устройство самой страницы. ^[1]

Ограничения требуют внимания при переносе функций. Например, авторские стили и встроенные стили элементов вместе ограничены 75 000 байтами; это не размер всей страницы. ^[1] При этом утверждение «в AMP вообще запрещён пользовательский JavaScript» слишком категорично. Компонент amp-script допускает такой код в Web Worker — отдельной среде выполнения, с ограниченным доступом к представлению страницы. Обычный виджет нельзя считать совместимым без проверки его возможностей в этой среде. ^[1]

Отличия и варианты применения

AMP не заменяет адаптивную вёрстку, которая приспосабливает отображение к экрану. Google прямо рекомендует адаптивный дизайн для AMP: такие страницы могут открываться и на телефоне, и на компьютере. ^[2]

SSR, или серверное формирование HTML, отвечает на другой вопрос: где подготавливается документ до отправки браузеру. Эти подходы совместимы. Руководство AMP Optimizer описывает обработку как при сборке статического сайта, так и после формирования AMP-документа сервером. ^[1]

Для выбора архитектуры редакция предлагает два основных варианта:

Вариант	Что сопровождается	Что особенно важно проверить
AMP как единственная реализация	Один вариант страницы для разных экранов	Поддерживают ли компоненты все необходимые действия
AMP как дополнительное представление	Основная и AMP-версии материала	Согласованы ли адреса, содержание и функции

Это практическая группировка, а не уровни качества технологии. Google требует по возможности обеспечивать на AMP тот же контент и те же действия, что и на соответствующей канонической странице. ^[2] При двух реализациях исправление текста или формы должно доходить до обеих: иначе читатели получают разные возможности.

Практика: учебная новостная страница

Условная редакция создаёт AMP-представление статьи. В исходном материале есть текст, фотография с подписью, ссылка на первичный документ и форма сообщения об ошибке. Команда заранее записывает эти четыре требования и проверяет их после переноса. Все числа и результаты далее — учебные, они не получены на реальном сайте.

В первом варианте текст и фотография отображаются, но ссылка на документ скрыта в неработающем меню. Даже положительный результат проверки разметки не исправляет эту проблему: читатель не может проверить основание новости. Команда восстанавливает доступ к ссылке и отдельно проверяет отправку формы, включая понятное сообщение об ошибке при неудаче. Такой сценарий конкретизирует требование сопоставимости Google. ^[2]

Затем обнаруживается превышение бюджета стилей. Допустим, таблица авторских стилей занимает 70 000 байт, а встроенные стили элементов — ещё 6000. Их сумма равна 76 000: лимит превышен на тысячу байт. После удаления 1200 байт повторяющихся правил остаётся 74 800 байт, то есть запас составляет двести байт. Это проверка одного ограничения, а не доказательство валидности всего документа. ^[1]

Байты не следует заменять числом символов: пример изначально задаёт измеренный размер данных. Отдельные правила для стилей анимации amp-keyframes нельзя автоматически применять к обычному авторскому CSS. ^[1]

Как измерить и проверить

Проверка формата сопоставляет документ с правилами AMP. Проверка содержания проходит по читательскому маршруту. Производительность требует собственных измерений: Core Web Vitals выделяют загрузку, отклик на действия и визуальную стабильность. Им соответствуют LCP, INP и CLS. ^[5]

LCP показывает время отображения крупнейшего изображения, текстового блока или видео в видимой области относительно начала перехода на страницу. ^[5] В условном лабораторном сравнении редакция сохраняет одинаковые текст, изображения, устройство, настройки сети и состояние кэша, выполняя по пять запусков каждой реализации.

Реализация	LCP в пяти запусках, секунды	Медиана
Исходная	3,2; 3,0; 3,1; 2,9; 3,3	3,1 с
AMP	2,6; 2,4; 2,5; 2,3; 2,7	2,5 с

Медиана — среднее по положению значение после сортировки: здесь третье из пяти. Сокращение составляет шесть десятых секунды. Относительное уменьшение рассчитывают так:

\frac{3{,}1-2{,}5}{3{,}1}\times100\%\approx19{,}35\%.

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

Lighthouse запускает автоматические проверки и формирует отчёт о странице. ^[6] Но обычная загрузка страницы без взаимодействия не измеряет INP: для него нужны действия пользователя. Документация Web Vitals также разделяет лабораторные испытания и наблюдения у реальных посетителей. ^[5] Поэтому пять лабораторных запусков не доказывают прохождения всех Core Web Vitals у аудитории сайта.

Ошибки и ограничения

Главная ошибка — принять один успешный тест за подтверждение всего результата. Прохождение валидатора не гарантирует доступности формы; хороший лабораторный показатель не подтверждает качество содержания; сам выбор AMP не обещает позиции в выдаче. ^{[1; 2; 5]}

Для российского проекта отдельно проверяется состояние страницы в Яндексе. Его справка различает обход, обработку данных, формирование базы и выдачу результатов; при обработке учитываются содержание и канонический адрес. ^[7] Из этого описания нельзя вывести специальное преимущество AMP или поддержку любого его компонента поисковым роботом.

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

Частые вопросы

AMP обязателен для мобильного сайта?

Нет. Это конкретная технология, а её страницы сами нуждаются в подходящем отображении на разных экранах. ^[2]

Нужна ли отдельная обычная версия?

Нет. Спецификация допускает каноническую ссылку AMP-страницы на саму себя, если другого HTML-представления нет. ^[1]

Можно ли использовать свой JavaScript?

Через предусмотренные средства, например amp-script, с его ограничениями. Это не разрешение бесконтрольно переносить любой сторонний код. ^[1]

Достаточно отчёта Lighthouse?

Нет. Он полезен для автоматической диагностики, но не заменяет проверку AMP-разметки и прохождение нужного читателю сценария. ^{[1; 6]}

Решить с помощью сервиса

По внутренней продуктовой справке, SEO-проверка Медиатрона проверяет технические параметры одной страницы, включая HTTPS, мета-теги и скорость через PageSpeed/Lighthouse. Инструмент работает внутри компании и готовится к открытию внешним пользователям. Поддержка отдельной AMP-валидации справкой не подтверждена. Блок описывает заявленные возможности; испытание сервиса для этой статьи не проводилось.

Сервисы MEDIATRONE →

Связанные термины

Источники

AMP Project. (б. д.). AMP HTML Specification; amp-script; Using an AMP Optimizer. https://amp.dev/documentation/guides-and-tutorials/learn/spec/amphtml ; https://amp.dev/documentation/components/amp-script ; https://amp.dev/documentation/guides-and-tutorials/optimize-and-measure/amp-optimizer-guide/ (дата обращения: 30.10.2026). Документация проекта консервативно учтена как одна работа. ↑ а б в г д е ж з и к л м н о п р
Google. (2026, July 1). About AMP on Google Search. Дата обновления документа. https://developers.google.com/search/docs/crawling-indexing/amp (дата обращения: 30.10.2026). ↑ а б в г д е ж з и к
Besbris, D. (2015, October 7). Introducing the Accelerated Mobile Pages Project, for a faster, open mobile web. Google Blog. https://blog.google/products-and-platforms/products/search/introducing-accelerated-mobile-pages/ (дата обращения: 30.10.2026). ↑
Jose, J. (2021, April 19). More time, tools, and details on the page experience update. Google Search Central Blog. https://developers.google.com/search/blog/2021/04/more-details-page-experience?isVariant=b (дата обращения: 30.10.2026). ↑ а б в
Google, web.dev. (б. д.). Web Vitals. https://web.dev/articles/vitals ; Walton, P., & Pollard, B. (2025, September 4). Largest Contentful Paint (LCP). Дата обновления; первоначальная публикация 8 августа 2019 года. https://web.dev/articles/lcp (дата обращения: 30.10.2026). Две главы документации Web Vitals учтены как одна работа. ↑ а б в г д
Google Chrome. (б. д.). Introduction to Lighthouse. https://developer.chrome.com/docs/lighthouse/overview (дата обращения: 30.10.2026). ↑ а б
Яндекс. (б. д.). Как работает поиск Яндекса. Справка Вебмастера. https://yandex.ru/support/webmaster/ru/yandex-indexing/site-indexing (дата обращения: 30.10.2026). ↑