Адаптивна верстка та інструментарій Google

Ваш сайт почав втрачати позиції у видачі через зміну алгоритму ранжування для мобільних пристроїв? Не знаєте, що робити і куди звернутися? Google поспішає на допомогу!

Інструменти Google для адаптації сайту

Для вирішення питання з адаптивною версткою Google запропонував 3 інструменти. Розглянемо їх:

Mobile-Friendly Test. Тестуючи сайт за допомогою цього інструмента, Google визначає, чи оптимізовано ресурс. Тест перевіряє наступне:

• Чи є мета-тег viewport, що вказує на те, як сторінка масштабуватиметься під розмір екрану мобільного пристрою.
• Розмір шрифтів. Мають бути читабельними.
• Активні елементи. Тут важливим є розмір елементів, на які натискає користувач.
• Проміжки між активними елементами.

У роботі сервіс дуже простий: у поле вводимо url-адресу сторінки, він її сканує та видає свої зауваження.

Ще один сервіс, він вбудований в інструменти Google для Вебмайстрів . За своєю суттю схожий на попередній, Mobile-Friendly. Єдине, що він обходить усі сторінки сайту сам приблизно раз на 3 дні. Подібно до Mobile-Friendly Test, після сканування видасть свої зауваження.

Page Speed Insights – третій інструмент, запропонований Google. Його можна зарахувати до допоміжного інструменту. Він шукає помилки, які ви припустилися при оптимізації сайту, коли ви намагаєтеся прискорити завантаження сторінок і рендеринг.

Під час перевірки сайту він використовує спочатку mobile user agent, а потім desktop user-agent. Результат видається оцінкою (за шкалою від 2 до 100).

JavaScript - проблема вирішена

Прохання про перенесення всіх JS-елементів звучали вже давно. І ось тепер, зайшовши в налаштування головного модуля і відзначивши галочку, можна перемістити всі JS-елементи в кінець сторінки. Давайте розберемося, як це працює.

Коли галочка активована, система переносить всі наявні на сайті JS-елементи вниз і розміщує їх перед тегом </body>. Порядок коду, що переміщається, повністю зберігається. За статистикою, 95% сторінок не втрачають працездатності.

Якщо ж є скрипти, які переносити не потрібно, вказавши атрибут data-skip-moving = true (як для внутрішніх скриптів, так і для зовнішніх), можна запобігти небажаному перенесенню.

Що ж з 5% сторінок, що залишилися, працездатність яких була порушена після перенесення JS-елементів?

Пошук коду здійснюється за допомогою тегів <script></script>. Система не сканує складні конструкції типу скриптів, що знаходяться в HTML-коментарях. Це потрібно мати на увазі. Також розробники браузерів не радять конструкцію document.write. Зверніть і на це увагу.

Звичайно, якщо JS перенесеться донизу, то і цей HTML виведеться внизу, не там, де нам потрібно.

Цей інструмент дає можливість користуватися ним як у межах однієї сторінки, так і шаблону сайту.

«А що ж буде з JS, що є в HTML-атрибутах? Чи збереже працездатність сторінка, у якої в атрибутах залишився JS, а решта перенеслося вниз? - запитаєте ви. Тут важливо пам'ятати, що коли скрипти, що знаходяться внизу, почнуть завантажуватися, сторінка сайту вже буде показана користувачеві. Якщо він натисне на якийсь елемент раніше, ніж завантажиться необхідний JS-файл, це призведе до JavaScript exception. Користувач не побачить помилки, елемент просто не відреагує на клік. Якщо він натисне ще раз, вже після завантаження елемента, то все запрацює.

Є й ті, хто вважає, що JavaScript не має бути присутнім в атрибутах, інакше верстка змішується з JS, що правильніше використовувати addEventListener-метод. Давайте розглянемо цей приклад, тільки на jQuery.

При використанні jQuery або функції бібліотеки BX, обробники навішуються на події DomContentLoaded. Після обробки останнього скрипта відбувається ця подія. Але проблеми в юзабіліті все одно можуть виникнути: при натисканні користувачем на ще не завантажений елемент нічого не відбувається.

Що робити у цьому випадку:

• Нічого не змінювати, залишити все на своїх місцях, сподіваючись на швидке завантаження всіх елементів.
• Знайти все ж таки альтернативний вихід для подібних ситуацій. Наприклад, показати індикатор завантаження, якщо скрипти елемента ще не довантажилися.
• Звернутися до старих методів з далеких 2000-х. Тоді зверталися до DOM перед тим, як подія DomContentLoaded відбудеться. Звичайно з фітбеком: вішаємо обробник у випадку, якщо елемент є, якщо ні - викликаємо в DomContentLoaded.

CSS теж підпадає під нещадну оптимізацію!

Йдемо далі. CSS також має властивість блокувати рендеринг сторінки. Ми не можемо прибрати CSS, тому що сторінка залишиться без дизайну. У цьому випадку Google пропонує розмістити стилі прямо в коді сторінки, використовуючи теги <style>. Але є невеликий нюанс: дана рекомендація застосовується у маленьких CSS. Щоб зрозуміти, де можна застосувати весь CSS, а де не можна, потрібно буде згадати про «повільний старт». Він уражає протоколу ТСР. Це означає, що коли клієнт запитує якийсь ресурс, сервер не віддає найбільшу кількість пакетів, а віддає мінімальне, чекає підтвердження про отримання і віддає наступний набір. При цьому збільшивши обсяг пакетів удвічі.

Перша частина пакетів має назву Initial Congestion Window. Якщо сторінка має великий обсяг, Google вам вкаже на це. Page Speed, наприклад, приймає не більше двох roundtrip (сумарний час, який проходить пакет «туди-назад» до моменту повного завантаження).

Є три варіанти виходу для CSS:

• Не чіпати стилі, залишивши їх у зовнішніх файлах. У цьому випадку вони уповільнять відображення сторінки на першому хіті. Але вже на других хітах браузер ресурсу візьме з кешу.
• Вставити стилі в тіло сторінки. Тоді потрібно зробити код найлаконічнішим. Якщо розмір залишається великим, можна зробити так: ті стилі, які використовуються для завантаження першого екрана вставити в тіло. Інші перенести у зовнішній файл і підвантажити за допомогою JavaScript. Google знаходить цей варіант одним із найбільш логічних.
• Збільшити пакети.

Оптимізація та мініфікація

Сервіс Page Speed Insights має особливість: він може занизити бал за об'ємні картинки, що примусово масштабуються до меншого розміру. Використовуйте інструменти, які стискують графічні файли. Як варіант, можна скористатися інструментом, убудованим в утиліту Page Speed від Google. Тест запропонує вам посилання на завантаження стислих версій ресурсів.

Ще одна корисна новинка – галочка в CDN біля оптимізувати ресурси. Якщо увімкнути CDN, всі CSS- і JavaScript-файли підвантажаться з стороннього ресурсу. Якщо відзначити галочку біля «Оптимизувати ресурси», то картинки та ресурси відразу оптимізуватимуться і стискатимуться.

І ще пару порад щодо оптимізації:

• Користуйтесь gzip-стисненням. Інакше «повільного старту» не обминути через роздуті сторінки.
• Використовуйте HTTP-кешування.
• Слідкуйте за часом відповіді сервера. Модуль продуктивності вам на допомогу! Google вважає, що має пройти не більше 200 мілісекунд до отримання першої відповіді.

І на закінчення

Як не крути, а для того, щоб пройти тест на адаптивність, для початку треба зробити мобільну версію ресурсу:

• Використовуючи адаптивну верстку
• Можна через домен m.
• Або показувати різний HTML, залежно від UserAgent.

Google ж надає перевагу адаптивній верстці. Тим більше, що її простіше зробити, ніж ще одну версію сайту і ще один домен. Також обов'язково перевірте дозволи у файлі robots.txt.

У роботі з Page Speed Insights все складніше. Зверніть увагу на можливе блокування ресурсів, що знаходяться в тезі <head>, на час відповіді сервера, розмір зовнішніх ресурсів та розмір сторінки.