САЙТОСТРОЙ.РУ
Построй свой сайт!

Адаптация сайта под требования Google: mobile-friendly и по скорости загрузки

опубликовано 15.07.2015

Поисковик Google задал новый тренд в разработке и продвижении сайтов: высокие требования к скорости работы и адекватное отображение на устройствах с небольшим размером экрана. Причина проста: в алгоритме ранжирования заложен учёт многих десятков параметров сайта, имеющих отношение именно к удобству для пользователей. Сайты с наилучшими показателями имеют фору в выдаче Google. Я хочу рассказать о своём опыте оптимизации сайтов при помощи инструмента Google PageSpeed Insights и я надеюсь, что результат будет следующим:

100% удобство для пользователей в Google PageSpeed

 

Что из себя представляет PageSpeed Insights

Это онлайн-инструмент, позволяющий замерить показатели удобства сайта, а также получить ряд рекомендаций и даже готовых решений. PageSpeed Insights оценивает сайт по 100-бальной шкале, учитывая:

  • удобство для пользователя мобильного устройства;
  • скорость загрузки сайта;
  • удобство для пользователя компьютера (комбинация первых двух).

Запустив на проверку страничку, мы получаем эти три оценки. В пояснениях указано, что нужно исправить. Подсвечиваются проблемные активные элементы (ссылки), указаны неоптимизированные стили, скрипты и т.д. Если число баллов меньше 85, сайт считается плохо оптимизированным.

PageSpeed, к слову, существует так же в виде браузерного расширения для Chrome (считается устаревшим), в виде модуля Nginx - ngx_pagespeed и в виде API. До недавнего времени существовал DNS-сервер Google, самостоятельно выполняющий преобразования и выдающий "оптимизированный результат".

При первой проверке результат, скорее всего, будет малооптимистичным:

Плохой результат при проверке в PageSpeed

 

Шаги к улучшению показателей PageSpeed

Давайте пройдёмся по наиболее важным моментам, которые нужно учесть при оптимизации сайта. Я постараюсь сразу указать быстрые решения.

Удаление из верхней части страницы подключения внешних JavaScript и CSS, блокирующих отображение

В идеале нужно убрать встраивание JS/CSS или, по крайней мере, сделать объём соответствующего кода как можно меньше. Google подсчитывает объём данных, реально подгружаемый при загрузки верхней части сайта.

РЕШЕНИЕ 1. Использование асинхронных JavaScript: вместо
<script type="text/javascript" src="//www.google.com/jsapi"></script>
по возможности преобразовать в
<script type="text/javascript" async="async" src="//www.google.com/jsapi"></script>
А код выполнять после загрузки документа, обернув его следующим образом:
(function(){ … });

РЕШЕНИЕ 2. Перенос в начало документа критически необходимого CSS-кода, а всё остальное — в самый конец. То же касается и JS. Google предлагает вот такой необычный вариант разметки:

CSS, размещённый после конца документа

Да, выглядит это несколько странно - ссылка на стилевое оформление находится после конца документа, - но это работает.

Хочу отметить, что многие JS-скрипты уже имеют обёртки для выполнения кода после полной загрузки дерева DOM. Однако с некоторыми скриптами могут быть большие проблемы. Например, ситуация, когда подключается скрипт, зависящий от другого скрипта. Если на Вашей странице используется jQuery, запросто может возникнуть ситуация, когда вызов происходит до инициализации библиотеки, и синхронизировать их не так-то просто.

Но решение есть - замечательная библиотека Head.js. Она позволяет загружать скрипты отложенно, в нужной очерёдности и инициируя события загрузки. Таким образом мы можем отследить загрузку как всех библиотек целиком, так и какой-то конкретной в отдельности (годится в том случае, если Вы законченный аккуратист).

Давайте рассмотрим пример использования Head.js. Предположим, нам нужно отобразить виджет комментариев для VK.com. Нам необходимо выполнить функцию VK.init() строго после загрузки //vk.com/js/api/openapi.js.

Включим перед закрывающимся тегом <BODY> вызов нашего head.js и попросим его подгрузить, в данном случае, локальную копию openapi.js:

<script type="text/javascript" src="/js/head.load.min.js"></script>
<script>
head.js(
 { vk: "/js/vk_openapi.min.js" },
);
</script>

А инициализацию виджета обернём в замыкающую функцию, вызываемому head.ready():

<script type="text/javascript">
head.ready("vk", function () {
    VK.Widgets.Group("vk_groups", {mode: 0, width: "250", height: "250"}, xxxID);
});
</script>

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

Использование кэша браузера для JS/CSS/шрифтов

Google настоятельно просит задать на стороне сервера при выдаче статики большое время хранения. Для локальных ресурсов: не менее недели, для внешних — не менее 1 суток.

РЕШЕНИЕ 1. В Nginx для локейшена со статикой задать:
Expires 7d;
При обновлении придётся учитывать, что у части клиентов по-прежнему старые версии файлов. Проблема имеет своё решение: выдаём файлы под уникальными именами для разных версий:
<script src="//yastatic.net/doccenter/1.44/js/_doc.js"></script>

РЕШЕНИЕ 2. Сделать робота, получающего внешние стили и скрипты в локальную папку со статикой, и отдавать их со своего сервера, проставив большой Expires. Стоит учесть, что не все JS будут работать корректно, будучи размещёнными на Вашем сервере. Проблемы могут быть, например, с AJAX (политика безопасности).

Проиллюстрирую решение с помощью bash-скрипта, который периодически получает внешние JS и CSS, заданные ему в виде списка FETCHER_LIST:

#!/bin/bash

TMP_FILE="/tmp/wget.tmp"
FETCHER_LIST="/home/user/scripts_fetcher/scripts.lst"

while read url local_file file_user file_group; do
    wget -O $TMP_FILE -q --no-check-certificate -w 30 $url
    WGET_RETURN_CODE=$?
    if [ $WGET_RETURN_CODE -eq 0 ]
    then
        echo "Got" $url
        mv -f $TMP_FILE $local_file
        chown $file_user.$file_group $local_file
        chmod 0550 $local_file
    else
        echo "Fail on" $url
        rm -f $TMP_FILE
    fi
done < $FETCHER_LIST

Формат файла, заданного в FETCHER_LIST:

URL_скрипта Имя_локального_файла Пользователь Группа

Алгоритм работы следующий:

  • для каждого заданного в файле из переменной FETCHER_LIST URL попытаться получить его из сети;
  • временный файл записывается в TMP_FILE во избежание затирания существующей копии неверно получененной новой копией (например, пустым файлом);
  • если передача завершилась успешно, помещает полученный файл на место локального;
  • устанавливает права доступа согласно заданным в FETCHER_LIST.

Таким образом можно получать такие внешние скрипты, как VK API, Google Adsense, Google Analytics, Яндекс Директ и т.д. Далее мы подключаем их на страницах сайта из локальных копий. А актуальность скриптов поддерживаем при помощи регулярного вызова нашего скрипта из crontab. На мой взгляд, оптимальный период: раз в сутки.

Оптимизация изображений

На размере файлов с картинками положительно скажется очистка JPEG от EXIF и прочей мета-информации и преобразование GIF в PNG. Необходимо отказаться от использования форматов BMP и TIFF.

Радует, что Google кое-что уже сделал за нас. Это блок из веб-инструмента PageSpeed Insights:

Google PageSpeed Insights предоставляет оптимизированные версии Ваших изображений

Ссылка на загрузку оптимизированных изображений

Похожий результат выдаёт расширение Google Chrome:

Google Insights из браузера

Иными словами, Google предоставляет нам на скачивание наши файлы в уже оптимизированном виде. Это бывает очень удобно, когда дело касается статики, используемой в оформлении сайта.

Стоит учесть, что Google PageSpeed Insights учитывает именно объём впустую израсходованного трафика. Просматривая предложения по оптимизации, нужно обратить внимание на файлы, содержащие максимальный объём бесполезной информации, и заменить их на предложенные копии. Имеет смысл перенести внешние картинки на свой сервер, чтобы не зависеть от подхода к хранению данных на других серверах. Кроме того, это улучшит скорость отображения страниц, поскольку не будет инициировать дополнительных обращений к DNS. (Тут я хочу напомнить о существовании механизма DNS prefetching, позволяющего предвосхитить запросы к внешним серверам и заранее получить эти данные.)

Сокращение JS и CSS

Google нравятся «минифицированные» версии скриптов и стилей. Необходимо удалить лишние пробелы и переносы строк из ваших скриптов и стилей, поскольку они создают лишний объём и трафик. Продвинутые "минификаторы" умеют так же сокращать названия переменных и функций и удалять ненужный код, вроде комментариев.

РЕШЕНИЕ. Будем создавать .min-версии автоматически из исходных файлов.

Для CSS есть, к примеру, PHP-библиотека: cssmin.

Для JS есть Google Closure Compiler, который:

  • Имеет API. Авторизация не требуется. Форматы взаимодействия: JSON, XML, plain. Есть возможность задать исходный код или URL. Возвращает ошибки, предупреждения, статистику.
  • Настройки уровня оптимизации. Возможность подключения внешних JS.
  • Онлайн-сервис.

Предлагаю использовать комбинированное решение - скрипт minifier, принимающий на входе имена JS/CSS-файлов и автоматически создающий их копии с суффиксом .min. На страничке в Github есть подробное описание. 

Прочие оптимизации

  • Собрать мелкие изображения в спрайты или закодировать в "data:image/png;base64,...", чтобы избавиться от лишних HTTP-запросов;
  • увеличить время ответа сервера (не более 200 мс);
  • gzip on в настройках Nginx;
  • уменьшить размер запроса (длинные URLы, лишние cookie...);
  • указать размер изображений в HTML-атрибутах;
  • не использовать изображения физически больших размеров, чем область отображения;
  • удалить строки запросов из URL статических ресурсов (Google против «добавок» к URL вида «?v=201503100001». Рассматривает такую практику как воспрепятствование кэшированию;
  • использование Keep-Alive;
  • исправление ссылок или удаление 404-ресурсов (Google снижает качество сайта в случае наличия большого количества таких ошибок);
  • по возможности не использовать переадресации;
  • не использовать @import в CSS;
  • <link> CSS лучше включать в <HEAD>, чем где-то в <BODY>, поскольку это останавливает поток рендеринга страницы;
  • лучше всегда задавать кодировку документа, чтобы не тратить время браузера на её автоопределение.

И это далеко не полный список возможных оптимизаций, которые рассматривеат и предлагает Google. Работы, как говорится, непочатый край.

 

Адаптация под мобильные устройства

Требования достаточно лаконичны:

  1. Размер шрифтов должен быть таким, чтоб текст читался.
  2. Расстояние между ссылками должно быть достаточным, чтоб попасть в них пальцем.
  3. Отказаться от Flash.
  4. Должен быть задан тег viewport.
  5. Адаптировать размер контента для области просмотра.

Легко сказать! На практике это означает кардинальные изменения в вёрстке, поскольку требование должно выполняться для любых разрешений, в том числе для самых низких. Но ориентироваться можно на разрешение, для которого выполняется проверка - экран шириной 320 пикселей:

Режим просмотра сайта на мобильном устройстве в PageSpeed Insights

Давайте посмотрим, как можно добиться адекватного отображения сайта на низких разрешениях. Я предлагаю использовать технологию CSS media queries. При помощи неё мы можем трансформировать стили с учётом текущего разрешения.

Для начала убедимся, что HTML-страница имеет валидный заголовок. Например:

<!DOCTYPE html>

Далее добавим специальный мета-тег:

<meta name="viewport" content="width=device-width, initial-scale=1.0">

Сам по себе он отображение не исправит, но задаст начальные условия для наших дальнейших разработок. С заданными параметрами тег означает, что ширина контента по умолчанию будет соответствовать ширине устройства, а масштаб отображения будет 1:1 к обычному "десктопному" виду.

Теперь прибегнем к способу постепенной деградации оформления при проектировании. Любая страница имеет минимальную ширину, при которой все элементы умещаются на экране и контент отображается адекватно. Хотя существуют исключения, мы будем рассматривать именно такие сайты (читай: тянущиеся вниз, как лента). Далее мы будем уменьшать ширину окна, наблюдая пороги деградации, когда какие-либо элементы перестают умещаться в заданном пределе. 

Нам поможет инструмент "Адаптивный дизайн", встроенный в Firefox:

Режим "Адаптивного дизайна" в браузере Firefox

Выбрав пункт в меню браузера, мы переключимся в режим, при котором можно выбирать размеры виртуального экрана, в котором отображается текущая страница. Теперь мы можем легко её варьировать при помощи непосредственного указания разрешения в числомов виде или изменяя размер области мышью.

Чаще всего дизайн сайта проектируется на разрешение 1000 точек по ширине и выше. Можно начать с этого значения. Мы будем сужать область до тех пор, пока ширина отображения не начнёт соответствовать максимальной ширине сайта без искажений. Нащупав эту ширину, впишем в стилях страницы правила для первого преобразования. Например:

@media only screen and (max-width: 950px) {
  .content {
     width: 100%;
   }
}

Смысл этого CSS-правила следующий: при ширине области просмотра в 950 пикселей заменить стиль на приведённый. Мы предполагаем, что content - класс основного контейнера на странице. После достижения минимально доспутимого размера мы хотим, чтобы ширина контента уменьшалась вместе с областью просмотра. Это может продолжаться до тех пор, пока не начнут "вылезать" другие элементы страницы.

Рассмотрим следующие типичные случаи:

  • сайт имеет несколько столбцов, созданных при помощи DIV. Мы можем "спустить" один или несколько столбцов вниз, например, задав правило clear: both или float: none;
  • у сайта слишком широкое меню, идущее в одну строку. Сделаем из меню вертикальный список, задав его элементам display: list-item;
  • у анонсов материалов имеются изображения. При некотором размере области просмотра мы можем скрыть эти иллюстрации при помощи display: none.

Трансформация при изменении области будет происходить примерно следующим образом:

1. Ширина сайта около 900 пикселей.

Ширина сайта около 900 пикселей

2. Ширина сайта около 800 пикселей.

Ширина сайта около 800 пикселей

3. Ширина сайта около 300 пикселей

Ширина сайта около 300 пикселей

Итак, наш сайт прекрасно виден даже в таком низком разрешении.

Выводы

Добавлю немного лирики в это техническое описание. На мой взгляд, Google осуществил прорыв, заставив вебмастеров больше шевелиться и думать во благо пользователей. Конкуренция нещадна: число баллов по приведённым критериям высчитывается относительно общего качества сайтов по вебу. На практике это означает, что улучшая качество своих сайтов, вебмастера борются друг с другом в бесконечной перспективе, поскольку планка качества повышается от их же усилий.

Требования по качеству сайтов для Google формализованы. Теперь понятно, как получить благосклонность поисковой системы. Это даёт хорошие перспективы в белом SEO. Число учитываемых факторов будет только увеличиваться, но все они благоприятно отобразятся на удобстве пользователей. Здесь интересы пользователей и поисковой системы сходятся.

теги: google, head.js, seo

Комментарии и вопросы

Статью никто не комментировал.


Задать вопрос или оставить комментарий

Ваше имя:
Комментарий:
Код с картинки справа:=


Просим с уважением относиться к труду автора сайта и при копировании документов указывать ссылки на http://saytostroy.ru.