WEBフロントエンドパフォーマンスチューニング

サイトのパフォーマンスが悪いとgoogle先生に低い評価をうけます
記事の内容がいくら良くても、評価されなければ
検索結果の順位が低くなってしまいます
なんとかして改善して行きたいと思い購入しました

作者: 久保田光則
出版社/メーカー: 技術評論社
発売日: 2017/05/26
メディア: 単行本（ソフトカバー）
この商品を含むブログを見る

本の紹介
まとめ
メモ

本の紹介

３２３ページ、２８６４円です。技術書なら普通の値段ですね

1.　ウェブパフォーマンスとは何か
2.　ブラウザのレンダリングの仕組み
3.　チューニングの基礎
4.　リソース読み込みのチューニング
5.　JavaScript実行のチューニング
6.　レイアウトツリー構築のチューニング
7.　レンダリング結果の描画のチューニング
8.　高度なチューニング
9.　認知的チューニング
Appendix. SVGのパフォーマンス特性

著者について

久保田光則さんです

福岡でAspective LLC(http://aspective.io )という会社をやっている。福岡市在住。UI/UXデザイナー，ソフトウェアエンジニア。ウェブフロントエンド，ハイブリッドアプリに造詣が深い。優れたデザインとエンジニアリングを両立したソフトウェアプロダクト開発の実現を目指し日々頑張る。著書に『HTML5ハイブリッドアプリ開発[実践]入門（技術評論社，共著）』がある。

ツイッター
twitter.com

ブログ
blog.anatoo.jp

facebook
https://www.facebook.com/anatoo.jp

著者のオススメの人

・Webサイトを高速化してPV増などに結び付けたい人
・Webアプリケーションを高速化してユーザーの満足度を上げたい人
・Webフロントエンドのチューニングを基礎から知りたい人

自分のオススメの人

・フロントエンドエンジニア
・インフラエンジニア（apacheの設定とか記載してあった為）

まとめ

・知識がメインの本なので手を動かして確認する必要があないので電車でも読めます

・フロントエンジニアおよび一部の内容はWebデザイナーの人にも
知ってほしいないようでした

・データベースはエンジンの仕組みを知らないとチューニングができない。
それと同じでWEBページもブラウザの仕組みを知らないとチューニングできない
仕組みをしってベストプラクティスを知る
これぞ、技術の王道ですな

・英語ですがgoogleのエンジニアがWebパフォーマンスについて
講義してくれている無料の動画があります
本を読んでこの動画を読むとさらに理解が深まります
www.udacity.com

メモ

masalibが気になった事をメモしています

第1章・ウェブパフォーマンスとは何か

なんでフロントエンドパフォーマンスチューニングできないのか？
レタリングについて知らないから

引用

WEB開発者はHTMLやCSSをかくだけで意図する見た目の
WEBページをユーザーに見せられる一方、実際のレタリングの中でどのような
処理が行われているのか知らない
底部分が開発者がパフォーマンスチューニングを行う時の問題になる

レタリングとか意識した事がねぇｗｗｗ
　

第2章　ブラウザのレンダリングの仕組み

レンダリング
１・Loading（リソース読み込み）
２・Scripting（JS実行）
３・Rendering（スタイル）
４・Paintin（描画）
というのでわかれている

Loading（リソース読み込み）について
HTMLが読み込まれてそれに紐付いたCSSやjavascriptをがLoadingされる事だけでいいと思う
まさかネットワーク・プロトコルの話がでてきて
IPとは何かとかまで記載されていた
TLSのハンドシェイクの処理はいいと思うけどプログラマーのレベルを超えてている
この部分でDOMツーリーの構築をおこなう
またHTML内にあるjavascriptを同期実行をおこなう
この時のjavascirptの実行時にはDOMツリーの構築がブロック（一時停止）される

cssの読み込み
link要素を使った外部ファイルの読み込みとstyle要素を使ったhtmlに埋め込まれたcssを取得する
読み込まれたcssはレタリングエンジンによってCSSOMになる

Scripting（JS実行）とは
javascriprのコンパイルして実行する部分
Chromeなどは、JIT(Just in Time)
実行時にその場でコンパイルする。コンパイル時のオーバーヘッドが大きい

Rendering（スタイル）
style計算とlayoutに分かれます
style計算はDOMツリーに対してどのようなcssプロパティーが当たるの計算する
DOM要素　×　cssルール　＝＞マッチング処理数
（単純計算の場合）
DOMツリーとcssomツリーを結合してlayouttreeを作成する

cssの詳細度を試せるサイト
http://specificity.keegan.st

若干わかりにくいが自分が書いたcssの要素をコピペして確認していく

Paintin（描画）
この段階でユーザーが見る形になる
上記でつくったlayouttreeをグラフィックエンジンに渡す
このエンジンはプラットフォームによって異なる

第3章　チューニングの基礎

無意味なチューニングは害だよ
だから計測する
chromeのデベロッパーモードでチェックしていく

パフォーマンス指標　RAILという物がある
RAIL モデルでパフォーマンスを計測する | Web | Google Developers

▪️レスポンス
　入力レイテンシ（タップからペイントまで）は 100 ミリ秒未満
　ユーザーがボタンをタップする（例: ナビゲーションを開く）。
▪️アニメーション
　各フレームの処理（JS からペイントまで）は 16 ミリ秒未満
　ユーザーがページをスクロールし、指をドラッグする（例: メニューを開くため）、アニメーションを見る。ドラッグ中は、指の位置に応じてアプリでレスポンスをする（プルして更新、カルーセルのスワイプなど）。このメトリクスはドラッグの開始時点ではなく、継続中にのみ適用されます。
▪️アイドル
　メインスレッドの JS 処理ブロックは 50 ミリ秒以内
　ユーザーがページを操作していなくても、次のユーザー入力を十分処理できるようメインスレッドを利用可能な状態にする。
▪️読み込み
　ページを使用する準備が整うまで 1,000 ミリ秒以内
　ユーザーがページを読み込み、クリティカルパスコンテンツを表示する。

これを目指す！！

第4章　リソース読み込みのチューニング

若干インフラよりの内容だった

ドメインシャーディング

通常の読み込み

http://xxxx.com/image1.gif
http://xxxx.com/image2.gif
http://xxxx.com/image3.gif
   ・
   ・
http://xxxx.com/image99.gif
http://xxxx.com/image100.gif

ドメインシャーディングで読み込んだ場合

http://image1.xxxx.com/image1.gif
http://image2.xxxx.com/image2.gif
http://image3.xxxx.com/image3.gif
 ↓
http://image1..com/image99.gif
http://image3.com/image100.gif

同一ドメインの場合は並列に読み込みが６が
最大なので
ドメインをわける事で並列に読み込ませるのを増やすことができる

▪️gzipの圧縮を利用する
　jpegとかあまり意味がないのでhtmlとか拡張子を指定する。
IISは指定できないかも・・・

▪️CDNを利用する
　並列の数を増やすのもあるが海外からのアクセスに有効

▪️事前読み込み
　DNSプリフェチ
　リソースプリフェチ
　コネクションの接続
　プリレンタリング

ランディングページなどの次のページが限られている場合に有効
プリレタリングは次のページのレンタリングまでやるので
ブラウザに負担があるので注意
DNSぐらいはいいかも

cssスプライト
　画像をまとめることで読み込みを減らす
アイコン画像とかで使える
CSSスプライトについてあれこれ。