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

30.09.2015

адаптивная верстка

Ваш сайт начал терять позиции в выдаче из-за изменение алгоритма ранжирования для мобильных устройств? Не знаете что делать и куда обратиться? 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.мойсайт.ru
  • Либо же показывать разный HTML, в зависимости от UserAgent.

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

В работе с Page Speed Insights все сложнее. Обращайте внимание, на возможную блокировку ресурсов, которые находятся в теге <head>, на время ответа сервера, размер внешних ресурсов и размер страницы.  

 

Последнее в нашем блоге