- Вирішувати тільки асинхронні скрипти
- Розміряти всі ресурси статично
- Не дозволяти розширенням блокувати рендеринг веб-сторінки
- Тримати все сторонні скрипти поза критичного шляху
- Всі CSS повинні бути вбудованими (inline) і «размеро-прив'язаними»
- Шрифти: завантаження повинна бути ефективною
- Мінімізація перерахунків стилів (CSS)
- Тільки GPU-прискорені анімації / зображення дозволені
- Пріоритетність завантаження ресурсів
- Завантаження сторінок "миттєво"
Отже, що необхідно, щоб AMP сторінки завантажувалися настільки швидко, що клієнти говорили б про вашому веб-сайті: "о! цей сайт завантажився «миттєво» "?
Розглянемо наступні комбіновані блоки і елементи оптимізації, які є стовпами AMP і причинами реального прискорення завантаження.
Вирішувати тільки асинхронні скрипти
(наводимо посилання на оригінал, так як до сих пір немає усталених термінів для перекладу в російській мові).
Ми вже відзначили, що перед використанням скриптів JavaScript необхідно переконатися, що вони не викликають погіршення швидкості завантаження та інших робочих характеристик (не блокують завантаження і рендеринг вмісту головної сторінки і т.д.).
Розміряти всі ресурси статично
Зовнішні ресурси, такі як зображення, оголошення або фрейми повинні поміщатися із зазначенням їх розміру в HTML, так щоб для AMP можна було визначити розмір кожного елемента і його положення на сторінці, перш ніж ці ресурси будуть завантажені. Таким чином, AMP завантажує макет сторінки, не чекаючи завантаження будь-яких інших (включаючи зовнішніх) ресурсів.
AMP відрізняється тим, що завантажує макет документа, на відміну від макета ресурсів. Тільки один HTTP-запит необхідний для завантаження макета всього документа (включаючи шрифти). Так як AMP сторінка оптимізована, щоб уникнути непотрібних перерахунків стилів і макетів в браузері, то не буде ризику будь-якої «перемальовування» або повторної компонування, коли навантаження ресурсів зовсім-таки не потрібна.
Не дозволяти розширенням блокувати рендеринг веб-сторінки
AMP не дозволяє механізмам розширення блокувати рендеринг сторінок. AMP підтримує розширення для таких елементів як лайтбокси, вставки Instagram, що вбудовуються кнопки соціальних мереж і т.д. У той час як вони все ж вимагають додаткових запитів HTTP, але ці запити не повинні блокувати макет сторінки (її рендеринг / промальовування).
Будь-яка веб-сторінка, яка використовує спеціальний скрипт, або точніше сам сайт, повинен сказати системі AMP, що сторінка буде в кінцевому підсумку мати кастомний тег (custom tag). Наприклад, сценарій amp-iframe повідомляє системі, що матиме amp-iframe тег. І AMP створює вікно Iframe, перш ніж навіть буде відомо, що сценарій буде виконувати це:
"Script async custom-element =" amp-iframe "src =" https://cdn.ampproject.org/v0/amp-youtube-0.1.js ""
Тримати все сторонні скрипти поза критичного шляху
Сторонні JavaScript (JS) - скрипти люблять використовувати синхронну (послідовну - читай повільну) JS завантаження. Вони також люблять зовнішні виклики document.write для синхронізації сценаріїв. Наприклад, якщо у вас є на сторінці п'ять рекламних оголошень, і кожне з них викликає по 3 синхронні завантаження (кожна з затримкою підключення в 1 секунду), то ви будете чекати як мінімум 15-18 секунд (і втрачати стільки часу тільки для JS- завантаження).
AMP-сторінки все ж дозволяють сторонні JavaScript, але тільки в sandboxed iframes (пісочниці фреймів). Обмежуючи їх таким чином (в iframes), скрипти не можуть блокувати виконання і завантаження головної сторінки. Навіть якщо вони викликають перерахунки, то sandboxed-iframes фрейми будуть обмежені розміром DOM.
Тому Iframe-перерахунки будуть проходити дуже швидко в порівнянні з перерахунком стилів і макета всієї сторінки.
Всі CSS повинні бути вбудованими (inline) і «размеро-прив'язаними»
CSS стилі блокують рендеринг, завантаження сторінки і мають тенденцію ставати «великими перешкодами» (роздутими). В технології AMP HTML-сторінок, дозволені тільки вбудовані стилі. Це мінімізує завантаження (позбавляються від зайвих HTTP-запитів), тобто виконується, як правило, один HTTP, а зайві запити вилучаються з критичного шляху рендеринга для більшості веб-сторінок.
Шрифти: завантаження повинна бути ефективною
Веб-шрифти є супер великим навантаженням, тому оптимізація веб-шрифтів має вирішальне значення для продуктивності - швидкості завантаження сайтів. На типовою веб-сторінці, яка має кілька сценаріїв синхронізації і кілька зовнішніх таблиць стилів, браузер все чекає і чекає, поки не все не завантажиться, перш ніж почати завантаження необхідних шрифтів.
Система AMP стандартизує, що не чекає ніяких HTTP-запити, поки шрифти почнуть завантаження. Це можливо тільки тому, що всі JS (в AMP) має атрибут асинхронної завантаження, а також дозволені тільки вбудовані таблиці стилів; тому немає необхідності очікування ніяких HTTP-запитів, які блокують браузер від завантаження шрифтів.
Мінімізація перерахунків стилів (CSS)
Кожен раз, коли ви хочете щось завантажити в браузері (виміряти), це викликає перерахунки стилів CSS, тому що браузер для відображення сторінки повинен мати макет всієї сторінки. У сторінках AMP, все DOM-читання відбувається, перш ніж DOM-записи. Це гарантує, що станеться максимум один перерахунок стилів у фреймі / сторінці.
Тільки GPU-прискорені анімації / зображення дозволені
Єдиний спосіб забезпечити оптимізацію анімованих зображень - це запустити їх на відео-карті GPU (пристрій повинен мати вбудовані відео-адаптер).
Правила AMP для анімації / зображень, пов'язаних з CSSзаключаются в тому, що анімація може бути виконана тільки з GPU-прискоренням. Зокрема, AMP дозволяє анімувати і запускати перехідні зображення (при використанні перетворення і непрозорості) тільки таким чином, щоб не був потрібен виклик макета сторінки.
Пріоритетність завантаження ресурсів
AMP контролює всі завантаження ресурсів: але віддає пріоритет завантаженні тих ресурсів, які потрібні більше / раніше, а також підтримує попередню вибірку завантажених ресурсів.
Коли AMP виробляє завантаження ресурсів, то оптимізує процес завантаження таким чином, що в найбільш важливі ресурси будуть гарантовано завантажені в першу чергу. Зображення та оголошення завантажуються тільки тоді, коли вони ймовірно будуть розглядатися користувачем, або якщо користувач може (або можливо вирішить) швидко перейти до них.
AMP також підтримує попередню вибірку навантажених ресурси і lazy-loaded зображення. Ресурси завантажуються якомога пізніше, але з prefetch-попередженням якомога раніше. Таким чином, всі завантаження відбуваються дуже швидко, а CPU використовується тільки тоді, коли необхідні ресурси фактично показуються користувачам.
Завантаження сторінок "миттєво"
Новий API «пред-з'єднання» ( preconnect API ) Використовується в значній мірі для забезпечення швидкого завантаження / виконання HTTP-запитів, тобто неободимо якомога швидше виконати запити (як тільки вони зроблені). При цьому, сторінка використовує предіктивне метод (коли знає, на що клацне користувач, і вже починає пред-завантажувати цей контент), що призводить до миттєвого завантаження.
У той час як спосіб попереднього завантаження візуалізації застосовується до всього веб-контенту, це може зажадати використання великої пропускної здатності мережі інтернет і навантаження на CPU. AMP технологія оптимізована для зниження негативного впливу цих чинників. Попередня візуалізація завантажує тільки ресурси у видимій частині сторінки, і не виконуються високо-навантажені з точки зору CPU операції, якщо тільки вони не є абсолютно необхідними.
Детальніше про те, чому AMP HTML не в повній мірі може скористатися сканером попереднього завантаження можна додатково прочитати: preload scanner .
***
На основі матеріалів www.ampproject.org, Google.com