Awesome

<h1 align="center"> <br> <a href="https://github.com/thedaviddias/Front-End-Performance-Checklist"><img src="https://raw.githubusercontent.com/thedaviddias/Front-End-Performance-Checklist/master/images/logo-front-end-performance-checklist.jpg" alt="Front-End Performance Checklist" width="170"></a> <br> <br> Front-End Performance Checklist <br> </h1> <h4 align="center">🎮 何よりも早く動作するための唯一のフロントエンドパフォーマンスチェックリストです。</h4> <p align="center">シンプルなルール: "パフォーマンスを考慮してデザイン・コーディングすること"</p> <p align="center"> <a href="http://makeapullrequest.com"> <img src="https://img.shields.io/badge/PRs-welcome-brightgreen.svg?style=flat-square" alt="PRs Welcome"> </a> <a href="https://discord.gg/btHQRkm"> <img src="https://img.shields.io/badge/chat-on_discord-4837E2.svg?style=flat-square" alt="Discord"> </a> <a href="https://opensource.org/licenses/MIT"> <img src="https://img.shields.io/badge/license-MIT-blue.svg?style=flat-square" alt="Licence MIT"> </a> </p> <p align="center"> <a href="#使い方">使い方</a> • <a href="#contributing">Contributing</a> • <a href="http://feedback.frontendchecklist.io/">ロードマップ</a> • <a href="https://www.producthunt.com/posts/front-end-performance-checklist">Product Hunt</a> </p> <p align="center"> <a href="https://github.com/JohnsenZhou/Front-End-Performance-Checklist">🇨🇳</a> <a href="https://github.com/WilliamDASILVA/Front-End-Performance-Checklist">🇫🇷</a> <a href="https://github.com/ParkSB/Front-End-Performance-Checklist">🇰🇷</a> <a href="https://github.com/fernandofawkes/Front-End-Performance-Checklist">🇵🇹</a> <a href="https://github.com/lex111/Front-End-Performance-Checklist">🇷🇺</a> </p> <p align="center"> <span>Other Checklists:</span> <br> 🗂 <a href="https://github.com/thedaviddias/Front-End-Checklist#---------front-end-checklist-">Front-End Checklist</a> • 💎 <a href="https://github.com/thedaviddias/Front-End-Design-Checklist#front-end-design-checklist">Front-End Design Checklist</a> </p>

HTML
CSS
Fonts
Images
JavaScript
サーバ（作成中）
JS Frameworks （作成中）

はじめに

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

使い方

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

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

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

パフォーマンスツール

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

🛠 WebPagetest - Website Performance and Optimization Test
🛠 ☆ Dareboost: Website Speed Test and Website Analysis (use the coupon WPCDD20 for -20%)
🛠 Treo: Page Speed Monitoring
🛠 GTmetrix | Website Speed and Performance Optimization
🛠 PageSpeed Insights
🛠 Web.dev
🛠 Pingdom Website Speed Test
📖 Make the Web Faster | Google Developers
🛠 Sitespeed.io - Welcome to the wonderful world of Web Performance
🛠 Calibre
🛠 Website Speed Test | Check Web Performance » Dotcom-Tools
🛠 Website and Server Uptime Monitoring - Pingdom (Free Signup Link)
🛠 Uptime Robot
🛠 SpeedCurve: Monitor front-end performance
🛠 PWMetrics - CLI tool and lib to gather performance metrics
🛠 Varvy - Page speed optimization
🛠 Lighthouse - Google
🛠 Checkbot browser extension - Checks for web performance best practices
🛠 Yellow Lab Tools | Online test to help speeding up heavy web pages
🛠 Speedrank - Web Performance Monitoring
🛠 DebugBear - Monitor website performance and Lighthouse scores
🛠 packtracker.io - Check your webpack bundle size on every pull request.
🛠 Exthouse - Analyze the impact of a browser extension on web performance

参考文献

HTML

html

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

理由:

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

方法:

ほとんどのフレームワークには、Web ページを容易に圧縮することができるプラグインがあります。自動的にジョブを実行できる多くの NPM モジュールを使用できます。
- 🛠 HTML minifier | Minify Code
- 🛠 Online HTML Compressor
- 📖 Experimenting with HTML minifier — Perfection Kills
不要なコメントの削除: コメントがページから削除されていることを確認してください。

理由:

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

方法:

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

🛠 remove-html-comments - npm

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

<script type="text/javascript">
    // JavaScript code
</script>


<script>
    // JavaScript code
</script>
```
理由:

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

方法:

すべての <link> および <script> タグに type 属性がないことを確認してください。
- 📖 The Script Tag | CSS-Tricks
CSS タグは必ず JavaScript タグの前に配置: 必ず CSS が JavaScript コードの前にロードされることを確認してください。
```

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


<link rel="stylesheet" href="foo.css"/>
<script src="jquery.js"></script>
<script src="foo.js"></script>
```
理由:

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

方法:

<head> 内の <link> と <style> が、常に <script> の前にあることを確認してください。
- 📖 Ordering your styles and scripts for pagespeed
iframe の数を最小限に抑える: iframe は他の技術的な可能性がない場合にのみ使用してください。できる限り iframe の使用を避けましょう。
prefetch、dns-prefetch、prerender での事前読み込みによる最適化: 一般的なブラウザでは、<link>タグに "rel" 属性のディレクティブ指定することで特定の URL を事前読み込みすることができます。

理由:

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

方法:

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

⬆ トップに戻る

CSS

css

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

理由:

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

方法:

⁃ ビルドまたはデプロイメントの前または途中でファイルを自動的に圧縮するツールを使用します。
ファイルの結合: CSS ファイルを1ファイルに結合します。 （HTTP/2 では常に有効とは限りません）
```

<link rel="stylesheet" href="foo.css"/>
<link rel="stylesheet" href="bar.css"/>


<link rel="stylesheet" href="foobar.css"/>
```
理由:

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

方法:

⁃ ビルド前かビルド中、もしくはデプロイ前かデプロイ中に、オンラインのツールもしくはプラグインを使ってファイルを結合します。 <br> ⁃ もちろん、結合によりプロジェクトが壊れないかどうかは確認してください。
- 📖 HTTP: Optimizing Application Delivery - High Performance Browser Networking (O'Reilly)
- 📖 Performance Best Practices in the HTTP/2 Era
ノンブロッキング: 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 クラスの長さ: クラスの長さは（最終的に）HTML ファイルと CSS ファイルに（わずかな）影響を与える可能性があります。

理由:

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

方法:

文字数に制限を設定することは一部の人にとっては興味深いことですが、ウェブサイトをコンポーネントに分割することで、クラス（および宣言）の数と長さを減らすことができます。
- 🛠 long vs short class · jsPerf
未使用の CSS: 未使用の CSS セレクタを削除する。

理由:

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

方法:

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

クリティカル CSS: クリティカル CSS（または above the fold）とは、ファーストビューのレンダリングに使用されるすべての CSS です。主要な CSS の読み込み前にこれを <style></style> タグにインライン化（可能な限り圧縮）して記載します。

理由:

インライン化したクリティカル CSS を使用すると、Web ページのレンダリングを高速化し、サーバへのリクエスト回数を減らすことができます。

方法:

オンラインツール、または Addy Osmani が開発したようなプラグインを使用してクリティカル CSS を生成することができます。
- 📖 Understanding Critical CSS
- 🛠 Critical by Addy Osmani on GitHub automates this.
- 📖 Inlining critical CSS for better web performance | Go Make Things
- 🛠 Critical Path CSS Generator - Prioritize above the fold content :: SiteLocity
- 📖 Reduce the size of the above-the-fold content

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

理由:

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

方法:

常に外部スタイルシートを使用するか、<head> に CSS を埋め込みます。（他の CSS パフォーマンスルールに従います）
- 📖 Observe CSS Best Practices: Avoid CSS Inline Styles
スタイルシートの複雑さを分析する: スタイルシートを分析すると、CSS セレクタの問題、冗長性、重複を見つけるのに役立ちます。

理由:

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

方法:

CSS プリプロセッサを使用して、CSS を整理する必要があります。下記のオンラインツールの一部はコードの分析と修正にも役立ちます。
- 🛠 TestMyCSS | Optimize and Check CSS Performance
- 🛠 CSS Stats
- 🛠 macbre/analyze-css: CSS selectors complexity and performance analyzer
- 🛠 Project Wallace は CSS Stats に似ていますが、変更を追跡できるように統計結果を長期間保存します。

⬆ トップに戻る

Fonts

fonts

📖 A Book Apart, Webfont Handbook

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

理由:

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

方法:

新しいフォントを購入する前に、プロバイダが WOFF2 フォーマットを提供しているかことを確認してください。フリーフォントを使用している場合は、常に Font Squirrel を使用して必要なすべてのフォーマットを生成することができます。
フォントをより速く読み込むには、preconnect を使用します:
```
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
```
理由:

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

方法:

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

📖 Font Bytes - Page Weight

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

⬆ トップに戻る

Images

images

📖 Image Bytes in 2018
画像の最適化: エンドユーザーに直接影響を与えることなく画像を圧縮し、最適化してください。

理由:

最適化された画像はより高速にブラウザに読み込まれるため、データの消費が少なくなります。

方法:

⁃ 可能であれば、CSS3 エフェクトを使用してください（小さな画像の代わりに） <br> ⁃ 可能であれば、画像にはテキストエンコードの代わりにフォントを使用してください <br> ⁃ SVG を使用してください <br> ⁃ ツールを使って、圧縮レベルを 85 未満に指定してください
画像形式: 画像形式を適切に選んでください。

理由:

画像が原因で Web サイトの速度を低下させないようにするには、画像に適した形式を選びます。写真の場合、PNG や GIF よりも JPEG が適しています。ただし、ファイルのサイズを削減できる next-gen 形式を確認することを忘れないでください。各画像形式には長所と短所がありますが、最も良い選択をするためにこれらのことを知っておくことが重要です。

方法:

⁃ Lighthouse を使用して、画像が next-gen 形式（JPEG 2000m、JPEG XR、WebP など）を使用できるかを特定します。 <br> ⁃ 複数の異なる画像形式を比較してください。PNG8 よりも PNG16 を使用する方が良い場合もあります。

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

理由:

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

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

理由:

あらかじめ画像に高さと幅が設定されていれば、ページをローディングする時に画像表示に必要なスペースが確保されますが、もしこれらの属性が設定されていなければ、ブラウザは画像のサイズを認識できず適切なスペースを確保することができません。これにより、ページ（画像ファイル）のローディング中に、レイアウトが変更されるという影響が出てしまいます。
Base64 画像の使用を避ける: 小さな画像であれば base64 に変換することもできますが、実際これはベストプラクティスではありません。
Lazy loading（遅延読み込み）: オフスクリーン画像（ブラウザに初期表示されない画像）は遅延ロードします（noscript フォールバックは常に提供されます）。

理由:

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

方法:

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

理由:

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

方法:

⁃ ターゲットとするデバイス用に異なる画像サイズを作成します。<br> ⁃ srcset 属性や picture タグを使用して、各画像の複数のバリエーションを配信します。
- 📖 Responsive images - Learn web development | MDN

⬆ トップに戻る

JavaScript

javascript

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

理由:

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

方法:

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

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

理由:

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

方法:

すべてのファイルが async または defer を使用してロードされていることを確認し、<head> に挿入する必要があるコードかどうか見極めましょう。
- 📖 11 Tips to Optimize JavaScript and Improve Website Loading Speeds
ノンブロッキング JavaScript: JavaScript ファイルは、async を使用して非同期でロードされるか、defer 属性を使用して遅延ロードされます。
```

<script defer src="foo.js"></script>


<script async src="foo.js"></script>
```
理由:

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

方法:

⁃ スクリプトタグの属性として、async（スクリプトが他のスクリプトに依存していない場合）または defer（スクリプトが他のスクリプトに依存、または非同期スクリプトに依存している場合）を追加します。 <br> ⁃ 小さなスクリプトは、非同期スクリプトの上にインラインスクリプトで配置することをお勧めします。
- 📖 Remove Render-Blocking JavaScript
- 📖 Defer loading JavaScript
最適化およびアップデートされた JS ライブラリ: プロジェクトで使用される全ての JavaScript ライブラリが必要であって（単純な機能についてはバニラ JavaScript を推奨）、JavaScript ライブラリを最新バージョンへアップデートし、不必要なメソッドで JavaScript をうめつくさないでください。

理由:

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

方法:

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

依存関係のサイズ制限を確認: 外部ライブラリは見極めてから使用してください。ほとんどの場合、同じ機能であればより軽いライブラリを使用します。

理由:

npm にある745 000パッケージのいずれかを使用したくなるかもしれませんが、ニーズに最適なパッケージを選択する必要があります。例えば、MomentJS は素晴らしいライブラリですが、まったく使われることがない多くのメソッドを備えているため、Day.js が作成されました。Day.js は2 kB で、MomentJS は16.4 kB gz です。

方法:

常にニーズに合った最適で軽量なライブラリを比較して選択してください。npm trend などのツールを使用して NPM パッケージのダウンロード数を比較したり、Bundlephobia を使用して依存関係のサイズを確認したりすることもできます。
JavaScript プロファイリング: JavaScript ファイル（および CSS）のパフォーマンスの問題を確認します。

理由:

JavaScript が複雑になると、ランタイムのパフォーマンスが低下する可能性があります。考えられるこれらの問題を特定することは、スムーズなユーザエクスペリエンスを提供するために不可欠です。

方法:

Chrome 開発者ツールのタイムラインツールを使用してスクリプトイベントを評価し、時間がかかりすぎるイベントを見つけます。
Service Worker の使用: PWA で Service Worker を使用して、アプリケーションのユーザエクスペリエンスに影響を与えることなく、データをキャッシュしたり、重いタスクを実行したりします。

⬆ トップに戻る

サーバ

![サーバサイド]

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

理由:

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

ページ容量 < 1500 KB (理想的には < 500 KB): ページとリソースのサイズをできるだけ減らす。

理由:

500 KB 未満を目標にするのが理想ですが、 Web の状態では、ページ容量の中央値が約 1500 KB （モバイルでも）であることが示されています。ターゲットユーザ、ネットワーク接続、デバイスに応じて、可能な限り総キロバイト数を減らすことで、可能な限り最高のユーザ体験を提供することができます。

方法:

⁃ フロントエンドパフォーマンスチェックリスト内の全てのルールは、リソースとコードを可能な限り削減するのに役立ちます。
- 📖 Page Weight
- 🛠 What Does My Site Cost?
- 🛠 web - Measure full page size in Chrome DevTools - Stack Overflow
ページ読み込み時間 < 3 秒: ページの読み込み時間を可能な限り短縮して、コンテンツを素早くユーザに配信する。

理由:

ウェブサイトやアプリが高速であればあるほど、離脱を増加する可能性を減らし、ユーザや将来のクライアントを失う可能性を減らします。主題に関する十分な調査は、この点を証明します。

方法:

Page Speed Insight や WebPageTest などのオンラインツールを使用して、何が遅くなるかを分析し、読み込み時間を短縮するために、フロントエンドパフォーマンスチェックリストを利用します。
最初の情報を受信する待ち時間 < 1.3 秒: データを受信する前に、ブラウザが待機する時間をできる限り減らします。

クッキーサイズ: クッキーを利用しているのであれば、各クッキーが4096バイトを超えないようにし、ドメイン毎に20を超えるクッキーが無いようにしてください。

理由:

クッキーは、ウェブサーバとブラウザ間で HTTP ヘッダでやりとりされます。ユーザの応答時間への影響を最小限に抑えるために、クッキーのサイズをできる限り小さくすることが重要です。

方法:

不要なクッキーを排除します。

HTTP リクエストの最小化: リクエストされている全てのファイルが、ウェブサイトまたはアプリケーションに不可欠であることを常に確認してください。

📖 Combine external CSS
📖 Combine external JavaScript

CDN を使用してアセットを配信: CDN を利用して、コンテンツをより速く世界中に配信します。

同じプロトコルからファイルを提供: 例えば、 HTTPS を使用しているウェブサイトで、 HTTP を使用したソースからファイルを提供するウェブサイトを作成しないでください。ウェブサイトが HTTPS を使用している場合、外部ファイルは同じプロトコルから取得する必要があります。
到達可能なファイルを提供: 到達不能なファイルへのリクエストを避けます（404）。

📖 How to avoid bad requests

HTTP キャッシュヘッダを適切に設定: HTTP ヘッダを設定して、ブラウザとサーバ間の往復コストを回避します。

📖 Using cache-control for browser caching

GZIP / Brotli 圧縮の有効化: GZIP や Brotli などの圧縮方法を利用して、 JavaScript ファイルのサイズを小さくします。ファイルのサイズを小さくすると、ユーザはアセットをより速くダウンロードできるようになり、パフォーマンスが向上します。

⬆ トップに戻る

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

Angular

📖 Angular Performance Checklist

React

Vue

📖 Vue - Useful Links|Style Guide and Performance

パフォーマンスと CMS

WordPress

🛠 Test Your Website Speed | WordPress Hosting by @WPEngine

記事

推奨プラグイン

翻訳

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

🇵🇹 Portuguese: fernandofawkes/Front-End-Performance-Checklist
🇨🇳 Chinese: JohnsenZhou/Front-End-Performance-Checklist
🇷🇺 Russian: lex111/Front-End-Performance-Checklist
🇫🇷 French: WilliamDASILVA/Front-End-Performance-Checklist
🇰🇷 Korean: ParkSB/Front-End-Performance-Checklist
🇪🇸 Spanish: dagerzuga/Front-End-Performance-Checklist
🇻🇮 Vietnamese : huynhan147/Front-End-Performance-Checklist

貢献する

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

サポート

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

著者

**Build with ❤️ by David Dias

貢献者

このプロジェクトは、ご協力いただいた皆様のおかげで成り立っています。 [貢献する]. <a href="https://github.com/thedaviddias/Front-End-Performance-Checklist/graphs/contributors"> <img src="https://opencollective.com/front-end-checklist/contributors.svg?width=890" /> </a>

後援者

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

スポンサー

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

ライセンス

MIT

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

⬆ トップに戻る

Awesome

Table of Contents

はじめに

使い方

パフォーマンスツール

参考文献

HTML

CSS

Fonts

Images

JavaScript

サーバ

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

Angular

React

Vue

パフォーマンスと CMS

WordPress

記事

推奨プラグイン

翻訳

貢献する

サポート

著者

貢献者

後援者

スポンサー

ライセンス