サイト速度改善(ブログ記事)の前編
まえおき
某スキルマーケットでサイトの速度改善の案件をときどき見かけます。
ただ、自分にはその手の知識がなかったこともあって鬼門もであるサイトの速度改善を敬遠してたのですが、知識習得のために行ってきたカスタマイズも実装することが少なくなり時間の余裕も出てきました。そんなこともあって思い切って鬼の懐(速度改善対策)に飛び込み実践(実装)で得たスキルや知識や改善の結果を専門用語の解説(長々と)や持論(否定が多いかも)を混ぜながら記事をまとめて投稿することにしました。
なお、この記事はWordPressでサイトを構築(する)していることが前提です。
ファーストビューとページの読み込み
サイトの速度改善で覚えていて欲しい最初の単語は「ファーストビュー」と「ページの読み込み」です。
ファーストビュー
ファーストビューはスクロールせず見られる表示部分(画面)のことです。ファーストビューを観て一般的に３秒以内に読み進めるかどうかをユーザーは判断するそうです。
勘違いしやすいのがファーストビューとはサイト(ホームページやブログなど)を開いたときに最初に表示される範囲のことで最初に表示するページそのもののことではありません。大体のサイトでは以下の要素(パーツ)が含まれてます。
サイト名やロゴ、また、カーセル(スライダー)などユーザーにサイトの概要や目的の情報を探してもらうためのパーツで文字や画像を表示させる部分です。
ユーザーに興味を持って貰うために表示するパーツ(主に文章)です。カーセル(スライダー)に含まれているケースが多いです。
そんなファーストビューの要素ですが、多くのユーザーは検索エンジンより記事のリンクを辿ってくることがほとんどなのでロゴやキャッチコピーを見せる(魅せる)工夫が大切になります。また、二つの要素は各ページに共通するパーツでもあり、ページによってはデザインもカーセル(スライダー)がなくヘッダーバーのみになるテーマも多いので工夫が必要です。
ページの読み込み
ページの読み込みはサイトを構成する色々なページ(種別)のことですが、この記事においてはトップページのことをさします。それを踏まえて、とある記事を観たときに疑問に思ったのが「ページ読み込みは２秒以内。３秒待てないモバイルユーザー…」と言う感じの記事のタイトルを観たときです。
自身の前提条件が厳しいと思うのですが「WordPresseでは不可能に近いんでないかなぁ…」と瞬間的に感じました。
※あくまでもトップページにおいてです。
それは３秒ルールは静的サイト(ホームページ)のことに適応されるルールだと自分は思っているからです。動的サイトであるWordPressは動的にページを作るためコンテンツの管理機能や各ページの作成機能などに膨大な数のモジュール(関数)を実行して動いています。
レンタルサーバーのスペックが上がっていてもページデータの作成(phpファイルの実行)に少し時間(0.5秒～1秒ほど)がかかるためです。静的サイトは出来上がっているページデータ(htmlファイル)を出力するだけで、WordPress(CMS)の動的サイトには致命傷になるときがあります。
また、トップページは投稿、固定ページ(WordPress上のでページ種別)と比べて表示するコンテンツ量(主に記事一覧)などが多いため必然とページのデータ量も増えます。投稿や固定ページでも画像を多様すると完全に読み込む(表示する)のに時間が掛かってしまいます。
また、特にトップページはカスタマイズなどで表示させる情報が増え投稿データ(本文)や関連データ(カスタムフィールド)が蓄積されていくとデータベースからデータを読み込んでHTMLを作成するのに時間が掛かってしまうケースがあります。
そんなWordPressのサイトで、しかもモバイルユーザー(モバイル回線(低速度)を前提にすると)だとするとページの読み込み(ファーストビューでない全体のことを言っている感じ？)を２秒と言う時間は不可能に近い要件(要望)だと思うからです。
ただ、ファーストビューだけに限っては「できなくはない」と思います。どのようなことをすればそれが可能なのかを解説していきたいと思います。
ただ、改善を検討される前に考えて欲しい…
時間や費用を掛けてまで速度改善する必要があるかは自分は疑問に思っています。サイトの主目的にもよりますがWordPressは使うテーマによって最適化されているテーマもあるからです。それ以上のことを求めるとサイト全体にまで影響範囲が増えるのである程度は妥協する必要もでてきます。
ただ、サイトの主目的がアフェリエイト(広告収入)なら…
アフェリエイトのサイトは必然とコンテンツの量も増えるので必要性があるかなと思います。とはいえ、広告収入を得られるのは本当にひと握りの人達なので、実際に多くの時間や費用を掛けてまで＂対応する必要性があるのかな？＂と思えるのが正直なところです。
冒頭から否定になってしまいましたが、それだと記事(ブログ)にはならないので、必要性や重要性、技術や方法(手法)をまとめて解説して行きたいと思います。
サイトの表示速度を上げる必要性
検索エンジンからの評価が下がる
サイトの表示速度が遅いと次の画面が待ちきれなくなったユーザーが離脱して、他のサイトに行ってしまう可能性が高くなります。また、Google検索では検索アルゴリズムの「スピード・アップデート」というものを採用していてページの表示が速度が遅いと検索結果のランキング順位が下がることもあるようです。
参考：「ページの読み込み速度をモバイル検索のランキング要素に使用します」
＂検索ユーザーはできるだけ早く質問に対する回答を見つけたいと考えています。研究（英語）では、ユーザーはページの読み込み速度を非常に気にかけていることがわかっています。 読み込み速度はこれまでもランキングシグナルとして使用されていました＂ 引用元：Google 検索セントラル https://webmaster-ja.googleblog.com/2018/01/using-page-speed-in-mobile-search.html?m=1
ただ、検索エンジンのランキング付けにおいてはページの表示速度は複数ある指標のうちの１つで、それが大きな割合を占めているわけではありません。アフィリエイトにおいては表示速度の遅れにより、ユーザーが記事から＂離脱してしまう＂という問題のほうが重要です。
記事が読まれにくくなる
ページの表示速度が遅いサイトは離脱率や直帰率が高くなる傾向にあります。記事を読んでくれるユーザーは早く答えや解決策が知りたくて記事にたどりついています。そんなときにいつまでもページが開かないと、しびれをきらしてページを閉じてしまう可能性が高くなります。
ユーザーがWebサイトから去るということはアフィリエイト記事も当然読まれにくくなるため、コンバージョン率にも影響します。
ここでも＂3秒ルール＂…
＂米国設立のWebアクセス解析ツール提供会社「Kissmetrics」の調査によると、ネット利用時に３秒以上ページの表示を待たされると離脱するユーザーは40%存在する＂と報告されているので、記事を読んでもらうためにはページの表示速度は３秒以内にすることが理想的です。
そのため、動的サイトであるWordPressのサイトは静的サイトに比べてページの表示速度の不利もあってページ速度の改善が必要項目な訳(理由)です。
では…
サイト速度の改善はサーバー側(レンタルサーバー)の話になることも多いですが、実際にはフロントエンド(WordPressやテーマやプラグインなど)側の対応が重要です。近年のレンタルサーバーの性能は何処も同じなことが大きな理由です。大きな差があるとすれば価格やサポート体制だったりするかと思います。
では実際にどんなことをする必要があるかというと二つ目の単語は「圧縮」と「遅延」です。
その理由と効果など専門用語も混じりますが自分なりの考えで解説します。
先ず、高速化と言っても…
上記の項目の通信の高速化はファイルの軽量化や通信方法を変えることで通信時間を短縮して表示を速くするようなことで、体感速度の高速化は処理や通信を実際に速くするわけではなくユーザーに＂処理が速いと錯覚させる(※)＂ような手法(技術)です。
この２つの要点を踏まえたうえでサイトの速度改善に繋がる具体的な方法やポイントを解説していきます。
速度改善のポイントと高速化の項目
先程も触れましたが、動的サイト(動的ページ)であるWordPressは静的サイト(静的ページ)に比べてページの表示速度に関して圧倒的に不利(※１)です。そのため下記のポイントと高速化の項目に対して適切な対応をとる必要性がWordPressを使うサイトにはあります。
物理リソースへの対応(確認要項)
サイトを開設する際に重要な項目なのですがランニングコストも考える必要があります。サイトの主目的によっては導入段階からサーバースペックの高いレンタルサーバー会社やプランを検討(確認)することが必須です。
まず、物理記憶装置にはＨＤＤではなくＳＳＤが使われているサーバーを、次にWebサーバーのソフトウェア(アプリケーション)には『LiteSpeed』もしくは『NGINX』が使われているかを検討(確認)してください。また、レンタルサーバーのＣＰＵも処理時間に影響があるので、どんなＣＰＵを使ったレンタルサーバーかを検討(確認)してください。
※共有型なのか占有型なのかも重要ではあります。
上記のことを踏まえてレンタルサーバーをすでに契約しているのであればプランを変えるか、よりスペックの高いレンタルサーバーに乗り換える必要があります。（※２）
キャッシュ対応
キャッシュ対応と言ってもいくつかのポイントがありレンタルサーバー上で対応する内容とWordPress上で対応する内容に別れます。
ブラウザキャッシュ
ブラウザキャッシュとはユーザーがアクセスしたサイトのデータをブラウザに保存(一時的)しておく技術のことです。ブラウザ内に保存される画像やHTMLなどのデータも同様にブラウザキャッシュと呼びます。
サーバー側の設定で直接編集するか、プラグインで設定する必要がある内容です。
通常、ページを表示するときにはページの各種データ（HTML／CSS／JavaScript）をサーバーよりダウンロード（配信される）してから表示させます。それに対してブラウザキャッシュがあればユーザーが再訪問したときにブラウザ側に保存された画像やHTMLデータか優先的に使われます。
ブラウザキャッシュはあらためてページの各種データをダウンロードする必要がないためサイトの表示時間が短縮でき、データのダウンロードにかかるパケットも節約できるメリットがあります。
※あくまでも再訪問したユーザーを対象にしているキャッシュなので初めて訪問したユーザーには効果がありません。※ＣＤＮを使っていれば効果がある場合もあります。※他のサイトで同じＣＤＮを使っていたときです。
ブラウザキャッシュの対応についてはサーバー上にある設定(.htaccess)にコマンドのようなものを追加したり修正することで対応が可能です。また、一部のプラグインでもファイル(.htaccess)を直接的に操作することなく対応が可能です。
※体感は効果(大)、サイト速度計測数値はほぼ影響なし
データキャッシュ
データキャッシュとはユーザーがアクセスしたときに作成するページに必要なデータをサーバー側に保存(一時的)しておく技術のことです。WordPress上ではデータベースや外部より取得したデータを含む様々な種類のデータがあり、それをキャッシュにする仕組みがWordPressには存在します。
テーマ上のプログラムコードを個別に対応を行う必要がある内容です。
※ページに必要なデータ(キャッシュ)が存在しない(キャッシュの有効期間がしたときやコンテンツが更新されての初回アクセスなど)ときのユーザーに対しては効果がありません。
WordPressのデータキャッシュ(API)と言ってもメモリ上ではなくデータベース（ＨＤＤ／ＳＳＤ）上で管理されているため物理リソースの影響を少し受けます。ただ、データ(画像を除く)を読み込む際に時間がかかるものや、外部データを取得する際に制限があったり取得に時間がかかる場合など、データキャッシュを利用することでブラウザキャッシュ同様にサーバー側の負荷や時間を減らせるメリットがあります。
結果、ブラウザ側にデータを素早く送れるためサイト速度の改善に効果があります。
※体感は効果(低)、サイト速度計測数値は効果(低)
ページキャッシュ
キャッシュとは、１度つくったページ(HTMLなど)のデータを保存(一時的に)しておく技術のことです。保存データを再利用することで、ページを速く表示することができます。WordPressの場合、サーバー内にある複数のモジュール(ファイル)をつなぎ合わせて実行することで１つのページが作られます。
以下のようなことが行われています。☆クライアント側 ★サーバー側
☆ユーザーがサイトにアクセスする
★サーバー内で、WordPressが各種データを元にページを作る
★完成したページデータ(HTMLや画像)をサーバーが配信する
☆ユーザー(クライアント側)がダウンロードする
☆ブラウザ(ユーザーエージェント)がＰＣやスマホで表示する
テーマのプログラムコードやプラグインで行う必要がある内容です。
上記の中で処理に時間がかかるのが、上記２、３(４）の項目です。しかし、ページをキャッシュしておけば、ページを作る時間を減らしてダウンロードするまでの時間(ＴＢＴも)を減らすことができます。その結果、サイトの表示速度を少し上げることができます。
３(４）の項目の対応については「gzip圧縮」で解説します。
※体感は効果(低)、サイト速度計測数値は効果(中)
雑学：GTmetrix https://gtmetrix.com/
『GTMetrix』はウェブサイトを計測し、その速度と最適化について分析をしてくれます。パフォーマンスの問題をチェックしたり、テーマが不要なファイルで雑然としていないかどうかなど確認(検証)したりするのに便利なオンラインサイト(ツール)です。
GTmetrix Grade: Performance ScoreとStructure scoreを基にランク付けした指標です。グレードは実際のサイトのパフォーマンスとユーザーの体感パフォーマンスの両方を考慮しています。
Performance Score: GTmetrixのテストで計測されたLighthouseのパフォーマンススコアです。高いほど優れています。
Structure Score: LighthouseとGTmetrix独自の検査の両方に基づいた指標です。Performance Scoreとほぼ同じ値であることが理想的です。
Web Vitals: ユーザーが体感するパフォーマンスの重要な指標としてGoogleが定めたものです。主要な指標にはLargest Contentful Paint（LCP）、Total Blocking Time（TBT）、Cumulative Layout Shift（CLS）があります。
GTmetrixでは「Largest Contentful Paint（LCP）」、「Total Blocking Time（TBT）」、「Cumulative Layout Shift（CLS）」の3つを採用しています。
Largest Contentful Paint（LCP）：ページの最も大きな要素が読み込まれるのにかかる時間を意味します。LCPはサイトのキービジュアルの読み込み時間であることもあれば、サイト本文の読み込み時間であることもあります。
Total Blocking Time（TBT）：ユーザーがサイトを操作できるようになるまでにサイトがブロックされている時間です。レンダリングを妨げるCSSやJavaScriptはTBTに大きな影響を及ぼすことがあります。
Cumulative Layout Shift（CLS）：ページが読み込まれる間に起きる要素のズレです。例えば、ツイートが埋め込まれたページのレイアウトではページ読み込み時に大きなズレが発生することがあります。
インライン化への対応
ちょっと疑問な項目とあげた理由は自分自身あまり実感(理解)できていないためです。ただ、速度改善に関連するブログやサイトでも必ず項目に上がっています。ただ、インライン化によりCSSやJavaScriptがレンダリングをブロックしなくなることで速度改善できると言うことらしいです。
インライン化への対応の内容は＂今回、ググッたもの＂を自分なりにまとめたものです。
レンダリングブロックとは
ページを表示するまでにブラウザは以下のようなことが行われいて、画面の描画に関連する処理が重いことで描画が遅延してしまうことをレンダリングブロックと良います。
CSSやJavascriptは外部ファイルに記述することが一般的になっていますが、外部ファイルにしているとブラウザは＂どうやってレンダリングすれば良いか＂がわからないため、外部ファイルのCSSやJavascriptを読み込むまでレンダリングをストップしているらしいです。
そのため、最近では「大まかなレイアウトを規定するCSSやJavascriptはHTMLのHEAD内に直書きする」という手法(クリティカルCSS)が取られているようで、ページ要素（サイトロゴやページヘッダなど）を高速表示させて、その後に残り部分をレンダリングすると言う感じにするそうです。
※まだ、自分はそんなテーマには出会ってません。
理屈はわかるのですが理解(実感)できていないんです。(笑 ただ、結果的に＂それが速くなるんだよ＂的なことだと…今は理解し始めてます。
では、実際のインライン化とは…
CSSのインライン化
解説するのはCSSのインライン化です。JavaScriptもありますが割愛します。(笑
解説すると画面描画(デザイン)に必要なテーマやプラグイン毎にあるCSS(ファイル)を分割して送るのではなく＂そのデータが無いと描画できないんだから＂、HTMLコード内に埋め込んで速く表示させると言う手法(技術)です。その際にCSSのミニファイ化も併用するのが好ましいです。
CSSのインライン化はテーマ上でできるテーマもありますがテーマ上でのプログラム対応をするにはちょっと大変なので、簡単にプラグインで行うことができるので「インライン化」できるプラグインを導入してください。
ただ、HTMLコードが…
HTMLコードにCSSのデータを含めるとサーバーから送られる初回のデータが肥大化します。ただ、サーバーからの送信データを圧縮(gzip)する設定がされていれば特に問題になることは無いです。※モバイル回線の場合は若干遅くなります。
自分のサイトの検証したときはトップページのページサイズが540KB程(最終的)になっていましたが、通信転送上は100KB程(含めないと30KB)になっていたので80%軽減されていました。
後日談…
クリティカルCSSを利用するのもアリかも？
クリティカル(正式名称はクリティカルパス)CSSはページを読み込むときに「ファーストビュー(最初に見える範囲)」のCSSだけをHTMLファイルにインラインCSSとして書き込んでおいて「ファーストビュー以外(見えていない範囲)」のCSSは別ファイルとして非同期に読み込み高速化する手法(技術)です。※効果がでないケースもあるかも(現在検証中)。
何処かのブログ記事によると1回目のレスポンスで送信できるサイズ上限の14KBくらい(多分、gzip圧縮サイズ)に収まるようにするといいらしいです。※WordPressはHTML上の文字列(サイズ)が長く(多く)なる傾向にあるので厳しいような気がしますが…。
なお、クリティカルCSSはサイト上のCSS(連結したCSS)と各ページのURLを用意すればオンラインツールで抽出可能です。
CSSの単なるインライン化はページデータ(HTMLデータ)を肥大化させますが、ファーストビューの範囲のCSSだけならサイズを最小限に抑えられるので少し速く表示できます。※低速度の通信環境であれば効果あります。
ただ、結合したCSSは遅延読み込み(差分ではない)するので、トータル的に通信量は増えますが体感的な効果は(絶大)です。以下、理由。
ちなみにフロントページのページキャッシュを調べてみると、クリティカルCSSを使わなかったときのインライン化したページサイズ(HTMLファイル)は450KB程で、クリティカルCSSをインライン化(サイトCSSを含まないと)したときのページサイズは50KB程(通信上での圧縮サイズは12KB程)でした。
クリティカルCSSの危険性…
ファーストビューに表示させる部分をピックアップしてCSSを抽出する必要がありますが、ページの種類ごとに抽出しないと行けないケースがあります。簡単にいえばページ毎に特色があるコンテンツを表示している場合です。抽出に漏れがあるとレイアウト崩れをお招く危険性があります。ただ、本当のCSSは遅延読み込まれるので直ぐに解消されます。
トップページ、や投稿ページや固定ページ、また、アーカイブページなどWordPressにはいくつものページスタイルが存在しているているので、プラグインでページ毎に設定ができないときは全てを詰め込んで設定する必要があります。
事象が発生しやすいのはモバイル回線(低速度)のときです。読み込まれるまでは3,4秒程掛かると思われるので、各ページに工夫が必要になります。※この手の作業は費用は高くなりますが本当の専門家(速度改善のサービスをメインにうたっている会社)におまかせするのが良いと思います。自身で対応するときはプラグインは色々なルール設定が可能なものもを選びページの種別ごとに細かく設定することをおすすめします。
インライン化にはブラウザがCSSをキャッシュに保存できず(HTMLに組み込まれているため)、後続のページの読み込みでCSSを再利用できないという欠点もあるため慎重に使用することをお勧めします。ただ、ページキャッシュのプラグインを併用することで回避できます。ただ、頻繁にWordPress(テーマやプラグインなど)の設定を変更するときは注意が必要です。※ページキャッシュをそのたび初期化してください。
クリティカルCSSとインライン化の可能性…
WordPressで定義されるCSSはテーマやプラグインなど複数の機能毎に開発者が違うため一つ一つモジュール化されページの種類に関係なく読み込まれます。※ページ毎に読み込むCSSを変えているテーマもあるかも？ですが、そのページに使わないCSSも混じっているため、クリティカルCSSの機能を使えばページに最適なCSSも含めほんの少し改善できます。ただ、元々のCSSは遅延読み込みされるのでクリティカルCSSを活用するのであればさらなる工夫が必要です。
ただ、個人的にはクリティカルCSSとインライン化はサイトの速度改善には有効な対応なのかも知れません。…と、思いつつ疑心暗鬼なんですがね！
(まだ評価がありません)
読み込み中...