# CSS Nite in Kobe, vol.43「ウェブページを高速化してユーザーに価値を届けたい制作者のためのセミナー＆ワークショップ」に参加してきました URL: https://webrandum.net/cssnite-kobe-43/ 公開日: 2019-07-23 更新日: 2019-07-23 カテゴリー: セミナー・イベント タグ: CSS Nite, 速度改善 出典: Webrandum（著者: サイトウ マサカズ） 先日開催されたCSS Nite in Kobe, vol.43「ウェブページを高速化してユーザーに価値を届けたい制作者のためのセミナー＆ワークショップ」に参加してきました。 ## 今回の登壇者 今回の登壇者は[株式会社サイバーエージェント](https://www.cyberagent.co.jp/)の佐藤 歩(さとう あゆむ)さんです。 『[超速！Webページ速度改善ガイド](https://www.amazon.co.jp/%E8%B6%85%E9%80%9F-Web%E3%83%9A%E3%83%BC%E3%82%B8%E9%80%9F%E5%BA%A6%E6%94%B9%E5%96%84%E3%82%AC%E3%82%A4%E3%83%89-WEB-PRESS-plus/dp/477419400X/ref=as_li_ss_tl?ie=UTF8&linkCode=ll1&tag=masakazu0510-22&linkId=c2a1e13e8c4a99e9d7cc9dd1850e4a89&language=ja_JP)』という書籍の著者でもあり、パフォーマンスとアクセシビリティを軸とした、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が起動します。 ![Lighthouse](https://webrandum.net/mskz/wp-content/uploads/2019/07/image_1-18-1024x619.png) 起動する前にいくつか項目を設定することで、設定できます。 | 設定項目 | 選択肢 | 備考 | | --- | --- | --- | | Device | 「Mobile（スマホ）」と「Desktop（PC）」どちらで確認するか選択 |   | | --- | --- | --- | | Audits | 検査する項目を選択 |   | | --- | --- | --- | | Throttling | 「Simulated Fast 3G, 4x CPU Slowdown」 →3G回線、処理速度を4分の1の場合を推定して検査する 「Applied Fast 3G, 4x CPU Slowdown」 →3G回線、処理速度を4分の1にして検査する 「No throttling」 →何もせずそのまま検査する | 「Simulated」はあくまで推定。 「Applied」の場合は実際にネットワークや CPUのスロットリングを行う。 | | --- | --- | --- | | Clear storage | ストレージをクリアして検査する | 初回アクセス時を想定するために、チェックを入れておく | | --- | --- | --- | 回線を遅くしてテストできるのが特徴的ですよね。 これでスコアが高いと、ユーザーにとっても速い可能性が高くなります。 このブログのトップページでも行なってみましたが、「Simulated Fast 3G, 4x CPU Slowdown」だと98点と、かなり良い結果でした（AccessibilityとBest Practicesの点がイマイチですが…）。 ![Performance 98点](https://webrandum.net/mskz/wp-content/uploads/2019/07/image_2-16-1024x603.png) ちなみに「No throttling」の方を試すと100点になりました。 速度制限を行なっていない場合で100点を取っても、速度制限がある人からすると98点と少しスコアが落ちることが分かります。 #### 他のテストサービスと比較 他にも有名なウェブサイトのテストサービスである「[PageSpeed Insights](https://developers.google.com/speed/pagespeed/insights/?hl=JA)」や「[WebPageTest](https://www.webpagetest.org/)」でも試してみました。 PageSpeed Insightsのページ速度に関する部分は、Lighthouseが使われているとのことです。ただ、回線を遅くしたりはできないため、Lighthouseの「No throttling」と同じ100点が出ました。 ![PageSpeed Insights 100点](https://webrandum.net/mskz/wp-content/uploads/2019/07/image_3-9-1024x543.png) WebPageTestの方に関しては、アルファベット評価で全てAになっていました。 ![WebPageTest](https://webrandum.net/mskz/wp-content/uploads/2019/07/image_4-6-1024x518.png) このことからも、とりあえずLighthouseが1番細かいところまで見れそうですし、点数もシビアで、Lighthouseの点数を上げれば自然と他のテストサービスでも好成績が出せるようになりそうです。 ### ページロードを遅くする原因 1. HTMLの返却が遅い サーバー側のHTML生成を何とかする（静的サイトの強みはこの部分がないこと） 2. キャッシュ系のプラグインを使う 3. サーバーの性能を上げる 4. サーバーを物理的に近づける（国内のレンタルサーバーなら気にしなくて良い） - 画像が大きい・多い（1番影響大きい） 1. 画像の形式を見直す 2. 画像の品質を見直す 3. メタデータ除去など最適化処理をする 4. 画像の遅延読み込みを行う - キャッシュや圧縮が有効でない 1. ブラウザキャッシュを設定する 2. gzipを適用する 3. キャッシュも圧縮もサーバー（ミドルウェア）で設定できる - CSSやJavaScriptが大きすぎる 1. CSSは1ファイルに結合するより分けた方が良い 2. jQueryプラグインを見直す（多機能なものは容量も大きいので、追加時にはシンプルなものを選ぶ） 3. npmでの依存パッケージを見直す - レンダリングがブロックされている 1. `