ダッシュボード用に50個のサイトアイコンを取得したいスクリプトがあり、自分でホスティングするのは避けたい。そんなときに便利なのが公開favicon APIで、わずか2行のコードで済みます。ただし、どのAPIを選ぶかで結果は大きく変わります。DuckDuckGoのfavicon APIは長年にわたりこの用途で使われてきており、GoogleのS2サービスや直接の/favicon.ico取得方法と並んで定番の選択肢です。
それぞれのオプションで返ってくるファイル形式は異なり、高負荷時の挙動も、サイト側にアイコンがないときの失敗の仕方も違います。間違った選択をすれば、サムネイルが壊れたり、ログに謎の404が記録されたりすることになります。
クイック比較: DuckDuckGo Favicon API vs 代替手段
| Criterion | DuckDuckGo | Google S2 | Direct /favicon.ico |
|---|---|---|---|
| Endpoint pattern | icons.duckduckgo.com/ip3/{domain}.ico | s2.googleusercontent.com/s2/favicons?domain={domain} | {site}/favicon.ico |
| Return format | ICOのみ | PNG (デフォルト16x16) | サイトが配信する形式 |
| Default size | マルチサイズICOコンテナ | 16x16 (sz=64が最大) | サイト定義 |
| Rate limits documented | 公式ドキュメントなし | 公式ドキュメントなし | サイトごとのCORS / サーバー次第 |
| CORS friendly | 対応 (ただし注意点あり) | 対応 | 通常は非対応 |
| Proxy / privacy layer | あり (DuckDuckGoプロキシ) | あり (Googleプロキシ) | なし |
| Fallback when missing | 404を返す | デフォルトの地球アイコンを返す | 404またはHTMLエラー |
| Best for | タブ風アイコン、ICOが必要な用途 | 小さなサムネイル、SERPとの統一 | 正確なソースアセット |
DuckDuckGo Favicon APIの実際の仕組み
エンドポイントは非常にシンプルで、https://icons.duckduckgo.com/ip3/example.com.icoでアクセスできます。DuckDuckGoが自社のインフラでサイトの実際のfaviconを取得し、必要に応じてICOコンテナへ変換した上でCDN経由で配信します。オリジンサーバーへ直接アクセスすることはなく、ほとんどのCORSの壁を回避できます。
このプロキシ的アプローチにより、URLはプライバシー保護付きのfetchとしても機能します。訪問者のブラウザは、アイコンを描画するためだけにターゲットサイトに直接接続しません。これはGoogleのs2.googleusercontent.comが使っているのと同じ手法であり、どちらのエンドポイントも追加ヘッダーなしで任意の出元の<img>タグで動作する理由でもあります。
フォーマット上の制約
最大の落とし穴は、DuckDuckGoがICOのみを返すという点です。iOS風の一覧表示のように、くっきりとした64x64のPNGが必要な場合は変換が必要になります。当社のPNG to ICO変換ガイドでは逆方向の変換方法を解説していますが、同じツールで双方向ともに対応できます。ICOで問題ないプロジェクト — デスクトップブラウザのタブ、レガシー<link rel='icon'>のフォールバックなど — では、DuckDuckGoが事実上最も手間のかからない選択肢です。
DuckDuckGo Favicon APIが選ばれるケース
- ICOを変換ステップなしで使用したい場合。ブラウザタブのフォールバック、レガシーIEサポート、WindowsショートカットはいまだにICOを必要とします。DuckDuckGoならICOを直接取得できます。
- ブラウザから呼び出し、CORS設定を一切行いたくない場合。DuckDuckGoとGoogleはいずれもリクエストをプロキシしますが、DuckDuckGoは歴史的にホットリンクに対してより寛容な傾向があります。
- プライバシーを重視したプロキシを求めている場合。DuckDuckGoはトラッキングを行わないというブランドで成り立っているため、同社のfaviconエンドポイントはGoogleのものよりも「監視されている」感じが薄れます。
Google S2の方が適しているケース
- ICOではなくPNGが必要な場合。Googleのエンドポイントはデフォルトで
image/pngを返し、最大64ピクセルまでのsz=パラメータに対応しています。 - SERP風の一覧を構築している場合。Googleはサイトにfaviconがない場合にデフォルトの地球儀アイコンを返します。DuckDuckGoは404を返すため別途ハンドリングが必要です。
- 16x16のサムネイルを一貫したサイズで取得したい場合。Googleのレスポンスは常に小さく、高速、かつ予測可能です。
直接 /favicon.ico を取得する方式が依然として有効なケース
信頼できる単一サイト（自社CDN、パートナーのサイト、信頼できる既知のソース元）の場合、faviconを直接取得すれば、フル解像度のオリジナルアセットを取得できます。SVG、マルチ解像度のICO、アニメーションPNGなど、サイトが実際に配信しているものがそのまま得られます。トレードオフはCORSで、多くのサイトはブラウザが必要とするヘッダーを返さないため、この方法はサーバー間でのみ機能し、クライアントサイドでは動作しません。
一括取得を行う場合、レート制限のドキュメントが公開されていないことは現実的なリスクです。50リクエスト程度で429を返すオリジンもあれば、そうでないものもあります。公開APIはまさにそのリスクを引き受けるために存在しています。
推奨
ブラウザのタブやリストビューで動作するアイコンが必要となるクライアントサイドプロジェクトの多くでは、ICOを取得したい場合のデフォルトとしてDuckDuckGo favicon APIが適切です。自身のアイコンも配信したい場合は、無料のfaviconジェネレーターと併用してください。PNGサムネイルやGoogle SERPと遜色ない結果が必要な場合は、GoogleのS2エンドポイントの方が高速で挙動も予測しやすくなります。フル解像度のソースファイルが必要で、かつ信頼できる単一ドメインに限定した用途では、直接の/favicon.ico取得を限定的にご利用ください。
どのAPIを選んだとしても、結果をキャッシュしてください。ブラウザのfavicon取得はキャッシュが効きにくいことで知られており、ページ読み込みごとにDuckDuckGoのCDNへ負荷をかけなければ、サーバー側にとっても好都合です。
ドキュメント化された要件を確認する
HTML仕様では、rel='icon'が現在のページを表すアイコンのリンク関係として定義されています。