Cum să optimizezi un site WordPress pentru milioane de articole

1. Setează interogarea înainte ca WP_Query să fie executată

Acesta pare a fi cel mai important lucru de reținut atunci când încerci să reduci la minimum interogările la baza de date, deoarece singura oportunitate de a modifica interogarea este, bineînțeles, înainte ca aceasta să fie executată în baza de date SQL.

Interogări normale
Pentru o interogare normală, WordPress folosește funcția wp(), care la rândul ei apelează $wp->main( $query_vars ). Variabilele "is_" din etichetele condiționale sunt setate înainte de a fi transmise către WP_Query->get_posts(), care le convertește într-o interogare MySQL și le stochează în obiectul $wp_query. Este posibil să filtrezi interogarea înainte ca aceasta să fie efectiv executată în baza de date SQL.

Acțiunea pre_get_posts se atașează acestui proces, permițându-ți să modifici interogarea înainte ca aceasta să fie transmisă către WP_Query->get_posts().

De exemplu, dacă vrei să filtrezi interogarea pentru postările din categoria "featured", ai folosi add_action( 'pre_get_posts', 'your_function_name' ); și ai include eticheta condițională in_category în interiorul funcției your_function_name.

function your_function_name( $query ) {
    if ( $query->in_category( 'featured' ) && $query->is_main_query() ) {
        // Înlocuiește 123 cu ID-ul categoriei featured.
        $query->set( 'cat', '123' );
    }
}
add_action( 'pre_get_posts', 'your_function_name' );

Vezi Plugin API/Action Reference/pre get posts « WordPress Codex

Solicitări de pagină
În cazul șabloanelor de pagină, cum ar fi pagina de arhivă pentru categoria "featured", etichetele condiționale nu vor funcționa din filtrul pre_get_posts. De exemplu, nu poți folosi is_category pentru a verifica pagina de arhivă deoarece WP_Query nu a fost încă executat.

În schimb, ar trebui să modifici interogarea principală pentru solicitările de pagină cu un new WP_Query, care ar arăta cam așa: $query = new WP_Query( 'cat=123' );. Aceasta execută interogarea cu argumentul potrivit setat de la început.

Vezi Class Reference/WP Query « WordPress Codex

2. Salvarea în baza de date

Poți folosi filtrul wp_insert_post_data asigurându-te că doar $data relevantă pentru tipul tău personalizat de post este returnată către wp_insert_post. Asigură-te că incluzi o declarație condițională pentru a verifica tipul tău personalizat de post.
Plugin API/Filter Reference/wp insert post data « WordPress Codex

Acest hook este apelat de funcția wp_insert_post, care este apelată de wp_update_post atunci când actualizezi tipul tău personalizat de post, de obicei prin salvarea unui draft sau publicarea postului.

Totuși, va trebui să faci benchmarking singur, deoarece nu pot afirma personal semnificația optimizării prin reducerea datelor care sunt actualizate în baza de date.

3. Tipurile personalizate de post afectează performanța?

Din experiența mea, tipurile personalizate de post sunt un instrument puternic pentru gestionarea conținutului. Nu cunosc alt mod de a gestiona postările în toate modurile pe care le permite într-o manieră care să consume mai puține resurse. Personal, m-aș concentra pe găsirea de modalități de a reduce numărul de interogări efectuate oriunde este posibil.

În trecut, exista o problemă de performanță legată de structura permalink-ului, care făcea ca performanța să scadă atunci când începea cu text în loc de un număr.3 Aceasta a fost problematică în special pentru site-urile care găzduiau un număr mare de pagini, dar a fost rezolvată începând cu versiunea 3.3 a WordPress.

Menționez permalink-urile aici deoarece slug-ul este de obicei prima parte a structurii permalink-ului, care poate sau nu să fi afectat performanța înainte de versiunea 3.3. În afară de aceasta, nu cunosc alte probleme de performanță care să apară din utilizarea tipurilor personalizate de post.

Alte opțiuni de performanță

Transiente
Aceasta nu este o înlocuire pentru menținerea interogărilor la minimum în codul tău, dar poți folosi set_transient pentru a stoca interogările pentru o anumită perioadă, astfel încât să nu fie necesare noi interogări. Iată exemplul folosit în postul lui Dave Clements. De asemenea, reține că el recomandă adăugarea unei acțiuni save_post pentru a șterge transienta ori de câte ori un anumit tip de post este actualizat.

<?php // INTEROGAREA IN THE SPOTLIGHT
if( false === ( $its_query = get_transient( 'its_query' ) ) ) {
    $pttimestamp = time() + get_option('gmt_offset') * 60*60;
    $its_query = new WP_Query( array(
        'post_type' => 'spotlight',
        'posts_per_page' => 1,
            'post__not_in' => $do_not_duplicate,
        'meta_query' => array(
            array(
                'key' => '_hpc_spotlight_end_time',
                'value' => $pttimestamp,
                'compare' => '>'
            )
        )
    ) );
    set_transient( 'its_query', $its_query, 60*60*4 );
}
if( have_posts() ) { // ASCUNDE SECȚIUNEA DACĂ NU EXISTĂ NICIUN FEATURE ITS CURENT ?>
    // BUCLA AICI: NU ESTE IMPORTANTĂ PENTRU EXEMPLU
<?php } ?>

Mai multă optimizare a interogărilor
Thomas Griffin are câteva sfaturi bune în tutorialul său Optimize WordPress Queries. Iată o listă scurtă cu sugestiile sale:

• Setează 'cache_results' => false în interogările unice dacă serverul tău nu utilizează caching persistent, cum ar fi Memcached. Interogările unice sunt descrise ca "interogări care sunt folosite pentru a afișa cantități mici de date. Poate fi vorba doar de afișarea titlurilor postărilor legate de postul curent, sau poate dorești să afișezi un dropdown cu postări pentru a selecta o anumită opțiune."

  Exemplul său: $query = get_posts( array( 'posts_per_page' => 1, 'cache_results' => false ) );

• Setează 'no_found_rows' => true acolo unde nu este necesară paginarea. Aceasta va "ocoli numărarea rezultatelor în MySQL pentru a vedea dacă avem nevoie de paginare sau nu."

  Exemplul său: $query = new WP_Query( array( 'posts_per_page' => 1, 'no_found_rows' => true ) );

• Interoghează doar pentru ID-uri de post dacă acesta este tot ce ai nevoie 'fields' => 'ids' în get_posts. Aceasta ar trebui să reducă semnificativ cantitatea de date returnate, care este destul de mare per post dacă te uiți la Database Description « WordPress Codex.

  Exemplul său: $query = get_posts( array( 'posts_per_page' => 1, 'fields' => 'ids' ) );

În plus față de ultimul sfat, același raționament poate fi aplicat atunci când ai nevoie doar de unul sau câteva câmpuri de post folosind get_post_field.

A avea o înțelegere solidă despre cum funcționează interogarea este esențial. Cu cât poți fi mai specific cu interogările tale, cu atât mai puțină muncă vei cere de la baza ta de date SQL. Aceasta înseamnă că există un număr vast de posibilități pentru gestionarea interogărilor la baza de date. Fii atent cu interogările personalizate în ceea ce privește locul în care rulează (este o pagină de administrare?), folosește sanitizare corespunzătoare în interogările directe și încearcă să utilizezi funcții native WordPress acolo unde îți permite să obții aceeași performanță.