「サイトはきれいになったのに、なぜか問い合わせが減った」——コーポレートサイトや申込フォームをリニューアルした中小企業から、ときどき聞く相談です。デザインは今風になり、画面はぬるぬる動く。けれど蓋を開けると、フォームの完了数が以前より落ちている。原因の多くは見た目ではなく、「JavaScript を前提に作り込みすぎて、回線や端末が弱いユーザーをこぼしている」ことにあります。
最近、海外のエンジニアが公開した How building an HTML-first site doubled our users overnight という記事が Hacker News で大きな反響を呼びました。ある公共サービスの申込フォームを、外注先が React で作ったところ、ローディングスピナーとグローバルな JavaScript 状態の塊になり、公開 3 日で苦情により取り下げ。これを **HTML ファースト（まず動く HTML を作り、JS は補助に回す）で作り直したところ、申込を完了する人が一晩で倍増しました。しかも運営側の解析ツールはその増加分を捉えられなかった——なぜなら JS ベースの解析タグは「JS が失敗して離脱したユーザー」を最初から数えられないからです。受託で企業サイトを支える立場では、これは「フレームワーク論争」ではなく、「JS の作り込みが、見えないところで問い合わせを削っていないか」**という売上に直結する問題だと捉えています。
なぜ「動いて見えるのに問い合わせが減る」のか
JavaScript を前提にしたサイトは、回線・端末・拡張機能のどれかがつまずくと、ユーザー側では何も表示されない・送信ボタンが反応しないという形で壊れます。本人は「このサイト、壊れてる」と感じて静かに離脱します。
ここで厄介なのは、その離脱が運営側のデータに残らないことです。GA4 をはじめ多くの解析は JavaScript で動くため、JS が読み込めなかったユーザーはセッションとしてカウントされません。つまり「指標上は問題なさそう」に見えていても、実際には一定数の見込み客が画面の向こうで詰まっている。元記事の筆者が「分析ツールはどこから増えたか分からなかった」と書いたのは、まさにこの構造を突いています。
中小企業のサイト訪問者は、最新の高速回線・最新端末ばかりではありません。古いスマホ、電波の弱い場所、企業の制限された社内ネットワーク——こうした環境ほど JS の重さが効いてきます。問い合わせや申込のような「ここで取りこぼすと売上を失う」導線ほど、JS への依存を減らす価値が大きいのです。
HTMLファーストとは「JSをやめる」ことではない
誤解されがちですが、HTML ファーストは JavaScript を全否定する思想ではありません。「まず JS なしでも成立する HTML を作り、その上に体験向上として JS を載せる」という順番の話です。標準の <form> は JavaScript がなくても送信できますし、リンク遷移もブラウザの標準機能で完結します。土台がそれで動くなら、JS が失敗しても最低限フォームは送れる・ページは読める状態を保てます。
| 観点 | JS前提（SPA寄り） | HTMLファースト |
|---|---|---|
| 初期表示 | JS の読込・実行を待つ | HTML が即表示される |
| フォーム送信 | JS が壊れると送れない | 標準フォームで送れる |
| 解析の死角 | JS 失敗ユーザーを計測不能 | サーバー側で取りこぼしを把握 |
| 弱い回線・端末 | 体験が大きく劣化 | 比較的堅牢に動く |
| 保守 | 状態管理が複雑化しがち | 仕組みが素直で引き継ぎやすい |
この発想は、決して目新しいものではありません。GH Media でも Jamstackは新しい標準になるか（GH Media） や ストリーミングSSRで体感速度を上げる受託（GH Media） で、過剰な JS を避けて体感速度を上げる方向性を扱ってきました。HTML ファーストはその「申込・問い合わせ導線版」だと考えてください。
受託で提供する「HTMLファースト・リビルド」
弊社の受託では、こうしたサイトをいきなり全面作り直しするのではなく、「どこで・どれだけこぼしているか」を計測してから、効果の大きい導線だけを作り直す進め方を取ります。
まず「取りこぼし」を可視化する
最初にやるのは作り直しではなく診断です。サーバー側のアクセスログ（JS に依存しない）と、フォームの「開始数」対「完了数」を突き合わせ、JS 起因で消えている可能性のある離脱を推定します。ある士業のクライアントでは、問い合わせフォームの開始から完了までの脱落が想定より大きく、原因をたどると入力途中で走る入力補助スクリプトが古い端末で固まっていました。ここを標準フォーム＋サーバー側バリデーションに置き換えただけで、完了率が目に見えて戻りました。フォーム改善の基礎は EFO（入力フォーム最適化）の進め方（GH Media） も参考になります。
効果の大きい導線から作り直す
診断で「ここが詰まっている」と分かったら、サイト全体ではなく売上に近い導線（問い合わせ・申込・予約）から優先して HTML ファーストに作り直します。トップページの飾りより、フォーム 1 枚のほうが売上に効くことは珍しくありません。「問い合わせが来ない」こと自体の切り分けは 問い合わせが来ないサイトの直し方（GH Media） でも整理しています。
バックエンドで入力を保持する
元記事では、ユーザーがフォームを開始してから1 か月後に完了した例が紹介されています。途中の入力をサーバー側のセッションに保持していたから実現できたことです。受託では、長い申込フォームほど「途中で離脱しても続きから入力できる」設計を入れ、機会損失を減らします。
作り直しの判断基準 — 全部 HTML にすべきではない
HTML ファーストが向くのは、主に情報提供と申込・問い合わせが中心の企業サイトです。逆に、ログイン後に複雑な操作を伴う管理画面やダッシュボードまで HTML だけで作るのは不自然で、ここは JS（必要なら SPA 的な作り）が適します。判断を誤らないことが受託の腕の見せどころです。
| 向いている | JSの作り込みが妥当 |
|---|---|
| コーポレート・サービス紹介 | ログイン後の業務アプリ |
| 問い合わせ・申込・予約フォーム | リアルタイム更新が要る画面 |
| 採用・IR など情報発信 | 複雑なドラッグ操作のUI |
| LP・キャンペーンページ | 社内向けダッシュボード |
「公開サイトは HTML ファーストで堅く、ログインの内側はリッチに」という住み分けが、多くの中小企業にとって現実的な最適解です。SPA からの移行可否は Navigation API を使った SPA 遷移の見直し（GH Media） も併読してください。
価格モデル — HTMLファースト・リビルド
| プラン | 金額 | 対象 | 内容 |
|---|---|---|---|
| 取りこぼし診断 | 15 万円〜 | 1 サイト | ログ/フォーム計測 + 離脱推定レポート |
| 導線リビルド | 50 万円〜 | 主要フォーム | 申込・問い合わせ導線を HTML ファーストで作り直し |
| サイトリビルド | 120 万円〜 | サイト全体 | 公開サイトを HTML ファーストへ再構築 |
| 継続改善 | 3 万円〜 / 月 | 運用 | 完了率モニタリング + 改善提案 |
診断（15 万円〜）だけでも、「いまの自社サイトが、見えないところでどれだけ申込をこぼしているか」を数字で把握できる価値があります。多くのサイトは、派手な作り直しよりフォーム 1 枚の堅牢化のほうが投資対効果が高いものです。
ハマりやすい落とし穴
第一に、「速くする」を JS の追加最適化だと思い込むこと。圧縮や遅延読み込みを足す前に、そもそも JS に依存しすぎていないかを疑うべきです。第二に、解析の数字だけを信じること。JS 失敗ユーザーは計測から消えるため、サーバー側ログと突き合わせないと取りこぼしは見えません。第三に、全ページを一律に作り直そうとすること。効果は導線ごとに偏るので、売上に近い順に手を入れます。表示速度の土台づくりは Core Web Vitals 改善ガイド（GH Media） も参考にしてください。
まとめ — 「動いて見える」より「こぼさない」
サイトが滑らかに動いて見えても、JavaScript の作り込みが回線や端末の弱いユーザーを静かに弾いていれば、その分だけ問い合わせと売上を失っています。しかもその損失は解析データに残りません。受託で企業サイトを支える立場では、まずサーバー側の計測で取りこぼしを可視化し、売上に近い導線から HTML ファーストで作り直す「リビルド」が、リニューアル後に問い合わせが減ったサイトを立て直す主力サービスです。
「リニューアルしたのに問い合わせが減った」「フォームの完了率が低い気がする」というご相談は お問い合わせフォーム からお気軽にどうぞ。まずは取りこぼし診断から始められます。
