工務店サイトは「見た目がきれい」だけでは成果につながりません。現場帰りの移動中や、家族と相談している夜にスマホで見られる場面が多く、そこで読み込みが遅い、文字が小さい、ボタンが押しにくいだけで離脱されます。
さらに厄介なのは、社内で「どこを直せば体感が改善するのか」「誰が判断するのか」が曖昧なまま、都度の修正で疲弊しやすい点です。結果として、更新のたびにサイトが重くなり、問い合わせ率がじわじわ落ちます。
この記事では、スマホ対応と表示速度を「計測→優先順位→実装→運用」に分け、現場と事務が同じ判断軸で回せる形に落とし込みます。
スマホで見づらいと言われるのですが、デザインを変えるべきか、速度を直すべきか分かりません。
速度改善はサーバーや専門知識が必要で、現場側では触れないと思い込んでいます。結局後回しです。
スマホで離脱を生まない「導線設計」と、最短で効く「速度改善の優先順位」を、社内で回せる手順とテンプレで整理します
モバイルファーストで施主の検討導線を切らさない設計
モバイルファーストは「スマホを最優先に設計する考え方」です。PC版を縮めるのではなく、スマホで見たときに迷わず次の行動へ進める順番で情報を置きます。
現場帰りのスマホ閲覧は情報を拾う時間が短い前提で組みます
施主の典型シーンは「移動中にサッと見る」「家族に見せる」「比較検討の候補に入れる」です。滞在時間が短いので、最初の画面で迷うと戻りません。実務では、トップと施工事例、会社情報、問い合わせの導線が同じレベルで並び、どこから見ればよいか分からない構成が多いです。
失敗しやすいポイントは、PC前提で「情報量を多く置けば親切」と判断してしまうことです。スマホでは情報が詰まるほど読む負担が増え、押し間違いも起きます。
ファーストビューは結論と次の一手を固定します
ファーストビューは「最初に見える範囲」です。ここに、誰向けの工務店か、何が強みか、次に何を見ればよいかを固定します。具体例として、現場帰りに見た施主は「施工事例」と「費用感」と「対応エリア」を先に確認しやすいです。
- 最初の画面で伝えるのは「強みは1つ」「対応エリア」「相談導線」の3点に絞ります
- 事例へは「種類別（新築／リフォーム／耐震など）」で入口を分けます
- 電話やLINEなどの導線は、押しやすい位置に1つだけ固定します
改善のコツは、社内で「最初の画面で伝える要素」を決めてからデザインを触ることです。判断軸がないまま見た目をいじると、要素が増えて重くなり、結局離脱が増えます。運用イメージとしては、月1回だけファーストビューの文言と導線を点検し、追加は原則しないルールにします。
スマホの最初の画面は「強み1つ＋対応範囲＋次の一手」で固定し、情報追加は原則しない運用にしましょう
表示速度の遅さは原因を分解して優先順位で直します
表示速度は「速くする」より「遅い原因を切り分ける」ほうが成果につながります。工務店サイトは画像が多いので、原因を特定せずにサーバーだけ変えても改善が小さいケースが多いです。
Core Web Vitalsはユーザー体験を数値化する指標です
Core Web Vitalsは「ページ体験を測るGoogleの指標」です。代表例として、LCPは「主要な内容が表示されるまでの時間」、CLSは「表示中にレイアウトがずれる量」、INPは「操作してから反応するまでの遅れ」を示します。
失敗しやすいポイントは、スコアだけ見て一喜一憂することです。改善の判断軸は「施主が読むページ（事例・料金・会社情報・問い合わせ）」の体感が改善しているかで揃えます。
社内で回す計測手順を固定すると迷いが減ります
計測は担当者の勘にせず、手順を固定します。具体例として、更新直後に画像を追加したら遅くなった、という現場あるあるは、計測ログがないと原因が特定できません。
【計測テンプレ】
1) 対象URL：
2) 計測日：
3) 直近の更新内容（画像追加／事例追加／プラグイン更新など）：
4) 計測結果（LCP／CLS／INPのメモ）：
5) 体感の不満（読み込み待ち／カクつき／ズレ）：
6) 次の打ち手（画像圧縮／遅延読み込み／キャッシュ見直しなど）：
改善のコツは、まず「何が原因になりやすいか」を一覧化し、担当を割り振ることです。下の表は、よくある遅さの原因と確認方法を、工務店の実務目線で整理したものです。
| 遅くなる原因 | 確認方法（社内でできる） | 優先度の目安 | 主担当の例 |
|---|---|---|---|
| 画像が重い | 事例ページの画像サイズと枚数を確認します | 高 | 広報／更新担当 |
| ファーストビューが大きい | トップの大画像・スライダー有無を確認します | 高 | 制作会社／Web担当 |
| プラグインが増えた | 直近追加・更新したプラグインを洗い出します | 中 | Web担当／外注 |
| 外部スクリプトが多い | 計測タグや埋め込み（地図・SNS）を確認します | 中 | マーケ担当 |
| サーバー応答が遅い | TTFBを確認します（TTFBは最初の応答までの時間です） | 中 | 制作会社／サーバー管理 |
運用イメージは、月1回の定点計測を「トップ＋事例1本＋問い合わせ」で実施し、更新が多い月は更新直後に追加計測を1回だけ入れる形です。これで「いつから遅くなったか」が追えます。
速度改善はスコアの追いかけではなく「施主が見る3ページを定点計測し、原因を表で分解して担当を決める」順で進めましょう
画像と動画の最適化で体感速度を一気に上げます
工務店サイトは事例が資産ですが、同時にサイトを重くする原因にもなります。体感速度を上げる最短ルートは、画像と動画を「見せ方は落とさず、データだけ軽くする」ことです。
WebPとAVIFは画像を軽くできる新しい形式です
WebPとAVIFは「同じ見た目でもファイル容量を小さくできる画像形式」です。実務では、JPGやPNGのまま高解像度で上げ続けるのが最も多い失敗です。
改善のコツは、事例画像のルールを決めてから一括で揃えることです。判断軸は「スマホで拡大しなくても素材感が分かる解像度」に止め、必要以上のサイズは持たせません。
lazy loadは画面外の画像を後から読み込む仕組みです
lazy loadは「最初に必要な画像だけを読み込み、画面外の画像は後から読み込む仕組み」です。あわせて、above-the-foldは「最初に見える範囲」を指します。最初の範囲に必要な画像まで遅延させると、逆に体感が悪化します。
ここは「本文＋箇条書き＋補足解説」で、現場で判断しやすい形に整理します。
本文：事例ページで効きやすいのは、ファーストビューの1枚だけは先に表示し、本文内の多数の写真は遅延読み込みに回す設計です。
- トップの大画像やスライダーは原則1枚に絞ります
- 事例の写真は「用途別に同じ幅」で揃え、差し替えコストを下げます
- 動画は埋め込み前提ではなく、サムネ＋クリック再生を基本にします
補足解説：スライダーは見栄えが良い反面、複数枚を同時に読み込むため重くなりやすいです。現場の改善では「まず1枚化」「次に画像形式と圧縮」「最後に遅延読み込み」の順で手戻りが減ります。
【事例画像ルール テンプレ】
1) 画像の最大横幅：
2) 形式：WebP（代替を用意する場合はJPG）
3) 1事例あたりの写真枚数上限：
4) ファーストビュー画像：遅延しない（先読み設定）
5) 本文内画像：遅延読み込みを基本
6) アップロード前チェック：容量／縦横比／ブレの有無
施工事例についてはこちらの記事で詳しく解説しています。
WordPressとSWELLでできる実装改善を現実的に揃えます
WordPressは更新しやすい反面、プラグイン追加で重くなりやすいです。SWELLを使っている場合も、テーマが優秀でも「使い方」で速度は劣化します。社内で触れる範囲と外注が必要な範囲を切り分けます。
キャッシュは一度作った表示結果を再利用して速くする仕組みです
キャッシュは「同じページを毎回ゼロから作らず、作った結果を再利用する仕組み」です。失敗しやすいポイントは、キャッシュ導入後に表示崩れや更新反映遅れが起き、結局オフにしてしまうことです。
改善のコツは、対象ページを限定して段階的に適用し、問い合わせや施工事例など重要ページで問題がないか確認することです。運用イメージとしては、更新担当が「更新後にキャッシュ削除を1回行う」手順まで含めて固定します。
JSとCSSは動きと見た目のプログラムです
JavaScript（JS）は「ページ上の動きや処理を行うプログラム」で、CSSは「見た目を整える設定」です。これらが多いと読み込みが増え、スマホでカクつきます。
失敗しやすいポイントは、便利そうな機能を追加し続けて「どれが重い原因か分からない」状態になることです。改善の判断軸は「問い合わせ導線に直接効く機能か」で揃え、必須以外は削ります。
【稟議テンプレ（外注・プラグイン導入）】
目的：スマホ表示速度と操作性の改善で離脱を減らし、問い合わせ率を落とさないため
対象：トップ／施工事例／問い合わせの3ページ
現状課題：読み込み待ち、表示ズレ、押しにくさが発生
実施内容：画像最適化、キャッシュ設定、不要機能の整理、計測の定点運用
費用上限：
完了条件：計測値の改善＋実機での体感確認（社内チェック）
担当：依頼窓口／更新担当／確認者
社内で回すためには、外注に丸投げせず「計測テンプレ」「画像ルール」「更新手順」をセットで渡すと、改善が継続します。制作会社側も判断材料が揃うため、手戻りが減ります。
プラグイン追加は「問い合わせ導線に直結するか」を判断軸にし、導入後は定点計測と更新手順までセットで運用しましょう
問い合わせ率を落とさないモバイルUIを作ります
速度だけ直しても、問い合わせまでの導線が弱いと成果は出ません。特にスマホでは「押しやすさ」と「迷わなさ」が重要です。電話、LINE、フォームのどれで受けるかを決め、導線を整理します。
CTAは行動を促すボタンや案内です
CTAは「問い合わせや資料請求など、次の行動を促す導線」です。失敗しやすいポイントは、ボタンが多すぎて選べない状態になることです。現場帰りの施主は、1回で決めたいので迷うほど離脱します。
改善のコツは、入口は複数でも「最終的に選ばせるのは1つ」に寄せることです。例えば、まずはLINE相談を主導線にし、フォームは補助、電話は営業時間内だけなど、社内の対応体制に合わせて決めます。
フォームは入力項目を減らすほど完了率が上がります
スマホのフォームは、入力が増えるほど途中離脱が増えます。具体例として、住所や詳細要望を最初から必須にすると、検討初期の施主は送信しません。
- 初回は「名前（任意可）／連絡先／相談内容（選択式）」までに絞ります
- 希望日時は候補選択にし、自由記述を減らします
- 個人情報の説明は短くし、安心材料（返信目安）を明記します
【現場・営業ヒアリング項目 テンプレ】
1) 施主からよく聞かれる質問（3つ）：
2) 相談が多いタイミング（現地調査前／比較中など）：
3) 返信の理想スピード（当日／翌日）：
4) 受けたい導線（電話／LINE／フォーム）の優先順位：
5) NG対応（夜間電話不可など）：
6) 事例ページで必ず見せたい写真（施工前後／素材感など）：
運用イメージとしては、月1回のミーティングで「問い合わせ経路の比率」と「未対応の発生」を確認し、導線を微調整します。ここが回ると、スマホ対応は一度作って終わりではなく、成果に合わせて強くできます。
スマホの問い合わせ導線は「主導線を1つに寄せ、フォームは最小項目、返信体制とセットで決める」ことが成果の近道です。
問い合わせフォームへの導線についてはこちらの記事で詳しく解説しています。
更新で劣化させない運用ルールと役割分担を作ります
サイトが遅くなる最大の理由は、改善が一度きりで、更新で元に戻ることです。施工事例の追加、バナー差し替え、プラグイン更新が積み重なり、誰も気づかないまま重くなります。
更新フローはチェック項目を先に決めると属人化しません
失敗しやすいポイントは、更新担当の判断に任せて画像や埋め込みを増やしてしまうことです。改善のコツは、更新前チェックを「5項目」程度に絞り、必ず通す運用にすることです。
月次点検はトップと事例と問い合わせだけを見ます
全部のページを点検しようとすると続きません。重要ページだけに絞ると、少人数でも回ります。具体例として、月末の事務作業が忙しい会社でも、15分で点検が終わる形にできます。
【月次点検チェックリスト テンプレ】
対象：トップ／事例1本／問い合わせ
1) スマホで開いて3秒以内に主要内容が見えるか
2) 文字が詰まっていないか、ボタンが押しやすいか
3) 事例画像が重くないか（容量・枚数）
4) フォームが途中で止まらないか（入力負担・エラー）
5) 直近更新内容と計測結果を記録したか
役割分担の例は、更新担当が画像ルールを守る、Web担当が月次点検を回す、制作会社は四半期に一度だけ実装レベルの見直しをする、という形です。こうすると、現場の繁忙期でも最低限の品質が保てます。
改善を定着させるには「重要3ページだけを月次点検」「更新前チェックを少数固定」「役割分担」をセットで運用しましょう
まとめ：スマホで逃さないサイトにする判断軸と明日からの一歩
判断軸は導線と速度を別物として整理します
スマホ対応は、導線と速度を混ぜると判断がぶれます。導線は「最初の画面で迷わせない設計」、速度は「原因分解と優先順位で直す運用」です。どちらもテンプレ化すると、担当が変わっても再現できます。
明日から試せる一歩は重要3ページの計測と画像ルール決めです
まずは、トップ・施工事例・問い合わせの3ページを決め、計測テンプレに記録します。次に、事例画像の形式と容量ルールを決め、更新フローに組み込みます。これだけで「更新で遅くなる」状態を止められます。
社内共有は、営業・現場・広報で「どの導線を主にするか」「返信体制はどうするか」まで握ると定着します。サイトは制作物ではなく運用資産なので、会議では見た目より判断軸を揃えましょう。
最初にやるのは「重要3ページの定点計測」と「画像ルールの固定」です、これを社内で共有するとスマホ対応と速度改善が継続します
