Ускорение работы сайта

Сделали мы такой супер-пупер сайт, все красиво и надежно, вот только еле работает и страницы грузятся по полчаса — значит пришло время заняться его оптимизацией. Если ваш сайт загружается медленно, страницы грузятся медленно — клиенты и посетители будут с него уходить, а поисковики — занижать в ранжировании и выбрасывать из индекса. Поэтому ускорение работы сайта это важный этап для вашего проекта.

Этапы ускорения работы сайта

Прежде чем перейти к собственно ускорению работы сайта, нужно уделить внимание оценке скорости работы сайта, потому что субъективное мнение «что-то тормозит» не очень подходит.

Есть много сервисов оценки скорости загрузки сайта, а также измерению его различных параметров, но самое первое что нас интересует — реальная скорость загрузки сайта. Если мы находимся в Мытищах, то скорость загрузки сайта в Дубаи для нас неинформативна. В Google Chrome и Firefox в режиме консоли (вызывается нажатием F12) смотрим панель Network

DOM Content Loaded показывает время полной загрузки и обработки HTML кода — в данном случае 2,28 секунды.

После этого запускается обработка разных событий на странице — событие Load завершилось в 3.69 секунды.И полная загрузка и выполнение всех операций и скриптов на странице завершилась в 4,02 секунды.Вот это все – самый точный объективный показатель того, с какой скоростью загружается страница сайта.

В списке запросов можно детально изучить — что, где, как и зачем, чтобы делать выводы и вносить изменения. Если время загрузки уменьшается — значит вы все делаете правильно. Но для оценки скорости нужно не забывать о важном моменте — большинство плагинов кеширования сайта настроены так, что если вы авторизированы на сайте, то кеширование не работает. Поэтому производите оценку выйдя из админки или в другом броузере, где вы не авторизированы.

И раз упомянул, то перейдем к первому инструменту ускорения работы сайта — кешированию. Кеширование означает сохранение результата какого-либо запроса и при повторном запросе — выдача готового результата, а не еще раз выполнение запроса.

Виды кеширования

Кеширование бывает нескольких видов:

1. Кеширование базы данных и объектный кеш
2. Страничное кеширование
3. Минификация стилей и скриптов

Каждый раз, как создается страница сайта, выполняется куча запросов к базе данных — посмотри содержимое этой записи, вот этой страницы, а также посмотри, какие были последние 5 комментариев. Кеширование позволяет хранить результаты таких запросов в файле на диске или в оперативной памяти. Страничное кеширование позволяет сделать полную копию уже готовой страницы и при повторном посещении сайта подсовывать сохраненное. Минификация стилей и скриптов означает их комбинирование в 1-2 общих файла, вместо десятков отдельных, удаление пустых строк, комментариев и сжатие.

Поэтому для наблюдательных сразу в глаза может броситься следующий момент — включение кеширования в некоторых случаях может замедлить сайт, если на сервере стоит медленный жесткий диск или мало оперативной памяти. Также объектное кеширование может замедлить сайт, если вместо пары больших и медленных запросов, будут выполняться маленькие и быстрые, но очень много запросов.

Что приводит к выводу — если у вас не очень посещаемый сайт, то ставьте любой плагин кеширования, включайте настройки по умолчанию и отдыхайте. Во всех остальных случаях нужно пробовать разные плагины, разные настройки и все измерять и контролировать, пока не добьетесь желаемого результата. Иногда будет необходимо признаться себе, что как ни крути, но поможет просто более мощный сервер, т. к. на дохлой лошади скачки не выиграть.

Для решения задачи кеширования можно использовать как несколько узкоспециализированных плагинов, так и универсальный, например W3 Total Cache. Есть очень хорошая и подробная инструкция по его настройке, от себя добавлю, что его преимущество является его недостатком — очень много кнопочек и крутилочек. Если вы делаете сайт, с последующей передачей ответственности и контроля к клиенту, то попробуйте WP Fastest Cache, все настройки — это несколько галочек на одной странице. Из недостатков — более тонкие и интересные возможности ушли в платную версию.

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

<?php if( current_user_can(‘administrator’) ){ ?>

<div align=”center”>

<div align=”center” style=”padding:6px;background:#FFF;color:#00A;font-size:12pt;font-weight:bold;width:550px;border:2px solid #A00;”>

<?php

printf( (‘SQL запросов: <span style=”color: #A00;”>%d</span> за <span style=”color: #A00;”>%s</span> секунд. ‘), get_num_queries(), timer_stop(0, 3) );

if ( function_exists(‘memory_get_usage’) ) echo ‘<br />Расход памяти: <span style=”color: #A00;”>’ . round( memory_get_usage()/1024/1024, 2 ) . ‘</span> Mb’;

if ( function_exists(‘memory_get_peak_usage’) ) echo ‘<br />Пиковый расход памяти (реальный): <span style=”color: #A00;”>’ . round( memory_get_peak_usage(TRUE)/1024/1024, 2 ) . ‘</span> Mb’;

if ( function_exists(‘memory_get_peak_usage’) ) echo ‘<br />Пиковый расход памяти (функция emalloc()): <span style=”color: #A00;”>’ . round( memory_get_peak_usage()/1024/1024, 2 ) . ‘</span> Mb’;

?>

</div> </div>

<?php } ?>

Тут идет проверка- не админ ли мы, и если да — то показывается что к чему. Посмотрим, что на сайте:

Как мы помним, админу по умолчанию показывается некешированная версия страницы, но можно включить объектное кеширование и кеширование запросов к БД для всех, обновить — и увидеть например уже такое:

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

Также эффект от включенного кеширования можно отследить и в консоли.

Хорошо видно, что генерация тела страницы заняла 2.14 секунды.

А вот повторная загрузка — и тело страницы загрузилось за 96 мс. Но тут есть одно но — части страницы сохранились в кеше самого броузера, типа небольших изображений, файлов стилей и т. п. Чем чаще и больше посетители тусуются на вашем сайте — тем быстрее он у них грузится, очевидно — но факт

За это отвечают настройки сжатия и броузерного кеширования.

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

Чтобы проверить работоспособность сжатия, воспользуемся тестером

Смотрим свой — красота, мы молодцы

Ускорение работы сайта для сервиса  Google Page Speed

Но не все готовы с нами согласиться. Один из самых популярных тестов скорости загрузки сайта — Google Page Speed. Посмотрим, что он думает по поводу нашего сайта.

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

Более подробную и развернутую оценку скорости загрузки дает сервис https://gtmetrix.com/

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

Также в качестве альтернативы, можно рассмотреть сервисы тестированияhttp://tools.pingdom.com/fpt/ и http://www.webpagetest.org/ , по сути они практически идентичны.

Мы для разбора полетов воспользуемся GTmetrix за то, что у него есть плагинhttps://wordpress.org/plugins/gtmetrix-for-wordpress/ , позволяющий проводить тестирование и изучать результаты прямо в админке сайта. А также будем контролировать время загрузки сайта с помощью консоли в броузере.

Посмотрим, какое влияние оказывает на скорость работы сайта его шаблон. Возьмем сайт-пустышку с установленной на него темой по умолчанию Twenty Fifteen.

Хороший, но далеко не идеальный результат для ускорение работы сайта устанавливаем плагин кеширования Fastest Cache, ставим все галочки по умолчанию, измеряем повторно.

Можно было бы попробовать дожать еще, но не хватает дополнительных настроек минификации, которые спрятаны в премиумной версии. Ускорение работы сайта от этого также зависит. Смотрим подробности — за что понижены баллы:

Необходимо отложить загрузку и минифицировать код Javascript, а также минифицировать код HTML.

Пробуем плагин W3 Total Cache – долго настраиваем, выставляем все необходимые галочки и опции:

Даже немного хуже результат, занижено за использование query параметра «?» у минифицированных скриптов (который блокирует их кеширование):

Решается очень просто — в настройках Browser cachе убирается галочка с «Prevent caching of objects after settings change».

И смотрим как было, и как стало:

Если вы пользуетесь другим плагином кеширования, в котором нет такой настройки, то вам поможет плагин для ускорение работы сайта Remove query strings from static resources, который как раз и занимается тем, что вырезает все параметры у статических файлов, чтобы они нормально кешировались.

Еще в данном примере Yslow традиционно занизил баллы за то, что не используем CDN для отдачи статических файлов — стили, скрипты, графика. Т.е. у нас все может быть здорово и красиво, но если нет CDN – минус балл.

Из этого можно сделать несколько выводов:

• без ручной доработки даже на пустом сайте практически невозможно получить 100% результат
• из-за метода оценки в тесте иногда 100% невозможно получить в принципе
• навороченный плагин с кучей опций не обязательно будет работать лучше остальных

Давайте попробуем руками дожать еще пару пунктов для ускорение работы сайта.

Чтобы заставить скрипты работать в отложенном режиме, необходимо к строке вызова скрипта добавить специальный параметр defer, а также перенести вызов скриптов из шапки сайта в подвал. Для этого добавьте в functions.php своего шаблона следующий код:

if (!(is_admin() )) {

function defer_parsing_of_js ( $url ) {

if ( FALSE === strpos( $url, ‘.js’ ) ) return $url;

return “$url’ defer onload='”;

}

add_filter( ‘clean_url’, ‘defer_parsing_of_js’, 11, 1 );

}

if(!is_admin()) {

remove_action(‘wp_head’, ‘wp_print_scripts’);

remove_action(‘wp_head’, ‘wp_print_head_scripts’, 9);

remove_action(‘wp_head’, ‘wp_enqueue_scripts’, 1);

add_action(‘wp_footer’, ‘wp_print_scripts’, 5);

add_action(‘wp_footer’, ‘wp_enqueue_scripts’, 5);

add_action(‘wp_footer’, ‘wp_print_head_scripts’, 5);

}

Сравниваем результаты.

Было и стало:

Также этот код оптимизации можно сохранить в виде плагина, чтобы он работал независимо от того, какой шаблон вы выбрали. Создайте файл с именем skl-defer-js.php и вставьте в него код по ссылке http://pastebin.com/fsSTYrB6 Скопируйте этот файл в папку плагинов и активируйте, плагин будет выполнять свою работу.

Давайте посмотрим, что еще можно улучшить — изучим исходный код страницы сайта и видим вот это:

В шапке сайта встроен код вызова скрипта emoji – забавные и совершенно бесполезные смайлики, включенные по умолчанию. Устанавливаем простенький плагин Disable Emojis, который занимается их вырезанием – и красота, код стал чище.

Теперь узнаем, что про сайт думает Google PageSpeed: Были ли наши работы по ускорение работы сайта оправданы?

Как видим замечание — уменьшить размер javascript файла.

Внизу есть удобная ссылка- возможность скачать архив с оптимизированными версиями файлов. Сравним оригинальный файл и сжатый:

Обращаем внимание — вырезаны комментарии, убраны пустые строки и переносы строк, оптимизирован код. Заменим оригинальный файл сжатым и сравним результат.

Общий балл не изменился, но замечание — пропало. Учтите, что при обновлении шаблона оптимизированный файл будет перезаписан!

Чтобы переместить в подвал вызов файлов стилей, добавим в наш плагин две новые строки

remove_action(‘wp_head’, ‘wp_enqueue_style’, 1);
add_action(‘wp_footer’, ‘wp_enqueue_style’, 5);

Сохраняем, обновляем, смотрим исходный код страницы — и видим, что вызов css файла стилей переместился в самый низ кода. Замечу, что оптимизировать этот вариант сайта — сплошное удовольствие, т. к. нет никаких плагинов, добавляющих свои стили и скрипты, на странице — минимум текста и никакой графики. Перед переходом к оптимизации реального сайта — давайте еще заглянем в вкладку «Для мобильных», чтобы оценить как загружается наш сайт на мобильных устройствах с точки зрения Google PageSpeed.

Сократить время ответа сервера — это очень неприятный и непостоянный критерий. Т.к. ваш сайт находится в одном месте, а сервера сервиса тестирования скорости — в очень далеком другом, то вполне может оказаться, что скорость ответа сервера будет недостаточно быстрая. Если эта ошибка будет появляться постоянно — задумайтесь о смене хостинга либо об оптимизации его настроек, если это выделенный сервер. Ускорение работы сайта от этого очень сильно зависит.

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

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

Компактно, но ничего особенного.

Давайте воспользуемся онлайн сервисом для сжатия css файлов http://cssminifier.com/

Получаем сжатую и совершенно не читаемую жесть

Но зато если оригинальный файл весит 97179 байт, оптимизированная версия весит 81801 байт, то сжатая — 75974 байта. Подменяем оригинал — и ошибка пропадает.

В целом, основные правила по оптимизации CSS кода можно прочесть в рекомендациях PageSpeed.

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

Ну а теперь перейдем к реальным условиям. Поставим шаблон с кучей наворотов The7, установим все демо-данные (тексты, графику) и посмотрим, что скажет PageSpeed:

Все плохо. А для мобильной версии — рейтинг 39/100.

Сама по себе работа оптимизатора напоминает работу археолога — сначала предполагаемое место раскопок копаем лопатой, потом когда на что-то наткнулись — начинаем отгребать руками и затем смахивать кисточкой.

Ускорение работы сайта начинается с самого важного первого шага — включим кеширование. Для поиска оптимального варианта можно ставить несколько плагинов, по очереди включать и замерять результат с помощью Gtmetrix или PageSpeed.

Стало немного лучше (для мобильных – 60/100).

Смотрим первую рекомендацию — сначала обращаем внимание на более важное, помеченное красным восклицательным знаком. Ускорение работы сайта от этого фактора сильно зависит.

Пока будем скачивать архив с оптимизированными изображениями, задумаемся о следующей информации: для фотографий использовать только jpeg формат, для различных фонов, изображений с прозрачным фоном (логотипы, водяные знаки) png формат. Если один и тот же файл сохранить в двух разных форматах — разница в размерах может быть в 3-5 раз, например:

Jpeg изображения могут быть избыточного качества — без визуальной потери качества фотографии вполне можно сжимать до 80%, а также удалять все метаданные (к примеру, FastStone Image Viewer обладает такой функцией).Png файлы можно уменьшить в размере, если понизить цветовую битность. Например сохранение в 256 цветном варианте уменьшает размер файла в три раза.

Вот один из предложенных вариантов оптимизации изображения:

Изменение размера и сжатие изображения по адресу /wp-content/uploads/2014/04/noimage1.png уменьшит его на 22,4 КБ (89 %).

Точно также оптимизированные варианты изображений можно скачать из расширенного отчета Gtmetrix.

Заменяем файлы на сжатые варианты и созерцаем. Работа по ускорению сайта не много стала успешнее.

Ускорение работы сайта по этому способу имеет  недостаток — оптимизируются только те изображения, что были загружены на тестируемой странице. Остается или по очереди перебирать все остальные страницы сайта, или воспользоваться плагинами оптимизаторами изображений – WP Smush, EWWW Image Optimizer и Compress JPEG & PNG images.

EWWW Image Optimizer зависит от библиотек, установленных на сервере. Если чего то будет не хватать, то и функционал работать не будет.

В моем случае — отсутствует библиотека для обработки png изображений.

Зато у плагина есть функционал обработки изображений вне папки Uploads, т. е. он может оптимизировать еще и изображения внутри папок шаблонов и плагинов.

WP Smush производит обработку всех типов изображений, но его функционал урезан для того, чтобы заманить на платную премиум версию без ограничений.

Compress JPEG & PNG images также обрабатывает и png, и jpeg с помощью облачного сервиса TinyPNG, на котором будет необходимо завести аккаунт. В бесплатном варианте доступно 500 обработок в месяц, что означает обработку примерно 100 изображений (ведь каждое изображение существует в нескольких вариантах — оригинальный размер, миниатюра, среднее, большое и т.п.)

Запустите пакетную обработку, для оптимизации уже существующих изображений на сайте. А все новые файлы будут обработаны на лету во время их загрузки. Ускорение работы сайта увидите мгновенно.

Но сделаю ремарку — есть и обратный процесс, не сжатия, а наоборот — повышения разрешения изображений, связанное с созданием изображений высокого качества для Retina дисплеев. Для этой цели есть вспомогательный плагин WP Retina 2x, который выводит список имеющихся файлов изображений и какие разрешения для каждого из них доступны. Если этот файл используется и отображается на ретина-дисплее, то рекомендует перезагрузить более качественное изображение.

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

Активируем наш плагин Отложенной загрузки — и наблюдаем бесконечно крутящийся прелоадер вместо страницы сайта. Или просто белый экран.

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

Если посмотреть консоль, то как раз видны эти ошибки — вызов того, что не еще задано.

Поэтому нам придется выбирать — или шашечки, или ехать.

Но если все таки очень хочется и тут покопаться, то есть хороший плагин Better WordPress Minify с возможностью выбора — какой скрипт перемещать вверх страницы, какой вниз, какой не трогать вовсе. Fastest cache в паре с ним работать не хочет, поэтому нужно будет подобрать другой плагин для кеширования страниц и запросов к базе данных, а минификацией займется Better WordPress Minify.

Если есть опыт — делаете со знанием дела, если нет — то методом тыка. Выбираете файл из очереди и перемещаете его в подвал. Сломалось? Возвращаете назад.

Рассмотрим еще одну область для улучшений — оптимизация кода самой страницы. Для отображения в броузере она преобразуется в html код, структурированный с отступами и переносами для лучшего визуального восприятия.

Один из тестов в Gtmetrix как раз оценивает степень сжатия страницы:

И сжатая версия страницы по его мнению выглядит вот так:

Однако мы можем пойти еще дальше и вырезать все переносы, ненужные пропуски и комментарии. Если выбранный вами плагин кеширования не выполняет сжатия кода страницы, то это можно сделать своими руками.

Нужно сделать два шага:

В header.php шаблона самой первой строкой добавить <?php ob_start();?>

В footer.php шаблона самыми последними строками добавить

<?php
$out = ob_get_clean();
$out = preg_replace(‘/(?![^<]*<\/pre>)[\n\r\t]+/’, “\n”, $out); //удаление тегов
$out = preg_replace(‘/<!–[\w\W]*?–>/’, ”, $out); //удаление комментариев
$out = preg_replace(‘/[\s]{2,}/’, ‘ ‘, $out); //удаление двойных пробелов
$out = preg_replace(‘/[\n\r]+/’, ”, $out); //удаление переносов строк
echo $out;

?>

Смотрим исходный код страницы — и видим красотищу

Правда Gtmetrix с нами не до конца согласен, балл поднял, но не до максимума:

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

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

1. Деактивируйте неиспользуемые плагины. Полностью удалите шаблоны и плагины, которыми не планируете пользоваться в ближайшее время. За пару кликов все, что вам нужно, устанавливается из репозитория. Но удаленные плагины и шаблоны — это уменьшение количества запросов и ускорение работы движка.
2. Скройте неиспользуемые шорткоды. Часто при смене плагинов в тексте записей остаются следы от их использования типа [shortcode id=”1234″]. Не нужно их удалять, если можно просто скрыть. Плагин Hide Unwanted Shortcodes уберет все отображаемые неработающие шорткоды.
3. Если не отключили ревизии или допустили спам на сайте, то база данных может распухнуть от ненужных копий записей или от обилия спам-комментариев. WP-Optimize удалит весь ненужный мусор.
4. Удалите неиспользуемые изображения, чтобы экономить место на жестком диске. Все изображения, которые связаны с удаленными записями, или все варианты размеров, если в записи использован только один — не нужны. Image Cleanup удалит все ненужные файлы.
5. Удалите неиспользуемые теги и рубрики, т. е. те — с которыми не связаны ни одна запись.

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