WP_Query og The Loop: ytelse, taksonomier og maler

WP_Query er hjertet i WordPress. Den driver hver sidevisning. Men den er også årsak #1 til trege nettsider.

I 2026, med PHP 8.4, har vi ikke råd til lat kode. Denne guiden på 1500 ord dekker Standard Loop, Avanserte Argumenter og Ytelsesfarer.

#Del 1: Standard vs. Sekundær loop

#1. Hovedloopen (global)

Skjer automatisk.

if ( have_posts() ) :
    while ( have_posts() ) : the_post();
        // Mal
    endwhile;
endif;

#2. Sekundær loop (custom)

Den Gylne Regel: Bruk alltid new WP_Query(). Bruk aldri query_posts().

$args = [
    'post_type'      => 'post',
    'posts_per_page' => 5,
    'no_found_rows'  => true, // KRITISK FOR YTELSE
];
$query = new WP_Query( $args );

#Del 2: Ytelses-drapsmenn (hva du ikke må gjøre)

#1. Posts_per_page => -1

Aldri gjør dette. Dette laster ALT inn i RAM. Sett alltid en grense.

#2. Sql_CALC_FOUND_ROWS (paginering)

Standard teller WP alle rader for paginering. Hvis du ikke trenger paginering: no_found_rows => true.

#3. Kompleks meta_query

Metadata er trege å søke i. Bruk Custom Taxonomies for søkbare data.

#Del 3: Avanserte scenarioer

#Ekskludere nåværende innlegg

$args = [
    'post__not_in' => [ get_the_ID() ],
];

#Del 4: Paginering i custom loops

Paginering brekker ofte i custom loops. Du må sende paged-argumentet manuelt.

$paged = ( get_query_var( 'paged' ) ) ? get_query_var( 'paged' ) : 1;
$args = [
    'paged' => $paged,
];

#Oppsummering

1. Bruk WP_Query.
2. Optimaliser: no_found_rows => true uten paginering.
3. Saner: Unngå posts_per_page => -1.
4. Nullstill: Alltid wp_reset_postdata().

Skriv rene spørringer.

Se vår WordPress-hastighetsoptimalisering.