Web ページを高速化して ユーザーに価値を届けたい 制作者のための セミナー＆ワークショップ資料公開
Posted: Updated:
Web ページの高速化セミナー
WCAN 2018/09/15「Web ページを高速化してユーザーに価値を届けたい制作者のためのセミナー＆ワークショップ」 - WCAN | Doorkeeper
先日、2018年9月15日にひっさびさに WCAN に登壇させていただいて Web パフォーマンスチューニング....のなかでもページロード速度の高速化を中心にセミナーとワークショップを行わせていただきました。
下記はそのときの資料です。今回は Web サイト制作者向けのセミナーとして企画したので、Web アプリ開発勢が好きそうなテクニカルな話はすべて割愛しています。
ウケが良かったような気がするネタ
なにがウケるか読みがつかなかったので、とりあえず色々盛り込んでみました。会場では下記のあたりがウケが良かったような....気が...する。
- 格安 SIM の回線は、大手キャリアのプロパー回線と比べると劇的に遅い話（P.7）
- 肥大化した JavaScript が端末スペックによっては致命的な一撃になる話（P.65, 67）
- PageSpeed Insights の Fast 評価は、ユーザー体験の一部しか示さないのでアテにするべきでない話（P.94）
最後のについては下記のごとくフォローいただいているので今後に期待してます( ╹◡╹)
ご指摘の通りでCrUXにFIDを記録し始めたりとRUMでもメトリックを充実しようとしております！引き続きよろしくお願いします‼️
— Yusuke Utsunomiya (@uskay) September 9, 2018
First Input Delay - State of the Web https://t.co/PDZPnwHSOg
イベント全体を通してのアレコレ
超速本もそうですが Web アプリケーションエンジニア向けの発表が最近は多く、ひさびさに Web サイト制作者向けのセミナーだったので今回はイチから構成を見直しました。
Lighthouse を軸に説明してみた
こういうセミナーではよくある改善ポイントについて、DevTools での調査方法からして網羅的にお伝えすることが多かったのですが、今回は「まずは Lighthouse でざっくりチェックして引っかかったところに対処しときましょう」という具合にしました。
Lighthouse によるウェブアプリの監査 | Tools for Web Developers | Google Developers
Google Developers の Lighthouse に関するページの Audit References > Performance を見れば分かりますが、初〜中級者むけにお伝えするような Tips 的トピックは一通り揃っています。これからやるぞ！っていう方は、これを頼りに知識を広げていくのがよろしいのではないかという所存です。
ワークショップというかグループワーク初挑戦
Web ページの速度改善をするときの基本的なフローは、調査 → 評価 → 計画 → 実行 です。これをグループワークとして実施してみてもらいました。詳細はスライドに手続きを書いてあるのでご覧頂ければ。
- ボトルネックとなっている部分を調査する
- 発見されたボトルネックの改善によるインパクトを評価する
- 改善の可能性や、工数などの現実性などを元に計画をする
- ボトルネックの解消を実行する
今回は 1-2 のあたりで特に Lighthouse に頼ることになりましたが、特に重要なのは 3 です。画像が多すぎるから画像を減らそう！という発想をしたとして、Web ページの重要コンテンツたる画像を本当に減らせるのか？となると議論の余地があるでしょう。そのような意志決定までワンセットで体験してもらいたいなという気持ちが込められています。
で、今回は全体的に時間がタイトになってしまって落ち着かないワークショップになってしまったことかと思いますが、これも次回以降はタイムテーブルに余裕をもたせて改善しようと思います...。
さまざまな計測行為と数字との向き合い方
Real User Monitoring 以外、Synthetic Monitoring や Lighthouse のようなセルフ計測（一応エミュレートつき）の数字は「その計測条件における数字であって、すべてのユーザーに同じ体験が提供されるわけではない」のと「良好であれば、ユーザーにとっても良好である可能性が高いが過信してはならない」という話を重ねてお伝えしました。
Lighthouse のスコアも、あくまで Lighthouse における重み付け によって算出される参考値であって、仮に90後半であってもエンドユーザーの体験が保証されるわけではない、という話もしています。当たり前に高得点にはしておきたいところですが、過信は禁物でしょう。
終わってからの反省ですが、このへんの数字との向き合い方や考え方は、一発で俯瞰できるようなモデル（図）を最初に提示して説明に時間を割けば良かったなと。次回以降に反映しようと思います。
資料で Google Slide に挑戦
今回は下記の機能を目当てに Google Slide を利用してみました。
- URL で共有できる
- PDF エクスポートできる（Speaker Deck 陳列用）
- Embed できる
- 聴講者がコメントできる
明確に動画の埋め込みが YouTube 的な Embed として扱われているため、動画が再生可能になるまでの初期化 etc が Keynote ほかローカルファイルへのリンクと比べると圧倒的に遅いのはデモ動画を差し込む際のストレスでした。
ahomu/Talkie の開発をやめたつもりはないんですが、Talkie 使うと Talkie 自体のメンテナンスがしたくなって時間が無限に溶けていくので今回は見送り。
というかんじでした
今回と同様の構成でよければ地方出張も承りますので、お気軽に Twitter とかでご相談ください。今回の難易度設定やセミナーのゴールなどは本記事冒頭にリンクしたイベントページに掲載されていますが、難易度や構成のチューニングも対応できます。
まずは西のほうから1件、来年分の仮オファーいただいてます(∩´∀｀)∩
