WordPressin admin-suorituskyky: Pullonkaulat ja ratkaisut

WordPressin admin-suorituskyky kokonaisuutena

WordPressin hallintapaneeli on monelle sivustolle kriittisin käyttöliittymä. Kun admin hidastuu, koko työ pysähtyy: sisällöntuotanto takkuaa, ylläpito turhauttaa ja virheiden määrä kasvaa. Admin-suorituskyky on kuitenkin usein huonompi kuin frontend, koska sitä ei ole suunniteltu skaalautuvaksi käyttöliittymäksi samalla tavalla.

Admin ei ole vain näkymä. Se on kasa synkronisia pyyntöjä, koukkuja ja lisäosia, jotka kilpailevat jokaisesta millisekunnista.

Miksi WordPress-admin hidastuu

Admin ajetaan aina PHP:llä

Toisin kuin frontend:

• adminia ei yleensä cacheta HTTP-tasolla

• lähes jokainen sivu on käyttäjäkohtainen

• jokainen klikkaus tarkoittaa PHP:n ajoa

Tämä tekee administa erityisen herkän pienillekin tehottomuuksille.

Admin lataa paljon enemmän kuin näyttää

Yksi admin-sivu voi:

• suorittaa kymmeniä hookeja

• ajaa useita WP_Query-kyselyitä

• ladata JS- ja CSS-paketteja globaalisti

Moni lisäosa lisää logiikkaa adminiin “varmuuden vuoksi”, vaikka sitä ei tarvita kyseisellä sivulla.

Yleisimmät pullonkaulat adminissa

Liialliset hookit

Adminissa:

• admin_init

• init

• current_screen

ovat usein ylikuormitettuja. Kun raskas logiikka ajetaan jokaisella admin-pyynnöllä, hidastuminen kertautuu nopeasti.

wp_options-taulu

Admin lukee wp_options-taulua jatkuvasti. Ongelmia syntyy, kun:

• taulu kasvaa hallitsemattomasti

• autoload-optioita on liikaa

• tilapäistä dataa ei poisteta

Yksi paisunut options-taulu vaikuttaa kaikkiin admin-sivuihin.

Autoload ei ole ilmainen

Autoload-optioita:

• ladataan jokaisella pyynnöllä

• ei voi ohittaa helposti

• käytetään usein väärin

Moni lisäosa tallentaa suuria rakenteita autoloadina, vaikka niitä tarvitaan vain tietyssä näkymässä.

JavaScript ja admin-käyttöliittymä

Globaalisti ladattu JS

Adminin JS-ongelmat syntyvät usein siitä, että:

• skriptejä ladataan kaikille sivuille

• riippuvuudet ovat raskaita

• buildit ovat vanhentuneita

Yksi raskas React-pohjainen näkymä voi hidastaa koko adminia, jos se ladataan globaalisti.

Gutenberg ei ole ainoa syyllinen

Block editor saa usein syyt, mutta:

• monet ongelmat ovat custom-lisäosissa

• vanhat kirjastot kuormittavat selainta

• tapahtumakuuntelijoita kertyy

Adminin frontend on yhtä haavoittuva kuin julkinen frontend.

AJAX ja REST adminissa

Jokainen pyyntö maksaa

Admin käyttää AJAXia ja RESTiä laajasti. Ongelmia syntyy, kun:

• endpointit palauttavat liikaa dataa

• kutsuja tehdään liian usein

• vasteaika on korkea

Hidas REST endpoint näkyy suoraan adminin tahmeutena.

Pollaus vs. tapahtumat

Moni admin-näkymä:

• pollaa palvelinta jatkuvasti

• ei rajoita kutsuja

• ei käytä välimuistia

Tämä kuormittaa sekä selainta että backendia turhaan.

Tietokantapullonkaulat

Adminin kyselyt eivät ole viattomia

Admin-näkymät voivat:

• listata tuhansia rivejä

• tehdä COUNT-kyselyitä

• käyttää monimutkaisia JOINeja

Ilman indeksejä ja rajoituksia admin-sivut hidastuvat eksponentiaalisesti.

Metadatan ylikuormitus

Postmeta ja usermeta:

• kasvavat nopeasti

• sisältävät epäyhtenäistä dataa

• hidastavat listanäkymiä

Admin kärsii tästä ensimmäisenä.

Ratkaisut admin-suorituskykyyn

Aja koodi vain oikeassa kontekstissa

Raskas logiikka tulee:

• sitoa tiettyyn admin-sivuun

• estää ajautumasta globaaliksi

• erottaa frontendistä

Yksi if-lause voi säästää satoja millisekunteja.

Siivoa wp_options

Säännöllinen siivous:

• vähentää autoload-dataa

• parantaa kaikkia pyyntöjä

• vakauttaa adminin

Admin-suorituskyky paranee usein ilman koodimuutoksia.

Optimoi listanäkymät

Admin-listoissa:

• rajoita oletusmäärät

• poista turhat sarakkeet

• vältä raskaita laskentoja

Kaikki data ei kuulu näkyville kerralla.

Välimuisti adminissa

Object cache auttaa adminiakin

Vaikka HTTP-cache ei toimi adminissa:

• object cache toimii

• transients vähentävät kyselyitä

• toistuvat laskennat voidaan välttää

Admin ei ole cache-vapaa alue.

Seuranta ja mittaus

Adminin suorituskykyä voi mitata

Hyviä työkaluja ovat:

• Query Monitor

• selaimen performance-työkalut

• PHP slow log

Ilman mittausta optimointi on arvailua.

Milloin admin on “riittävän nopea”

Admin on onnistunut, kun:

• sivut latautuvat ennustettavasti

• viive ei vaihtele hallitsemattomasti

• raskaat toiminnot on erotettu taustatöiksi

Admin ei koskaan ole yhtä nopea kuin frontend, mutta sen ei tarvitsekaan olla tuskallisen hidas.

Lopuksi: Admin on työväline, ei demo

WordPressin admin-suorituskyky ei parane yhdellä tempulla. Se paranee:

• karsimalla

• rajaamalla

• mittaamalla

Kun admin nähdään tuotantotyökaluna eikä vain käyttöliittymänä, sen suorituskykyyn aletaan suhtautua vakavasti. Ja silloin myös käyttäjät kiittävät.