Но дьявол, как обычно, кроется в деталях. В интернете есть самые разные обзоры и сравнения плагинов кеширования. И за столько лет кто-то же должен был выдать идеальный рецепт? Но нет. Все эти обзоры сводятся к тезису: «мы сделали 10 одинаковых сайтов, установили плагины с дефолтными настройками и смотрим, где страница загрузилась быстрее». При этом все забывают, что нюансов при оптимизации кеширования вагон и маленькая тележка. Похоже, эта статья первая, которая примет во внимание реальное поведение пользователей на сайте, вместо сравнения скорости загрузки одной страницы в тепличных условиях.
Используя бестселлеры с Themeforest или, те же конструкторы, вроде Elementor, WP Backery и прочие, сайт обречен на 5-15 секунд TTFB (time for first byte, время ответа сайта) при загрузке КАЖДОЙ страницы. С одной страницы может быть несколько сотен обращений к базе данных, выполняться большое число php-функций, подключаться множество библиотек. Естественно, что такая скорость недопустима, она влечет за собой понижение в поисковой выдаче, «отказы» посетителей, сливы бюджетов на рекламу и так далее. С этим нужно что-то делать.
Я никогда шибко оптимизацией WordPress не заморачивался, потому что в моей практике сайты, которые требуют космической скорости работы, делали не на WordPress, а на Yii2 или Laravel. Для WP я использовал околодефолтные настройки плагина WP Super Cache, подсмотренные на Stackoverflow. Правда со временем начали появляться проблемы. Что-то приходилось «колхозить», где-то пробовать другие плагины. Но каждый раз появлялись всё новые и новые «косяки».
В какой-то момент я просто устал от постоянного «колхозинга» и решил найти идеальное решение. Я занимался этим больше месяца, тестируя разные плагины, разные настройки на разных сайтах, чтобы найти идеальный рецепт.
Забегая вперед, скажу, что идеального рецепта (идеальных настроек) не существует. В первую очередь необходимо четко сформулировать свои требования к функционалу и понять принципы работы того или иного плагина. Этим мы сегодня и займемся.
- Определяем требования к функционалу
- WP Super Cache
- Заключение
- Рекомендации
- Настройки WP Super Cache
- Настройка WP Super Cache
- Проблемы WP Super Cache
- WP Rocket
- Настройка W3 Total Cache
- Настройка W3 Total Cache
- Swift performance
- Настройка Swift perfomance
- Недостатки Swift perfomance
- Настройка WP Fastest Cache
- Стоит обратить внимание
- Вкладка ‘Простые’ в настройке плагина Wp Super Cache
- Расширенная конфигурация плагина кэша
- Разное
- Расширенные настройки
- Настройки времени истечения
- Допустимые имена & Запрещенные адреса
- Шаг 3. Поддержка сети доставки контента CDN
- Про кеширование сайтов
- До установки WP Super Cache
- Обзор плагина WP Super Cache
- Где скачать WP Super Cache
Определяем требования к функционалу
Как я уже говорил выше, идеального рецепта не существует, и необходимо разобраться в логике работы того или иного плагина и выбрать наиболее подходящее решение для каждого конкретного сайта. Во второй части статьи я подробнее рассматриваю популярные плагины для кеширования WordPress, их проблемы и предлагаю методы решения этих проблем. Здесь я обобщу все плюсы и минусы каждого из плагинов.
WP Super Cache
В ходе своего исследования я также успел поработать с WP Rocket и LiteSpeed Cache, в которых разочаровался почти сразу и не посчитал нужным расписывать подробно все их преимущества и недостатки, их я упоминаю во второй части статьи.
Заключение
Без сомнения, наиболее высокую скорость загрузки показал плагин W3 Total Cache. Он работает быстро и в классическом режиме, и в режиме PHP, да и страницы с GET‑параметрами загружает быстрее всех. Но для меня критичной стала проблема отсутствия автоматического фонового кеширования, которое бы обновляло файлы кеша, не снося их полностью, а заменяя постепенно.
Плагин, конечно, не требует доработок, и имеет все необходимые настройки, но в период обновления кеша, пользователи, попадающие на сайт, видят медленную загрузку, а при большом трафике на сайте это становится критичной проблемой. Его лучше использовать на статичных сайтах без автокеширования.
Большие надежды я возлагал на Swift Perfomance. Он имеет все необходимые настройки, не требует доработок, да и распространяется платно, а ведь платный плагин должен оправдывать вкладываемые в него средства? Но он разочаровал полностью, нестабильные механизмы автокеширования, недоработанный механизм ручного обновления кеша, высокая нагрузка на сервер при кешировании – все эти недостатки свели на нет его преимущества. Если бы я регулярно не мониторил его работу, может быть и не заметил бы этих недостатков. На текущий момент я его не использую ни на одном из проектов.
WP Super Cache был бы идеальным вариантом, если только на сайты с ним не вести рекламу. Как только на сайте появляются любые GET-параметры, необходимо дорабатывать исходный код плагина, чтобы устранить эту проблему. А при частом обновлении сайта с большим количеством страниц это становится настоящим геморроем, ведь если мы не хотим, чтобы некоторая часть пользователей с рекламы видела медленную загрузку после проведения автокеширования, то необходимо придумывать дополнительные методы обхода страниц с GET-параметрами. Чаще проще установить плагин, который всё это умеет из коробки. К недостаткам WP Super Cache можно также отнести отсутствие работы с оптимизацией контента на сайте (минификация HTML/CSS/JS, объединение CSS и JS-файлов, Lazy loading изображений, а также оптимизация и сжатие изображений), но это на любителя, плагин кеширования по факту не должен этим заниматься, все эти настройки нужно тестить, у других плагинов не все они работают адекватно.
Закрывает эти проблемы плагин WP Fastest Cache, который прекрасно умеет работать с GET-параметрами. Хотя он всё равно требует доработок. Лично мне не сложно внести небольшие изменения в код плагина, чтобы познакомить его с метками типа yclid и разрешить использовать PHP.
Рекомендации
Подробные настройки каждого плагина и инструкции по доработке исходного кода я выложу во второй части статьи.
Это переписанная и структурированная статья из моего телеграм-канала «digital на минималках», где я делюсь опытом в бизнесе, инструкциями, рассказываю, как удешевить свои вложения в digital, рассуждаю на небанальные темы, немного бомблю и делюсь мемчиками (осторожно, нецензурная речь). Решил, что подобное объемное исследование будет интересно не только подписчикам моего канала.
В этой части я подробно рассмотрю принцип работы каждого плагина, о которых говорил в первой части, а также приведу код с доработками для закрытия проблем плагинов. Кратко все преимущества и недостатки, основные выводы я уже сделал в первой части статьи.
На сегодняшний день — это самый популярный плагин для кеширования WordPress. Его я выбрал в самом начале своих потуг в оптимизации WordPress. В процессе эксплуатации выявлялись разные «косяки» в его работе, и я периодически правил настройки, чтобы подобрать оптимальные.
Настройки WP Super Cache
Почему именно так? И почему многие настройки отличаются от рекомендованных разработчиком и рекомендаций со StackOverflow.
Отключаем таймаут кеширования. Позже мы включим автокеширование, которое не позволит очищать автоматически созданные файлы, при этом созданные кеш-файлы по заходам пользователей из рекламы будут удаляться по таймауту. Но нам это не нужно, эти файлы будут удалены при следующем запуске автокеширования, а если мы укажем таймаут меньше, чем интервал запуска автокеширования — они попросту удаляться раньше, чем нужно. Поэтому устанавливаем значение: «0», при этом не стоит переживать за накопление мусора, при запуске автокеширования ВЕСЬ мусор будет удален.
Настройка WP Super Cache
Нужно проставить все галки, а также подобрать оптимальный период обновления кеша для настраиваемого сайта.
Не стоит указывать слишком большой промежуток обновления кеша, чтобы при публикации контента, который доступен на нескольких страницах, не попасть в ситуацию, когда была опубликована новость или важный пресс-релиз, а на сайте эта публикация появляется только спустя сутки.
Да, WP Super Cache самостоятельно обновит кеш страницы при внесении в неё изменений, НО он не будет обновлять другие страницы, где может присутствовать эта запись (например, на главной, в подвале или в сайдбаре).
Слишком маленький промежуток устанавливать тоже не стоит, т.к. при запуске автокеширования будут удалены все кеш-файлы, которые были созданы, в том числе неавтоматическим способом (например, при переходе из рекламы), и пользователи, заходя на эти страницы, будут опять видеть медленную загрузку.
В общем, если на сайте активно публикуются новости или статьи, стоит указать промежуток от 1 до 2 часов. Если же сайт по большей части статичный, и на нём редко что-либо публикуется или редактируется, спокойно можно выставить интервал в 24 часа.
Также полезно будет включить галку у параметра «Сообщения о статусе кэша» на вкладке «Обслуживание», для того чтобы периодически поглядывать, когда фактически был создан кеш той или иной страницы, не отвалилось ли кеширование в принципе, нет ли проблем с автоматическим кешированием.
Проблемы WP Super Cache
Единственная (но критичная) проблема WP Super Cache заключается в том, что он не умеет вычленять из URL необходимые GET-параметры, и все страницы с UTM-метками и прочими аналитическими параметрами считает за уникальные.
Разработчики плагина как будто бы знали о такой проблеме, потому что предусмотрели настройку «Не кешировать страницы с параметрами GET (?x=y в конце URL)». Тем не менее, она ничего не даёт, кроме экономии места на диске, потому что кеш не будет создаваться для страниц с GET-параметрами.
Единственный способ избежать этой проблемы — это «колхозить» плагин. Колхоз и допилы чужих решений — это то, за что я проклинаю всех разработчиков, потому что так делать нельзя (как минимум, после обновления плагина — все твои изменения будут отменены).
Ничего умнее я не смог придумать, как добавить в файл wp-content/plugins/wp-super-cache/wp-cache-phase1.php следующий код:
после строчки $wp_cache_request_uri
Это позволяет указать плагину на то, какую страницу мы хотим достать из кеша, при этом не перенаправляя никуда пользователя (в адресной строке UTM-метки у пользователя останутся).
Перелопатив тысячи строк кода, я так и не нашел способ это победить. Поэтому для себя, пока что, я нашел очень «костыльный», но всё же работающий способ решить эту проблему:
10 хитов в минуту — это не слишком много, а при условии, что по большей части будет отдаваться уже существующей кеш, то ощутимой нагрузки это не создаст. Тем не менее, WP Super Cache создаст кеш-файлы для всех страниц сайта, которые могут игнорировать указанные нами GET-параметры.
WP Rocket
В попытках найти более элегантный способ для реализации кеширования с GET-параметрами, я решил попробовать другой плагин — WP Rocket. И это полный провал. Несмотря на то, что плагин распространяется исключительно платно (по подписке), имеет красивый интерфейс и кучу настроек — все они бесполезны!
Во-первых, возможности выбора метода доставки кеша (mod_rewrite или PHP) нет, он работает исключительно через mod_rewrite, поэтому реализовать кастомный трекинг (как и любую другю PHP-логику) невозможно.
Во-вторых, автокеширование даже сравнительно небольшого сайта (~100 страниц) убивает напрочь сервер, на котором он крутится (скорее всего WP Rocket пытается осуществить обход всех страниц разом).
В-третьих, уже созданный кеш на половине страниц отваливается буквально через пару минут после его создания по неизвестной причине.
В общем, я даже не стал тратить время на доработки этого плагина.
Следующим на очереди у меня был W3 Total Cache. Он хорошо себя показал, и имеет право на жизнь. Он имеет настройку, которая позволяет игнорировать указанные GET-параметры, и это работает без «костылей», как с WP Super Cache. Также W3 Total Cache имеет возможность работать через PHP (выбрав в разделе «Page Cache» настройку хранилища «Disk: Basic», код, размещенный в корневом index.php, будет исполнен, а скорость загрузки закешированных страниц будет высокая, сопоставимая с результатами WP Super Cache). В целом, функционал W3 Total Cache значительно превосходит WP Super Cache. Помимо множества вариантов более сложного кеширования (Memcached, APC, Zend OPcache, Redis), он из коробки умеет объединять и сжимать HTML, CSS и JS, а также выполнять Lazy Loading изображений.
В этом случае каждый час у нас будет промежуток в +/- 10 минут, когда пользователь может попасть на страницу, кеш которой истек, а новый кеш будет создаваться во время загрузки страницы для этого пользователя. Пользователь увидит долгую загрузку страницы (чего мы пытаемся избежать).
Увеличивать время жизни кеша не хочется. Да, при обновлении страниц или новостей кеш для них автоматически будет обновлен, но на других страницах, куда могут быть подгружены эти записи, например, на главную, кеш обновлен не будет, а соответственно, добавленная или измененная запись там не появятся ровно до тех пор, пока не истечет время жизни предыдущего кеша.
Тем не менее в случае, если нет желания дорабатывать WP Super Cache, то W3 Total Cache вполне себе альтернатива. Также W3 Total Cache отлично подойдет для статичных сайтов, где можно обновлять кеш раз в сутки — запустил один раз ночью, и пусть он всё обновляет пока на сайте трафика мало. Либо вообще не использовать функцию автокеширования и обновлять кеш вручную при изменении сайта.
Настройка W3 Total Cache
После установки и активации плагина, нас встречает «Мастер настройки». Для каждого типа кеширования он проведет наглядные тесты и предложит на выбор разные параметры кеширования.
Настройка W3 Total Cache
Далее переходим в админке в раздел «Perfomance» — «Page cache»
Включаем автокеширование («Автоматическая настройка кеша страницы»), указываем интервал обновления (минимум 60 секунд, т.к. W P Cron не умеет работать быстрее), указываем кол-во страниц в интервале — выбираем в зависимости от скорости загрузки страниц без применения кеширования (если без кеширующего плагина в среднем TTFB страниц ~5 сек., то стоит указать кол-во не более 12, чтобы не нагружать лишний раз сервер). Также необходимо указать путь к Sitemap. XML, на основе которого будет осуществляться обход сайта. Рекомендую использовать для построения Sitemap. XML плагин «Yoast SEO», т.к. для интеграции с Yoast SEO у W3 Total Cache есть отдельное расширение, а это значит, что сайтпамы, сгенерированные Yoast SEO будут поглощаться плагином W3 Total Cache без каких-либо ошибок.
В блоке «Принятые строки запроса» указываем те GET-параметры URL-адресов, которые мы не хотим кешировать отдельно. Также укажем значения «Максимальное время жизни кэшированых объектов» и «Период удаления устаревшего кэша» в зависимости от того как часто мы хотим обновлять кеш. Нажимаем «Сохранить настройки и очистить кэш». На этом настройка плагина завершена.
Выше я уже писал о том, что периодически, несмотря на то, что кеш для определенных страниц уже создан, они все равно грузятся медленно. Частично исправить эту проблему поможет включение PHP-расширения «Zend Opcache» на сервере с сайтом.
Тем не менее вторую проблему (долгая загрузка страниц в период обновления кеша) решить невозможно, т.к. это особенность логики работы плагина W3 Total Cache, поэтому я продолжаю свои изыскания.
Swift performance
Очередной плагин, распространяющийся исключительно по подписке.
По началу я отнесся к нему крайне скептически, очередной «миллион-в-одном-плагин» с кучей «свистелок», но он смог меня удивить.
Человеческая настройка исключения GET-параметров из URL-адресов, которая работает без «колхоза», возможность работы без mod_rewrite (что позволяет исполнять кастомную PHP-логику), умное автокеширование, инструменты оптимизации контента (html/js/css minify, lazy loading, генерация WebP-изображений). И это чудо работает без танцев с бубном.
Настройка Swift perfomance
Параметров для настройки у Swift perfomance огромное множество. Поэтому будет проще не перечислять их все, а указать лишь те, которые отличаются от дефолтных.
Настройка Swift performance
Нажимаем «Manual configuration» и попадаем в консоль Swift perfomance, где сразу же нажимаем «Advanced view»:
Настройка Swift perfomance
Нажимаем «Save changes». На этом настройка плагина закончена.
Недостатки Swift perfomance
В общем, я возлагал большие надежды на Swift Perfomance, но из-за нестабильной работы своего основного функционала, пришлось от него отказаться. На текущий момент я его не использую ни на одном из проектов.
WP Fastest Cache — это еще один популярный плагин для кеширования WordPress.
Забегая вперед, WP Fastest Cache вернул меня обратно к «колхозу». Но несмотря на это, на сегодня он попал в мои фавориты.
Настройка WP Fastest Cache
Вот оно. Плагин, который не требует кучи параметров и просто работает. Плагин обходит сайт 1 раз в 5 минут (изменить в настройках время невозможно, но разработчики предусмотрели такую возможность через редактирование файла wp-config.php). Плагин кеширует указанное кол-во страниц (не более 12 шт. за раз, но с помощью wp-config.php можно указать любое количество). Пользователям отдаются кешированные файлы вне зависимости от их давности, а плагин в фоне (если установлена галочка «Restart After Completed») будет непрерывно обходить весь сайт для обновления файлов кеша.
Во-первых. Не довели разработчики до ума функционал игнорирования GET-параметров. U TM-метки и gclid работают без проблем — закешированная версия страницы загружается быстро. Но, к сожалению, разработчики не знают про Яндекс, и наличие метки yclid всё ломает, а страницы с такой меткой грузятся медленно. Раз уж мы начали с «колхоза», «колхозом» и закончим.
Открываем файл /wp-content/plugins/wp-fastest-cache/inc/cache.php и ищем «gclid»
Доработка WP Fastest Cache
после чего по тому же самому принципу добавляем недостающие GET-параметры, такие как yclid.
В-вторых, WP Fastest Cache работает исключительно с помощью mod_rewrite и выполнить свой PHP-код в момент конкретной загрузки страницы посетителем нельзя. Но и это решается с помощью доработки.
Открываем в корневой директории файл .htaccess и дописываем в начало следующий код:
Что тут написано? Мы проверяем, что запрос был совершен без POST-параметров (т.е. это не отправка какой-то формы, логику работы которой мы не хотим нарушать), а также у пользователя отсутствовала кука PHPSESSID, отвечающая за хранение информации о сессии пользователя. В этом случае мы проверяем существует ли кеш-файл для страницы, которую пользователь пытается открыть, если да, то мы отдаем пользователю файл lkdm-cache.php с GET-запросом пользователя (полный URL-адрес) и останавливаем исполнение условий, описанных в .htaccess. В иных случаях ничего не делаем, и обработкой запроса занимаются правила WP Fastest Cache, описанные ниже в файле .htaccess. При этом, если кеш-копии файла нет, то мы ничего не делаем, наш код будет выполнен уже из корневого index.php.
Теперь нам нужно исполнить свой код. Для этого создаем файл lkdm-cache.php в корневой директории WordPress, указываем в нём тот код, который нам необходимо исполнить, а после этого пишем следующее, чтобы отдать пользователю кеш-копию страницы:
Стоит обратить внимание
В заключение скажу, что у всех плагинов находятся свои проблемы. Мирится с ними, не замечать или дорабатывать решает каждый сам. Полное заключение по плагинам и свои рекомендации я даю в первой части статьи. Здесь же дополню, что убедился, что даже «платность» плагина не гарантирует его качественную работу.
Это переписанная и структурированная статья из моего телеграм-канала «digital на минималках», где я делюсь опытом в бизнесе, инструкциями, рассказываю, как удешевить свои вложения в digital, рассуждаю на небанальные темы, немного бомблю и делюсь мемчиками (осторожно, ненормативная лексика). Решил, что подобное объемное исследование будет интересно не только подписчикам моего канала.
Ищите инструкцию по настройке плагина WP Super Cache, которая поможет вам начать работу с этим популярным плагином для кэширования WordPress? Ниже я рассмотрю все настройки и действия, которые необходимо предпринять, чтобы ускорить ваш сайт WordPress с помощью WP Super Cache.
Вкладка ‘Простые’ в настройке плагина Wp Super Cache
По умолчанию WP Super Cache отключает кеширование до тех пор, пока вы не включите его вручную, и этот параметр вы увидите, когда углубитесь в настройки плагина: Ниже этого раздела вы найдете обзор текущей конфигурации плагинов.
На этом этапе вам потребуется немного подождать, чтобы включить плагин, так как есть несколько параметров, которые вам нужно настроить, влияющие на функционирование кэширования. Когда завершите с настройками, не забудьте вернуться на вкладку «Простые», чтобы включить кэширование.
Далее переходим ко второму шагу нашей инструкции WP Super Cache.
Расширенная конфигурация плагина кэша
Здесь вы можете выбрать, какой метод доставки кэша использовать. По умолчанию () использует PHP для обслуживания кэшированных статических файлов. А опция использует модуль Apache для обслуживания этих файлов: Метод Apache требует настройки файла и настройки модуля . Если на вашем сайте используются пользовательские постоянные ссылки, модуль уже должен быть настроен. С другой стороны, если вы умелый пользователь Nginx, вам нужно будет настроить пользовательские правила для вашего сервера, если вы хотите использовать этот метод.
В целом, хотя метод Apache немного быстрее, простая опция должна сработать для большинства веб-сайтов, и вероятность появления ошибок гораздо ниже.
По этой причине я рекомендую начинать с простой опции, если вы опасаетесь в редактировании файла вашего сайта.
Разное
Далее, прокрутите вниз до настроек под заголовком : Я рекомендую отключить кэширование для зарегистрированных пользователей, поскольку им может понадобиться доступ к динамическим данным. По этой же логике нужно отключить кэширование для страниц с параметрами (страницы, которые отображаются по-разному для каждого пользователя).
Ниже вы должны включить параметр сжатия страницы, который включает сжатие Gzip. Это популярная стратегия оптимизации, которая не вызовет каких-либо проблем и может уменьшить размер ваших страниц до ~ 70%.
Оставьте настройку восстановления кэша включенной. Эта функция будет предоставлять кэшированную копию вашего сайта для анонимных пользователей при создании новой.
Также включите опцию 304 кэширования браузера. Это еще один тип кэширования, который хранит статические ресурсы на локальных компьютерах посетителей. Например, ваш логотип. Это гарантирует, что посетителям не нужно загружать один и тот же файл снова и снова для каждой загрузки страницы.
Расширенные настройки
Далее прокрутите вниз до раздела . Здесь необходимо включить параметр «Включить динамическое кэширование», который будет генерировать статические копии динамического содержимого (например, рекламы или количества посещений): Если хотите принудительно очистить файлы кэша при публикации или обновлении записей либо страниц. То же самое касается опции дополнительных проверок домашней страницы и принудительного обновления страниц при публикации новых комментариев.
Все эти функции гарантируют, что при обновлении контента на вашем веб-сайте плагин будет создавать новые копии ваших кэшированных страниц, чтобы посетители могли сразу увидеть эти изменения.
Настройки времени истечения
Далее, давайте настроим время истечения срока и сбора мусора. Время ожидания по умолчанию для ваших кэшированных файлов установлено на 1800 секунд (или 30 минут). Это означает, что WP Super Cache будет хранить кэшированную версию страницы в течение 30 минут перед созданием новой копии: Для большинства веб-сайтов вы можете безопасно удвоить число до 3600 секунд, что составляет час. Таким образом, вашему серверу не придется генерировать кэшированные файлы так часто.
Если что-то изменится, например, вы обновили записи, то WP Super Cache проигнорирует это и сразу же сгенерирует новую версию кэша (это то, что вы включили в предыдущем разделе).
Допустимые имена & Запрещенные адреса
Здесь вы можете выбрать типы страниц, которые вы хотите кэшировать. Как правило, записи и страницы безопасны для кеширования. Однако высоко динамичные страницы, такие как продукты и оформление заказа, лучше не кэшировать.
Шаг 3. Поддержка сети доставки контента CDN
Вам не нужно настраивать этот раздел. Но если вы хотите использовать сеть доставки контента (CDN) для ускорения глобальной загрузки страниц вашего сайта, этот раздел может помочь вам обслуживать файлы из вашего CDN.
Есть два способа включить поддержку CDN с помощью WP Super Cache. Сам плагин рекомендует использовать встроенную функциональность Site Accelerator в плагине Jetpack. Это оптимизирует ваши изображения и сохранит файлы, а также ваши CSS и JavaScript, вне сайта.
Этот подход работает, и он также бесплатный, но он создает пару проблем. Для начала вам понадобится учетная запись WordPress.com для Jetpack для работы с вашим сайтом — это скорее нудно, но об этом нужно знать.
Во-вторых, Site Accelerator хранит файлы неограниченное время. Он не проверяет наличие обновлений для ваших изображений или сценариев, если вы не принудите его, переименовав эти файлы.
К счастью, WP Super Cache также предлагает встроенную опцию поддержки CDN. Он позволяет автоматически направлять плагин на сторонний URL (ваш CDN URL), из которого он будет извлекать все ваши и файлы. В целом, интеграция WP Super Cache с CDN может быть немного сложнее. Однако CDN могут значительно повысить производительность вашего сайта и позволить ему лучше справляться со скачками трафика. Это определенно вариант, если вы не против технических проблем. Вы также можете найти несколько хороших бесплатных CDN для WordPress.
На этом этапе можно включить кеширование для своего сайта. Для этого вернитесь на вкладку и поставьте галочку напротив первого шага!
Про кеширование сайтов
Кеширование в вебразработке — это очень важно. В WordPress особенно. Не то, чтобы Вордпресс такой плохой и тяжёлый, просто если можно ускорить загрузку страниц и одновременно снизить нагрузку на хостинг, а потратить на это пару минут, не воспользоваться этой возможностью было бы очень глупо. Итак, ближе к делу. Знакомьтесь с самым популярным плагином для кеширования страниц в вордпресс: WP Super Cache
Просто приведу 2 примера, до и после установки и настройки плагина
До установки WP Super Cache
Есть и противопоказания, но они больше условные: например, если ваш сайт почти не содержит постоянного содержимого, например предоставляет некоторый сервис, динамически изменяемые в php блоки и тому подобное. Правда, и тут можно найти выход, настроив тип кеширования Legacy или PHP и включив Enable dynamic caching в настройках. Так что, пути выхода есть 🙂 Однако, я лично думаю, что для таких сайтов лучше обходиться объектным кешированием, например, на основе W3 Total Cache, что тоже будет довольно эффективно.
Обзор плагина WP Super Cache
Принцип работы прост: плагин создаёт статичные html и php файлы – копии страниц WordPress и сохраняет их в кеш: /wp-content/cache/supercache/. Потом, при заходе пользователя на какую-либо страницу сайта, WordPress, вместо того, чтобы создать страницу с нуля, отдаёт браузеру заранее сохранённую копию html-страницы из кеша или собирает её максимально быстро из готовых php-файлов. Думаю, вполне очевидно, что такой вариант выходит экономнее по затратам ресурсов сервера и быстрее в плане скорости загрузки страницы.
Где скачать WP Super Cache
Кстати, есть подробная инструкция с видео для новичков, как устанавливать плагины в WordPress
Здесь и далее заменяйте http://example.com в примерах на ваш адрес сайта
Если у вас свой виртуальный или выделенный сервер, обязательно выставите верные права доступа на распакованные файлы, каталоги, и /wp-content/, чтобы кеш смог записываться