【ITニュース解説】'Browser Tools, Server Checks, and a Directory: One Architecture'

多くの無料オンラインツールを提供するウェブサイトは、設計において二つの大きな課題を抱えている。一つは、サイトに存在する全てのツール機能を最初に読み込んでしまう方式で、これはページが重くなり、読み込みが遅くなる原因となる。もう一つは、ほとんどの操作を常にサーバーに依存する方式で、これもユーザーが操作するたびにサーバーとの通信が発生し、遅延が生じやすい。どちらの方法も、ユーザーにとって最適な体験を提供しているとは言えない。

今回解説するsitetoolsbox.comというサイトは、これらの課題に対し、異なるアプローチを採用している。このサイトは、ウェブサイトのナビゲーション機能と、ブラウザ上で動作するツール、そしてサーバーの助けを借りて動作するツールの両方を組み合わせたハイブリッドなアーキテクチャで構築されている。具体的には、PHPというプログラミング言語を使って開発されており、データをサーバーに送らずにJSONを整形できるツールや、RDAPという新しいプロトコルを利用して大量のドメイン登録状況を確認できるツールなどを提供している。この設計は、必要に応じて静的な（変化しない）ページを使い、動的な（変化する）処理が必要な場合にだけ動的な仕組みを導入し、さらにそれらの機能を必要な時だけ読み込むという、「意図的に地味」とも言える堅実な方法が取られている。

まず、ブラウザ側で完結するツールの代表例として、「JSON Formatter」を挙げる。このツールは、ユーザーがJSON形式のデータを入力し、それを整形したり、正しい形式であるか検証したり、整形後のデータをコピーしたりする機能を提供する。この種のツールでは、ユーザーが入力したデータがブラウザからサーバーへ送信される必要は全くない。もしデータがブラウザからサーバーへ送られてしまうと、そのたびに通信による遅延が発生し、データの送受信に余計なコストがかかるだけでなく、ユーザーのプライバシーに関するリスクも生まれてしまう。無駄な処理を省くことで、ユーザーはより速く、安全にツールを利用できる。

このJSON Formatterは、ユーザーがそのツールを開いたときに初めて読み込まれるように設計されている。つまり、ウェブサイトのトップページや他のカテゴリページを開いた時点では、JSON Formatterの機能は読み込まれていない。このように、必要な機能を必要なタイミングで読み込む仕組みを「遅延読み込み（lazy-load）」と呼ぶ。これにより、最初にページを表示する際のJavaScriptの量を大幅に削減でき、特に性能の低いスマートフォンなどでも、ユーザーがまだ何も操作していない段階でページが重くなり、動きがカクカクするような問題を防ぐことができる。JSONの整形や検証には、JavaScriptのJSON.parseやJSON.stringifyといった標準機能が使われており、入力データが極端に大きくない限り、ブラウザのメイン処理で十分高速に動作する。

次に、サーバー側での処理が必要となるツールの例として、「大量ドメインチェック」ツールを説明する。ドメイン（ウェブサイトのアドレス）が登録されているかどうかを確認する処理は、ブラウザ単独では実行できない。この情報は、RDAPやWHOISといった特定のプロトコルを使って、ドメインの登録情報を管理するサーバーに問い合わせる必要があるためだ。

従来のWHOISというプロトコルは、シンプルなテキスト形式で情報をやり取りするため、応答の形式がバラバラで、同時にたくさんのドメインを問い合わせる並行処理には向いていなかった。また、問い合わせ回数に厳しい制限（レートリミット）があるため、大量のドメインを一つずつ確認するような処理は、完了までに非常に時間がかかり、サーバーに問い合わせをブロックされてしまう可能性も高かった。

この問題を解決するのがRDAPプロトコルだ。RDAPはJSON形式で情報を返すため、データの処理が標準化されており、HTTPステータスコード（例: 登録済みなら200、利用可能なら404）を使って結果を判断できるため、解析が非常に簡単になる。sitetoolsbox.comでは、まずRDAPに対応しているドメインについてはRDAPを使って確認し、RDAPが利用できない場合にのみWHOISに切り替えるようにしている。

さらに、大量のドメインを高速にチェックするために、PHPのcurl_multiという機能が活用されている。これは、一度に複数のHTTPリクエストを並行して実行できる機能だ。仮に200個のドメインを一つずつ順番にチェックすると何分もかかってしまうが、curl_multiを使えば、例えば最大30個のRDAPクエリを同時に実行できる。これにより、登録情報管理サーバーへの負担を考慮しつつも、ユーザーが実用的に使える速さで大量のドメインチェックを完了させることが可能になる。これは、適切なプロトコル（RDAP）と適切な並行処理モデル（curl_multi）を組み合わせることで、非効率なWHOISプロトコルを力ずくで突破するのではなく、よりスマートな解決策を提供している良い例だ。

サイト全体の「ディレクトリ」機能、つまりツールやカテゴリの一覧ページも重要な要素だ。これらのページは、ユーザーが目的のツールを見つけやすくするための「発見の窓口」であり、検索エンジンからのアクセス（インデックス登録）が非常に重要になる。そのため、全てのツールページやカテゴリページには、検索エンジンが内容を理解しやすいために必要な情報（ページのタイトル、説明文、正規URL、見出しなど）が適切に設定されている。また、サイト全体や個々のツールに関する構造化データ（JSON-LD）を埋め込むことで、検索結果でよりリッチな情報が表示されるように工夫されている。さらに、ツールが一つも存在しないカテゴリページは、サイトマップ（検索エンジンにサイトの構造を伝えるファイル）から除外されており、コンテンツのない「空のページ」が検索エンジンにインデックスされるのを避けている。

このサイトのカテゴリは、「オンラインツール」「AI」「開発者」など、幅広くも具体的な名称が付けられている。各カテゴリページは、そのカテゴリに属するツールへのリンクを持ち、各ツールページからは、関連するカテゴリや他のツールへのリンクが張られている。このようにサイト内部で密接にリンクを張り巡らせることで、特定のツールに関するより詳細な検索クエリ（「長尾キーワード」と呼ばれる）に対しても検索エンジンの上位に表示されやすくなる。静的なページのように動作させるために、必ずしも「静的サイトジェネレーター」という特別なツールを使う必要はない。このサイトでは、PHPを使って登録情報からカテゴリページやツールページを生成し、エッジキャッシュ（ユーザーに近い場所でコンテンツを一時保存する仕組み）を使って高速に配信している。そして、ドメインチェックのようなサーバー側処理が必要な場合は、そのルート（URL）でサーバー側処理を実行できる柔軟性も持っている。

サイト全体のパフォーマンスを保つために、ディレクトリページと各ツールページでは、それぞれ異なる性能目標が設定されている。例えば、ディレクトリやカテゴリページの初期JavaScriptサイズは圧縮後120KB未満、初期表示時間（LCP）は2.0秒未満、ユーザー操作への応答速度（INP）は200ミリ秒未満といった具体的な目標がある。最も重要なルールとして、ディレクトリページのJavaScriptの量が、サイト内のツールの数が増えるにつれて増えてはいけない、というものがある。ディレクトリページはツールのメタデータ（情報）を読み込むべきであり、ツールの実際の機能は読み込むべきではない。ツールの機能は、ユーザーがツールを開く意思を示したとき（例えば、ツールカードをタップしたとき）に初めて読み込まれるべきであり、ページが最初に表示されたときに全て読み込まれるべきではない。

キャッシュ（一時保存）の仕組みも、ページの種類によって使い分けられている。ハッシュ化された（内容が変わるとファイル名も変わる）ツール機能のファイルは、非常に長期間キャッシュされることで、一度読み込まれれば再度のダウンロードが不要になる。一方、カテゴリやツールのHTMLページは、エッジキャッシュを利用して短期間キャッシュされ、必要に応じて再検証される。ドメインチェックのようなAPIエンドポイントは、ユーザーの操作に応じてリアルタイムに結果が変わるため、決してキャッシュされないように設定されている。

このハイブリッドなツールディレクトリサイトが成功しているのは、「全てを一つの技術で構築する」という考え方ではなく、各ツールが「最も適した実行環境」で動作するように割り当てられているからだ。具体的には、ユーザーデータがブラウザから出なくてよいツールは、ブラウザ側で遅延読み込みされ、サーバーにデータを送信しない設計とする。ブラウザ単独では対応できないプロトコルが必要なツールは、サーバー側で適切な並行処理モデルを用いて効率的に処理する。そして、サイトの発見やナビゲーションに関する部分は、静的で、検索エンジンにインデックス可能で、構造化され、軽量になるように構築する。

もしあなたがツールを付属させたディレクトリサイトを構築しようと考えているなら、まずツールの登録管理をしっかり行い、ディレクトリと各ツールの間に明確な「遅延読み込みの境界」を設けるべきだ。そして、ブラウザが本当にその処理を実行できない場合にのみ、サーバー側での実行を検討する。このアプローチを取ることで、結果として、高速で、検索エンジンにも見つけやすく、そして最も重要なこととして、ユーザーが要求していないツールのために待たされることのない、優れたウェブサイトを構築できるだろう。