店舗サイトの写真が重い。サーバー変更前に見直す画像の大きさと枚数

一ページ、同じ操作で改善前を残す

まず、トップかメニューの一ページだけを選びます。困っているのが「最初の写真が出ない」「写真の追加で画面が動く」「予約ボタンの操作が止まる」のどれかを書き、公開URLで再現します。

• 実測データが足りないページではオリジンのデータが表示されることがあり、どちらもなければ実測は表示されない
• データなしは不合格ではない。ラボは原因調査に使い、実際の端末でも操作する

1. PageSpeed Insightsで公開URLを調べる

   モバイルとパソコンを分け、測定日時と結果を残します。

   完了の目安編集用URLや別のページと混ぜていない

2. 実測の対象範囲を読む

   実測が「このURL」か、サイトのオリジン全体かを確認します。実測は過去28日間の集計です。

   完了の目安オリジン全体の数字を、その一ページだけの結果と扱わない

3. ラボ結果から候補を探す

   診断が指摘する画像・処理と、実際の困る場面を照合します。

   完了の目安点数だけで修正内容やサーバー変更を決めていない

画像の役割と、配信する大きさをそろえる

写真の原本は残し、掲載用のコピーで調整します。元ファイルが大きくてもサービス側で縮小配信している場合があるため、原本の容量だけで原因を決めません。診断に出た実際の画像URLと掲載位置を対応させます。

• 「全画像を一律に同じ幅・容量以下」にせず、写真の用途と表示条件で決める
• srcset等を直接編集できないサービスは、自動生成の有無を公式ヘルプで確認する

表は横にスクロールして読めます。

軽量化で、最初の写真を待たせない

最初に必要な写真と、下へスクロールしてからでよい写真を分けます。遅延読み込みを一括適用すると、最初の大きな写真まで待たせることがあります。写真のための表示領域を確保する対策と、通信量を減らす対策も分けます。

• LCPは画面内の最大の画像や文字の表示を測る指標で、予約完了や全操作の快適さを保証しない
• 画像の転送が短くなっても、描画を待たせる処理が残ればLCPが変わらない場合がある

表は横にスクロールして読めます。

圧縮後は、速さと読めることを一緒に判定する

一度にすべてを変えず、選んだ画像や配置を一つずつ直します。変更前後は同じURL・端末区分で比べ、実行ごとのばらつきも見ます。今日の変更が、過去28日間の実測へ即座に置き換わるわけではありません。

• 改善記録：公開URL／変更日／変更内容／端末／画質と操作の確認／残った症状
• 制作会社へは点数だけでなく、問題が起きる画面と診断で指摘された対象を渡す

1. 変更を一つ記録する

   画像名、変更した設定、元へ戻すコピーを残します。

   完了の目安原因が分からなくなるほど同時変更していない

2. 見えることと使えることを試す

   入口の目印、料理の見た目、主要情報の文字を確認し、予約先や地図を開きます。

   完了の目安軽くなっても必要な情報や操作を失っていない

3. 診断と実際の症状を比べる

   同じ条件で測り直し、良くなった点と残った症状を記録します。

   完了の目安一回の点差だけを改善の証拠にしていない

4. 変化が乏しければ原因を切り替える

   外部の予約表示・動画・スクリプトなどを診断と照合します。

   完了の目安不要な有料プラグインや上位契約を先に増やしていない