ブラウザがこの端末について報告する内容を確認できます。画面解像度、ビューポート、ピクセル比、CPU コア数、タイムゾーン、言語、ユーザーエージェント。すべてローカルで読み取ります。
ブラウザが Web サイトに開示するこの端末の情報を、読みやすい一覧にまとめます。 ウィンドウのサイズ変更やネットワーク状態の変化に応じて自動で更新されます。コピーボタンで完全なレポートを不具合票に貼り付けられます。
よく混同される 3 つの寸法があり、取り違えると「他人の環境でだけ壊れるレイアウト」が生まれます。画面解像度は物理パネルの値で、ウィンドウをどう変えても変化しません。利用可能な画面領域は、タスクバーや macOS のメニューバーなど OS が常時占有する部分を差し引いた値です。ビューポートはページが実際に描画できる領域で、CSS メディアクエリが反応するのはこの 3 つのうちビューポートだけです。
レスポンシブレイアウトをデバッグしているなら、必要なのはほぼ常にビューポートです。3840 ピクセルのモニターを使っていても、幅 700 ピクセルのウィンドウで閲覧しているかもしれません。画面幅を基準にメディアクエリを書くと、収まらない領域にデスクトップ版レイアウトを出してしまいます。
デバイスピクセル比が両者を結び付けます。比が 2 なら CSS ピクセル 1 つを 2×2 の物理ピクセルで描画するという意味で、古いモニターで鮮明だった画像が最近のノート PC でぼやける理由もこれです。ビューポートにピクセル比を掛けた値が、ラスター画像に本当に必要なピクセル数です。
ユーザーエージェントはこのページで最も信頼できない項目です。各ブラウザは何十年も、雑に書かれたサーバー側判定を通過するために他社の名前を自分の文字列へ追加してきました。だから現在の Chrome も Mozilla、AppleWebKit、KHTML、Gecko、Safari を同時に名乗ります。フィンガープリント対策として、各社はこの文字列の凍結と簡素化を進めています。
判断材料ではなくヒントとして扱ってください。ある機能の有無を知りたいなら、その機能自体を検出します。API の存在確認は 1 行で済み、コードを書いた時点で存在しなかったブラウザでも動作し、ベンダーが UA を書き換えても壊れません。
個々の項目だけで個人を特定することはできませんが、組み合わせると識別力は驚くほど高くなります。画面解像度、タイムゾーン、言語リスト、CPU コア数、ピクセル比を合わせると、数百万人の訪問者の中で一意になることも珍しくありません。トラッカーがこれらを収集するのはそのためです。
一部の項目が意図的にぼかされたり非公開になっていたりするのも同じ理由です。デバイスメモリは粗い段階に切り下げられ、コア数の上限を設けたり、メモリを一切公開しなかったり、汎用的なプラットフォーム文字列を返すブラウザもあります。Do Not Track は事実上放棄されており、尊重するサイトはほとんどなく、多くのブラウザは送信自体をやめました。ここが空でも何も意味しません。
開発上の実践的な結論は、本当に必要な最小限だけを取得することです。重いアニメーションを読み込むか判断したいなら、コア数から推測するのではなく最初のフレームの描画時間を実測してください。実測は推定スペックに勝り、フィンガープリントの面積も増やしません。