速度が大事
Googleがサイト評価の指標としてサイトの速度を採用したのは記憶に新しいです。
SEOの面から考えてもサイト速度は無視すべからざる項目となっています。
またSEOを抜きにしても、サイトが重鈍であるというのは、せっかくアクセスしてくれたユーザの離脱を招くものであり、サイトの価値を下げる要因になり兼ねないです。
そこで今回はwordpressを使った際に、サイトの速度アップに参考になるであろう方法を紹介したいと思います。
速度改善の項目
今回はgoogleが提供しているPageSpeed Insightsを使った場合に、修正勧告される項目
スクロールせずに見えるコンテンツのレンダリングをブロックしている JavaScript/CSS を排除する
に焦点を当てたいと思います。
またブラウザ側ではchromeのデベロッパーツールにて数値の確認を行いたいと思います。
cssファイル・jsファイル等の読み込みに関して
headタグにjsライブラリや広告関係スクリプトの読み込み、cssの読み込みを行っていると大抵この勧告が出るでしょう。
これらの弊害としては、ファイルが読み込まれるまで他の処理がストップするという点にあります。結果的にページの表示が遅くなる原因なのです。
解決方法としては、jsファイルであればasync等のオプションで非同期ローディングにする、footerで読み込ませる等が挙げられるが、ライブラリ等は読み込みのタイミングを制御するのが、難しい場合もあります。
またcssファイルは通常非同期では読み込めないので、インライン記述による解決が提案されることが多いです。 CSSファイルの場合、全体を遅延読み込みをするとサイトの見た目に対して致命的な影響を与えかねないです。
すくなくとも見えている範囲のcssだけは読み込む必要があります。
PageSpeed Insightsでの説明でも「インラインにしたら？」と言っていますが、インラインにすると記述箇所が分散して、開発がとっちらかるのが嫌で、いまいち踏み切れない人も多いのではないでしょうか？
そこでjsファイルやcssファイルに細工を施し、wordpressなりの方法を提案してみたいです。
テンプレートファイル機能の活用
wordpressでサイトを構築する場合、テンプレートファイルを使うことが多いかと思います。この仕組みをcssやjsファイルにも適応する方法です。
主要なテンプレートファイルにはそれぞれ専用の関数が用意されていますが、自作のテンプレートファイルを読み込む為に、get_template_part()を使うことができます。
つまり任意の位置にphpファイルを埋め込むことが可能なのです。
jsのコードの場合、styleタグで前後を囲うことで、埋め込み用のphpファイルとすることができます。 またcssもscriptタグで前後を囲うことで埋め込み用のphpファイルとして扱うことが可能です。
そうして作ったphpファイルをget_template_part()で必要な場所に埋め込みます。
このようなローディングを
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<title>テストページ</title>
<link rel="stylesheet" href="http://pecodrive.heteml.jp/1bit/wp-content/themes/1bit1/style.css">
<script src="https://pecodrive.heteml.jp/1bit/wp-content/themes/1bit1/js/jquery-2.1.4.min.js" ></script>
<script src="https://pecodrive.heteml.jp/1bit/wp-content/themes/1bit1/js/jsfile01.js" ></script>
<script src="https://pecodrive.heteml.jp/1bit/wp-content/themes/1bit1/js/jsfile02.js" ></script>
<script src="https://pecodrive.heteml.jp/1bit/wp-content/themes/1bit1/js/jsfile03.js" ></script>
</head>
<body>
<img src="https://pecodrive.heteml.jp/1bit/wp-content/themes/1bit1/img/img01.jpg">
<img src="https://pecodrive.heteml.jp/1bit/wp-content/themes/1bit1/img/img02.jpg">
<img src="https://pecodrive.heteml.jp/1bit/wp-content/themes/1bit1/img/img03.jpg">
</body>
</html>このように埋め込みにする形(cssとjsファイルはそれぞれphpファイルにしている)
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<title>テストページ</title>
<?php get_template_part("style"); ?>
<?php get_template_part("jquery"); ?>
<?php get_template_part("jsfile01"); ?>
<?php get_template_part("jsfile02"); ?>
<?php get_template_part("jsfile03"); ?>
</head>
<body>
<img src="https://pecodrive.heteml.jp/1bit/wp-content/themes/1bit1/img/img01.jpg">
<img src="https://pecodrive.heteml.jp/1bit/wp-content/themes/1bit1/img/img02.jpg">
<img src="https://pecodrive.heteml.jp/1bit/wp-content/themes/1bit1/img/img03.jpg">
</body>
</html>概念としては図のような感じになるかと思います。
jQueryなどのライブラリもこのようにPHPファイルとしてラッピングしてしまうことで、get_template_part()をつかって埋め込むことができます。
(※jQueryはMITライセンスなので大丈夫だと思いますが、ライブラリが採用しているライセンスによっては拡張子の変更やタグの追加だけでも、ライセンス違反になるものがあるかもしれないので、良く確認する必要があること、自己責任でお願いしたいです。)
ブラウザ上の計測でどれだけ改善されるか
実際に見てもらえばわかりやすいかと思います。chromeのデベロッパーツールのNetWorkでの計測結果です。
上の画像がcssファイル1つ、jsファイル3つ、jQueryライブラリ(圧縮)1つをlink、spriptタグで読み込んでいる通常のローディング方法(以下[ロード])で、 下の画像が同じファイルをテンプレートファイルで埋め込みした場合(以下[埋め込み])の結果です。
[ロード]の場合
最初のリクエストでhtmlがレスポンスされ、そのあとにcssファイル、jsファイルのリクエスト・レスポンスが立て続けに起こっていることが判ます。
cssファイルは非同期通信でのリクエストではないため、このことがjsfile01～03のリクエストを遅延させているのも良く分かます。
jQueryファイルは圧縮されているものを読み込ませていますが、それでも80kB位ありますので、それなりにContent Downloadが発生しています。
最終的にすべてのリクエストが得られるまでに887ms掛かっており、ページ読み込み完了までには1.38s掛かっています。
[埋め込み]の場合
一方[埋め込み]は、リクエスト・レスポンスが一本しかないです。最初のリクエストでcss、jsファイルを埋め込んでレスポンスしていますので、一回のコネクションで終了しているのです。
jQueryなどを含んだ為、初回レスポンスの容量は80kBを超したが、リクエスト完了までに603msと[ロード]に比べ300ms程度も速度が改善しています。
またページ読み込み完了までに701msと、[ロード]に比べ600ms以上の改善がされています。
これは[ロード]の場合、cssファイルの読み込みを待ってからじゃないとレンダリングが開始できないのに対し、[埋め込み]は初回のレスポンス後すぐにレンダリングが開始できることによる差です。
場合によっては1秒以上の差がつく可能性もあります。
実際にPageSpeed Insightsで計測した場合には以下の様に点数が改善しました。
埋め込み側には「スクロールせずに見えるコンテンツのレンダリングをブロックしている JavaScript/CSS を排除する」の修正勧告が無くなっているのが判るかと思います。
デメリットの整理
この方法は速度改善が出来る点においては有用だと思いますが、デメリットも存在します。
埋め込む為、キャッシュが効かないです。
ブラウザキャッシュは速度改善につながるのですが、この方法を用いると、当たり前だがjsファイルやcssファイルのキャッシュが効かないです。
どのくらいの頻度でキャッシュ活用がされるかに関しては、そのサイトのユーザのアクセス状況によるものなので、何とも言えないです。
新規アクセスが多いサイトなら、キャッシュよりも埋め込みの方が利点が多いかもしれないですが、リピーターが多いサイトではキャッシュの方がいいのかもしれないです。
サイトのアクセス状況をかんがみてどちらがいいのかを検討する必要はあるかもしれないです。
レスポンスを一つにまとめることになるので、レスポンスボディは重くなる
これは上記のキャッシュの件ともかぶるが、本来キャッシュで済んでいたファイルを埋め込みしていることになる場合もありますので、明らかに無駄な容量になってしまいます。
ただ、数十kb～百数十kb程度の世界では、容量増よりもコネクション数の増大の方が速度に対して負荷がかかるのではないかと思っています。
ファイルが増える
デメリットとなるかどうかは、サイトの制作状況に依るだろうが、管理するファイルが増えることになるので、やはり幾分か手間がかかると言えるでしょう。
@MINOは部品分けでのサイト構築の方がメリットがあると思う(部品の再利用なども含め）が、ファイルが分かれることで開発しにくくなる人もいるかもしれないです。
まとめ
デメリットも把握してもらった上ではあるが有用な場合もあるのではないかと思います。
この方法では動的に埋め込むファイルを変えることが出来ることや、ajaxとの相性も意外といいことはメリットとして挙げられるでしょう。
あまり正規なやり方とは言えないですが、実際に速度改善がなされるので、場合においては方法として検討してもいいのではないかと思います。
