デバイスピクセル比（DPR）とは？Retinaディスプレイで画像がぼやけて見える理由

何日もかけて丁寧にウェブサイトをデザインし、クッキリ鮮明なPNGロゴを書き出してデスクトップモニターで確認したところ、すべて完璧に見えたとします。しかし、まったく同じウェブページをiPhone、MacBook、あるいは4Kディスプレイで開いてみると、ロゴの輪郭がぼやけ、眠たい印象になってしまっていることに気づきます。

その一方で、同じページ上にあるテキストは驚くほどくっきりとシャープに表示されています。見出しはまるでガラスから切り出されたように精細なのに、写真やアイコン、ヒーローバナーだけが2005年頃の古いウェブサイトから持ってきたかのように粗く見えてしまうのです。

なぜ高価な高解像度スクリーンで表示すると、グラフィックが綺麗になるどころか悪化して見えるのでしょうか？

その答えを握るのが、デバイスピクセル比（Device Pixel Ratio: DPR） という数値です。

DPRを理解することは、ウェブデザイナー、フロントエンドエンジニア、サイト運営者にとって最も実用的なスキルの1つです。高密度ディスプレイをブラウザがどのように処理しているかを把握すれば、画像がぼやけてしまったり、レスポンシブな画像配信で悩んだりすることはもうなくなります。

---

根本的な問題：ハードウェアピクセル vs レイアウトピクセル

DPRを理解するには、まず従来のコンピューターモニターがどのように動作していたかを振り返る必要があります。

何十年もの間、デジタル画面の仕組みは単純でした。「コード上の1ピクセル」が「モニター上の物理的な発光ダイオード1個」と1対1で対応していたのです。

例えばモニターのネイティブ解像度が 1024 × 768 であれば、横に1,024個、縦に768個の微小なRGB発光素子が並んでいました。CSSで width: 200px; と指定すれば、ブラウザはモニターガラス上のハードウェアの点を正確に200個光らせるよう指示していました。

当時のディスプレイの画素密度は、おおよそ 72〜96 PPI（Pixels Per Inch） でした。100ピクセルのボタンは、世界中のほぼすべてのオフィスモニター上でほぼ同じ物理的な大きさに見えていたのです。

スマートフォン革命が従来の常識を覆した

このルールが一変したのが、2010年に高精細ディスプレイ（iPhone 4に搭載されたAppleの初代「Retinaディスプレイ」など）が一般市場に登場した瞬間でした。

ハードウェアメーカーは、まったく同じ物理的サイズのガラスの中に従来の4倍ものピクセルを詰め込みました。かつて 320 × 480 ピクセルだったiPhoneの画面に、わずか3.5インチのポケットサイズでありながら 640 × 960 物理ピクセル が凝縮されたのです。

この進化は、ウェブの世界に即座に重大な問題をもたらしました。

もしブラウザが従来のまま「1 CSSピクセル = 1 物理ピクセル」として処理し続けていたらどうなっていたでしょうか。

• デスクトップ向けに作られた一般的なウェブサイト（幅960px）は、切手ほどの極小サイズに縮小されてしまいます。
• ナビゲーションのリンクやボタンは幅2〜3ミリ程度になり、人間の指でタップすることは不可能です。
• 本文を読むには虫眼鏡が必要になってしまいます。

世界中のウェブサイトを破綻させるわけにはいきません。この問題を解決するため、ブラウザ開発者とウェブ標準化団体は、「ピクセル」の概念を完全に独立した2つのものに分離しました。

1. 物理ピクセル（ハードウェアピクセル / Physical Pixels）： ディスプレイパネルに物理的に組み込まれている、微小な光の点そのもの。
2. CSSピクセル（論理ピクセル / 参照ピクセル / CSS Pixels）： レイアウト、タイポグラフィ、余白、メディアクエリなどの設計のためにウェブブラウザが使用する抽象的な単位。

デバイスピクセル比（DPR）とは、まさにこれら2つの世界を結ぶ「変換レート（倍率）」のことなのです。

---

デバイスピクセル比（DPR）の正確な定義

デバイスピクセル比（DPR） とは、特定のディスプレイにおける「物理ハードウェアピクセル」と「CSS論理ピクセル」の比率を表します。

$$\text{DPR} = \frac{\text{物理ハードウェアピクセル}}{\text{CSS論理ピクセル}}$$

DPRは、次のような疑問に対する答えと考えることもできます。

「CSSスタイルシートで指定した 1px の正方形を描画するために、この画面は物理ハードウェアの点を何個使用しているか？」

一般的な画面タイプごとの計算式と挙動は以下のとおりです。

1. 標準ディスプレイ（DPR = 1.0）

• 意味： 1 CSSピクセル = 1 物理ハードウェアピクセル。
• 該当デバイス： 従来の1080pデスクトップモニター（24インチや27インチ）、一般的なオフィス向けノートPC、旧型テレビなど。
• レンダリングの様子： 100 × 100ピクセルの画像は、画面上のちょうど 100 × 100 個のハードウェアダイオードを占有します。拡大縮小や補間処理、引き伸ばしは発生しません。

2. High-DPI / Retinaディスプレイ（DPR = 2.0）

• 意味： 各軸に沿って 1 CSSピクセル = 2 物理ピクセル。
• 該当デバイス： MacBook Air、MacBook Pro、iPad、200%スケーリング設定の4Kモニター、多くのAndroidタブレット。
• レンダリングの様子： ピクセルは縦横の2次元で数えられるため、$1 \times 1$ のCSSピクセル領域の裏には $2 \times 2$ のグリッド、すなわち 4つの物理ピクセル が1つの論理レイアウト単位の描画に使われます。

3. 超高密度モバイル画面（DPR = 3.0）

• 意味： 各軸に沿って 1 CSSピクセル = 3 物理ピクセル。
• 該当デバイス： iPhone 13 Pro〜iPhone 16 Pro、Samsung Galaxy Sシリーズ、Google Pixelのフラッグシップ機。
• レンダリングの様子： $1 \times 1$ のCSSピクセル領域の裏には $3 \times 3$ のグリッドが配置されます。つまり、わずか1つのCSSピクセルに対して 9つの物理ハードウェアの点 が点灯します。

---

主なデバイスのDPRチートシート

デバイス	物理画面解像度	CSSビューポートサイズ	デバイスピクセル比 (DPR)	1 CSSピクセルあたりの物理ドット数
標準 24インチ オフィスモニター	1920 × 1080	1920 × 1080	1.0x	1 ドット ($1 \times 1$)
MacBook Air 13インチ (M2/M3)	2560 × 1664	1280 × 832	2.0x	4 ドット ($2 \times 2$)
MacBook Pro 16インチ (M3 Max)	3456 × 2234	1728 × 1117	2.0x	4 ドット ($2 \times 2$)
27インチ 4Kモニター (200%スケーリング時)	3840 × 2160	1920 × 1080	2.0x	4 ドット ($2 \times 2$)
14インチ WindowsノートPC (150%スケーリング時)	1920 × 1080	1280 × 720	1.5x	2.25 ドット
iPhone 15 / 16 (標準モデル)	2556 × 1179	393 × 852	3.0x	9 ドット ($3 \times 3$)
Samsung Galaxy S24 Ultra	3120 × 1440	384 × 832	3.0x	9 ドット ($3 \times 3$)
iPad Air 11インチ	2360 × 1640	1180 × 820	2.0x	4 ドット ($2 \times 2$)

WindowsノートPCの特徴に注目してください
WindowsノートPCのDPRが 1.5x になっている点にご注目ください。Apple製品は主に整数倍（2.0xや3.0xなど）の端正なスケールを採用しますが、Windowsのディスプレイ設定では小数点を含むスケーリング（125%、150%、175%）が可能です。そのため、DPRは 1.25 や 1.5 のような浮動小数点数になることも珍しくありません。

---

高DPRディスプレイで画像がぼやけて見える理由

iPhoneやMacBookが、1つのCSSレイアウトピクセルに対して4〜9個ものハードウェアドットを使用していることがわかれば、グラフィックがぼやけてしまう理由は明白です。

具体的な例に沿って順を追って見ていきましょう。

クライアントのロゴをウェブページに配置する場合を想定します。CSSで次のようにレイアウトサイズを指定しました。

.site-logo {
  width: 200px;
  height: 60px;
}

この領域に合わせて、ぴったり 200 × 60 ピクセル で書き出した logo.png をHTMLに埋め込みます。

<img src="logo.png" class="site-logo" alt="Acme Corp">

訪問者が使用しているモニターによって、舞台裏では次のような処理が行われます。

パターンA：1080pの標準オフィスモニターで閲覧（DPR = 1）

• ブラウザは画面上に 200 × 60 CSSピクセルの表示領域を確保します。
• 画面側は1 CSSピクセルにつき1個のハードウェアドットを持っています。
• 物理ハードウェア面積：$200 \times 60 = 12,000$ 個の発光ダイオード。
• 画像ファイルが保持するデータ：$200 \times 60 = 12,000$ 画像ピクセル。
• 結果： 完全な1対1の一致。画像ファイルの各ピクセルがハードウェアのピクセルにぴったり1つずつ配置され、ロゴは鮮明かつクリアに表示されます。

パターンB：MacBook Proや4Kモニターで閲覧（DPR = 2）

• レイアウト崩れを防ぐため、ブラウザは変わらず 200 × 60 CSSピクセルの枠を確保します。
• しかし、画面のDPRは2.0です。このレイアウト枠は、画面上では 400 × 120 物理ハードウェアピクセル 分の領域を占有します。
• 物理ハードウェア面積：$400 \times 120 = 48,000$ 個の発光ダイオード。
• 画像ファイルが持っているデータ：依然として $200 \times 60 = 12,000$ ピクセル分のみ。
• ブラウザ側から見ると、36,000ピクセル分の視覚情報が不足しています。
• 結果： ブラウザは画像を元の2倍の大きさに引き伸ばさざるを得ません。バイリニア補間やバイキュービック補間などのアルゴリズムを用いて「足りないピクセルが何色であるべきか」を推測して埋めます。その結果、輪郭がにじみ、シャープな線がぼやけ、ピントが合っていないように見えてしまいます。

パターンC：iPhone 16 Proで閲覧（DPR = 3）

• 200 × 60 CSSピクセルの枠が、物理画面上では 600 × 180 物理ピクセル（$108,000$ 個のハードウェアドット）に拡大されます。
• わずか12,000ピクセルの画像が、元の9倍の画素面積に引き伸ばされます。
• 結果： 著しいぼやけ、ジャギー（ピクセルの粗さ）、文字の不鮮明さが発生します。

なぜテキストはぼやけないのか？

ここで疑問に思うかもしれません。「画像が引き伸ばされるのなら、なぜHTMLのテキストはくっきり綺麗なままなのか？」

テキストはビットマップ画像のようなピクセルデータを持っていません。フォントは、数式に基づいた曲線と座標（ベジェ曲線）で記述された ベクター輪郭線（アウトライン） です。

2xや3xの高精細画面でテキスト段落を描画する際、OSとブラウザはディスプレイのネイティブな物理解像度に合わせてフォントのジオメトリを直接再計算します。利用可能な48,000個や108,000個のハードウェアピクセルをすべて使って、極めてシャープな輪郭線を描き出します。

完璧に鮮明なベクターテキストのすぐ隣にぼやけたビットマップ画像が並ぶため、高DPI画面では画像の粗さがより一層際立って目立ってしまうのです。

---

ブラウザで現在のDPRを確認する方法

現在お使いのスクリーンのデバイスピクセル比を確認するのに、専用のツールや拡張機能は必要ありません。

方法1：ブラウザの開発者ツール（コンソール）を使う

1. ブラウザの開発者ツールを開きます（Windows/Linuxなら F12、Macなら Cmd + Option + I）。
2. Console（コンソール） タブをクリックします。
3. 次のコードを入力します。

   window.devicePixelRatio

4. Enter キーを押します。

返された数値が、現在の画面のアクティブなDPRです。標準モニターなら 1、Retina MacBookなら 2、最新のスマートフォンなら 3（または設定に応じた倍率）が返されます。

方法2：JavaScriptでDPRの変更をリアルタイム検知する

DPRは利用状況によって動的に変化することをご存じでしょうか？

ユーザーがブラウザで拡大ズーム（Cmd + や Ctrl +）を行ったり、ブラウザウィンドウをノートPCの画面から外部の1080pモニターへ移動させたり、Windowsのディスプレイ設定で拡大率を変更したりすると、ブラウザのDPRは即座に更新されます。

モダンJavaScriptの matchMedia を使うと、DPRの変化を監視できます。

const updateDprNotice = () => {
  console.log(`現在のDPR: ${window.devicePixelRatio}`);
};

// 現在の解像度に合致するメディアクエリを作成
const dprQuery = window.matchMedia(`(resolution: ${window.devicePixelRatio}dppx)`);

// 解像度の変化（ズームやモニター間移動など）を監視
dprQuery.addEventListener("change", updateDprNotice);

---

画像のぼやけを防ぐ5つの実践的アプローチ

ここからは実践編です。旧型のモニターに重い大容量ファイルを無駄に読み込ませることなく、あらゆる画面でグラフィックや写真を鮮明に保つにはどうすればよいでしょうか。

現代のウェブ開発で標準的に用いられている5つの手法を紹介します。

1. ロゴやアイコン、図形にはSVGを採用する

図形やフラットカラー、ロゴマークなどの画像には、決してPNGやJPEGを使ってはいけません。代わりに SVG（Scalable Vector Graphics） を使用してください。

フォントと同様に、SVGはラスターグリッドではなくXMLの座標データで構成されたベクターファイルです。1xのモニター、3xのiPhone、あるいは16Kの超大型サイネージで表示しても、SVGはディスプレイの物理解像度を最大限に生かし、数学的に完全なシャープさでレンダリングされます。

<!-- あらゆるディスプレイで極めて鮮明、ファイルサイズもごくわずか -->
<img src="/logo.svg" width="200" height="60" alt="会社ロゴ">

使い分けの目安：

• ロゴ、アイコン、UIバッジ、矢印、ベクターイラスト $\rightarrow$ SVG
• 写真、写実的なスクリーンショット、複雑なイラスト $\rightarrow$ レスポンシブなsrcsetを備えたラスター形式（後述）

---

2. ラスター画像向けの「2倍ルール」（手軽な修正方法）

アバター写真や著者の顔写真など、CSSで常に固定サイズ（例：80px × 80px）で表示されるラスター画像がある場合：

1. 2倍の解像度（160px × 160px）で画像ファイルを書き出します。
2. ファイルサイズを抑えるため、WebP や AVIF などの最新フォーマットで保存します。
3. HTMLやCSSで、表示上の目標サイズを明示的に制限します。

<!-- 物理ファイルは160x160だが、表示は80x80 CSSピクセルに制限 -->
<img src="/avatar@2x.webp" width="80" height="80" alt="プロフィール写真">

1xモニターではブラウザが画像を適度に縮小（ダウンサンプリング）して綺麗に表示し、2x Retinaディスプレイではハードウェアの発光ドット1つひとつに本来の画素情報が行き渡るため、非常にシャープな画質が得られます。

---

3. ピクセル密度記述子（1x, 2x）を付けた srcset を活用する

低速なモバイル回線や標準的な1xディスプレイのユーザーに、倍サイズの重い画像を一律でダウンロードさせたくない場合はどうすればよいでしょうか。

HTMLには、密度記述子（1x, 2x, 3x）を持つ srcset 属性を使ったDPRごとの画像切り替え機能が標準で用意されています。

<img 
  src="/hero-800.webp" 
  srcset="/hero-800.webp 1x, 
          /hero-1600.webp 2x, 
          /hero-2400.webp 3x"
  width="800" 
  height="450" 
  alt="モダンなワークスペース環境"
  loading="lazy">

ブラウザの判断プロセス：

• 標準的な1080pオフィスPC（DPR 1.0）のユーザーは hero-800.webp（約45 KB）をダウンロード。
• MacBook Pro（DPR 2.0）のユーザーは hero-1600.webp（約120 KB）をダウンロード。
• iPhone 16 Pro（DPR 3.0）のユーザーは hero-2400.webp（約220 KB）をダウンロード。

各端末は物理的に表示可能な密度に最適な画像のみを取得するため、通信量を抑えつつ最高の鮮明さを自動的に両立できます。

---

4. srcset と sizes を組み合わせたフルードレスポンシブ画像（可変レイアウト向け）

レスポンシブなウェブサイトでは、画像の表示幅が固定されていることは稀です。カード型デザインの画像は、スマートフォンでは全幅（100%）を占め、デスクトップでは3カラムグリッドの1枠（33%）になることがあります。

画面幅によって画像の幅が変化する場合、密度記述子（1x, 2x）だけでは対応できません。そこで、幅記述子（w） と sizes 属性 を組み合わせて使用します。

<img 
  src="/article-cover-800.webp"
  srcset="/article-cover-400.webp 400w,
          /article-cover-800.webp 800w,
          /article-cover-1200.webp 1200w,
          /article-cover-1600.webp 1600w"
  sizes="(max-width: 640px) 100vw, 
         (max-width: 1024px) 50vw, 
         33vw"
  width="800"
  height="450"
  alt="画面解像度の理解"
  loading="lazy">

この仕組みが極めて効率的な理由：

ブラウザはレンダリングされるCSSスロットのサイズと、画面のデバイスピクセル比を掛け合わせて計算します。

• 390px幅のモバイル端末（DPR 3.0）の場合、画像は 100vw（$390\text{px}$）を占有します。ブラウザは次のように計算します。 $$390\text{px} \times 3.0 = 1,170\text{ 物理ピクセルが必要}$$ これに最も適した article-cover-1200.webp が自動選択されます。
• 1080pデスクトップでウィンドウ幅1280px（DPR 1.0）の場合、画像は 33vw（$422\text{px}$）を占有します。ブラウザの計算： $$422\text{px} \times 1.0 = 422\text{ 物理ピクセルが必要}$$ article-cover-400.webp（または800w）が効率的に選択されます。

JavaScriptによる複雑な処理は一切不要です。ブラウザが最初の1ピクセルを描画する前に、最適な画像を自動で計算・選定してくれます。

---

5. image-set() やメディアクエリを用いた高DPI CSS背景画像

CSSスタイルシート側で背景画像を指定する場合、標準のメディアクエリや最新の image-set() 関数を使えば、高密度向けのアセットをスマートに配信できます。

選択肢A：モダンな image-set()（推奨）

現在すべての主要モダンブラウザ（Chrome、Safari、Firefox、Edge）でサポートされています。

.hero-banner {
  background-image: image-set(
    url("/hero-bg.webp") 1x,
    url("/hero-bg@2x.webp") 2x
  );
  background-size: cover;
  background-position: center;
}

選択肢B：min-resolution を使ったCSSメディアクエリ

ブレークポイントと解像度密度を細かく制御したい場合：

/* 標準 1x 向け背景 */
.card-header {
  background-image: url("/card-bg.webp");
  background-size: 300px 180px;
}

/* 2x Retina 向け背景 */
@media (-webkit-min-device-pixel-ratio: 2), (min-resolution: 192dpi) {
  .card-header {
    background-image: url("/card-bg@2x.webp");
  }
}

なぜ 192dpi なのか？
CSSの標準基準解像度は 96 DPI（Dots Per Inch）と定義されています。2x画面ではその2倍になるため、$96 \times 2 = 192\text{dpi}$（またはピクセル単位あたりのドット数を表す 2dppx）となります。

---

見落としがちな落とし穴：高DPI画面における Canvas と WebGL

HTML5の <canvas> 要素を使ってグラフやインタラクティブな描画、ゲーム、電子署名パッドなどを開発している場合、DPRによるぼやけはさらに深刻な形で現れます。

デフォルトでは、HTML canvas はそのHTML属性の値のみに基づいて描画バッファを生成します。

<!-- デフォルトのcanvas: 300x150 の描画バッファを生成 -->
<canvas id="chart"></canvas>

このキャンバスをレイアウトに合わせてCSSで装飾したとします。

#chart {
  width: 300px;
  height: 150px;
}

MacBookや4Kモニターで表示すると、キャンバス内のテキストや描画線が驚くほどぼやけてしまいます。

なぜでしょうか？キャンバス内部で生成されたビットマップバッファがわずか 300 × 150 ピクセルしかなく、ブラウザがその小さなビットマップを 600 × 300 の物理ハードウェア領域に無理やり引き伸ばしているからです。

Retinaディスプレイ向けに HTML Canvas を鮮明にする正しい実装法：

これを解決するには、キャンバスのCSS表示サイズを固定したまま、内部の描画バッファサイズを window.devicePixelRatio 倍にスケーリングする必要があります。

const canvas = document.getElementById("chart");
const ctx = canvas.getContext("2d");

// CSSピクセル単位の目的レイアウトサイズ
const cssWidth = 300;
const cssHeight = 150;

// 現在の画面のピクセル密度を取得
const dpr = window.devicePixelRatio || 1;

// 1. 物理バッファサイズにDPRを掛けて設定
canvas.width = cssWidth * dpr;
canvas.height = cssHeight * dpr;

// 2. CSSピクセルを用いてページ上の視覚サイズを固定
canvas.style.width = `${cssWidth}px`;
canvas.style.height = `${cssHeight}px`;

// 3. 描画座標をCSS単位のまま扱えるよう全体をスケール
ctx.scale(dpr, dpr);

// あとは通常通り描画するだけで、極めてシャープにレンダリングされます！
ctx.fillStyle = "#2563eb";
ctx.fillRect(20, 20, 100, 50);

このシンプルなコードを追加するだけで、チャートライブラリやゲームエンジン、ベクター描画アプリがRetinaディスプレイ上でピクセルパーフェクトな鮮明さを発揮します。

---

パフォーマンス vs 鮮明さ：最適なバランスの見極め方

2xや3x画像の配信方法を理解したところで、重要な疑問が浮かびます。 「すべての最新スマートフォンに向けて、常に3x画像を配信すべきなのだろうか？」

ほぼすべてのケースにおいて、その答えは「No」です。

その理由は以下の通りです。

1. 人間の視覚における限界（収穫逓減）：
   スマートフォンを通常の距離（約25〜30cm）で見る場合、画素密度が約300〜350 PPIを超えると、人間の目では個々のピクセルを識別できなくなります。3xの画面で2xの画像を表示しても、99%のユーザーにとってネイティブの3x画像との違いを見分けることはできません。

2. ファイルサイズの爆発的な増加：
   画素面積は2乗（自乗）で増加します。

   • 1x 画像のデータ量を 1x とすると、
   • 2x 画像は 4倍（$2 \times 2$）のデータ量、
   • 3x 画像は実に 9倍（$3 \times 3$）のデータ量になります！

   大きな写真で律儀に3x画像を配信すると、適正な120 KBのWebP画像が800 KB以上の巨大ファイルに膨れ上がってしまいます。これはモバイル通信量を圧迫し、Core Web Vitals（特にLCP: Largest Contentful Paint）を悪化させ、ページの表示速度を大幅に低下させます。

2026年における推奨プラクティス：

• ベクターUI（ロゴ・アイコン）： 必ずSVGを使用する。ぼやけゼロでファイルサイズも極小です。
• 一般的な写真・ヒーローバナー： レスポンシブな srcset の上限を 2.0x に設定する。3xスマートフォンに2x画像を配信しても視覚的な鮮明さは95%保たれ、通信量を最大60%削減できます。
• 最新の圧縮技術： 高解像度画像は必ず WebP や AVIF で圧縮する。高DPI画面は画素が非常に密に詰まっているため、圧縮率を少し強め（品質設定75〜80程度）にしても視覚的な劣化はほとんど気になりません。

---

よくある質問（FAQ）

PPI、DPI、DPRの違いは何ですか？

• PPI（Pixels Per Inch）： 物理的なハードウェアの画素密度。ディスプレイの1インチあたりにいくつの発光素子が並んでいるかを示します。
• DPI（Dots Per Inch）： 本来は印刷分野の用語で、プリンターが1インチあたりに吹き付けるインクのドット数を指します。ウェブ制作ではPPIと同義で使われることがよくあります。
• DPR（Device Pixel Ratio）： ブラウザやOSが、論理的なレイアウト単位（CSSピクセル）を物理ハードウェアピクセルに変換する際に使用するソフトウェア上の倍率です。

4Kモニターなのに解像度が 1920 × 1080 と表示されるのはなぜですか？

4Kディスプレイ（3840 × 2160）を接続していて、WindowsやmacOSのディスプレイ設定で拡大率が 200% に設定されている場合、OSはウェブブラウザに対して「デスクトップの論理幅は 1920 × 1080、DPRは 2.0 である」と通知します。

モニターは依然として本物の4K解像度で表示されています。文字やウィンドウが細かすぎて読めなくならないよう、OSが4つの物理ピクセル（$2 \times 2$）を1つの論理ピクセルとして描画しているためです。

DPRは 1.25 や 1.5 のような小数になることがありますか？

はい、あります。WindowsやChromeOSでは、125%、150%、175%といったカスタム拡大率を設定できます。ユーザーがディスプレイのスケーリングを150%に設定している場合、ブラウザの window.devicePixelRatio は 1.5 になります。

ブラウザでズームインするとDPRは変わりますか？

はい、変化します。ウェブページ上で Ctrl + や Cmd + を押してズームインすると、現代のブラウザは虫眼鏡のようにページを引き伸ばすのではなく、window.devicePixelRatio の値を引き上げます。これによってレイアウトが再計算され、レスポンシブな srcset 属性が作動して、より鮮明な画像が読み込まれます。

---

まとめ：覚えておくべき重要ポイント

1. 2種類のピクセルが存在する： 物理ピクセルは画面上のハードウェア素子であり、CSSピクセルはブラウザがレイアウト構築に用いる設計単位です。
2. DPRは変換係数： DPRは、1つのCSSピクセルを描画するために何個の物理ハードウェアドットが使われているかを示します。
3. 画像がぼやける原因： 4個または9個の物理ドットで描画される領域に対して画像データが1ピクセル分しかない場合、ブラウザが補間して引き伸ばすためぼやけが発生します。
4. まずはSVGを検討する： ベクター化できる図形、アイコン、ロゴには常にSVGを使用します。
5. 写真は2xを目安にする： ビットマップ写真には srcset を用いて2xアセットを配信することで、ファイルサイズ肥大化を防ぎつつRetinaにふさわしい鮮明さを実現できます。

ご使用中の端末が現在どのような数値を返しているか確かめてみませんか？WhatIsMyScreenResolutions.com のトップページツールにアクセスすれば、ビューポートサイズ、画面解像度、デバイスピクセル比をリアルタイムに確認できます。