Aeglane WordPress või WooCommerce: kuidas leida päris põhjus

Kolm kihti, kus laadimine venib

• Enne kui brauser midagi näeb. PHP käivitub, pluginad laaditakse, andmebaasist tehakse päringud ja HTML pannakse kokku. Mõõdik on TTFB. Kui siin kaob poolteist sekundit, ei võida sa seda piltide kokkupakkimisega tagasi.
• Laadimise ajal. HTML on kohal, aga brauser peab veel alla laadima CSS-i, fondid, pildid ja skriptid, enne kui midagi kasulikku näha on. Mõõdikud on LCP ja CLS.
• Pärast laadimist. Leht on nähtav, aga skriptid jooksevad edasi: slaiderid, jälgimispikslid, vestlusaken, ostukorvi värskendus. Mõõdik on INP.

Diagnostika ülesanne on välja selgitada, millises neist kolmest kihist sinu leht kõige rohkem aega kaotab. Enne seda on iga parandus lotomäng, ka siis, kui parandus ise on õige.

Kuidas kitsendada, ilma et midagi katki läheks

• Mõõda kahte erinevat lehte. Testi avalehte ja siis lehte, mida vahemälu ei kata: e-poes ostukorvi või kassat. Kui avaleht on kiire ja kassa aeglane, tuleb vastust otsida sealt, mis igal üksikul päringul PHP-s ja andmebaasis toimub.
• Vaata sisse logituna ja välja logituna. Sisse logitud kasutaja jaoks on leheküljevahemälu tavaliselt välja lülitatud. Kui leht on admin-kasutajana aeglane ja anonüümselt kiire, näed vahemälu taga peituvat tegelikku laadimisaega.
• Ava brauseri arendaja tööriistade Network-vaade. Sorteeri päringud kestuse järgi. Otsi kahte asja: kas esimene dokument ise võttis kaua aega (server) või kas mõni üksik fail on hiiglaslik või mõni väline päring lihtsalt ripub (kolmanda osapoole skript).
• Loe kokku päringute arv ja maht. Kui üks leht tõmbab sadu faile ja mitu megabaiti, ei päästa teda ükski vahemälu. Küsimus on selles, mis lehele on ehitatud.
• Kontrolli, mis taustal jookseb. Tarnija tootevoo import, varundus või e-kirjade järjekord keset tööpäeva sööb sama serveri ressurssi, mida su külastajad ootavad.
• Pane peale Query Monitor. See tasuta WordPressi plugin näitab lehe kohta päringute arvu, kõige aeglasemaid päringuid ja seda, milline plugin need tekitas. Pärast selle paigaldamist ei pea sa enam pakkuma, milline plugin aeglust tekitab: see on nimekirjas kirjas.

Enne kui midagi välja lülitad: tee varukoopia ja tee muudatused testkoopial. Töötavas e-poes pluginate kaupa katsetamine tähendab, et osa ostjaid satub täpselt sellele hetkele, kui midagi on pooleldi väljas.

Levinumad WordPressi aeglustajad

• Lehtede ehitajad. Elementor, Divi ja WPBakery toodavad iga sektsiooni kohta lisakihte HTML-i ning oma CSS- ja JS-faile. Admin on mugav, esileht on raske.
• Pluginad, mis laadivad end igal lehel. Broneerimisvorm, mida kasutab üks alamleht, laeb oma varad tavaliselt kõikjal, ka avalehel, kus seda kunagi ei kuvata.
• Originaalsuuruses pildid. 4000 pikslit lai foto, mida kuvatakse 800 piksli laiuselt, laetakse ikkagi täies mahus alla. Mobiilis on see sage LCP põhjus.
• Slaiderid ja taustavideod. Mitme slaidiga karussell on esilehe kõige raskem element ja külastaja näeb neist enamasti ainult esimest.
• Väline kraam. Vestlusaken, kaardid, Facebooki piksel, kaks analüütikat ja veebifondid. Iga tükk on eraldi ühendus võõra serveriga, mille kiirust sa ei kontrolli.
• Kattuv funktsionaalsus. Kaks vahemälupluginat, kaks SEO-pluginat, kolm vormipluginat. Nad teevad sama töö üksteise järel uuesti.
• WP-Cron külastaja seljas. Vaikimisi käivitab WordPress ajastatud tööd külastaja päringu ajal. Kui ajastatud töid on palju, maksab osa külastajaid nende eest ootamisega. Selle töö saab üle anda serveri enda ajastajale.
• Vana PHP ja puuduv objektivahemälu. Mõlemad on majutuse poolel. PHP versiooni saab juhtpaneelist tavaliselt ise vahetada, objektivahemälu (Redis või Valkey) sõltub sellest, kas pakett seda üldse pakub.

Mis on WooCommerce'is teistmoodi

Enamik WordPressi kiirusnõuandeid eeldab vaikimisi, et lehe saab vahemällu panna ja siis on asi korras. E-poes see eeldus ostukorvi ja kassa kohta ei kehti.

• Ostukorv, kassa ja konto ei lähe vahemällu. Nende sisu on iga külastaja jaoks erinev, seega WooCommerce ütleb vahemälule otse, et neid lehti salvestada ei tohi. Iga selline laadimine on täismahus PHP ja andmebaasi töö. Tulemus: sinu poe kiireim leht on avaleht ja aeglaseim see, kus ostja maksab.
• Ostukorvi fragmendid. Päise mini-ostukorv peab näitama õiget seisu, seega WooCommerce värskendab seda eraldi vahemälustamata päringuga. Viimaste aastate versioonid hoiavad tulemust brauseri mälus, aga esimesel külastusel ja iga ostukorvi muutuse järel käib päring ikka PHP-st läbi.
• Tootefiltrid ja kihiline navigatsioon. Iga filtrikombinatsioon on omaette andmebaasipäring ja omaette URL. Kombinatsioone tekib nii palju, et vahemälu ei jõua neile järele. Suure kataloogiga poes jääb leht just filtrite peal kõige sagedamini seisma.
• Kataloog ei kasva lineaarselt. Iga toode toob kaasa hulga meta-kirjeid ja iga variatsioon - suurus, värv, pakendi maht - veel omakorda. Mitu tuhat toodet ei tähenda mitut tuhat rida andmebaasis, vaid sadu tuhandeid.
• Sessioonid ja ajastatud tööd. WooCommerce peab külastajate sessioone ja kasutab taustatööde jaoks Action Scheduleri tabeleid. Vanas poes, kust neid kunagi koristatud ei ole, kasvavad need tabelid aastatega suureks.
• Tellimuste salvestus. Uuemas WooCommerce'is on tellimuste jaoks eraldi tabelid (HPOS). Vanemas poes istuvad tellimused samas tabelis koos toodete ja lehtedega, nii et iga juurde tulnud tellimus teeb ka tootepäringu raskemaks.
• Tootevoogude import. Kui tarnija XML või API-voog jookseb sisse keset päeva, konkureerib import sama serveri ressursi pärast su ostjatega. Selle nihutamine öisesse aega on mõnikord kogu lahendus.

Millal on probleem majutuses

• TTFB on suur ka lihtsal vahemälustatud lehel ja ka öösel, kui liiklust praktiliselt ei ole.
• Leht on hommikul kiire ja pärastlõunal aeglane: jagatud majutuse ressursipiirang hakkab koormuse kasvades pidurdama.
• WordPressi admin on aeglane, kuigi esileht tundub korras. Admini poolel leheküljevahemälu ei aita, nii et see näitab serveri võimekust otse.
• PHP töötab vanal versioonil või objektivahemälu (Redis, Valkey) ei ole paketis üldse saadaval.
• Koormuse ajal tulevad 502 või 504 vead.

Kontroll on lihtne: pane serverisse üks tavaline HTML-fail, mille taga ei ole WordPressi, ja mõõda selle laadimist. Kui ka see on aeglane, ei aita ükski WordPressi-poolne parandus - viga on serveris. Kui see on kiire, aga sinu leht mitte, on põhjus WordPressi sees.

Millal on probleem teemas või pluginates

• TTFB on korras, aga leht tõmbab sadu faile ja mitu megabaiti CSS-i ning JavaScripti.
• Sama sisu laeb testkoopial WordPressi vaiketeemaga kordades kiiremini.
• Aeglus algas pärast ühe plugina või teemauuenduse paigaldamist ja keegi ei seostanud neid kahte omavahel.
• Üks kindel lehetüüp, näiteks tootekategooria või otsingutulemus, on teistest selgelt aeglasem.

Meetod on tüütu, aga ainus, mis annab kindla vastuse: tee lehest testkoopia, lülita kõik pluginad välja ja lülita neid ükshaaval tagasi, mõõtes iga sammu järel. Süüdlaseks osutub harva üks halb plugin. Sagedamini tuleb välja mitu keskmise raskusega pluginat korraga, millest osa ei kasuta enam keegi.

Millal on probleem andmebaasis

• Nii esileht kui admin on aeglased ning eriti aeglased on otsing, tootenimekirjad ja filtrid.
• Leht muutus aeglaseks järk-järgult, ilma et keegi oleks midagi paigaldanud või muutnud.
• Query Monitor näitab üksikuid päringuid, mis võtavad sadu millisekundeid.
• Andmebaas on mitu korda suurem, kui sisu maht seda seletaks.

Kõige tavalisemad põhjused on need:

• Autoload-read wp_options tabelis. Need loetakse igal üksikul päringul, ka siis, kui plugin, mis need kirjutas, on ammu kustutatud.
• Aegunud transientid. Kui objektivahemälu ei ole, elavad ajutised vahetulemused andmebaasis ja neid ei koristata alati ära.
• Orvuks jäänud meta-read. Kustutatud toodete ja vanade imporditsüklite jäljed jäävad tabelisse alles ning teevad iga tootepäringu raskemaks.
• Koristamata taustatööde ja sessioonide tabelid. Admini vaates neid tabeleid ei näe, seega tuleb nende suurust vaadata otse andmebaasist.
• Postituste revisjonid. Iga salvestus jätab wp_posts tabelisse uue rea. Suure sisumahuga lehel tasub revisjonide arvu piirata (WP_POST_REVISIONS), kümne alalehega firmalehel ei ole see kiiruse põhjus.

Andmebaasi puhastusplugina ühekordne käivitamine on harva lahendus. Kasulik samm on tuvastada, milline päring on aeglane ja miks. Alles siis on teada, kas aitab koristamine, indeks, objektivahemälu või hoopis selle päringu ümberkirjutamine.

Mida omanik saab ise ära teha

• Tee varukoopia ja muuda ühte asja korraga. Kaks muudatust korraga ei ütle sulle kunagi, kumb neist mõjus.
• Vähenda pilte enne üleslaadimist. Ükski plugin ei tee 5 MB fotost nii head tulemust kui see, kui laed algusest peale üles 200 kB pildi.
• Kustuta pluginad, mida ei kasutata. Väljalülitamisest ei piisa: väljalülitatud plugin on endiselt uuendamata koodihunnik serveris.
• Loobu taustavideost ja mitmeslaidilisest karussellist. See on tavaliselt üks otsus, mis annab mobiilis kohe nähtava võidu.
• Vaata üle välised skriptid. Iga vestlusaken, piksel ja kaart peab oma koha ära teenima. Kui keegi neist tulevaid andmeid ei vaata, võib skripti ära jätta.
• Kontrolli majutuse juhtpaneelist PHP versiooni. Ja lülita objektivahemälu sisse, kui pakett seda võimaldab.
• Mõõda enne ja pärast. Sama leht, sama kellaaeg, vähemalt kolm mõõtmist. Üksik test kõigub niikuinii mõne punkti võrra.

Kui sa ei tea, mida mõni plugin täpselt teeb, ära kustuta seda enne, kui keegi on üle vaadanud. Kadunud broneerimissüsteem või katkenud makseühendus on kallim kui paar sekundit laadimisaega.

Mis ei aita nii palju, kui loodetakse

• Vahemälu plugin üksinda. See teeb kiiremaks need lehed, mis olid niigi kiiremad, ja jätab puutumata ostukorvi, kassa ja konto, kus ostja aega kaotab. Halvemal juhul lõhub liiga agressiivne seadistus ostukorvi nii, et viga avastatakse alles paari päeva pärast kaotatud tellimustest.
• Kaks vahemälupluginat korraga. Nende mõju ei liitu. Nad seisavad teineteise ees ja teevad vea otsimise oluliselt raskemaks.
• Ainult piltide kokkupakkimine. Kui LCP-element on JavaScriptiga laetav slaider või kui TTFB on poolteist sekundit, ei muuda WebP-le üleminek tervikpilti.
• Ühe klikiga optimeerimisrežiim. JavaScripti edasilükkamine ja CSS-i kokkupanek võivad WooCommerce'i ostukorvi või makselahenduse vaikselt katki teha. Testimata seadistus on rohkem risk kui kasu.
• Majutuse vahetamine ilma mõõtmiseta. Kui probleem on teemas või andmebaasis, tuleb ta uude serverisse kaasa. Kolimine tasub end ära alles siis, kui mõõtmine osutab serverile.
• PageSpeed 100 taga ajamine. Skoor näitab, kust vaadata. Ostjale loeb see, kui kiiresti kassaleht vastab: kiire kassa keskmise skooriga teenib teda paremini kui kõrge skoor lehel, kus maksmine venib.

Millal ise enam ei jõua

• Mõõtmine osutab serverile või andmebaasile, kus vale liigutust ei saa ilma varukoopiata tagasi pöörata.
• Parandus nõuab teema koodi muutmist. Otse teemas tehtud muudatus kaob järgmise uuendusega, seega on vaja lapsteemat või eraldi lahendust.
• Iga katse parandada üht asja lõhub midagi muud.
• Tegemist on töötava e-poega, kus iga tund live-keskkonnas katsetamist maksab käivet.
• Testkeskkonda ei ole ja töötava poe peal katsetamine ei ole vastuvõetav risk.

Sellest kohast edasi on mõistlik lasta keegi teine mõõtma ja parandama. Seda tööd teen kodulehe kiiruse optimeerimise teenusena: kõigepealt audit, siis suurima mõjuga parandused, siis mõõtmine uuesti. Kui leht on pärast seda korras, hoiab jooksev veebilehe hooldus ära selle, et kiirus järgmise aasta jooksul uuenduste ja uue sisuga jälle alla vajuks.