Kā paātrināt WordPress: ko īsti dara katrs kešatmiņas slānis

Šī rokasgrāmata izved cauri tipiskas WordPress vietnes kešošanas slāņiem no augšas uz leju: ko katrs slānis dara, kāpēc dažas lapas to apiet, kādā secībā visu ieslēgt un kā pārbaudīt rezultātu ar reāliem skaitļiem. Tā domāta vietņu īpašniekiem un administratoriem, kas var rediģēt wp-config.php un palaist dažas komandas caur SSH.

Kā slāņi sakārtojas

Pieprasījums uz WordPress lapu iziet cauri vairākām stacijām: apmeklētāja pārlūks, tīmekļa serveris ar pilnas lapas kešatmiņu, PHP interpretators ar OPcache, objektu kešatmiņa un visbeidzot MySQL. Katrs slānis stāv nākamā priekšā, un trāpījums augstākā slānī nozīmē, ka viss zem tā nedara neko. Pilnas lapas keša trāpījums pilnībā izlaiž PHP un datubāzi. Objektu keša trāpījums joprojām darbina PHP, bet izlaiž atkārtotos datubāzes vaicājumus. Tāpēc slāņi nav savstarpēji aizvietojami: katrs palīdz citam trafika veidam.

Pilnas lapas kešatmiņa: lielākais atsevišķais ieguvums

Pilnas lapas kešatmiņa saglabā lapas gatavo HTML un pasniedz to nākamajam apmeklētājam, WordPress vispār nestartējot. Anonīmam trafikam tas ir lielākais iespējamais uzlabojums: atbilde no keša aizņem dažas milisekundes vairāku simtu vietā, jo nedarbojas PHP un netiek izpildīts neviens datubāzes vaicājums.

Ielogojušos lietotāju lapas un iepirkumu grozi šo kešu apiet apzināti. To HTML ir personalizēts: administratora josla, lietotāja vārds, groza saturs. Kešotas kopijas pasniegšana parādītu vienam apmeklētājam cita apmeklētāja datus. Tāpēc kešošanas spraudņi un servera noteikumi izlaiž kešu, tiklīdz redz tādas sīkdatnes kā wordpress_logged_in_* vai woocommerce_cart_hash. Praktiskais secinājums: veikals, kurā lielākā daļa pircēju ir ielogojusies, no lapas keša iegūst krietni mazāk un ir stipri atkarīgs no zemākajiem slāņiem.

Pārbaudi, vai lapa nāk no keša, apskatot atbildes galvenes:

curl -sI https://example.com/ | grep -i -E "x-cache|age|cache-control"

Objektu kešatmiņa: ko Redis īsti ietaupa

Pēc noklusējuma WordPress katrā pieprasījumā visu būvē no jauna no MySQL: automātiski ielādētās opcijas, lietotāju un ierakstu metadatus, taksonomiju saites, spraudņu iestatījumus, izvēļņu struktūras. Lielākā daļa šo vaicājumu tūkstošiem reižu dienā atgriež vienu un to pašu rezultātu. Pastāvīga objektu kešatmiņa šos rezultātus glabā Redis atmiņā, tāpēc nākamais pieprasījums tos nolasa, datubāzei nepieskaroties.

Efekts ir vislielākais tieši tur, kur pilnas lapas kešatmiņa ir bezspēcīga: wp-admin, ielogojušies lietotāji, WooCommerce pirkuma noformēšana, REST API izsaukumi. Nekešota lapas atvēršana bieži izpilda 100 un vairāk vaicājumu; ar uzsildītu Redis kešu šis skaits nokrīt līdz dažiem desmitiem.

wp plugin install redis-cache --activate
wp redis enable
wp redis status

Ja wp redis status rāda savienojumu un augošu atslēgu skaitu, viss strādā. Tipiskai vietnei Redis prasa pieticīgu atmiņas apjomu: parasti pietiek ar 64 līdz 256 MB.

OPcache: nekompilē PHP katrā pieprasījumā

PHP pirms izpildes tiek kompilēts baitkodā. Bez OPcache interpretators katrā pieprasījumā pārkompilē WordPress kodolu, tēmu un visus spraudņus, viegli vairākus tūkstošus failu. OPcache tur kompilēto baitkodu koplietojamā atmiņā, tāpēc šī cena tiek samaksāta vienu reizi pēc koda izmaiņām, nevis nepārtraukti.

Jebkura mūsdienu PHP versija ietver OPcache, un tīmekļa serverim tas parasti ir ieslēgts. Pārbaudi to caur tīmekļa SAPI, nevis komandrindu: php -r darbojas CLI vidē, kur opcache.enable_cli pēc noklusējuma ir izslēgts, tāpēc CLI pārbaude rāda false pat tad, kad PHP-FPM pusē OPcache strādā bez problēmām. Ieliec pagaidu failu tīmekļa saknē, pieprasi to caur HTTP un pēc tam izdzēs:

echo ' /var/www/html/opcache-check.php
curl -s https://example.com/opcache-check.php
rm /var/www/html/opcache-check.php

bool(true) nozīmē, ka OPcache ir aktīvs īstiem tīmekļa pieprasījumiem. Saprātīgi php.ini iestatījumi WordPress vajadzībām: opcache.memory_consumption=192 un opcache.max_accelerated_files=20000. Ja atjaunini kodu, kopējot failus, atstāj opcache.validate_timestamps=1, lai izmaiņas tiktu pamanītas.

Pārlūka kešošana un attēlu formāti

Lētākais pieprasījums ir tas, kuru pārlūks nemaz nenosūta. Statiskie resursi: CSS, JavaScript, fonti un attēli, klienta pusē jākešo uz ilgu laiku. WordPress pievienotajiem resursiem pieliek ?ver= parametru, tāpēc ilgs derīguma termiņš ir drošs: kad fails mainās, mainās arī tā URL. Tipisks nginx noteikums:

location ~* \.(css|js|png|jpg|jpeg|gif|svg|webp|avif|woff2)$ {
    expires 365d;
    add_header Cache-Control "public, immutable";
}

Attēla formāts nozīmē tikpat daudz, cik tā kešošana. WebP parasti ir par 25 līdz 30 procentiem mazāks nekā līdzvērtīgs JPEG, un AVIF vēl par 15 līdz 20 procentiem mazāks nekā WebP, samaksājot ar lēnāku kodēšanu. Konvertē augšupielādes brīdī ar spraudni vai cron uzdevumu, saglabā oriģinālu kā rezerves variantu un nepārkodē failus, kas jau ir optimizēti: katra pārkodēšana ar zudumiem samazina kvalitāti.

Darbu secība, mērīšana un piecu spraudņu mīts

Ieslēdz slāņus šādā secībā un mēri pēc katra soļa, nevis vienu reizi beigās:

1. Pārbaudi OPcache. Tas ir pamats, nerada risku un neprasa spraudni.
2. Pilnas lapas kešatmiņa. Lielākais ieguvums anonīmajam trafikam.
3. Redis objektu kešatmiņa. Palīdz ielogotajiem lietotājiem, wp-admin un WooCommerce, tieši tam trafikam, ko lapas kešs nevar apkalpot.
4. Pārlūka kešošana un expires galvenes.
5. WebP vai AVIF attēliem.

Skaitlis, kuram sekot, ir TTFB, laiks līdz pirmajam baitam, jo kešošanas slāņi nostrādā, pirms pirmais baits atstāj serveri:

curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s  total: %{time_total}s\n" https://example.com/

Palaid komandu 5 reizes un atmet pirmo rezultātu: tas var trāpīt aukstā kešā. Nekešota WordPress lapa parasti rāda TTFB no 300 līdz 800 ms; pilnas lapas keša trāpījumam jāpaliek krietni zem 100 ms.

Un visbeidzot mīts: piecu kešošanas spraudņu uzstādīšana nedod pieckārtīgu paātrinājumu. Divas lapas kešatmiņas pasniedz viena otras novecojušās kopijas, dubulta minifikācija salauž JavaScript, un iztīrīšana vienā spraudnī neaizsniedz kopiju, ko glabā otrs. Izmanto vienu rīku katrā slānī un dod priekšroku lapas kešatmiņai servera līmenī, nevis PHP iekšpusē.

Mūsu WordPress hostinga plānos viss šis komplekts, servera līmeņa lapas kešatmiņa, Redis un OPcache, jau ir sakonfigurēts, tāpēc no saraksta augstāk paliek tikai mērīšana. Ja gribi visu uzstādīt pats, tos pašus slāņus atbalsta jebkurš no mūsu mājas lapu hostinga plāniem.