上記のプレビューが携帯電話の画面に読み込まれたとき、何かおかしなことに気づいた人はいますか？
なぜ画像がプレビューの四角全体を埋めるのに、あんなに苦痛なほど時間がかかったのでしょうか？
それは、画像が非常に大きいからです！
では、なぜ非常に大きな画像がユーザーのデータプランを食いつぶし、ほんの小さなプレビューならすぐに表示されるのに、時間がかかる必要があるのでしょうか？
いいえ、誰を責めるべきか正確にはわかりません。
いいえ。バグではありません。画像はいずれ表示されます。単に、ユーザーエクスペリエンスが悪いと言っているのです。ユーザーは、誰も自分のデータプランを気にかけていないと考え、ページが他のページほど速く読み込まれないと考えます。
読み込み時間はあまり気になりませんでした。ブラウザかネットワークの問題のようです。
初めて別のデバイスから試したとき：
これはChromeのiOS版でした。
待て、そんなに早くない。君は第一世界の国にある君の「象牙の塔」にいるので、違いなど決して分からないだろう。しかし、私の「象牙の塔」ではない、私の第一世界ではない国にいる私には、その違いが非常によく分かるのだ！
開発者ツールを使い、国を第二または第三世界に設定し、
キャッシュをオフにして、ページを再読み込みしてほしい。
あなたの苦情はISPとそのピアリングにあるということですか？
はっきりさせておきますが、元の画像は3.4MBで、そのサムネイルはCloudfrontから提供されており、690x460で164KBです。
いずれにしても、何を提案していますか？ Cloudfrontがあなたの地域のユーザーにとって悪いCDNであるということですか？ Discourseが最適化された画像を十分に速くダウンロードして作成できなかったということですか？
私が知っているのは、その寸法が携帯電話の画面全体よりも大きいということです！
私のスマートフォンは小さいです（4.6インチ | 720 x 1.280ピクセル）。私の画面はサムネイルより小さくありません。あなたの画面はどれくらい小さいですか？
データがアメリカの8分の1、ヨーロッパの2.5分の1という、あなたの非特権的な国でですか？ (source) それとも、世界最速のブロードバンドインターネットを持つ、あなたの非特権的な国でですか？ (source) それとも、モバイルデータでは依然として多くの先進国を大きく上回る28位にランクインしている、あなたの非特権的な国についてですか？ (source)
単に、もっと大きな電話が必要なだけのように聞こえますね。
過去の投稿から判断すると、JidanniさんはGalaxy A13 5GとZenfone 3をお持ちのようです。
Galaxy A13 5G: 6.5インチ、1600 x 720
Asus Zenfone 3: 5.5インチ、1920 x 1080
最適化されたサムネイルは690x460で、oneboxによってさらに制限されるため、画面よりも大きくはありません。ブラウザの拡大縮小機能も使用しているため、どうなるかはわかりません🤷🏻♂️
ここに何か怪しい点があるかもしれません。
デスクトップ表示では、onebox は 690x460px、160 KB の画像 を読み込みますが、モバイルでは 1380x920、500 KB の画像を読み込みます。
トピックを Bug に移動しました。私にはバグのように思えますが、後で再分類されるかもしれません 
間違っているかもしれませんが、理にかなっていると思います。
HTMLのsrcsetを見ると、以下の画像はデバイスピクセル比（x1、x1.5、x2）に基づいて提供されます。
https://...2f50d4ad9f5f865b783b02d392de75bdceec01da_2_690x460.jpeg,
https://...2f50d4ad9f5f865b783b02d392de75bdceec01da_2_1035x690.jpeg 1.5x,
https://...2f50d4ad9f5f865b783b02d392de75bdceec01da_2_1380x920.jpeg 2x
通常、モバイルはピクセル密度が高いため、x2（またはそれ以上）の比率になります。
したがって、より高解像度の画像を提供したいはずです。
デバイスピクセル比（DPR）は、デバイスメーカーによって与えられる数値であり、現代のスマートフォン、タブレット、さらには一部のラップトップやモニターに搭載されているHiDPI（高ドット密度）またはRetina（Appleの商標）ディスプレイに使用されます。
DPRはディスプレイのピクセル密度と直接相関しており、密度が高いほどDPRの値は大きくなります。DPRは、画面の水平（幅）または垂直（高さ）方向における物理（デバイス）ピクセルと論理（CSS）ピクセルの比率です。
言い換えれば、DPRは画面のCSS解像度を計算するために使用される数値です。DPRから、1つのCSSピクセルを形成するためにいくつの実際の物理ハードウェアピクセルが使用されているかを直接確認できます。例：
Apple iPhone 12
デバイス（物理）ピクセルでの解像度：1170 x 2532
DPR：3
幅：1170/3 = 390、高さ：2532/3 = 844
したがって、CSSピクセルでの解像度：390 x 844DPRが3であるため、ピクセルグリッドでは、3（幅）x 3（高さ）= 9。9つの物理ピクセルが1つのCSSピクセルを形成するために使用されます。
いいえ、これはバグではないと思います。私のiPadはモバイルビューでデスクトップよりも高解像度の写真を読み込みますが、それは可能なためです。間違っているかもしれませんが、画面サイズではなくデバイスの機能に依存すると理解していました。
また、このトピックがワンボックスサムネイル自体に関するものなのか、それともワンボックスリンクをクリックしたときに実際の写真が読み込まれることに関するものなのか、まだはっきりしていません。
よく気がつきました。
スマートフォンの画面サイズでは、解像度が低い画像に気づくことはないでしょう。また、一般的に、自宅のインターネット接続よりもモバイルネットワーク経由のインターネット接続の方が遅い傾向があると思います。この点に関して、デスクトップコンピューターよりも大きな画像を読み込むモバイルエクスペリエンスを期待すべきではありません。
しかし、scrset はピクセル比率ごとにどの画像を読み込むかを決定します。
これは間違いなくバグではありません。UX に戻します 
サムネイルです。
確かに、ここではKiwiブラウザの開発者ツールで結果が表示されています。
はい、500キロバイトのサムネイルについて話しています。
ティム・バーナーズ＝リーならどう思うでしょうか？
さて、ウェブ検索をしたところ、YouTubeにアップロードする場合であれば、サムネイルとしては妥当なサイズであることがわかりました。
それは、かなり素晴らしいホログラムか、50次元のサムネイルか、何かでなければならないはずです。5000バイト程度で同じことはできないのでしょうか？ユーザーは違いを検出できるでしょうか？エネルギー危機やウェブの遅延のせいにしているわけではありません。ただ、最終的な目的地が小さな携帯電話であることを考えると、もっと改善できる点があるのではないかと思います。
人間が、どんなに小さな携帯電話サイズのデバイスであっても、より多くのバイトを追加しても違いがわからないという点があるはずです。彼らはワシではなく人間なのですから。
確かに、何かがおかしいですね。その画像は大きすぎます。私たちのワンボックス実装では、もっと小さい画像で十分な場合に、非常に大きな画像を要求しています。
今後1か月ほどで確認します。
このPRは、Wikimediaリンクに特化したoneboxサムネイルサイズのバグを修正するためにマージされました。
テスト用のWikimediaリンクはこちらです。
すべてのoneboxサムネイルサイズに適用できる、より一般的な修正はまだ開発が必要です。
すべてのワンボックスに対する、より一般的な修正が作成されました。
テストには、この非ウィキメディアサイトの記事を使用しました: https://www.hagerty.com/media/category/great-reads/。これらのサイトには、ワンボックス化するのに十分な大きさの画像がありました。
変更前：
変更後：
この変更前は、ワンボックスの画像は約400KBでした。私の変更後は、約100KBになります。
こちらは、縮小されたサムネイルサイズを使用しているワンボックスの例です。
このトピックは41時間後に自動的に閉じられました。返信はもうできません。
