画像表示が遅い既存サービスを軽くする方法

「商品一覧ページを開くたびにグルグル回る」「スマホだとスクロールするたびに画像がガクガク出てくる」「PageSpeed Insightsのスコアがずっと赤い」——画像を多く扱うサービスで、こうした相談を私たちはよく受けます。担当のエンジニアに聞くと「画像が多いので仕方ない」という説明が返ってくることも多いのですが、実際に調べてみると、仕方なくはなく明確な原因があって、対処法も定石が確立しているというケースがほとんどです。

画像表示の遅さは、離脱率に直結する分かりやすい問題です。ユーザーは表示が遅いページを数秒で見限りますし、Googleの検索順位にも画像の読み込み速度を含むCore Web Vitalsが影響します。この記事では、画像が原因で重くなっている既存サービスについて、原因の切り分け方から具体的な改善策、コストと効果の目安、外注する際の進め方までを整理します。

まず「本当に画像が原因か」を確認する

「サイトが重い」という体感には複数の原因がありえます。改善に着手する前に、ブラウザの開発者ツールの「ネットワーク」タブでページ読み込み全体の内訳を確認します。

• 転送量(トランスファーサイズ)の上位を占めているのが画像ファイルかどうか
• 画像1枚あたりのファイルサイズが数百KB〜数MBになっていないか(適切に最適化されていれば、表示サイズにもよりますが多くの場合数十〜数百KB程度に収まります)
• 画像の読み込みがJSやCSSの読み込みをブロックし、ページ全体の表示開始(First Contentful Paint)を遅らせていないか

ここで画像が転送量の大半を占めていれば、画像配信の改善が最も費用対効果の高い打ち手になります。逆にAPIレスポンスの遅延やJSバンドルの肥大化が主因であれば、既存プロダクト改善の最初の確認観点やAPIレスポンス改善の進め方で扱っている観点のほうが優先度が高い場合もあります。

典型的な原因

私たちが改善案件で実際に遭遇する原因は、パターン化するとおおむね次の4つに集約されます。

1. 巨大な画像をそのまま配信している

スマホの画面幅は数百pxしかないのに、一眼レフやスマホカメラで撮影した4000px級の画像をそのまま表示用に使っている、というケースは非常に多く見られます。ブラウザ側でCSSやHTMLのサイズ指定で縮小表示していても、ダウンロードされる実データは元のサイズのままなので、通信量も表示までの時間もまったく削減されません。管理画面から画像をアップロードするだけで、リサイズ処理が一切挟まっていない設計のプロダクトでよく起きます。

2. CDNを経由していない

画像がアプリケーションサーバー(オリジン)から直接配信されている場合、ユーザーの物理的な距離やサーバーの負荷状況によって配信速度が大きく左右されます。CDN(Content Delivery Network)を挟めば、ユーザーに地理的に近いエッジサーバーからキャッシュ済みの画像が配信されるため、初回以降のアクセスは大幅に高速化されます。特に画像点数の多いECサイトやメディアサイトで、CDN未導入のまま運用されているケースは珍しくありません。

3. 遅延読み込み(Lazy Loading)がない

一覧ページや長いLPで、画面外にある画像まで最初から全部読み込んでいると、ユーザーが実際に見る前の段階で不要な通信が大量に発生します。画面に入ってくるタイミングで画像を読み込む遅延読み込みを入れるだけで、初期表示に必要な転送量を大きく減らせます。

4. 古い画像フォーマットのまま配信している

JPEGやPNGは長く使われてきたフォーマットですが、同じ見た目の画質でもWebPやAVIFはファイルサイズを大幅に(目安として数十%程度)削減できます。ブラウザの対応状況もすでに広く行き渡っており、新しいフォーマットへの切り替えは費用対効果が高い割に見落とされがちな改善点です。

改善の打ち手

原因が特定できたら、影響が大きく・リスクが低いものから順に着手します。

リサイズパイプラインの導入

アップロード時、あるいは配信時に、用途ごとに必要なサイズへ自動でリサイズする仕組みを入れます。RailsであればActive Storageのバリアント機能やimage_processing(libvips/ImageMagick)を使い、サムネイル・一覧用・詳細用など表示箇所ごとに複数サイズを生成しておくのが定石です。既存のアップロード機能に後付けする形でも導入できるため、リプレイスを伴わずに着手できる改善です。

WebP/AVIFへの変換

サーバー側で自動的に次世代フォーマットへ変換し、ブラウザの対応状況に応じて出し分けます。HTMLの<picture>要素で<source type="image/webp">を指定しつつ、非対応ブラウザ向けに元フォーマットもフォールバックとして残す構成が一般的です。CDNのオンザフライ画像変換機能(後述)を使えば、アプリケーション側の実装を最小限に抑えられます。

CDNの導入

CloudFront・Cloudflare・Fastlyなどの画像配信CDNを導入します。単なるキャッシュだけでなく、多くのCDNはURLパラメータでリサイズ・フォーマット変換をオンザフライで行う機能を持っており、これを使えばアプリケーション側でリサイズ処理を実装しなくても、配信時に自動で最適なサイズ・フォーマットに変換してくれます。既存のS3等のストレージ構成を大きく変えずに導入できるのも利点です。

遅延読み込みとレスポンシブ画像

loading="lazy"属性はモダンブラウザで標準サポートされており、追加のJSライブラリなしで遅延読み込みを実装できます。加えて、srcset属性で画面幅・解像度ごとに複数サイズの画像を用意しておけば、ブラウザが最適なサイズを自動選択して読み込みます。スマホでPC用の大きな画像をダウンロードさせてしまう、という無駄を防げます。

これらの打ち手は互いに独立しているため、一気に全部やり直す必要はなく、段階的に導入できます。まずCDN導入とリサイズだけでも体感速度は大きく改善し、その後フォーマット変換やsrcset対応を追加していく進め方が、既存サービスを止めずに改善する現実的なアプローチです。

コストと効果の目安

画像配信の改善は、他の改善施策と比べて投資対効果が見えやすい領域です。

• CDN導入とリサイズ・フォーマット最適化だけで、画像を多く含むページの転送量が数分の1になることも珍しくなく、体感速度の改善はユーザーやクライアントにも伝わりやすい
• CDNの利用料自体は転送量に応じた従量課金が中心で、多くのケースでオリジンサーバーの負荷軽減分と相殺され、コスト増が最小限に収まることが多い
• Core Web VitalsのLCP(Largest Contentful Paint、多くの場合ページ内で最大の画像がこの指標に影響します)が改善されることで、SEO評価にも好影響が期待できる

一方で、既存のアップロード・表示ロジックが密結合になっているプロダクトでは、リサイズパイプラインの差し込み方によって改修範囲が変わります。「どこまで自動化するか」「オンザフライ変換に寄せるか、事前生成に寄せるか」の設計判断が、コストと保守性を左右する分岐点です。

外注する場合に確認すべきこと

画像配信のパフォーマンス改善を外部チームに依頼する際は、次の点を確認しておくと安心です。

• 原因の計測から始めるか: 「とりあえずCDNを入れましょう」ではなく、ネットワークタブや計測ツールで転送量・表示速度のボトルネックを具体的に特定した上で提案してくるか
• 段階的に導入できる設計か: 既存のアップロード・配信の仕組みを止めずに、CDN導入→リサイズ→フォーマット変換と順に進められる計画になっているか
• 改善前後の数値を提示するか: 「軽くなった気がする」ではなく、転送量・LCP・PageSpeedのスコアなど、改善前後を数値で比較して報告してくれるか

技術スタックの詳細は技術ページに、進め方全体はモダナイゼーション支援サービスにまとめています。

まとめ

• 画像表示の遅さは「巨大画像のそのまま配信・CDN未導入・遅延読込なし・古いフォーマット」の4パターンに原因が集約されることが多く、まずネットワークタブで転送量の内訳を確認するところから始める
• 打ち手はリサイズパイプライン・WebP/AVIF変換・CDN導入・遅延読み込みとレスポンシブ画像で、それぞれ独立しているため段階的に導入できる
• 他の改善領域と比べて投資対効果が見えやすく、コストを転送量削減分と相殺しやすい一方、既存実装との結合度によって改修範囲の設計が分岐点になる

「画像が多いページが重い」というのは体感で終わらせず、数値で原因を特定すれば着実に改善できる領域です。torcheeesでは既存プロダクト改善の診断と、継続的な改善支援を提供しています。まずはお問い合わせフォームから現状を聞かせてください。