この記事の対象: 旅行・観光・宿泊サイトの制作担当者、および自社サイトの表示速度に悩む観光事業者
読了時間: 約9分
旅行サイトほど「画像が重くて当たり前」と諦められているジャンルは、他にありません。客室、露天風呂、朝食、周辺の景色、季節ごとの表情。売り物が体験である以上、写真を削るという選択肢は事実上ありません。だから、多くの旅行サイトは重いままです。
ですが、実際に計測してみると、旅行サイトの遅さの原因は「画像が多いこと」そのものではありません。多いことを前提にした設計になっていないことです。同じ100枚でも、設計次第で初回表示に効くのは3枚に絞れます。
この記事では、AVIFやWebPといった一般的な軽量化の話はしません。それは別記事で扱っています。ここで扱うのは、旅行サイト特有の構造——ヒーロースライダー、客室ギャラリー、プラン一覧のサムネイル、季節替えのビジュアル——を、どう設計すれば重さが問題にならなくなるかという話です。
旅行サイトの画像が重くなる4つの構造
一般的なコーポレートサイトと旅行サイトでは、画像の「効き方」がまったく違います。まずそこを整理します。
1. ファーストビューがほぼ全面写真
旅行サイトのトップは、画面いっぱいの風景写真から始まるのが定石です。これは正しい判断です。宿やエリアの世界観は、テキストでは一秒では伝わりません。
問題は、その一枚がLCP（Largest Contentful Paint）そのものになることです。他のジャンルなら見出しテキストがLCP要素になることも多く、画像が多少遅れても数字は動きません。旅行サイトでは、ヒーロー画像の読み込み完了＝ページが表示された瞬間になります。逃げ道がない。
さらに厄介なのが、ここをスライダーにしているケースです。3枚組、5枚組のスライダーを組むと、初期表示で全部読み込む実装になっていることが少なくありません。1枚で済むはずのLCPが、5枚待ちになります。
2. ギャラリーページの枚数が桁違い
客室タイプが複数、それぞれ数枚ずつ。加えて館内、料理、周辺観光。ギャラリーページだけで60枚、80枚というのは旅行サイトでは珍しくありません。
しかもこれらは「ユーザーが見たがっている」画像なので、削減の対象にできません。見せることが目的のページで、見せる量を減らすのは本末転倒です。
3. 更新が現場で行われる
ここが旅行サイト最大の落とし穴です。宿泊施設のサイトは、制作会社が納品したあと、現場のスタッフが更新します。季節の料理、雪景色、リニューアルした客室。
そのとき、スマートフォンやデジタルカメラで撮った数千px級の高解像度写真がそのまま入る。制作時にどれだけ丁寧に最適化しても、公開半年後には数MBの画像が並んでいる、という現象は非常によく起きます。
技術的な最適化と同じくらい、運用で壊れない仕組みが要ります。
4. 予約エンジンや外部パーツが同時に走る
旅行サイトは自前だけで完結しません。予約システムのウィジェット、地図、口コミの埋め込み、SNSフィード。これらが画像と帯域を奪い合います。画像だけを見ていると、原因を見誤ります。
初回表示（LCP）
- ヒーロー画像
- スライダーの2枚目以降
ページ全体の重量
- ギャラリーの大量画像
- 現場更新で入った未圧縮画像
帯域の奪い合い
- 予約エンジン・地図・SNS
効く打ち手が層ごとに違うので、ひとまとめに「画像最適化」と言わない。
この4層のうち、初回表示に効くのは最上段だけです。ギャラリーの60枚を必死に圧縮しても、トップページのLCPは1ミリも改善しません。どこを触るかを最初に決めることが、旅行サイトの画像最適化の第一歩になります。
旅行・観光サイトの実装から読み取れる共通パターン
旅行・宿泊・観光カテゴリのサイトを開き、実際の表示の挙動を追うと、「速いサイト」に共通する設計パターンが見えてきます。ここでは表示が速い実装に共通して見られる工夫を、制作者目線と発注者目線の両方から整理します。
共通点1：ヒーローは一枚勝負
【制作者目線】
表示が速い旅行サイトは、ファーストビューのスライダーを「見た目はスライダー、読み込みは一枚」として組んでいます。具体的には、1枚目だけ fetchpriority="high" を付けて優先読み込みし、2枚目以降は遅延させる。スライド切り替えが始まるのは、ユーザーが数秒滞在してからなので、初回表示に間に合わせる必要がありません。
さらに一歩進んだ実装では、そもそもファーストビューをスライダーにせず、一枚の強い写真＋短いコピーで構成しています。技術的に速いだけでなく、「何の宿なのか」が一秒で伝わる点でも優れています。
【発注者目線】
「トップで5枚見せたい」という要望は、ほぼ必ず出ます。気持ちはわかります。客室も料理も温泉も見せたい。
しかし、スライダーの2枚目以降を最後まで見るユーザーは多くありません。多くの訪問者は数秒で次の行動に移ります。5枚見せるコストを払って、実際に届くのは1枚目だけという構造になりがちです。
それなら、一番強い一枚に絞って、残りの4枚はその下のセクションで見せたほうが確実です。写真を減らすのではなく、置き場所を変える。発注時に「トップの主役写真を一枚決めてください」と言われたら、それは手抜きではなく設計判断だと理解してください。
共通点2：ギャラリーは「見えたら読む」
【制作者目線】
ギャラリーページを開いて、開発者ツールのネットワークタブを見ると実装の差がはっきりします。良い実装は、最初のスクロール位置に入っている数枚しかリクエストが飛びません。スクロールに応じて追加で読み込まれていく。
ポイントは3つです。
| 実装項目 | やること | 効果 |
|---|---|---|
loading="lazy" |
ファーストビュー外の全画像に付ける | 初回リクエスト数が激減 |
width / height 指定 |
全画像に必ず入れる | レイアウトのガタつき（CLS）を防ぐ |
| サムネイルと拡大画像を分ける | 一覧は小さい画像、クリックで大きい画像 | 一覧ページの重量が数分の一に |
3つ目が旅行サイトでは特に効きます。ギャラリー一覧に高解像度の原寸画像を並べて、CSSで縮小しているだけ、という実装がよく見られます。見た目は同じですが、通信量は何倍も違います。
【発注者目線】
「ギャラリーを見た人ほど予約につながりやすい」——これは多くの宿泊施設で実感されている傾向です。だからこそギャラリーページは重要で、だからこそ途中で離脱されると損失が大きい。
見積もりを取るとき、「ギャラリーページの実装」が一行いくらで書かれていたら、サムネイルと拡大画像を分ける設計になっているかを確認してください。ここが分かれているかどうかで、同じ見た目でも体感速度がまったく変わります。
共通点3：季節替えを想定した作り
【制作者目線】
旅行サイトは年に数回、ビジュアルが入れ替わります。この入れ替えを「画像ファイルを差し替えるだけ」で済ませられる設計かどうかが、長期的な速度を決めます。
CMSの管理画面から画像をアップロードした時点で、自動的にリサイズ・フォーマット変換されて複数サイズが生成される。この仕組みがあれば、現場が高解像度の写真を入れても壊れません。WordPressなら標準のサムネイル生成に加えて add_image_size() で必要なサイズを定義し、srcset で出し分けます。
【発注者目線】
ここは発注時に必ず確認すべき項目です。質問の形はこうです。
「更新のときに、こちらで画像サイズを調整する必要はありますか？」
「1200px以下にリサイズしてからアップしてください」という答えなら、半年後に必ず守られなくなります。悪気なく、忙しい現場で、そのまま上がります。
「そのまま上げてもらって大丈夫です」という答えが返ってくる設計にしておくこと。これが旅行サイトの画像最適化で、もっとも長持ちする投資です。
発注前に決めておくと揉めない3つのこと
制作会社に依頼する前に、発注側で決めておくと進行が速くなる項目があります。
1. 主役写真を1枚決める
トップページのファーストビューに使う一枚。これを発注前に決めておくと、デザインの初回提案から的を射たものが出てきます。決まっていないと「候補を並べて選ぶ」ラウンドが1回増えます。
選ぶ基準は「うちらしさが一番出ている写真」ではなく、「はじめて知る人が見て、行きたくなる写真」です。内部の人ほど、思い入れのある写真を選びがちですが、それは二枚目以降で使えばいい。
2. 写真の総量を数える
客室タイプごとの枚数、館内、料理、周辺観光——例えば「客室3タイプ×5枚、館内10枚、料理15枚、周辺観光8枚」のように総数を出しておくと、ギャラリーの構造が決まります。
| 総枚数の目安 | 推奨する見せ方 |
|---|---|
| 〜30枚 | 1ページにまとめて遅延読み込み |
| 30〜80枚 | カテゴリタブで分割、タブ切替時に読み込み |
| 80枚〜 | カテゴリごとに別ページ、一覧はサムネイル専用画像 |
この判断を後回しにすると、実装が終わってから「やっぱり全部見せたい」となって作り直しが発生します。
3. 更新の担当者を決める
誰が、どの頻度で、どの機材で撮った写真を上げるのか。スマホなのか一眼なのか。ここが決まると、制作側は適切なアップロード処理を組めます。
図の通り、速度に効く判断のほとんどは実装前に終わっています。公開後にプラグインを入れて解決しようとすると、うまくいかないか、別の問題を呼び込みます。
よくある「これで速くなるはず」の落とし穴
圧縮プラグインを入れれば解決する、という誤解
画像圧縮系のプラグインやアプリは確かに効きます。ですが、効くのは「ページ全体の重量」の層だけです。ヒーロー画像がLCPになっている構造そのものは変わりません。
さらに、プラグインを追加すること自体がJavaScriptを増やし、別の遅延を生むケースもあります。特にECサイトでは顕著です。
「PageSpeed Insightsの点数」を目的にしてしまう
点数は指標であって、目的ではありません。旅行サイトで本当に測るべきは、ギャラリーページの離脱率と予約ボタンへの到達率です。
点数が低くても予約が取れているサイトと、点数が高くても写真が貧相で問い合わせが来ないサイトなら、前者のほうが健全です。数字を追う前に、何のための速度なのかを確認してください。
計測の設計については、こちらが参考になります。
すべての画像を同じ基準で扱う
ヒーロー画像とギャラリーのサムネイルとSNSアイコンは、求められるものがまったく違います。一律の圧縮率をかけると、ヒーロー画像が粗くなって印象を損ないます。
旅行サイトでは、主役写真だけは画質を優先する判断が正解になることが多い。一枚のために読み込みが少し遅くなっても、その一枚で行きたいと思わせられるなら投資対効果は合います。逆に、ギャラリーのサムネイルは思い切って品質を落としても誰も気づきません。
実装で最低限押さえる項目
技術的な詳細は前掲の最適化ガイドに譲りますが、旅行サイト特有の優先順位だけ整理しておきます。
先にやる（効果が大きい）
- ヒーロー1枚の優先読み込み
- スライダー2枚目以降の遅延
- ギャラリーのサムネイル分離
- アップロード時の自動変換
後でよい（効果が限定的）
- フッター付近の画像の圧縮率調整
- アイコン類のSVG化
- 全画像の一括フォーマット変換
左側の4つを終える前に右側に手を出すと、労力に対してほとんど数字が動かず、「最適化しても速くならない」という誤った結論にたどり着きます。
実装の順番としては、まずヒーロー1枚。ここだけで初回表示の体感が変わります。次にギャラリー。最後に運用の仕組み——ただし運用の仕組みだけは、後から入れると既存画像の作り直しが発生するので、設計段階で決めておくのが理想です。
サイト全体の構造設計については、こちらも合わせて読むと判断しやすくなります。
よくある質問
旅行サイトの画像は何枚くらいが適正ですか？
枚数に上限はありません。ギャラリーは見たい人が見るページなので、多いこと自体は問題になりません。重要なのは、初回表示で読み込まれる枚数を絞ることです。トップページのファーストビューで実際に読み込まれるのが1〜2枚に収まっていれば、サイト全体で100枚あっても体感は軽くなります。
既存サイトの画像を後から最適化できますか？
できますが、効果は構造によって変わります。圧縮や形式変換は後付けで効きますが、ヒーロースライダーの読み込み設計やサムネイル分離は実装の作り直しが必要です。まずPageSpeed Insightsで「最大コンテンツの描画」に何が指定されているかを見て、それがヒーロー画像なら改修の価値があります。
現場スタッフが大きい画像を上げてしまうのを防ぐには？
ルールで縛るのではなく、仕組みで吸収してください。CMSにアップロードした時点で自動的にリサイズ・変換される設定にしておけば、何が上がっても壊れません。「1200px以下にしてから上げる」という運用ルールは、半年で守られなくなります。制作会社に依頼するときは、この自動処理が含まれているかを明示的に確認してください。
写真のクオリティを落とさずに速くできますか？
主役写真とそれ以外を分けて扱えば可能です。ファーストビューの1枚は画質優先で残し、ギャラリーのサムネイルや下部のセクション画像は圧縮率を上げる。ユーザーが画質を意識して見るのは最初の一枚と拡大表示したときだけなので、この2箇所を守れば全体の印象は落ちません。
予約システムのウィジェットが重い場合はどうすべきですか？
画像とは別問題として切り分けてください。外部ウィジェットは多くの場合JavaScriptの読み込みが原因で、画像を最適化しても改善しません。ウィジェットの読み込みを遅延させる、あるいはトップページには予約ボタンだけ置いて専用ページで読み込む、といった構成変更が有効です。
まとめ：旅行サイトの画像最適化は「減らす」ではなく「分ける」
旅行サイトの写真は、売り物そのものです。だから減らすという発想では解けません。
解き方は「分ける」です。
- 初回表示に要る画像と、後から読めばいい画像を分ける
- 主役写真と、それ以外の画像を画質基準で分ける
- 一覧用サムネイルと、拡大表示用の画像を分ける
- 制作時の最適化と、運用で壊れない仕組みを分ける
この4つの分離ができていれば、写真が100枚あっても速いサイトになります。逆に、どれだけ丁寧に圧縮しても、分離ができていないサイトは重いままです。
Soreiine!!のギャラリーには、実際に「写真をたっぷり使いながら速い」旅行・観光サイトが掲載されています。数字を読むより、実物をスマートフォンで開いて、ファーストビューが何秒で立ち上がるかを体感してみてください。設計の差は、そこに一番はっきり出ます。
