私は実際に誰もがそれについて知っていると感じていますが、私はまだ伝えます。
一番下の行は、ブラウザがユーザーが次に開くページを教えてくれるということです-そして、彼は事前にそれをロードし始めます。
これは難しくありません-いくつかのメタタグを頭に追加するだけです：
<link rel="prefetch" href="NEXT PAGE URI" /> <link rel="prerender" href="NEXT PAGE URI" />
次に、制限とニュアンスについて詳しく説明します。
もちろん、最初に思い浮かぶのは、それがどこからでも遠く、常に適用できるわけではないということです。この奇妙な市民がどこへ行くかは必ずしも明確ではありません。
しかし、例えば複数ページの記事の場合、それはちょうどいいです。 または、前の投稿と次の投稿へのリンクがあるブログ投稿の場合。 または、登録ファネルの場合-一般的に、申請できるケースは多くあります。
第二に、FirefoxとChromeのみが現時点でこのようなフェイントをサポートしており、最初のものは長年にわたって存在しており、興味深いものです。 実際、最初の値relはFirefoxを認識し、2番目の値はChromeを認識します。 それらの間には違いがあり、Chromeではより詳細に実装されているという事実にあります。詳細は後で説明します。
ただし、プリフェッチオプションは、現在のWHATWGエディション（ www.whatwg.org/specs/web-apps/current-work/#link-type-prefetch）に既にあります。 これは、WHATWGが2つのオプションのうち最悪のものを選択したことを意味するものではありません-この属性の値の定義は非常に一般化され（「ブラウザーは指定されたコンテンツをキャッシュする必要があります」）、特定のブラウザーがChromeレベルまたはそれ以上で動作することを妨げるものは何もありません。
したがって、他のブラウザー、特にWebKitエンジンでサポートが表示されることを期待できます（これは既にGeckoベースのブラウザーに存在することを理解する必要がありますが、FFを除く人気のあるGeckoブラウザーはどこにありますか？）
第三に、ブラウザは現在のページ全体をロードした後にのみ何かのロードを開始することを理解することが重要です-さらに、FFはブラウザファイルのダウンロードと、おそらく他のタブのネットワークアクティビティの両方を考慮します。
ただし、Chromeは伝統的にこの問題に関してより攻撃的であり、早い段階で読み込みを開始できると思いますが、ろうそくを持っていませんでした。 誰かがその種類を正しく見ることができれば-確かに知ることは興味深いでしょう。
最後に、重要な注意事項について説明します。両方のブラウザで、これらのメタタグは動的に追加されたときに完全に正しく機能します。 そして、いくつかあるかもしれません。
実際、FirefoxでのプリフェッチとChromeでのプリレンダリングの違いは何ですか？
Chromeは、事前レンダリングの指示に応じて、非表示のタブを作成し、その中にすべてのスクリプト（実行するスクリプト）、画像などを含むページの読み込みを開始します。 ユーザーが実際に予測されたアドレスに移動すると、現在のタブはこの非表示のタブに置き換えられ、すでにロードされている（または少なくともロード中の）ページに表示されます。
Firefoxは指定されたページのhtmlをロードするだけで、すべての外部リソースは移行時にのみロードを開始します。 MDN [1]の公式FAQでこれを見つけませんでしたし、最初にそれを読んだ場所すら見つけませんでした-しかし、15番目のバージョンでのフィールド実験はそうだと言っているようです。
確かに、ここで予約する必要があります。ページのアドレスだけでなく、CSS、画像へのリンクもメタタグで指定できます。 そのため、新しいタグを作成することでFFのロードを増やすことができますが、これはエレガントさからはほど遠いものです。
ただし、Chromeのアプローチでは、特に誰もが無制限ではないことを覚えている場合、短所を見つけることもできますが、私にとってはよりきれいです。
どうやら、私には無制限があるからです:-)
この記事は2つのハブで執筆しています。そのうちの1つはSurfingbirdの企業ブログです。
それでは、私たちがそれをどのように使用したかについて-面白くなければ、スキップできます。
サイトを使用する主なモードは、ユーザーが私たちの推奨事項の1つから別の推奨事項に移動するとき（念のため、公式化する）サーフィンです。 彼はそれらをiframeの形で表示し、ブラウザウィンドウのほぼ全体を占めます。 その過程で、いいね、嫌いなものを入れ、他の方法で反応します-そしてその場で配信を再構築します。
そこで、「Surf」ボタン（実際には「Next！」のようなもの）をクリックしたときではなく、ドキュメントの準備に従ってすぐに次の推奨事項を要求することから始めました。 300。
また、次のページの完全なURLが応答で返されるため、受信したURLを使用してこれらのメタタグをその場で生成し始め、さらに保存します。
カテゴリ、ドメイン、リンク作成者の制限など、サーフィン中にユーザーが設定を設定できる最後のニュアンスが残っています。もちろん、設定が変更されていない場合にのみ事前に受け取った推奨事項を使用することが重要です。 ただし、これはほとんどの場合に見られます。
Chromeで視覚的に見ると、現在のページに数秒間留まると、すぐに次のページが開きます。 効果は素晴らしいです-彼らがチェックしたとき、彼らは子供のように喜びました。
こちらでChromeでITが機能することを確認できます-chrome：// net-internals /＃prerender、残念ながらFFについては説明しません。
これは統計に影響を及ぼし、プライバシーを侵害する可能性さえあるという発言を予見します（もちろんsurfingbird.ruの場合ではなく、一般的に-邪悪な人々があなたのブラウザに児童ポルノのページをロードするように指示し、あなたのIPがログ）、トラフィック、および何か他のものを増やします。
一方では、FFはプリフェッチ時にFFが特別なヘッダーを送信するという質問に答えることができますが、ChromeはPage Visibility APIの使用を提案し、悪人は他の多くの方法で嫌なことをします。
一方、私は個人的にこれを深刻な問題とは考えていません。 利点は私にとってはるかに重要なようです。
[1] developer.mozilla.org/en-US/docs/Link_prefetching_FAQ
[2] www.chromium.org/developers/design-documents/prerender