Tänään WordPress toimii yli 30% Internetistä . Se on helppokäyttöinen, uskomattoman suosittu eikä mene mihinkään pian.

Mutta WordPress voi olla hidas. Joten miten optimoida se?

On paljon artikkeleita WordPressin virittämisestä ja optimoinnista. Itse asiassa WordPress itse tarjoaa kestävä opas WordPress-optimoinnista.

Suurimmaksi osaksi nämä artikkelit ja oppaat kattavat melko peruskäsitteitä, mutta hyödyllisiä käsitteitä, kuten välimuistilaajennusten käyttämisen, integroinnin sisällönjakeluverkkoihin ja pyyntöjen minimoimisen. Vaikka nämä vinkit ovat erittäin tehokkaita ja jopa välttämättömiä, ne eivät lopulta korjaa taustalla olevaa ongelmaa: Useimmat hitaat WordPress-sivustot ovat seurausta huonosta tai tehottomasta koodista.

WordPress voi olla hidas, mutta sen ei tarvitse olla. Tweet

Siksi tämä artikkeli on pääasiassa tarkoitettu tarjoamaan kehittäjille ja WordPress-kehitysyritykset joidenkin ohjeiden avulla, jotka voivat auttaa heitä ratkaisemaan WordPressin suorituskykyongelmien taustalla olevat syyt.

WordPress tarjoaa monia suorituskykyyn liittyviä ominaisuuksia, jotka kehittäjät usein unohtavat. Koodi, joka ei hyödynnä näitä ominaisuuksia, voi hidastaa yksinkertaisia ​​tehtäviä, kuten viestien noutamista. Tässä artikkelissa kuvataan neljä mahdollista ratkaisua, joissa käsitellään joitain hitaan WordPress-suorituskyvyn taustalla olevia ongelmia.

Haetaan viestejä

WordPress tarjoaa mahdollisuuden hakea minkä tahansa tyyppisiä viestejä tietokannasta. Tähän on kolme perustapaa:

• query_posts() toiminto: Tämä on hyvin suora lähestymistapa, mutta ongelmana on, että se ohittaa tärkeimmän kysely , mikä voi aiheuttaa haittaa. Esimerkiksi, tämä voi olla ongelma, jos haluamme jossain vaiheessa selvittää viestien noutamisen jälkeen (kuten sisällä footer.php), millaista sivua olemme tekemisissä. Itse asiassa virallisissa asiakirjoissa on huomautus, jossa suositellaan tämän toiminnon käyttöä, koska alkuperäisen kyselyn palauttamiseksi sinun on kutsuttava lisätoiminto. Lisäksi pääkyselyn korvaaminen vaikuttaa kielteisesti sivujen latausaikoihin.

• get_posts() toiminto: Tämä toimii melkein kuten query_posts(), mutta se ei muuta pääkyselyä. Toisaalta get_posts() suorittaa oletusarvoisesti kyselyn suppress_filters parametriksi asetettu true. Tämä voi johtaa epäjohdonmukaisuuksiin, varsinkin jos käytämme kyselyyn liittyviä suodattimia koodissamme, koska tämä toiminto saattaa palauttaa viestit, joita et odota sivulla.

• WP_Query luokka: Mielestäni tämä on paras tapa hakea viestejä tietokannasta. Se ei muuta pääkyselyä, ja se suoritetaan normaalilla tavalla, kuten mikä tahansa muu WordPress-kysely.

Mutta mitä menetelmää käytämme vuorovaikutuksessa tietokannan kanssa, on muitakin asioita, jotka on otettava huomioon.

Kyselyn rajoittaminen

Meidän tulisi aina määritellä, kuinka monta viestiä kyselymme on haettava.

Tämän saavuttamiseksi käytämme posts_per_page parametri.

WordPress antaa meille mahdollisuuden osoittaa -1 parametrin mahdolliseksi arvoksi, jolloin järjestelmä yrittää noutaa kaikki määritetyt ehdot täyttävät viestit.

Tämä ei ole hyvä käytäntö, vaikka olemme varmoja, että saamme vastauksena vain muutaman tuloksen.

Ensinnäkin, voimme harvoin olla varmoja siitä, että saamme vain muutaman tuloksen takaisin. Ja vaikka voimme, ei rajoitusten asettaminen vaatii tietokantamoottorin tarkistamaan koko tietokanta etsimällä otteluita.

Sitä vastoin tulosten rajoittaminen antaa tietokantamoottorille mahdollisuuden skannata tiedot vain osittain, mikä johtaa vähemmän käsittelyaikaan ja nopeampaan vasteeseen.

Toinen asia, jonka WordPress tekee oletuksena, mikä voi vaikuttaa haitallisesti suorituskykyyn, on se, että se yrittää tuoda tahmeat viestit ja laskea, kuinka monta riviä kyselyssä löytyi.

Usein emme kuitenkaan todellakaan tarvitse kyseisiä tietoja. Näiden kahden parametrin lisääminen poistaa nämä ominaisuudet käytöstä ja nopeuttaa kyselymme:

$query = new WP_Query( array( 'ignore_sticky_posts' => true, 'no_found_rows' => true ) );

Viestien poissulkeminen kyselystä

Joskus haluamme jättää tietyt viestit kyselystä. WordPress tarjoaa melko suoran tavan saavuttaa se: käyttämällä post__not_in parametri. Esimerkiksi:

$posts_to_exclude = array( 1, 2, 3 ); $posts_per_page = 10; $query = new WP_Query( array( 'posts_per_page' => $posts_per_page, 'post__not_in' => $posts_to_exclude ) ); for ( $i = 0; $i posts ); $i++ ) { //do stuff with $query->posts[ $i ] }

Mutta vaikka tämä on melko yksinkertaista, se ei ole optimaalinen, koska sisäisesti se tuottaa alikyselyn. Varsinkin suurissa asennuksissa tämä voi johtaa hitaaseen vastaukseen. Nopeampi on antaa käsittelyn suorittaa PHP-tulkin kanssa yksinkertaisilla muutoksilla:

$posts_to_exclude = array( 1, 2, 3 ); $posts_per_page = 10; $query = new WP_Query( array( 'posts_per_page' => $posts_per_page + count( $posts_to_exclude ) ) ); for ( $i = 0; $i posts ) && $i posts[ $i ]->ID, $posts_to_exclude ) ) { //do stuff with $query->posts[ $i ] } }

Mitä tein siellä?

Pohjimmiltaan otin jonkin verran työtä tietokantamoottorista ja jätin sen sijaan PHP-moottorille, joka tekee samoja juttuja, mutta muistissa, mikä on paljon nopeampi.

Miten?

Ensin poistin post__not_in parametri kyselystä.

Koska kysely saattaa tuoda meille joitain viestejä, joita emme halua sen seurauksena, lisäsin posts_per_page parametri. Tällä tavoin varmistan, että vaikka minulla olisi ollut ei-toivottuja viestejä vastauksessani, minulla olisi ainakin $posts_per_page halutut viestit siellä.

Sitten, kun silmukan viestejä, käsittelen vain ne, jotka eivät ole $posts_to_exclude: n sisällä taulukko.

Monimutkaisen parametroinnin välttäminen

Kaikki nämä kyselymenetelmät tarjoavat monenlaisia ​​mahdollisuuksia viestien hakemiseen: luokittain, metaavaimilla tai arvoilla, päivämäärän, kirjoittajan jne. mukaan

Ja vaikka tämä joustavuus on tehokas ominaisuus, sitä tulisi käyttää varoen, koska parametrointi voi johtaa monimutkaisiin taulukkoliitäntöihin ja kalliisiin tietokantatoimintoihin.

Seuraavassa osassa hahmotellaan tyylikäs tapa saavuttaa samanlainen toiminnallisuus suorituskykyä tinkimättä.

Eniten irti WordPress-vaihtoehdoista

WordPress Options -sovellusliittymä tarjoaa sarjan työkaluja tietojen lataamiseen tai tallentamiseen helposti. Se on hyödyllinen käsiteltäessä pieniä tietoja, joiden muut WordPressin tarjoamat mekanismit (kuten viestit tai taksonomiat) ovat liian monimutkaisia.

Esimerkiksi, jos haluamme tallentaa todennusavaimen tai sivustomme otsikon taustavärin, etsimme vaihtoehtoja.

WordPress ei vain anna meille toimintoja niiden käsittelyyn, vaan se antaa meille myös mahdollisuuden tehdä niin tehokkaimmalla tavalla.

Jotkut vaihtoehdoista ladataan jopa suoraan, kun järjestelmä käynnistyy , mikä tarjoaa meille nopeamman pääsyn (kun luot uuden vaihtoehdon, meidän on harkittava, haluatko lähettää sen automaattisesti vai ei).

Mieti esimerkiksi sivustoa, jolla meillä on karuselli, joka näyttää viimeisimmät uutiset. Ensimmäinen vaistomme olisi käyttää meta-avainta siihen seuraavasti:

// functions.php add_action( 'save_post', function ( $post_id ) { // For simplicity, we do not include all the required validation before saving // the meta key: checking nonces, checking post type and status, checking // it is not a revision or an autosaving, etc. update_post_meta( $post_id, 'is_breaking_news', ! empty ( $_POST['is_breaking_news'] ) ); } ); // front-page.php $query = new WP_Query( array( 'posts_per_page' => 1, 'meta_key' => 'is_breaking_news' ) ); $breaking_news = $query->posts[0] ?: NULL;

Kuten näette, tämä lähestymistapa on hyvin yksinkertainen, mutta se ei ole optimaalinen. Se suorittaa tietokantakyselyn ja yrittää löytää viestin tietyllä metaavaimella. Voisimme käyttää vaihtoehtoa samanlaisen tuloksen saavuttamiseksi:

// functions.php add_action( 'save_post', function ( $post_id ) { // Same comment for post validation if ( ! empty ( $_POST['is_breaking_news'] ) ) update_option( 'breaking_news_id', $post_id ); } ); // front-page.php if ( $breaking_news_id = get_option( 'breaking_news_id' ) ) $breaking_news = get_post( $breaking_news_id ); else $breaking_news = NULL;

Toiminnallisuus vaihtelee hieman esimerkistä toiseen.

Ensimmäisessä koodikappaleessa saamme aina viimeisimmät uutiset julkaisun julkaisupäivän suhteen.

Toisessa, joka kerta, kun uusi viesti asetetaan uutiset, se korvaa edelliset uutiset.

Mutta koska haluamme todennäköisesti yhden uutiset kerrallaan, sen ei pitäisi olla ongelma.

Ja lopulta muutimme raskaan tietokantakyselyn (käyttäen WP_Query metaavaimilla) yksinkertaiseksi ja suoraksi kyselyksi (kutsumalla get_post()), mikä on parempi ja suorituskykyisempi lähestymistapa.

Voisimme myös tehdä pienen muutoksen ja käyttää transientteja vaihtoehtojen sijaan.

Siirtymät toimivat samalla tavalla, mutta antavat meille mahdollisuuden määrittää vanhentumisaika.

Esimerkiksi uutiset, se sopii kuin hansikas, koska emme halua vanhaa viestiä uutisena, ja jos jätämme tehtävän muuttaa tai poistaa kyseiset uutiset järjestelmänvalvojalle, hän voisi unohtaa tehdä se. Joten kahdella yksinkertaisella muutoksella lisätään viimeinen voimassaolopäivä:

// functions.php add_action( 'save_post', function ( $post_id ) { // Same comment for post validation // Let's say we want that breaking news for one hour // (3600 = # of seconds in an hour). if ( ! empty ( $_POST['is_breaking_news'] ) ) set_transient( 'breaking_news_id', $post_id, 3600 ); } ); // front-page.php if ( $breaking_news_id = get_transient( 'breaking_news_id' ) ) $breaking_news = get_post( $breaking_news_id ); else $breaking_news = NULL;

Ota pysyvä välimuisti käyttöön

WordPressillä on luonnollisesti kohteen välimuistimekanismi .

Esimerkiksi vaihtoehdot tallennetaan välimuistiin kyseisen mekanismin avulla.

Mutta oletusarvoisesti välimuisti ei ole pysyvää, mikä tarkoittaa, että se elää vain yhden pyynnön ajan. Kaikki tiedot tallennetaan välimuistiin nopeamman pääsyn varmistamiseksi, mutta ne ovat käytettävissä vain pyynnön aikana.

Pysyvän välimuistin tukeminen edellyttää pysyvän välimuistilaajennuksen asentamista.

Joissakin koko sivun välimuistilaajennuksissa on pysyvä välimuistilaajennus (esimerkiksi W3 Total Cache), mutta toiset eivät, ja meidän on asennettava se erikseen.

Se riippuu alustamme arkkitehtuurista, käytämmekö tiedostoja, Memcachedia tai muuta mekanismia välimuistitiedon tallentamiseen, mutta meidän tulisi hyödyntää tätä hämmästyttävää ominaisuutta.

Voisi kysyä: 'Jos tämä on niin hieno ominaisuus, miksi WordPress ei ota sitä käyttöön oletuksena?'

Tärkein syy on, että alustamme arkkitehtuurista riippuen jotkut välimuistitekniikat toimivat ja toiset eivät.

Jos isännöimme sivustoamme esimerkiksi hajautetulla palvelimellamme, meidän tulisi käyttää ulkoista välimuistijärjestelmää (kuten a Memcached palvelin), mutta jos verkkosivustomme sijaitsee yhdellä palvelimella, voimme säästää rahaa yksinkertaisesti käyttämällä välimuistiin tiedostojärjestelmää.

Yksi asia, joka meidän on otettava huomioon, on välimuistin vanhentuminen. Tämä on yleisin kuoppa työskentelystä jatkuvan välimuistin kanssa.

Jos emme käsittele ongelmaa oikein, käyttäjät valittavat, etteivät he näe tekemiäsi muutoksia tai että muutosten soveltaminen kesti liian kauan.

Joskus aiomme löytää kompromisseja suorituskyvyn ja dynaamisuuden välillä, mutta jopa näiden esteiden takia jatkuva välimuisti on jotain, jota käytännössä jokaisen WordPress-asennuksen tulisi hyödyntää.

AJAXing nopein tapa

Jos joudumme kommunikoimaan AJAX: n kautta verkkosivustomme, WordPressin kanssa tarjoaa jonkin verran abstraktiota palvelimen puolella olevan pyynnön käsittelyn aikana.

Vaikka näitä tekniikoita voidaan käyttää ohjelmoimalla taustatyökaluja tai lomakkeiden lähetyksiä käyttöliittymästä, niitä tulisi välttää, jos se ei ole ehdottoman välttämätöntä.

Syynä tähän on, että näiden mekanismien käyttämiseksi meidän on tehtävä postituspyyntö johonkin tiedostoon, joka sijaitsee wp-admin kansio. Suurin osa (ellei kaikki) WordPressin koko sivun välimuistilaajennuksista ei välimuistiviestipyyntöjä eikä järjestelmänvalvojan tiedostoihin soitettuja puheluja.

Esimerkiksi, jos lataamme dynaamisesti lisää viestejä, kun käyttäjä vierittää kotisivua, olisi parempi soittaa suoraan jollekin muulle käyttöliittymäsivulle, mikä saa välimuistiin tallentamisen edut.

Voimme sitten jäsentää tulokset selaimen JavaScriptin kautta.

Kyllä, lähetämme enemmän tietoja kuin tarvitsemme, mutta voitamme prosessointinopeuden ja vasteajan suhteen.

Tuhoa käsitys, että WordPress on vain hidas

Nämä ovat vain muutamia neuvoja, jotka kehittäjien tulisi ottaa huomioon koodaamalla WordPress .

Joskus unohdamme, että laajennuksemme tai teemme saattaa joutua elämään yhdessä muiden laajennusten kanssa tai että sivustoamme voi palvella hosting-yritys, joka palvelee satoja tai tuhansia muita sivustoja, joilla on yhteinen tietokanta.

Keskitymme vain siihen, kuinka laajennuksen tulisi toimia, eikä siihen, miten se käsittelee kyseistä toiminnallisuutta miten se tehdään tehokkaasti .

Edellä esitetyn perusteella on selvää, että WordPressin heikon suorituskyvyn perimmäiset syyt ovat huono ja tehoton koodi. WordPress tarjoaa kuitenkin kaikki tarvittavat toiminnot eri sovellusliittymiensä kautta, jotka voivat auttaa meitä rakentaa paljon tehokkaampia laajennuksia ja teemoja vaarantamatta koko alustan nopeutta.