From 33058f2b292b3a581333bdfb21b8f671898c5060 Mon Sep 17 00:00:00 2001 From: Peter Bengtsson Date: Tue, 8 Dec 2020 14:40:17 -0500 Subject: initial commit --- .../business_case_for_performance/index.html | 83 ++++++++++++++ files/ja/learn/performance/index.html | 120 +++++++++++++++++++++ .../performance/measuring_performance/index.html | 105 ++++++++++++++++++ .../performance/perceived_performance/index.html | 111 +++++++++++++++++++ .../performance/web_performance_basics/index.html | 89 +++++++++++++++ .../performance/what_is_web_performance/index.html | 90 ++++++++++++++++ .../performance/why_web_performance/index.html | 101 +++++++++++++++++ 7 files changed, 699 insertions(+) create mode 100644 files/ja/learn/performance/business_case_for_performance/index.html create mode 100644 files/ja/learn/performance/index.html create mode 100644 files/ja/learn/performance/measuring_performance/index.html create mode 100644 files/ja/learn/performance/perceived_performance/index.html create mode 100644 files/ja/learn/performance/web_performance_basics/index.html create mode 100644 files/ja/learn/performance/what_is_web_performance/index.html create mode 100644 files/ja/learn/performance/why_web_performance/index.html (limited to 'files/ja/learn/performance') diff --git a/files/ja/learn/performance/business_case_for_performance/index.html b/files/ja/learn/performance/business_case_for_performance/index.html new file mode 100644 index 0000000000..106a517a8f --- /dev/null +++ b/files/ja/learn/performance/business_case_for_performance/index.html @@ -0,0 +1,83 @@ +--- +title: ウェブパフォーマンスのビジネスケース +slug: Learn/Performance/business_case_for_performance +tags: + - Web パフォーマンス + - Web 開発 +translation_of: Learn/Performance/business_case_for_performance +--- +
{{LearnSidebar}}
+ +
{{PreviousMenu("Learn/Performance/Mobile", "Learn/Performance")}}
+ +

{{draft}}

+ +

ここまで、ウェブパフォーマンスの重要性についてお話してきました。ウェブパフォーマンスを最適化するために何をすべきかを学びました。しかし、クライアントや経営陣にパフォーマンスに優先順位をつけて投資するように説得するにはどうすればよいのでしょうか？このセクションでは、意思決定者に投資をするように説得するための明確なビジネスケースの作成について説明します。

+ + + + + + + + + + + + +
前提条件:コンピュータリテラシーの基礎、クライアントサイドのウェブ技術の基礎知識、ウェブパフォーマンス最適化の基礎知識。
目標:クライアントや経営者に ウェブパフォーマンスを優先してもらい、自信を持って仕事ができるようになること。
+ +

パフォーマンスを経営の最優先事項にする

+ +

これまで、パフォーマンスに優先順位をつけることで、ユーザー体験を向上させ、その結果として収益を上げる方法について説明してきました。ウェブパフォーマンスを優先させないと、ビジネスの収益を失う可能性があることを知っています。この記事では、特定のビジネス指標がユーザーのウェブパフォーマンス体験にどのように直接関係しているか、ウェブパフォーマンスのユーザー体験を向上させるためにサービス設計を適用する方法について説明しています。また、累積的な経験がコンバージョン率やリテンション率にどのように影響するかを理解することの重要性を強調しています。

+ +
+
+ +

パフォーマンス予算

+ +

ウェブパフォーマンス予算を設定することで、チームがサイトを維持するための軌道に乗っているかどうかを確認し、回帰を防ぐのに役立ちます。パフォーマンスバジェットとは、維持しなければならない最大の http リクエスト数、すべてのアセットを合わせた最大の合計サイズ、特定のデバイスでの最小許容 FPS などの制限を指定するために設定される制限のセットです。予算は、単一のファイル、ファイルタイプ、ページに読み込まれたすべてのファイル、特定のメトリック、または一定期間のしきい値に適用することができます。

+ +

予算を定義して推進することで、マーケティング、セールス、さらにはビデオやサードパーティスクリプト、フレームワークを追加したいと考えている他の開発者など、競合する利害関係者に対抗して、優れたユーザーエクスペリエンスを提供するためのパフォーマンス推進者を支援することができます。パフォーマンス予算は、開発者チームがユーザーのために最適なパフォーマンスを保護し、ビジネスが新しい市場に参入してカスタム体験を提供できるようにするのに役立ちます。

+ +

key performance indicators

+ +

目標として主要業績評価指標（KPI）を設定することで、ビジネスの目標でもある業績目標を明確にすることができます。KPIは、ユーザーエクスペリエンスとパフォーマンスがビジネスのトップラインに与える影響を測定する上で重要なビジネスメトリクスのセットであると同時に、パフォーマンスに優先順位をつけることのメリットを示す方法でもあります。ここでは、検討すべき KPI をいくつか紹介します。

+ +
+
コンバージョン率 (CR)
+
購入の完了やニュースレターへの登録など、意図した行動をとったトラフィックの割合。ビジネスサイトの表示速度が遅いと、ユーザーが意図したタスクを完了できないことがあります。これは、コンバージョン率の低下につながる可能性があります。
+
Time on Site
+
集計したユーザーがサイトに費やす平均時間。サイトのパフォーマンスが低下すると、ユーザーはサイトを早期に放棄する可能性が高くなり、サイトのメトリクスにかかる時間が短くなる可能性があります。
+
ネットプロモーションスコア (NPS)
+
ネットプロモーションスコア (NPS) は、企業のブランド、製品、サービスに対する顧客の忠誠心を評価するための指標です。ユーザーのパフォーマンスが悪いと、ブランドの評判が悪くなります。
+
+ +

KPI としてコンバージョン率、サイト上の時間、および/またはネットプロモーションのスコアを設定すると、ウェブパフォーマンスの努力に財務および他のビジネス目標の価値を与え、努力の価値を証明するためのメトリクスを使用して、購入を後押しするのに役立ちます。

+ + + +
{{PreviousMenu("Learn/Performance/Mobile", "Learn/Performance")}}
+ +

このモジュール

+ + diff --git a/files/ja/learn/performance/index.html b/files/ja/learn/performance/index.html new file mode 100644 index 0000000000..070c09f1f1 --- /dev/null +++ b/files/ja/learn/performance/index.html @@ -0,0 +1,120 @@ +--- +title: Web パフォーマンス +slug: Learn/Performance +translation_of: Learn/Performance +--- +

{{LearnSidebar}}{{draft}}

+ +

Web サイトを構築するには、HTML、CSS、および JavaScript が必要です。人々が使用したい Web サイトやアプリケーションを構築し、ユーザを引き付けて維持するには、優れたユーザエクスペリエンスを作成する必要があります。良好なユーザエクスペリエンスの一部は、コンテンツの読み込みが迅速であり、ユーザの操作に反応することを保証することです。これは Web パフォーマンスと呼ばれ、このモジュールではパフォーマンスのよい Web サイトを構築するために必要なすべてを学習します。

+ +

Webパフォーマンスとは、客観的な測定値であり、ロード時間と実行時間に関するユーザーエクスペリエンスの評価です。 Webパフォーマンスとは、サイトがロードされて対話型で応答するまでにかかる時間、およびユーザーとの対話中のコンテンツの滑らかさです。スクロールはスムーズですか？ボタンはクリック可能ですか？ポップアップはすばやく開くことができますか？また、ポップアップはスムーズにアニメーション化されますか？ Webパフォーマンスには、ロードにかかる時間、1秒あたりのフレーム数、インタラクティブにかかる時間などの客観的な測定値と、コンテンツのロードにかかったと感じる時間の主観的な経験値の両方が含まれます。
+
+ レイテンシ、アプリケーションサイズ、DOMノードの数、行われたリソースリクエストの数、JavaScriptのパフォーマンス、CPU負荷など、多くの機能がパフォーマンスに影響を与えます。ロードと応答時間を最小限に抑え、エクスペリエンスを可能な限り早くインタラクティブにできるようにすることで、レイテンシーを隠すための追加機能を追加し、エクスペリエンスの長いテール部分で非同期的にロードすることが重要です。
+
+ Webパフォーマンスの測定と改善に役立つツール、API、およびベストプラクティスがあります。これらもこのモジュールの過程で見ていきます。

+ +

学習経路

+ +

Webパフォーマンスの改善に関する多くの推奨事項を実装するにはHTML、CSS、およびJavaScriptを知っている必要がありますが、アプリケーションの構築方法を知っていることはWebパフォーマンスを理解および測定するための必須条件ではありません。
+
+ 以下の導入モジュールのいくつかはプログラミングの知識を必要としませんが、HTMLおよびパフォーマンスモジュールにはHTMLの理解が必要であり、CSSおよびパフォーマンスモジュールにはCSSの理解が必要です。導入モジュールを使用することをお勧めします。まず、最初に「Webパフォーマンスとは何か」から始めます。入門モジュールは、Webパフォーマンスの概要を提供します。最初の3つは、開発者であろうとプロジェクトマネージャーであろうと読む必要があると考えるべきです。技術トピックに焦点を当てたモジュールは、これらの技術を使用する開発者により適しています。
+
+ 高度なモジュールでは、入門モジュールで概要を説明したトピックをさらに深く掘り下げ、パフォーマンスAPI、テストおよび分析ツール、パフォーマンスのボトルネックの概要を提供します。
+
+ このトピックに進む前に、「Web入門」を完了することをお勧めします。ただし、そうすることは必ずしも必要ではありません。

+ +

Introductory modules

+ +

このトピックには、次のモジュールが含まれています。必ず最初のものから始めてください。

+ +
+
Webパフォーマンスとは何ですか？
+
この記事では、実際のパフォーマンスとは何かを詳しく説明することから始めます。これには、パフォーマンスを考える際に考慮する必要があるツール、メトリック、API、ネットワーク、人々のグループ、およびパフォーマンスをWeb開発ワークフローの一部にする方法が含まれます。
+
ユーザーはパフォーマンスをどのように知覚しますか？
+
ミリ秒単位のWebサイトの速度よりも重要なのは、ユーザーがサイトを認識する速度です。これらの認識は、実際のページの読み込み時間、アイドリング、ユーザーインタラクションへの応答性、スクロールやその他のアニメーションの滑らかさの影響を受けます。この記事では、実際のタイミングではなくても、ユーザーの認識を改善するためのベストプラクティスとともに、さまざまな読み込みメトリック、アニメーション、応答性メトリックについて説明します。
+
Webパフォーマンスの基本
+
+

HTML、CSS、JavaScript、およびメディアファイルのフロントエンドコンポーネントに加えて、アプリケーションを遅くできる機能と、アプリケーションを主観的および客観的に高速化できる機能があります。 Webパフォーマンスに関連する多くのAPI、開発者ツール、ベストプラクティス、および悪いプラクティスがあります。ここでは、これらの機能の多くを基本レベルで紹介し、各トピックのパフォーマンスを改善するためのより深いダイブへのリンクを提供します。

+
+
HTMLパフォーマンス機能
+
+

一部の属性とマークアップのソースの順序は、パフォーマンスまたはWebサイトに影響を与える可能性があります。 DOMノードの数を最小限に抑え、スタイル、スクリプト、メディア、サードパーティスクリプトなどのコンテンツを含めるために最適な順序と属性が使用されるようにすることで、ユーザーエクスペリエンスを大幅に改善できます。この記事では、パフォーマンスを最大限に高めるためにHTMLを使用する方法について詳しく説明します。

+
+
マルチメディア：画像とビデオ
+
+

多くの場合、Webパフォーマンスの最も低い成果はメディアの最適化です。各ユーザーエージェントの機能、サイズ、ピクセル密度に基づいて異なるメディアファイルを提供することが可能です。バックグラウンドビデオからオーディオトラックを削除するなどの追加のヒントは、パフォーマンスをさらに向上させることができます。この記事では、ビデオ、オーディオ、画像のコンテンツがパフォーマンスに与える影響と、その影響を最小限に抑える方法について説明します。

+
+
レスポンシブ画像
+
+

画像を最適化することは、高性能なメディアリッチユーザーエクスペリエンスに不可欠ですが、画像をダウンロードするデバイスに合わせて適切なサイズにすることは特に重要です。この記事では、効率的な画像配信における<picture>要素やsrcset属性などのネイティブブラウザー機能の役割と、それらを自信を持って使用する方法について説明します。

+
+
組み込みのプロファイラーを使用したプロファイリング
+
Firefoxの組み込みプロファイラーでアプリのパフォーマンスをプロファイリングする方法を学びます。
+
代替メディア形式
+
画像やビデオに関しては、おそらくあなたが知っているよりも多くのフォーマットがあります。これらの形式の中には、ファイルサイズをさらに削減することにより、高度に最適化されたメディアリッチページをさらに活用できるものがあります。このガイドでは、いくつかの代替メディア形式、サポートされていないブラウザが寒さの中に置き去りにされないように責任を持って使用する方法、および既存のアセットをトランスコードするための高度なガイダンスについて説明します。
+
CSSパフォーマンス機能
+
CSSは、パフォーマンスを向上させるためにそれほど重要ではない最適化の焦点となる場合がありますが、他のCSSよりもパフォーマンスに影響を与えるCSS機能がいくつかあります。この記事では、パフォーマンスに影響を与えるいくつかのCSSプロパティを検討し、パフォーマンスが悪影響を受けないようにスタイルを処理する方法を提案しました。
+
JavaScriptパフォーマンスのベストプラクティス
+
+

JavaScriptを適切に使用すると、インタラクティブで没入型のWebエクスペリエンスを実現できます。または、ダウンロード時間、レンダリング時間、アプリ内パフォーマンス、バッテリー寿命、ユーザーエクスペリエンスに大きな悪影響を与える可能性があります。この記事では、複雑なコンテンツであっても可能な限りパフォーマンスを高めるために考慮すべきJavaScriptのベストプラクティスの概要を説明します。

+
+
Webフォントのパフォーマンス
+
+

パフォーマンスのランドスケープで見落とされることが多いのは、Webフォントです。 WebフォントはWebデザインにおいてこれまで以上に目立っていますが、多くの開発者は単にサードパーティのサービスからフォントを埋め込み、それについて何も考えていません。この記事では、効率的なファイル形式とサブ設定を使用して、フォントファイルをできるだけ小さくする方法について説明します。そこから、ブラウザのテキストのしくみ、CSSとJavaScriptの機能を使用してフォントをすばやくレンダリングし、ユーザーエクスペリエンスの中断を最小限に抑える方法について説明します。

+
+
モバイル性能
+
+

モバイルデバイスでのWebアクセスは非常に人気があり、すべてのモバイルプラットフォームは本格的なWebブラウザーを備えていますが、帯域幅、CPU、およびバッテリーの寿命が制限されている可能性があるため、これらのプラットフォームでのWebコンテンツのパフォーマンスを考慮することが重要です。この記事では、モバイル固有のパフォーマンスに関する考慮事項について説明します。

+
+
+ + + +

Advanced Modules

+ +
+
Populating the page
+
HTTPリクエストが行われ、可能なら、数秒後にサイトが表示されます。コンテンツを表示するには、JavaScriptを実行し、DOMを変更し、スタイルを計算し、レイアウトを計算し、最後にコンテンツをレンダリングします。これには、ペイントと合成が含まれ、GPUアクセラレーションが別のスレッドに含まれます。
+
パフォーマンスのボトルネック
+
+
レイテンシを理解する
+
+

レイテンシとは、ブラウザーがリソースを要求してから、ブラウザーが要求されたリソースの最初のバイトを受信するまでにかかる時間です。この記事では、レイテンシとは何か、それがパフォーマンスに与える影響、レイテンシを測定および改善する方法について説明します。

+
+
帯域幅について
+
+

帯域幅は、1秒間に送信できるデータの量（MbpsまたはKbpsで測定）です。この記事では、メディアリッチインターネットアプリケーションにおける帯域幅の役割、測定方法、利用可能な帯域幅を最大限に活用するためにアプリケーションを最適化する方法について説明します。

+
+
HTTP / 2とあなた
+
+

トランスポート層（つまりHTTP）はWebの機能に不可欠であり、HTTP / 2の形で大きな更新が行われたのは比較的最近になってからです。すぐに使用できるHTTP / 2は、以前のバージョンよりも多くのパフォーマンスの改善と利点を提供しますが、状況を変えます。この記事では、HTTP / 2が何をするのか、そしてアプリケーションをさらに微調整してさらに前進させる方法を学びます。

+
+
パフォーマンスにおけるTLSの役割
+
+

TLS（またはHTTPSと呼ばれる傾向がある）は、安全で安全なユーザーエクスペリエンスを作成するために重要です。ハードウェアはTLSがサーバーのパフォーマンスに与える悪影響を軽減しましたが、ブラウザーがサーバーに接続するのを待つ時間のかなりの部分を占めています。この記事では、TLSハンドシェイクプロセスについて説明し、OCSPステープリング、HSTSプリロードヘッダー、サードパーティのTLSレイテンシをマスクするリソースヒントの潜在的な役割など、この時間を短縮するためのヒントを提供します。

+
+
組み込みのプロファイラーを使用したプロファイリング
+
Firefoxの組み込みプロファイラーでアプリのパフォーマンスをプロファイリングする方法を学びます。
+
パフォーマンスチャートを読む
+
開発者ツールは、パフォーマンス、メモリ、およびネットワーク要求に関する情報を提供します。ブラウザ開発ツールのウォーターフォールチャート、コールツリー、トレース、フレームチャート、および割り当ての読み方を知っていると、他のパフォーマンスツールのウォーターフォールチャートとフレームチャートを理解するのに役立ちます。
+
CSSおよびJavaScriptアニメーションのパフォーマンス
+
アニメーションは、楽しいユーザーエクスペリエンスにとって重要です。この記事では、CSSとJavaScriptベースのアニメーションのパフォーマンスの違いについて説明します。
+
JavaScriptバンドルの分析
+
間違いなく、JavaScriptは現代のWeb開発の大きな部分を占めています。アプリケーションで使用するJavaScriptの量を減らすよう常に努力する必要がありますが、どこから始めればよいかを知ることは困難です。このガイドでは、アプリケーションのスクリプトバンドルを分析し、使用しているものを把握する方法と、アプリのバンドル間でスクリプトが重複しているかどうかを検出する方法を示します。
+
動的インポートを使用したJavaScriptのLazy-load
+
開発者は「lazy loading」という用語を聞くと、ビューポートにスクロールするときに読み込まれるスクロールせずに見える画像をすぐに思い浮かべます。しかし、JavaScriptもlazy loadできることを知っていましたか？このガイドでは、動的import（）ステートメントについて説明します。これは、JavaScriptモジュールをオンデマンドでロードする最新のブラウザーの機能です。もちろん、この機能はどこでも利用できるわけではないため、この機能を広く互換性のある方法で使用するようにツールを構成する方法も示します。
+
+ +
+
リソースヒントを使用したリソース配信の制御
+
ブラウザは、リソースの優先順位付けと配信に関して、私たちよりもよく知っていますが、千里眼からはほど遠いです。ネイティブブラウザー機能により、ブラウザーが別のサーバーに接続するタイミングを示唆したり、ブラウザーが必要とする前にリソースをプリロードしたりできます。賢明に使用すると、これにより高速なエクスペリエンスがさらに速く見えるようになります。この記事では、rel = preconnect、rel = dns-prefetch、rel = prefetch、rel = preloadなどのネイティブブラウザー機能と、それらを活用する方法について説明します。
+
+ +

See Also

+ + + +

{{LandingPageListSubpages}}

diff --git a/files/ja/learn/performance/measuring_performance/index.html b/files/ja/learn/performance/measuring_performance/index.html new file mode 100644 index 0000000000..f70a9cfa20 --- /dev/null +++ b/files/ja/learn/performance/measuring_performance/index.html @@ -0,0 +1,105 @@ +--- +title: パフォーマンスの測定 +slug: Learn/Performance/Measuring_performance +tags: + - API + - Beginner + - Guide + - Tools + - Web +translation_of: Learn/Performance/Measuring_performance +--- +
{{LearnSidebar}} {{PreviousMenuNext("Learn/Performance/Perceived_performance", "Learn/Performance/Multimedia", "Learn/Performance")}}
+ +
+ +
パフォーマンスの測定は、あなたがあなたのアプリケーション、サイト、ウェブサービスを評価することを助ける重要な指標を提供します。たとえば、パフォーマンスの指標を使うことで、競合と比較してアプリケーションをどのように動作させるか決めたり、リリースごとのパフォーマンスを比較したりできます。測定対象として選択する指標はユーザー、サイト、そしてビジネスのゴールに関連するものであるべきです。それらは一貫した手法で収集、測定され、非技術系の関係者にも理解でき、利用可能なフォーマットで分析される必要があります。この記事ではサイトのパフォーマンス測定と最適化に利用できるウェブパフォーマンスの指標を紹介します。
+ +
+ + + + + + + + + + + + +
前提:基本的なコンピューターリテラシー、基本的なソフトウェアのインストール、クライアントサイドのウェブ技術の基本的な知識
目的: +

様々なウェブパフォーマンス API を通じて収集できる ウェブパフォーマンスの指標とデータの視覚化に利用できるツールの情報を提供すること

+
+ +

パフォーマンス API

+ +

ウェブのコードを書くとき、自分自身でパフォーマンス測定ツールを作るために利用できるたくさんのウェブ API があります。

+ +

クライアントサイドのウェブパフォーマンスを測定するために Navigation Timing API を利用できます。前のページをアンロードするために必要な時間、ドメインのルックアップにかかる時間、ウィンドウのロードハンドラー実行にかかる時間の合計などが含まれます。この API は、下図に示すナビゲーションイベント全てに関する指標として利用できます。

+ +

The various handlers that the navigation tiiming API can handle including Navigation timing API metrics Prompt for unload redirect unload App cache DNS TCP Request Response Processing onLoad navigationStart redirectStart redirectEnd fetchStart domainLookupEnd domainLookupStart connectStart (secureConnettionStart) connectEnd requestStart responseStart responseEnd unloadStart unloadEnd domLoading domInteractive domContentLoaded domComplete loadEventStart loadEventEnd

+ +

現在のページのパフォーマンスに関連する情報へのアクセスを提供する Performance API は、Performance Timeline API、Navigation Timing API、User Timing API、そして Resource Timing API を含みます。これらのインターフェースにより、JavaScript のタスクが完了するまでにかかる時間の正確な測定が可能になります。

+ +

PerformanceEntry オブジェクトは、パフォーマンスタイムラインの一部です。パフォーマンスエントリーは アプリケーション内の明示的なポイントでパフォーマンスの{{domxref("PerformanceMark","mark")}} または {{domxref("PerformanceMeasure","measure")}}  を作ること（たとえば {{domxref("Performance.mark","mark()")}} メソッドを呼び出すこと）で直接的に作成されます。パフォーマンスエントリーは、画像などリソースの読み込みのようなタイミングで間接的に作成されることもあります。

+ +

PerformanceObserver API はパフォーマンス測定のイベントを観察するために利用できます。さらにブラウザーのパフォーマンスタイムラインに新しいパフォーマンスエントリーが記録されるたびに通知することができます。

+ +

この記事ではこれらの API に深入りしませんが、これらの存在を知っていると便利です。パフォーマンスウェブ API を使う例についてより深く知りたい場合は Navigation and timings の記事を参照してください。

+ +

ツールと指標

+ +

パフォーマンスの改善を助けるために利用できるいくつかの異なるツールがあります。これらは一般的にふたつのカテゴリーに分類できます。

+ + + +

このコースでは両方のカテゴリーを取り上げます。そしてパフォーマンスの指標だけではなく、サイトのパフォーマンスが改善しているかどうかを測定するための指標についても議論します。

+ +

一般的なパフォーマンスレポートツール

+ +

PageSpeed Insights のようなツールではウェブサイトのパフォーマンスを測定できます。URL を入力すると数秒でパフォーマンスのレポートを入手できます。レポートはモバイルとデスクトップの両方でウェブサイトがどの程度の性能を示すかを表すスコアを含みます。これは、すでにできていることと改善が必要な部分についてのアイデアを得る良いスタート地点になります。

+ +

本記事の執筆時点で、MDN のパフォーマンスレポートのサマリーは以下のようになっています。

+ +

A screenshot of PageSpeed Insights report for the Mozilla homepage.

+ +

パフォーマンスレポートは、ページに何かが表示されまでにユーザーがどのくらい待たなければならないか、ページを表示するまでに何バイトのデータがダウンロードされる必要があるかなどの情報を含みます。さらに測定された値が良好と考えられるか、あるいは不良であるかも示します。

+ +

webpagetest.org は、サイトを自動的にテストして有益な指標を返すツールのもう一つの実例です。ぜひ webpagetest.org と PageSpeed Insights の両方であなたの好きなウェブサイトを実行してみてください。そしてスコアを見てみましょう。

+ +

ネットワークツール

+ +

多くのブラウザーが、読み込み対象のページに対してそれらがどのように動作しているか確認するために使えるツールを用意しています。たとえば、FIrefox の Network Monitor はネットワークからダウンロードされるすべてのアセットの詳細な情報を、それぞれダウンロードのどのくらいの時間がかかるかを示すグラフと合わせて表示します。

+ +

+ +

異なるアクションを実行したときのウェブアプリケーションやサイトのユーザーインターフェースのパフォーマンスを測定するために Performance Monitor を利用できます。これは ウェブアプリケーションやサイトを遅くしているかもしれない要素を指し示します。

+ +

+ +

結論

+ +

この記事ではウェブアプリケーションやサイトで利用可能なウェブパフォーマンスの指標の簡単な概要を紹介しました。次は、知覚されるパフォーマンスと、避けられないパフォーマンスへの影響をユーザーに深刻に見せない、あるいは完全に気づかれないようにするいくつかのテクニックを見ていきます。

+ +

{{PreviousMenuNext("Learn/Performance/Perceived_performance", "Learn/Performance/Multimedia", "Learn/Performance")}}

+ +

このモジュール内

+ + diff --git a/files/ja/learn/performance/perceived_performance/index.html b/files/ja/learn/performance/perceived_performance/index.html new file mode 100644 index 0000000000..8af223ce2e --- /dev/null +++ b/files/ja/learn/performance/perceived_performance/index.html @@ -0,0 +1,111 @@ +--- +title: 知覚されるパフォーマンス +slug: Learn/Performance/perceived_performance +tags: + - Perceived Performance + - Web Performance +translation_of: Learn/Performance/perceived_performance +--- +
{{LearnSidebar}}
+ +
{{PreviousMenuNext("Learn/Performance/what_is_web_performance", "Learn/Performance/Measuring_performance", "Learn/Performance")}}
+ +

知覚されるパフォーマンスは、ユーザーから見てウェブサイトがどれくらい速く感じられるかを表します。ユーザーがパフォーマンスをどのように知覚するかは、具体的な統計値と同じくらい、あるいはどんな具体的な統計値よりも重要ですが、それは主観的で簡単に計測できるものではありません。知覚されるパフォーマンスはユーザーの視点であり、計測される値ではありません。

+ +

この記事は、ユーザーの知覚と、主観的な要素を計測するために使える具体的なツールに目を通し、知覚されるパフォーマンスの簡潔な紹介を提供します。

+ + + + + + + + + + + + +
前提条件:基本的なコンピューターリテラシー、基本的なソフトウェアのインストール、クライアントサイドのウェブ技術の基本的な知識
目的: +

ウェブパフォーマンスに対するユーザーの知覚について基本的な理解を獲得すること

+
+ +

パフォーマンスはユーザーの知覚に関連します。ウェブサイトの読み込みや描画がどれくらい速く感じられるかは、そのサイトが実際にどのくらい速く読み込まれ描画されるか以上にユーザーの体験に大きなインパクトを与えます。ある操作に（遅延やメインスレッドの無効状態によって）長い時間がかかる場合であっても、待っている間にローディングスピナーや一連の便利なヒント・ティップス（あるいはジョーク、その他適切なものであれば何でも）を表示することでユーザーのエンゲージを維持することが可能です。そのようなアプローチはただ何も表示しないよりずっと良いことです。何も表示しないことはより長い時間を感じさせ、ユーザーはそれが壊れていると思って待つのを諦めるかもしれません。

+ +

知覚されるパフォーマンス

+ +

サイトがどのくらい速く読み込まれるか、ユーザーのインタラクションにどのくらい良く反応すかの知覚はきわめて重要です。それは定量化することが難しい一方、実際のダウンロード時間以上に重要です。サイトにはそれ以上高速化することができない領域があるかもしれません。しかし、他のセクションで議論した統計値がそれ以上改善できない場合でも、サイトをより速く感じさせることは可能です。

+ +

ユーザーがどう感じるかを計測するたった一つの統計値 (unicorn metric) はありませんが、統計値は改善（または悪化）を判断するために有用です。関連する計測値には、First Meaningful Paint  (FMP)、Largetst contentful paint (LCP)、Time to interactive (TTI)、render start、DOM interactive、Speed Index があります。

+ +

First paint はブラウザーから報告され、ページの変更が始まる時間をミリ秒単位で提供します。しかし、この変更はシンプルな背景色の更新や、より気付きづらい小さなものである可能性があります。それは変更の完了を意味しておらず、目に見えるものが何も描画されていない時間を報告することもあります。First Contentful Paint (FCP) はブラウザーが最初に意味のある何か、テキスト、フォアグラウンド・バックグラウンドの画像、またはキャンバスや SVG を描画した時間を報告します。読み込みの経験のまさに始まりを補足します。しかし、それはただ単なるコンテンツであるため、意味のあるコンテンツ、あるいはユーザーが消費できるコンテンツであることを意味していません。First Meaningful Paint (FMP) は実際に意味のあるコンテンツがスクリーンに映し出された時間です。それは、ユーザーが知覚する読み込みの経験としてより適切な統計値ですが、まだ理想的とは言えません。Largest contentful paint (LCP) は、ビューポートの中で最も大きい目に見えるコンテンツの要素が描画される時間を報告する、Largest Contentful Paint API の中で定義された統計値です。

+ +

Speed index も知覚されるパフォーマンスの概算として使用されます。それは目に見えるスクリーン上にピクセルが描画される平均時間を計測します。それはジッターも、どのコンテンツがユーザーによってより重要であるかも考慮しません。そのため完全な統計値ではありません。

+ +

これらの統計値は最初の読み込みと描画に関わります。ユーザーがサイトとインタラクションを始めた後もサイトが速いと感じさせることは重要です。このために、time to interactive は良い統計値です。それは読み込みプロセスにおける最後の long task が終わり、ユーザーに UI が利用可能になる時間を表します。

+ +

UI の欠落や質の悪い反応はどちらも知覚されるパフォーマンスに悪い影響を与えます。タスクに長い時間がかかる場合であっても、それをより速く見せる方法はあります。知覚されるパフォーマンスを改善するいくつかのティップスがあります。

+ +

知覚されるパフォーマンスを改善する

+ +

ネットワークを理解すること、ブラウザがどのように動作するか、ユーザーが知覚する時間など、こういったものはユーザーのインタラクションを改善する方法を理解するために役立ちます。しかし、速さの知覚を改善するために、人間の心がどのように働くかと言った全てを理解する必要はありません。

+ +

それがどのくらい速い、または遅いと感じられるかは、ユーザーが能動的に待つか、受動的に待つかに大きく影響されます。待つことには能動と受動のフェーズがあります。ユーザが活動しているとき、マウスを動かしたり、考えたり、楽しんだりしているとき、ユーザーは能動的なフェーズにいます。受動的なフェーズは、ユーザーがモノクロのスクリーンを見つめるように受動的に待つ時に起こります。受動と能動の時間が客観的に同じとき、ユーザーは受動的に待つ時間が長かったと感じるでしょう。読み込み、描画、または反応の時間が客観的にそれ以上小さくできない場合、待つことを受動から能動的に待つ時間に変えることでより速く感じさせることができます。

+ +

いくつか従うべきヒントとコツがあります。より深く知りたい場合、これらのヒントのいくつかには別途完全な記事があります。

+ +

コンテンツ、または少なくともページの一部をコンテンツが読み込み中であることと併せてできるだけ速く表示することは、知覚されるパフォーマンスを改善するためにきわめて重要です。たとえば、ページの描画は CSS と Java Script の読み込みとパース処理にブロックされるため、最初の読み込みに必要とされる CSS と JS の量を最小化することは知覚されるパフォーマンスに大きな影響を持つでしょう。バイトとしてのサイズが同じだったとしても、ページの描画をブロックしないことは読み込みをより速く感じさせます。

+ +

知覚されるパフォーマンスを改善するヒントとコツを以下に示します。

+ +

最初の読み込みを最小化する

+ +

知覚されるパフォーマンスを改善するために、最初のページ読み込みを最小化しましょう。すなわち、最初に、実際に表示するものすべて、ただし本当に使うものだけをダウンロードしましょう。それから残りをダウンロードしましょう。すべてのアセットを最後までダウンロードしたときにはアセットの総量は改善されていません。実際にはコードを追加する必要があるかもしれません。しかし、直ちに必要ではないアセットをユーザーに気づかれない形で後からダウンロードすることによって、ユーザーはダウンロードが速くなったように感じます。

+ +

アセットを最小化するには最初の読み込みとコンテンツのインタラクティブな機能を分割する必要があります。その結果、目に見えるテキスト、スタイル、画像などの必要なコンテンツが最初に読み込まれます。

+ +

最初のページ読み込みで使用されない、あるいは目に見えない画像やスクリプトは読み込みしないようにしましょう。それらは読み込みを遅らせて、ページが使用可能になってから読み込むか、必要になった時に読み込みましょう。最初のページ読み込みの後で、追加のアセットやリソースを読み込むことは知覚されるパフォーマンスを改善します。最初のリクエストで必要なデータを読み込み、必要に応じて徐々に必要な部分やデータを読み込むことは帯域が限られている場合やスペックの低いハードウェアの問題を緩和することにも役立ちます。

+ +

さらに、読み込むアセットを最適化する必要があります。画像と動画は最適なフォーマットで、圧縮され、適切なサイズで提供されるべきです。

+ +

コンテンツのジャンプとリフローを防ぐ

+ +

画像やサードバーティーの広告のような、コンテンツを押し下げたり他の場所にジャンプさせたりするアセットは、ページがまだ読み込み中であるように感じさせ、知覚されるパフォーマンスを悪化させます。ユーザーのインタラクションに起因することなくリフローするコンテンツは特に悪いと言えます。他と比べて読み込みが遅く、かつ他のコンテンツがスクリーンに描画された後に要素が読み込まれるアセットは、レイアウト上にそれらのためのスペースを残すよう事前に計画しましょう。そうすることでコンテンツは、とくにサイトがインタラクション可能になった後で、ジャンプやリサイズしなくなります。

+ +

フォントファイルの遅延を避ける

+ +

フォントの使用はユーザーの体験を良くすることも悪くすることもあります。適切なフォントを選ぶことは芸術的であり、ユーザーの体験を劇的に良くすることもできます。フォントは、特に使用するフォントをインポートしなければいけないという点でユーザーの体験を悪化させることがあります。インポートするフォントが最適化されていない場合や馬鹿げた Comic Sans が使用されている場合はそうです。スタイリングされていないテキストのチラつきや該当するテキストが見つからないことはどちらもパフォーマンスを悪化させます。

+ +

同じサイズとウェイトのフォールバックフォントを用意しておきましょう。そうすることでフォントの読み込みによるページの変化に気付かれにくくなります。

+ +

インタラクティブな要素はインタラクティブに

+ +

目に見えるインタラクティブな要素は常にインタラクティブで反応できるようにしましょう。入力の要素が目に見える場合、ユーザーは遅延なしにそれらとインタラクションできるべきです。ユーザーは反応に 50 ミリ秒より長い時間がかかる場合、それが遅れていると感じます。コンテンツの再描画が 16.67 ミリ秒（または 60 frames per second）より遅いか、不規則な間隔で再描画されるとページが壊れているように感じます。

+ +

CSS で入力用のモーダルを表示したり、可能な場合は JS で先行入力・自動補完を追加するなど、先行入力や漸進的な拡張を使いましょう。

+ +

タスクの開始をよりインタラクティブにする

+ +

キーの押し上げを待たずにキーの押し下げでコンテンツをリクエストすることにより、知覚されるコンテンツの読み込みを 200 ミリ秒減らすことができます。キーの押し上げに合わせて興味深く、ただし目立ちすぎない 200 ミリ秒のアニメーションを追加することで知覚される読み込みをさらに 200 ミリ秒減らすことができます。実際に 400 ミリ秒の時間を削減したわけではありませんが、ユーザーは、自分がコンテンツを待っていると感じるまでは待っているとは感じないものです。

+ +

結論

+ +

ダウンロード、描画、待ち時間を能動的なフェーズに変え、受動的に待つ時間を減らすことにより、客観的な測定値が同じであったとしても、ユーザーはコンテンツのダウンロード、描画、反応がより速くなったように感じます。これで速度向上のために何をするべきかわかりました。次はいくつかの統計値を確認し、これらのイベントをどのように測定できるか学びましょう。

+ +

{{PreviousMenuNext("Learn/Performance/what_is_web_performance", "Learn/Performance/Measuring_performance", "Learn/Performance")}}

+ +

このモジュール内

+ + diff --git a/files/ja/learn/performance/web_performance_basics/index.html b/files/ja/learn/performance/web_performance_basics/index.html new file mode 100644 index 0000000000..276e2f2e04 --- /dev/null +++ b/files/ja/learn/performance/web_performance_basics/index.html @@ -0,0 +1,89 @@ +--- +title: ウェブパフォーマンスの基礎 +slug: Learn/Performance/Web_Performance_Basics +tags: + - Best practices + - Website performance +translation_of: Learn/Performance/Web_Performance_Basics +--- +

{{draft}}あなたのウェブサイトが可能な限りのパフォーマンスを発揮すべき理由はたくさんあります。
+ 以下に、各トピックの詳細情報を提供するためのリンク付きのベストプラクティス、ツール、API の簡単なレビューを示します。

+ +

Best practices

+ + + +

Quick Wins

+ +

CSS

+ +

Web performance is all about user experience and perceived performance. As we learned in the critical rendering path document, linking CSS with a tradional link tag with rel="stylesheet" is synchronous and blocks rendering. Optimize the rendering of your page by removing blocking CSS.

+ +

To load CSS asynchronously one can simpy set the media type to print and then change to all once loaded. The following snippet includes an onload attribute, requiring Javascript, so it is important to include a noscript tag with a traditional fallback.

+ +
<link rel="stylesheet" href="/path/to/my.css" media="print" onload="this.media='all'">
+<noscript><link rel="stylesheet" href="/path/to/my.css"></noscript>
+
+ +

The downside with this approach is the flash of unstyled text (FOUT.) The simplist way to address this is by inlining CSS that is required for any content that is rendered above the fold, or what you see in the browser viewport before scrolling. These styles will improve perceived performance as the CSS does not require a file request.

+ +
<style type="text/css">
+// Insert your CSS here
+</style>
+
+ +

Javascript

+ +

Avoid Javascript blocking by using the async or defer attributes, or link javascript assets after the page's DOM elements. Javascript only block rendering for elements that appear after the script tag in the DOM tree.

+ +

Web Fonts

+ +

EOT and TTF formats are not compressed by default. Apply compression such as GZIP or Brotli for these file types. Use WOFF and WOFF2. These formats have compression built in.

+ +

Within @font-face use font-display: swap. By using font display swap the browser will not block rendering and will use the backup system fonts that are defined. Optimiize font weight to match the web font as closely as possible.

+ +

Icon web fonts

+ +

If possible avoid icon web fonts and use compressed SVGs. To further optimize inline your SVG data within HTML markup to avoid HTTP requests.

+ +

Tools

+ + + +

APIs

+ + + +

Things not to do (bad practices)

+ + + +

See also:

+ + diff --git a/files/ja/learn/performance/what_is_web_performance/index.html b/files/ja/learn/performance/what_is_web_performance/index.html new file mode 100644 index 0000000000..f969943627 --- /dev/null +++ b/files/ja/learn/performance/what_is_web_performance/index.html @@ -0,0 +1,90 @@ +--- +title: ウェブパフォーマンスとは何ですか？ +slug: Learn/Performance/What_is_web_performance +tags: + - Beginner + - Introduction + - Learn + - Performance + - Reference + - Tutorial + - Web Performance +translation_of: Learn/Performance/What_is_web_performance +--- +
{{LearnSidebar}}
+ +
{{PreviousMenuNext("Learn/Performance/why_web_performance", "Learn/Performance/Perceived_performance", "Learn/Performance")}}
+ +

ウェブパフォーマンスは、実際には遅い処理を速いように見せることを含め、ウェブサイトを速くすることに関わるすべての事柄を表します。サイトを速く読み込む、ユーザーが早くインタラクションを始められるようにする、あるいは、読み込みに時間がかかる場合は、たとえばローディングスピナーを表示するなど、ユーザーが安心できるフィードバックを提供する、これらができていますか？スクロールとアニメーションは滑らかですか？この記事では、客観的で測定可能なウェブパフォーマンス*についての簡潔なイントロダクションを提示し、どのような技術、テクニック、そして最適化に関わるツールが利用できるかを探っていきます。

+ + + + + + + + + + + + +
前提条件: +

基本的なコンピューターリテラシー、基本的なソフトウェアのインストール、クライアントサイドのウェブ技術の基礎知識

+
目的: +

Web パフォーマンスに関わる事項について基本的な理解を得ること

+
+ +

* 次の記事でカバーする主観的な知覚されるパフォーマンスの逆

+ +

ウェブパフォーマンスとは何ですか？

+ +

ウェブパフォーマンスはウェブサイトまたはウェブアプリケーションの客観的な測定結果とユーザーによって知覚される体験です。これには以下の主要な領域が含まれます。

+ + + +

まとめると、たくさんの要素がパフォーマンスに影響を与えます。レイテンシー、アプリケーションのサイズ、DOM ノードの数、リクエストされるリソースの数、JavaScript の性能、CPU 負荷、その他いろいろです。それらの読み込みとレスポンスの時間を小さくすることが重要です。それから、ユーザーの体験上後で必要になる部分を同期で読み込むなどして、サイトが利用可能になる時間をできる限り早くすることでレイテンシーを感じさせないようにするといった追加の要素も重要です。

+ +
+

注:ウェブのパフォーマンスには、Time to load、Frames per second、Time to interactive のような客観的や測定結果とコンテンツの読み込みがどれくらい長く感じられるかといった主観的な経験の両方が含まれます。

+
+ +

コンテンツはどのように描画されるか

+ +

効率的にウェブパフォーマンス、その背後にある問題やここまでに挙げた主要なトピックを理解するためにはブラウザーがどのように動作するかについていくつかの詳細を理解することが必要です。これには以下のトピックが含まれます。

+ + + +

結論

+ +

以上です。ウェブパフォーマンスのトピックに関するこの簡潔な要約が、あなたが全体のアイデアを理解するための助けとなり、さらに学ぶ意欲をかき立てることができたなら幸いです。この後は知覚されたパフォーマンスを取り上げ、避けられないパフォーマンスへの影響を、ユーザーにとって深刻に見えないようにする、あるいは完全に気づかれないようにする賢い方法について見ていきます。

+ +

{{PreviousMenuNext("Learn/Performance/why_web_performance", "Learn/Performance/Perceived_performance", "Learn/Performance")}}

+ +

このモジュール内

+ + diff --git a/files/ja/learn/performance/why_web_performance/index.html b/files/ja/learn/performance/why_web_performance/index.html new file mode 100644 index 0000000000..fdc99200d6 --- /dev/null +++ b/files/ja/learn/performance/why_web_performance/index.html @@ -0,0 +1,101 @@ +--- +title: ウェブパフォーマンスの "なぜ" +slug: Learn/Performance/why_web_performance +tags: + - Beginner + - Introduction + - Learn + - Performance + - Reference + - Tutorial + - Web パフォーマンス +translation_of: Learn/Performance/why_web_performance +--- +
{{LearnSidebar}}
+ +
{{NextMenu("Learn/Performance/What_is_web_performance", "Learn/Performance")}}
+ +

ウェブパフォーマンスは、遅いプロセスを速く見せることも含めて、ウェブサイトを速くすることがすべてです。この記事では、なぜウェブパフォーマンスがサイト訪問者にとって、またビジネスの目標にとって重要なのかを紹介しています。

+ + + + + + + + + + + + +
前提条件: +

基本的なコンピュータリテラシー、基本的なソフトウェアのインストール、クライアントサイドのウェブ技術の基本的な知識。

+
目標:良いユーザー体験のために、なぜウェブパフォーマンスが重要なのか、その基礎知識を身につけること。
+ +

ウェブパフォーマンスとは、サイトのコンテンツの読み込みやレンダリングの速さ、ユーザーとのやりとりへの反応の速さを指します。パフォーマンスの悪いサイトは、表示に時間がかかり、入力への反応が遅くなります。パフォーマンスの悪いサイトは、サイトの離脱率を高めます。パフォーマンスが悪いと、最悪の場合、コンテンツに完全にアクセスできなくなります。Web パフォーマンスの良い目標は、ユーザーがパフォーマンスに気づかないことです。サイトパフォーマンスのパフォーマンスに対する個人の認識は主観的なものですが、読み込みとレンダリングは測定できます。パフォーマンスが良いことは、ほとんどのサイト訪問者には明らかではないかもしれませんが、ほとんどの人は停滞しているサイトをすぐに認識するでしょう。それが私たちが気にする理由です。

+ +

なぜパフォーマンスを気にするのか？

+ +

ウェブパフォーマンスとそれに付随するベストプラクティスは、ウェブサイトの訪問者が良い体験をするために不可欠です。ある意味では、ウェブパフォーマンスはウェブアクセシビリティのサブセットと考えることができます。アクセシビリティと同様にパフォーマンスでは、サイト訪問者がサイトにアクセスするために使用しているデバイスとデバイスの接続速度を考慮します。

+ +

例として、この記事を書いている時点で、ファイルサイズが 22.6 MB を超える 400 以上の HTTP リクエストがあった CNN.com の読み込み体験を考えてみましょう。

+ + + +

22.6 MB のサイトは、3G ネットワーク上での読み込みに最大 83 秒かかり、DOMContentLoaded (サイトのベースとなる HTML 構造の意味) は 31.86 秒でした。

+ +

ダウンロードにかかる時間だけが大きな問題ではありません。多くの国では、いまだにメガバイト単位で請求されるインターネット接続があります。私たちの例では、22.6 MB の CNN.com をダウンロードするのに平均的なインド人の日給の約 11 % の費用がかかることになります。アフリカ北西部のモバイル・デバイスからだと、平均的な給料の2日分の費用がかかるかもしれません。 もしこのサイトが米国のキャリアの国際ローミングプランで読み込まれたとしたら？その費用に誰もが泣くことでしょう。("how much your site costs to download" を参照)

+ +

コンバージョン率を改善する

+ +

サイトのダウンロードとレンダリング時間を短縮することで、コンバージョン率とユーザー維持率が向上します。

+ +

コンバージョン率とは、サイト訪問者が測定された、または希望するアクションを実行する率のことです。例えば、購入する、記事を読む、ニュースレターを購読するなどです。コンバージョン率として測定されるアクションは、ウェブサイトのビジネス目標によって異なります。

+ +

パフォーマンスはコンバージョンに影響を与えます。サイト訪問者は、サイトが2秒以内に読み込まれることを期待していますが、モバイル (一般的にはもっと時間がかかる) ではそれ以下になることもあります。同じサイト訪問者でも、遅いサイトを3秒で放棄し始めます。

+ +

サイトの読み込み速度は1つの要因です。サイトがユーザーとのやり取りに反応するのが遅かったり、不愉快に見えたりすると、サイト訪問者は興味を失い、信頼を失います。

+ +

ここでは、パフォーマンス向上の実例をいくつか紹介します。

+ + + +

サイト訪問者を惹きつけ、維持するためには、アクセスしやすいサイトを作成し、優れたユーザー体験を提供する必要があります。ウェブサイトを構築するには、HTML、CSS、JavaScript が必要であり、通常は画像や動画などのバイナリファイルタイプも含まれます。サイトを構築する際の決定やツールの選択は、完成した作品のパフォーマンスに大きく影響します。

+ +

良いパフォーマンスは資産です。パフォーマンスが悪ければ負債となります。サイトの速度は、バウンス率、コンバージョン、収益、ユーザー満足度、検索エンジンランキングに直接影響します。パフォーマンスの高いサイトは、訪問者の維持率とユーザーの満足度を高めることが示されています。遅いコンテンツはサイトの放棄につながることが示されており、訪問者の中には二度と戻ってこない人もいます。クライアントとサーバーの間を通過するデータ量を減らすことで、すべての関係者のコストを削減します。HTML/CSS/JavaScript とメディアファイルのサイズを減らすことで、ロード時間とサイトの消費電力の両方を削減できます (パフォーマンス予算を参照)。

+ +

パフォーマンスのトラッキングは重要です。ネットワーク速度やデバイスの機能など、複数の要因がパフォーマンスに影響を与えます。また、ビジネスの目的が違えば、サイトやサポートしている組織の目標に応じて、異なるメトリクスの方がより関連性が高いことを意味する場合もあります。サイトのパフォーマンスがどのように認識されるかは、ユーザー体験です。

+ +

まとめ

+ +

ウェブパフォーマンスは、アクセシビリティだけでなく、組織やビジネスの目標を達成するための他のWeb サイトの測定基準にとっても重要です。ウェブサイトのパフォーマンスの良し悪しは、ほとんどのサイトの全体的な有効性と同様に、ユーザーエクスペリエンスと強力に相関しています。これが、ウェブパフォーマンスに注意を払うべき理由です。

+ +

{{NextMenu("Learn/Performance/What_is_web_performance", "Learn/Performance")}}

+ +

このモジュール

+ + -- cgit v1.2.3-54-g00ecf