シンプルなルール: "パフォーマンスを考慮してデザイン・コーディングすること"
使い方 • Contributing • ロードマップ • Product Hunt
Other Checklists:
🗂 Front-End Checklist • 💎 Front-End Design Checklist
- HTML
- CSS
- Fonts
- Images
- JavaScript
- サーバ (作成中)
- JS Frameworks (作成中)
パフォーマンスは大きなテーマですが、いつも "バックエンド" や "管理者" の問題というわけではありません。フロントエンドの責任範囲でもあります。このフロントエンドパフォーマンスチェックリストは、フロントエンド開発者としてプロジェクト(個人でも業務でも)に充たる場合に、確認もしくは気にしておくべき項目を網羅的にリストアップしたものです。
各ルールには、このルールが重要である 理由 と 修正する 方法 を記載しています。より詳細な情報は、 🛠: ツール、 📖: 記事、 📹: 動画サイト のリンクを参照してください。
フロントエンドパフォーマンスチェックリスト は、どれも最高のパフォーマンススコアを達成するためには不可欠な項目ですが、どのルールを優先的に適用すべきかを3段階で示しています。
は、優先度が 低 であることを意味しています。
は、優先度が 中 であることを意味しています。 このルールの適用を避けるべきではありません。
は、優先度が 高 であることを意味しています。 このルールに従い、推奨される方法で実装してください。
ウェブサイト または アプリケーションのテストやモニタリングに使用できるツールのリスト:
- 🛠 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
- 📹 The Cost Of JavaScript - YouTube (text version)
- AddyOsmani.com - Start Performance Budgeting
- 📖 Get Started With Analyzing Runtime Performance | Google Developers
- 📖 State of the Web | 2018_01_01
- 📖 Page Weight Doesn't Matter
- 📖 Front-End Performance Checklist 2018 [PDF, Apple Pages]
- 📖 Designing for Performance Weighing Aesthetics and Speed - By Lara Callender Hogan [eBook, Print]
- 📖 Varvy - Web performance glossary
- 📖 fabkrum/web-performance-resources: Up to date collection of valuable web performance resources
- 📖 Checkbot - Web Speed Best Practices
- 🛠 Progressive Tooling - A list of community-built, third-party tools that can be used to improve page performance
-
HTML の軽量化(Minified):
HTML コードは圧縮され、コメント、空白、改行が本番のファイルから削除されていること。
理由:
不要なスペース、コメント、ブレークを全て削除すると、HTML のサイズが小さくなり、サイトのページの読み込み時間が短縮され、ユーザのダウンロードにかかる時間が明らかに軽減されます。
方法:
ほとんどのフレームワークには、Web ページを容易に圧縮することができるプラグインがあります。自動的にジョブを実行できる多くの NPM モジュールを使用できます。
-
不要なコメントの削除:
コメントがページから削除されていることを確認してください。
理由:
コメントはユーザにとって何も役に立たないので、本番のファイルからは削除すべきです。コメントを保持したくなるケースは、ライブラリのソースを保持する必要がある場合くらいです。
方法:
ほとんどの場合、コメントは HTML 圧縮プラグインを使って削除することができます。
-
不要な属性の削除:
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 タグの前に配置:
必ず 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 の数を最小限に抑える:
iframe は他の技術的な可能性がない場合にのみ使用してください。できる限り iframe の使用を避けましょう。
-
prefetch、dns-prefetch、prerender での事前読み込みによる最適化:
一般的なブラウザでは、
<link>
タグに "rel" 属性のディレクティブ指定することで特定の URL を事前読み込みすることができます。理由:
事前読込み(Prefetching)により、ブラウザはユーザが近い将来アクセスする可能性のあるコンテンツの表示に必要なリソースを事前に取得しておくことができます。ブラウザはこれらのリソースをキャッシュに保存するので、コンテンツが異なるドメインを使っている場合でも Web ページの読み込みを高速化できます。 Web ページの読み込みが完了し、アイドル時間が経過すると、ブラウザは他のリソースのダウンロードを開始します。ユーザが特定のリンク(事前読み込み済み)にアクセスすると、コンテンツは即時に提供されます。
方法:
⁃
<link>
タグが<head>
タグ内に あることを確認してください。
-
ファイルの軽量化(minification):
すべての CSS ファイルは圧縮され、コメント、空白、改行が本番のファイルから削除されています。
理由:
CSS ファイルの圧縮を行うと、コンテンツの読み込み時間が早くなりクライアントに送信されるデータが少なくなります。常に本番用の CSS ファイルは圧縮されていることが重要です。帯域幅やリソース使用量を削減したいビジネスユーザにとって有益です。
方法:
⁃ ビルドまたはデプロイメントの前または途中でファイルを自動的に圧縮するツールを使用します。
-
ファイルの結合:
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 を使用している場合はその限りではありません。(テストを行う必要があります)
方法:
⁃ ビルド前かビルド中、もしくはデプロイ前かデプロイ中に、オンラインのツールもしくはプラグインを使ってファイルを結合します。
⁃ もちろん、結合によりプロジェクトが壊れないかどうかは確認してください。 -
ノンブロッキング:
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 を使用する場合、必要以上の文字がクラスに含まれることがあります。名前や名前空間をしっかりと考え選択することは常に重要です。
方法:
文字数に制限を設定することは一部の人にとっては興味深いことですが、ウェブサイトをコンポーネントに分割することで、クラス(および宣言)の数と長さを減らすことができます。
-
理由:
未使用の CSS セレクタを削除すると、ファイルサイズが削減できアセットの読み込みも早くなります。
方法:
⁃
⚠️ 使用する CSS フレームワークにリセット CSS/ノーマライズ CSS のコードが含まれていないかどうかを常に確認してください。リセット CSS/ノーマライズ CSS ファイルに記載されている全てのコードを必要としない場合があります。
-
クリティカル CSS:
クリティカル CSS(または above the fold)とは、ファーストビューのレンダリングに使用されるすべての CSS です。主要な CSS の読み込み前にこれを
<style></style>
タグにインライン化(可能な限り圧縮)して記載します。理由:
インライン化したクリティカル CSS を使用すると、Web ページのレンダリングを高速化し、サーバへのリクエスト回数を減らすことができます。
方法:
オンラインツール、または Addy Osmani が開発したようなプラグインを使用してクリティカル CSS を生成することができます。
-
埋め込み または インライン CSS:
<body>
内で埋め込み CSS、またはインライン CSS を使うのは避けましょう。 (HTTP/2 では無効)理由:
最初の理由の一つは、コンテンツをデザインから分離 することがグッドプラクティスだからです。コードの保守性が向上し、サイトのアクセシビリティも向上します。パフォーマンスに関して言うと、HTML ページのファイルサイズと読み込み時間を短縮することができます。
方法:
常に外部スタイルシートを使用するか、
<head>
に CSS を埋め込みます。(他の CSS パフォーマンスルールに従います) -
スタイルシートの複雑さを分析する:
スタイルシートを分析すると、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 に似ていますが、変更を追跡できるように統計結果を長期間保存します。
-
ウェブフォント フォーマット:
ウェブプロジェクトまたはアプリケーションで 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 を使ってウェブサイトを評価しましょう
⁃ 青緑色の DNS ルックアップを探して、要求されたホストをメモしてください
⁃ ウェブフォントを<head>
の中でプリフェッチし、最終的にはプリフェッチする必要があるホスト名も追加してください- 📖 Faster Google Fonts with Preconnect - CDN Planet
- 📖 Make Your Site Faster with Preconnect Hints | Viget
- 📖 Ultimate Guide to Browser Hints: Preload, Prefetch, and Preconnect - MachMetrics Speed Blog
- 📖 A Comprehensive Guide to Font Loading Strategies—zachleat.com
- 🛠 typekit/webfontloader: Web Font Loader gives you added control when using linked fonts via @font-face.
-
画像の最適化:
エンドユーザーに直接影響を与えることなく画像を圧縮し、最適化してください。
理由:
最適化された画像はより高速にブラウザに読み込まれるため、データの消費が少なくなります。
方法:
⁃ 可能であれば、CSS3 エフェクトを使用してください(小さな画像の代わりに)
⁃ 可能であれば、画像にはテキストエンコードの代わりにフォントを使用してください
⁃ SVG を使用してください
⁃ ツールを使って、圧縮レベルを 85 未満に指定してください- 📖 Image Optimization | Web Fundamentals | Google Developers
- 📖 Essential Image Optimization - An eBook by Addy Osmani
- 🛠 TinyJPG – Compress JPEG images intelligently
- 🛠 Kraken.io - Online Image Optimizer
- 🛠 Compressor.io - optimize and compress JPEG photos and PNG images
- 🛠 Cloudinary - Image Analysis Tool
- 🛠 ImageEngine - Image Webpage Loading Test
- 🛠 SVGOMG - Optimize SVG vector graphics files
-
理由:
画像が原因で Web サイトの速度を低下させないようにするには、画像に適した形式を選びます。写真の場合、PNG や GIF よりも JPEG が適しています。ただし、ファイルのサイズを削減できる next-gen 形式を確認することを忘れないでください。各画像形式には長所と短所がありますが、最も良い選択をするためにこれらのことを知っておくことが重要です。
方法:
⁃ Lighthouse を使用して、画像が next-gen 形式(JPEG 2000m、JPEG XR、WebP など)を使用できるかを特定します。
⁃ 複数の異なる画像形式を比較してください。PNG8 よりも PNG16 を使用する方が良い場合もあります。
-
ベクター画像かラスター/ビットマップを使用:
ビットマップ画像よりもベクター画像を使用することをお勧めします(可能な場合)。
理由:
ベクター画像 (SVG) はサイズが小さくなる傾向があり、レスポンシブでスケールすることができます。またこれらの画像は、CSS を使ってアニメーションしたり変更したりできます。
-
画像の大きさ:
レンダリング時の画像サイズがわかっている場合は、
<img>
タグにwidth
とheight
の属性を設定します。理由:
あらかじめ画像に高さと幅が設定されていれば、ページをローディングする時に画像表示に必要なスペースが確保されますが、もしこれらの属性が設定されていなければ、ブラウザは画像のサイズを認識できず適切なスペースを確保することができません。これにより、ページ(画像ファイル)のローディング中に、レイアウトが変更されるという影響が出てしまいます。
-
Base64 画像の使用を避ける:
小さな画像であれば base64 に変換することもできますが、実際これはベストプラクティスではありません。
-
Lazy loading(遅延読み込み):
オフスクリーン画像(ブラウザに初期表示されない画像)は遅延ロードします(noscript フォールバックは常に提供されます)。
理由:
表示画面の応答時間を短縮し、ユーザーが必要としない不要な画像の読み込みを回避することができます。
方法:
⁃ Lighthouse を使用して、オフスクリーン画像 の数を特定します。
⁃ 以下のような JavaScript プラグインを使用して、画像の遅延読み込みを行います。必ずオフスクリーン画像のみを遅延読み込み対象にしてください。
⁃ また、マウスオーバー時やユーザー操作時に表示される代替画像も遅延読み込みするようにしてください。 -
レスポンシブ画像:
ディスプレイサイズに近い画像を利用するようにしてください。
理由:
画面が小さいデバイスでは、ビューポートよりも大きな画像を必要としません。1つの画像をそれぞれの異なるサイズで複数枚用意しておくことをお勧めします。
方法:
⁃ ターゲットとするデバイス用に異なる画像サイズを作成します。
⁃srcset
属性やpicture
タグを使用して、各画像の複数のバリエーションを配信します。
-
JS 圧縮:
全ての JavaScript ファイルが圧縮され、コメント、空白、および改行がプロダクションファイルから削除されます (HTTP/2を使用している場合でも有効です)。
理由:
不要なスペース、コメント、ブレークをすべて削除すると、JavaScript ファイルのサイズが小さくなり、サイトのページの読み込み時間が短縮され、ユーザのダウンロードが明らかに軽くなります。
方法:
⁃ 以下に示すツールを使用して、ビルドまたはデプロイメントの前か最中にファイルを自動的に圧縮します。
-
JavaScriptを内部には無記載 :
(ウェブサイトでのみ有効です) body 内部に複数の JavaScript コードを埋め込むことは避けてください。JavaScript コードを外部ファイル内に、最終的には
<head>
、またはページの最後(</body>
の前)で再グループ化します。理由:
JavaScript の埋め込みコードを直接
<body>
に配置すると、DOM の構築中にページが読み込まれるため、ページの速度が低下する可能性があります。 最適なオプションは、DOM のブロックを回避するために、async
またはdefer
で外部ファイルを使用することです。 別のオプションは、<head>
内にいくつかのスクリプトを配置することです。<head>
に配置するスクリプトは、ほとんどの場合、DOM がメイン処理に到達する前にロードする必要がある分析コードまたは小さなスクリプトです。方法:
すべてのファイルが
async
またはdefer
を使用してロードされていることを確認し、<head>
に挿入する必要があるコードかどうか見極めましょう。 -
ノンブロッキング JavaScript:
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 ライブラリ:
プロジェクトで使用される全ての JavaScript ライブラリが必要であって(単純な機能についてはバニラ JavaScript を推奨)、JavaScript ライブラリを最新バージョンへアップデートし、不必要なメソッドで JavaScript をうめつくさないでください。
理由:
ほとんどの場合、新しいバージョンには最適化とセキュリティ修正が含まれています。最適化されたコードでプロジェクトを高速化し、古いプラグインを使うことなく、ウェブサイトまたはアプリの速度を落とさないようにしてください。
方法:
プロジェクトで NPM パッケージを使用している場合、npm-check は、ライブラリをアップグレード/アップデートするための非常に興味深いライブラリです。 Greenkeeper は、依存関係を自動的に探し、新しいバージョンがリリースされる度にアップデートを提案します。
-
依存関係のサイズ制限を確認:
外部ライブラリは見極めてから使用してください。ほとんどの場合、同じ機能であればより軽いライブラリを使用します。
理由:
npm にある745 000パッケージのいずれかを使用したくなるかもしれませんが、ニーズに最適なパッケージを選択する必要があります。例えば、MomentJS は素晴らしいライブラリですが、まったく使われることがない多くのメソッドを備えているため、Day.js が作成されました。Day.js は2 kB で、MomentJS は16.4 kB gz です。
方法:
常にニーズに合った最適で軽量なライブラリを比較して選択してください。npm trend などのツールを使用して NPM パッケージのダウンロード数を比較したり、Bundlephobia を使用して依存関係のサイズを確認したりすることもできます。
-
JavaScript プロファイリング:
JavaScript ファイル(および CSS)のパフォーマンスの問題を確認します。
理由:
JavaScript が複雑になると、ランタイムのパフォーマンスが低下する可能性があります。 考えられるこれらの問題を特定することは、スムーズなユーザエクスペリエンスを提供するために不可欠です。
方法:
Chrome 開発者ツールのタイムラインツールを使用してスクリプトイベントを評価し、時間がかかりすぎるイベントを見つけます。
- 📖 Speed Up JavaScript Execution | Tools for Web Developers | Google Developers
- 📖 JavaScript Profiling With The Chrome Developer Tools — Smashing Magazine
- 📖 How to Record Heap Snapshots | Tools for Web Developers | Google Developers
- 📖 Chapter 22 - Profiling the Frontend - Blackfire
- 📖 30 Tips To Improve Javascript Performance
-
Service Worker の使用:
PWA で Service Worker を使用して、アプリケーションのユーザエクスペリエンスに影響を与えることなく、データをキャッシュしたり、重いタスクを実行したりします。
![サーバサイド]
-
理由:
HTTPS は、 e コマースウェブサイトだけではなく、データをやりとりする全てのウェブサイト用です。データとは、ユーザが共有するデータ、または外部エンティティと共有するデータです。今時の最新ブラウザは安全でないサイトの機能を制限しています。例えば、インスタンスが HTTPS を使用していない場合、位置情報、プッシュ通知、および Service Worker は機能しません。また、現在は SSL 証明書を使用したプロジェクトのセットアップが、以前よりもはるかに簡単になりました。(そして、 Let's Encrypt のおかげで無料です。)
- 📖 Why Use HTTPS? | Cloudflare
- 📖 Enabling HTTPS Without Sacrificing Your Web Performance - Moz
- 📖 How HTTPS Affects Website Performance
- 📖 HTTP versus HTTPS versus HTTP2 - The real story | Tune The Web
- 📖 HTTP vs HTTPS — Test them both yourself
-
ページ容量 < 1500 KB (理想的には < 500 KB):
ページとリソースのサイズをできるだけ減らす。
理由:
500 KB 未満を目標にするのが理想ですが、 Web の状態では、ページ容量の中央値が約 1500 KB (モバイルでも)であることが示されています。ターゲットユーザ、ネットワーク接続、デバイスに応じて、可能な限り総キロバイト数を減らすことで、可能な限り最高のユーザ体験を提供することができます。
方法:
⁃ フロントエンドパフォーマンスチェックリスト内の全てのルールは、リソースとコードを可能な限り削減するのに役立ちます。
-
ページ読み込み時間 < 3 秒:
ページの読み込み時間を可能な限り短縮して、コンテンツを素早くユーザに配信する。
理由:
ウェブサイトやアプリが高速であればあるほど、離脱を増加する可能性を減らし、ユーザや将来のクライアントを失う可能性を減らします。主題に関する十分な調査は、この点を証明します。
方法:
Page Speed Insight や WebPageTest などのオンラインツールを使用して、何が遅くなるかを分析し、読み込み時間を短縮するために、フロントエンドパフォーマンスチェックリストを利用します。
-
クッキーサイズ:
クッキーを利用しているのであれば、各クッキーが4096バイトを超えないようにし、ドメイン毎に20を超えるクッキーが無いようにしてください。
理由:
クッキーは、ウェブサーバとブラウザ間で HTTP ヘッダでやりとりされます。ユーザの応答時間への影響を最小限に抑えるために、クッキーのサイズをできる限り小さくすることが重要です。
方法:
不要なクッキーを排除します。
- 📖 10 Tips to Optimize CDN Performance - CDN Planet
- 📖 HTTP Caching | Web Fundamentals | Google Developers
-
同じプロトコルからファイルを提供:
例えば、 HTTPS を使用しているウェブサイトで、 HTTP を使用したソースからファイルを提供するウェブサイトを作成しないでください。ウェブサイトが HTTPS を使用している場合、外部ファイルは同じプロトコルから取得する必要があります。
- GZIP / Brotli 圧縮の有効化:
GZIP や Brotli などの圧縮方法を利用して、 JavaScript ファイルのサイズを小さくします。ファイルのサイズを小さくすると、ユーザはアセットをより速くダウンロードできるようになり、パフォーマンスが向上します。
- 📖 Optimizing Performance - React
- 📖 React image manipulation | Cloudinary
- 📖 Debugging React performance with React 16 and Chrome Devtools.
- 📖 19 Tips to Speed Up WordPress Performance (Updated)
- 📖 Speed Up Your WordPress - How to Save Images Optimized for Web
- 🛠 Caching Plugin for WordPress - Speed up your website with WP Rocket
- 🛠 WP-Sweep | WordPress.org
- 🛠 Imagify Image Optimizer | WordPress.org
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
このプロジェクトは、ご協力いただいた皆様のおかげで成り立っています。 [貢献する].
ご支援いただいた皆様、ありがとうございました! 🙏 [後援者になる]
スポンサーになってこのプロジェクトをサポートしてください。スポンサーのロゴは、ウェブサイトへのリンクと共にここに表示されます。[スポンサーになる]
アイコンはすべて Icons8 によって提供されています。