Ускорьте свой сайт на WordPress
Как описано в предыдущей части, я использовал Varnish для повышения скорости и надежности веб-сайта с высоким трафиком, одновременно снижая затраты на сервер:
Что такое Varnish-Cache?
Varnish - это инструмент, который служит механизмом полностраничного кеширования. Его можно настроить как обратный прокси - перед тем, как запросить у серверной системы определенный HTTP-запрос, он выполняет проверку кеша в собственном хранилище кеша. При попадании в кеш он вернет точную полную HTML-страницу, которую он хранил ранее, а в случае промаха он попросит одну из конечных конечных точек серверной части обслужить запрос, сохранить его, а затем вернуть его запрашивающему пользователю.
Представление
Лак работает очень хорошо. Обычно это связано со скоростью сети, что фактически превращает производительность в проблему. Мы видели, как Varnish обеспечивает скорость 20 Гбит / с на стандартном стандартном оборудовании.
Как настроить его для WordPress
Как и в случае с любым приложением, некоторые запросы могут быть полностью кэшированы, а другие запросы кэшироваться не могут.
В зависимости от случая могут быть запросы на получение, которые невозможно кэшировать. Как правило, на сайте WordPress все запросы на получение можно кэшировать.
Для WordPress не следует кэшировать конечные точки API, которые находятся по пути /wp-json/, и, конечно же, все запросы POST. Я обнаружил, что есть некоторые плагины, которые не нуждаются в кешировании - например, Elementor.
Срок хранения кеша, очевидно, зависит от веб-сайта и от того, как часто изменяется контент. В моем случае я создал простой плагин для WordPress, подключенный к обновлению публикации / страницы, который очистит для меня кеш. Правильнее всего будет очистить кеш только для той записи, которая была только что обновлена. Я не зашел так далеко и просто удалял весь кеш при каждой новой статье или обновлении статьи.
Конфигурация
Здесь у нас есть три участника: WordPress, обратный прокси Varnish-Cache и веб-сервер, которым в моем случае является Nginx.
Во-первых, нам нужно настроить Varnish-Cache как обратный прокси, ничего не кэшируя.
Настроить бэкэнд в Varnish-Cache
backend default {
.host = "10.0.0.5";
.port = "8080";
}
В моей конфигурации у меня есть все экземпляры в сети Azure, а веб-сервер имеет IP-адрес 10.0.0.5.
Обработка запросов
sub vcl_recv {
return(pass);
}
return(pass); будет игнорировать кеширование и просто делегирует запрос бэкэнду. С этими двумя блоками Varnish-Cache настроен как обратный прокси и всегда будет запрашивать серверную часть для каждого запроса.
Полный файл /etc/varnish/default.vcl:
Настройка NGinX
Единственное, что нужно обновить в конфигурации веб-сервера NGinX, - это изменить порт, который он слушает.
server {
server_name your_server_name.com;
.....
listen 8080;
}
Настройка SSL
Я управляю своими доменами с помощью Cloudflare, и, безусловно, будет достаточно настроить только гибкий SSL для администратора Cloudflare. Хотя я настроил его как Full. Разница между Гибким и Полным состоит в том, что первый будет гарантировать SSL-соединение между клиентом и Cloudflare, в то время как между Cloudflare и вашим сервером соединение не будет использовать SSL. Полный, с другой стороны, означает, что обе ветви этого соединения будут использовать SSL.
По этой причине я настроил свой веб-сервер в качестве первого респондента, который служит только конечной точкой SSL для выполнения рукопожатия. Затем он пересылает запрос в Varnish-Cache, который, в конечном итоге (на MISS), перенаправляет его на бэкэнд (веб-сервер).
Это конфигурация:
server {
server_name servername1.com servername2.com *.servername.com ....;
location / {
proxy_pass http://10.0.0.4:80;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto https;
proxy_set_header X-Forwarded-Port 443;
proxy_set_header Host $host;
}
# Certbot will eventually take care of the following if you
# generate the SSL certificate with it
listen 443 ssl;
ssl_certificate path_to_cetificate/fullchain.pem;
ssl_certificate_key path_to_private_key/privkey.pem;
}
Внутри моей сети Azure соединения не будут использовать SSL, поэтому этот блок сервера будет перенаправлять вызовы экземпляру Varnish-Cache по адресу 10.0.0.4 на порт 80.
Он также пересылает все заголовки, связанные с HTTPS, для работы WordPress.
Заставьте WordPress работать с указанной выше конфигурацией
Добавьте следующее в конец wp-config.php файла в корень вашей установки WordPress:
if (strpos($_SERVER['HTTP_X_FORWARDED_PROTO'], 'https') !== false) {
$_SERVER['HTTPS']='on';
}
Это предотвратит выполнение бесконечных перенаправлений WordPress на протокол https: //, поскольку он не понимает, что текущий запрос уже превышает https.
Включить кеширование
Теперь, когда у нас есть все основные части, мы можем настроить Varnish для фактического кэширования запросов.
Прежде всего, давайте добавим несколько блоков для запросов, которые мы хотим исключить из кеширования:
sub vcl_recv {
# Exclude caching Ajax requests
if (req.http.X-Requested-With == "XMLHttpRequest") {
return(pass);
}
# Exclude all POST requests or Authorization requests
if (req.http.Authorization || req.method == "POST") {
return (pass);
}
# Exclude everything that is neither GET nor HEAD
if (req.method != "GET" && req.method != "HEAD") {
return (pass);
}
# Exclude everything related to the backed, using a
# Regular Expression we can match the url against
# wp-admin, post.php, edit.php, wp-login, wp-json.
if (req.url ~ "(wp-admin|post\.php|edit\.php|wp-login|wp-json)") {
return(pass);
}
# Exclude wp-cron or when the front end is being
# previewed from the administrator/developer
if (req.url ~ "/wp-cron.php" || req.url ~ "preview=true") {
return (pass);
}
# Exclude explicitly a specific file when requested
# from a specific host_name
if ((req.http.host ~ "myhost.com" && req.url ~ "^specific_file_name\.(css|js)")) {
return (pass);
}
}
Для других запросов, которые будут фактически кэшироваться, должно применяться следующее:
sub vcl_recv {
...
# Remove the has_js cookie
set req.http.Cookie = regsuball(req.http.Cookie, "has_js=[^;]+(; )?", "");
# Remove the wp-settings-1 cookie
set req.http.Cookie = regsuball(req.http.Cookie, "wp-settings-1=[^;]+(; )?", "");
# Remove the wp-settings-time-1 cookie
set req.http.Cookie = regsuball(req.http.Cookie, "wp-settings-time-1=[^;]+(; )?", "");
# Remove the wp test cookie
set req.http.Cookie = regsuball(req.http.Cookie, "wordpress_test_cookie=[^;]+(; )?", "");
# Remove the PHPSESSID in members area cookie
set req.http.Cookie = regsuball(req.http.Cookie, "PHPSESSID=[^;]+(; )?", "");
unset req.http.Cookie;
}
Очистить кеш
Последний шаг - это возможность очистить кеш от определенного HTTP-запроса:
sub vcl_recv {
if (req.method == "PURGE") {
return (purge);
}
if (req.method == "CLEANFULLCACHE") {
ban("req.http.host ~ .*");
return (synth(200, "Full cache cleared"));
}
}
С этими двумя условиями мы можем легко очистить полный кеш.
Вызов CURL для запуска очистки будет выглядеть так curl -XCLEANFULLCACHE http://varnishurl_or_ip.
Полный /etc/varnish/default.vcl
Автоматическое обновление кеша WordPress
Последний кусок головоломки - заставить WordPress очищать кеш при создании новой статьи / страницы или обновлении существующей сущности.
Для этого создайте новую папку внутри [wordpress-root-installation] / wp-content / plugins / например. [wordpress-root-installation] / wp-content / plugins / cachecleaner.php.
Создайте новый файл в только что созданной папке. Мы можем назвать это cachcleaner.php.
Добавьте в файл следующий код и затем включите новый плагин в панели администратора WordPress.
Полный файл cachecleaner.php
Измените адрес Varnish-Cache и информацию о плагине WordPress в соответствии с вашими потребностями.
