WPOガイド：ウェブサイトの読み込み速度を最適化する
近年、マーケティング担当者があらゆる最適化プロセスの最上位に読み込み速度を置くようになるのを私たちは見てきました。2017年にGoogleは読み込み速度の重要性とランキングへの将来的な影響を強調し始めましたが、2018年夏になってようやくGoogleはこの声明を公式化しました。
この記事では、皆さんが自分でウェブサイトの読み込み速度の最適化と改善を始められるようにお手伝いすることを目指しています。あらゆる最適化プロセスと同様に、複雑になり得る技術的な側面があります。SEO Aliveでは、この種の記事を書くときはいつでも、皆さんが自分で実装できることを望んでいますが、いくつかのアクションはより技術的なレベルの知識を必要とします。とはいえ、正直なところ、サイトのWPOを監査するために使用するツールのスコアを追い求めて気が狂わないようにしましょう。
最適化はテンプレートがどのように設計されたかに大きく依存し、すべてのテンプレートが同じパフォーマンスを得られるわけではありません。これを念頭に置いておくことが重要です。
それでは始めましょう！
WPOとは何か？
ウェブパフォーマンス最適化、私たちが呼ぶWPOとは、単純にウェブサイトの読み込みに影響する様々なプロセスの最適化のことです。
ウェブサイトの読み込み速度を測定する方法は？
読み込み速度を測定するためのツールはたくさんあります。最も人気のあるものは：
監査を始める前に、読み込み速度はユーザーごとに異なることを念頭に置くことが重要です。さまざまな変数がクエンカ（スペイン）にいるユーザーとオタワにいるユーザーの速度の感じ方に影響を与える可能性があります。
そのため、秒単位の読み込み時間に取り組むのではなく、以下の最適化に焦点を当てることをお勧めします：
-
ウェブサイトの重さ（MB）
-
リクエスト
-
サーバー応答時間
これら3つの領域を改善すれば、ユーザーがどこにいても読み込み速度が改善されます。
それぞれの領域に深く入り込み、さまざまなツールを通じて、どのように取り組めばすべてのURLのパフォーマンスを改善できるかを見ていきます。なぜすべてのURLと言うのでしょうか？それは、当たり前のように思えるかもしれませんが、ホームページのデータのみが評価されるケースに何度も遭遇したことがあるからです。そしてもちろん、サイトのすべてのページが同じリソースを読み込むわけではないのです。
Google開発者ツール
始める前に、Googleが開発者ツールを通じて提供するいくつかのオプションについて説明したいと思います。このツールは、ウェブサイトがどのように動作するかを分析するための最も重要なものの一つです。ブラウザで開いているページを右クリックすると、さまざまなオプションを含むパネルが表示されます。Inspect（Ctrl + Shift + I）に進みます。
そのツールが開いたら、上部にあるNETWORKオプションに進みます。ブラウザで再度ENTERを押すと、ツールは様々なリソースの読み込みを表示します。
画像の下部に、サイトの読み込みについての一般的なビューに必要なデータが表示されます。
このパネルを上部から深く掘り下げ、列の構造を見ると、以下があります：
-
Name: リソースの名前。
-
Status: リソースの応答コード（200、301、404...）
-
Type: リソースのタイプ（script、font、png、jpg、stylesheet...）
-
Initiator: どのリソースがリクエストをトリガーするか。
-
Time: リクエストにかかった時間。
-
Waterfall: リソースの読み込み時間のグラフィック表現。
上部を右クリックすると、この情報の列を追加および削除できます。
Domain、Scheme、Cookiesなどの追加の情報要素を有効にすると、特定のケースで何らかの問題を引き起こしている可能性のあるリソースを特定するのに役立ちますが、現時点では事前定義されているものを使用します。
非常に興味深いものの、私たちが念頭に置くために軽く触れるだけにする側面があります。接続速度、特にモバイルでの接続速度は、サイトの読み込み方の重要な部分です。このツールから、モバイルの3Gのような遅い速度をシミュレートできます。
URLの重さを知る方法とそれを減らす方法は？
メガバイトであれキロバイトであれ、重さはURLの読み込みに時間がかかる主な理由の一つです。そのため、サイトで良い最適化を達成するための道筋を設定するため、この側面を深く掘り下げることから始めます。
以下のデータは、上記で言及したツールGTMETRIXから取得したもので、私が最適化を始めようとしているウェブサイトに対応しています。
右側の列のデータ、つまり（Page Details）を参照しているデータ、特にTotal Page Sizeに焦点を当てます。
一見すると、このサイトの重さは平均をはるかに上回っていますが、重要なのはサイトの総重量ではなく、その重量が読み込まれるのにかかる時間であることに注意してください。なぜなら、Lazy Loadと呼ばれる機能があり、ユーザーがリソースを必要とするまで読み込みを遅延させる機能があるからです。後でそれについて話します。
この情報は、上記で見たパネルの開発者ツールでも見つけることができます。再度思い出してください。
下部を見ると、7.5 MBと215のリクエストの両方がGTMETRIXによって報告された数値に非常に近いことがわかります。GTMETRIXがどこから情報を取得しているかを知ることが重要です。万が一、別のツールを使用したい場合に備えて。
では、何がそんなに重く、どのように修正できるかを見てみましょう。
Waterfallオプションは、リソースがどのように読み込まれるかを視覚的に確認できるようにし、リソースのURL、ステータス、ドメイン、Size列を表示します。その最後の列をクリックすると、重さが大きいものから小さいものへ、また小さいものから大きいものへとソートされます。
重さを見ると、ほとんどの場合と同様に、画像がURLの過剰な重さに大きく責任があることがわかります。
画像の最大重さに関する正式な仕様はありませんが、100 KBを超えないこと、そしてオプションがある場合（Photoshopを使用する場合は可能）、画像をJPGとして段階的に読み込むように設定し、アルファチャンネル（透明度）が必要ない場合は常にPNGを避けることをお勧めします。
画像の重さを減らすことで、サイトの読み込みを大幅に改善でき、使用できるツールがいくつかあります。私自身はPhotoshopで最適化していますが、興味深いオンラインオプションがあります：
GTMetrixとGoogleツールの両方で、リソースをタイプ別に表示できます。つまり、画像のみ、スクリプトのみ、CSSのみ…
これは、どこに取り組むべきかについてより広い視点を得るのに役立ちます。このURLでは、画像が7.2 MBのうち4 MBを占めているので、重さの問題の大部分はそこにあります。それでも、CSSファイルが700 KBを超え、スクリプトが300 KBを超えるなど、そのタイプにとって非常に重いリソースが他にもあります。
ここで明確にしておきたいのは、読み込み速度の最適化（WPO）を実施するときには、解決策はあるものの、私たちが行動する範囲外にある特定の問題に直面しなければならないということです。
この場合、非常に大きなCSSファイルが見られます。デザイナーが700 KBを超えるCSSを作成した場合、その特定のファイルを最適化するのは困難です。
これらのファイルの重さを減らすために何ができるでしょうか？
最小化（CSS、JS、HTML）
最小化は、コメント、スペース、繰り返しコード、未使用コードなどの不要なデータを削除することでファイルの重さを減らすことを目指すプロセスです。このプロセスを実行するためのツールはたくさんあります。ただし、最適化が困難で、ファイルに手動で入る必要がある未使用コード部分を除きます（私はお勧めしません）。
ファイルを最小化するツール
-
HTML Minifier http://kangax.github.io/html-minifier/
-
CSS Nano https://cssnano.co/
幸い、私たちはWordPressについて話しており、ご存じのように、WordPressではこの操作を処理するプラグインを見つけられないことは非常に稀です。
個人的には、完全に無料のAutoptimizeと有料のWP Rocketを使用するのが好きです。
この記事では、これらのプラグインがどのように機能するかを説明することよりも、最適化タスクをどのように実行するかを説明したいと思います。なぜなら、他のプラグインを使用する場合でも、これらのオプションがあり、最も良いのは私たちが何をしているのかを理解することだからです。
WP Rocketで最小化する
この部分は複雑ではありません。ファイル最適化タブに進み、minify HTMLボックスにチェックを入れるだけです。WP Rocketでは、このオプションはCSSとJSファイル用に下に繰り返されています。それでも、このボックスを有効にしてテストすることをお勧めします。何かが失敗した場合、問題を特定しやすくなるため、このオプションを一つずつ繰り返してください。
最小化の効果を確認する前に、キャッシュをクリアする必要があります。そうしないと、更新されたHTMLの結果が表示されません。
ブラウザのキャッシュをクリアする方法は？
この種のプラグインには、上部に表示されるキャッシュをクリアするためのオプションが付属しています。
別の方法は、Google開発者ツールが有効になっている（Ctrl + Shift + I）状態で、ブラウザを通じて行うことです。
「ページを再読み込み」矢印を右クリックし、「キャッシュを空にしてハードリロード」を選択します。
Autoptimizeで最小化する
Autoptimizeでは、optimizeアクションが最小化を実行します。HTMLコメントを保持するオプションを提供する特殊性があります。これらのコメントは通常、開発者が将来役に立つかもしれない情報を保持するために追加します。
この最適化が有効になっていることを確認するために、URLのソースコードに進み、次のような表示が見られるはずです：
コードは判読不能になりますが、その機能は同じです。
これらのオプションは、CSSおよびJSファイルに対してWP RocketとAutoptimizeで同じように繰り返されます。先ほど述べたように、すべてを一度に最適化するのではなく、1つずつ最適化することをお勧めします。これらのプラグインは、最小化されたファイルのコピーを保持するため、対応するボックスのチェックを外すことで元に戻すことが可能です。
ページの重さを減らし続けるには、さらに2つのオプションがあります：
-
読み込みにCSSやJSを追加するプラグインを削除または減らす。
-
CSSファイルから未使用コードを削除またはトリミングする。
これら2つのオプションはより複雑で、より多くの知識を必要とします。なぜなら、削除している部分に他のページからの呼び出しがないかを注意深く確認する必要があるからです。
プラグインを削除することは、それが提供するリソースのために常に可能ではありませんが、他のものよりもよりよく最適化されたプラグインがあります。つまり、より少ないリクエストとより軽いJSです。だから、素晴らしいWordPressエコシステムには、ほとんど常に代替案があります。
読み込み時間と応答時間
今度はリクエスト、応答時間、読み込み時間について話す時です。この時点で、プロセスの基本部分であるサーバーについて言及する必要があります。サーバーの最適化は通常私たちの手の届かないところにあるので、効率的なソリューションを選ぶことが重要です。
しかし、一歩ずつ進めましょう。
リクエストとは何か？
リクエスト、つまりHTTP Requestは、特定のリソースを要求するためにクライアントからサーバーへ行われる呼び出しです。リクエストは異なるサーバーに到達することができます。
リクエストはHTTPまたはHTTPSのいずれかになります。リクエストの構造を見ると、時間の遅延がどこで発生するかを分析できます。
HTTPリクエスト時間の分析
HTTPリクエスト構造
このタイミングチャートで見られるものを分解してみましょう。
-
リクエストが開始されるがブロックまたはキューに入れられる：ブロックが長く続く場合、複数の理由がある可能性があります：優先度の高いリクエスト、またはこのオリジンへの多くのリクエスト。
-
DNS Lookup: ブラウザがリクエストのIPアドレスを解決しています。
-
Connecting: リクエストを解決するためにサーバーに接続するのにかかる時間。この時間が長い場合、ネットワークの問題、接続エラー、または過負荷のサーバーを示している可能性があります。
-
Sending: リソースリクエストが送信されます。
-
Waiting: これはサーバーがリクエストを解決して応答を送信するのにかかる時間です。長い場合、サーバーに問題があります。
-
Receiving: リソースを受信中。
HTTPSリクエストにはもう1つステップが追加され、ここに表示されます。
これら2つのスクリーンショットは2つの異なるサイトに属しています。1つは最適化されていない（HTTP Request）もので、もう1つは最適化されている（HTTPS Request）ものです。
注意深く見て比較すると、最大の違いは待機時間にあります。これらの場合、サーバーをより詳細に分析する必要があります。
サーバーリクエスト：どのように減らせるか？
これまで見てきたように、リクエストの数は読み込み時間と密接に関連しているので、リクエストの数を減らすことでURLの読み込み時間が改善されます。常識は最適化プロセスにおいて役割を果たし、リソースが本当にユーザーやビジネスに有用かどうかを知ることが重要です。これは、何の貢献もしない特定のリソースに別れを告げる時ですが、それを決めるのは私ではありません。
それでも、リクエストを改善するためのオプションがあります。これらのアクションがサイトの読み込みに大きな変化をもたらさないとしても。繰り返しますが、最善は何の貢献もしないリソースを削除することです。
CSSとJSを結合する
ウェブページを最適化する際のもう1つの一般的なアクションは、CSSとJSリソースを結合することですが、それはどういう意味でしょうか？
結合の目的は、ファイルの重さを増やすことの代償としてリクエストを減らすことです。結合とは、異なるCSSまたはJSリソースを1つに統合することを意味します。
応答時間が長い場合、結合は有益である可能性があります。送信時間が非常に遅い場合は、別のテクニックの方が良いかもしれません。
理想的なのは、良いサーバーを持ちながら結合することです。そうすれば両方の側面で勝利できます。
WP RocketとAutoptimizeでリソースを結合する
これらのプラグインでの結合操作は、前と同じくらい簡単です。対応するボックスにチェックを入れるだけです。
WP RocketではCSSとJSを結合するオプションは同じで、パネルは実質的に同じです。画像で見られるように、結合したくないファイルのパスを追加するためのボックスがあります。
チェックボックスの下には、HTTP/2を使用している場合は結合オプションを使用しないようにとのメモも表示されています。この記事ではHTTP/2について詳しく説明しています。
AutoptimizeはCSSを操作してリクエストを減らすためのより多くのオプションを提供しています。私がマークするオプションでは、結合し、それが持つ可能性のある効果について警告を出しますが、結局のところこれは常に相対的なものです。
この記事の最初の部分では、特定の基本的なアクションが何で構成されているかを説明したかったのです。ほとんどすべてのWPO最適化プラグインで通常見られるものですが、リクエストと読み込み時間の両方を改善するためにできることはまだたくさんあります。
キャッシュ設定
間違いなく、キャッシュ最適化は、サイトの読み込み方法において最大の改善が見られるアクションの一つです。このWordPressのSEOに関する記事で、キャッシュがどのように機能するかを説明しました。その仕組みを理解するために、ぜひ目を通すことをお勧めします。
AutoptimizeとWP Rocketはキャッシングアクションを実行しますが、WP Rocketはもう少し多くのオプションを提供しています。プラグインがこの最適化をよりシンプルなものに変えてくれたことは注目に値します。オプションは2つほどしかなく、プロセスは迅速で痛みを伴いません。
ご覧のとおり、WP Rocketでは4つの作業ができます：
-
モバイルデバイスのキャッシュを有効にする。
-
モバイルデバイス用に別々にファイルを保存する。
-
ログインユーザーのキャッシュを有効にする。
-
キャッシュをクリアする時間を指定する。
どのオプションを選択するかは各プロジェクトに依存しますが、これらすべてを念頭に置いた私のアドバイスは：
-
モバイルキャッシュは常に。なぜなら、ほとんどのサイトがレスポンシブですが、モバイルにはあるがデスクトップにはないコンテンツがあるかもしれないからです。
-
別々にファイル。
-
ログインユーザーにはキャッシュなし。特に編集を行っている場合、キャッシングは望まないからです。
-
キャッシュ時間は、サイトに加える変更の数に依存します。日刊ニュースサイトであれば短く、頻繁に更新されないコンテンツであれば長くします。
Lazyload
Lazyload機能は、ユーザーが必要とするときにリソース（画像とiframe）を表示するのに役立ちます。つまり、ブラウザはユーザーがそこまでスクロールするまでこれらのリソースを読み込みません。この機能は多くのプラグインで実装されており、一部のWordPressテーマでは事前設定されている場合もあります。Chromeバージョン76以降では、ブラウザにネイティブで搭載されています。
これは、loading="lazy"属性を追加することで、ブラウザが画像のlazyロードを既に解釈することを意味しますが、もちろんすべてのブラウザがこれを解釈するわけではないので、引き続きプラグインを使用することをお勧めします。web.devから取得した、画像のlazyローディングが何であるかの例を示すビデオがあります。
Iframeの最適化
他のサイトからコンテンツを埋め込むためにiframeを使用する場合、読み込みを改善するために使用できる2つのアクションがあります。
-
lazyload機能を介したlazyローディング
-
またはユーザーがクリックするまでiframeを画像に置き換える。
最初のオプションも2番目のオプションも、再び私たちのお気に入りのプラグインWP Rocketを通じて有効にできます。
Autoptimizeはこの部分を持っていませんが、それを行うための補完プラグインのインストールを提供しています https://wordpress.org/plugins/wp-youtube-lyte/
DeferまたはAsyncを使用したJSファイルの遅延読み込み
JSファイルは、速度監査がページのレンダリングブロックと呼ぶものの原因の一つです。これは、レンダリング中にブラウザが停止してJSファイルをダウンロードして実行するときに発生します。WPO最適化の目標はできるだけ早くユーザーに情報を届けることです。これがブロッキングと見なされる理由は、ダウンロードされたJSが実行されるまで何もレンダリングされないからです。
これが、この種のアクションが監査でよく指摘される理由です。最適化が不十分なサードパーティのプラグインやテーマを使用する場合、たとえばヘッダーにあるためにレンダリングをブロックするJSが存在する可能性があります。
これらの場合、JS呼び出しコードに追加される2つの属性、DeferとAsyncを使用する必要があります。これらの属性が機能するためには、スクリプトが外部である必要があります。
SEO Aliveでは、適用したいファイルと読み込み方法を選択できるPre Party Resource Hintsプラグインを使用しています。素晴らしいです！
DeferとAsyncの違いは何か？
両方の属性は、DOM HTML解釈がJSによって停止されるのを防ぐという同様の目標を持っていますが、両者には顕著な違いがあります。
Async属性では、リソースはHTMLの読み込みを停止せずにダウンロードされますが、ダウンロードされると、HTMLの読み込みが一時停止されてJSが実行されます。defer属性では、リソースもHTMLの読み込みと並行してダウンロードされますが、読み込みが終了したときに実行されるので、スクリプトによるブロッキングはありません。
この点で、WP RocketとAutoptimizeの間に違いがあります。WP Rocketは決定をはるかに簡単にし、JSがレンダリングをブロックしないように半自動で動作します。一方、Autoptimizeでは、Asyncオプションをトグルできるだけです。
Autoptimizeでは、extraタブの下にAsyncで読み込みたいJSファイルを追加するこのオプションがありますが、より柔軟性のために、別の補完プラグイン「Async Javascript」を推奨しています。
このプラグインを使用すると、DeferとAsyncの両方を操作でき、ワンクリックオプションも提供されており、物事を簡単にします。このプラグインの良いところは、スクリプトを操作し、必要と思われるものを除外できることです。一方、WP Rocketでは、プラグインが行うことを信頼する必要がありますが、それはうまく行います。
このオプションは同じファイル最適化タブにあります。
CDNとは何か、どのように私たちを助けることができるか？
CDNはコンテンツ配信ネットワークとして知られているものです。CDNは、サーバーのこれらのリソースの負荷を軽減し、読み込みによりよく応答するために、情報とリソースの一部を保存する役割を果たします。CDNはまた、ユーザーがどこから接続してもリソースを利用できるようにし、異なるポイントでリソースを提供するための地理的コピー機能も持っています。通常、この種のサービスは画像やビデオなどの重いファイルに使用されます。
このサービスにサインアップすることは、トラフィックの多いサイトを持つ場合に重要ですが、トラフィックの少ないサイトでも除外すべきではありません。
さらに少し改善するためのその他のアクション
記事をまとめるために、読み込み時間に大きな変化をもたらさないものの、リクエストを減らすのに役立つ、さらに3つの改善があります。結局のところ、それが私たちが望むことです。
フォントの最適化
フォントの最適化は、プラグインを通じて、または手動でCSSを編集して最適化することで行うことができます。理想は、使用するフォントだけを呼び出し、多くの場合のように、すべてのGoogle Fontsを含むファイルをダウンロードしないことです。
Autoptimizeにはフォントを操作するオプションがあります。
プロジェクトを見ずにどのオプションを選ぶかを言うのは難しいです。なぜなら、テンプレートがどのフォントを使用しているか、いつ読み込まれるかを知らないからです。だから最善は試して結果を見ることです。
ご覧のように、Google Fontsオプションのすぐ後に「Remove Emoji」があり、これによりサーバーへのリクエストが節約されます。その機能は、絵文字を表すシンボルをアイコンに変換することです。
WP Rocketでもこれらの絵文字を無効にすることができ、サードパーティサイトにコンテンツが埋め込まれるのを防ぐオプションも提供しています。
結局のところ、サイトの読み込み速度を改善するためのアクションはたくさんあります。すべてのリソースを最適化するために深く取り組むことが常に可能なわけではありません。なぜなら、ビジネスのタイプとそれが必要とするものに依存するからです。
このWPO最適化ガイドが役立ち、プロジェクトやクライアントのために適用できることを願っています。
著者: David Kaufmann
私はこの10年以上、SEOに完全に夢中になって過ごしてきました。正直なところ、他の生き方は考えられません。
私のキャリアが新たな次元に到達したのは、Chess.com でシニアSEOスペシャリストとして働いたときでした。Chess.com はインターネット全体で最も訪問数の多い上位100サイトの1つです。数百万ページ、数十言語、そして最も競争の激しい SERPs の1つという規模で仕事をした経験は、どんなコースや資格でも得られないことを教えてくれました。あの経験は、本当に優れたSEOとは何かという私の視点を一変させ、それ以降に私が築いてきたすべての土台となりました。
その経験から、私は SEO Alive を創業しました。オーガニック成長に本気で取り組むブランドのためのエージェンシーです。私たちは dashboards や月次レポートを売るためにここにいるのではありません。本当に成果を動かす戦略を構築するためにここにいます。クラシカルなSEOの最良の部分と、Generative Engine Optimization (GEO) というエキサイティングな新しい世界を組み合わせ、あなたのブランドが Google の青いリンクだけでなく、ChatGPT、Perplexity、Google AI Overviews が毎日何百万人もの人々に届けている AI 生成の回答の中にも確実に表示されるようにします。
そして、この両方の世界をきちんと扱えるツールが見つからなかったので、自分で作りました。それが SEOcrawl です。rankings、テクニカル監査、backlinks モニタリング、crawl ヘルス、そして AI ブランド可視性トラッキングを1つの場所に統合した、エンタープライズ向けのSEOインテリジェンスプラットフォームです。まさに、ずっと存在してほしいと願っていたプラットフォームです。
この著者の他のコンテンツをご覧ください
