レスポンシブ問題 CSSピクセルとデバイスピクセル DPR(Device Pixel Ratio)

Web / HTMLのレスポンシブコードとWordPress

WordPressの「メディアを追加」で自動的にレスポンシブになる
4K対応サイズの画像(横幅1200px以上)をアップロードすればWordPressレスポンシブは4Kレスポンシブになる
(正確には 4Kレスポンシブイメージになる)

よってWordPressの画像コンテンツでレスポンシブとは、テーマもプラグインもユーザーのレスポンシブHTMLコーディングも関係はなし!

ただし、(画像伸縮)レスポンシブではなく、(画像選択)レスポンシブイメージにするためには、「メディアを追加」で挿入された画像コードのwidthとheight、classの画像ID(wp-image-123など)を削除しないこと

<img src="~.png" alt="ほげほげ" width="1280" height="1280" class="alignnone size-full wp-image-123">

今どきのモダンブラウザーは、記述されたwidthとheightからアスペクト比を計算して、レスポンシブ表示させるとのこと
widthとheightが無いとPageSpeed Insightsで警告される
複数サイズを生成した画像をWordPressでレスポンシブイメージ化するには画像IDのメタデータが必要

画像IDなどのclass記述は余計なもの、widthとheightはレスポンシブの邪魔、そう思っていたあの頃…

じつはWordPressレスポンシブイメージはテーマ次第

テーマというよりもテーマのfunctions.phpのコーディング次第、およびWordPressのメディア設定次第

4Kレスポンシブイメージのソース例

<img src="画像ファイル.png" alt="~" class="wp-image-123"
srcset="画像ファイル.png 1280w,
画像ファイル-960x960.png 960w,
画像ファイル-640x640.png 640w,
画像ファイル-480x480.png 480w"
画像ファイル-320x320.png 320w,
sizes="(max-width: 1280px) 100vw, 1280px" width="1280" height="1280">

ということは、上記画像ファイルが生成されるような functions.php のコーディングが必要

CSSピクセルとデバイスピクセル

さて「640w」「1280w」は、ウインドウ幅なのか、デバイス画面幅なのか
はたまた、ビューボート幅までからんでくるし、その「幅」とはCSSピクセルなのかデバイスピクセルなのか

Chromeなどのデベロッパーツールのモバイル表示で、デバイスのピクセル「DPR」とは「Device Pixel Ratio / デバイスピクセル比」、簡単にはスマートフォンの画面は「375px」が多いが、スマートフォンに最適なキレイな画像は、DPR2なら375×2=750px、DPR3ならx3の1125pxとなる

DPR 1 2 3の概念図

Appleが切り開いた小画面で大解像度(Retina)のスマートフォン
SNS各社が投稿画像は1200px以上と叫ぶのは、これ(375画面DPR3)が理由だろう

レスポンシブで何が問題なのか?

Webページの意図した画像を意図した場所に意図したサイズ(幅と高さ)で表示するのは当たり前
問題はブラウザーで読み込まれ表示される画像がどのサイズなのか、ということである

横幅「375px」を想定したページの箇所では、2K(DPR1)ディスプレイでは「375px」の画像ファイル、DPR2のデバイス(ディスプレイ)では「750px」の画像ファイル、DPR3のデバイス(ディスプレイ)では「1125px」の画像ファイルが読み込まれ表示されることが望ましい
どのデバイスでも「1125px」の画像ファイルが読み込まれ表示されてかまわないのであれば、無問題で悩みも苦労もない
(巷のレスポンシブは、同一サイズの画像の伸び縮みで表示されることを意味している)

PageSpeed Insightsで「 適切なサイズの画像」の警告が出ることがある

この適切なサイズの画像とは「375px画面」では、2K(DPR1)デバイスでは「375px程度」、DPR2のデバイスでは「750px程度」、DPR3のデバイスでは「1125px程度」の画像ファイルを読み込ませ表示させなさい、ということである

最適な画像サイズ(レスポンシブ ブレークポイントのサイズを含む)が使用されるようにします。「Full Size」の画像は、十分なスペースがある場合を除いて使用しないようにします。

この文言からサイズとは、ファイル容量(例:117.0 KiB)ではなくて、幅x高さのサイズのことと想定できる

Google PageSpeed Insights:Moto G4 360px DPR 3

そしてGoogleのPageSpeed Insightsも、モバイルチェックしているデバイスのベースは何か?
レンダリングエンジンはChromeのBlink?
画面幅のCSSピクセルとデバイスピクセル、DPRは?

Google検索 生成AIから

Moto G4 の DPR は 3 です。DPR は「デバイスピクセル比」の略で、画像サイズを計算するために使用されます。
Moto G4 の画面幅は 360 ピクセルです。
Google Chrome の開発者ツールを使用して、Moto G4 をシミュレートできます。

Moto G4 に搭載されているレンダリングエンジンは、HTMLレンダリングエンジンです。

HTMLレンダリングエンジンには、次のようなものがあります。
KHTML、WebKit、Blink、Gecko、Servo、Trident、EdgeHTML、Presto。

ちなみに、Chromeのデベロッパーツール、モバイル エミュレート対象のデバイスの中に「Moto G4」があるので、これを有効化して随時スマートフォン画面の確認に利用するべきかもしれない

⌘ 弊社ではMoto G4をエミュレート対象デバイスのデフォルトにしている
360 x 640 / DPR 3
ユーザーエージェント:Mozilla/5.0 (Linux; Android 6.0.1; Moto G (4) Build/MPJ24.139-23.4; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/77.0.3865.92 Mobile Safari/537.36 [FB_IAB/FB4A;FBAV/286.0.0.48.112;]

繰り返すが、PageSpeed Insightsで「 適切なサイズの画像」が表示されることもあり、適切でないとは横幅が大きすぎるか小さすぎる場合である

アスペクト比 1:1 の画像
アスペクト比 4:3 の画像
アスペクト比 16:9 の画像
アスペクト比 1:1 の画像
アスペクト比 4:3 の画像
アスペクト比 16:9 の画像

想定とは違うレスポンシブ画像表示

上記の画像並べのsrcsetの中のコードは次のとおり

画像ファイル名.png 1280w,
画像ファイル名-960x#.png 960w,
画像ファイル名-640x#.png 640w,
画像ファイル名-480x#.png 480w,
画像ファイル名-320x#.png 320w,

これ以外にも記述はあるが、このような羅列の中からブラウザーが最適な1つを選び他を無視切り捨てて、表示する仕組み

不思議な現象として、これらの画像はデスクトップ1366で開くと「画像ファイル名-480x#.png.webp」が表示されている!
ブラウザー幅は1366なのに…
理論的には一番上の「画像ファイル名.png 1280w」1280x#が読み込まれ表示されるはずなのだが

画像480が表示されるということは、画像を囲むboxが 1/3 の幅(1366÷3=455…)だから? ウインドウ幅ではなく画像表示枠が計算対象なのだろうか?
また、6個目の画像は「画像ファイル名-640x#.png.web」が表示されている

aspect-ratio: 1 / 1;
width: 100%;
height: 100%;
object-fit: cover;
border-radius: 999.9rem;

上記のCSSのどれか、とくにaspectが怪しい…

DPR3のスマートフォン縦画面では、もちろん「画像ファイル名.png.webp 1280w」が表示されている
そしてスマホ横画面では2列なので「画像ファイル名-960x#.png.webp 960w」の表示となっている

レスポンシブイメージは”デバイスピクセル幅”で表示される

物理的なスマートフォンの狭い小さい画面とデスクトップの広い大きい画面
デスクトップで大サイズの画像を、スマートフォンで小サイズの画像をうまく切り替えて表示させることがレスポンシブと勘違いしていないだろうか?

1~2年前までは、私もそう思っていた

そして2Kデスクトップよりも、4K・DPR3以上のスマートフォンのほうが、より大きいな(横幅が広い)画像が必要と、思い知らされる

まずレスポンシブは、”デバイスピクセル”がベースということであり、2K(DPR1)で500pxならDPR2で1000px、DPR3なら1500pxが表示されるべきということ

ビューポート幅/デバイス画面幅/ウインドウ幅

レスポンシブコードやメディアクエリは、デバイスピクセルがベース

スマートフォンの縦画面は、「ビューポート幅=デバイス画面幅=ブラウザー ウインドウ幅」になっているので、あまり悩まない
よってレスポンシブコードやメディアクエリはそのまま適用されても無問題と思える

「ビューポート幅=デバイス画面幅=ブラウザー ウインドウ幅」がベースなら、デスクトップは、複数サイズのディスプレイ画面があり、ユーザーが好みの幅でブラウザーを使っている
しかも閲覧サイトによってはサイドバーがあったり、コンテンツが2列3列で表示されたり、かえって画像が狭く小さく表示される(目視)ことも多い

画像は、CSSで次のよう設定している

img { max-width: 100%; height: auto; }
画像囲みbox { width: 100%; }

勘違い(同一サイズ伸縮)レスポンシブでも、読み込まれる画像サイズ(width)が大きくても小さくても、その箇所に画像は最適に(目視では)表示される

デスクトップ内レスポンシブ

さて、このページを2Kデスクトップ1920px全画面表示させると、上の画像並びは3列なので1画像の幅は640pxが表示される
ビューポート幅/デバイス画面幅/ウインドウ幅に合わせ手表示されるなら、幅1280pxの元画像が表示されるはず
ところが、表示画像は画像枠(box)のデバイスピクセルが対象となっている!

上記画像並べと他の画像ありページと比較検討したところ、もし画像を囲むboxなどの幅をブラウザーが理解できれば、その枠に合わせて表示されるようだ

念を押しておくが、「表示」とは画像の表示/非表示ではなく、最適なサイズ(横幅)の画像ファイルが呼び出されているかどうか、ということである

ともかく、ブラウザーは「画像ファイル名-640x#.png 640w」なら、ウインドウ幅640までということではなく、画像囲み枠幅640までなら「画像ファイル名-640x#.png」を呼び出し表示するということになる

⌘ いろいろ検証した結果、WordPressでプラグインEWWW Image Optimizerを導入している場合だけのインフラに依存する特別な現象という可能性がある

ウインドウ幅ではなく囲み枠幅のレスポンシブイメージ

下記は囲み枠の幅に合わせて相応するサイズの画像が読み込まれ表示される検証
デスクトップでは、ウインドウ幅の伸縮によって囲み枠も伸縮し、画像もその都度サイズの違う画像が読み込まれ表示される

ついでに最後のスクリーンショット、iPhoneではSafariでも他のブラウザーでも、aspectサークルが意図したとおりに表示されない…
デベロッパーツールでは正常に表示されるから厄介、凝ったことをやれば実機確認が必須ということ

アスペクト比 1:1 の画像
アスペクト比 4:3 の画像
アスペクト比 16:9 の画像
アスペクト比 4:3 の画像
アスペクト比 16:9 の画像
アスペクト比 16:9 の画像
iPhoneでaspectサークルの不具合

囲み枠幅(ボックスサイズ)のレスポンシブイメージ:エビデンス

上記の画像群はgrid横並べで
(1)スマホ1列・タブレット2列・デスクトップ3列
(2)スマホ1列・タブレット2列・デスクトップ2列
(3)スマホ1列・タブレット1列・デスクトップ1列
(4)スマホ1列・タブレット2列・デスクトップ3列(ただしコンテンツは1個)
こういったレイアウトではgridは神である

それぞれ、表示される画像のサイズが違っているし、(4)もウインドウ幅ではなく画像囲み枠幅でレスポンシブ表示、つまりその幅に応じた幅の画像が呼び出され読み込まれている

またサイドバー内の画像も、やはり囲み枠幅(ボックスサイズ)のレスポンシブとなっている
(picture/source srcsetでコーディング、WordPressまかせではないのだが…)

ウインドウ/ビューポート・レスポンシブイメージではなく、囲み枠幅 ボックスサイズ・レスポンシブイメージ と称すべきだろうか…
もちろん、幅やサイズとはCSSピクセルではなくデバイスピクセルである

とここまで書いてきたけど、どうやら Firefox だけかもしれない…

Windows の Chrome では必ずしも「ボックスサイズ・レスポンシブ」になっていない、キャッシュの関係で表示させるたびにバラバラである
ただし、「ビューポート・レスポンシブ」にはなっているので、同一サイズ伸縮のレスポンシブ画像ではないので、デスクトップでのレスポンシブイメージ化はそれなりに成功している、取り組む甲斐があったと言えるだろう

 

モバイルファーストとデスクトップインディ

今回のWordPress新テーマでは、モバイルファーストや4K(Retina)レスポンシブイメージとスマホアプリ模倣のアーカイブ表示スタイルがメインで、デスクトップはある程度切り離して、gridレイアウトによってサイドバーなどを加えた12パターンのレイアウトを実現している

以降のバージョンアップで、デスクトップ表示は切り離して独立させる予定
独立はインディペンデンス、「デスクトップインディ」というコンセプトで、全デバイス完全対応を実現したい

画像多め、テキスト少なめ、デザイン重視、今どきこれからのWebのお役に立てればと思う

また、そういう条件でも、デバイス間レスポンシブだけでなく、デスクトップ内レスポンシブを実現し、Web Vitalsを損なわない、ビジュアルSEOが目標である

 

スマートフォンの画面解像度と画像作成のサイズ

Google検索 生成AIから

2022年11月時点で、画面解像度のシェア率が高いのは 390×844px のサイズです。
iPhone12・13・14のサイズが 390×844 となっており、Apple社の機種が約58%を占めています

Androidのスマートフォンは画面サイズが一定ではないため、「横幅400」と考えられます。
そのため、最適なWebデザインのサイズは「横幅375px」または「横幅400px」と言えるでしょう。
日本はiPhoneのシェアが高いため、「横幅375px」で作成するといいでしょう。

画像作成はDPR3対応で1200px以上

Androidも射程に入れて、DPR3も想定して、画像は 1200px以上で作成するべきかな

 

code用フォント Source Han Code JP

ちょっと道草
WordPressではcode表示のプラグインもたくさんあるけど、できるだけプラグインは入れたくない
そこでネットで調べてクールなコード表示フォントを発見

コーディングに最適な日本語対応の等幅フォントSource Han Code JPとは – ICS MEDIA

みなさんも、このフォントをインストールして、codeエディタなどのデフォルトフォントに設定してみてはどうでしょう

 

ブラウザー閲覧用フォント BIZ UDゴシック / 明朝

Webページで見やすいフォントとして、かなりバズっているというか、賞賛されているフォント、BIZ UDゴシック / 明朝

あのモリサワのフォントが、無料で配付されている

Google Fonts

P はプロポーショナルフォント

BIZ UDPGothic

BIZ UDGothic

BIZ UDPMincho

BIZ UDMincho

MORISAWA BIZ+ モリサワ本家

Google配付のフォントは、バージョンが低いような…
そこでモリサワ本家

全3書体MORISAWA BIZ+ 無償版

モリサワ本家では最新バージョンが配布されているが、無償でゲットするにあたって会員登録しなければならない
また、Windows版はインストーラーからフォントをシステムに組み込むが、同一フォントがある場合、システムフォントで使われている場合、上書きや削除もできない
ということで、自己責任で導入を

ブラウザーとWebのフォント

まず、パソコンにインストールして、ブラウザーのフォントに設定
やや太くて丸みをおびた字体なので、かなり見やすく感じる

もし気に入ったなら、Webサイトの font-family にも、BIZ UDGothic を記述

当サイト(新テーマ)も、日本語フォントに一番目に設定している

 

おすすめ