店舗名の数文字を検索するために、すべての店舗情報を先に受け取る必要はあるだろうか。ブラウザー内で検索するには比較用の一覧が要る。小規模なら単純な方法だが、店舗が約300か所に近づき、検索しない場所まで転送する量が増えていた。

Gammaでは検索語をサーバーへ送り、関連する店舗だけを受け取る方式へ変えた。周辺の距離計算と検索が別々のAPIから似た資料を取得していたため、検索用の転送から減らす必要があった。

ブラウザー検索の準備費用

ブラウザー検索は、受け取った一覧と入力文字列を比較して結果を選ぶ方法である。特定の店名を探す場合でも、どこに一致があるか調べるには全候補が必要になる。入力後の比較は単純だが、準備量が一覧全体に応じて増える。

従来は検索用と距離計算用の資料を別々に受け取っていた。同じ店舗が大きな応答に繰り返し含まれれば、最初の画面を開く人も負担する。欲しい結果に比べ、転送する範囲が広くなっていた。

従来のBeta検索画面。2023-12-25のコードをサンプルデータで再現した。当時は取得済みの一覧と検索語を比較していた。 韓国語の原画面。当時のBetaは韓国語のみ対応。

flowchart TD
    accTitle: 従来の検索の準備コスト
    accDescr: ブラウザーは全データを受け取った後、入力された検索語で結果を絞り込んでいた。
    A["全ゲームセンター一覧を転送"] --> B
    B["ブラウザーに一覧を準備"] --> C
    C["検索語で結果を絞り込む"]

キーワード検索API

APIは、画面がサーバーへ処理を要求する窓口である。検索APIには現在のキーワードを送り、サーバーが関連する店舗を結果として返す。全候補をブラウザーで比べる処理を、サーバー側の検索へ移す方式だ。

これにより、一店舗を探すために全検索資料を準備する必要が減る。一方、検索ごとに通信するため、全件ダウンロードをやめた後は入力に伴う要求回数も考える必要がある。

flowchart TD
    accTitle: キーワード中心のリクエスト
    accDescr: 入力が落ち着いたらキーワードを送り、関連する場所だけを受け取る。
    A["検索語を入力"] --> B
    B["入力待ち"] --> C
    C["サーバーへキーワードを送信"] --> D
    D["関連する結果を表示"]

入力待ちと結果の取得

検索語は一度に完成するものではない。店名を入力する途中の文字列ごとに要求すれば、未完成の検索に対する応答も返ってくる。そこで値がしばらく変わらないときに取得する待機を設けた。入力が落ち着いてから要求する方法をデバウンスと呼ぶ。

画面は現在の検索語を管理し、サーバーの結果を表示する。今回の対象は検索であり、ホームの距離計算用一覧まで全部移したわけではない。同じ店舗情報を使っていても、この二つは別に改善する必要がある。

flowchart TD
    accTitle: 今回の変更と残る距離計算
    accDescr: 検索の全一覧への依存を減らし、ホームの距離計算の負担は別の課題として残す。
    A["検索専用のリクエスト"] --> B
    B["検索用の全一覧転送を削減"] --> C
    C["ホームの距離計算は別の課題"]

初期表示の改善と通信への依存

今回の作業では初期読み込みが約1秒短くなることを確認した。検索用の全一覧を先に取得する過程がなくなったことによる観測値である。端末や通信環境が変わっても、同じ時間が減るとは限らない。

サーバー検索は通信の遅延や応答失敗の影響を受ける。入力が速く変わる場合には、どの検索語に対する結果かを合わせて表示する必要もある。名称や別名が誤っていたり資料が古かったりすれば、転送量を減らしても候補が見つからない問題は残る。

参考：Musecatのエンジニアリング記録。

関連アップデート

• Musecat δ8 アップデート