Оптимизация Сайта под Гугл

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

На что влияет этот показатель и кому это вообще нужно? Официальная позиция гугла примерно такова: “ваши сайты должны работать быстро, и тогда мы их будем ранжировать чуть выше, возможно”. В общем, так или иначе, а сайты должны работать побыстрее. Если даже гугл и не будет ранжировать сайт выше, поведенческие факторы вашего сайта наверняка улучшатся, если сайт будет рузиться быстрее.

Сегодня я решил оптимизировать загрузку нашего сайта и добился вот такого результата:

Можно было бы конечно еще заморочиться с оптимизацией картинок и еще выиграть пару процентов, но не думаю что это того стоит, тем более что сам гугл говорит “Если страница набрала более 85 баллов, значит она загружается быстро”, то есть 95/100 — это более чем достаточно, тем более что у нас маленькая социальная сеть, а не небольшой корпоративный сайт.

Далее я хочу рассказать с какими основными моментами столкнулся и как их решал.

Для начала давайте приведу полный лог ошибок, на которые гугл очень жаловался.

То есть больше всего ему не нравились различные скрипты в шапке ( теге ).
Если коротко, то все их я перенес в подвал, но есть тут очень интересный момент: есть оснойно файл стилей styles.css, его я перекидывал даже в самый низ страницы, и все равно получал вот предупреждение.

Это меня особо умиляло, ведь он просил вынести именно из верхней части страницы. Вопрос: куда ниже?)))

В итоге, я сделал проще: в шаблоне в head прописал

То есть я сделал инклюд этого CSS-файла, загнал его в переменную, выполнил ему замену относительных УРЛов на абсолютные и как есть вывел в саму страницу. Вот такой вариант уже устроил гугл. При чем на конечном уже варианте разница между таким подходом и просто ссылкой на CSS довольно серьезная (-7%, если через ссылку):

Второе, на что он очень жаловался — отсутствие серверных заголовков expired (конец срока действия файла).

Без указания срока действия файла браузер каждый раз обращается к веб-серверу за этим файлом.

В nginx это лечится так:
В директиву server{ прописываем
location ~* \.(woff|css|js|png|jpg|jpeg|gif|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|tar|wav|bmp|rtf)$ {
access_log off;
expires 30d;
}

Вот пример серверных заголовков при отсутствии этой информации в FireBug