Чому AMP сторінки втрачають швидкість на мобільних
AMP сторінки замислювалися як гарантовано швидкий формат для мобільної видачі, але на практиці прискорення втрачається вже на етапі інтеграції з основним сайтом.
Причина в тому, що AMP-обв'язка не скасовує помилок у контенті та підключеннях: сторонні лічильники, чати й віджети чіпляються до сторінки звичайними тегами й знову стають блокуючими скриптами.
Браузер зупиняє розбір документа, поки не завантажить і не виконає їх, — і вся вигода від легкого каркаса зникає.
Друге джерело деградації — зображення. В AMP їх віддають через спеціалізований компонент, який резервує місце під картинку й підвантажує її ліниво.
Якщо цей компонент обходять стороннім тегом або віддають повнорозмірний файл без адаптивних варіантів, мобільна швидкість падає: сторінка смикається під час підвантаження, а час до відмалювання основного контенту зростає.
Те саме зі шрифтами й стилями — невинесений критичний CSS і підключення зовнішніх накреслень блокують перше відмалювання.
Третя причина — відсутність пріоритетів завантаження. Коли всі ресурси запитуються одночасно й з однаковою вагою, браузер витрачає час на другорядне: аналітику, банери, приховані блоки. Оптимізація завантаження починається з того, що видно в першому екрані, — решту відкладають.
Без розстановки пріоритетів навіть коректно зібрана AMP сторінка програє за метриками звичайній, добре оптимізованій верстці.
Окремо варто згадати кешування й роздачу. Якщо AMP-версія живе на окремому піддомені без спільної політики кешу, відвідувач під час переходу з мобільної видачі отримує холодну відповідь сервера.
Узгоджені заголовки кешування, стиснення й коректна роздача статики повертають секунди, які губляться на повторних запитах.
Усі ці причини можна усунути, і розбираємо, як це закривається на рівні збірки, пріоритетів і роздачі.
Що дає переведення сайту на AMP-розмітку
AMP-розмітка прибирає все, що заважає сторінці з'явитися на екрані одразу: важкі скрипти, зовнішні блоки, відкладене підвантаження основного контенту.
Браузер отримує заздалегідь підготовлену розмітку і малює перший екран, не чекаючи сторонніх запитів, — час до першого відображення в мобільних мережах скорочується в рази, а не на відсотки. Для відвідувача це різниця між «відкрилося миттєво» і «крутиться коліщатко».
Далі ефект накопичується. Коли перший екран з'являється швидко, частина людей не встигає піти: показник відмов падає, бо людина не кидає сторінку на етапі очікування.
Це найпомітніше там, де аудиторія приходить з телефонів і на нестабільному з'єднанні, — тобто на більшій частині мобільного трафіку.
Окремий шар — швидка видача. Сторінки, зібрані за вимогами AMP, потрапляють у блок прискореного показу в результатах пошуку, де видача відкривається без повного завантаження сайту.
Частка таких сторінок зростає, і переходи з пошуку починають приходити на підготовлену, а не на «сиру» версію.
Важливо, що це не окремий сайт-двійник. Канонічна адреса залишається незмінною, звичайна і AMP-версії посилаються одна на одну, тому накопичена вага сторінок і позиції не втрачаються.
Якщо розмітка десь відходить від вимог, сторінка просто випадає з прискореного показу — решта сайту продовжує працювати як раніше.
Прискорення завантаження тут не разова правка, а режим: шаблони, стилі та логіка підвантаження фіксуються в межах правил, і нові сторінки одразу збираються за ними. Тому виграш тримається, а не зникає після першого перезбирання.
Варіанти реалізації AMP: порівняння підходів
Вибір підходу визначає не лише швидкість завантаження, а й те, як далі живе сайт: скільки версій сторінки доведеться підтримувати, наскільки складно вносити правки та як поводитиметься видача при оновленні контенту.
Нижче — три робочі варіанти, між якими реально обирають на проєктах, з їхніми сильними сторонами та ціною підтримки.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Окремі AMP-сторінки | Контентні розділи: статті, новини, картки товарів, де важлива миттєва видача в пошуку | Дві версії кожної сторінки — правки потрібно синхронізувати; урізаний набір елементів, свої правила щодо скриптів і стилів |
| Гібридна розмітка | Один контент, дві видачі: звичайна сторінка та її AMP-версія з тієї самої адреси | Потребує акуратного зв'язку між версіями та контролю канонічних посилань, інакше пошуковик вибере не ту сторінку |
| Динамічні AMP-компоненти | Інтерактивні блоки всередині AMP: фільтри, підвантаження, форми, стрічки | Логіка обмежена дозволеним набором компонентів; нестандартні сценарії доводиться переписувати під правила AMP |
На практиці найчастіше беруть гібридну розмітку: вона дає швидку AMP-версію без дублювання контенту й без другої команди правок. Окремі сторінки виправдані, коли AMP потрібен точково — наприклад, лише для статей, а решта сайту живе своїм життям.
Динамічні компоненти підключають поверх будь-якого з варіантів, коли в AMP-версії потрібні фільтри або підвантаження, а не просто текст.
Обмеження AMP — не вирок, а рамки, під які проєктують заздалегідь: набір дозволених тегів, заборона на довільні скрипти, вимоги до стилів і розмітки.
Якщо закласти їх на етапі проєктування, а не прикручувати AMP до готового сайту, вартість підтримки падає: правки йдуть в одне джерело, а швидка версія збирається автоматично.
Вибір підходу фіксуємо після розбору структури сайту та сценаріїв: де потрібна швидкість видачі, де інтерактив, а де важливіше єдине джерело контенту. Опишіть задачу — повернемося з оцінкою та планом за конкретним варіантом.
Як ми впроваджуємо AMP: етапи робіт
Впровадження AMP — це не «поставити плагін», а перебудувати видачу й розмітку так, щоб кожна сторінка проходила валідацію й віддавалася з кешу миттєво.
Починаємо з аудиту: дивимося, які типи сторінок взагалі мають сенс в AMP (статті, картки товарів, лендінги), які скрипти й сторонні вставки їх ламають, де вже є дублювальні мобільні версії. За підсумками аудиту фіксуємо перелік шаблонів і обмежень — це економить тижні переробок далі.
Далі процес іде за етапами, і на кожному є зрозумілий результат, який можна перевірити.
- Аудит поточної розмітки. Розбираємо структуру сторінок, знаходимо невалідний HTML, важкі сторонні скрипти, інлайнові стилі та блоки, які AMP забороняє. На виході — карта сторінок і список того, що доведеться переписати.
- Проєктування шаблонів AMP. Збираємо набір шаблонів під кожен тип контенту: стаття, каталог, картка, лендінг. Заздалегідь закладаємо компоненти, дозволені в розмітці, і точки підключення аналітики.
- Налаштування кешування. Налаштовуємо віддачу статики й розмітку так, щоб сторінки коректно потрапляли в кеш пошуковика й оновлювалися при публікації. Тут же вирішуємо, як синхронізувати AMP-версію з основною.
- Валідація. Проганяємо кожну сторінку через валідатор, усуваємо помилки й попередження. Мета — нуль критичних помилок: інакше сторінка не потрапить у швидку видачу.
- Впровадження й передача. Викочуємо на прод, перевіряємо індексацію, віддаємо команді документацію щодо шаблонів і правил додавання нових сторінок.
Ключовий момент — синхронізація: AMP-версія не повинна жити окремо від основної. Ми пов'язуємо їх канонічними посиланнями, щоб пошуковик не вважав це дублями, і налаштовуємо автоматичне перезбирання при оновленні контенту. Так команда публікує матеріал один раз, а обидві версії залишаються актуальними.
Після запуску відстежуємо частку сторінок, що пройшли валідацію, і час завантаження на мобільних. Якщо шаблон ламається при додаванні нового блоку — це видно одразу, до того як сторінка випаде зі швидкої видачі.
Що замовник отримує після впровадження AMP
Після впровадження AMP замовник отримує не «увімкнений модуль», а комплект артефактів, за яким систему можна розвивати й передавати іншій команді без усних легенд. Нижче — що саме залишається в репозиторії та у внутрішній документації.
- Конфігурації шаблонів. Набір шаблонів AMP-розмітки з валідацією на етапі збірки: окремі варіанти для карток товару, статей, категорій і посадкових. Плюс правила, які блоки допустимі, а які вирізаються автоматично — щоб розробник не ламав розмітку вручну.
- Схеми кешування. Карта: що кешується на стороні CDN, що на стороні застосунку, який термін життя у кожного типу контенту і як інвалідується кеш при оновленні. Окремо — поведінка при недоступності джерела, щоб сторінка не віддавала порожню відповідь.
- Політики безпеки. Налаштовані заголовки, обмеження на вбудований контент, правила роботи із зовнішніми скриптами та формами. Усе зафіксовано так, щоб новий розробник не вимкнув захист заради «швидкого фіксу».
- Документація. Опис структури проєкту, точок розширення, залежностей і того, як локально відтворити збірку. З прикладами типових задач: додати новий шаблон, змінити розмітку, підключити нове джерело даних.
- Регламенти оновлення. Порядок випуску змін: як перевіряється валідність розмітки, які перевірки обов'язкові перед публікацією, як відкочується невдалий реліз і хто відповідає за кожну точку.
- Моніторинг і звітність. Дашборд із ключовими показниками: частка валідних сторінок, швидкість віддачі, помилки кешу. Налаштовані оповіщення при відхиленні від норми — проблема видна до того, як її помітить користувач.
- Інструкція з передачі. Чек-ліст для онбордингу нової команди: доступи, середовища, порядок розгортання, контакти відповідальних. Передача займає дні, а не тижні листування.
Кожен пункт — це результат, який можна перевірити: відкрити репозиторій, запустити збірку, подивитися дашборд. Якщо за підсумком впровадження таких артефактів немає — отже, робота не завершена, і ми це чесно фіксуємо в прийманні.
Кейс: прискорення мобільної видачі для інтернет-магазину
Інтернет-магазин із каталогом на кілька тисяч позицій звернувся до нас із типовим болем: мобільна видача просідала, а аналітика показувала, що відвідувачі йдуть, не дочекавшись відмальовування карток.
Заміри підтвердили гіпотезу — на смартфонах у мережах із нестабільним покриттям сторінка категорії збиралася надто довго, і значна частка візитів закінчувалася поверненням ще до першого екрана.
Що зробили
Розділили фронт на два контури. Основний сайт залишився на звичному стеку з повним функціоналом, а для сторінок каталогу й карток товарів зібрали полегшені AMP-версії: лише критична розмітка, відкладене завантаження зображень, відмова від блокуючих скриптів.
Канонічні посилання та розмітка структурованих даних зв'язали обидві версії так, щоб пошуковик віддавав мобільному користувачеві швидкий варіант, а десктопному — повний.
Окремо пройшлися по зображеннях: перевели каталог у сучасні формати, зафіксували розміри контейнерів, щоб верстка не «стрибала» під час підвантаження. Кешування статики винесли на периферію — повторний візит став помітно легшим за перший.
Результат
| Метрика | До | Після |
|---|---|---|
| Час завантаження на мобільних | 6–7 с | 1,5–2 с |
| Частка відмов на сторінках каталогу | ~58% | ~31% |
| Позиції за комерційними запитами | за межами першої десятки | топ-5 за ключовими категоріями |
Проєкт вів наш інженер, який відповідав за фронтенд і розмітку; роботу приймали за замірами в реальних умовах, а не за синтетичними тестами. Після запуску частка мобільного трафіку зі швидкої видачі зросла, а конверсія в кошик на цих сторінках підтягнулася вслід за швидкістю.
Чим AMP відрізняється від адаптивного дизайну?
Це два різних підходи до одного завдання — швидко віддавати сторінку на будь-якому екрані. Адаптивний дизайн — це гнучка верстка: та сама розмітка перебудовується під ширину екрана через медіазапити, а поведінка задається вашими стилями та скриптами.
AMP — окремий формат розмітки зі своїм набором тегів і жорсткими правилами: частину звичних елементів замінено на вбудовані компоненти, сторонній код підключається лише через дозволені блоки, а критичні стилі інлайняться прямо в документ.
Звідси головна відмінність — у ступені свободи.
Адаптив не обмежує: ви верстаєте як зручно, підключаєте будь-які бібліотеки, аналітику та зовнішні віджети, але за швидкість і стабільність відповідаєте самі — оптимізація картинок, відкладене завантаження, порядок відрисовки лягають на команду.
AMP ці рішення бере на себе: правила формату не дають випадково уронити продуктивність, тому сторінка передбачувано проходить перевірку і швидко показується на слабкому мобільному інтернеті.
Обмеження AMP — це його ж гарантія. Не можна вставити довільний сторонній скрипт, важкий слайдер або кастомну анімацію без готового компонента; частину інтерактиву доводиться перезбирати під доступні елементи.
Адаптив таких рамок не ставить, але й не захищає від регресій: одна важка бібліотека — і метрики завантаження просідають на всіх сторінках.
На практиці це не «або-або». Адаптивна верстка залишається основою сайту, а AMP має сенс як окремий полегшений шар для сторінок, які повинні миттєво відкриватися з пошуку та стрічки новин.
Ми розбираємо, які сторінки виграють від формату, а які дешевше прискорити засобами самого адаптиву, і збираємо обидва варіанти так, щоб вони не конфліктували в розмітці та аналітиці.
Часті технічні питання щодо AMP-сторінок
AMP-сторінки вбудовуються в наявний сайт, а не замінюють його: канонічна адреса залишається за основним документом, а полегшена версія віддається за окремою адресою та позначається rel="amphtml".
Пошуковик сам обирає, яку версію показати в мобільній видачі, тому важливо, щоб обидві містили однаковий контент і коректні метадані. Якщо канонізацію налаштовано правильно, AMP не «краде» трафік, а розширює точки входу.
Підтримка зводиться до двох регулярних операцій: валідація розмітки та синхронізація контенту.
Валідатор виявляє порушення обов'язкових правил (заборонені теги, інлайнові стилі понад ліміт, сторонні скрипти), а розсинхрон контенту між версіями — найчастіша причина просідання позицій.
Ми закриваємо це збіркою з одного джерела: правка вноситься один раз, обидві версії оновлюються разом.
AMP конфліктує з нашим поточним стеком — доведеться все переписувати?
Ні. AMP-версія збирається з тих самих даних і шаблонів, що й основний сайт, — переписувати логіку не потрібно. Обмеження стосуються лише клієнтського шару: сторонні скрипти підключаються через дозволені компоненти, а інтерактив реалізується штатними засобами.
Якщо якийсь блок не переноситься, він залишається на основному сайті, а в AMP-версії замінюється посиланням на повну сторінку.
Що буде з SEO, якщо ми відмовимося від AMP пізніше?
Відкат безпечний: достатньо зняти розмітку rel="amphtml" і налаштувати редірект з полегшених адрес на канонічні. Пошуковик переіндексує сторінки за кілька циклів обходу, позиції зберігаються, бо канонічна адреса не змінювалася. Ми тримаємо цю процедуру в документації, щоб перехід у будь-який бік займав години, а не тижні.
Як часто потрібно перевіряти валідацію після оновлень?
Валідацію проганяємо в збірці: якщо розмітка ламається, реліз не виходить у продакшн. Додатково раз на місяць перевіряємо вже опубліковані сторінки — оновлення пошуковика іноді змінюють вимоги до обов'язкових атрибутів. Так порушення знаходяться до того, як сторінка випаде з видачі.
Обговоримо ваше завдання з AMP-оптимізації
Переводити сайт на AMP має сенс не «загалом», а під конкретне завдання: прискорити мобільну видачу, прибрати просідання за показником відмов, вивести в топ розділ, який зараз недобирає трафік.
Тому розмову починаємо з вступних — які шаблони сторінок у пріоритеті, звідки йде трафік, які метрики вважаєте цільовими. Далі дивимося поточну розмітку і вирішуємо, де AMP дасть виграш, а де достатньо звичайної оптимізації.
Оцінка термінів будується на обсязі: скільки типів сторінок переводимо, чи є динамічні блоки, як влаштована верстка і шаблонізатор. Після розбору даємо план за етапами з реалістичними термінами і розумінням, що саме перевіряємо на кожному кроці.
Що входить у роботу:
- розбір поточних сторінок і вибір шаблонів під AMP-версію;
- проєктування AMP-розмітки та її зв'язок з основною версією сайту;
- налаштування канонічних посилань, щоб версії не конкурували у видачі;
- перевірка валідності розмітки та усунення помилок до релізу;
- тестування швидкості завантаження та поведінки на мобільних;
- підключення аналітики, щоб бачити ефект у цифрах;
- передача документації та навчання вашої команди роботі з AMP.
Результат фіксуємо заздалегідь: які сторінки прискорюємо, на скільки скорочуємо час завантаження, як відстежуємо позиції та відмови після впровадження.
Далі — підтримка: стежимо за валідністю розмітки, оновлюємо шаблони при змінах сайту і розбираємо просідання, якщо вони з'являються.
Опишіть завдання — які сторінки хочете прискорити і який результат вважаєте успішним. Повернемося з оцінкою термінів і планом впровадження.
