CSS Nite in Kobe, vol.43「ウェブページを高速化してユーザーに価値を届けたい制作者のためのセミナー＆ワークショップ」に参加してきました

先日開催されたCSS Nite in Kobe, vol.43「ウェブページを高速化してユーザーに価値を届けたい制作者のためのセミナー＆ワークショップ」に参加してきました。

今回の登壇者

今回の登壇者は株式会社サイバーエージェントの佐藤 歩(さとう あゆむ)さんです。

『超速！Webページ速度改善ガイド』という書籍の著者でもあり、パフォーマンスとアクセシビリティを軸とした、Webプロダクト品質向上のプロフェッショナルな方です。

セミナー全体を通しての感想

ページの表示速度が重要だと言われているのはよく聞きますが、じゃあどうやって表示速度を上げていくのかはあまり聞いたことがありませんし、表示速度高速化にフォーカスしたセミナーもあまり無いように思います。

どんなに良いコンテンツを作っても、表示が遅くて見られないのでは意味がありません。
そのために必要な知識やノウハウが、得られました。

特に印象深かったのが、ワークショップのときに佐藤さんが「速度を3G回線まで落としてリロードして、コンテンツがどの順番で読み込まれるとユーザー体験が良くなるか考えるといい」と仰っていたことです。

ページの速度改善というと、全て数字を見て判断していくようなイメージを持っていましたが、結局はWebページなので、実際にそのページを見た人の気持ちにならなければ意味がありません。

もちろん数字も指標として重要ですが、それとはまた別の視点も得られたのは大きかったです。

ウェブページの高速化方法

Webページの速度には2種類ありますが、今回はページロード時の高速化についての内容でした。

• ページロード：ブラウザがページを最初に表示する速度（一般的に表示速度と聞いて思い浮かべる方）
  • First Contentful Paint（FCP）：初めてコンテンツが表示された時間
  • First Input Delay（FID）：ユーザーの操作に対しての最初の応答時間
  • Time to Interactive（TTI）：ページの表示が終わり、完全に操作可能になった時間
• ランタイム：ブラウザが表示やコンテンツを動かす速度（Canvasやアニメーションをゴリゴリ使っていなければ特に問題なし）

また、ページロードにもいくつかのフェーズがあります。

とりあえずLighthouseを確認するのが手っ取り早い

いまはLighthouseというGoogleが出している確認サービスを利用すればOKだそうです。

使い方はGoogle Chromeの開発者ツールで「Audits」タブを開いて、「Run audits」をクリックすればLighthouseが起動します。

起動する前にいくつか項目を設定することで、設定できます。

回線を遅くしてテストできるのが特徴的ですよね。
これでスコアが高いと、ユーザーにとっても速い可能性が高くなります。

このブログのトップページでも行なってみましたが、「Simulated Fast 3G, 4x CPU Slowdown」だと98点と、かなり良い結果でした（AccessibilityとBest Practicesの点がイマイチですが…）。

ちなみに「No throttling」の方を試すと100点になりました。
速度制限を行なっていない場合で100点を取っても、速度制限がある人からすると98点と少しスコアが落ちることが分かります。

他のテストサービスと比較

他にも有名なウェブサイトのテストサービスである「PageSpeed Insights」や「WebPageTest」でも試してみました。

PageSpeed Insightsのページ速度に関する部分は、Lighthouseが使われているとのことです。ただ、回線を遅くしたりはできないため、Lighthouseの「No throttling」と同じ100点が出ました。

WebPageTestの方に関しては、アルファベット評価で全てAになっていました。

このことからも、とりあえずLighthouseが1番細かいところまで見れそうですし、点数もシビアで、Lighthouseの点数を上げれば自然と他のテストサービスでも好成績が出せるようになりそうです。

ページロードを遅くする原因

1. HTMLの返却が遅い
   1. サーバー側のHTML生成を何とかする（静的サイトの強みはこの部分がないこと）
   2. キャッシュ系のプラグインを使う
   3. サーバーの性能を上げる
   4. サーバーを物理的に近づける（国内のレンタルサーバーなら気にしなくて良い）
2. 画像が大きい・多い（1番影響大きい）
   1. 画像の形式を見直す
   2. 画像の品質を見直す
   3. メタデータ除去など最適化処理をする
   4. 画像の遅延読み込みを行う
3. キャッシュや圧縮が有効でない
   1. ブラウザキャッシュを設定する
   2. gzipを適用する
   3. キャッシュも圧縮もサーバー（ミドルウェア）で設定できる
4. CSSやJavaScriptが大きすぎる
   1. CSSは1ファイルに結合するより分けた方が良い
   2. jQueryプラグインを見直す（多機能なものは容量も大きいので、追加時にはシンプルなものを選ぶ）
   3. npmでの依存パッケージを見直す
5. レンダリングがブロックされている
   1. <script>は</body>の直前へ配置
   2. <script>にdefer属性をつける
   3. Web Fontsをなるべく使わないようにする
6. 広告やSNS系プラグインが多い
   1. なるべく減らす
   2. 広告に関してはどうしようもない部分があるが、SNS系のものは本当に必要か検討する

個人的に気になったのが「CSSは1ファイルに結合するより分けた方が良い」という部分。
最近はSassの@importを使って、複数のSassファイルを1つにまとめて書き出していたのですが、分割した方が良かったんですね。

昔はHTTP/1.1という通信が主流で、1サーバーあたり同時にダウンロードできるファイルの数が6個までだったので、CSSファイルを1つにしてファイル数を減らしていたみたいです。

今はHTTP/2という通信が主流で、18個まとめて並列ダウンロードできるようになったらしく、CSSファイルが分割されていても問題ないみたいです。

まとめ

かなり現実的で次の日からすぐ使えるような知識がたくさん得られました。

とりあえず、下記の3項目は比較的ライトに始められそうなので、日頃から意識していきたいと思います。

• まずはLighthouseを確認する
• 画像は最初に作成する段階で拡張子を適切にして、圧縮をしておく
• プラグインやパッケージを導入するときはサイズを意識する