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

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

Установка плагина 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 году мой блог размещался на бесплатном хостинге окснул.нет и этот товарищ был там администратором. Много мне помогал и даже запомнил мой сайт. Работу он сделал очень быстро и недорого. Классный специалист, рекомендую.

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