Täna on WordPressi volitused üle 30% Internetist . Seda on lihtne kasutada, uskumatult populaarne ja see ei lähe niipea kuhugi.

Kuid WordPress võib olla aeglane. Kuidas siis seda optimeerida?

WordPressi häälestamise ja optimeerimise kohta on palju artikleid. Tegelikult pakub WordPress ise a kindel juhend WordPressi optimeerimise kohta.

Enamasti hõlmavad need artiklid ja õpetused üsna lihtsaid, kuid kasulikke mõisteid, nagu vahemälu pistikprogrammide kasutamine, integreerimine sisuteenuse edastusvõrkudega (CDN) ja taotluste minimeerimine. Kuigi need näpunäited on väga tõhusad ja isegi vajalikud, ei lahenda need lõpuks põhiprobleemi: enamik aeglasi WordPressi saite on vale või ebaefektiivse koodi tulemus.

WordPress võib olla aeglane, kuid see ei pea olema. Piiksuma

Seetõttu on see artikkel suunatud peamiselt arendajatele ja WordPressi arendusettevõtted mõnede juhistega, mis aitavad neil lahendada paljude WordPressi jõudlusprobleemide põhjuseid.

WordPress pakub palju jõudlusele suunatud funktsioone, mida arendajad sageli tähelepanuta jätavad. Kood, mis neid funktsioone ei kasuta, võib aeglustada lihtsamaid ülesandeid, näiteks postituste toomist. Selles artiklis kirjeldatakse nelja võimalikku lahendust, mis käsitlevad mõnda WordPressi aeglase jõudluse taga olevat põhiprobleemi.

Postituste toomine

WordPress pakub võimalust tuua andmebaasist mis tahes liiki postitusi. Selleks on kolm põhilist viisi:

• Kasutades query_posts() funktsioon: See on väga otsene lähenemine, kuid probleem on selles, et see alistab peamise päring , mis võib põhjustada ebamugavusi. Näiteks võib see olla probleem, kui me tahame mingil hetkel pärast postituste hankimist (näiteks footer.php) välja selgitada, millist lehte me käsitleme. Tegelikult on ametlikus dokumentatsioonis märkus, milles soovitatakse seda funktsiooni mitte kasutada, kuna algse päringu taastamiseks peate kutsuma lisafunktsiooni. Pealegi mõjutab põhipäringu asendamine lehe laadimisaega negatiivselt.

• Kasutades get_posts() funktsioon: See töötab peaaegu nagu query_posts(), kuid see ei muuda peamist päringut. Teiselt poolt get_posts() vaikimisi täidab päringu suppress_filters -ga parameeter on true. See võib põhjustada vasturääkivusi, eriti kui kasutame koodis päringutega seotud filtreid, kuna see funktsioon võib tagastada postitused, mida te lehel ei oota.

  
  
  

• Kasutades WP_Query klass: Minu arvates on see parim viis andmebaasist postituste saamiseks. See ei muuda põhipäringut ja see käivitatakse tavapärasel viisil, nagu iga teine ​​WordPressi päring.

Kuid ükskõik millist meetodit me andmebaasiga suhtlemiseks kasutame, peame arvestama ka muude asjadega.

Päringu piiramine

Peaksime alati määrama, mitu postitust meie päring peab tooma.

Selle saavutamiseks kasutame posts_per_page parameeter.

WordPress võimaldab meil selle parameetri võimaliku väärtusena näidata -1, sel juhul üritab süsteem tuua kõik määratletud tingimustele vastavad postitused.

See pole hea tava, isegi kui oleme kindlad, et saame vastusena tagasi vaid mõned tulemused.

mille eest vastutab finantsjuht

Esiteks võime harva olla kindlad vaid mõne tulemuse tagasisaamise suhtes. Ja isegi kui suudame, nõuab piiranguteta määramine andmebaasimootorilt kogu andmebaasi vastete otsimist.

Seevastu tulemuste piiramine võimaldab andmebaasimootoril andmeid skaneerida vaid osaliselt, mis tähendab vähem töötlemisaega ja kiiremat reageerimist.

Teine asi, mida WordPress vaikimisi teeb, mis võib jõudlust negatiivselt mõjutada, on see, et ta püüab tuua kleepuvaid postitusi ja arvutada, mitu rida päringust leiti.

Sageli pole meil seda teavet siiski vaja. Nende kahe parameetri lisamine keelab need funktsioonid ja kiirendab meie päringut:

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

Postituste väljajätmine päringust

Mõnikord soovime päringust teatud postitused välja jätta. WordPress pakub selle saavutamiseks üsna otsest viisi: post__not_in abil parameeter. Näiteks:

$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 ] }

Kuigi see on üsna lihtne, pole see optimaalne, sest sisemiselt genereerib see alampäringu. Eriti suurtes installatsioonides võib see reageerida aeglaselt. Kiirem on lubada, et töötlemine toimub PHP tõlgi abil mõningate lihtsate muudatustega:

$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 ] } }

Mida ma seal tegin?

Põhimõtteliselt võtsin andmebaasimootorist osa tööd maha ja jätsin selle hoopis PHP-mootorile, mis teeb sama, kuid mällu, mis on palju kiirem.

Kuidas?

Kõigepealt eemaldasin post__not_in parameeter päringust.

Kuna päring võib tuua meile mõned postitused, mida me selle tulemusena ei soovi, suurendasin posts_per_page parameeter. Nii tagan, et isegi kui mul oleks vastuses olnud soovimatuid postitusi, oleks mul vähemalt $posts_per_page soovitud postitused seal.

Kui ma postitusi üle vaatan, töötlen ainult neid, mis pole $posts_to_exclude sees massiiv.

Kompleksse parameetrite vältimine

Kõik need päringumeetodid pakuvad postituste toomiseks väga erinevaid võimalusi: kategooriate, metavõtmete või väärtuste, kuupäeva, autori jne järgi.

Ja kuigi see paindlikkus on võimas funktsioon, tuleks seda kasutada ettevaatusega, sest see parameetrite määramine võib muutuda keerukateks tabeliliideteks ja kulukateks andmebaasitoiminguteks.

Järgmises osas tutvustame elegantset viisi, kuidas ikkagi saavutada sarnane funktsionaalsus jõudlust kahjustamata.

WordPressi suvanditest maksimumi võtmine

The WordPressi suvandite API pakub rida tööriistu andmete hõlpsaks laadimiseks või salvestamiseks. See on kasulik väikeste teabeosade käsitsemiseks, mille jaoks muud WordPressi pakutavad mehhanismid (nt postitused või taksonoomiad) on liiga keerulised.

Näiteks kui soovime salvestada autentimisvõtme või oma saidi päise taustavärvi, on valikud need, mida otsime.

WordPress annab meile mitte ainult funktsioonid nende käsitsemiseks, vaid võimaldab seda teha ka kõige tõhusamal viisil.

Mõned valikud laaditakse isegi otse, kui süsteem käivitub , pakkudes seeläbi meile kiiremat juurdepääsu (uue võimaluse loomisel peame kaaluma, kas soovime selle automaatse avaldamise või mitte).

Mõelgem näiteks saidile, kus meil on karussell, kus kuvatakse taustauuringus täpsustatud uudiseid. Meie esimene sisetunne oleks kasutada selleks meta võtit järgmiselt:

// 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;

Nagu näete, on see lähenemine väga lihtne, kuid see pole optimaalne. See viib läbi andmebaasipäringu, püüdes leida postitust konkreetse metavõtmega. Sarnase tulemuse saavutamiseks võiksime kasutada võimalust:

// 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;

Funktsionaalsus varieerub veidi erinevates näidetes.

Esimeses koodis on postituse avaldamise kuupäeva osas alati uusimad uudised.

Teises kirjutab iga kord, kui uus postitus on seatud uudiseks, eelmised uudised üle.

Kuid kuna me tahame ilmselt ühte uudiste postitust korraga, ei tohiks see probleem olla.

Ja lõpuks muutsime raske andmebaasipäringu (kasutades WP_Query koos metavõtmetega) lihtsaks ja otseseks päringuks (kutsudes get_post()), mis on parem ja toimivam lähenemine.

Võiksime teha ka väikese muudatuse ja kasutada valikute asemel transiente.

Transiendid töötavad sarnaselt, kuid võimaldavad meil määrata aegumisaega.

Näiteks värskete uudiste jaoks sobib see nagu kinnas, sest me ei soovi vana postitust kui uudiseid ja kui jätame selle uudiste muutmise või kõrvaldamise ülesandeks administraatorile, võiks ta unustada seda teha seda. Nii lisame kahe lihtsa muudatusega aegumiskuupäeva:

// 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;

Lubage püsiv vahemällu salvestamine

WordPressil on algupärane objekti vahemälu mehhanism .

Näiteks valikud salvestatakse selle mehhanismi abil vahemällu.

Kuid vaikimisi pole see vahemällu salvestamine püsiv, see tähendab, et see elab ainult ühe taotluse vältel. Kõik andmed salvestatakse mällu vahemällu, et kiiremini juurde pääseda, kuid need on saadaval ainult selle taotluse ajal.

Püsiva vahemälu toetamine nõuab püsiva vahemälu pistikprogrammi installimist.

Mõne täislehekülje vahemälu pistikprogrammiga on kaasas püsiv vahemälu pistikprogramm (näiteks W3 kogu vahemälu), kuid teistel seda pole ja peame selle eraldi installima.

See sõltub meie platvormi arhitektuurist, kas me kasutame vahemällu salvestatud andmeid failide, Memcachedi või mõne muu mehhanismi abil, kuid me peaksime seda hämmastavat funktsiooni ära kasutama.

Võib küsida: 'Kui see on nii suurepärane funktsioon, siis miks WordPress seda vaikimisi ei võimalda?'

Peamine põhjus on see, et sõltuvalt meie platvormi arhitektuurist töötavad mõned vahemälutehnikad ja teised mitte.

Kui me hostime oma saiti näiteks hajutatud serveris, peaksime kasutama välist vahemälusüsteemi (näiteks a Memcached server), kuid kui meie veebisait asub ühes serveris, võiksime säästa natuke raha, kui lihtsalt vahemällu salvestada failisüsteemi.

Üks asi, mida peame arvestama, on vahemälu aegumine. See on püsiva vahemällu töötamise kõige tavalisem lõk.

Kui me ei lahenda seda probleemi õigesti, kaebavad meie kasutajad, et nad ei näe tehtud muudatusi või et nende muudatuste rakendamine võttis liiga kaua aega.

Mõnikord leiame end kompromissidest jõudluse ja dünaamika vahel, kuid isegi nende takistuste korral peaks püsiv vahemällu salvestamine olema midagi, mida praktiliselt iga WordPressi install peaks ära kasutama.

AJAXing kiireim viis

Kui peame AJAXi kaudu oma veebisaidiga WordPressiga suhtlema pakub mõningast abstraktsiooni serveri poolel päringu töötlemise ajal.

Kuigi neid tehnikaid saab kasutada taustaprogrammide programmeerimisel või esipaneelilt esildiste vormistamisel, tuleks neid vältida, kui see pole tingimata vajalik.

Selle põhjuseks on see, et nende mehhanismide kasutamiseks oleme kohustatud esitama postitustaotluse mõnele failile, mis asub wp-admin kausta. Enamik (kui mitte kõiki) WordPressi täislehelisi vahemälu pistikprogramme ei vahemälu postitaotlusi ega administraatorifailidele helistamisi.

Näiteks kui laadime dünaamiliselt rohkem postitusi, kui kasutaja meie kodulehte kerib, oleks parem helistada otse mõnele muule esilehele, mis saab vahemällu salvestamise eeliseid.

Seejärel saaksime tulemused brauseris JavaScripti kaudu sõeluda.

Jah, me saadame rohkem andmeid kui vaja, kuid töötlemiskiiruse ja reageerimisaja osas võidame.

Hävitage arusaam, et WordPress on lihtsalt aeglane

Need on vaid mõned nõuanded, mida arendajad peaksid kodeerimisel arvestama WordPress .

Mõnikord unustame, et meie pistikprogramm või teema võib vajada teiste pistikprogrammidega koos elamist või et meie saiti võib teenindada hostimisettevõte, mis teenindab sadu või tuhandeid muid ühise andmebaasiga saite.

Keskendume lihtsalt sellele, kuidas pistikprogramm peaks toimima, mitte sellele, kuidas see selle funktsionaalsusega tegeleb või kuidas seda tõhusalt teha .

Eeltoodust on selge, et WordPressi halva jõudluse algpõhjused on halb ja ebaefektiivne kood. Kuid WordPress pakub oma erinevate API-de kaudu kõiki vajalikke funktsioone, mis võivad meid aidata ehitada palju toimivamaid pistikprogramme ja teemasid kahjustamata kogu platvormi kiirust.