WCAN 2018/09/15「Web ページを高速化してユーザーに価値を届けたい制作者のためのセミナー＆ワークショップ」に参加してきました。

ウェブDeBLOG｜トライデントコンピュータ専門学校 Webデザイン学科

トライデントコンピュータ専門学校 Webデザイン学科の最新情報を紹介しています。学生へのインタビュー記事から学生作品の解説、Webデザイン・マークアップ・プログラミングの授業風景、プロジェクト発表会、名古屋のWeb制作会社情報、イベント参加レポートやWeb制作の技術解説などWeb制作に関連する記事を掲載しています。トライデントコンピュータ専門学校は、いま話題の名古屋駅からユニモール地下街を歩いて3分です。

<< picture要素と、source要素と、srcset属性と

第56回技能五輪全国大会愛知県選手団結団式 >>

2018.09.24 [月] WCAN 2018/09/15「Web ページを高速化してユーザーに価値を届けたい制作者のためのセミナー＆ワークショップ」に参加してきました。

最終更新:2020.11.28セミナー・イベント参加レポート

2018年9月15日（土）に開催された、WCAN 2018/09/15「Web ページを高速化してユーザーに価値を届けたい制作者のためのセミナー＆ワークショップ」に参加してきました。講師のカワグチです。
さて、久しくセミナー参加レポートを記事にしていなかったのですが、今回は、トライデントコンピュータ専門学校のWebサイトの高速化についても、ワークショップで題材にしていただいたので、書いてみようと思います。

WCAN 2018/09/15「Web ページを高速化してユーザーに価値を届けたい制作者のためのセミナー＆ワークショップ」

"Web ページの表示や動作は速いほうが良い"
… どのように調査、そして改善をすればいいのか
速い Web ページを維持するために何ができるか
本セミナーではこのようなテーマについて講義とワークショップを通し、次の日から現場で活かすための足がかりとなる考え方とノウハウをお伝えします。

講師は、株式会社サイバーエージェントの佐藤歩さん、@ahomuとしても、フロントエンドエンジニア界隈やアクセシビリティ関連で活動されています。
今は、名古屋中心で働いて、東京と行き来しているのですが、もともと名古屋出身でトライデントコンピュータ専門学校にも業界研究授業などでお越しいただいています。

Webサイトを制作する上で、表示スピードはとても重要です。
あまりにも遅いと、どんな魅力的なコンテンツでも、直帰どころか1ページも見られずに閉じられたりします。
逆にWebページが速ければコンテンツを見てくれる可能性が高くなります。
今回は、技術評論社から発刊されている「超速! Webページ速度改善ガイド ── 使いやすさは「速さ」から始まる」から、速度改善の基礎のエッセンスをわかりやすく解説していただきました。

高速なWebページを作るための基礎知識

Webサイトが利用されるサイクルは、

ナビゲートを開始する
リソースをダウンロードする
コンテンツが表示される
ユーザーが操作する
閉じる（or 別のページへのナビゲートを開始する）

となります。
この場合、速度が速いには2種類あり、リソースがダウンロードされて、Webページが表示されるまでが速ければ、「ページロードの速度が速い」と言えます。

ブラウザがページにHTML, CSS, JavaScriptを読み込む事によって、Webページのビジュアルレンダリングを作成し表示します。

続いて、ブラウザの表示速度やコンテンツを動かす速度が速いと「ランタイム (orレンダリング) の速度が速い」と言えます。
FPSやUIスレッドなどを計測、対応することで改善することができます。

どの部分の改善が必要かによって、調査の仕方、改善方法が変わります。
今回は、主に「ページロードの速度が速い」の話でした。

高速化ポイントのセルフチェック

既存のWebページを調査する方法として、Google Chromeに搭載されているDeveloper Tools（通称DevTools）とページ速度を測定するWebサービスが手軽に始められます。

Lighthouse

今回、Dev Tools > Auditsの「Lighthouse」を教えてもらいました。簡単に改善点のセルフチェックができます。

表示をみると、上から順に速度の各指標、時系列のキャプチャ、改善ポイントの提案となっています。

例で利用したトライデントのWebサイトでは、いきなり表示されていますが、時系列のキャプチャの表示の仕方にも意味があります。

FP ( First Paint ) — ページが表示され始めたとき
FCP ( First Contentful Paint ) — コンテンツが表示され始めたとき
FMP ( First Meaningful Paint ) — ユーザーに意味のある表示になったとき
TTI ( Time to Interactive ) — ユーザーの操作に応答できるようになったとき

さらに、DCL（DOMContentLoaded ）—最初のHTMLドキュメントの読み込みと解析が完了したときという、指標もあります。

いきなり全てが表示されるのは、何かがブロッキングしているということになるのかな。
「View Trace」ボタンをクリックすると詳細を確認する事ができます。

参考：Web クライアントサイドのパフォーマンスメトリクス — Speed Index、Paint Timing、TTI etc... ::ハブろぐ

ページの表示スピードを計測する時に、よく利用するツールにGoogleが提供しているPageSpeed Insightsがあります。
私もよく利用しているのですが、こちらは、Chrome User Experience Reportに基づいたRUM（リアルユーザモニタリング）データを取得して判定しているようで、ブラウザに届いたデータで判定しているLighthouseとは、違ってきます。

また、現在PageSpeed Insightsが示すFastの評価は、FCP( First Contentful Paint ) までのようで本来、ユーザーが感じるFMP ( First Meaningful Paint ) やTTI( Time to Interactive )までの評価ではないようですので、信頼しすぎるのは危険・制作者が参考にするのはオススメではないということでした。
ただ、Googleでは機能改善を進めているようですので、今後に期待です。

WebPagetest

ここまでは、ユーザーというよりは制作者がセルフチェックするための方法ですが、クラウド上のテストエージェントでWebページの表示速度をテストしたい場合、より網羅的なレポートが出るWebPagetestが便利です。

このような、ツールなどでチェックをして、Webサイトのボトルネックになっている部分を見つけ、改善点を探っていきます。

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

さて、ページロードを遅くする主な要因として、

HTMLの返却が遅い
画像が大きい、多い
キャッシュや圧縮が有効でない
CSSやJavaScript が大きすぎる
レンダリングがブロックされている

があります。
それぞれのDevtoolsでの検証方法と原因・対処法です。

HTMLの返却が遅い

DevToolsでは、
①Network panel→②Doc tab→③Select HTML→④Timing tab
を見ることでどのぐらいの時間がかかっているのかわかります。

対処方法: 基本的にサーバーに原因がある; キャッシュプラグインなどを活かす; サーバーのプラン変更や乗り換え

サーバーの管理者が違う場合は、説明して対応してもらうしかないようです。

画像が大きい、多い

DevToolsでは、
①Network panel→②Img tab→③Size sort→④Select File→⑤Preview tab
で、どの画像のサイズが大きいのかがわかります。

対処方法: 最適な画像形式を選択する; .jpgは画像の品質を見直す; メタデータ除去などで最適化する; 画像の寸法を見直す; srcset属性や<picture>要素によるレスポンシブイメージを実装する; CSS Backgroundならメディアクエリで参照する画像を調整; コンテンツとしての画像自体を可能なら減らす; 画像の遅延ロードは今でも有効

こちらは、制作者、運用者側でできることが多いですね。まずは、ここから手を付けていきたいところです。
srcset属性やpicture要素については、いつか調べてまとめたいと思います。

［追記：20181002］「picture要素と、source要素と、srcset属性と」でまとめました。

キャッシュや圧縮が有効でない

DevToolsでは、
①Network panel→②Select File→③Headers tab
で、どのようなResponceが返ってきているのかを確認できます。

対処方法: キャッシュも圧縮もサーバーで設定; ブラウザキャッシュをCache-Controlで指定する; テキストリソースは gzip を適用する

こちらも、サーバーの設定ですね。

CSS、JavaScriptが大きすぎる

DevToolsでは、
①Network panel→②JS or CSS tab→③Size sort
で、JavaScriptやCSSのサイズが確認できます。

対処方法: 共通 CSSと個々のページ用CSSで分ける; 使っていないCSSはコード管理的にキチンと消して; HTTP/2で並列ダウンロード数を増やす; JavaScriptの肥大化は、ボトルネックになりやすい; 不要な jQuery プラグインや npm の依存パッケージを減らす

一時期、全てのCSSを1ファイルにまとめて、HTTPリクエストを少なくするというテクニックもありましたが、大きなファイルを作るよりは、適宜CSSをわけて運用するほうがベストということです。
また、JavaScriptの肥大化は、CSSよりもボトルネックになりやすいので気をつけたいところです。

CSSのセレクタなどの使用状況を調べる

Bootstrapを利用している場合や、長年運用していると更新して使わなくなってしまったセレクタなどがCSSのデータ量を大きくしている場合があります。
そんなとき便利なのがDevToolsで、
①Show Drawer→②Coverage tab→③Select file
を見るとセレクタの使用状況などがわかります。

ただし、このページでは使っていないが、他の重要なところに利用されている場合もありますので、注意が必要です。

レンダリングブロック

「レンダリングブロックする」とは、レンダリング（≒コンピュータが解析して表示）に影響するので待つということで、ブロックするリソースは、

HTML は DOM の構築に必要 + Web ページの基点
CSS は CSSOM を構築し、レンダーツリーに影響する
JavaScript は DOM と CSSOM に作用して、レンダーツリーに影響する
Web Font もテキストのレンダリングに影響する

などで、Lighthouseで確認する事ができます。

グループワーク

事前に、講師の佐藤さんから「改善したいWebサイトを持ち寄ってきてください」ということでした。
数名のグループに分かれて検証して、ボトルネックを探り、対処方法を話し合いました。私のグループでは、幸いにもトライデントコンピュータ専門学校のWebサイトを対象にしていただきました。
レポートの説明で利用したキャプチャでもわかるように、ボトルネックになっていそうなところ、改善できそうなところなど、Web制作者の方々に、色々と指摘してもらったので、改善の提案をしていきたいと思います。
グループワークの様子は、WCANのレポートで紹介されています。

長文の参加レポートになってしまったのですが、セミナーでは技術的な話だけでなく、実際に運用者やクライアントが最適化に取り組むにあたって、どこから始めればいいのか、提案のしかた、有料サービスの紹介など盛りだくさんの内容でした。
今回の資料は、後日一般公開されるそうですので、Twitterの@ahomuさんのアカウントをチェックしてみてください。

［追記：20181018］資料とブログの記事が公開されました。

Web ページを高速化してユーザーに価値を届けたい制作者のためのセミナー＆ワークショップ資料公開 ::ハブろぐ https://t.co/xqlaknO0vA

ヾ('ω'ヾ) ﾖｯ　9/15 のセミナー資料を一般用に公開しました #wcan
— あほむ (•ө•) (@ahomu) 2018年9月29日