4K画像と最適化800px WebP:パフォーマンスと品質のトレードオフ

マルテペの18席タバレストランには明確な問題があった:客がQRをスキャンしてもメニュー画面が5-6秒間真っ白だった。原因はDSLR撮影の4K JPEGで、商品カード1枚あたり4-6 MB。解決策は4Kを捨てることではなく、正しいサイズで配信すること。

Core Web Vitals:LCPの赤線

GoogleのLargest Contentful Paint (LCP)閾値は2.5秒。4Kで読み込むメニューカードは4.2-6.1秒——「Poor」カテゴリ。800px WebPに切り替えると同じカードは1.2-1.8秒に下がり、「Good」圏内に収まる。

LCPはSEOランキングに直接影響する。モバイル検索上位3位の店舗は平均LCPが1.9秒未満;4秒超のサイトは2-3ページ目に落ちる。

なぜ800px WebPで十分か

最新スマホ(iPhone 14、Galaxy S23)のCSS幅は390-430px。Retina ×2 = 最大860px。800px WebPは既に物理上限。4Kの残り3,200ピクセルは見える画素に対応しない。

同画質でWebPはJPEGより25-35%軽い。800px WebP(180 KB)対4K JPEG(5.2 MB)=96.5%の帯域節約。

thMenuレスポンシブ画像パイプライン

4K原本をアップロードするとthMenuが自動的に320px、640px、800px、1200pxのWebP+AVIF派生を生成。ブラウザはsrcsetで最適サイズを選択。

Lazy loadingはデフォルト有効。First Contentful Paint 600ms未満;残りはスクロール時に読み込み。

よくある質問

4K原本は削除すべき?いいえ。thMenuはR2に原本を保管し、将来の8Kディスプレイに対応します。

AVIFはどれくらい軽い?同画質でJPEGより50%、WebPより20%軽い。94%のブラウザがサポート。

写真品質は劣化する?いいえ。800pxのモバイル画面では4Kと区別がつかない——肉眼は手持ちで300 PPI超を識別できません。

お役に立ちましたか?シェアしてください。