NGINX on yksi tehokkaimmista tavoista ajaa WordPressiä tuotannossa, mutta todellinen suorituskyky syntyy vasta, kun palvelinkonfiguraatio, PHP-FPM, välimuisti ja WordPress itse on optimoitu yhdessä. Pelkkä NGINX ei tee sivusta nopeaa, mutta se mahdollistaa erittäin matalan TTFB:n ja korkean rinnakkaisuuden oikein konfiguroituna.
Tyypillinen optimoitu stack:...
FastCGI cache muuttaa WordPressin lähes staattiseksi sivuksi....
Älä cacheta kaikkea...
Paras malli:...
NGINX toimii vain niin hyvin kuin PHP-FPM....
Ilman OPcachea WordPress on hidas....
gzip on; gzip_types text/css application/javascript text/plain application/json; Brotli (parempi) brotli on; brotli_types text/plain text/css application/json application/javascript; 8. Static asset optimointi NGINX hoitaa nämä suoraan ilman...
NGINX hoitaa nämä suoraan ilman PHP:tä...
location / { try_files $uri $uri/ /index.php?$args; } 👉 yksinkertainen ja tehokas routing...
Tärkeää:...
Erittäin tärkeä WordPressissä...
client_max_body_size 64M; fastcgi_read_timeout 300; fastcgi_buffers 16 16k; fastcgi_buffer_size 32k; 13. HTTPS optimointi ssl_session_cache shared:SSL:10m; ssl_session_timeout 10m; ssl_protocols TLSv1.2 TLSv1.3; 14. HTTP/2 ja HTTP/3 HTTP/2 listen...
ssl_session_cache shared:SSL:10m; ssl_session_timeout 10m; ssl_protocols TLSv1.2 TLSv1.3; 14. HTTP/2 ja HTTP/3 HTTP/2 listen 443 ssl http2; HTTP/3 (QUIC) parempi mobiilissa vähemmän latencyä 15. Logging optimointi...
listen 443 ssl http2; HTTP/3 (QUIC) parempi mobiilissa vähemmän latencyä 15. Logging optimointi Liiallinen logging hidastaa:...
Liiallinen logging hidastaa:...
NGINX ei riitä ilman WordPress-tason säätöjä:...
Paras yhdistelmä:...
Skaalautuva WordPress NGINX stack:...
Skaalautuva WordPress NGINX stack:...
NGINX-ympäristössä WordPressin suorituskyky ei riipu yhdestä asetuksesta vaan koko pinosta. Kun FastCGI cache, Redis, OPcache ja CDN toimivat yhdessä, WordPress muuttuu lähes staattiseksi järjestelmäksi yleisille...
1. Perusarkkitehtuuri
Tyypillinen optimoitu stack:
Client → NGINX → PHP-FPM → WordPress → MySQL
↓
Redis cache
↓
Object cache
Lisäksi usein mukana:
- FastCGI cache (NGINX)
- CDN edge cache
- OPcache PHP:lle
2. NGINX FastCGI cache (tärkein optimointi)
FastCGI cache muuttaa WordPressin lähes staattiseksi sivuksi.
Peruskonfiguraatio
fastcgi_cache_path /var/cache/nginx levels=1:2 keys_zone=WORDPRESS:100m inactive=60m;
server {
location ~ \.php$ {
fastcgi_cache WORDPRESS;
fastcgi_cache_valid 200 301 302 60m;
fastcgi_cache_bypass $skip_cache;
fastcgi_no_cache $skip_cache;
}
}
3. Cache bypass logiikka
Älä cacheta kaikkea
set $skip_cache 0;
if ($request_method = POST) {
set $skip_cache 1;
}
if ($http_cookie ~* "wordpress_logged_in") {
set $skip_cache 1;
}
4. Edge + NGINX hybrid cache
Paras malli:
Cloudflare CDN
↓
NGINX FastCGI cache
↓
PHP-FPM
↓
WordPress
Tulos:
- lähes 0ms edge-vastaus cachehitissä
- erittäin pieni origin-kuorma
5. PHP-FPM optimointi
NGINX toimii vain niin hyvin kuin PHP-FPM.
Tärkeimmät asetukset
pm = dynamic
pm.max_children = 50
pm.start_servers = 10
pm.min_spare_servers = 5
pm.max_spare_servers = 20
Miksi tämä on tärkeä
- liian vähän children → jonoja
- liikaa → muistivuoto
6. OPcache optimointi
Ilman OPcachea WordPress on hidas.
opcache.enable=1
opcache.memory_consumption=256
opcache.max_accelerated_files=20000
opcache.validate_timestamps=0
👉 productionissa timestamps usein pois
7. Gzip tai Brotli
Gzip
gzip on;
gzip_types text/css application/javascript text/plain application/json;
Brotli (parempi)
brotli on;
brotli_types text/plain text/css application/json application/javascript;
8. Static asset optimointi
NGINX hoitaa nämä suoraan ilman PHP:tä
location ~* \.(jpg|jpeg|png|gif|css|js|svg)$ {
expires 1y;
add_header Cache-Control "public, immutable";
}
9. WordPress rewrite optimointi
location / {
try_files $uri $uri/ /index.php?$args;
}
👉 yksinkertainen ja tehokas routing
10. MySQL optimointi (NGINX ei yksin riitä)
Tärkeää:
- query cache (riippuen versiosta)
- proper indexing
- slow query log
- InnoDB buffer pool
11. Redis object cache
Erittäin tärkeä WordPressissä
WordPress → Redis → MySQL
Hyödyt:
- vähentää WP_Query kuormaa
- nopeuttaa adminia
- vähentää DB connectioneja
12. NGINX buffering ja timeoutit
Tärkeät asetukset
client_max_body_size 64M;
fastcgi_read_timeout 300;
fastcgi_buffers 16 16k;
fastcgi_buffer_size 32k;
13. HTTPS optimointi
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
ssl_protocols TLSv1.2 TLSv1.3;
14. HTTP/2 ja HTTP/3
HTTP/2
listen 443 ssl http2;
HTTP/3 (QUIC)
- parempi mobiilissa
- vähemmän latencyä
15. Logging optimointi
Liiallinen logging hidastaa:
access_log off;
Tai eriytetty:
access_log /var/log/nginx/access.log main buffer=512k flush=1m;
16. WordPress-tason optimoinnit
NGINX ei riitä ilman WordPress-tason säätöjä:
- disable WP Cron → käytä system cron
- vähennä autoloaded options
- optimoi WP_Query
- käytä page cachea
- minimoi pluginien määrä
17. TTFB optimointistrategia
Paras yhdistelmä:
- NGINX FastCGI cache
- Redis object cache
- OPcache
- CDN edge cache
Tulos:
TTFB < 50ms cache hitissä
18. Yleisimmät virheet
- NGINX ilman cachea
- PHP-FPM liian pieni tai liian iso
- OPcache pois käytöstä
- ei Redis cachea
- liian monta pluginia WordPressissä
- ei static asset cachea
- ei CDN:ää
19. Paras kokonaisarkkitehtuuri
Skaalautuva WordPress NGINX stack:
- Cloudflare (edge cache)
- NGINX FastCGI cache
- PHP-FPM + OPcache
- Redis object cache
- MySQL optimoitu InnoDB:llä
- system cron WP-Cronin sijaan
- CDN static assetsille
Yhteenveto
NGINX-ympäristössä WordPressin suorituskyky ei riipu yhdestä asetuksesta vaan koko pinosta. Kun FastCGI cache, Redis, OPcache ja CDN toimivat yhdessä, WordPress muuttuu lähes staattiseksi järjestelmäksi yleisille käyttäjille ja samalla säilyttää dynaamisuuden kirjautuneille.
Hyvin optimoitu NGINX-WordPress stack pystyy käsittelemään suurta liikennettä erittäin pienellä palvelinkuormalla ja matalalla viiveellä.