ユーザーコンバージョンを倍増させるためのHTMLファーストなサイト構築

HTMLファースト・アーキテクチャがユーザーコンバージョンを倍増させた

複雑でJavaScriptに依存したReactアプリケーションを、Astroを使用したHTMLファーストのアーキテクチャに置き換えたことで、規制対象の公共事業会社におけるサービス申請フォームの完了ユーザー数が倍増しました。コンバージョンが増加した理由は、新しいサイトが古いブラウザ、不安定なネットワーク接続、および支援技術（アクセシビリティ技術）でも機能し続けたためです。以前はJavaScriptの失敗によって「離脱」し、JavaScriptベースの分析ツールでは「見えない」存在となっていたユーザーが、利用可能になりました。

クライアントサイド・アプローチの失敗

HTMLファーストの実装を行う前、同社はReactアプリで申請プロセスを解決しようと試みましたが、リリースから3日以内に深刻な顧客からの苦情により失敗に終わりました。React実装における技術的な失敗には以下が含まれます：

  • 過剰なペイロード: 単純なフォームを表示する前に、大量のJavaScript（最大20MB）を配信すること。
  • 不適切な状態管理: グローバルなJavaScriptの状態やローディングスピナーへの依存が、ユーザー体験を低下させたこと。
  • ストレージの制限: 重要な画像のアップロードやフォームデータを、5MBという厳しい制限がある localStorage に保存しようとしたこと。
  • アクセシビリティの欠如: アプリケーションが基本的なアクセシビリティ基準を満たしておらず、支援技術を利用するユーザーを疎外してしまったこと。

HTMLファースト設計の核となる原則

10年前のAndroid端末や極端に制限されたブラウザを使用している人々を含む、すべての市民がサービスを利用できるようにするために、プロジェクトは以下の要件に基づきAstroを使用して再構築されました：

1. プログレッシブ・エンハンスメント

JavaScriptは体験を「強化」するためにのみ使用され、「有効化」するために使用されませんでした。サイトはJavaScriptなしでも完璧に動作するように設計されており、「粗末なブラウザ」（PlayStation Portableのブラウザなど）を使用しているユーザーでも、重要な公共サービスにアクセスできることを保証しました。

2. サーバーサイドの状態管理と永続化

データの損失を防ぐため、アプリケーションはクライアントサイドのストレージから脱却しました。各セッションには一意のIDが割り当てられ、フォームウィザードの各ステップにおいて、ファイルアップロードを含むデータがバックエンドに保存されました。これにより、ユーザーはフォームを開始し、数週間後に進捗を失うことなく完了させることが可能になりました。

3. マルチページ・フォームフロー

シングルページアプリケーション（SPA）の代わりに、サイトは伝統的なウェブパターンを採用しました：フォームの各ステップは独自のページでした。ステップの送信はAPIへのPOSTリクエストをトリガーし、有効であればサーバーがユーザーを次のページにリダイレクトします。このアプローチにより、複雑なクライアントサイドのルーティングや状態の同期の必要性が排除されました。

4. 軽量なバリデーション

重いReactのバリデーションライブラリを使用する代わりに、実装ではネイティブのブラウザバリデーションを活用し、カスタムHTMLウェブコンポーネント（後に validation-enhancer としてリリース）によって強化されました。このコンポーネントは：

  • 既存のHTMLフォームをラップして、モダンなUIを提供します。
  • アクセシビリティのために、デフォルトのブラウザツールチップの代わりに aria-describedby または aria-errormessage を使用します。
  • 1KB未満のJavaScriptで動作します。
  • ネイティブのブラウザバリデーション、そして最終的にはバックエンドAPIのバリデーションへとフォールバックし、多層的なセーフティネットを確保します。

影響と洞察

「見えないユーザー」の問題

最も重要な発見は、JavaScriptベースの分析パッケージが、分析自体を実行するために必要なJavaScriptをロードできないユーザーを追跡できないという点でした。リリース後の新しいユーザーの「急増」は、人口の大部分を占める、これまで静かにサービス利用に失敗していた層が明らかになったことを示していました。

コミュニティの視点

業界の専門家は、この移行からいくつかの重要な教訓を強調しています：

"JavaScriptベースの分析パッケージは、JavaScriptの失敗によって離脱させているユーザーを検知できません。このようなバイアスが、彼らが存在しないという考えを強化してしまうことを考えると、恐ろしいことです。"

他の開発者は、重いSPAへの傾向は、エンドユーザーのニーズではなく、請負業者のインセンティブや開発者の習慣を反映していることが多いと指摘しています。技術（React vs. Astro）はあくまでツールであり、真の勝利は、厳格な設計制約と、低スペックのハードウェアや不安定な接続環境にあるユーザーへの共感に基づいた設計の適用であったと主張する者もいます。

技術サマリーテーブル

特徴 以前のReactアプローチ 新しいHTMLファースト・アプローチ
レンダリング クライアントサイド (SPA) サーバーサイド (Astro)
データストレージ localStorage (5MB制限) バックエンド・セッションストレージ
バリデーション JSライブラリ ネイティブHTML + <1KBのウェブコンポーネント
接続性 高速通信/モダンなJSが必要 3G / レガシーブラウザで動作
アクセシビリティ 低い / 非準拠 WCAG AA準拠
}

Sources