WP_Queryで全件取得して大丈夫？posts_per_page=-1が重くなる理由と対策

posts_per_page=-1はページ分割せず全件取得する

posts_per_pageは取得件数を指定する引数で、5なら最大5件です。-1を指定するとnopagingがtrueになり、条件に合う投稿をページ分割せず取得します。

今の投稿数で動くことと、運用後も負荷を抑えられることは別です。公開ページで毎回全件を取ると、投稿数が増えた後に問題が表れます。

全件取得が重くなりやすい理由

取得件数以外も含めて負荷を見直したい場合には、WP_Queryを高速化する7つの方法もご覧ください。件数や総ページ数が合わない場合は、速度対策を施す前に表示件数が合わない時の確認事項を確認してください。

全件取得では、データベースから取る量、PHPが保持・処理する量、生成するHTMLが同時に増えます。

さらに、カスタムフィールドやタクソノミー条件を組み合わせている場合は、条件そのものも複雑になりやすくなります。meta_query や tax_query が悪いわけではありませんが、全件取得と組み合わさると、確認すべき範囲が一気に広がります。

公開ページで避けたい全件取得の書き方

次は、公開ページで全記事を一度に取得する例です。少数の検証データでは問題が見えにくい点に注意してください。

$args = [   'post_type'      => 'post',   'post_status'    => 'publish',   'posts_per_page' => -1,]; $all_posts = new WP_Query( $args ); if ( $all_posts->have_posts() ) {   echo '<ul>';    while ( $all_posts->have_posts() ) {      $all_posts->the_post();       printf(         '<li><a href="%1$s">%2$s</a></li>',         esc_url( get_permalink() ),         esc_html( get_the_title() )      );   }    echo '</ul>';} else {   echo '<p>表示できる投稿はありませんでした。</p>';} wp_reset_postdata();

この例が危険なのは、投稿数に上限を設けず、アクセスのたびに全件を取得して全件分のHTMLを作るためです。実際のテンプレートでは、画像、抜粋、カスタムフィールド、タームなどの処理も全件分繰り返します。件数だけでなく、ループ内の追加取得や出力量も確認します。

posts_per_page=-1を検討できる場面

posts_per_page => -1は常に禁止ではありません。対象件数に予測可能な上限があるか、表示か処理か、実行頻度を管理できるかで判断します。

「何件までなら大丈夫」という共通の上限はありません。投稿の大きさ、ループ内の処理、アクセス数、サーバー環境によって負荷が変わるためです。対象が少なく上限も予測できる設定用データ、一時的な管理・検証処理などでは使用を検討できます。逆に、投稿、商品、イベント、会員向けコンテンツのように増え続けるデータでは慎重に扱います。

公開一覧なら、最新10件、カテゴリごとに20件、ページ分割など、読者が必要な範囲へ絞れないかを先に考えます。

全件取得の代わりに選びたい書き方

公開ページでは必要な件数を明示し、残りはページ分割や「もっと見る」で辿れるようにします。次は最新記事を10件だけ取得する例です。

$args = [   'post_type'           => 'post',   'post_status'         => 'publish',   'posts_per_page'      => 10,   'ignore_sticky_posts' => true,]; $latest_posts = new WP_Query( $args ); if ( $latest_posts->have_posts() ) {   echo '<ul>';    while ( $latest_posts->have_posts() ) {      $latest_posts->the_post();       printf(         '<li><a href="%1$s">%2$s</a></li>',         esc_url( get_permalink() ),         esc_html( get_the_title() )      );   }    echo '</ul>';} else {   echo '<p>表示できる投稿はありませんでした。</p>';} wp_reset_postdata();

ignore_sticky_postsは、固定表示投稿の影響を受けたくない独自一覧で検討します。

ページ分割が必要な一覧では、paged と組み合わせて「1ページあたり何件表示するか」を決めます。全件を1ページに詰め込むのではなく、ページごとに分けて取得する考え方です。

ページ送りが必要なら、posts_per_pageへ1ページの件数を指定してください。

$paged = max( 1, get_query_var( 'paged' ) ); $args = [   'post_type'      => 'post',   'post_status'    => 'publish',   'posts_per_page' => 10,   'paged'          => $paged,]; $paged_posts = new WP_Query( $args );

posts_per_pageで1ページの件数を決め、pagedで現在のページ番号を渡します。全件取得後に分けるのではなく、必要なページ分だけ取得します。

IDだけ必要ならfieldsを検討する

後続処理で投稿IDだけを使う場合は、fields => ‘ids’で投稿IDの配列を取得できます。

$args = [   'post_type'      => 'post',   'post_status'    => 'publish',   'posts_per_page' => 100,   'fields'         => 'ids',   'no_found_rows'  => true,]; $id_query = new WP_Query( $args );$post_ids = $id_query->posts;

取得したIDは$id_query->postsに入ります。no_found_rows => trueは、ページ数や総件数が不要な処理で使います。

ただし、fields => ‘ids’やno_found_rows => trueを付ければ、無制限に取得してよいわけではありません。IDだけであっても、対象が数万件になれば処理量は増えます。大量データを扱うなら、一定件数ごとに分け、処理時間とメモリ使用量を計測してください。

全件取得する前に確認したい順番

表示目的と処理目的を分けて、次の順に判断します。

最後は推測ではなく計測します。クエリ時間とメモリだけでなく、ループ内で投稿ごとに追加取得が起きていないか、生成されるHTML量や表示時間が増えていないかも確認してください。

公式資料で確認したいポイント

-1、no_found_rows、fieldsはWP_Queryの公式資料で確認できます。通常のループでthe_post()を使ったら、後続のテンプレートタグを戻すためwp_reset_postdata()も必要です。