このページは Cloud Translation API によって翻訳されました。

Client Hints を使用してユーザーに適応する

Jeremy Wagner

あらゆる場所で高速なサイトを開発するのは、一筋縄ではいきません。膨大な数の接続しているネットワークの品質乗り越えられないタスクに思えるかもしれません。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" />

警告: 以前のバージョンの仕様には Accept-CH-Lifetime ヘッダーが含まれていましたが、現在は削除されており、サイトもこのヘッダーの送信を停止する必要があります。これを使用してヒントがブラウザセッションで保持されるようにしていた場合は、関連するレスポンスで必要な Accept-CH ヘッダーを送信する必要があります。

クライアント向けのヒント

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 になります。

本質的サイズと
サイズがあります。INTRINSIC というラベルの付いた 320x240 ピクセルのボックスが表示されます。
サイズ。その中には 256x192 ピクセルの小さなボックスがあり、
CSS が適用された HTML img 要素。この箱のラベルは「EXTRINSIC」です
サイズ。右側は要素に適用された CSS を含むボックスで
外部サイズが異なるように img 要素のレイアウトを変更する
サイズが小さくなります。 — **図 1**.本質的関数と本質的関数とサイズがあります。レイアウトファクタが設定されると、画像の外部サイズが大きくなる適用されます。この例では、`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

注: この情報はユーザーの識別に使用される可能性があるため、Device-Memory の値は意図的に粗くしています。有効な値は 0.25、0.5、1、2、4、8 です。

このヒントのユースケースとして、JavaScript の量を減らすことなどが考えられます。メモリが限られているデバイスのブラウザに送信されます。これは JavaScript が最も多くのリソースを必要とするコンテンツタイプのブラウザでは、 load。あるいは、デコードでメモリの使用量が少ないため、DPR が低い画像を送信することもできます。

ネットワークのヒント

Network Information API は、ユーザーのネットワークのパフォーマンスを説明するクライアントヒントのカテゴリ接続します私の意見では、これらのヒントが最も役立つと思います。それらを使用して、ユーザーに合わせたエクスペリエンスを提供するためにリソースへの負荷が軽減されます。

RTT

RTT ヒントは、次のリクエストのおおよそのラウンドトリップ時間（ミリ秒単位）を提供します。作成されます。RTT ヒントには、トランスポートレイヤ RTT とは異なり、次のものがあります。処理時間が短縮されます

RTT: 125

注: RTT の値は、フィンガープリントを防ぐために 25 ミリ秒単位で丸められます。

読み込みのパフォーマンスにおいてレイテンシが果たす役割があるため、このヒントが役立ちます。 RTT ヒントを使用すると、ネットワークの応答性、全体的なエクスペリエンスの提供をスピードアップできます（例: 一部のリクエストは省略）。

ダウンリンク

読み込みのパフォーマンスにおいてレイテンシは重要ですが、帯域幅は影響します。できます。Downlink ヒントはメガビット/秒（Mbps）で表され、ユーザーの接続の下流速度の概算値を表します。

Downlink: 2.5

注: Downlink の値は 25 キロビット/秒の最も近い倍数に丸められます。フィンガープリントは

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 はユーザーであるため、ネットワーク状態を説明するヒントではありません。ページから送信されるデータを減らすよう設定している。

注: すべてのクライアント向けのヒントの中で、Accept-CH でオプトインできないのは Save-Data のみです。このヒントを送信するかどうかは、Android デバイスで Chrome のデータセーバー機能のオンとオフを切り替えることで管理できます。

多くのことから、私は 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 で入手できますポイントは、ネットワーク関連のヒントをファッションについてよりよいものにすることで、接続します

クライアントを使用しないサイトの比較
低速のネットワーク接続（左）と、通信速度が遅い場合と同じサイトに適応するためのヒント
（右）。 — **図 2**. 地域の店舗の「会社概要」ページビジネスサイトをご覧ください。基本的なエクスペリエンスとしては、ウェブフォント、コンテンツ画像にも対応していますこれらはすべてネットワーク状態の読み込みが遅すぎる場合は省略できます。

サイトが Client Hints から提供される情報に適応している場合、アプローチを採用することにしましたどのリソースをインテリジェントに決定し、送信します。レスポンシブ画像選択ロジックを変更して、低品質の画像を特定のディスプレイに 1 つずつ画像を表示させることで、ネットワーク品質が高い場合に読み込みパフォーマンスを高速化できます。十分ではありません

この例では、キャンペーンのヒントが低速なネットワークでのサイトのパフォーマンスを向上させる。以下は WebPagetest の例です。クライアントのヒントに適応しない、低速ネットワーク上のサイトのウォーターフォール

スコニーの WebPagetest 滝
Timber サイトが低速のネットワーク接続ですべてのリソースを読み込んでいます。 — **図 3**. リソースを大量に消費するサイトではスクリプト、フォントを低速の接続で安全に移行できます。

同じ低速接続で同じサイトのウォーターフォールを使用しますサイトでは、Client Hints を使用して重要性の低いページリソースを除外します。

スコニーの WebPagetest 滝
Timber サイトでクライアントのヒントを使用して、
ネットワーク接続が遅くなります。 — **図 4**. 同じ接続上の同じサイト、「あれば便利」なリソースのみが除外され、より迅速な

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!
    })(),
  );
});

警告: クライアントヒントはすべてのブラウザでサポートされているわけではないため、event.request.headers.get が返す値を確認する必要があります。もう 1 つの方法は、window.devicePixelRatio や window.innerWidth などで同等の JS を IndexedDB に記録することです。これは Service Worker スコープでアクセスできます。

オプトインした Client Hints ヘッダーは、この方法で読み取ることができます。しかし、これは情報の一部を知る唯一の手段ではありません。ネットワーク固有のヒント navigator オブジェクトの同等の JavaScript プロパティで確認できます。

で確認できます。 <ph type="x-smartling-placeholder">

</ph> ファイル形式用の Imagemin プラグイン。
クライアントのヒント	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 で実装できます。これにより開発側の時間と労力を削減するだけでなくユーザーの画面をターゲットにした方法で、リソース（特に画像）をや srcset よりも細かく定義できます。

おそらくさらに重要なこととして、不安定なネットワーク接続をスニッフィングし、送信内容とその送信方法を変更することで、ユーザーとのギャップを解消できます。これにより、脆弱なネットワークでもユーザーが簡単にサイトにアクセスできるようにするには、多大な努力が必要です。 Service Worker を組み合わせることで、オフラインで利用できます。

クライアントヒントは Chrome および Chromium ベースでのみ使用できます。という、煩わしさのない方法でも使用できます。サポートしていないブラウザにも対応しています。クライアントのヒントを使用して、すべてのユーザーのデバイスに対応するインクルーシブで適応性に優れたエクスペリエンス機能、接続先のネットワークを定義します。おそらく他のブラウザベンダーはその価値と導入の意志を示します

リソース

Ilya Grigorik 氏、Eric Portis、Jeff Posnick、Yoav Weiss、Estelle Weyl の貴重なフィードバックや編集を加えたいと思います。