WordPressの高速化を知識を抑えた上で行いませんか?実測値を上げる27の施策を解説します

質問者

ん? なんだか・・・サイトの表示が・・・遅い様な・・・気がする・・・気のせい・・・ではないな・・・

 WordPressの高速化はサイトを運営している人にとっては非常に重要なファクターの1つです。どれくらい重要かについて、この記事を閲覧している人に説明する必要はないと思います。

  • 3秒以内に表示されないと、半数以上の訪問者が離脱
  • 1秒の遅延で10%以上のの売り上げが減る
  • 表示が遅いだけで検索結果順位が下がる

 調べればたくさん文献が出てきますが、もはや当たり前のことなので、いちいちこの事実を証明するために引用を用いたりはしません。

質問者

そんなことは分かっています。どうにかしてWordPressを高速化しなければなりません。

 

 この様に言われそうなので、本題に入りましょう。WordPressを高速化するには大きく分けて3つの作業が必要です。

  1. サーバーの見直し: 実測値の改善
  2. WordPress処理の見直し : 実測値の改善
  3. Googleから見たページの高速化 : Google 評価の改善

 今回述べるのは[1]と[2]についてです。[1]・[2]と[3]で分けた理由はどうしてでしょうか? 実は実測値だけで見るなら[1]と[2]だけやれば良いのです。しかし、厄介なことにGoogleはページの実測値以外にも、多くの指標を元にページ評価を下しているため、Google検索エンジンから見ても評価が高くなる様にページを構築する必要があります。

 よって、[3]は話の流れでは触れていますが、実測値の高速化とは別の視点で見なければならないので本稿では深く突っ込みません。

KAZU

世の中の90%以上のWEB体験がGoogleから始まります。Googleは神です。従いましょう。

 [3]については、2020年5月28日にGoogleから「2021年からコアウェブバイタルを検索ランキングの要素に含める」 と話があったため、2021年以降はWordPressの高速化への意識はさらに必要になると思われます。

quote-left

Core Web Vitalsと既存のページエクスペリエンスのシグナルを組み合わせた新しいシグナルを導入して、Webページでのユーザーエクスペリエンスの品質の全体像を提供します。

Googleウェブマスターセントラルブログ(訳しました)

 私もエンジニアとして、そしてWordPressデベロッパーとして、[3]に対応するにはどうするかを真剣に考え、いろいろ試行錯誤したのですが、結論は「サイト全体をAMPで作る」というのが唯一無二の解決策ではないかと考え、IDEA HACKでは、ブログページとコース関連ページを含むほとんどのページをAMPで表示しています。*というか、固定ページ以外基本全てAMPです。

 この話は本稿の話題ではないので、気になる方は下記の記事も合わせてお読みください。

AMP対応とは?簡易ページと考えたら負け! AMPでサイト自体を構築すべき決定的な理由
AMP対応とは?簡易ページと考えたら負け! AMPでサイト自体を構築すべき決定的な理由

 話を戻します。本稿のタイトルに[実測値]とわざわざ入れた理由はお分かりいただけましたでしょうか?この記事の作業は必要ですが、これだけでは皆様の目標である「Googleから高評価をもらう」ことは達成できないからです。このことに触れていない(分かっていない?)WEBマーケターが多い気がします。

KAZU

とはいえ、絶対に無視して良い物ではありません。Googleから高評価をもらうための土台として、[1]・[2]の作業は必須です。

サーバーの見直し: 実測値の改善

 サーバーの見直しについて考えていきましょう。サーバー選びというのは非常に重要です。日本ではレンタルサーバーがシェアを占めていますが(これは日本だけですよ。)、レンタルサーバーはサイトに知名度が出てきたら離脱しなければならない運命(そしてここで大体のブロガーはつまづく)なので、ここではVPSを使うことを念頭にします。

 サーバー選びで考えるべきポイントは下記の通りです。

  • サーバーサイドキャッシュを扱う
    • バイトコードキャッシュ
    • オブジェクトキャッシュ
    • ページキャッシュ
  • CDNの利用
  • リージョンの見直し
  • NGINXを採用しているホスティング会社を選択する
  • 最高のパフォーマンスのため、PHP 7以上を使用する
  • HTTP/2を利用する
  • 待ち時間を減らす
  • DNSプロバイダーにも気を使う

サーバーサイドキャッシュを扱う

 サーバーレベルでのキャッシングは、エンドユーザーにとってはもちろん、そして私たちWordPressサイト運営者によっても嬉しい機能です。サーバーサイドキャッシュは、さらに4つに分けることができます。これらキャッシュの各レイヤーの概要を理解しておくことは、キャッシュに関連する不具合の対処にも役立ちますので、メディアやECサービスを運営されている方は絶対覚えてください。またはこのページをブックマークしましょう。

バイトコードキャッシュ

バイトコードキャッシュは、同じコードが次回使用されるときにコンパイル手順をスキップできるように、コンパイル済みのPHPコードを保存します。OPcacheの有効が選択肢に含まれている、または有効になっているサーバーを選択しましょう。

 PHPファイルやスクリプトが処理されるときは、最初に機械可読なOPコードにコンパイルする作業が発生します。OPcacheが、この変換済みのOPコードを保存することにより、該当のファイルまたはスクリプトが再度必要になったときにPHPがコンパイル手順をスキップすることができます。OPcacheを使用すると、PHPのパフォーマンスが大幅に改善します。

オブジェクトキャッシュ

 オブジェクトキャッシュはデータベースクエリの結果を保存し、次回その特定のデータが要求されるとデータベースにクエリを実行せずにキャッシュを利用する仕組みです。これによりPHPの実行時間が短縮されます。もちろん、オブジェクトキャッシュは複数のページの読み込みに渡って再利用されるため、WordPressのデータベースの負荷も減ります。

 例えば下記のコードを同じページで何度も利用しますよね?

WordPress
<?php
$post_id = get_the_ID();
?>

 毎回このリクエストを素直にDBに行っていたらあまりにも非効率ですし、DBへのリクエストも無駄に増えて良いことがありません。それなら、この関数を通じて行われるSQLリクエストの結果をキャッシュして節約したいですよね。オブジェクトキャッシュはまさにこの作業を行ってくれます。

 この作業は、実際には[Redis]というオープンソースのメモリデータ構造を使って行います。WordPress向けにはこれを導入するためのプラグインが用意されていますが、あくまでサーバーを触れる人向けです。

構築にコマンドの知識とインフラの知識が必要な割には6万インストールです。これは多いと思います。

 WordPressサイトの運用ではフルマネッジドのサーバーの利用をオススメしています。このプラグインを導入するよりも、これを既に組み込んでいるサーバーを選ぶことが賢明です。

WP オブジェクトキャッシュ

 実は、WordPressには、WP_Object_Cacheという組み込みのオブジェクトキャッシュがあります。これはオススメしていません。 WP_Object_Cacheは、同一ページの読み込みに対して同じSQLリクエストの1度しか行わない様にすることでページの読み込み速度を上げる物です。しかし、他のページに渡って再利用される物ではないため、サーバーが用意するオブジェクトキャッシュの方が優秀です。

ページキャッシュ

 ページキャッシュは最終的に出力されたHTMLを保存して使い回すことで、サーバーの処理を全部省いて高速化を行います。

 WordPressが読み込まれるとき、WordPressは多数のPHPファイルを処理して、データベースに何度も照会していることは何となく理解していると思います。WordPressでメディアやブログを運営している人にとって、これは無駄と思うはずです。一度目の生成時に、そのページを保存し、次のリクエスト時にはそれを返した方が得策です。

質問者

これは周知の事実です。でも、なぜサーバー側の対策にページキャッシュがリストされているのですか?WordPressのプラグインが基本対応していますよね?

 もちろん、WordPressのプラグインはページキャッシュを採用していますが、サーバーサイドのページキャッシュの方が遥かに条件と性能が良いのです。

 条件についてですが、先ほど私は「サーバーの処理を全部省いて高速化」と申し上げました。これはサーバーサイドのページキャッシュの話です。プラグイン側のページキャッシュでは、どうしてもWordPressの初期動作が走ります。プラグイン側なのですから当然です。

 性能についてですが、ページキャッシュにはnginx fastcgi cache moduleを採用するのが一般的です。このFastCGIを利用したキャッシュの仕組みがプラグイン側の処理よりも圧倒的に性能が良いです。私自身もこの違いに焦点を当てていない時期がありまして、導入前後のデータが下記になります。

FastCGIを導入したらレスポンスがとんでもないくらい速くなりました。

 なので、サーバーサイドでキャッシュする仕組みを用意しているサーバーを選ぶことは非常に重要です。

KAZU

ちなみに、「LiteSpeedの方が早いじゃん」と言う人がいますが、LiteSpeedをVPSでかつフルマネッジドで運用するのは非常に難しいため、考慮に入れていません。VPSでLiteSpeedのフルマネッジドサービスを行ってるクラウドホスティングプロバイダーを私は知りません。レンタルサーバーの中にはLiteSpeedを売りにしている会社がありますが、それはたくさんのサイトを一括で1つのサーバーで運用する仕組みですし、それを専門に監視するインフラ担当がいるからできるのです。

CDNの利用

 CDN(コンテンツ配信ネットワーク)キャッシュは、世界中のサーバーに同じデータを保存しておいて、常に近くのサーバーからデータを配信することでユーザーとの地理的距離を縮め、ページを高速化する仕組みです。ユーザーがページにアクセスする際、設定に応じて一部のデータがオリジンサーバーからではなく、CDNサーバーから配信されます。

KAZU

一般的には静的リソースであるCSS / JS / 画像に適用します。HTMLの出力自体も可能ですが、WooCommerceなどのECサービスの利用などでは不具合が出ることもあるので、オリジンサーバーから返すのが一般的ですね。

CDNには、2つの主な利点があります。

  • サイトの読み込みに必要なサーバーリソースの量を削減します。CDNが処理を行っているため、オリジンサーバーは処理しなくても良くなります。
  • 世界中の複数箇所の場所からリソースを配信できるため、サイトがホスティングされているサーバーから地理的に離れているユーザーへのパフォーマンスが改善されます。

リージョンの見直し

 オリジンサーバーの設置箇所も重要なファクターです。インフラの業界ではこのオリジンサーバーの位置のことを「リージョン」と呼びます。CDNを利用していたとしても、HTMLの配信自体はオリジンサーバーで行うケースが大半なので、やはり重要です。次の画像をご覧ください。

リージョンの位置は[Time to Interactive]に結構影響を与えます。

 この様に、リージョンの位置はGoogle Page Speed Insightにおける[Time to Interactive]に結構影響を与えます。

 日本人の方は東京リージョン・大阪リージョン、またはシンガポールリージョンを選ぶのが得策です。

KAZU

この様に言っておきながら私はUSリージョンです。理由は将来的に英語圏で行う予定のサービスがあり、かつフルマネッジドサービスの中で、コスパが最適と思えるサービスが日本リージョンを提供していなかったからです。先ほどのレスポンスの画像も上記のPage Speed Insightの画像もUSリージョンから配信しているデータです。それにしては速いと思いませんでしたか?知識があれば、USリージョンでもこのくらい出ますよ。

NGINXを採用しているホスティング会社を選択する

 WordPressで利用されるサーバーは次の3つです。

  • Apache
  • NGINX
  • LiteSpeed

フルマネッジド環境下では[NGINX]が実現できる最適なソリューションです。

 有名な会社でNGINXを採用しているのは企業の中には、Autodesk、Atlassian、Intuit、T-Mobile、GitLab、DuckDuckGo、Microsoft、IBM、Google、Adobe、Salesforce、VMWare、Xerox、LinkedIn、Cisco、Facebook、Target、Citrix Systems、Twitter、Apple、Intel等があります。

NGINXのロゴ

PHP 7以上を使用

 最新版のPHPをサポートしないサービスは皆無なので、ここでは「自分が常に最新版のPHPで動く環境を維持する」ことと「最新版のPHPが利用できるまでのタイムラグが少ないサーバー選ぶ」ことが重要です。

KAZU

レンタルサーバーは結構遅いですよね、私は昔Xサーバーを使っていた時期がありましたが、半年くらいかかってた印象があります。遅すぎ・・・

 PHP7以上を使用するが何故大事なのでしょうか? 新しいPHPの方が速いからです。これを証明するベンチマークテストを定期的にKinstaが行ってくれています。これは非常に助かります。2020年11月にはPHP8がリリースされます。さらにパフォーマンスが良くなるはずなので、今から待ち遠しいです。


Img src: Kinsta

HTTP/2を利用

 HTTP/2の利用も忘れてはなりません。2015年にリリースされたウェブプロトコルです。HTTP/1が同時に1つのレスポンスしか処理ができなかった点を解消し、複数のレスポンスを同時に処理することで、ページの読み込み速度を飛躍的に向上させました。技術的には多重化・並列性を持ったと言えます。

 HTTP/2の利用にはHTTPS通信が必須です。これとSSL証明書をサポートしていない、またはSSL証明書に費用がかかり、コスト高になる場合は、そもそもサーバーを移行すべきです。

KAZU

ちなみに、ファイルの結合をすることで読み込むファイル数を減らしてページの読み込み速度向上させる施策が多くのサイトで紹介されていますが、これはHTTP/1での話です。HTTP/2の場合はこの作業がHTTP/2のロジックの中で行われますので、不必要な作業です。

 また、ブラウザのサポートがまだほとんど無いため、導入している会社は少ないですが、HTTP/3が登場しています。多くのサーバーは今後HTTP/3を導入していくことかと思います。現時点ではHTTP/3を導入しているサーバーを選ぶ必要は全く無いでしょう。

待ち時間を減らす

 WEBサーバーとユーザーの間にはもちろん、物理的な距離があります。CDNを使えば、HTMLリソース以外に関しては、オリジンサーバーのリージョンは関係なくなります。しかし、HTMLだけはオリジンサーバーから吐き出すケースが多いため、ターゲットユーザー層の近くにオリジンサーバーを設定することで、物理的距離を減らす必要があります。

 実際、この物理的距離は[ネットワーク待ち時間][TTFB]への影響を与えます。

ネットワーク待ち時間

データのネットワークを介したの送信に必要な時間と遅延のことです。言い換えると、データのパケットがある地点から別の地点に移動する時間です。普通はミリ秒内で完了しますが、ネットワークによっては数秒かかる場合もあります。これを0に近づけることでGoogle Page Speed Insightで高評価をもらいやすくなります。

TTFB

「最初の1バイトが到着するまでの時間」(Time To First Byte)を指します。簡単に言うと、TTFBはブラウザがサーバーからのデータの最初のバイトを受け取るまでにかかる時間のことです。そのデータを受け取るまでに時間がかかるほど、ページを表示するのにかかる時間が長くなります。これも0に近づけることでGoogle Page Speed Insightで高評価をもらいやすくなります。

 これらを減らす方法は単純です。オリジンサーバーのリージョンをターゲットユーザー層がいる地域にすることです。

DNSプロバイダーにも気を使う

DNS

DNSとはDomain Name System(ドメイン名システム)の略で、IPアドレスとドメイン名を相互参照させる物です。*名前解決と言います。通常、全てのサイトはIPアドレスでアクセスする様になっています。例えば、216.3.128.21の様な値です。これは人間に取っては非常に覚えづらいものになります。そこで、idea-hack.comのような名称を付けて、それをIPアドレス(216.3.128.21 *ただしこれは実際の値ではありません。)に紐づけることで、「idea-hack.comとブラウザバーに打つと、DNSサーバーが名前解決を行い、該当するIPアドレスを特定し、アクセスをつなげてくれる」わけです。

 DNSの役割を担うサーバーを[DNSサーバー]と言い、それを運用している組織を[DNSプロバイダー]と呼びます。この[DNSサーバー]にも性能差があります。DNS作業を行うのが遅いDNSサーバー(無料が主)もあれば、非常に早いDNSサーバー(有料が主)もあり、AmazonのRoute 53の様な有料のDNSサーバーを選ぶ人が一定数いる理由はこういう背景からです。

質問者

では、どのくらい早ければ良いのでしょうか?

 明確な答えはありませんが、このページを読んでいる皆様が大企業のインフラ担当者であり、複雑なインフラ環境を扱っているわけでも無いと仮定すると、DNSサーバーは皆様がお使いのWEBサーバーと同じ場所にあると考えられます。また、CDNと同じ様に、世界に同種のコピーサーバーが点在してるはずです。

 同一リージョンにDNSサーバーがある場合は 100ms 以下になっているのが理想です。DNSサーバーの応答速度をテストするツールがありますので、IDEA HACKでテストしてみました。

IDEA HACKは USリージョンです。前述した通りこれには理由があるわけですが、この事情のせいで、日本からサイトにアクセスした場合70ms程かかっています。これは遅いです。

 IDEA HACKのオリジンサーバーはUSリージョンです。私がパートナーを組んでいるホスティングベンダーは東京リージョンをまだ用意していないため、DNSサーバーも東京に存在しません。そのため、やや遅い結果となっています。

KAZU

ちなみに、私は現在パートナーとWEBサーバーの東京リージョンの開設と皆様への販売に取り組んでおり、2021年の前半を目標に進めております。開設した段階で、IDEA HACKも東京リージョンへ移行する予定です。それでも、DNSサーバーの東京設置は、コスト高になるため見送る予定です。40msの節約のためにインフラ投資して、販売コストが上がるのは腑に落ちないので・・・

 まずは、あなたのサイトのDNS時間を調べてみてください。

WordPress処理の見直し : 実測値の改善

 WordPressの処理の見直しについて考えていきましょう。考えるべきポイントは下記の通りです。

  • プラグインサイドキャッシュを使う
    • ブラウザキャッシュ
    • ページキャッシュ
    • フラグメントキャッシュ
  • プラグインの取捨選択
  • アーカイブページの表示件数の調整
  • defer属性・async属性の付与
  • CSSの非同期化
  • 外部ファイルの結合
  •  CSSの@importの不使用
  • CSSのセレクタの簡素化
  • 不要なコードの削除
  • リソースの縮小
  • 画像の圧縮
  • 画像の遅延読み込み
  • 画像フォーマットの最適化

 説明するのが嫌になる程たくさんありますが、1つ1つ見ていきましょう。

プラグインサイドキャッシュを使う

 高速化について考えたとき、皆様が最初に思いつくのが「プラグインを使ったキャッシュ作成」です。上述した通り、ページキャッシュについては、サーバーサイドの物を使った方が良いですが、他にもやっておくべきキャッシュはあります。

ブラウザキャッシュ

ブラウザにCSSやJSなどの繰り返し使うファイルをユーザーのデバイスに保存することで、ページの読み込み速度を向上します。ユーザーは都度ネットワークからリソースを取得する必要がなくなるため、ネットワーク使用料の削減にもつながります。

ブラウザキャッシュは一定時間期間ごとにリセットされる等に構築されますが、その期間を自分で指定することが可能です。Googleは1年間を推奨しており、Google Page Speed Insightでも1年未満の場合は警告が出され、ページ評価に悪影響が出ますので、365日以上をオススメします。

ページキャッシュ

仕組みは上述したサーバーサイドのキャッシュと同じです。ただ、プラグインで行う方が遅いです。

フラグメントキャッシュ

WordPressが用意している部分キャッシュのことです。メディア運営など、ページキャッシュを有効にできる環境下で運用が可能である場合は必要ありません。しかし、ログインユーザーに対してはページキャッシュを有効にできない(会員サイトなど)場合があります。その場合でも、ページ全体を素直に都度データベースにリクエストするよりも、使いまわせる部分は使い回した方が賢いです。フラグメントキャッシュはこの様にページの一部分をキャッシュするのをサポートします。

ページの一部を使い回すWordPress フラグメントキャッシュの使い方

プラグインの取捨選択

 WordPressはプラグインなしでは運用できません。しかし、プラグインはサイトのパフォーマンス低下の主要因となります。ただ、「プラグインの量が問題ではなく、質が問題」ということは誤解しないでもらいたいです。

KAZU

IDEA HACK は30近いプラグインを有効化しており、その中にはWooCommerce・Jetpackも含まれます。それにも関わらず、Google Page Speed Insightでは90点近い点数を出せます。

 あなたがエンジニアなら、WordPressプラグインの負荷テストを行い、重いプラグインを特定することができるでしょうが、多くのWordPress利用者にそれが可能とは思えません。そこで私がオススメする方法は以下の2つの作業です。

ステージング環境で1つずつ検証

 私が常に気にするのはGoogleの評価であり、Google Page Speed Insightの結果です。ステージングで全てのプラグインを無効にして、下記の作業を行ってみてください。

  1. プラグインの優先順を決める
  2. 全てのプラグイン無効化
  3. 1つだけ有効化
  4. Google Page Speed Insightで測定
  5. [3]に戻って繰り返す

 ページ評価に影響を与えるプラグインを見つけるにはこれが手っ取り早いです。私の場合だと、以前 Add This プラグインをサイトに導入していました。これがAMPで唯一サポートされている3rd パーティーのSNSモジュールだからです。

Add This

 しかし、Google Page Speed Insightで測ったところ、残念なことに、非常に多くのデータを読み込んでおり、サイトのパフォーマンスに影響が出ていました。現在はこのプラグインの使用をやめて、Google公式のAMPコンポーネント(amp-social-share)を利用しています。

 この様に、Googleからの評価を意識しながらプラグイン選定ができるのでオススメです。

有効化するプラグインをテンプレート単位で制限する

 どうしても必須のプラグインがあり、それを有効するとサイトのパフォーマンスが低下するケースもあります。例えば、ElementorやContact Form7は非常に有名で人気ですが、動作が遅く・重い事でも有名です。

KAZU

しかし、これらのプラグインは別に全てのページで読み込む必要は無いわけです。WordPressは有効化されているプラグインをそのページ上での実際の使用有無に関わらず読み込みます。これはあまりに非効率です。

 そこで、テンプレート別に読み込むプラグインを選択する必要があります。状況により、2つの方法を組み合わせます。

 1つは目はAMPプラグインを利用していて、[スタンダードモード]を選択している場合です。BrandiaはAMPの[スタンダードモード]を利用することを推奨しており、IDEA HACKもAMPプラグインの [スタンダードモード]を適用しています。

WordPress AMP

詳しくは下記記事も参考にしてください。

AMP対応とは?簡易ページと考えたら負け! AMPでサイト自体を構築すべき決定的な理由
AMP対応とは?簡易ページと考えたら負け! AMPでサイト自体を構築すべき決定的な理由

 AMPプラグインはAMPページ上で任意のプラグインを無効化する機能を用意しています。[Plugin Suppression]の欄にはAMPが許可していないコードが存在しているプラグインが表示され、これらのプラグインに含まれている許可されないコードを取り除く[Active]か、そもそもプラグインを有効化しないかを選択する[Suppressed]ことが可能です。

AMPプラグインのPlugin Supression

 私の場合、Brandiaでサイトを構築しているので、WordPressコアとBrandiaがサポートを意識しているプラグインの機能はAMPでも動きます。一方でElementorやフォーム関連のプラグインなど、AMP上ではどうしても動かないプラグインもあります。ただ、これらのプラグインは[固定ページ]など、一部テンプレートでしか使われません。

 よって、[Supported Templates]の欄で一部のページだけをAMPから除外し、その上で[Plugin Suppression]でAMPページ上で動いているプラグインの中から必要ない物を無効化しています。これにより、例えばElementorはAMPページでは読み込まれずに済みます。

AMP Plugin Supported Templates
質問者

質問です。この方法はAMPページというのが前提になってますし、先ほど「[Plugin Suppression]の欄にはAMPが許可していないコードが存在しているプラグインが表示」とも言ってましたね。ということは、通常テンプレートでサイトを表示する場合や、AMPが許可していないコードを含んでいないために[Plugin Suppression]に表示されないプラグインをAMPページ上で無効化して、さらなる高速化を測りたい時はどうするんですか?

KAZU

良い質問です。このケースでは[Plugin Load Filter]というプラグインを使うことでテンプレート別に有効化するプラグインを選択することが可能です。

Plugin Load Filter

 私は以前、AMPページ上で、この[Plugin Load Filter]を試用にしたのですが、[Plugin Load Filter]がなくてもGoogle Page Speed Insightで90点近くを取得できる様になったため、採用しませんでした。「AMPが許可していないコードを含んでいないために[Plugin Suppression]に表示されないプラグインをAMPページ上で無効化して、さらなる高速化を測る」という作業は行っていません。放置してます。

KAZU

ちなみに[Plugin Load Filter]を有効して、プラグインを無効化していくと500エラーに遭遇する場合があります。理由はケースバイケースですが、無効化されたプラグインが原因であることがほとんどです。Brandiaがサポートしているプラグインでは[LearnDash]が対応できていませんでした。

アーカイブページの表示件数と記事詳細ページのコンテンツ量の調整

 アーカイブページ上で、1ページに表示する記事数を多くしている場合、その分記事サムネイルが多く読み込まれることになります。これは良くありません。加えて、良く記事詳細ページに記事本文以外に関連記事などのサブコンテンツをたくさん入れるサイトがありますが、その分高速化の妨げになっていることを分かっていますか?

 アーカイブページの1ページあたりの表示件数は10件程度に抑えましょう。

 そして、記事詳細ページには最低限の情報だけを掲出することを心がけ、増やす場合でもその都度Google Page Speed Insightでテストすることを強くオススメします。

defer属性の付与

HTML5ではdefer属性を使うことができます。<script>タグにdeferを付与して記述すれば、JavaScriptの読み込みをHTMLパースを止めずに行い、HTMLのDOM解析が完了した後にJavaScriptを実行する様にするため、ページの表示が速くなります。

 Brandiaはdeferオプションを用意していますが、より細かく制御したい場合はプラグインを利用してください。

JavaScriptにDefer属性を追加
質問者

async属性も選択肢にあると思うんですけども・・・

 deferasyncもHTMLパースを止めずにJavaScriptのダウンロードを行える点では同じですが、deferが、HTMLパースが終わるまでJavaScriptを実行しないのに対して、asyncは、JavaScriptのダウンロードが終わり次第、JavaScriptを実行し、その間はHTMLパースが止まります。つまり、asyncはJavaScriptの処理を完全に後回しする物ではありません。

 加えて、asyncは記載通りに上からjavaScriptファイルが実行されることを保証しないので、jQueryが必要なファイルがjQueryより先に読み込まれ、エラーが出てしまうなど、WordPressとの相性も良くありません。

CSSの非同期化

JavaScriptにおけるdefer属性のようなものは、CSSでは用意されていません。しかし、CSSを非同期で読み込ませるテクニックは発見されています。

正攻法で行けば、<link>タグの属性rel="stylesheet"の値を"preload"にすればCSSファイルの読み込みを非同期にできます。しかしこの方法では、ブラウザのサポート状況がバラバラなため、まだ実装には向きません。またpreloadはページ上で重要なリソース3つまでを読み込むことが推奨されているので、その点でもWordPressには向きません。

 そこで採用したいのが、<link>タグのmedia属性を書き換える方法です。

HTML
<link rel="stylesheet" href="/path/to/my.css" media="print" onload="this.media='all'">

 この方法だと、media属性に"print"を指定します。このように定義すると、印刷用のスタイルシートと解釈され、HTMLパース時には実行されなくなります。HTMLパース完了後にonloadに記述したJavaScriptによって、media属性を"all"に変更するのです。こうすることで、HTMLパース完了後にCSSの読み込みが行われるようになります。

 ただし、この方法を無作為に実行すると、ページの読み込み時に一瞬カクツキが発生します。そのため、プラグイン側で導入できる物ではなく、テーマ側の仕事になります。Brandiaは、このオプションを用意しており、かつカクツキが発生しない様に、オプションを有効にした場合でも最低限のCSSはこの処理から除外される様に設計しています。

CSS非同期処理

CSSの@importの不使用

 @importを用いてCSSを読み込むと、通信速度が遅くなります。多くのテーマ開発者はこれを知っているので、@importを使っているテーマは見なくなりましたが、Google Fontsなどは内部で依然として@importを使っているため、注意が必要です。

 これを考慮して、最低限のフォントを利用することを心がける必要があります。

KAZU

ただし、嬉しいことにAMPページはGoogleフォントをAMPのコンポーネントとして扱い、読み込んでくれるため、AMPページ上ではあんまり気にする必要はありません。要するに特別対応されています。

CSSのセレクタの簡素化

 CSSの.parent > .childのようなセレクタについては、ブラウザが解析時に右から左へマッチングしていくため、これらのセレクタの数が多いほど(詳細度が深いほど)、CSS適用までの時間が長くなります。

 CSSの解析の流れを簡潔に説明しますと、まず.childというクラスを持つ要素を探し出し、その中から親要素が.parentである要素に絞ります。この場合つまり、.parent >.childよりも.childだけの指定をした場合、絞り込み作業を減らすことができるので、高速化に繋がるわけです。

 このような仕組みを理解して、CSSを書くときは必要以上に詳細度を深くしない様に心がけ、シンプルにクラス名一つで指定するのは良い方法です。

 もう1つ例を紹介します。例えば<ul>の子要素<li>は、ul liのように指定しがちですが、<li>にクラスを付与し、そのクラスに対してスタイルを記述した方が、表示の高速化に繋がるわけです。

CSS
//処理が多い
ul li {
}

//処理が少ない
li {
}

 実際、Google Page Speed InsightもCSS解析の時間を評価の対象にしています。

「JavaScript の解析、コンパイル、実行にかかる時間を短縮することをご検討ください。」と記載がありますが、CSSも当てはまります。
KAZU

だからといって、闇雲に詳細度を捨てるのも危険です。ページが複雑になるほど、詳細度はどうしても必要になるからです。ここでは、不必要に詳細度を深くするとCSS解析に時間がかかることを知ることだけでも十分でしょう。このことを知っているエンジニアが少ないので

不要なコード

 ソースコードに記述された文字数が多く、ファイルサイズが大きくなるほど、ダウンロードにかかる時間とブラウザが解釈する時間が長くなるため、ページ表示速度は遅くなります。そのため、不要な記述はできるだけ削除する必要があります。

  • コメントの削除
  • 改行だって文字列です。出力されるHTMLも縮小しましょう。
KAZU

出力されるHTMLの縮小については、インラインJavaScriptは避けるべきです。不具合が起こる可能性が排除できないためです。Brandiaは縮小機能を提供していますが、このことからインラインJavaScriptは対象外にしています。

ファイルの縮小

 同様に、外部ファイルも縮小すべきです。大抵のライブラリはmin.js / min.cssを用意しています。それらを意識して読み込む様にしてください。

 これらも、Google Page Speed Insightの評価項目です。

JavaScript ファイルを最小化すると、ペイロード サイズとスクリプトの解析時間を抑えることができます。
CSSも同様に縮小が必要です。

画像の圧縮

 画像はページの8割の容量を占めます。したがって、最重要課題です。画像を圧縮するために下記の作業を行いましょう。幸いなことにプラグインを使えばこの作業は簡単です。

  • EXIF情報など不要な情報を削る
  • 最適なファイル形式を選ぶ
  • 画像サイズは大きすぎず、小さすぎず

画像の遅延読み込み

 画像の遅延読み込みも同様に重要な課題です。これまで、ブラウザはページの読み込み時にすべての画像を読み込む様になっていました。

 HTML5になり,loading=”lazy”が追加されたため、HTML5の機能だけで、ファーストビューの外にある画像の遅延読み込みを可能にすることができる様になりました。

HTML
<img src="hoge.png" loading=”lazy”>

 しかし、IEとSafariがサポートしていません。 

 この機能はWordPress5.5でコア機能に導入されたので、WordPress最新版を利用の方はすでに適用されています。IEとSafariでも遅延読み込みを導入したい場合はプラグインの導入が必要です。 

その際は、コアの遅延読み込みを無効化する必要が出るかもしれません。下記のコードで可能です。

WordPress
/*
 * Remove wp_lazy_loading.
 * @since 5.5.0
 */
add_filter( 'wp_lazy_loading_enabled', '__return_false' );

WebPフォーマットを採用する

 WebPフォーマットはGoogleが推奨する次世代の画像フォーマットです。IDEA HACKもWebPフォーマットデ配信しており、下記のメリットがあります。

  • PNG / JPEGと同じ質で半分の要領
  • PNGの様に簡単にPC端末にダウンロードできないので、盗作をめんどくさくできる。完璧に不可能にするわけではないけれども、多分エンジニアでない限り盗作は無理。もちろん、スクショされたらどうしようもないですけども・・・・

 デメリットもあります。

  • サポートされていないブラウザがある
  • そのため、PNG / JPEGの画像も必要で、結果的に必要な画像フォルダの容量が増える

 ただ、Google Page Speed Insightに評価項目がある以上、デメリットを理解した上で導入するしかありません。

JPEG 2000、JPEG XR、WebP などの画像フォーマットは、PNG や JPEG より圧縮性能が高く、ダウンロード時間やデータ使用量を抑えることができます。

まとめ

 いかだでしたでしょうか?サイトの高速化は非常に大変だとは思いませんでしたか?しかも、「これだけやれな劇的にサイトが高速化される」という魔法も存在しません。むしろその逆で、Googleはこれらのうちのいくつかをしていないだけで低評価扱いしてきます。

 しかも、2020年5月28日にGoogleから「2021年からコアウェブバイタルを検索ランキングの要素に含める」 の話があったため2021年以降はWordPressの高速化への意識はさらに必要になると思われます。

 でも安心してください。IDEA HACKはこれをクリアしてるWordPressテーマBrandiaを販売していますし、それを支える最高のWordPressホスティング環境の提供も、2021年最初を目処に計画中です。

 高速化に時間をかけるくらいでしたら、私達に任せていただけませんか?もしよろしければ、試してみてください。

 この記事を読んだ感想や、わからない点があれば、コメントからお願いします。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です