Как ускорить сайта на Вопрдресс за счет кэширования на примере плагина Hyper Cache и других

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

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

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

Кэширование в WordPress и как при этом работает блог

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

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

В случае же CMS ( читайте подробнее про движки сайтов), базирующейся на PHP и MySql, странички в формате HTML генерятся непосредственно на сервере хостинга, в момент обращения к ним. Каким образом они генерятся?

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

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

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

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

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

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

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

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

Герой сегодняшней публикации (плагин Hyper Cache) кэширует странички целиком и хранит их HTML версии в своей папке с кэшем. Что примечательно, кэширование работает только для незарегистрированных посетителей вашего блога. Т.к. у большинства блогеров регистрация не используется, то единственным зарегистрированным пользователем в этом случае будет лишь администратор, т.е. вы.

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

KtoNaNovenkogo.ru в начале своего существования базировался на халявном free hosting. Хостинг хороший, а для бесплатного так и вовсе отличный. Но однажды у них полетел жесткий диск, где размещались базы данных всех пользователей. И что примечательно, мой блог продолжал при этом спокойно работать, ибо его странички открывались из кэша и при этом обращений к базе данных вообще не было, т.к. она была недоступна.

Сайт на Joomla ( их примеры) у которого тоже было включено кэширование, при этом не работал, жалуясь на недоступность базы данных. Время жизни HTML копий вебстраниц в кэше у меня стояло 1440 минут (одни сутки), и это оказалось больше, чем время, в течении которого на хостинге была неактивной база данных (несколько часов).

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

Установка плагина Hyper Cache на Вордпресс

Скачать Hyper Cache вы можете с официальной страницы. Далее осуществляем стандартные действия по установке. Распакуйте архив hyper-cache.zip, используя ftp-менеджер (здесь можно скачать лучший из них — Файлзилу) подключитесь к вашему сайту и загрузите папку hyper-cache в папку с плагинами wp-content/plugins/ на удаленном хосте.

Дальше нужно будет включить кэширование в самом движке WordPress. Для этого нам потребуется открыть на редактирование файл конфигурации wp-config.php, который вы сможете найти в корневой папке на сервере вашего сайта. Вам нужно будет добавить в него всего одну строчку кода:

define('WP_CACHE', true);

Вставить ее можно в любое место до строки:

/** Абсолютный путь к директории WordPress. */
if ( !defined('ABSPATH') )
	define('ABSPATH', dirname(__FILE__) . '/');

Я, например, вставил в область, где идет задание параметров для базы данных:

/** Имя базы данных для WordPress */
define('WP_CACHE', true);
define('DB_NAME', 'wm1604_ox823');

Войдите в админку Вордпресса, выберете вкладку «Плагины»- «Inactive», найдите строку с этим плагином и активируйте его. Далее выберете из левого меню Параметры -> Hyper Cache. Если в окне с настройками никаких предупреждающих сообщений не появилось, то все готово к работе.

Если предупреждения появились, то скорее всего поможет выставление прав доступа 777 на папку (читайте об этом в статье про Файлзилу по приведенной чуть выше ссылке) wp-content или папку wp-content/plugins/hyper-cache.

Это нужно для того, чтобы данный плагин мог создать в WordPress папку для хранения кэшированных вебстраниц под названием cache. После того, как он ее создаст, вы можете вернуть права доступа (здесь рассказывается про chmod — права доступа) на папку wp-content и папку wp-content/plugins/hyper-cache обратно на 755, а уже папке cache, которая у меня находится в wp-content/plugins/hyper-cache/cache, назначить права 777, чтобы Hyper Cache имел возможность записывать в нее и стирать HTML-файлы с кэшем.

Настройки Hyper Cache для снижения нагрузки на сервер

В первом поле настроек (в левом меню выбрать Параметры — Хипер Кеш) под названием «Файлы в кэше» вы можете видеть, сколько вебстраниц вашего блога в данный момент сохранено в кэше.

В этом же поле имеется очень важная кнопка «Clear cache», которая позволяет сбросить кэш, т.е. удалить из отведенной для этой цели папки все имеющиеся там файлы. Эта кнопка вам может понадобиться в том случае, если вы, например, внесли изменения в дизайн и хотите, чтобы их увидели ваши посетители как можно быстрее. Потому как в противном случае, им будет по-прежнему доступна только кэшированные версии вебстраниц.

В области «Конфигурация» сосредоточены основные настройки.

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

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

В поле «Режим аннулирования кэша» задается способ очистки кэша при добавлении новых материалов на ваш блог или обновлении уже существующих статей (в том числе и при добавлении комментариев). Если из выпадающего списка выбрать «Все кешированные страницы», то при добавлении новой записи или обновлении существующей будет обновлен (очищен) весь кэш в WordPress. При выборе «Ничего» кеш останется без изменений.

При выборе «Только измененные записи» будут обновляться (удалены из кэша) только файлы кэша тех вебстраниц, которые были изменены. Галочка в поле «При аннулировании записи также аннулировать домашнюю страницу, страницы архивов и категорий» добавит вам удобства при работе с блогом.

В поле «Отключить кэш для комментаторов» можно поставить галочку. В этом случае пользователи смогут видеть добавленные ими комментарии не дожидаясь истечения времени жизни кэша для данной вебстраницы. Это делает кеширование в Вордпрессе менее эффективным, но сам блог более удобным. Галочка в поле «Кэширование RSS» позволит кэшировать RSS ленту.

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

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

Не знаю всей подноготной, но несмотря на запрет индексации в robotx.txt урлов со всякими там знаками вопросами и прочей ерундой что умеет генерировать Вордпресс, к таким страницам кто-то обращается (боты или еще кто) и их тоже следует кешировать.

В поле «Кэширование Домашней» вы можете поставить галочку для отключения кеширования главной страницы. Это может понадобиться, если она интенсивно обновляется и включение ее кэширования может вызывать дополнительную нагрузку за счет постоянной перезаписи файла.

Не забудьте сохранить произведенные изменения в окне настроек плагина Hyper Cache, нажав на кнопу «Обновление». Для того, чтобы проверить работает ли кэширование, вам надо будет зайти на свой блог не под зарегистрированным пользователем, а как обычный посетитель. Для этого его можно просто открыть в браузере, отличном от того, в котором вы работаете как администратор.

Откройте любую страницу блога и посмотрите ее исходный код. Для этого нужно щелкнуть правой кнопкой мыши по странице в вашем браузере и выбрать пункт контекстного меню «Исходный код» (Opera), либо «Исходный код страницы» (Firefox), либо «Просмотр кода страницы» (Google Chrome), либо «Просмотр HTML-кода» (IE).

Если вы увидите в самом низу окна с исходным кодом что-то вроде

<!-- hyper cache: 1b7e9b9b714b0b83a6f28ad4f7541abf 10-01-23 06:09:45 -->

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

Как я ускорил сайт и получил 100 баллов в PageSpeed

Из того, что сделал и что осталось в памяти (если нужно будет подробнее, то пишите в комментах — попробую вспомнить):

1. Сократил размер структуры DOM с 2500 до 1400 на самых больших по объему содержимого страницах (основное количество блоков там создавали комментарии). Как это сделал? Ну, например, посмотрел структуру комментариев и убрал лишнюю вложенность блоков (если комментов сотни, то и снижение DOM структуры происходит на сотни). То же проделал с сайдбаром.
2. Сделал постзагрузку счетчиков и прочего обвеса с задержкой относительно основного контента страницы. Это дало самый ощутимый эффект. Реальное время загрузки стало меньше на секунды. Как это сделать? В сети описаны разные способы с разными тригерами (по времени, по первому скролу и т.п.). Для разных вещей я использовал разные способы, но конкретики уже, к сожалению, не помню. Надо было записывать, но я как-то не верил, что это сработает.
3. Применил описанный в сети способ настройки четырех популярных плагинов для Вордпресса (LiteSpeed Cache + Hyper Cache Extended + Autoptimize + Speed Up — по ссылке найдете описание нужных настроек для каждого из них), использование которых в связке решило сразу несколько проблем:
   1. Полностью убралась подгрузка внешнего файла CSS стилей. Эти стили интегрировались в Html код (в область Head с помощью тела Style). К сожалению, по умолчанию туда набилось много лишнего CSS кода (например, из админки Вордпресса, который во фронтэнде без надобности). Но путем внесения исключений в плагин, который за это отвечал, удалось от этих огрехов избавиться. Потом еще несколько дней ушло на то, чтобы проверить все строки CSS кода на актуальность, что позволило сократить его более чем в два раза.
   2. Джава скрипт файлы тоже были объединены в один файл. Но мне особо ничего не дало.
   3. Что-то еще там улучшилось, но что не помню.

   Эффект от использования этой связки ощутил сразу. Реально выросла скорость загрузки (еще раза в два, наверное). Кстати, использовал для измерения скорости загрузки эти сервисы. Сразу оговорюсь, прежде чем вы стали кидаться в меня палками — ПингДом не показывает реальной картины (сильно в лучшую сторону дает результаты), но относительно предыдущих измерений и у него скорость выросла в два раза. А вот ВебПейджТест и ДжиТиМетрикс вполне себе адекватную картину формируют, на мой взгляд.

4. Отложенная загрузка картинок (так называемый Лези Лоуд). Штука необходимая. Дело в том, что измеряется, по сути, скорость загрузки первого экрана, но сама по себе страница может быть очень длинной и с множеством изображений. Если применить Лези Лоуд, то подгрузится только первая картинка (или несколько), попадающая на первый экран, а остальные будут подгружаться по мере прокрутки страницы.

   У меня это реализовано с помощью плагина BJ Lazy Load. Вариант не идеальный, ибо для того, чтобы происходила индексация картинок поисковиками используются костыли (урлы картинок прописываются в теге noscript). Но, к сожалению, правильный вариант лези лоуда пока не реализован в виде плагина для Вордпресс (во всяком случае бесплатного и проверенного временем).

   Вы мне скажите, что я дурак и уже давно есть атрибут Lazy Load для тега IMG (так называемый, нативный лези лоуд). Да есть, но прямое его применение не дает ровно никакого результата (даже наоборот, на мобильных устройствах все картинки будут грузиться при открытии первого экрана). Есть способ это побороть с помощью CSS свойства content-visibility, но у меня не получилось это реализовать на своем сайте (да и ютуб ролики, как я понимаю, в этом случае не будут работать с отложенной загрузкой).

5. Добавил ко всем изображениям атрибут decoding="async". Что он делает? Если кратко, то помогает ускорить сайт за счет асинхронной загрузки изображений. Стоит ли его добавлять, если об этом никто не пишет? Стоит, ибо реально есть прибавка в скорости. Как добавил? Через файл функшион.пхп, но деталей не помню. Если кто сам не найдет способ — попробую покопаться в этом файле, чтобы вспомнить.
6. Убрал все изображения из шаблона. Дело в том, что каждое из изображений прописанных в CSS (например, фоновые картинки, значки соцсетей, галочки, полочки, линии и тп.) создает отдельный запрос при загрузке страницы, что влияет на общую скорость. Причем Лези Лоуд на них не действует. Изначально (несколько лет назад) у меня формировалось около семи десятков запросов при загрузке страницы. Сейчас их только несколько (html страница, заглавная картинка, фавикон, объединенный джаваскрипт-файл и джиквери)
   
7. Убрал CLS (Cumulative Layout Shift). Не сразу обратил внимание и разобрался что такое CLS. Оказалось, что под этой аббревиатурой скрывает так называемый суммарный сдвиг шаблона. Он напрямую говорит об удобстве пользования сайтом, хотя его вес в калькуляторе Core Web Vitals весьма скромен на сегодняшний день (5 процентов).

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

   Сначала я прописал для всех картинок высоту и ширину (через функшион.пхп) и поменял метод прикрепления верхнего меню (ранее было через джава-скрипт, а стало через css позиционирование). Потом в настройках автоматических объявлений Адсенса (они у меня все автоматом расставляются) исключил все места на первом экране. Делается это через меню Объявления — настройки вашего сайта — удаление нежелательного места размещения.

   

   Это решило проблему с большим CLS (более 0.3 был). Но в начале этого года опять начал расти CLS, но только «для компьютеров». Вот честно, сломал голову, ибо не мог понять в чем дело. Визуально никаких сдвигов на первом экране не наблюдалось. Хоть тресни.

   Спасибо ребятам, которые выпустили размещенный ниже ролик.

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

   

   К тому же они привели ссылку на отличный плагин для Хрома, который позволяет в реальном времени отследить изменения Cumulative Layout Shift при прокрутке страницы.

   

   Причиной стал так называемый плавающий сайдбар (реклама в блоке внизу сайдабара, которая остается зафиксированной при прокрутке страницы ниже сайдбара). Она фиксировалась с помощью джаваскрипта (подменой позиционирования relative на fixed при прокрутке страницы ниже сайдбара).

   Пришлось потратить пару часов и заменить джава логику относительно новым CSS способом позиционирования через position sticky. Время ушло на то, чтобы понять, почему это не работает. Оказалось, что мешает overflow:hidden родительского элемента (это недокументированая фича). Пришлось заменить overflow:hidden новым CSS свойством display: flow-root, как посоветовал один замечательный товарищ в этой ветке.

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

8. Обновил компоненты сервера (ОС, Php, веб-сервер) и исправил ошибки. Все это вкупе дало малую прибавочку в скорости (особенно при формировании страниц еще не закешированных плагином, для которых на лету производится рендеринг) и повысило безопасность сайта (HSTS, убрал версии некоторых компонентов сервера из общего доступа), что тоже может быть оценено поисковиками.

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

   Обратился через Кворк к спецу с хорошими (отличными) отзывами. Прикольно, что когда указал ему сайт, то оказалось, что мы уже сотрудничали. В 2009 году мой блог размещался на бесплатном хостинге окснул.нет и этот товарищ был там администратором. Много мне помогал и даже запомнил мой сайт. Работу он сделал очень быстро и недорого. Классный специалист, рекомендую.

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