@harrasteblogi JUURI NYT
--:--

Tilaa uutiskirje

Saat tuoreimmat 10 uusinta artikkelia kerran viikossa sähköpostiisi.

Tilaa uutiskirje

WordPressin palvelinoptimointi NGINX-ympäristössä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.

Tiivistelmä
1. Perusarkkitehtuuri

Tyypillinen optimoitu stack:...

2. NGINX FastCGI cache (tärkein optimointi)

FastCGI cache muuttaa WordPressin lähes staattiseksi sivuksi....

3. Cache bypass logiikka

Älä cacheta kaikkea...

5. PHP-FPM optimointi

NGINX toimii vain niin hyvin kuin PHP-FPM....

6. OPcache optimointi

Ilman OPcachea WordPress on hidas....

7. Gzip tai Brotli

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...

8. Static asset optimointi

NGINX hoitaa nämä suoraan ilman PHP:tä...

9. WordPress rewrite optimointi

location / { try_files $uri $uri/ /index.php?$args; } 👉 yksinkertainen ja tehokas routing...

11. Redis object cache

Erittäin tärkeä WordPressissä...

12. NGINX buffering ja timeoutit

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...

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...

14. HTTP/2 ja HTTP/3

listen 443 ssl http2; HTTP/3 (QUIC) parempi mobiilissa vähemmän latencyä 15. Logging optimointi Liiallinen logging hidastaa:...

15. Logging optimointi

Liiallinen logging hidastaa:...

16. WordPress-tason optimoinnit

NGINX ei riitä ilman WordPress-tason säätöjä:...

17. TTFB optimointistrategia

Paras yhdistelmä:...

18. Yleisimmät virheet

Skaalautuva WordPress NGINX stack:...

19. Paras kokonaisarkkitehtuuri

Skaalautuva WordPress NGINX stack:...

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...


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ä.

🍪