サイト高速化のメモ

CSS, JavaScript, performance, Programming | 2020年8月 | Comments (0)
このエントリーをはてなブックマークに追加
Pocket

目的

サイトを高速化して検索ランキングを改善してサイトへの流入を増やす。

以下記事でGoogleは表示速度をモバイル検索ランキングの指標とすることに言及している。
ref. https://webmaster-ja.googleblog.com/2018/01/using-page-speed-in-mobile-search.html

参考文献

  • 書籍
    • 久保田 光則 Webフロントエンド ハイパフォーマンス チューニング 技術評論社
    • 佐藤 歩,泉水 翔吾. 超速！ Webページ速度改善ガイド ── 使いやすさは「速さ」から始まる (WEB+DB PRESS plus) (Japanese Edition)
  • レンダリング処理
    • https://developers.google.com/web/fundamentals/performance/critical-rendering-path/constructing-the-object-model?hl=ja
    • https://developers.google.com/web/fundamentals/performance/critical-rendering-path/render-tree-construction?hl=ja
    • https://developers.google.com/web/fundamentals/performance/critical-rendering-path/render-blocking-css?hl=ja
    • https://developers.google.com/web/fundamentals/performance/critical-rendering-path/adding-interactivity-with-javascript?hl=ja
    • https://developers.google.com/web/fundamentals/performance/critical-rendering-path/optimizing-critical-rendering-path?hl=ja
    • https://developers.google.com/web/fundamentals/performance/critical-rendering-path/page-speed-rules-and-recommendations?hl=ja
  • DevTools
    • https://developers.google.com/web/tools?hl=en
    • https://developers.google.com/web/tools/chrome-devtools/?hl=en
    • https://developers.google.com/web/tools/chrome-devtools/evaluate-performance/timeline-tool?hl=ja
  • web.devcss
    • https://web.dev/
  • Google
    • https://webmaster-ja.googleblog.com/2020/06/evaluating-page-experience.html
    • https://support.google.com/webmasters/answer/9205520?ref_topic=7440006#about_data
    • https://developers-jp.googleblog.com/2020/05/web-vitals.html
    • https://webmasters.googleblog.com/2018/01/using-page-speed-in-mobile-search.html
  • Others
    • https://developers.google.com/web/updates/2018/09/inside-browser-part1
  • Repository
    • https://github.com/s-hiroshi/frontend-playground

HTTP/1.1 TCP同時接続数

単一のドメインに対するTCPの同時接続数は、多くのブラウザで最大6に制限されていて、HTTP/1.1ではその制限の中で複数のTCPコネクションを持つことで並行性を確保しています（

佐藤 歩,泉水 翔吾. 超速！ Webページ速度改善ガイド ── 使いやすさは「速さ」から始まる (WEB+DB PRESS plus) (Japanese Edition) (Kindle の位置No.1297-1299). Kindle 版.

TCP同時接続数は規定では2だが、現状多くのブラウザのTCP同時接続数は6となっている。
TCP同時接続が6なので、サブリソース（CSS/JavaScript/画像）のリクエスト数やファイルサイズを最適化する必要がある。

Lighthouse/PageSpeed Insights

Googleは、ページのパフォーマンスを評価するフレームワークLighthouseを公開している。
Lighthouseを手軽に使用するツールとして以下の2つがある1。
（ツールによって指標の呼び方が異なる）

ツール DevTools Lighthouse PageSpeed Insight
指標 Performance > Metrix ラボデータ

Ref.

Metrics/ラボデータ（2020/07/23現在）

  • https://web.dev/metrics/
  • https://simulate.site/cheatspeed-insights/
項目 内容 対策
First Contentful Paint(FCP)
https://web.dev/fcp/		 The First Contentful Paint (FCP) metric measures the time from when the page starts loading to when any part of the page’s content is rendered on the screen. For this metric, “content” refers to text, images (including background images), elements, or non-white elements. クリティカルレンダリングパス高速化
Largest Conetntful Paint（LCP)
https://web.dev/lcp/		 The Largest Contentful Paint (LCP) metric reports the render time of the largest image or text block visible within the viewport. FCPを改善
最大コンテンツ（メイン画像等）を最適化
Speed Index(SI)
https://web.dev/speed-index/
https://sites.google.com/a/webpagetest.org/docs/using-webpagetest/metrics/speed-index		 Speed Index measures how quickly content is visually displayed during page load. Lighthouse first captures a video of the page loading in the browser and computes the visual progression between frames. Lighthouse then uses the Speedline Node.js module to generate the Speed Index score. FCPを改善
最大コンテンツ及びビューポート（≒ファーストビュー）のコンテンツを改善
Time To Intractive（TTI）
https://web.dev/tti/
インタラクティブになるまでの時間		 条件1：FCPを開始してからメインスレッドに5秒以上の余裕が生じた時点からさかのぼって、最後のロングタスク（50ms以上のタスク)の終わり
条件2：TCPコネクションが2以下		 FCPの後に取得するリソース数およびロングタスクを改善
Total Blocking Time（TBT）
https://web.dev/tbt/		 The Total Blocking Time (TBT) metric measures the total amount of time between First Contentful Paint (FCP) and Time to Interactive (TTI) where the main thread was blocked for long enough to prevent input responsiveness. TTIが短ければ相対的にTBTも短くなる。
ロングタスクを改善
Cumulative Layout Shift（CLS）
https://web.dev/cls/		 CLS measures the sum total of all individual layout shift scores for every unexpected layout shift that occurs during the entire lifespan of the page. JavaScriptによる要素操作を改善
画像サイズ指定漏れを改善

ref.
https://github.com/GoogleChrome/lighthouse/blob/d2ec9ffbb21de9ad1a0f86ed24575eda32c796f0/docs/scoring.md#how-are-the-scores-weighted

クリティカルレンダリングパス

クリティカルレンダリングパスとは

ページは、Loading -> Scripting -> Rendering -> Paintingを経て表示される。この処理をクリティカルレンダリングパスと呼ぶ（フレームともいう）。

  1. Loading
    1. リソースのロード（Load）
    2. 解析（Parse）
      Parseにはdocument.write()といったJavaScriptの解析も含む

      • DOMツリー構築
      • CSSOM（CSS Object Model）ツリー構築
  2. Scripting
  3. Rendering：LoadingとScriptingで作成されたDOMツリーとCSSOMツリーをもとにして、スタイル計算とレイアウト処理を行ってレンダリングツリー（StyleTreeともいう）を構築
    1. スタイル計算（Calculate Style）
    2. レイアウト処理（Layout）
  4. Paint：レンダリングツリーをもとに実際にブラウザに描画
    1. Paint：2次元描画命令発行
    2. Rasterize：Paintで発行された命令を元にピクセルを作成（≒レイヤーを作成）
    3. Composite Layouts：すべてのレイヤーを処理

Webサイト高速化のおおきな作業の1つが上記クリティカルレンダリングパスの高速化である。

ref.

  • Webフロントエンド ハイパフォーマンス チューニング 久保田 光則
  • https://developers.google.com/web/fundamentals/performance/critical-rendering-path?hl=ja

クリティカルレンダリングパスをブロックする処理

CSSとJavaScriptのロード中は、DOMツリーやCSSOMツリーに影響を与える可能性があるためレンダリング処理をブロックします。

佐藤 歩,泉水 翔吾. 超速！ Webページ速度改善ガイド ── 使いやすさは「速さ」から始まる (WEB+DB PRESS plus) (Japanese Edition) (Kindle の位置No.1426-1427). Kindle 版.

JavaScriptによるクリティカルレンダリングパスのブロック

以下リンクは、JavaScriptの動作をわかりやすく解説している。
当文章のJavaScript部分は基本的に以下リンク先を引用したもの。

  • https://developers.google.com/web/fundamentals/performance/critical-rendering-path/adding-interactivity-with-javascript?hl=ja
  • https://developers.google.com/web/fundamentals/performance/critical-rendering-path/analyzing-crp?hl=ja

概要

  • JavaScript は非同期（async, defer）であると明示的に宣言されていない場合、DOM構築をブロック
  • JavaScript は、DOM と CSSOM に対するクエリ（問い合わせ）と変更が可能
  • JavaScript の実行は CSSOM をブロック

※ 外部CSSも含めてCSSはDOMツリー構築をブロックしない。
しかしJavaScriptが現れた時点で、CSSにアクセスする可能性が発生するので、記載位置より前にあるCSSをすべてロードするまでDOM構築はブロックされる。

詳細

  1. HTMLパーサーが script タグを検知
  2. DOM構築のプロセスを一時中断して、JavaScript エンジンに制御を渡す
  3. JavaScriptエンジンがスクリプトを実行
  4. 実行が完了すると、ブラウザは中断前の位置に戻り、そこから DOM 構築を再開

レンダリングに関するイベント

DOMContentLoaded

DOMツリーとCSSOMツリーの作成が完了した時点。

load

サブリソースも含めてロードが完了した時点。

クリティカルレンダリングパス高速化

以下のリンク内容を実行
https://developers.google.com/web/fundamentals/performance/critical-rendering-path/optimizing-critical-rendering-path?hl=ja

改善の基本

  1. サイズの大きいリソースの調査と改善（データの転送量をなるべく小さくすること）
    • サイズが大きいファイルはダウンロードに時間がかかる
    • HTTP/1.1においては同時接続数の1つを占有
    • 他リソースのダウンロードを阻害
    • 画像最適化
    • HTML/CSS/JavaScriptを最小化（Minify）
  2. リクエスト数の調査と改善（データの転送回数をなるべく少なくすること）
    • リソース（ファイル）を結合
    • 不必要なリソースの削除
    • 画像の遅延ロード
    • キャッシュを使用
  3. 待機時間が長いリクエストの調査と改善（データの転送距離をなるべく短くすること）
    • キャッシュを利用
    • CDNを利用

佐藤 歩,泉水 翔吾. 超速！ Webページ速度改善ガイド ── 使いやすさは「速さ」から始まる (WEB+DB PRESS plus) (Japanese Edition) (Kindle の位置No.2070). Kindle 版.

改善リスト

  • JS/CSS/画像を結合（HTTP1.1が前提）
    • 同時接続数への改善
    • TCPハンドシェイクへの対策
  • HTML/JS/CSSを最小化（Minify）
  • 画像を最適化
    • ImageOptimaによる最適化
    • 動画形式WebPを導入 次世代フォーマットでの画像の配信
    • デバイスごとに最適な画像を配信（pictureタグ）
  • JS非同期読込（外部CSSdefer/async属性）
  • CSS遅延読込
  • 画像遅延読込
    • Google Chromeのloading="lazy"
  • ファーストビューのCSSをインライン化
  • web fontのpreload

最小化

  • htmlminifier：https://github.com/kangax/htmlminifier
  • cssnano：https://github.com/beneb/cssnano ※ 一番使用率が高いので、特別な理由がない限り使用
  • uglifyes：https://github.com/mishoo/UglifyJS2

佐藤 歩,泉水 翔吾. 超速！ Webページ速度改善ガイド ── 使いやすさは「速さ」から始まる (WEB+DB PRESS plus) (Japanese Edition) (Kindle の位置No.1989-1997). Kindle 版.

WebPを使用

  1. WebPへ変換
  2. .htaccessを使って画像リクエストに対してwebpを返す
    • https://blog.ideamans.com/2019/02/webphtaccess.html

ディレクトリ内画像をexample.jpg -> example.jpg.webpに一括変換。
ref.https://qiita.com/ishimasar/items/bf92e22004fcaf870d9b

$ for file in *; do cwebp "$file" -o "${file%}.webp"; done

web fontのpreloadとページ速度改善

web fontファイルは、preloadしない場合は呼び出しもとがダウンロードされて、フォントが適用（解釈）されるときに、逐次的にロードされる。
（逆に言えば、フォントが利用されていなければフォントファイルはロードされない）

使用されることがわかっている場合は、preloadすることによって呼び出し元と並列でロードできる可能性が高まる。

CDN

  • https://developers.google.com/speed/libraries
  • https://www.cloudflare.com/ja-jp/

キャッシュ

ブラウザキャッシュ

ブラウザキャッシュはすでにキャッシュされたのもをサーバー側で強制的にクリアすることはできない。
やるとしたら以下が可能な場合のみか。

対象MIMEタイプの全ファイルにデプロイ時にプレフィックスを付与できる場合。

例）スタイルとしてbootstrap.min.cssとstyle.min.cssしかなくデプロイ時に以下のようなサフィックスを付与可能な環境

  • bootstrap.min.css?{{timestamp}}
  • style.min.css?{{timestamp}}

.htaccessのブラウザキャッシュ設定例

<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/x-icon "access plus 6 months"
ExpiresByType text/css "access plus 1 months"
</IfModule>

ref.
https://lpeg.info/html/htaccess_cache.html

  • 現実的には採用は難しい
  • faviconは可能かも

備考

画像最適化ツール

  • ImageOptim：https://imageoptim.com/howto.html
  • WepP
    • https://squoosh.app/ オンライン
    • https://developers.google.com/speed/webp/docs/cwebp コマンドライン brewでインストール
  • WordPressプラグイン
    • https://wordpress.org/plugins/search/convert+webp/
    • EWWW Image Optimizer

  1. その他に、コマンドラインツールなども提供されている。 ↩

コメント

No comments yet.

コメントの投稿

改行と段落タグは自動で挿入されます。
メールアドレスは表示されません。

 


©2017 FindxFine, 2017 All Right Reserved