Google PAGESPEED INSIGHTS との闘い
いつものように Google Search Console を見ていると、「CLS に関する問題: 0.25 超（パソコン）」 などというものに気がつく。たしか以前にも見た気がする。それなりにチェックしてみたものの、対策というものが、何をすればいいのかよくわからないものだったのではなかったか。
今回、リンクをたどっていくと、その時にはなかったと思うのだけれど、PAGESPEED INSIGHTS なるものが出てきて、対象のページの表示されるスピードチェックなんてのが実行されてその結果が表示された。結果は黄色いレンジで 84 なんて数字を示している。ちなみに、90 以上がグリーンゾーンになっている。そのページのスクリーンショットをとっておけばよかったのだけれど、と思ったのは後の祭りで。
ページスピードをより速く改善するための処方もいろいろと出て書いてある。提示されているものには、すぐに取りかかれそうなものもいくつかありそうだ。
使っている背景画像などは全てサイズダウン済みのはず・・・、と思ったものの確認してみると思い違いも甚だしく、多くの画像がオリジナルサイズのままだった。と、これは、かなり違うことになるはず、と片っ端からサイズダウンさせていく。jpg はあまり変わらないけれど、png の方はものによると元のサイズの 20% 以下ほどまでサイズダウンできる。
そしてお次は、と・・・。
HTTPリクエストを減らすことは以前から頭に入れていて、関連する画像はなるべく一つにまとめるとかは、当然のこととして普段からやっていることではある。今回はもう一歩進めて画像の BASE64 化などということをしてみようかと。
背景画像の BASE64 による文字列化でリクエストを減らす
画像は通常、html、css、javascript において、そのアドレスを指定し、HTTPリクエストにより画像データをダウンロードして表示させる。それを、BASE64 処理によって画像データを文字列に変換させておき、その文字列を指定しておくことで、HTTPリクエストによる画像データのダウンロードをすることなく、その画像を表示させることができるとのこと。これをすれば単純に、HTTPリクエストを減らす事ができると。
実はこのことは以前から知っていたこと。というのは、なんとかリクエストを減らすことができないだろうかと考えていた時に、php でファイルを読み込むことができるのだから、画像ファイルも php で読み込んでデータとして html のようにクライアント側にまとめて送信することは出来ないものだろうか？などと考えて探してみた時に、あっさりとこの BASE64 に変換する方法にたどりついたというわけ。
まぁ、それはいいとしてこの BASE64、良い面ばかりということでもなく、デメリットもある。BASE64 処理によるバイナリデータの文字列化は、そのデータサイズが約 1.3 倍となってしまう。送信するデータの量が増えてしまうわけだ。まぁ、あと、実際にやってみて感じたことは、html にBASE64 文字列を入れると、そのデータのあまりの長さにコードがとても読みづらくなるということ。javascript ファイルにしても然りで、うっとうしいことなんの。javascript の場合は最後の方の部分だけとかにした方がストレスがたまらなくて良さそうではある。
リクエストは減らすことができるけれど、それぞれの画像データの量は1.3倍になってしまう。と、ふと、考えが浮かんだのだけれど、新しい画像フォーマットである webp を使ってということができないのだろうか。せっかく webp にて画像サイズを圧縮することができたのに、また BASE64 でデータ化することで、データの量が元に近く戻ってしまうというのもなんとも妙な感じではあるのだけれど、それにて元からデータ量をそんなに増やすことなく、リクエストの数は減らせるということになるのだから、それなりに説得力はあるように思う。
webp の BASE64 化ももちろん可能であるわけで。php でのエンコードする関数も、ちょっとよけいな手間がかかるけれども、 jpg、png と同じ関数が使えた。
ではあるのだけれど、webp 化は、Mac においての対応状況もよくわからなかったので、ここではひとまず置いておいて、最後の次なる一手として、考えていたことを全てやった後に試してみようということにして、それはあらためてページを変えて書くことにしようと思う。
と、いうことで css の画像の BASE64 化にとりかかる。
BASE64 化する画像は、多くのページで共有する画像だけにとどめる。特定のページだけでしか使わない背景画像とかは、url 指定の場合はそのスタイル設定の対象が存在しなければ画像のリクエストも発生しないはずだと思うが、BASE64 の文字列での指定は、当然のことそのシートが読み込まれれば必ず一緒に転送される。必要のない画像の 1.3 倍のデータが常に一緒についてまわることになってしまう。
さて、どうやろうか！
スタイルシートのリクエストがあった時に、php で BASE64 に変換して返すか？と、いう方法もある。この方法だと、元のスタイルシート( CSS ファイル ) には何の変更もいらないし、訂正やらチェックなどするときに今まで通りで見やすくやりやすい。けれど、これだとサイトアクセスがあるたびに変換することになる。元々、BASE64 に変換させるのは、リクエストを減らして少しでもページの表示スピードを速くするためにやっていることなのに、アクセスの度に変換する処理を入れることは、少なからずリクエストを減らす効果を減じてしまうことになるのではなかろうか。後々のメンテナンスのことを考えると、この方法は良さそうではあるけれど、やはり、少しでも表示スピードを速くすることに長けた方法を選択したい。
で、やはり、あらかじめ変換処理してあるスタイルシートを読み込ませることにする。
予定では、スタイルシートを読み込んで、その中の画像を BASE64 に変換、そのデータをスタイルシートに書き込み保存する、というものをつくるはずだった。しかるに、とりあえず変換する部分のコードを書いて試しにやっていたら、画像の数がそんなに多くないということもあって、テストで変換されたデータをスタイルシートに書き込んで、ということを何回か繰り返していたら、それでことが足りてしまったのであしからず。
それが以下のコード。同じフォルダにある画像を指定すれば、BASE64 に変換してくれるだけの php。”,”で区切ってリストすれば一度に複数も可。
ちなみに BASE64 文字列での画像の指定の仕方はというと、別段、なんら難しいことはなく、以下のごとく。
画像の url が指定してあったところに、
data:image/png;base64,/
という指定された文字列に変換された BASE64 文字列データをくっつけて指定するだけのこと。javascript においても全く同じ。
指定文字列の image/png など画像の種類を指定する部分は、それぞれの画像によって入れ替える。jpg、png、gif 等。ただ、やっているときにうっかり jpg 画像なのにこの部分の訂正をせず png になっていたことがあったが、 jpg 画像はしっかり表示されていたりした。まっ、どうでもいいか。
スタイルシートにおいては、コメントアウトしてある行も削除してサイズダウンさせた。
これらだけでもかなり効果が期待できるのでは！と期待しつつ Google Search Console へのリンクをクリックしたのではあるけれど・・・。
結果は 89 。まだイエローゾーン。くっ～～！
体感的に、んっ！と感じる具合に速くなった気はしたのではあるけれど・・・。
ちなみにサーバーは、ロリポップのスタンダードプランだすっ！
jQuery の使用をやめてロードさせないようにする
さて、お次の手はと・・・。何をすれば良いのだろうか？
推奨の項目に目を通していると、jquery 関連で2つのファイルを読み込んでいるのだけれど、この2つのファイルの読み込みを無くすと効果がありそうだ、と。
この部分は前から考えていたことなのだけれど、面倒で手をつけていなかったことでもあり。jquery を使わないように書き直すかな。
と、いうことで、jquery に依存する javascript を書き直すことに。対象は ２ファイル。テーマの jquery ファイルと、それと自作プラグイン、prism ハイライター用の補助的 jquery ファイル。ちなみに、prisum 本家 javascript は jquery 依存では全く違うのでありがたい。さぁ、はたしてどれほどの効果があるだろうか？
この作業は結構手間がかかる。時間もかかる。かかった手間だけの効果があればよかったのではあるけれど・・・、さて、結果はというと。
えっ！たったの1ポイント。あれだけ手間が掛かったのに！でも、かろうじてグリーンゾーンに入って 90 。ふ～っ！
こんなものでしょうか。なかなか難しいものです。
時間をあけて 3度ほど試してみて同じ結果だったので誤差というものもないようだ。
でも、とりあえずこれで javascript もプレーンな状態にすることができたし、前からわかっていたことだけれど、先の事を考えるとやはりライブラリ等には極力依存しない方が良いということなんじゃないだろうか。
ふと、思ったことなのだけれど、メインコンテンツがアニメーションで透明度を変化させて現れるようにしているのは影響があるのだろうかと。このアニメーションの設定は、delay = 0.5s 、duration = 3.0s になってる。試しにそれを delay = 0.2s 、duration = 1.5s に変更してやってみた。
結果はもしやと思ったとおり 1 ポイント良くなった。あれ～？
元々、Search Console に表示されていたのは、「CLS に関する問題」であった。けれど、どの結果を見てみても、その CLS ( Cumulative Layout Shift ) に関しては全く問題はないようだ。一体何をすればよいのだろうか？このアニメーションで表しているメインコンテンツがやはり問題だったのだろうか？
ちなみに単純に考えて、コンテンツの量が少なければ速くなるだろうし、どれくらいの数値が出るのだろう？と期待して試してみると、
と、思った通り少し良い結果となる。このページは字数も多少少なく、prism.js が変換する <pre><code> ブロックも2つしかなく、そしてクラシックエディタで書かれた投稿である。それも多少、影響しているような気がする。
ページ下部の背景画像を Ajax で取得
さて、と。
画像のロードに関してはもう少し詰められるかも。
ページの下の方にある、そんなに重要度の高くないアイコンなどの画像。それらの画像たちも BASE64 化しているわけなのだけれど、下のほうにあって、ページが表示された時には見えない状態にあるので、ならばスタイルシートに指定してアクセスされた時に一緒に読み込ませる必要など、通常ならば無いわけなのである。であるからして、それらの画像の BASE64 データをひとまとめにして、javascript によって Ajax で取得させよう、というこんたん。
まぁ、これは「 O’REILLY High Performance JavaScript 」に書いてあった手法。後ほど出てくる BASE64 データをつなぐデリミタとして使う chr(1) という文字もこの本にて学んだこと。
と、いうことでまずは、javascript から呼ばれてそのページに必要な画像データをまとめて送り返す php の方から。これは、WordPress なので正統的にやるならば、functions.php に記述した関数にて受けることになる。WordPress を介さずに普通に php ファイルで受けることも全く可能なのではあるけれど、その場合、セキュリティの事を少し考えないといけないと思う。まぁ、画像データを送り返すぐらいのようなものならそんなに神経質にならなくてもいいような気もするのだけれど。
画像データはそれ専用の別ファイルに配列にしてまとめて書いておいて、それを functions.php の関数から呼みこんで使うようにした。そうじゃないと、ばかでかいいくつもの画像データが、 functions.php についてまわるなんてことになってしまう。ページごとに必要な画像は異なっているので、それは javascript から指定を出す。
Ajax を受ける php 側の関数はこれだけのもの。なんてことはない。chr(1) は ASCII の小さい番号の方の文字。実際のデータの中に現れる可能性は無いとのこと。ちなみに下は画像データの入ったファイル。そのデータが何の画像がわかるように、ファイル名とセットの二次元配列にしてある。
実際の画像データはあまりにも長く、画像データ自体の数ももっと多く登録しているので省略しているが、[ ファイル名, 画像データ ] を一つの配列にセットした二次元配列である。なぜ二度言う？くどいし。
と、いうことで、送る側の javascript 。
XMLHttpRequest の部分は、よく使うものなので別関数にしている。それはこれの下に。
ちなみに、下のコードは鳥画像ページのもの。もちろん同じことを、テンプレートの部分を対応させて、この WordPress DIY のページでもやらせてる。アイコン画像自体は共通してる部分が多いもので。
コールバックが必要な場合の XMLHttpRequest の関数。
さてさて、結果はいかに！
と、3ポイントほど改善された。ちなみにモバイルの方はといえば・・・？
こちらはまだまだという具合。でかい背景画像がない分、こちらのほうが割合、良い結果が出そうなのではあるけれど・・・？
で、ちなみに鳥画像ページの方はというと。以下の具合。
と、なんとモバイルのほうが好結果が出る。まぁ、こちらの方は重要でない画像はほとんど読み込まないようにしているのだから、当然といえばなんだけれど。
さてさて・・・。
この後、まだまだ闘いは続くのですが・・・この投稿があまりに長くなりつつあるので、続きは新しいページへと移ります。こちらへと → 「Google PAGESPEED INSIGHTS との闘い – それから」
Post : 2021/02/07 18:50
Comments feed
Trackback URL : https://strix.main.jp/wp-trackback.php?p=164288