サイトスピードの改善案まとめた

7

この記事について

ここ最近業務時間ではエディター見るよりも Dev ツールの NetWork やら Performance と睨めっこしてる時間の方が大きい気がする。ずっとパフォーマンスを気にしてる。だんだんページに施す改善がルーティン化してきたので軽くまとめた。

大抵の場合、重いのは画像

暴論かもしれないが、サイトスピードを気にしてフロントからチューニングしようとして情報を探す人は画像関係をゴニョゴニョすれば解決しそうな気がする。まず取り掛かる点として、

  1. オフスクリーン(非 FV/スクロールしないと見えない範囲)にある画像は全て lazysizes で遅延読み込みする
  2. FV の画像は WebP を使用する
  3. 圧縮する

ここら辺は最低限のラインと言える。

lazysizes の導入

body 閉じタグ直前などで下記挿入。

<script
  src="//cdnjs.cloudflare.com/ajax/libs/lazysizes/5.3.0/lazysizes.min.js"
  integrity="sha512-JrL1wXR0TeToerkl6TPDUa9132S3PB1UeNpZRHmCe6TxS43PFJUcEYUhjJb/i63rSd+uRvpzlcGOtvC/rDQcDg=="
  crossorigin="anonymous"
  defer
></script>
<script
  src="//cdnjs.cloudflare.com/ajax/libs/lazysizes/5.3.0/plugins/unveilhooks/ls.unveilhooks.min.js"
  integrity="sha512-GKwsVWFwe3FO37nvvXuZAMFJ6+drC/5rtXeQ23PZNbxK2v59ifWXswDWZU7wL/9earCfL77/VYzmxJrZNPs5nQ=="
  crossorigin="anonymous"
  defer
></script>

2 行目の unveilhooks は背景画像も遅延読み込みすることができる。また、ここでは記事執筆時点での最新版を指定しているが、古くなることもあると思うので下記リンクから確認してもらえれば。

参考: https://cdnjs.com/libraries/lazysizes

また、その際にdeferをつけ、非同期読み込みするといい。

参考: https://html.spec.whatwg.org/multipage/scripting.html#attr-script-async

WebP の導入

WebP については過去にまとめた。WebP の導入はpictureタグなどを使えば良い。

<picture>
  <source srcset="hoge.webp" media="(min-width:769px)" />
  <source srcset="hoge.png" media="(min-width:769px)" />
  <source srcset="hoge_sp.webp" media="(max-width:768px)" />
  <source srcset="hoge_sp.png" media="(max-width:768px)" />
  <img src="hoge.png" alt="ファーストビュー" />
</picture>

ただし、WebP を使用すると画像編集などが面倒になるため、画像の変更(例えば文字を含んでいる画像などの文字部分を変えるなど)が多々ある場合は保守性を考慮して愚直に png などで表示した方がエンジニア的には嬉しいかもしれない。

SVG を使用する

単純なアイコンやロゴなど不変なものは SVG で表示してしまうのがいい。大抵の場合、画像よりも容量が軽く、画質も落ちないので。イラレなどのデザインカンプがある場合は SVG 形式での書き出しは容易。念の為、圧縮もするとなおいい。

https://jakearchibald.github.io/svgomg/

iframe の埋め込みはで loading="lazy"よりも lazysizes で

いまどき YouTube の埋め込みや GoogleMap の埋め込みはしていないサイトの方が多いかもしれない。僕の勤める会社も全国 7 店舗の GoogleMap が大抵のページに入ってくる。それらの埋め込みは iframe タグを使って、要は外部サイトを自サイトの中に表示するわけだが、これがまぁ遅い。

僕は iframe に対してloading="lazy"を使用していた(サポートしていないブラウザがあるのは織り込み済み)。ただ、どうもloading="lazy"だとサポートブラウザでも遅延が感じられない。lazysizes はスクリーン(表示範囲)に入った段階でdata-srcsrcに書き換える(=パース/レンダリング段階では src 元に対してリクエストを送らない)のに対して、loading="lazy"はおそらくパース/レンダリング時点でリクエストが送られてしまっている。画像のダウンロードなどは遅延させることができるのだろうが、iframe 系の遅延には向いていないのだろう。

なので、FV に YouTube なり GoogleMap がある場合は仕方ないが、ページの非 FV(=深い部分)にある場合は必ず lazysizes で遅延読み込みをする必要がある。loading="lazy"は非推奨だ

<!--YouTube-->
<iframe
  class="lazyload"
  data-src="https://www.youtube.com/embed/G4X0C-4n-ek"
  width="560"
  height="315"
  frameborder="0"
  allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture"
  allowfullscreen
></iframe>

<!--GoogleMap-->
<iframe
  class="lazyload"
  data-src="https://www.google.com/maps/embed?pb=!1m18!1m12!1m3!1d2162.9965192692625!2d139.7652839627025!3d35.68111511958082!2m3!1f0!2f0!3f0!3m2!1i1024!2i768!4f13.1!3m3!1m2!1s0x60188bfbd89f700b%3A0x277c49ba34ed38!2z5p2x5Lqs6aeF!5e0!3m2!1sja!2sjp!4v1529927231570"
  width="600"
  height="450"
  frameborder="0"
  style="border:0"
  allowfullscreen
></iframe>

.htaccess での gzip 配信

こちらを参考にすればいい。

参考: https://www.cloud9works.net/seo/tutorial-gzip-with-htaccess/

.htaccess でのブラウザキャッシュ

広告出稿が前提の LP などでは効果はあまり期待はできないが、ブラウザキャッシュなどするといい。

参考: https://qiita.com/shotets/items/a5465fb41623cc3dae94

CSS の遅延読み込み

スライダーなど、外部ライブラリを使用していてそれがオフスクリーンにある場合、CSS も遅延読み込みするといい。高機能なライブラリであればあるほど当然ファイルサイズも大きくなる。

参考: https://qiita.com/rana_kualu/items/95a7adf8420ea2b9f657

preload などでのコンテンツ先読み

preload, preconnect, dns-prefetch, prefetch, prerenderなど外部リソースを先読みできる属性があるので GTM 周りなどに使ってみるのもいい。ただし、正直そこまで大きな効果を得られることはないとは思う。なお、何度も書いているがそれぞれの違いがいまだに覚えられない。導入する場合はチートシートなど用意するといい。

GTM はどうしようもない

僕が勉強不足であることが大きいと思うが、GTM はもうどうしようもないものとして割り切っている。コーディング完了段階では PageSpeedInsight でモバイル 90 点以上安定していたページも GTM を導入した瞬間 50〜60 点台に落ちることはザラにある。悔しすぎるが、軽くしようがないし、変にいじって計測ツール各種のデータに悪影響を及ぼすわけにもいかない。もうこれに関しての説明責任など求められた場合は A/B テストの結果など用意して逃げ切る他ない。無力。南無。

サーバーの変更

あまり会社の歴史が長くなかったりサーバーを細かく分離している職場であるのならばサーバー周りの改善を検討しても良いかもしれない。歴史が長かったり一つのサーバーに抱えるものが多い場合は引っ越しも面倒だと思うため非推奨。Dev ツールの Network 欄を開き、一番上にくるドキュメントにホバーして TTFB 値(ブラウザにデータが届くまでにかかる時間)を見てみる。100ms 以内でないのならばサーバーの引っ越しを検討するのも良い選択肢だと思う。

ファイル実行言語の見直し

例えば php も 8.0 系がリリースされ、従来より処理速度が向上した。上記の TTFB 値はサーバー側に起因するスコアなので、実行言語の処理速度をあげれば改善も図れる。

まとめ

というか、こういう小手先の改善を積み重ねるよりも Gatsby みたいな SSG 使うとかなにか抜本的な変更をした方が導入コストとかを考えてもお釣り返ってくるくらいにリターン大きい気がするんですけどね。ただまぁさまざまな観点から現実的じゃないパターンが多いとは思います。というわけで今後も地味にしこしこ改善していきましょうウェイソイヤ

  • SNSでシェアしよう
  • Twitterでシェア
  • FaceBookでシェア
  • Lineでシェア
  • 記事タイトルとURLをコピー
トップへ戻るボタン

\ HOME /

トップへ戻る