Webニュースサイトのお客様から、「トップページの表示に時間がかかるため、改善したい」というご相談をいただきました。

WordPressサイトの表示速度が遅くなる原因としては、画像、JavaScript、CSS、外部サービスとの通信、プラグイン、データベースへの問い合わせなど、さまざまな要因が考えられます。
このため、複数の施策を一気に試したけど、結局どの施策がクリティカルだったのかわからず、
「なんとなく早くなった気がする…」
という結果で終了してしまうケースも多いのではないでしょうか？

今回はお客様とご相談の上、一度に複数の施策を行うのではなく、改善施策を一つずつ実施しその効果を検証していくことにしました。

最初に注目したのが、トップページに複数設置されている「カテゴリー別の記事フィード」です。

今回検証したこと

今回は実際のサイトを改修する前に、当社サイト上に検証環境を用意し、WordPressのTransient API（Transient Cache）を利用することで、どの程度の効果が期待できるのかを検証しました。

ニュースサイトやオウンドメディアのトップページでは、次のような構成をよく見かけます。

WordPressでこれを素直に実装する場合、カテゴリーごとにWP_Queryを使って記事を取得することになります。
カテゴリーが5つあれば、ページを表示するたびに5つのサブループが実行されます。

そこで今回は、この処理をTransient Cacheを利用した実装に変更した場合、サーバーの応答時間にどの程度違いが出るかを比較しました。

ちなみに、Transient APIそのものは新しい機能ではなく、WordPressに以前から用意されている仕組みです。

今回のポイントは、新しい技術を導入することではなく、
毎回同じ結果を取得しているWP_Queryを、本当にアクセスのたびに実行する必要があるのか？
という点です。

通常のWP_Queryによる実装

比較用として、当社サイトに5カテゴリーの記事をそれぞれ4件ずつ表示するテストページを作成しました。
各カテゴリーで次のようなWP_Queryを実行します。

 
$query = new WP_Query([
    'post_type'           => 'post',
    'post_status'         => 'publish',
    'posts_per_page'      => 4,
    'category_name'       => $category_slug,
    'orderby'             => 'date',
    'order'               => 'DESC',
    'ignore_sticky_posts' => true,
]);
 

この場合、ページへアクセスするたびに、

 
カテゴリー1 → WP_Query
カテゴリー2 → WP_Query
カテゴリー3 → WP_Query
カテゴリー4 → WP_Query
カテゴリー5 → WP_Query
 

という処理が行われます。

Transient Cacheを利用した実装

もう一つ、表示内容がまったく同じページを用意し、こちらでは生成した記事フィードのHTMLをTransientに保存しました。

概略としては次のような処理です。

 
$transient_key = 'intactis_news_' . $category_slug;

$section_html = get_transient( $transient_key );

if ( false === $section_html ) {

    // WP_Queryで記事を取得
    // HTMLを生成

    set_transient(
        $transient_key,
        $section_html,
        HOUR_IN_SECONDS
    );
}

echo $section_html;
 

今回の検証では、キャッシュの有効期限を1時間に設定しています。

最初のアクセスでは通常通りWP_Queryを実行してHTMLを生成しますが、2回目以降は保存されているHTMLを利用します。
つまりキャッシュが有効な間は、カテゴリーごとのWP_Queryを繰り返し実行する必要がありません。

計測方法と条件

効果計測は、PageSpeed Insightsのスコアではなく、TTFB（Time To First Byte）を比較しました。
TTFBは、ブラウザがWebページをリクエストしてから、サーバーから最初のデータが返ってくるまでの時間です。

理由としては、改善したいのは画像やCSSの読み込み速度ではなく、WordPressがページを生成するサーバーサイドの処理だからです。
そのため、今回のような比較ではTTFBの方が変化を確認しやすいと考えました。

確認方法は、Chrome DevToolsのNetworkパネルから対象ページのDocumentリクエストを選択し、Timingに表示される「サーバーの応答を待機しています」の時間を計測しました。

計測条件は以下の通りです。

• 同一サーバー、同一WordPress環境
• 表示するカテゴリー・記事件数・HTMLは同一
• WordPressからログアウトした状態
• Chrome DevToolsのブラウザキャッシュを無効化
• サーバー側のページキャッシュはOFF
• Transient版はキャッシュ生成後の状態で計測
• それぞれ5回計測

計測結果

結果は次のようになりました。

計測ごとに少しばらつきはありますので、今回は一時的な変動の影響を受けにくい中央値で比較します。

キャッシュなしでは813.02ms、Transient Cacheありでは438.43msという結果でした。

今回のテスト環境では、TTFBが約 374.6ms短縮され、約46%改善する結果となりました。

なぜこれだけ違いが出たのか

今回キャッシュした記事フィードは、アクセスするたびに内容が変わるものではありません。
新しい記事が公開されない限り、同じカテゴリーに対してWP_Queryを実行すれば、基本的には同じ記事が返ってきます。

にもかかわらず、
「アクセスされる → WP_Queryを実行する → 同じ記事を取得する → 同じHTMLを生成する」
という処理を毎回繰り返していました。

Transient Cacheを利用すると、一度生成した結果を一定時間再利用できます。

今回のように複数カテゴリーの記事フィードを1ページに表示する構成では、繰り返し実行される処理を減らせるため、その効果が比較的大きく現れたと考えられます。

もちろん、すべてのWordPressサイトで46%速くなるわけではありませんのでご注意ください。
カテゴリー数、記事数、テーマやプラグインの構成、サーバー環境、データベースの状態などによって効果は変わります。

また実際の運用では、単純に1時間キャッシュするだけでなく、記事の公開・更新時に該当するTransientを削除するなど、コンテンツの更新を適切に反映する仕組みも必要になります。

WordPressが遅い原因はサイトによって異なります

WordPressの高速化では「とりあえずキャッシュプラグインを入れる」といった対応だけではなく、どの処理に時間がかかっているのかを確認し、一つずつ改善していくことが重要だということです。

今回取り上げたWP_Queryは、その一例です。

• 「WordPressサイトの表示が遅い」
• 「アクセス数の増加とともにサイトが重くなってきた」
• 「さまざまな高速化を試したものの改善しない」

といったお悩みがありましたら、サイトの構成や処理内容を確認したうえで改善方法をご提案させていただきます。
是非お気軽にご相談ください！