【技術本】パフォーマンス向上のためのデザイン設計
https://amzn.to/3INaoKq
【技術本】パフォーマンス向上のためのデザイン設計
へポスト
主にWebサイトの表示処理におけるパフォーマンス向上の手段をフロントエンド側でのテクニックを中心に紹介し、パフォーマンス測定を行いボトルネックを調査できるまでのノウハウが記載されている。
最終的には、身に着けた技術などをメンバ内で共有し、継続的に改善を行える組織作りにすることまでを目標としている。
付録ではHTTP/1と2の仕様の比較を紹介し、HTTP/2で想定されるWebサイトパフォーマンステクニックにも言及している。
学べること:
・画像の圧縮最適化技術
・css、JavaScript、読み込みフォントの最適化
・サーバサイドと連携したgzip圧縮
・キャッシュの活用方法
・モバイル、スマートフォンの各スペックに併せた最適画像の選択処理
・パフォーマンスモニタリングツールなどによるボトルネック調査
・最適化と改善を継続的に行える組織作り
本書は”フロントエンドエンジニア”より”デザイナ”側により近い位置づけで、主にWebで視覚効果のユーザエクスペリエンスをつかさどる技術を中心に性能向上のノウハウを解説している。
パフォーマンス向上のためにきちんと着眼すべき項目とその理由を、Webサーバの挙動やモバイル通信基盤の仕組み、HTTP/1の仕様を踏まえて、技術者でなくてもわかりやすく説明もされている。
Web制作に携わる人なら既知の内容も含まれてると思うが、知識に漏れが無いか一読しておいて損はないと思う。
記載されている内容の補足メモは下記の様です。
------------------------------------
1章 サイトパフォーマンスはユーザエクスペリエンス
ユーザがページ表示に期待する時間は2秒以内
3秒以上になると40%以上が離脱
85%のモバイルユーザがデスクトップと同等かそれ以上の速度で表示してほしい
Webページ応答までの時間
100ms未満:即反応と判断
100~300ms:遅れに気づく
300~1000ms:まだ正常に動作していると判断
1000ms以上:他サイトに切り替えたい
WebECサイトでトラブル(クラッシュ、フリーズ、ややこしさ、表示遅延)にあった75%がリピーターから離脱
88%が不快な経験をしたら再来訪なし
75%がアクセスピーク時間帯で表示を待つより、快適な競合他社サイトへ移動する
ECサイトに限らずすべてのサイトにおいて、表示遅延をユーザが体験するとGoogleの検索順位が低下する。
検索エンジン:高速なサイトは順位も上
モバイルユーザへの影響:アフリカ、アジア地域50%がモバイルのみでインターネットアクセス
モバイルネットワークの通信基盤による技術的な遅延。
モバイル端末のバッテリー消費の影響。(Wifi信号強度、JSレンダリング、画像レンダリング)
応答性とデザイン
・リソースのために何回HTTPリクエストが発生したか
・画像ファイルサイズ
・画像フォーマット
・マークアップ言語とCSS構造のデザインに対する影響
------------------------------------
2章 表示速度の基礎
エンドユーザの応答時間の80-90%はフロントエンドに費やされる
・HTTPリクエスト数、サイズを最適化で大きな効果
ウォータフォールドチャート(サイト読み込みファイルごとタイムラインで表示したもの)で可視化。
->画像を一つのスプライトにまとめる[3.2.1章]
->画像を圧縮ツールで縮小[3.1.4章]
->css,JavaScriptの総数を減らす[4.5.1章]
・HTTPS通信では暗号化確率処理でページロードが増大
・ブラウザのコネクション数:ブラウザ種別により異なる(最新:6〜8個)
->サードパーティスクリプトなど別サイトからダウンロードするものがあるとコネクションが分散され最適表示の妨げになる可能性
・gzip圧縮で最適化[4.5.2章]
www.webpagetest.orgのサービスを利用したパフォーマンス測定
2.3.1クリティカルレンダリングパス
・一時的な空白表示はユーザエクスペリエンスの低下を招く
・CSSのどの部分がレンダリングブロックになるかの切り分け
・Chrome Developer Toolでジャンク(画面スクロール時の再描画によるなめらかスクロールが阻害される現象)の調査
2.4表示速度に影響するその他の要因
・物理的距離による要因
->CDNの活用でユーザは最寄りのサーバからデータを取得できる
------------------------------------
3章 画像の最適化
photoshop「web用に保存」機能の活用
3.1.1 JPEG
不可逆圧縮
容量増大原因:
・ノイズの多い画像
・色の差があるものが多く含まれる
プログレッシブJPEGによる表示方法の活用
・早いレスポンスで低解像度描画し徐々に画質をあげて表示する
3.1.2 GIF
可逆圧縮、256色、アニメーション、透過も可能
容量増大原因
・ディザリング処理
・縦方向にノイズが多い
3.1.3 PNG
可逆圧縮
水平垂直圧縮、透過に最適
PNG-8,PNG-24が存在
半透明はPNG-24
3.1.4 画像圧縮
画質を崩さず最適化
ツールの活用
・ImageOptim
・Smush.it
3.2.1 スプライト
画像をまとめてHTTPリクエスト数を減らす
スプライト画像を表示するCSS実装の紹介
欠点:
・修正はファイル全体のキャッシュに影響
・不要画像までまとめてダウンロードしてしまう
3.2.2 CSS3
画像をCSSにおきかえ
3.2.3 データURIとBase64エンコード
画像をhtml内にテキストに変換して参照する
3.2.4 SVG
ベクターデータに変換
単色、グラデーッション、透明使用、緻密描写の画像はSVGを検討
制作チームで継続的な精査チェックをする環境づくりが大切
------------------------------------
4章 マークアップ言語とスタイルの最適化
4.1.1 Divits(不要なdivタグの多様症候群)
不要なタグはhtml,css両方を増大させる
4.1.2 セマンティクス
コンテンツの意味や内容に沿った内容を要素に命名
保守性向上
4.1.4 フレームワークとグリッド
フレームワークを使用したい場合は、汎用性を兼ねて含まれている不要タグなどをクリーンアウトしてから使用すべき。
4.2 CSSのクリーンアップ
CSSの削除ツール:
・Dust-Me Selectors
・ChromeのDeveloper tool -> Audits -> Web Page Performance でRun実行で未使用CSSルール一覧表示
4.3 Webフォントの最適化
サイトに取り込む価値があるか確認
Webフォント:数KB〜数百KBまである
4.4 流用可能なマークアップの作成
ファイルキャッシュの機会を提供できる
車輪の再発明を防ぐ
サイト全体で一貫性をもった色の配置で色に意義をもたす
4.5.1 CSSとJavaScript読み込み
・CSS
->から読み込む。理由:レンダリングブロックするため
->@importも避けるべき
・JavaScriptはページ下部から読み込む
->ページ終わりに非同期で読まれるべき->表示速度向上
4.5.2 縮小化とgzip
コード縮小化ツール:
・CSSMinifier.com
・JSCompress.com
gzip:
Webサーバ上で設定数必要あり。
Apahce,nginx,IIS...etc
4.5.3 ファイルのキャッシュ
HTTPリクエスト数を減らせる
全ての静的ファイルはキャッシュ化されるべき
・Expires or Cache-Control: max-age
※Expires:1年後以降まで設定するのはガイドライン違反なので注意
・Last-Modified or ETag
------------------------------------
5章 レスポンシブWebデザイン
各種モバイル、スマートフォンのスペック、利用形態(縦表示、横表示)に沿った、最適なファイルがダウンロードできるようにするテクニックの紹介。
最適サイズ画像の選択方法:
・HTML,picture要素の活用
・picture要素以外の設定方法
フォントの選択方法
Chrome DevToolを活用したデバッグ
WebPageTestサイトを利用したSpped Indexの計測
------------------------------------
6章 パフォーマンスモニタリングの継続的な実施
各種パフォーマンス測定ツールの紹介
ブラウザプラグイン:
・YSlow
・Chrome DevRools
シンセティックモニタリング(機械による人工的な測定ツール):
・WebPagetest
・Catchpoint
・Gomez
・wpt-script
リアルユーザモニタリング(実ユーザのトラフィックの分析ツール):
・Google Analytics
・mPulse
・Glimpse
------------------------------------
7章 外観とパフォーマンスの両面を考慮するには
・バランスをデザイナー、開発者との折衝から導き出す
・パフォーマンス測定をワークフローの一部にする
・パフォーマンスの目標値を決めてからデザインに掛かる
------------------------------------
8章 組織の風土を変えていく
・サイトの優れたパフォーマンスを作り出し保持するための組織作り
・上層部の説得
・デザイナーと開発者の連携
・メンバの教育
・意思決定力の育成
------------------------------------
付録A HTTP/2の概要とWebパフォーマンスデザインの最適化
HTTP/1の欠点:
・一つのリクエストが完了するまで次を送ることができない
->コネクション多重で対応
HTTP/1におけるWebパフォーマンスデザイン:
・リクエスト数を減らす、同時接続数を増やす
・転送データの軽量化
HTTP/2の機能:
・1コネクションで同時複数リクエスト
・リクエストの優先度付けが可能
->サイトのレンダリングブロックなどの問題を最小限に
・FQDNごとに1コネクション、コンテンツ受信完了でも切断しない
・ヘッダー圧縮
・サーバプッシュ:クライアントのリクエストなしにレスポンスをプッシュ可能
HTTP/2におけるWebパフォーマンスデザイン
・ドメインシャーディングを見直す
->2では複数同時リクエストが可能なため、複数コネクションは不要
・リソースファイルの結合を見直す
->パケットロスの再送が起きたら遅延が大きい
・リソースのインライン化を見直す
------------------------------------
付録B 外部タグとサイトパフォーマンス 〜3rd Party tagとの付き合い方〜
・タグが原因で単一障害点になる
->外部タグサーバの障害が影響
ページ表示遅い、表示されないなどのブロックに
・タグによるユーザ端末への負荷
->CPU,メモリの切迫
導入の検討と、モニタリングを継続に行うべき
------------------------------------
以上。
へポスト