I dag bruker WordPress 33% av Internett . Det er enkelt å bruke, veldig populært, og du skal ikke noe sted når som helst snart.

Men Wordpress kan være tregt. Så hvordan optimaliserer du det?

Det er mange artikler om hvordan du optimaliserer WordPress. Faktisk gir WordPress selv en robust guide av hvordan du kan optimalisere.

I de fleste tilfeller dekker disse artiklene og veiledningene ganske grunnleggende og likevel nyttige konsepter. Slik er bruken av hurtigbuffer-plugins, integrering med innholdsleveringsnettverk (CDN) og minimering av forespørsler. Selv om disse tipsene er svært effektive og til og med nødvendige, tar de ikke opp det underliggende problemet; De fleste trege Wordpress-nettstedene er resultatet av dårlig eller ineffektiv koding.

Wordpress kan være tregt, men det trenger ikke å være. kvitring

Derfor er denne artikkelen primært ment å gi utviklere og Wordpress utviklerbedrifter noen retningslinjer som kan hjelpe deg med å løse de underliggende årsakene til mange WordPress-ytelsesproblemer.

WordPress tilbyr mange ytelsesorienterte funksjoner som ofte blir oversett av utviklere. Kode som ikke lar deg dra nytte av disse funksjonene, kan redusere de enkleste oppgavene, for eksempel å skaffe jobber. Denne artikkelen beskriver fire mulige løsninger som adresserer noen av de underliggende problemene bak WordPress 'langsomme ytelse.

Få jobber

WordPress tilbyr muligheten til å søke etter alle typer posisjoner i databasen. Det er tre grunnleggende måter å gjøre det på:

• Ved hjelp av funksjonen 'query_posts ()': Dette er en veldig grei tilnærming, men problemet er at det overstyrer spørringen rektor som kan forårsake ulempe. For eksempel kan dette være et problem hvis vi på et eller annet tidspunkt etter å ha fått innlegg (for eksempel i 'footer.php') vil bestemme hvilken type side vi har å gjøre med. Faktisk har den offisielle dokumentasjonen et anbefalt notat mot å bruke denne funksjonen, da du må ringe en tilleggsfunksjon for å gjenopprette den opprinnelige spørringen. Hvis du erstatter hovedspørringen, vil det også ha en negativ innvirkning på sidens lastetid.

• Ved hjelp av 'get_posts ()' - funksjonen: Dette fungerer nesten som 'query_posts ()', men det endrer ikke hovedsøket. På den annen side utfører ‘get_posts ()’ som standard spørringen til ‘suppress_files’, parameter satt til ‘true’. Dette kan føre til inkonsekvenser, spesielt hvis vi bruker spørrerelaterte filtre i koden vår, da innlegg som du ikke forventer på en side kan returneres av denne funksjonen.

• Ved hjelp av klassen ‘WP_query’: Etter min mening er dette den beste måten å hente innleggene fra databasen. Det endrer ikke hovedspørringen og kjøres i sin standardform, akkurat som alle andre WordPress-spørsmål.

Men uansett hvilken metode vi bruker for å samhandle med databasen, er det andre ting å vurdere.

Begrensning av spørringen

Vi må alltid spesifisere hvor mange innlegg forespørselen vår skal ha.

For å gjøre dette bruker vi parameteren 'innlegg per side'.

WordPress lar oss indikere -1 som en mulig verdi for den parameteren, i så fall vil systemet prøve å hente alle meldinger som oppfyller de definerte vilkårene.

Dette er ikke god praksis, selv om vi er sikre på at vi bare får få resultater som svar.

For en kan det sjelden være sant å bare få resultater igjen. Og selv om vi kan sette en grense, vil det kreve at databasemotoren analyserer hele databasen for treff.

I motsetning til dette, begrenser resultatene ofte databasemotoren til bare å analysere dataene delvis, noe som betyr mindre behandlingstid og raskere respons.

En annen ting som WordPress gjør som standard er at det kan påvirke ytelsen negativt, ettersom den prøver å ta med klissete innlegg og beregne hvor mange rader som er i spørringen.

Imidlertid trenger vi egentlig ikke den informasjonen veldig ofte. Tillegget av disse to parametrene er å deaktivere disse funksjonene og øke hastigheten på spørringen:

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

Ekskluderer innlegg fra spørring

Noen ganger ønsker vi å ekskludere visse innlegg fra spørringen. WordPress tilbyr en fin grei måte å gjøre dette på: med parameteren 'post__no_en'. For eksempel:

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

Men selv om dette er ganske enkelt, er det ikke optimalt fordi det genererer et underspørring internt. Spesielt i store installasjoner kan dette føre til langsom respons. Det er raskere å tillate prosessering utført av PHP-tolk med noen få enkle modifikasjoner:

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

Hva gjorde jeg her

I utgangspunktet fjernet jeg noen jobber på databasemotoren og la den være på plass for PHP-motoren som gjør de samme tingene, men i minnet, som er mye raskere.

Hvordan?

Først har jeg fjernet 'post__no_en' parameteren fra spørringen.

Siden spørringen kan gi oss noen innlegg som vi ikke ønsker som et resultat, har jeg økt parameteren “posts_per_page. På den måten kan jeg sikre at selv om jeg hadde noen uønskede innlegg i svaret mitt, vil jeg gjerne ha kl. minst '$ posts_per_page ønsket' satt der.

Så når jeg ser etter innleggene og bare behandler de som ikke er innenfor '$ posts_para_exclude' array. '

Unngå kompleks parametrisering

Alle disse spørringsmetoder tilby et bredt spekter av muligheter for å oppnå stillinger: etter kategorier, etter metataster eller verdier, etter dato, etter forfatter osv.

Fleksibilitet er en veldig kraftig funksjon, så den bør brukes med forsiktighet, da det kan føre til parameterisering av komplekse tabellforbindelser og kostbare databaser.

I neste avsnitt vil jeg elegant skissere hvordan du kan oppnå lignende funksjonalitet uten å kompromittere ytelsen.

Få mest mulig ut av Wordpress-alternativene.

Alternativer WordPress WordPress API gi et antall verktøy for å enkelt laste inn eller lagre data. De er nyttige for håndtering av små biter, siden andre mekanismer som WordPress tilbyr (for eksempel innlegg eller taksonomier) er for kompliserte.

Hvis vi for eksempel vil lagre en autentiseringsnøkkel eller bakgrunnsfargen på nettstedet vårt i overskriften, er alternativene det vi leter etter.

WordPress gir oss ikke bare funksjonene for administrasjonen, men lar oss også gjøre det på den mest effektive måten.

Noen av alternativene lastes til og med direkte når systemet starter og gir dermed raskere tilgang (når vi oppretter et nytt alternativ, må vi vurdere om vi vil ha autoload eller ikke).

Tenk for eksempel på et nettsted der vi har en spesifisert karusell som viser nyheter på baksiden. Vårt første instinkt ville være å bruke et hovedmål som følger:

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

Som du kan se, er denne metoden veldig enkel, men den er ikke optimal. Det vil bli spurt til databasen for å prøve å finne et innlegg med en bestemt metanøkkel. Vi kan bruke et alternativ for å få et lignende resultat:

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

Funksjonaliteten varierer litt fra eksempel til eksempel.

I den første delen av koden vil vi alltid få de siste nyhetene, når det gjelder publiseringsdatoen for innlegget.

For det andre, hver gang et nytt innlegg blir etablert som en nyhet, vil det bli overskrevet på forrige nyhet.

Men siden vi sannsynligvis vil ha en nyhetsblits om gangen, vil dette ikke være et problem.

Og til slutt har vi endret et tungt databasespørsmål (ved hjelp av 'WP_QUERY' med metataster) til et enkelt og greit spørsmål ('get_post ()' -anropet), som er en bedre og mer effektiv tilnærming.

Vi kan også gjøre en liten endring og bruke transienter i stedet for alternativer.

Transienter fungerer på lignende måte, men tillater oss å spesifisere en utløpstid.

For eksempel når det gjelder nyhetene som er perfekt tilpasset, fordi vi ikke vil ha et gammelt innlegg som en nyhet, og hvis vi overlater oppgaven med å endre eller fjerne nyhetene til administratoren, kan [han] glemme å gjøre det . Så, med to enkle endringer, kan vi legge til en utløpsdato:

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

Aktiver en vedvarende hurtigbuffer

WordPress har naturlig en cachemekanisme gjenstand .

Alternativer, for eksempel, er hurtigbufret ved hjelp av den mekanismen.

Men som standard er ikke hurtigbufferen vedvarende, noe som betyr at den bare lever i løpet av en enkelt forespørsel. All data er hurtigbufret for raskere tilgang, men er bare tilgjengelig under forespørselen.

Vedvarende cache-støtte krever installasjon av et vedvarende cache-plugin.

Noen helsides hurtigbuffer-plugins kommer med et vedvarende hurtigbuffer-plugin inkludert (for eksempel W3 Total Cache), men andre ikke, og vi må installere det separat.

Det vil avhenge av arkitekturen til plattformen vår hvis vi skal bruke filer som Memcache eller annen mekanisme for å lagre data i cache, vi må dra nytte av denne fantastiske funksjonen.

Du kan spørre deg selv: 'Hvis dette er en flott WordPress-funksjon, hvorfor er den ikke aktivert som standard?'

Hovedårsaken er at avhengig av arkitekturen til plattformen vår, vil noen caching-teknikker fungere og andre ikke.

Hvis vi for eksempel vil være vert for en distribuert server på nettstedet vårt, må vi bruke et eksternt cache-system (for eksempel en Memcached server ), men hvis nettstedet vårt ligger på en enkelt server, kan vi spare penger og bare bruke cache-filsystemet.

En ting vi må ta i betraktning er utløpet av hurtigbufferen. Dette er den vanligste fallgruven for å jobbe med vedvarende hurtigbuffer.

Hvis vi ikke adresserer dette ordentlig, vil brukerne våre klage over at de ikke vil kunne se endringene de har gjort, eller at endringene deres tok for lang tid å gjelde.

Noen ganger kommer vi til å finne oss selv i å balansere ytelse og dynamikk, men selv med disse hindringene er vedvarende hurtigbufring noe som nesten alle WordPress-installasjoner bør dra nytte av.

AJAXing The Fastest Way

Hvis vi trenger å kommunisere via AJAX med nettstedet vårt, WordPress tilbyr litt abstraksjon på tidspunktet for behandling av forespørselen på serveren.

Selv om disse teknikkene kan brukes med programmering av backend-verktøy eller front-end skjemainnleveringer, bør de unngås hvis de ikke er strengt nødvendige.

Årsaken til dette er at for å kunne bruke disse mekanismene, er vi forpliktet til å sende en forespørsel om innlegg til en fil som ligger i mappen “wp-admin”. De fleste (hvis ikke alle) Wordpress-plugins har verken hurtigbuffer eller postforespørselbuffer eller filbehandleranrop.

For eksempel, hvis vi ønsker mer dynamiske innlegg når brukeren navigerer til hjemmesiden vår, ville det være bedre å ringe direkte til en annen front-end-side, som vil få fordelene ved å bli bufret.

Da kunne vi analysere resultatene via JavaScript i nettleseren.

Ja, vi sender mer data enn vi trenger, men vi vinner når det gjelder behandlingshastighet og responstid.

Ødelegge forestillingen om at WordPress er treg

Dette er bare noen få tips som utviklere bør huske på når de koder for WordPress .

Noen ganger glemmer vi at vårt plugin eller tema er nødvendig for å leve sammen med andre plugins, eller at nettstedet vårt kan betjenes av et vertsfirma som serverer hundrevis eller tusenvis av andre nettsteder med en felles database.

Vi fokuserte bare på hvordan programtillegget skal fungere og ikke hvordan det håndterer funksjonaliteten, eller hvordan du gjør det i en effektiv .

Av det jeg diskuterte tidligere, er det klart at årsakene til dårlig WordPress-ytelse er dårlig og ineffektiv kode. WordPress tilbyr imidlertid alle nødvendige funksjoner gjennom de forskjellige API-ene som kan hjelpe oss med å bygge mange i tillegg til utviklingsprogrammer og temaer uten å gå på kompromiss med den totale hastigheten på plattformen.