WordPress за 1 ms: кеш, OPcache и gzip на малък VPS
WordPress не е бавен сам по себе си. Бавно е, когато всяко посещение кара PHP да сглобява страницата наново, с десетки заявки към базата. На малък VPS това се усеща веднага. Ето четирите настройки, които слагаме на всеки наш WordPress сървър, и какво реално спечелихме с тях. Командите са за Debian/Ubuntu с nginx и PHP-FPM.
Какво измерихме
Тест на нов WordPress на план Start (Debian 12, PHP 8.2), начална страница:
- PHP сглобява страницата: около 47 ms в самия сървър
- Готова страница от кеша: около 1 ms
- Отвън, през интернет, без кеш: първият байт идва след около 100 ms
- Отвън, с кеш: около 55 ms. Останалото време е самият път през мрежата.
- Размер на HTML-а: 12 KB компресиран вместо 70 KB
Кеш на страниците
Най-голямата печалба. Плъгинът записва готовата страница като файл и следващият посетител я получава директно, без PHP и без база. Ние ползваме Cache Enabler: безплатен, без настройки, сам изчиства кеша, когато промениш или публикуваш нещо, и не кешира за влезли потребители (затова в /wp-admin/ винаги виждаш актуалното).
Code: Select all
# с WP-CLI, от папката на сайта
wp plugin install cache-enabler --activate
OPcache
PHP превежда кода си при всяка заявка. OPcache пази преведения код в паметта. Обикновено вече е инсталиран, но с малко памет за голям проект като WordPress.
Code: Select all
php -v # виж версията, например 8.2
sudo apt install -y php8.2-opcache
echo "opcache.enable = 1
opcache.memory_consumption = 128
opcache.max_accelerated_files = 10000
opcache.revalidate_freq = 2" | sudo tee /etc/php/8.2/fpm/conf.d/90-opcache.ini
sudo systemctl restart php8.2-fpm
php-fpm8.2 -m | grep -i opcache # трябва да пише: Zend OPcacherevalidate_freq = 2 значи, че PHP проверява за променени файлове на всеки 2 секунди. Качиш ли нова версия на плъгин, тя се вижда почти веднага.
gzip и кеш за CSS, JS и картинки
По подразбиране nginx в Debian компресира само HTML. CSS и JavaScript отиват некомпресирани, а браузърът ги тегли отново при всяко посещение. В server { } блока на сайта:
Code: Select all
gzip on;
gzip_proxied any;
gzip_vary on;
gzip_types text/css text/plain text/xml application/javascript application/json application/xml image/svg+xml;
location ~* \.(?:css|js|mjs|png|jpe?g|gif|webp|avif|svg|ico|woff2?|ttf|otf|eot|mp4|webm)$ {
expires 30d;
access_log off;
try_files $uri =404;
}Code: Select all
sudo nginx -t && sudo systemctl reload nginx?ver= към файловете си. Нова версия има нов адрес и браузърът я тегли наново.location ~ /\.), сложи блока за статиката след него.
wp-cron от системата, не от посетителите
WordPress пуска планираните си задачи (публикации по график, обновления, бекъп плъгини) по време на посещение. Някой посетител чака. По-добре ги пусни на всеки 5 минути от системата. В wp-config.php, преди реда „That's all, stop editing“:
Code: Select all
define('DISABLE_WP_CRON', true);sudo crontab -u www-data -e):
Code: Select all
*/5 * * * * wp --path=/var/www/wordpress cron event run --due-now --quietcurl -s https://твоят-сайт/wp-cron.php >/dev/null.
Как да провериш сам
Code: Select all
curl -s -o /dev/null -H "Accept: text/html" -w "първи байт: %{time_starttransfer}s\n" https://твоят-сайт/-H "Accept: text/html" е важно: Cache Enabler дава кешираната страница само ако заявката я иска като HTML. Браузърът го прави сам, curl без него — не, и ще ти покаже бавното време.
При нас е включено от самото начало
Когато поръчаш VPS с WordPress, всичко отгоре е направено: Cache Enabler, OPcache, gzip и кеш за статиката, wp-cron от системата. Сайтът минава и през Cloudflare, който пази CSS, JS и картинките близо до посетителя. Ти само пишеш съдържанието.Въпроси или твои мерения? Пиши тук в темата