ワードプレスのページスピードを改善する方法

ワードプレスのページスピードを改善するプラグイン

つい最近までテーマの作成をしていたものですから、ちょっとそれに関連したページ作成に関する話題です。

ワードプレスのページって遅い印象がありませんか? 

SEOにおいてもページ速度がその要素に含まれていますが、特にモバイル端末を使っている場合、あんまり遅いとページから離れてしまいますよね。

これをどうにか改善できないものかと考える運営者は多いでしょうが、原因を特定して改善するのは実際なかなか難しいものです。

ワードプレスの性質上、特にリポジトリのテーマを利用する場合、ページ速度を改善するのは非常に難しいということは知っておく必要があります。

また、画像サイズ関連はプラグインである程度解消出来ると思いますし、キャッシュ系プラグインも効果に大きく差が出ますので省きます。

そう言う僕自身は面倒で画像やキャッシュ系プラグインや「.htaccess」による圧縮設定など、全然着手していません_(┐「ε:)_

ページスピードが落ちる原因の大半はプラグイン

ワードプレスではページがロードされるまでにも、テーマやプラグインのロードをしたり、使われるべきテンプレートを選択したり、といった処理を行うためのフック(処理を登録できる場所)が用意されていて、各フックにおいてワードプレス自身の他、テーマとプラグインがそれぞれに処理を登録しています。そして、最終的に準備が整ってから「よし、HTMLを書くか」といった感じで、ページが出力されています。

この時にページを構成しているのが、誰でも何となく耳にしたことがあるであろうHTML・CSS・JavaScriptといったコード達です。そして、CSSやJavaScriptといったはページのデザインを定義する役割を果たしていますが、これらはページに出力されてからブラウザ(FirefoxやChromeなど)に反映されるまでに時差があります。実際にはこれらに加えて、画像などのロードもページのロードに影響します。

テーマの作者はデザインを重視していると思いますが、実際はページ速度もある程度気を配りながら作成しているものです。ただ、それでもページが遅くなってしまう理由は、ページ速度に影響を与える追記的な要素が、プラグインにより出力されていることが挙げられるのです。

例えば、当サイトではテーマ「Nora Ace(仮)」を使用していますが、当サイトで使用するとページスピードインサイトでのモバイル評価は最初は50前後だったのですが、プラグインの切り替えなどによっては20近くまで落ちることも有り得ます。フロントエンドに殆どプラグインによる影響が出ていないデモサイトのモバイル速度を見てみると90程度の評価となります。この速度低下の要因として挙げられるのが、「Jetpack」から「jetpack.css」や「social-logos.min.css」といったCSSファイルがロードされていることなどです。これらは「Jetpack」の設定により、ページに出力される要素に対してスタイルを施すためのもので、例えば、現段階でページ下部に出力されている「SNS」などのシェアアイコンに適用されています

標準的にはテーマがこれらを出力する役割を担っているのですが、ワードプレスの性質上、プラグインからも例のような出力が可能となっているので、プラグイン選びはある程度慎重に行う必要があるのです。

CSSの出力がページのロードを阻害する要因として大

CSSはページのHTMLをデザインを定義する要素ですが、各CSSファイルのロードはページ速度に強く影響します。実際にページとか作成している方はご存知でしょうが、まぁ思っている以上に遅くなるんです。実際には出力されていないHTML要素に対するCSSが追加されるだけで、「勘弁してくれ」と言わんばかりに遅くなります。

メジャーなプラグインとしてはやはり先にも挙げた「jetpack」でしょう。機能ごとにCSSを出力していますので、個人的には「1つにまとめてくれ」という心境です。実際には使用していないにも拘わらずCSSが出力されているケースも多いので、ユーザーも多いことから「Jetpack」によりページが遅くなっている可能性は結構高めです。HTMLに「jetpack.css」が出力されているか見てみてください。

この他、プラグインによりいくつのCSSが読まれているか一度見るのも良いかもしれません。

JSは関係ないのか?

前の見出しではCSSを挙げましたが、JavaScriptも速度的な要因としては小さい気はしますが、ワードプレスでは結構大きな要因になりかねない場合も考えられます。

その理由として、ワードプレスでは標準的に依存関係を作ってロードできるようになっていますが、問題はプラグインの殆どで使用されているJavaScriptがjQueryを使用して出力されている点です。まぁjQueryはプラグインも豊富なので便利なのですが、ワードプレスのプラグインにもよく利用されています。そうすると、jQueryをグローバルに定義することで各プラグインによるjQuery依存したJavaScriptが使用する形になるため、非同期にロードができない状態になっていることが考えられます。これが結構厄介なのです。

非同期で使用するには、少なくともjQueryを使える環境であることをJavaScriptファイル内で定義していてもらう必要があるのですが、流石にこれはワードプレスプラグインなどの作者によるファイルですので、これは自分でPHPやJSをある程度書けないと対処出来ないので、プラグインとJavaScirptはセットになってしまっています。たくさん出力されているのであれば、一度全てJavaScriptを非同期で読ませてみて、JavaScriptがちゃんと読まれるか確認してみると、jQueryへの依存具合がよく見えると思います。

リポジトリのテーマでのページスピード改善が難しい理由

冒頭の最後に書いた話になりますが、その理由に先に触れておきます。

まず、リポジトリにアップロードする際のテーマの基準があるのですが、実はプラグイン領域に該当する特徴・機能は認められません。

プラグイン領域の機能ならプラグインに任せるべきだろ、と単純に捉えても良いのですが、アップロードするプラグインには、「ページ速度をなるべく害さないようにする」といった基準が無いんですね。「フロントエンドのコンテンツに影響するスタイルはstyleタグでフッターに出力しろ」といった簡単なルールが欲しいところ。

でも、「じゃ、コンテンツを出力するプラグインを使わなければ良いんじゃない?」と誰もが思ったことでしょう。

ですが、SNS関連(Twitterシェアボタンの出力など)はプラグイン領域と定められており、リポジトリにアップロードするテーマ側では出力してはいけないルールが有るのです(今はテーマ基準が変わっているのか知りませんが、少なくとも僕がテーマ「ShapeShifter」を作成していた時はそんなルールが有りました)。そして、そのボタンのスタイルを定義するのに殆どのプラグインがCSSファイルをロードします。

SNSなんて今やほぼ全てのウェブサイトにボタンが付いていそうなものですが、アップロードするテーマでは制御できないんですよ。つまり、SNSボタンを含んだデザインのテーマをアップロードしようとすると、それに応じたプラグインも合わせて作成することが必要になってくるんですよ。でないとスタイルを統一出来ませんし、個別のプラグインだとプラグイン側の意思でCSSファイルをロードされてしまうのです。

メジャープラグインによるページスピード悪化への対策

テーマやプラグインを作成する時に、関係性がまったくない他のプラグインなんていちいち記にしないと思いますし、僕自身もあまり気にしたくありません。ワードプレスのプラグインは、リポジトリにアップロードされているものだけでも非常に数多く存在しますのでキリがありませんが、人気でよく使われているプラグイン数件程度であれば、それに応じたサポートをした方がいい場合もあります。

ページスピードに関しては実際にフロントエンドに影響するプラグインだけを気にすれば良いので、一般的なブログやコーポレートサイト、ポートフォリオなどを想定すると「Jetpack」や「Contact Form 7」、ECサイトなら「WooCommerce」、フォーラムやSNSなら「bbPress」や「BuddyPress」などが予想されます。

非常に便利で強力なプラグインなんですけど、それらにより出力されるタグがページスピードに影響することに変わりはありません。実際にそれらによるコンテンツが使用されているページにて、コンテンツのスタイルなどを定義するために出力されていれば良いのですが、プラグインコンテンツが何も出力されていないにも拘わらず、CSSとJSがロードされている場合もあります。(というか、殆どのプラグインでそうなっていると思います)

コンテンツが出力される条件がある程度決まっているのであれば、各プラグインによって方法は異なりますが、ワードプレスの一般的なCSSとJavaScriptをエンキューする方法が使われている場合、PHPコードをテーマの「functions.php」に少し書くだけである程度制御出来るんですよ。

なぜ制御する必要があるのか?

各プラグイン自身が管理・制御してくれれば非常にありがたいんですが、プラグイン作者側の意向もあります。そう作られているのです。「jetpack.css」なんてコンテンツが何も出力されていないにも拘わらず、ずっと出力されていることもあります。フロントエンドに出力される「jetpack」コンテンツを使っていない人からすれば、嫌がらせ以外の何物でもないですよ。

「最終的にエンドユーザーがプラグインを作るなり、子テーマ作って編集するなりしてくれ」といった感じで託されている感がありますが、ワードプレスを使う敷居はそれ程高くないため、ブログを始めるまでって別にコード書かなくても出来ます。ええ、実際そんな編集できない人だってたくさんいるのです。というか、僕もそういう状態から始めましたが、ある程度勉強していくと、実際ちょっとした修正で制御できることも分かってきますので、出来る限りページの負担も考えてほしいもの。

プラグインにより出力される部分的なコンテンツは、ほぼ確実にワードプレスのフックが使われています。中にはJavaScriptによって生成されている場合もありますが、問題はそこではなく、それらのスタイルを定義するCSSの存在です。部分的なコンテンツであるにも拘わらずlinkタグを使ってHEADタグに出力されるケースが非常に多いのです。これによりページ速度は一気に低下していきます。

CSSのファイルサイズだけでなく、その数が増えるだけで遅くなるので、気をつける必要があります。

ウィジェット出力とショートコードをターゲットにする方法

個人的に「Nora Ace(仮)」でも使用している方法の1つで、上に挙げたプラグインを対象にしています。先に書いておきますが、万能ではありませんので気休め程度です。あと、ここはちょっとコード編集に関する話になります。ワードプレスでのプログラミング要素が少し入る話になりますので、興味ない場合はスルーしてください。

では、ウィジェットの出力を検知する方法は色々ありますが、フィルターフック「widget_display_callback」を使うことをオススメします。ウィジェットを配置して出力される前にウィジェットのインスタンスを編集できるフィルターなのですが、これによる第一引数がfalseになっているとウィジェットが出力されない状態になっており、「Widget Option」などのウィジェットの出力条件を定義するプラグインでも恐らく使われていると思います(コードを読んだことはありませんので間違ってたら申し訳ない)。このフックでは第2引数でウィジェットクラスのインスタンスが渡されますので、これを使ってウィジェットのクラス名を取得できますから、このフィルターフックによりページに出力されるウィジェットのクラス名を全て取得できます。get_class( $instance )でOKですので、これによりプラグインによるウィジェットの出力を検知できるようになります。

例えば、「WooCommerce」のウィジェットなら「WC_Widget_」で始まっています。そんな具合に各プラグインがそれぞれプレフィックスが使っている筈ですから、それらの特徴によりどのプラグインとの関連性を判別することが出来ます。

次にショートコードですが、こちらはフィルターフック「do_shortcode_tag」を使うことをおすすめします。第2引数としてショートコードタグ名が渡されますので、これにより実際にそのページにて使用されているショートコードが分かります。ショートコードはコンテンツ内で使用される場合が殆どですが、「do_shortcode」という関数を使うことでウィジェットのテキストの他、直接どこにでも出力してしまうことが出来ますので、プラグインがどのような形でそのショートコードを使用するか分からないため、検知するには「do_shortcode_tag」がオススメなのです。

上記の方法でウィジェットとショートコードは検知できるようになったと思いますので、あとはこれをCSS・JSの出力に反映させます。

アクションフック「wp_enqueue_scripts」などで、エンキューを取り消す関数「wp_dequeue_style」や「wp_dequeue_script」を一度コールしてそのままエンキューされるのを一旦取り消します。そして、上記の方法で検知した結果をもとにフッターで再び同じハンドルを「wp_enqueue_style」と「wp_enqueue_script」でエンキューすれば無駄は減ります。ええ、ちょっとした制御です。

ただ、これからはブロックエディタが主流になっていきますので、ブロックコンテンツなども増えていくことが予想されますから、それらのコンテンツに対するスタイルが出力されるようになるとちょっと何とも言えないです。

ワードプレスでのページスピード改善の基本

まず、不用意に訪問者が閲覧できるページに何かを出力するプラグインを使わないことが第一ですが、便利なものだと使いたくなる心境も分かります。評価の高いものもなんか使ったほうが良いのかなと思って流されちゃいがちです。コードの編集が出来るのであれば、ある程度上に書いたような方法の他、色んなやり方があることでしょう。ヘッドレスWPという形にしてしまうのも良いかもしれません。

ただ、まぁあくまで標準的なテーマとプラグインで改善する場合、悪化した時に手を伸ばしてしまいそうになるのがキャッシュプラグインですが、スタイルなどが崩れてしまう可能性が結構高いです。昔「なんじゃこりゃー!」という状態になった記憶がありますので、僕は二度と触れなくなりました。「.htaccess」が編集されるのも嫌ですので、個人的にはあまりオススメしたくないものです。

テーマ作成ではCSSとJSはなるべくコンパクトにして1つにまとめる

CSSファイルとJSファイルはそれぞれ1つで十分です。これらに全てをまとめて書いてしまうのが理想で、実際に静的なウェブページだとそう書くのが基本ではないでしょうか。また、JavaScriptはjQueryに依存しないように書くことで、非同期で読ませても問題がなくなりますので、JavaScriptファイルでjQueryを使っているなら移行してみるのも良いかもしれません。

ファイルを纏めるには、個人的にWebpackを使うのがオススメです。これで出力するCSSファイルもJSファイルも予め1つにまとめることが出来ますので、めちゃ便利です。ただ、JavaScriptを読まないようにしている場合も考えられますから、CSSファイルを1つは用意して、代替的にnoscriptタグで囲っておくと良いでしょう。

あと、ファーストビュー(モバイルで最初に表示されるコンテンツ部分)のスタイルだけをインラインでHEADタグ内に書いて、残り全体のスタイルを1つのファイルに纏める方法も良いですよ。

テーマ「ShapeShifter」では使っていませんでしたが、「Nora Ace」では使っています。また時間がある時に「ShapeShifter」も編集していこうと思っていますが、追いつかぬ。

プラグイン作成ではCSSはなるべくインラインで

このページで既にしつこく書いたことですが、<link href=”SRC”>ではなく、<style>CODE</style>という形でまとめて出力してほしいということです。

もうHEADタグで大量にCSSファイルをロードさせるのは止めて欲しいと切実に願っております。

せっかくページ速度を気遣ったテーマに仕上がっていても、プラグインに阻害されるのはなかなか悲しいですから。

古代兵器「Magic Inliner」

すみません、僕が随分前に作ったプラグインで、CSS・JSをロードするタグがワードプレスのエンキューで出力されるのを、インラインでフッターに書き出すプラグインです。キャッシュ系プラグインよりはスタイルなどが崩れないように意識して書いたつもりです。CSSで使用される関連パスもある程度保管される筈ですので、サードパーティ製で画像などを使用する場合などでもロードしてくれるように書いていたと思います。

設定項目は1つもありません。ただプラグインを有効化するかどうかだけです。

どうしてもページスピードインサイトなどで赤信号が出るようなら最終手段として使ってみてください。データも何も保存しませんし、「.htaccess」を編集するような機能もありません。100%の保証はできませんが、ワードプレスの設定に変更を加えるようなコードは一切ありませんので安心してください。

効果が見られなかったら無効化すればいいだけのプラグインです。

ちなみに「Magic Inliner」の評価が最低なのは、メンテナンスすることが殆ど無いために僕自身が付けている評価ですので、その点も心配しなくて大丈夫です(笑)。ひっそりと最近アップデートもしましたし。

管理画面の「プラグイン」->「新規追加」->「Magic Inliner」で検索すると出てくると思いますが、本当にそれだけのプラグインですし、僕自身が存在を忘れているくらいのプラグインですので、更新は期待しないでください。

1件のピン

コメントを残す

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください