あらゆる場所で高速なサイトを開発するのは、一筋縄ではいきません。膨大な数の 接続しているネットワークの品質 乗り越えられないタスクに思えるかもしれません。Google Cloud の ブラウザ機能を利用して読み込みパフォーマンスを向上させる方法、 ユーザーのデバイスの機能、ネットワークの品質 ?解決策は、クライアント ヒントです!
Client Hints はオプトイン HTTP リクエスト ヘッダーのセットです。このヘッダーにより、 ユーザーのデバイスと接続先のネットワークの 特性を把握します方法 この情報サーバーサイドにより、Google のデリバリーの方法を デバイスやネットワークの状態に応じてコンテンツを分類できます。これにより よりインクルーシブな体験を提供できます
コンテンツ交渉がすべて
クライアントのヒントはコンテンツ ネゴシエーションのもう一つの方法です。つまり、 コンテンツ レスポンスを作成します。
コンテンツネゴシエーションの一例として
Accept
使用します。ブラウザが認識するコンテンツ タイプと、
サーバーはレスポンスのネゴシエーションに使用できます。画像リクエストの場合、コンテンツは
Chrome の Accept
ヘッダーの内容は次のとおりです。
Accept: image/webp,image/apng,image/*,*/*;q=0.8
すべてのブラウザは JPEG、PNG、GIF などの画像形式をサポートしていますが、Accept は この場合はブラウザも WebP と APNG。この情報を使用して ブラウザごとに最適な画像タイプをネゴシエートします。
<?php
// Check Accept for an "image/webp" substring.
$webp = stristr($_SERVER["HTTP_ACCEPT"], "image/webp") !== false ? true : false;
// Set the image URL based on the browser's WebP support status.
$imageFile = $webp ? "whats-up.webp" : "whats-up.jpg";
?>
<img src="<?php echo($imageFile); ?>" alt="I'm an image!">
クライアントのヒントは、Accept
と同様に、コンテンツについて交渉するためのもう一つの手段ですが、
コンテキストに基づいて識別します。Client Hints API では、
ユーザーの個人レベルに基づいてサーバーサイドのパフォーマンスを
重要でないリソースを提供するかどうかの判断など、
接続できないことを意味しますこのガイドでは、Chronicle にデータを取り込むための
コンテンツ配信を効率化する方法と、そのヒントを
設計されているからです
オプトイン
Accept
ヘッダーとは異なり、Client Hints は魔法のように(
ただし、Save-Data
については後で説明します)。データの保持と
使用する場合は、使用する Client Hints をオプトインする必要があります。
受信するには、Accept-CH
ヘッダーを送信して
resource:
Accept-CH: Viewport-Width, Downlink
Accept-CH
の値は、サイトがリクエストしたヒントのカンマ区切りのリストです。
後続のリソース リクエストの結果を決める際に使用されます。リリースを
クライアントがこのヘッダーを読み取ると、「このサイトは Viewport-Width
をリクエストしています」というメッセージが表示されます。
「Downlink
Client Hints」と入力します。具体的なヒントについて気にする必要はありません。
これについてはこの後すぐに説明します。
これらのオプトイン ヘッダーは、任意のバックエンド言語で設定できます。たとえば、PHP の
header
関数を使用できます。
これらのオプトイン ヘッダーは、http-equiv
属性
<meta>
タグの場合:
<meta http-equiv="Accept-CH" content="Viewport-Width, Downlink" />
クライアント向けのヒント
Client Hints は、ユーザーが使用しているデバイス、使用状況、 サイトへのアクセスに使用しているネットワーク。Chronicle SOAR の いくつかあります。
デバイスに関するヒント
クライアント ヒントの中には、ユーザーのデバイスの特性(通常は画面)を説明するものもある 説明します。そのいくつかは、顧客に最適なメディア リソースの選定に役立ちます。 そのすべてが必ずしもメディア中心であるわけではありません。
このリストに入る前に、使用されている主な用語をいくつか確認しておきましょう。 : 画面とメディアの解像度を示します。
固有のサイズ: メディア リソースの実際のサイズ。たとえば Photoshop で画像を開くと、画像サイズ ダイアログに表示される寸法が その本質的なサイズを表します。
密度修正された固有サイズ: 適用後のメディア リソースのディメンション ピクセル密度が調整されています。画像の本質的なサイズ デバイス ピクセルで割る できます。 例として、次のマークアップについて考えてみましょう。
<img
src="whats-up-1x.png"
srcset="whats-up-2x.png 2x, whats-up-1x.png 1x"
alt="I'm that image you wanted."
/>
たとえば、1x
画像の本質的なサイズが 320x240 で、
2x
画像の固有のサイズは 640x480 です。このマークアップがクライアントによって解析され
画面デバイスのピクセル比が 2 のデバイス(Retina など)にインストールされている
2x
画像がリクエストされます。密度修正後本質的サイズ
640x480 を 2 で割った値が 320x240 のため、2x
画像は 320x240 です。
極端なサイズ: CSS やその他のレイアウト後のメディア リソースのサイズ
要因(width
属性や height
属性など)が適用されています。始めましょう
密度補正された画像を読み込む <img>
要素があるとします。
320x240 のサイズですが、CSS の width
プロパティと height
プロパティもあります。
値 256px
と 192px
がそれぞれ適用されます。この例では
この <img>
要素の外部サイズは 256x192 になります。
width: 256px;
の CSS ルールを適用します。
height: 192px;
は、本質的にサイズが 320x240 の画像を変換します。
256x192 の外部サイズに変換しましたいくつかの用語については、デバイス固有のリストを見ていきましょう。 クライアント ヒントが用意されています。
ビューポートの幅
Viewport-Width
は、ユーザーのビューポートの幅(CSS ピクセル単位)です。
Viewport-Width: 320
このヒントを画面固有の他のヒントと組み合わせることで、 特定の画面サイズに最適な画像の処理(切り抜きなど) ( ルート)、 または、現在の画面幅に不要なリソースを省略することもできます。
DPR
DPR
(デバイス ピクセル比)は、CSS に対する物理ピクセルの比率を報告します。
ピクセル数:
DPR: 2
このヒントは、画面の画像に対応する画像ソースを選択する際に役立ちます。
ピクセル密度(srcset
での x
記述子と同様)
属性をご覧ください)。
幅
Width
ヒントは、<img>
または
sizes
を使用する <source>
タグ
属性です。
sizes
は、リソースの外部サイズをブラウザに伝えます。
Width
はその外部サイズを使用して、固有のサイズを持つ画像をリクエストします。
現在のレイアウトに最適な選択です
たとえば、ユーザーが 320 CSS ピクセルのワイド スクリーンでページをリクエストしたとします
DPR は 2 ですデバイスが、<img>
要素を含むドキュメントを読み込みます。
sizes
属性値 85vw
(つまり、すべてビューポートの幅の 85% を占めます。
。Width
ヒントが有効になっている場合、クライアントは
<img>
の src
のリクエストを使って、この Width
ヒントをサーバーに送信します。
Width: 544
この場合、クライアントは最適な組み込みインフラストラクチャを リクエストされた画像の幅は、ビューポートの幅の 85%(272 ピクセル)になります。 に画面の DPR(2)を掛けます。これは 544 ピクセルです。
このヒントは特に重要です。これは、 密度補正された画面の幅だけでなく、この重要な部分を レイアウト内の画像の外部サイズにあわせて説明します。これにより、 両方に最適な画像レスポンスをネゴシエートする機会を 調整する必要があります。
コンテンツ DPR
画面にはデバイスのピクセル比があることはすでに説明しましたが、リソースも
独自のピクセル比があります最も単純なリソース選択のユースケースでは、
デバイスとリソースの比率は、同じでもかまいません。でも!両方の
DPR
ヘッダーと Width
ヘッダーが使用されている場合、リソースの外部サイズは
両者が異なるシナリオが生まれますここで Content-DPR
ヒントを
出番です
他のクライアント ヒントとは異なり、Content-DPR
はリクエスト ヘッダーではありません。
代わりに、レスポンス ヘッダー サーバーは、常に DPR
および
Width
ヒントはリソースの選択に使用されます。Content-DPR
の値は、
次の式の結果になります。
Content-DPR
= [選択した画像リソースのサイズ] ÷ ([Width
] / [DPR
])
Content-DPR
リクエスト ヘッダーが送信されると、ブラウザはスケーリング方法を認識します
画面のデバイス ピクセル比とレイアウトを表す指定された画像です。これなしでは、
画像が適切に拡大縮小されない場合があります。
デバイスメモリ
厳密に言えば、デバイスメモリの一部
API の場合、Device-Memory
は、
データのおおよその
メモリ
現在のデバイスの GiB 単位:
Device-Memory: 2
このヒントのユースケースとして、JavaScript の量を減らすことなどが考えられます。 メモリが限られているデバイスのブラウザに送信されます。これは JavaScript が最も 多くのリソースを必要とするコンテンツ タイプのブラウザでは、 load。 あるいは、デコードでメモリの使用量が少ないため、DPR が低い画像を送信することもできます。
ネットワークのヒント
Network Information API は、 ユーザーのネットワークのパフォーマンスを説明するクライアント ヒントのカテゴリ 接続します私の意見では、これらのヒントが最も役立つと思います。それらを使用して、 ユーザーに合わせた エクスペリエンスを提供するために リソースへの負荷が軽減されます。
RTT
RTT
ヒントは、次のリクエストのおおよそのラウンド トリップ時間(ミリ秒単位)を提供します。
作成されます。RTT
ヒントには、トランスポート レイヤ RTT とは異なり、次のものがあります。
処理時間が短縮されます
RTT: 125
読み込みのパフォーマンスにおいてレイテンシが果たす役割があるため、このヒントが役立ちます。
RTT
ヒントを使用すると、ネットワークの応答性、
全体的なエクスペリエンスの提供をスピードアップできます(例:
一部のリクエストは省略)。
ダウンリンク
読み込みのパフォーマンスにおいてレイテンシは重要ですが、帯域幅は影響します。
できます。Downlink
ヒントはメガビット/秒(Mbps)で表され、
ユーザーの接続の下流速度の概算値を表します。
Downlink: 2.5
RTT
と組み合わせて Downlink
を使用すると、コンテンツの表示方法を変更できます。
ネットワーク接続の品質に基づいてユーザーに配信されます。
エクアドル時間(ECT)
ECT
ヒントは有効な接続タイプ(Effective Connection Type)を表します。この値は
接続タイプの列挙リスト。各タイプの接続は、
RTT
と Downlink
の両方の指定範囲内
あります。
このヘッダーでは、実際の接続タイプが
ゲートウェイが基地局であるか Wi-Fi アクセスであるかは報告されません。
あります代わりに、現在の接続のレイテンシと帯域幅を分析し、
最も似ているネットワーク プロファイルを決定します。たとえば
Wi-Fi 経由で低速のネットワークに接続する場合、ECT
には 2g
の値が入力されることがあります。
これは有効な接続に最も近いものです。
ECT: 2g
ECT
の有効な値は 4g
、3g
、2g
、slow-2g
です。このヒントは、
接続品質を評価するための出発点として使用され、その後、
RTT
ヒントと Downlink
ヒントを使用して絞り込みます。
データの保存
Save-Data
はユーザーであるため、ネットワーク状態を説明するヒントではありません。
ページから送信されるデータを減らすよう設定している。
多くのことから、私は Save-Data
をネットワークのヒントとして分類しています。
他のネットワークのヒントと同様です。ユーザーが
高レイテンシ/低帯域幅の環境で有効になる可能性が高い。このヒントを
常に次のようになっています。
Save-Data: on
Google では、Google Workspace で
Save-Data
。
パフォーマンスへの影響は多大なものになり得ます。これはユーザーが広告を
送ってほしいものを減らしてほしいって!これに耳を傾けて行動すれば
ユーザーに高く評価してもらうことができます。
すべてを組み合わせる
Client Hints をどのように使用するかは、開発者によって異なります。なぜなら 多数のオプションがあります。アイデアを形にするために、 クライアントのヒントは Sconnie で Timber: 架空の木材 地方に拠点を置く同社はこれはリモートワークや エリア 脆弱になる場合があります。Client Hints などのテクノロジーは、 ユーザーに変化をもたらします
レスポンシブ画像
最も単純なレスポンシブ画像のユースケースを除き、どれも複雑になる可能性があります。もし
画面ごとに同じ画像の複数のパターンとパターンがある
サイズのほか、形式の違いは何でしょうか。このマークアップはとても複雑とてもします
できます。
間違えやすく、重要なことを忘れたり誤解したりしやすい
コンセプト(sizes
など)。
<picture>
と srcset
は間違いなく優れたツールですが、
複雑なユースケースでは
開発と保守に時間がかかります自動化と
ただし、生成には手間がかかりますが、
<picture>
と srcset
は、自動化のニーズに対応できるほど複雑です。
高い柔軟性が維持されます
Client Hints はこれを簡素化できます。画像レスポンスについてクライアントと交渉する ヒントは次のようになります。
- ワークフローに応じて、まず画像処理(例:
アート主体の画像など)を
Viewport-Width
のヒントで確認できます。 Width
ヒントとDPR
ヒントを確認して画像の解像度を選択します。 画像のレイアウト サイズと画面密度(srcset
でのx
記述子とw
記述子の動作を確認)。- ブラウザがサポートする最適なファイル形式(
Accept
はほとんどのブラウザで機能します)。
架空の木材会社のクライアントが心配していたところ、 クライアント ヒントを使用する PHP でのレスポンシブ画像選択ルーチンについて説明します。つまり このマークアップをすべてのユーザーに送信する代わりに、
<picture>
<source
srcset="
company-photo-256w.webp 256w,
company-photo-512w.webp 512w,
company-photo-768w.webp 768w,
company-photo-1024w.webp 1024w,
company-photo-1280w.webp 1280w
"
type="image/webp"
/>
<img
srcset="
company-photo-256w.jpg 256w,
company-photo-512w.jpg 512w,
company-photo-768w.jpg 768w,
company-photo-1024w.jpg 1024w,
company-photo-1280w.jpg 1280w
"
src="company-photo-256w.jpg"
sizes="(min-width: 560px) 251px, 88.43vw"
alt="The Sconnie Timber Staff!"
/>
</picture>
個々のブラウザ サポートに基づいて、次のように減らすことができました。
<img
src="/image/sizes:true/company-photo.jpg"
sizes="(min-width: 560px) 251px, 88.43vw"
alt="SAY CHEESY PICKLES."
/>
この例では、/image
URL は PHP スクリプトで、その後にパラメータが続きます。
書き換え
mod_rewrite:これは、
バックエンド スクリプトをサポートするため、画像のファイル名と追加パラメータを受け取ります。
与えられた条件で最適な画像を選択します。
「しかし、これは単に <picture>
と srcset
を
確認しましょう」を質問します。
ある意味では可能ですが、重要な違いがあります。それは、アプリケーションで クライアントがメディアで反応するためのヒントを得る。ほとんどの作業は(すべてとは言わないまでも) 自動化が容易。これには、これを行えるサービス(CDN など)が含まれる 自動的に作成されます。一方 HTML ソリューションでは、新しいマークアップを 提供しますマークアップの生成を自動化できます。お使いの 設計や要件は変わる可能性がありますが、場合によっては、 将来自動化戦略を見直す
Client Hints API を使用すると、ロスレスで高解像度のトピックから開始できます。
あらゆる組み合わせに最適なよう、動的にサイズ変更できる画像
決定できます固定値を列挙する必要がある srcset
とは異なり、
ブラウザが選択できる画像候補のリスト。このアプローチは
柔軟性を高めることができます。srcset
を使用すると、ブラウザに大まかなセットを提供せざるを得なくなりますが、
バリアント(256w
、512w
、768w
、1024w
など)のクライアント ヒント
マークアップを積み重ねることなく、あらゆる幅に対応できます。
もちろん、画像選択のロジックをご自身で記述する必要はありません。Cloudinary
w_auto
を使用する際にクライアント ヒントを使用して画像レスポンスを作成する
パラメータ、
ブラウザ使用時のダウンロード バイト数が中央値で 42% 減少
クライアントのヒントをご覧ください
でも気をつけて!PC 版 Chrome 67 の変更により、サポートを終了しました (クロスオリジン クライアント用) ヒントです。 幸い、こうした制限はモバイル版 Chrome には影響しません。 機能の開発時は、すべてのプラットフォームでまったく削除される予定です。 ポリシーの作成が完了しました。
低速なネットワークを使用するユーザーをサポートする
適応型パフォーマンスとは、リソースの提供方法を調整できるという考え方です。 Client Hints が提示する情報に基づく特に ユーザーのネットワーク接続の現在の状態に関する情報。
Sconnie Timber のサイトの懸念事項として、Google は
ネットワークの速度が遅く、Save-Data
、ECT
、RTT
、Downlink
ヘッダーが
確認しています。これが完了すると、ネットワーク品質の
介入すべきかどうかを判断するために使用できるスコアです。
体験できますこのネットワーク スコアは 0
~1
です。0
が最も低いスコアです。
可能なネットワーク品質であり、1
が最適です。
最初に、Save-Data
が存在するかどうかを確認します。有効である場合、スコアは
0
。ユーザーは、
より軽量かつ高速に操作できます。
ただし、Save-Data
が存在しない場合は、さらに ECT
の値を重み付けします。
ネットワークを説明するスコアを計算するための RTT
と Downlink
のヒント
向上しますネットワーク スコア生成ソース
コード
GitHub で入手できますポイントは、ネットワーク関連のヒントを
ファッションについてよりよいものにすることで、
接続します
![クライアントを使用しないサイトの比較
低速のネットワーク接続(左)と、通信速度が遅い場合と同じサイトに適応するためのヒント
(右)。](https://web.developers.google.cn/static/articles/performance-optimizing-content-efficiency-client-hints/image/a-comparison-a-site-doe-b20caac28fc7f.png?authuser=6&hl=ja)
サイトが Client Hints から提供される情報に適応している場合、 アプローチを採用することにしましたどのリソースをインテリジェントに決定し、 送信します。レスポンシブ画像選択ロジックを変更して、低品質の画像を 特定のディスプレイに 1 つずつ画像を表示させることで、ネットワーク品質が高い場合に読み込みパフォーマンスを高速化できます。 十分ではありません
この例では、キャンペーンのヒントが 低速なネットワークでのサイトのパフォーマンスを向上させる。以下は WebPagetest の例です。 クライアントのヒントに適応しない、低速ネットワーク上のサイトのウォーターフォール
![スコニーの WebPagetest 滝
Timber サイトが低速のネットワーク接続ですべてのリソースを読み込んでいます。](https://web.developers.google.cn/static/articles/performance-optimizing-content-efficiency-client-hints/image/a-webpagetest-waterfall-6bc17bbfd8c27.png?authuser=6&hl=ja)
同じ低速接続で同じサイトのウォーターフォールを 使用します サイトでは、Client Hints を使用して重要性の低いページ リソースを除外します。
![スコニーの WebPagetest 滝
Timber サイトでクライアントのヒントを使用して、
ネットワーク接続が遅くなります。](https://web.developers.google.cn/static/articles/performance-optimizing-content-efficiency-client-hints/image/a-webpagetest-waterfall-3ba4268e712f2.png?authuser=6&hl=ja)
Client Hints の使用により、ページの読み込み時間は 45 秒以上から 表示されます。このシナリオでの Client Hints のメリットは、 重要ポイントを強調しており、批判的な言葉や 通信できます。
さらに、エクスペリエンスを損なわずに Client Hints を活用できる
をサポートしています。たとえば、リソースの調整と
ECT
ヒントの値を使用して配信されますが、引き続き完全な
ブラウザがサポートしていない場合は、デフォルト値にフォールバックを設定できます。
次のようになります。
// Set the ECT value to "4g" by default.
$ect = isset($_SERVER["HTTP_ECT"]) ? $_SERVER["HTTP_ECT"] : "4g";
ここで、"4g"
は ECT
ヘッダーで最高品質のネットワーク接続を表します。
説明します。$ect
を "4g"
に初期化すると、クライアントをサポートしていないブラウザは
ヒントには影響しません。オプトイン
キャッシュに気をつけて!
HTTP ヘッダーに基づいてレスポンスを変更するときは常に、
そのリソースの今後の取得をキャッシュがどのように処理するかを指定します。Vary
header は
ここで不可欠となります。キャッシュ エントリを、リクエスト ヘッダーの値に
与えられます。簡単に言うと、特定の HTTP リクエストに基づいてレスポンスを変更する
リクエスト ヘッダー。ほとんどの場合、そのヘッダーのリクエストは Vary
に含める必要があります。
次のようになります。
Vary: DPR, Width
ただし、これには大きな注意点があります。Vary
キャッシュ可能にしない
頻繁に変更されるヘッダー(Cookie
など)にレスポンスを返すのは
キャッシュできなくなります。このことがわかっていれば
クライアント ヒント ヘッダー(RTT
や Downlink
など)での Vary
の使用。
頻繁に変化する可能性があります。メッセージを変更したい場合は、
ECT
ヘッダーのみをキー化することを検討してください。これにより、
キャッシュミスを最小限に抑えられます
もちろん、これはレスポンスをキャッシュする場合にのみ該当します。
たとえば、コンテンツが動的な場合、HTML アセットはキャッシュに保存されません。その理由は次のとおりです。
再訪問時のユーザー エクスペリエンスが損なわれる恐れがあります。このような場合は、
回答は、必要に応じて自由に修正でき、
Vary
について懸念しています。
Service Worker でのクライアントのヒント
コンテンツ ネゴシエーションは、もはやサーバーだけのものではありません。Service Worker は
クライアントとサーバー間のプロキシとして機能するため、
JavaScript で配信されます。これには、クライアントのヒントも含まれます。Service Worker
fetch
イベントを処理する場合は、event
オブジェクトの
request.headers.get
メソッドを使用して、リソースのリクエスト ヘッダーを読み取ることができます。
self.addEventListener('fetch', (event) => {
let dpr = event.request.headers.get('DPR');
let viewportWidth = event.request.headers.get('Viewport-Width');
let width = event.request.headers.get('Width');
event.respondWith(
(async function () {
// Do what you will with these hints!
})(),
);
});
オプトインした Client Hints ヘッダーは、この方法で読み取ることができます。しかし、これは
情報の一部を知る唯一の手段ではありません。ネットワーク固有のヒント
navigator
オブジェクトの同等の JavaScript プロパティで確認できます。
クライアントのヒント | JS の同等のもの |
---|---|
「ECT」 | `navigator.connection.effectiveType` |
RTT | `navigator.connection.rtt` |
`Save-Data` | `navigator.connection.saveData` |
`Downlink` | `navigator.connection.downlink` |
`Device-Memory` | `navigator.deviceMemory` |
これらの API は、機能チェックが必要な場所では利用できないため、
in
演算子:
if ('connection' in navigator) {
// Work with netinfo API properties in JavaScript!
}
ここからは、サーバーで使用する場合と同じようなロジックを使用できますが、 クライアントのヒントを使用してコンテンツをネゴシエートするためにサーバーが必要ありません。サービス より高速かつ復元力の高いエクスペリエンスが 実現されます ユーザーがオフラインのときでもコンテンツを配信できる機能が加わりました。
まとめ
Client Hints API を使用すると、
実現できますユーザーのデバイスに応じてメディアを配信できる
機能を拡張できます。レスポンシブな画像を
特に複雑なユースケースの場合、<picture>
と srcset
で実装できます。これにより
開発側の時間と労力を削減するだけでなく
ユーザーの画面をターゲットにした方法で、リソース(特に画像)を
おそらくさらに重要なこととして、不安定なネットワーク接続をスニッフィングし、 送信内容とその送信方法を変更することで、ユーザーとのギャップを解消できます。これにより、 脆弱なネットワークでもユーザーが簡単にサイトにアクセスできるようにするには、多大な努力が必要です。 Service Worker を組み合わせることで、 オフラインで利用できます。
クライアント ヒントは Chrome および Chromium ベースでのみ使用できます。 という、煩わしさのない方法でも使用できます。 サポートしていないブラウザにも対応しています。クライアントのヒントを使用して、 すべてのユーザーのデバイスに対応するインクルーシブで適応性に優れたエクスペリエンス 機能、接続先のネットワークを定義します。おそらく他のブラウザベンダーは その価値と導入の意志を示します
リソース
- クライアントによる自動レスポンシブ画像 ヒント
- Client Hints とレスポンシブ画像 - Chrome での変更点 半角 67 文字(全角 17 文字)
- (お客様)のヒントを受ける (スライド)。
- Google Cloud による
Save-Data
Ilya Grigorik 氏、Eric Portis、Jeff Posnick、Yoav Weiss、Estelle Weyl の 貴重なフィードバックや編集を加えたいと思います。