Algolia™は必要ないかもしれない

静的サイトにおそらくホスティング型検索は不要

Image by Dan Levy

ほとんどのサイト検索の決定は、時期が遅すぎる。

「Algoliaを使うべきだ」と誰かが言う頃には、チームはすでに肝心の質問を飛ばしていることが多い。つまり、「何を検索するのか？」だ。

答えが「すでにビルド済みのHTMLページ」なら、Pagefindを最初に試すべきだ。Algoliaが悪いからではない。Algoliaは難しい問題に対して非常に優れている。しかし、検索インデックスがサイトデプロイのタイミングで変わるなら、ホスティング型検索サービスはインフラのコスプレに過ぎないかもしれない。

検索対象のコンテンツがビルド時に生成される場合はPagefindを使え。検索がライブ書き込み、ビジネスルール、ユーザー固有のランキング、または静的ビルドでは提供できない運用保証を受け入れる必要がある場合はAlgoliaを選べ。

このルールは、人々が期待するよりも多くのサイトをカバーしている。ブログ、ドキュメント、マーケティングサイト、内部ハンドブック、製品ガイド、コースカタログ、そして驚くべきことに「ほとんどページを公開するだけのアプリ」も含まれる。

問題の構造

Algoliaは外部の検索システムを提供する。レコードを作成し、インデックスにプッシュし、ランキングを構成し、UIを接続し、そして信頼できる情報源と同期し続ける必要がある。

Pagefindは、すでに配信済みのHTMLを見て、その隣に静的検索インデックスを構築する。

この違いは、統合を維持するまで退屈に聞こえるかもしれない。

Algoliaでは、サイトにコンテンツの2番目のコピーが存在する。ここで次のような質問に答える必要がある：

• デプロイは完了したが、インデックス更新は失敗したか？
• どのフィールドが正統か：CMSのフィールド、レンダリングされたページ、それとも検索レコードか？
• ランキングの微調整がページと一致しなくなった場合、誰が責任を持つのか？
• 無料枠が実際のトラフィックの形状ではないことが判明した場合、何が起こるのか？

これらの質問に答える価値がある場合もある。マーケットプレイス、サポートポータル、または大規模なECカタログでは、おそらくそうだ。しかし、静的ドキュメントサイトでは、多くの場合自分で招いた複雑さに過ぎない。

Pagefindが機能する理由：余計なシステムを拒否するから

Pagefindのトリックは魔法ではない。それは品味だ。

Pagefindは、ページが存在するまで待ち、完成したHTMLをインデックス化し、サイトの残りの部分と同じCDNに配置できる静的アセットのコレクションを書き出す。ブラウザは必要なチャンクのみをダウンロードする。ウォームアップが必要な検索サーバーも、監視するクローラークォータも、変更内容を覚えていようとするWebhookパイプラインもない。

これにより、失敗モードがはるかに理解しやすくなる：

• ページがデプロイされたなら、インデックス化されたコンテンツはそのページから来ている。
• ページがデプロイされなかったなら、ユーザーはそもそもそれを見られない。
• 検索が間違っている場合、問題は通常、レンダリングされたマークアップまたはPagefindの設定にあり、遠く離れた同期ジョブにあるのではない。

これが、コンテンツサイトでPagefindを好む理由だ。インデックスはアーティファクトに従う。

実際のセットアップがどのようなものか

プレーンな静的サイトの場合、ワークフローは快適に退屈だ：

• CLI: サイトのHTMLファイルをスキャンし、インデックスを生成し、グローバルCDNにデプロイする——すべて数分で完了。
• 静的サイトジェネレーター: AstroやHugo用のPageFindプラグインを使用して、インデックス処理を自動化する。
• カスタムソリューション: PageFindのAPIを利用して、独自の要件に合わせた検索体験を構築する。

Getting Startedガイドは、動き始めるのに十分だ。より良いテストは運用面にある：CIでインデックスを再構築し、出力をデプロイし、レンダリングされたHTMLを検査することで全ての検索ミスについて説明できるか？

Algoliaがまだ勝つ場所

Pagefindは小さなAlgoliaがトレンチコートを着ているわけではない。それは異なる答えだ。

検索インデックスがサイトデプロイとは独立して変更する必要がある場合は、Algolia、OpenSearch、Postgres検索、または他のライブシステムを使用せよ。

これには以下が含まれる：

• 数分ごとに変化する在庫数
• ユーザーごとの権限またはプライベートな結果
• 収益、新鮮度、人気、または実験に基づくカスタムランキング
• 1つの静的サイトにレンダリングされないシステム間のフェデレーテッド検索
• ベンダーからビジネスが期待する分析および運用サポート

これらは実際のニーズだ。Pagefindが高速だからといって、これらを処理できると考えるのは、別の種類のベンダーブログの声になる。

私が使用する決定

最初に1つの質問をせよ：

検索インデックスは、ユーザーが閲覧しているのと同じ静的出力から再構築できるか？

はいなら、Pagefindから始めろ。デフォルトでプライベートな検索、CDNに優しいアセット、そして意見を持つサービスアカウントが1つ減る。

いいえなら、インデックスをライブにするものを名指しせよ：在庫、権限、パーソナライゼーション、分析、ランキング、または書き込み頻度。その後、そのジョブを明示的に所有するデータベースまたは検索サービスを選択せよ。

Algoliaはここでは悪役ではない。悪役は、最初のアーティファクトが不十分であることを証明する前に、2番目のシステムを採用することだ。