WordPressのパフォーマンスを最適化するための高度なガイド

公開: 2022-03-11

今日、WordPressはインターネットの30％以上に電力を供給しています。 それは使いやすく、信じられないほど人気が​​あり、すぐにどこにも行きません。

しかし、WordPressは遅くなる可能性があります。 では、どのように最適化するのでしょうか。

WordPressを調整して最適化する方法についての記事はたくさんあります。 実際、WordPress自体は、WordPressの最適化に関する強力なガイドを提供します。

ほとんどの場合、これらの記事とチュートリアルでは、キャッシュプラグインの使用、コンテンツ配信ネットワーク（CDN）との統合、リクエストの最小化など、非常に基本的でありながら便利な概念について説明しています。 これらのヒントは非常に効果的で必要ですが、最終的には根本的な問題に対処していません。ほとんどの遅いWordPressサイトは、不良または非効率的なコードの結果です。

WordPressのパフォーマンスを最適化するための高度なガイド

WordPressは遅くなる可能性がありますが、そうである必要はありません。
つぶやき

したがって、この記事は主に、開発者とWordPress開発会社に、多くのWordPressパフォーマンス問題の根本的な原因に対処するのに役立つガイドラインを提供することを目的としています。

WordPressは、開発者が見落としがちなパフォーマンス指向の機能を数多く提供します。 これらの機能を利用しないコードは、投稿の取得などの最も単純なタスクの速度を低下させる可能性があります。 この記事では、WordPressのパフォーマンスの低下の背後にある根本的な問題のいくつかに対処する4つの可能な解決策について詳しく説明します。

投稿の取得

WordPressは、データベースからあらゆる種類の投稿を取得する可能性を提供します。 これを行うには、3つの基本的な方法があります。

  • query_posts()関数の使用：これは非常に直接的なアプローチですが、問題は、メインクエリをオーバーライドすることであり、不便につながる可能性があります。 たとえば、投稿（ footer.php内など）を取得した後のある時点で、処理しているページの種類を判別したい場合、これは問題になる可能性があります。 実際、元のクエリを復元するには追加の関数を呼び出す必要があるため、公式ドキュメントにはこの関数の使用を推奨する注記があります。 さらに、メインクエリを置き換えると、ページの読み込み時間に悪影響を及ぼします。

  • get_posts()関数の使用：これはquery_posts()とほとんど同じように機能しますが、メインクエリを変更しません。 一方、 get_posts()は、デフォルトで、 suppress_filtersパラメーターをtrueに設定してクエリを実行します。 これにより、特にコードでクエリ関連のフィルターを使用する場合、ページで予期しない投稿がこの関数によって返される可能性があるため、不整合が発生する可能性があります。

  • WP_Queryクラスの使用：私の意見では、これはデータベースから投稿を取得するための最良の方法です。 メインクエリを変更せず、他のWordPressクエリと同じように標準的な方法で実行されます。

しかし、データベースとの対話にどの方法を使用する場合でも、考慮する必要のある他のことがあります。

クエリを制限する

クエリがフェッチする必要のある投稿の数を常に指定する必要があります。

これを実現するために、 posts_per_pageパラメーターを使用します。

WordPressでは、そのパラメーターの可能な値として-1を指定できます。この場合、システムは、定義された条件を満たすすべての投稿をフェッチしようとします。

応答として返される結果がわずかであると確信している場合でも、これは良い習慣ではありません。

一つには、ほんの少しの結果しか得られないことを確信できることはめったにありません。 また、可能であっても、制限を設定しない場合は、データベースエンジンがデータベース全体をスキャンして一致するものを探す必要があります。

逆に、結果を制限すると、データベースエンジンがデータを部分的にしかスキャンできないことがよくあります。これは、処理時間の短縮と応答の高速化につながります。

WordPressがデフォルトで行うもう1つのことは、パフォーマンスに悪影響を与える可能性があり、スティッキーな投稿を取得して、クエリで見つかった行数を計算しようとすることです。

ただし、多くの場合、その情報は実際には必要ありません。 これらの2つのパラメーターを追加すると、これらの機能が無効になり、クエリが高速化されます。

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

クエリからの投稿の除外

Wordpressクエリから投稿を除外する

特定の投稿をクエリから除外したい場合があります。 WordPressは、 post__not_inパラメーターを使用するという非常に直接的な方法を提供します。 例えば：

 $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 < count( $query->posts ); $i++ ) { //do stuff with $query->posts[ $i ] }

ただし、これは非常に単純ですが、内部的にサブクエリを生成するため、最適ではありません。 特に大規模なインストールでは、これにより応答が遅くなる可能性があります。 いくつかの簡単な変更を加えて、PHPインタープリターで処理を実行する方が高速です。

 $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 < count( $query->posts ) && $i < $posts_per_page; $i++ ) { if ( ! in_array( $query->posts[ $i ]->ID, $posts_to_exclude ) ) { //do stuff with $query->posts[ $i ] } }

私はそこで何をしましたか？

基本的に、私はデータベースエンジンからいくつかの作業を取り除いて、代わりにPHPエンジンに任せました。これは、同じことを実行しますが、メモリ内にあり、はるかに高速です。

どのように？

まず、クエリからpost__not_inパラメーターを削除しました。

クエリによって、結果として不要な投稿が表示される可能性があるため、 posts_per_pageパラメーターを増やしました。 そうすることで、応答に不要な投稿があったとしても、少なくとも$posts_per_pageの必要な投稿がそこにあることを確認します。

次に、投稿をループすると、 $posts_to_exclude配列内にない投稿のみを処理します。

複雑なパラメータ化の回避

これらのクエリメソッドはすべて、投稿をフェッチするためのさまざまな可能性を提供します。カテゴリ別、メタキーまたは値別、日付別、作成者別などです。

その柔軟性は強力な機能ですが、パラメータ化は複雑なテーブル結合やコストのかかるデータベース操作につながる可能性があるため、注意して使用する必要があります。

次のセクションでは、パフォーマンスを低下させることなく同様の機能を実現するためのエレガントな方法の概要を説明します。

WordPressオプションを最大限に活用する

WordPressオプションAPIは、データを簡単にロードまたは保存するための一連のツールを提供します。 これは、WordPressが提供する他のメカニズム（投稿や分類法など）が非常に複雑な小さな情報を処理する場合に役立ちます。

最適化されたWordpressオプション

たとえば、認証キーやサイトのヘッダーの背景色を保存する場合、オプションが必要です。

WordPressは、それらを処理する機能を提供するだけでなく、最も効率的な方法で処理することもできます。

一部のオプションは、システムの起動時に直接ロードされるため、より高速なアクセスが可能になります（新しいオプションを作成するときに、自動ロードするかどうかを検討する必要があります）。

たとえば、バックエンドで指定された最新ニュースを表示するカルーセルがあるサイトについて考えてみます。 私たちの最初の本能は、次のようにそのためのメタキーを使用することです。

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

ご覧のとおり、このアプローチは非常に単純ですが、最適ではありません。 特定のメタキーを持つ投稿を見つけようとするデータベースクエリを実行します。 オプションを使用して、同様の結果を得ることができます。

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

機能は例ごとにわずかに異なります。

コードの最初の部分では、投稿の公開日に関して、常に最新の最新ニュースを取得します。

2つ目では、新しい投稿が最新ニュースとして設定されるたびに、以前の最新ニュースが上書きされます。

しかし、おそらく一度に1つの最新ニュースの投稿が必要なので、問題にはならないはずです。

そして、最終的に、重いデータベースクエリ（メタキーでWP_Queryを使用）を、より優れたパフォーマンスの高いアプローチである単純で直接的なクエリ（ get_post()を呼び出す）に変更しました。

小さな変更を加えて、オプションの代わりにトランジェントを使用することもできます。

トランジェントは同様に機能しますが、有効期限を指定できます。

たとえば、ニュース速報の場合、古い投稿をニュース速報として使用したくないので、手袋のようにフィットします。そのニュース速報を変更または削除するタスクを管理者に任せると、管理者はそれを忘れる可能性があります。それ。 したがって、2つの簡単な変更で、有効期限を追加します。

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

永続的なキャッシュを有効にする

WordPressにはネイティブにオブジェクトキャッシュメカニズムがあります。

たとえば、オプションはそのメカニズムを使用してキャッシュされます。

ただし、デフォルトでは、そのキャッシュは永続的ではありません。つまり、単一のリクエストの期間のみ存続します。 アクセスを高速化するために、すべてのデータはメモリにキャッシュされますが、そのリクエスト中にのみ使用できます。

永続キャッシングの図

永続キャッシュをサポートするには、永続キャッシュプラグインをインストールする必要があります。

一部のフルページキャッシュプラグインには永続キャッシュプラグインが含まれていますが（たとえば、W3 Total Cache）、含まれていないため、個別にインストールする必要があります。

ファイル、Memcached、またはその他のメカニズムを使用してキャッシュデータを保存するかどうかは、プラットフォームのアーキテクチャによって異なりますが、この驚くべき機能を利用する必要があります。

「これがとても素晴らしい機能であるなら、なぜWordPressはデフォルトでそれを有効にしないのですか？」と尋ねるかもしれません。

主な理由は、プラットフォームのアーキテクチャによっては、一部のキャッシュ手法が機能する場合と機能しない場合があるためです。

たとえば、分散サーバーでサイトをホストする場合は、外部キャッシュシステム（Memcachedサーバーなど）を使用する必要がありますが、Webサイトが単一のサーバー上にある場合は、ファイルシステムを使用するだけでコストを節約できます。キャッシュする。

考慮する必要があることの1つは、キャッシュの有効期限です。 これは、永続キャッシュを使用する際の最も一般的な落とし穴です。

この問題に正しく対処しないと、ユーザーは、自分が行った変更が表示されない、または変更を適用するのに時間がかかりすぎると不満を言うでしょう。

パフォーマンスとダイナミズムの間でトレードオフを行うこともありますが、これらの障害があっても、永続的なキャッシュは事実上すべてのWordPressインストールで利用する必要があります。

最速の方法でAJAXする

AJAXを介して当社のWebサイトと通信する必要がある場合、WordPressは、サーバー側でリクエストを処理するときに抽象化を提供します。

これらの手法は、バックエンドツールやフロントエンドからのフォーム送信をプログラミングするときに使用できますが、厳密に必要でない場合は避ける必要があります。

これは、これらのメカニズムを使用するために、 wp-adminフォルダー内にあるファイルにpostリクエストを送信する必要があるためです。 WordPressフルページキャッシングプラグインの大部分（すべてではないにしても）は、投稿リクエストも管理者ファイルへの呼び出しもキャッシュしません。

たとえば、ユーザーがホームページをスクロールしているときに動的にさらに多くの投稿を読み込む場合は、他のフロントエンドページを直接呼び出すと、キャッシュされるというメリットが得られます。

次に、ブラウザのJavaScriptを介して結果を解析できます。

はい、必要以上のデータを送信していますが、処理速度と応答時​​間の点で勝っています。

WordPressがただ遅いという概念を破壊する

これらは、WordPressのコーディング時に開発者が考慮すべきアドバイスのほんの一部です。

プラグインやテーマを他のプラグインと一緒に使用する必要があることや、共通のデータベースを使用して数百または数千の他のサイトにサービスを提供しているホスティング会社がサイトにサービスを提供していることを忘れることがあります。

プラグインがその機能をどのように処理するか、または効率的な方法でプラグインを実行する方法ではなく、プラグインがどのように機能するかに焦点を当てています。

上記のことから、WordPressのパフォーマンス低下の根本的な原因は、コードが悪く非効率的であることは明らかです。 ただし、WordPressはさまざまなAPIを通じて必要なすべての機能を提供し、プラットフォーム全体の速度を損なうことなく、はるかにパフォーマンスの高いプラグインとテーマを構築するのに役立ちます。