Please note, this is a STATIC archive of website developer.mozilla.org from 03 Nov 2016, cach3.com does not collect or store any user information, there is no "phishing" involved.

リンクの先読みとはブラウザの機能の一つで、ブラウザのアイドル時間を使って、ユーザが近い将来に訪問するであろう文書をダウンロードして、予め読み込んでおくことを指します。まず、Web ページの方から先読みのヒントをブラウザに渡します。そのページの読み込みが完了すると、ブラウザは黙って指定された文書を先読みし、キャッシュに蓄積しておきます。ユーザが先読みされている文書を訪問すると、ブラウザのキャッシュからすぐに提供できます。

HTTPS でも先読みしますか?

Gecko 1.9.1 (Firefox 3.5) 以降から HTTPS コンテンツも先読みできます。

先読みのヒントとは?

HTML の link タグまたは HTTP の Link: ヘッダにおいて、next, prefetch のいずれかの関係を持つものです。 link タグを使う例を以下に示します。

<link rel="prefetch" href="/images/big.jpeg">

同じヒントを HTTP の Link: ヘッダを使って表すと次のようになります。

Link: </images/big.jpeg>; rel=prefetch

Link:ヘッダは HTML 文書中からも HTML の <meta> タグを使って指定できます。

<meta HTTP-EQUIV="Link" CONTENT="</images/big.jpeg>; rel=prefetch">

Link:ヘッダのフォーマットは、 RFC 2068 の 19.6.2.4 節で説明されています。

ヒント: 改訂版の標準 RFC 2616 には Link: ヘッダについての記述が無いため、ここではわざと改訂前の HTTP/1.1 仕様書を参照しています。 Link: ヘッダは、改訂版の標準には無いものの、実際には現在もサーバでの CSS スタイルシートの指定で使われています。そのため、我々はこの機能をここでも使うことにしました。

ブラウザはこれらのヒント全てを元に、ブラウザが使われていない時に先読みするための各リクエストを待ち行列に入れます。一ページに複数のヒントがあれば、複数の文書に対して先読みを行います。例えば、次の文書としていくつかの大きな画像を指定することもあります。

他にも以下のような指定ができます。

<link rel="prefetch alternate stylesheet" title="Designed for Mozilla" href="mozspecific.css">
<link rel="next" href="2.html">

アンカータグ（<a>）の内容も先読みされますか?

いいえ。 next か prefetch のリンク形式を持つ <link> タグだけが先読みの対象です。しかし、要望が多いようなら、next や prefetch の関係を含む <a> タグのリンクの先読みを将来的にはサポートするようになるかもしれません。そうすれば、コンテンツ提供者が先読みリンクを更新し忘れるという問題を回避しやすくなるでしょう。

はい。ここで述べているリンクの先読み機能は、既存のウェブ標準に違反していません。実際、HTML 4.01 仕様書では新たなリンク形式の定義は明確に許されています(Section 6.12: Link types を参照)。しかし、Mozilla で採用した手法自体はまだ標準化されていません。 Internet Draft を現在準備中です。

この手法の標準化は HTML5 の範囲の一部です。現在のワーキングドラフトの section §5.11.3.13. Link type "prefetch" を参照してください。

ブラウザのアイドル時間はどのように判定されますか?

現在の実装（Mozilla 1.2）では、アイドル時間は nsIWebProgressListener API を用いて判定されます。トップレベルの nsIWebProgress オブジェクトにリスナーを追加しました（"@mozilla.org/docloaderservice;1"）。このリスナーから、文書の開始と停止の通知を受け取って、前の文書の停止と次の文書の開始の間の時間をアイドル時間として概算します。前の文書の停止通知は、大まかに言って、トップレベル文書の onLoad ハンドラが起動した時に行われます。この時が先読みリクエストを行う時になります。サブフレームが先読みのヒントを含む場合にも、先読みは最上位のフレームとその「子」フレームの読み込みが終了するまで始まりません。

ユーザがリンクをクリックしたり、何らかの種類のページ読み込みを発生させたりすると、先読みは停止し、先読みのヒントは捨てられます。先読みしている文書が部分的にダウンロードされている場合は、途中までの文書をサーバから送られた "Accept-Ranges: bytes" レスポンスヘッダ付きでキャッシュに蓄積されます。このヘッダは、大抵、ウェブサーバが静的なコンテンツを提供する際に生成するものです。ユーザが先読みした文書を実際に訪問する際には、その文書の残りの部分を HTTP の byte-range リクエストを使って取得します

「イエス」であり、「ノー」でもあります。まず、Mozilla を使って何かをダウンロードしている場合は、全てのダウンロードが終わるまでリンクの先読み機能を遅らせます。例えば、ブックマーク・グループを読み込んでいる（複数のタブを開く）場合には、そのブックマークされたページで発生した先読みリクエストは、全てのタブがロードし終わるまで、開始されません。一方、別のアプリケーションがネットワークを使っている場合は、Mozilla のリンクの先読みはその他のアプリケーションと回線容量を奪い合います。将来的には、ネットワークのアイドル時間を監視するオペレーティングシステムのサービスを利用して、この問題を解決したいと思っています

先読みできるものに何か制限はありますか?

はい。https:// URL だけが先読み可能です（https:// URL はセキュリティ上の理由から先読みされません）。（FTP などの）その他のプロトコルはクライアントサイドのキャッシュへの対応が十分でありません。さらに、クエリ文字列付きの URLも先読みされません。なぜなら、このような URL の多くはブラウザのキャッシュを再利用しないような文書であるため、これらの先読みは大抵役に立たないからです。一連の文書群の中で次の文書を参照するために、<link rel="next"> タグにクエリ文字列付きの URL を使っている既存のサイトも現実にはあります。 Bugzilla はこのようなサイトの一例です。 Bugzilla のバグ報告などはキャッシュ可能でないため、これらの URL を先読みすると貧弱な Bugzilla の負荷を倍にしてしまうことになってしまいます! 他のサイトも Bugzilla と同様の設計になっていると容易に想像できますので、クエリ文字列付きの URL は先読みしないことにしました（ただし、rel=prefetch のリンク形式が指定されている文書は既存のコンテンツには存在しないと思われますので、これは先読みしてもよいかもしれません）。先読みされる URL にその他の制限はありません。

Mozilla は別のホストからも文書を先読みしますか?

はい。先読みには、 同一オリジン (same-origin) についての制限はありません。リンクの先読みを同一サーバの URL に限定したとしても、ブラウザのセキュリティ向上にはならないでしょうから。

先読みのリクエストには Referer: ヘッダが付きますか?

はい。先読みリクエストには、どの文書から先読みヒントを取ったかを示す、HTTP の Referer: ヘッダが付きます。

このことは、多くのサイトで広く行われている参照元の追跡に影響するかもしれません。このため、リンクの先読みは全てのコンテンツに対して向くものではないかもしれません。そこで、Cache-control: must-revalidate HTTP レスポンスヘッダを指定することにより、ユーザが先読みされた文書へのリンクを辿った際に、Mozilla にその先読みされた文書を検証させることができるようにしています。このヘッダが使われると、キャッシュは有効なままですが、ブラウザのキャッシュから文書を取り出す前には、If-Modified-Since もしくは If-None-Match の検証用リクエストが必要になります。

サーバ管理者ですが、先読みのリクエストを通常のリクエストと区別する方法はありますか?

はい。先読みのリクエストには、次のようなヘッダが付きます。

X-moz: prefetch

もちろん、このリクエストヘッダは全く標準化されていないものですので、将来の Mozilla リリースでは変更される可能性もあります。

はい。リンクの先読み機能を無効化できる隠し設定があります。 あなたのプロファイルディレクトリにある prefs.js ファイルに次の行を追加してください（もしくは、about:config 経由で変更してください）。

user_pref("network.prefetch-next",false);

しかし、リンクの先読み機能を無効にしたいという場合には、この先読みの実装に何か不具合があるのではないかと思います。我々としては、不具合がある場合には、ユーザに設定 UI の中から目立たない設定項目を探させて変更させるよりも、実装を改善したいと思っています。

ネットワーク回線容量の出費を byte 単位で行っている人たちについてはどうですか?

基本的には、この問題は二つの観点から見ることができます。

  1. ウェブサイトでは既に JavaScript や DOM といった技を使って、無断でダウンロードすることが色々と行われている。
  2. 先読みはブラウザの機能の一つであり、ユーザが簡単に無効化できるようにしておくべきだ。

まず、既存のウェブサイトにおいて、JavaScript や DOM の色々な技を使って黙ってダウンロードする手法を進めていく代わりに、<link> タグを使った手法を採用してもらうことが重要です。 <link> タグにより、ブラウザはサイトの進むべき方向を知ることができます。この情報を使うことによって、文書の先読みの優先順序をより良く付けることができます。 <link> タグによる先読みを無効化するユーザ設定を付けることは、単に JavaScript や DOM による技で我慢させることにつながり、ユーザにとって望ましくない結果になるかもしれません。先読み機能がデフォルトで有効なのは、このためです。

Mozilla 1.2 以降ベースおよび Mozilla 1.0.2 以降ベースのブラウザが先読み機能をサポートしています。これには Netscape 7.01 以降と Phoenix ビルドも含まれます。 2003年3月現在の Chimera ビルドは Mozilla 1.0.1 ベースですので、先読み機能に対応していません。あなたのブラウザがリンクの先読みをサポートしているかどうかテストしてください。

プライバシーとの関わり

参照元と URL の追跡との関係はすでに上記で説明されているとおりであり、先読みは一般的に先読みサイトの Cookie へのアクセスを引き起こします。（例えば、amazon をググるとき、google の結果ページは www.amazon.com 【訳注: google.co.jp で検索した場合は www.amazon.co.jp】 を先読みし、ブラウザに Cookie が送られてきます。 Firefox で サードパーティの Cookie をブロックするには、Disabling third party cookies を参照してください。）

他には...?

リンクの先読み機能について質問やコメントなどありましたら、私の方までお気軽にどうぞ。 :-)

参考...

Prefetching Hints

原文情報

  • 著者: Darin Fisher (darin at meer dot net)
  • 最終更新日: Updated: March 3, 2003

ドキュメントのタグと貢献者

タグ: 
 このページの貢献者: hamasaki, jigs12, ethertank, Marsf, Potappo, Kohei, Mgjbot, Taken, Shimono, Yama
 最終更新者: hamasaki,