Skip to content

Latest commit

 

History

History
744 lines (516 loc) · 55.6 KB

README.md

File metadata and controls

744 lines (516 loc) · 55.6 KB
Raw


Front-End Performance Checklist

  Front-End Performance Checklist  

🎮 何よりも早く動作するための唯一のフロントエンドパフォーマンスチェックリストです。

シンプルなルール: "パフォーマンスを考慮してデザイン・コーディングすること"

      PRs Welcome         Discord           Licence MIT  

  使い方 • Contributing • ロードマップ • Product Hunt

🇨🇳 🇫🇷 🇰🇷 🇵🇹 🇷🇺

Other Checklists:
🗂 Front-End Checklist • 💎 Front-End Design Checklist

Table of Contents

  1. HTML
  2. CSS
  3. Fonts
  4. Images
  5. JavaScript
  6. サーバ （作成中）
  7. JS Frameworks （作成中）

はじめに

パフォーマンスは大きなテーマですが、いつも "バックエンド" や "管理者" の問題というわけではありません。フロントエンドの責任範囲でもあります。このフロントエンドパフォーマンスチェックリストは、フロントエンド開発者としてプロジェクト（個人でも業務でも）に充たる場合に、確認もしくは気にしておくべき項目を網羅的にリストアップしたものです。

使い方

各ルールには、このルールが重要である 理由 と 修正する 方法 を記載しています。より詳細な情報は、 🛠: ツール、 📖: 記事、 📹: 動画サイト のリンクを参照してください。

フロントエンドパフォーマンスチェックリスト は、どれも最高のパフォーマンススコアを達成するためには不可欠な項目ですが、どのルールを優先的に適用すべきかを３段階で示しています。

  • Low は、優先度が 低 であることを意味しています。
  • Medium は、優先度が 中 であることを意味しています。 このルールの適用を避けるべきではありません。
  • High は、優先度が 高 であることを意味しています。 このルールに従い、推奨される方法で実装してください。

パフォーマンスツール

ウェブサイト または アプリケーションのテストやモニタリングに使用できるツールのリスト:

参考文献

HTML

html

  • HTML の軽量化（Minified）: medium HTML コードは圧縮され、コメント、空白、改行が本番のファイルから削除されていること。

    理由:

    不要なスペース、コメント、ブレークを全て削除すると、HTML のサイズが小さくなり、サイトのページの読み込み時間が短縮され、ユーザのダウンロードにかかる時間が明らかに軽減されます。

    方法:

    ほとんどのフレームワークには、Web ページを容易に圧縮することができるプラグインがあります。自動的にジョブを実行できる多くの NPM モジュールを使用できます。

  • 不要なコメントの削除: low コメントがページから削除されていることを確認してください。

    理由:

    コメントはユーザにとって何も役に立たないので、本番のファイルからは削除すべきです。コメントを保持したくなるケースは、ライブラリのソースを保持する必要がある場合くらいです。

    方法:

    ほとんどの場合、コメントは HTML 圧縮プラグインを使って削除することができます。

  • 不要な属性の削除: low type="text/javascript" や type="text/css" のようなタイプ属性は、もはや必要ではないため削除すべきです。

    <!-- Before HTML5 -->
<script type="text/javascript">
    // JavaScript code
</script>

<!-- Today -->
<script>
    // JavaScript code
</script>

    理由:

    HTML5 ではデフォルトで text/css と text/javascript が含まれているため、タイプ属性は必要ありません。未使用のコードはページを重くするため、ウェブサイトやアプリで使用されないコードは削除すべきです。

    方法:

    すべての <link> および <script> タグに type 属性がないことを確認してください。

  • CSS タグは必ず JavaScript タグの前に配置: high 必ず CSS が JavaScript コードの前にロードされることを確認してください。

    <!-- Not recommended -->
<script src="jquery.js"></script>
<script src="foo.js"></script>
<link rel="stylesheet" href="foo.css"/>

<!-- Recommended -->
<link rel="stylesheet" href="foo.css"/>
<script src="jquery.js"></script>
<script src="foo.js"></script>

    理由:

    JavaScript の前に CSS タグを置くと、より効率的な並列ダウンロードが可能となり、ブラウザのレンダリング時間が短縮されます。

    方法:

    <head> 内の <link> と <style> が、常に <script> の前にあることを確認してください。

  • iframe の数を最小限に抑える: high iframe は他の技術的な可能性がない場合にのみ使用してください。できる限り iframe の使用を避けましょう。

  • prefetch、dns-prefetch、prerender での事前読み込みによる最適化: low 一般的なブラウザでは、<link>タグに "rel" 属性のディレクティブ指定することで特定の URL を事前読み込みすることができます。

    理由:

    事前読込み（Prefetching）により、ブラウザはユーザが近い将来アクセスする可能性のあるコンテンツの表示に必要なリソースを事前に取得しておくことができます。ブラウザはこれらのリソースをキャッシュに保存するので、コンテンツが異なるドメインを使っている場合でも Web ページの読み込みを高速化できます。 Web ページの読み込みが完了し、アイドル時間が経過すると、ブラウザは他のリソースのダウンロードを開始します。ユーザが特定のリンク（事前読み込み済み）にアクセスすると、コンテンツは即時に提供されます。

    方法:

    ⁃ <link> タグが<head> タグ内に あることを確認してください。

⬆ トップに戻る

CSS

css

  • ファイルの軽量化（minification）: high すべての CSS ファイルは圧縮され、コメント、空白、改行が本番のファイルから削除されています。

    理由:

    CSS ファイルの圧縮を行うと、コンテンツの読み込み時間が早くなりクライアントに送信されるデータが少なくなります。常に本番用の CSS ファイルは圧縮されていることが重要です。帯域幅やリソース使用量を削減したいビジネスユーザにとって有益です。

    方法:

    ⁃ ビルドまたはデプロイメントの前または途中でファイルを自動的に圧縮するツールを使用します。

  • ファイルの結合: medium CSS ファイルを1ファイルに結合します。 （HTTP/2 では常に有効とは限りません）

    <!-- Not recommended -->
<link rel="stylesheet" href="foo.css"/>
<link rel="stylesheet" href="bar.css"/>

<!-- Recommended -->
<link rel="stylesheet" href="foobar.css"/>

    理由:

    まだ HTTP/1 を使用していれば、ファイルを結合する必要があるかもしれません。もしサーバが HTTP/2 を使用している場合はその限りではありません。（テストを行う必要があります）

    方法:

    ⁃ ビルド前かビルド中、もしくはデプロイ前かデプロイ中に、オンラインのツールもしくはプラグインを使ってファイルを結合します。
    ⁃ もちろん、結合によりプロジェクトが壊れないかどうかは確認してください。

  • ノンブロッキング: high DOM の読み込みに時間がかかるのを防ぐため、CSS ファイルはノンブロッキングである必要があります。

    <link rel="preload" href="global.min.css" as="style" onload="this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="global.min.css"></noscript>

    理由:

    CSS ファイルは、ページの読み込みをブロックしレンダリングを遅延させる可能性があります。preload を使用すると、ブラウザがページのコンテンツを表示し始める前に CSS ファイルを読み込ませることができます。

    方法:

    ⁃ preload の値を持つ rel 属性と、as="style" を <link> 要素に追加する必要があります。

  • CSS クラスの長さ: low クラスの長さは（最終的に）HTML ファイルと CSS ファイルに（わずかな）影響を与える可能性があります。

    理由:

    パフォーマンスへの影響も議論の余地がありますが、プロジェクトの命名規則を決めておくと、スタイルシートの保守性に大きな影響を与える可能性があります。BEM を使用する場合、必要以上の文字がクラスに含まれることがあります。名前や名前空間をしっかりと考え選択することは常に重要です。

    方法:

    文字数に制限を設定することは一部の人にとっては興味深いことですが、ウェブサイトをコンポーネントに分割することで、クラス（および宣言）の数と長さを減らすことができます。

  • 未使用の CSS: medium 未使用の CSS セレクタを削除する。

    理由:

    未使用の CSS セレクタを削除すると、ファイルサイズが削減できアセットの読み込みも早くなります。

    方法:

    ⁃ ⚠️ 使用する CSS フレームワークにリセット CSS/ノーマライズ CSS のコードが含まれていないかどうかを常に確認してください。リセット CSS/ノーマライズ CSS ファイルに記載されている全てのコードを必要としない場合があります。

  • 埋め込み または インライン CSS: high <body> 内で埋め込み CSS、またはインライン CSS を使うのは避けましょう。 （HTTP/2 では無効）

    理由:

    最初の理由の一つは、コンテンツをデザインから分離 することがグッドプラクティスだからです。コードの保守性が向上し、サイトのアクセシビリティも向上します。パフォーマンスに関して言うと、HTML ページのファイルサイズと読み込み時間を短縮することができます。

    方法:

    常に外部スタイルシートを使用するか、<head> に CSS を埋め込みます。（他の CSS パフォーマンスルールに従います）

  • スタイルシートの複雑さを分析する: high スタイルシートを分析すると、CSS セレクタの問題、冗長性、重複を見つけるのに役立ちます。

    理由:

    CSS に冗長性や検証エラーがある場合は、CSS ファイルを分析しこれらの複雑なコードを削除すると、CSS ファイルの読み込みが高速化されます。（ブラウザが高速に読み取るためです）

    方法:

    CSS プリプロセッサを使用して、CSS を整理する必要があります。下記のオンラインツールの一部はコードの分析と修正にも役立ちます。

⬆ トップに戻る

Fonts

fonts

  • ウェブフォント フォーマット: medium ウェブプロジェクトまたはアプリケーションで WOFF2 を使用しています。

    理由:

    Google によると、WOFF 2.0 ウェブフォントの圧縮フォーマットは、WOFF 1.0 よりも平均30%向上します。その場合、WOFF 2.0、WOFF 1.0 をフォールバックおよび TTF として使用することをお勧めします。

    方法:

    新しいフォントを購入する前に、プロバイダが WOFF2 フォーマットを提供しているかことを確認してください。フリーフォントを使用している場合は、常に Font Squirrel を使用して必要なすべてのフォーマットを生成することができます。

  • フォントをより速く読み込むには、preconnect を使用します: medium

    <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>

    理由:

    ウェブサイトにアクセスしたら、デバイスはそのサイトがどこにあり、どのサーバに接続する必要があるか検出する必要があります。ブラウザは、リソース（フォント、CSS ファイル...）を取得する前に、DNS サーバに接続し、ルックアップが完了するのを待つ必要がありました。プリフェッチとプリコネクトを使用すると、ブラウザは DNS 情報を検索して、フォントファイルをホストしているサーバへの TCP 接続の確立を開始できます。これにより、ブラウザがフォント情報を含む CSS ファイルを解析し、サーバからフォントファイルを要求する必要があることを検出するまでに、DNS 情報が事前に解決され、サーバへのオープン接続がコネクションプールに用意されているため、パフォーマンスが向上します。

    方法:

    ⁃ ウェブフォントをプリフェッチする前に、webpagetest を使ってウェブサイトを評価しましょう
    ⁃ 青緑色の DNS ルックアップを探して、要求されたホストをメモしてください
    ⁃ ウェブフォントを <head> の中でプリフェッチし、最終的にはプリフェッチする必要があるホスト名も追加してください

  • ウェブフォント サイズ: medium ウェブフォントのサイズは 300kb 以下です（含まれているすべてのバリエーション）

  • フラッシュまたは不可視テキストの防止: medium ウェブフォントが読み込まれるまでは、テキストを透過させないようにします

⬆ トップに戻る

Images

images

  • ベクター画像かラスター/ビットマップを使用: medium ビットマップ画像よりもベクター画像を使用することをお勧めします（可能な場合）。

    理由:

    ベクター画像 (SVG) はサイズが小さくなる傾向があり、レスポンシブでスケールすることができます。またこれらの画像は、CSS を使ってアニメーションしたり変更したりできます。

  • 画像の大きさ: medium レンダリング時の画像サイズがわかっている場合は、<img> タグに width と height の属性を設定します。

    理由:

    あらかじめ画像に高さと幅が設定されていれば、ページをローディングする時に画像表示に必要なスペースが確保されますが、もしこれらの属性が設定されていなければ、ブラウザは画像のサイズを認識できず適切なスペースを確保することができません。これにより、ページ（画像ファイル）のローディング中に、レイアウトが変更されるという影響が出てしまいます。

  • Base64 画像の使用を避ける: medium 小さな画像であれば base64 に変換することもできますが、実際これはベストプラクティスではありません。

  • Lazy loading（遅延読み込み）: medium オフスクリーン画像（ブラウザに初期表示されない画像）は遅延ロードします（noscript フォールバックは常に提供されます）。

    理由:

    表示画面の応答時間を短縮し、ユーザーが必要としない不要な画像の読み込みを回避することができます。

    方法:

    ⁃ Lighthouse を使用して、オフスクリーン画像 の数を特定します。
    ⁃ 以下のような JavaScript プラグインを使用して、画像の遅延読み込みを行います。必ずオフスクリーン画像のみを遅延読み込み対象にしてください。
    ⁃ また、マウスオーバー時やユーザー操作時に表示される代替画像も遅延読み込みするようにしてください。

  • レスポンシブ画像: medium ディスプレイサイズに近い画像を利用するようにしてください。

    理由:

    画面が小さいデバイスでは、ビューポートよりも大きな画像を必要としません。1つの画像をそれぞれの異なるサイズで複数枚用意しておくことをお勧めします。

    方法:

    ⁃ ターゲットとするデバイス用に異なる画像サイズを作成します。
    ⁃ srcset 属性や picture タグを使用して、各画像の複数のバリエーションを配信します。

⬆ トップに戻る

JavaScript

javascript

  • JS 圧縮: high 全ての JavaScript ファイルが圧縮され、コメント、空白、および改行がプロダクションファイルから削除されます （HTTP/2を使用している場合でも有効です）。

    理由:

    不要なスペース、コメント、ブレークをすべて削除すると、JavaScript ファイルのサイズが小さくなり、サイトのページの読み込み時間が短縮され、ユーザのダウンロードが明らかに軽くなります。

    方法:

    ⁃ 以下に示すツールを使用して、ビルドまたはデプロイメントの前か最中にファイルを自動的に圧縮します。

  • JavaScriptを内部には無記載 : medium （ウェブサイトでのみ有効です） body 内部に複数の JavaScript コードを埋め込むことは避けてください。JavaScript コードを外部ファイル内に、最終的には <head> 、またはページの最後（</body> の前）で再グループ化します。

    理由:

    JavaScript の埋め込みコードを直接 <body> に配置すると、DOM の構築中にページが読み込まれるため、ページの速度が低下する可能性があります。 最適なオプションは、DOM のブロックを回避するために、async または defer で外部ファイルを使用することです。 別のオプションは、<head> 内にいくつかのスクリプトを配置することです。<head> に配置するスクリプトは、ほとんどの場合、DOM がメイン処理に到達する前にロードする必要がある分析コードまたは小さなスクリプトです。

    方法:

    すべてのファイルが async または defer を使用してロードされていることを確認し、<head> に挿入する必要があるコードかどうか見極めましょう。

  • ノンブロッキング JavaScript: high JavaScript ファイルは、async を使用して非同期でロードされるか、defer 属性を使用して遅延ロードされます。

    <!-- Defer 属性 -->
<script defer src="foo.js"></script>

<!-- Async 属性 -->
<script async src="foo.js"></script>

    理由:

    JavaScript は、通常の HTML ドキュメント解析をブロックするため、パーサが <script> タグに到達すると（特に <head> 内にある）、フェッチと実行を停止します。スクリプトをページの上部に配置する場合は async または defer を追加することを強く推奨しますが、</ body> タグの直前ではあまり効果がありません。ただし、これらの属性を常時使用し、パフォーマンスの問題を回避することが望ましいです。

    方法:

    ⁃ スクリプトタグの属性として、async（スクリプトが他のスクリプトに依存していない場合）または defer（スクリプトが他のスクリプトに依存、または非同期スクリプトに依存している場合）を追加します。
    ⁃ 小さなスクリプトは、非同期スクリプトの上にインラインスクリプトで配置することをお勧めします。

  • 最適化およびアップデートされた JS ライブラリ: medium プロジェクトで使用される全ての JavaScript ライブラリが必要であって（単純な機能についてはバニラ JavaScript を推奨）、JavaScript ライブラリを最新バージョンへアップデートし、不必要なメソッドで JavaScript をうめつくさないでください。

    理由:

    ほとんどの場合、新しいバージョンには最適化とセキュリティ修正が含まれています。最適化されたコードでプロジェクトを高速化し、古いプラグインを使うことなく、ウェブサイトまたはアプリの速度を落とさないようにしてください。

    方法:

    プロジェクトで NPM パッケージを使用している場合、npm-check は、ライブラリをアップグレード／アップデートするための非常に興味深いライブラリです。 Greenkeeper は、依存関係を自動的に探し、新しいバージョンがリリースされる度にアップデートを提案します。

⬆ トップに戻る

サーバ

![サーバサイド]

  • ウェブサイトが HTTPS を使用していること: high

    理由:

    HTTPS は、 e コマースウェブサイトだけではなく、データをやりとりする全てのウェブサイト用です。データとは、ユーザが共有するデータ、または外部エンティティと共有するデータです。今時の最新ブラウザは安全でないサイトの機能を制限しています。例えば、インスタンスが HTTPS を使用していない場合、位置情報、プッシュ通知、および Service Worker は機能しません。また、現在は SSL 証明書を使用したプロジェクトのセットアップが、以前よりもはるかに簡単になりました。（そして、 Let's Encrypt のおかげで無料です。）

  • HTTP リクエストの最小化: high リクエストされている全てのファイルが、ウェブサイトまたはアプリケーションに不可欠であることを常に確認してください。
  • CDN を使用してアセットを配信: medium CDN を利用して、コンテンツをより速く世界中に配信します。

  • 同じプロトコルからファイルを提供: high 例えば、 HTTPS を使用しているウェブサイトで、 HTTP を使用したソースからファイルを提供するウェブサイトを作成しないでください。ウェブサイトが HTTPS を使用している場合、外部ファイルは同じプロトコルから取得する必要があります。

  • 到達可能なファイルを提供: high 到達不能なファイルへのリクエストを避けます（404）。

  • HTTP キャッシュヘッダを適切に設定: high HTTP ヘッダを設定して、ブラウザとサーバ間の往復コストを回避します。
  • GZIP / Brotli 圧縮の有効化: high GZIP や Brotli などの圧縮方法を利用して、 JavaScript ファイルのサイズを小さくします。ファイルのサイズを小さくすると、ユーザはアセットをより速くダウンロードできるようになり、パフォーマンスが向上します。

⬆ トップに戻る

パフォーマンスと JS フレームワーク

Angular

React

Vue

パフォーマンスと CMS

WordPress

記事

推奨プラグイン

翻訳

Front-End Performance Checklist は、他言語でも利用できるようにしたいと考えています!迷わず投稿してください!

貢献する

Issue やプルリクエストをオープンして、変更や追加を提案してください。

サポート

質問や提案があれば、遠慮なく Discord や Twitter を利用して下さい:

著者

**Build with ❤️ by David Dias

貢献者

このプロジェクトは、ご協力いただいた皆様のおかげで成り立っています。 [貢献する].

後援者

ご支援いただいた皆様、ありがとうございました! 🙏 [後援者になる]

スポンサー

スポンサーになってこのプロジェクトをサポートしてください。スポンサーのロゴは、ウェブサイトへのリンクと共にここに表示されます。[スポンサーになる]

ライセンス

MIT

アイコンはすべて Icons8 によって提供されています。

⬆ トップに戻る