JP6568985B2 - バッチ最適化レンダリング及びフェッチアーキテクチャ - Google Patents

Description

本発明は、バッチ最適化レンダリング及びフェッチアーキテクチャに関する。

ワールドワイドウェブは、情報が豊富である。今日では、1兆以上のユニークなウェブページがあると推定されている。これらのページの多くは、例えばNew York Timesのホームページなどに動的に作成され、レンダリングされたウェブページのコンテンツや外観に効果を与えることができる、画像やビデオのような埋め込みコンテンツへのリンクを有する。例えば、ブラウザがJavaScript（登録商標、以下同じ）コードのようなスクリプトを実行するとき、これはブラウザがウェブページのレンダリングを完了した後に、ウェブページがユーザに対してどのように見えるかに影響を与え、ページのコンテンツ及び／又は外観を変更することができる。別の例として、いくつかのウェブページは、テキストの見た目を変える方法をブラウザに指示するスタイルシートを使用する。典型的なウェブページは、そのような追加の埋め込みアイテムのハンドラを有することができ、そのいくつかはブラウザレンダリングエンジンのために特別に設計されるか、あるいはブラウザレンダリングエンジンに向けられている。レンダリングプロセスによって生成された追加の情報は、インターネット検索エンジンのような、ダウンストリームシステムに役立つことができる。単一のユーザのウェブブラウザのために、リアルタイムで単一のウェブページをレンダリングすることは比較的容易であるが、ましてやワールドワイドウェブ上の全てのページ（1兆ページ）のように多数のページをレンダリングすること、あるいはワールドワイドウェブ（100億ページ）上の上位1％だけをリアルタイムでレンダリングすることは難しい。

実施形態は、ウェブページインデックスシステムのような、ダウンストリームユーザのためのウェブページのバッチレンダリングのために最適化されたレンダリングサーバおよびフェッチサーバを含む。ダウンストリームユーザは、１つまたは複数の埋め込みアイテムを有するウェブページ（例えば、そのＵＲＬを使用して）を識別するとき、ダウンストリームユーザはレンダリングサーバがレンダリング結果を生成するためにＵＲＬをレンダリングすることを要求してもよい。レンダリングサーバは、多数の（例えば、何万もの）レンダリングエンジンを含むことができる。各レンダリングエンジンは、多くのレンダリングエラーを排除するバッチレンダリングのために最適化されたブラウザカーネルをシミュレートする。レンダリングの間、レンダリングエンジンは埋め込みアイテムを発見すると、レンダリングエンジンはフェッチサーバから埋め込みアイテムを要求する。フェッチサーバは、各埋め込みアイテム（例えば、そのＵＲＬ）のための識別子と、ウェブクローラ（web-crawler）によって検索されたアイテムのためのコンテンツとによって適合された埋め込みアイテムのデータストアを含む。埋め込みアイテムのためのデータストアを探す前に、フェッチサーバは書き換え規則を使用してＵＲＬを書き換えてもよい。ＵＲのためのコンテンツが別の埋め込みアイテム（例えば、リダイレクトＵＲＬによって表される）と重複しているとき、書き換え規則は、ＵＲＬをリダイレクトＵＲＬと置き換えてもよい。要求された埋め込みアイテムが重複している場合、フェッチサーバは、リダイレクトＵＲを使用するようにＵＲＬを書き換えてもよく、これは要求されたＵＲＬのためのコンテンツをフェッチする代わりに、リダイレクトＵＲＬのための既に検索されたコンテンツを使用できるようにする。このような重複排除方法は、フェッチサーバによって作られるクロール要求の実際の数を劇的に減少することができ、レンダリングエンジンの応答時間を向上することができる。書き換え規則は、ＵＲＬがブラックリストに載せられていることを示してもよい。いくつかの実施形態において、フェッチサーバは、埋め込まれた画像の実際のコンテンツではなく、サイズを格納してもよい。レンダリングエンジンが画像を要求したとき、フェッチサーバが画像のサイズを有するモック画像を生成し、モック画像をレンダリングエンジンに返してもよい。レンダリングエンジンがウェブページのレンダリングを完了しているとき、レンダリング結果をウェブページの処理を向上するためにレンダリング結果の情報を使用することができる、インデックスエンジンのようなダウンストリームユーザに提供してもよい。

１つの態様において、コンピュータシステムは、少なくとも１つのプロセッサと、メモリと、を含むコンピュータシステムであって、メモリが、埋め込みアイテムのためのコンテンツのデータストアと、少なくとも１つのプロセッサによって実行されたときにシステムに動作を行わせる命令を格納する。該動作は、バッチプロセスから、ウェブページをレンダリングするための要求を受信することと、ウェブページの埋め込みアイテムを識別することと、を含む。該動作は、書き換え規則に基づいて、前記埋め込みアイテムが以前にフェッチされた埋め込みアイテムのためのコンテンツの重複であるコンテンツを有すると判定することと、判定に応答して、データストアから前記以前にフェッチされた埋め込みアイテムのための前記コンテンツを提供することと、以前にフェッチされた埋め込みアイテムのための前記コンテンツを使用して、前記ウェブページについてのレンダリング結果を生成することと、およびバッチプロセスにレンダリング結果を提供することと、も含む。

本明細書に記載される主題の１つ又は複数の実施形態は、以下の特徴の内の１つ又は複数を含むことができる。例えば、埋め込みアイテムが以前にフェッチされた埋め込みアイテムのためのコンテンツの重複であるコンテンツを有すると判断することは、書き換え規則のテンプレートに前記埋め込みアイテムを照合させることを含み、書き換え規則がリダイレクト識別子を含むことができる。このような実施形態において、以前にフェッチされた埋め込みアイテムのための前記コンテンツを提供することが、以前にフェッチされた埋め込みアイテムのための前記コンテンツ及び／又はクエリ文字列なしでURLを含んでもよいテンプレートを示すための前記リダイレクト識別子を使用することを含む。

他の例として、埋め込みアイテムは、第1の埋め込みアイテムであり、かつ動作がウェブページの第2の埋め込みアイテムを識別することを含んでもよく、前記第2の埋め込みアイテムがブラックリストに載せられているか否かを判断し、第2の埋め込みアイテムが第2の埋め込みアイテムのためのフェッチコンテンツなしでブラックリストに載せられているとき、エラーを返し、および第2の埋め込みアイテムのためのコンテンツなしでレンダリング結果を生成することを含んでもよい。別の例として、レンダリング結果を生成するとき、動作が仮想時計の使用を含んでもよく、仮想時計はリアルタイムとは無関係に進む。別の例において、レンダリング結果を生成するとき、動作が仮想時計の使用を含んでもよく、仮想時計が以前にフェッチされた埋め込みアイテムの提供されたコンテンツを待つ間に進行しない。

他の例として、埋め込みアイテムは第１の埋め込みアイテムであってもよく、動作がウェブページの第２の埋め込みアイテムを識別することと、第２の埋め込みアイテムが画像を含むことを判断することと、サイズテーブルを使用して、第２の埋め込みアイテムのためのサイズを指定するモック画像を生成することと、レンダリング結果を生成するときにモック画像を使用することと、を含んでもよい。

別の態様において、コンピュータ実装された方法は、ウェブページをレンダリングするための要求をバッチプロセスから受信するステップと、仮想時計とウェブページをレンダリングするためのタスクリストを初期化するステップであって、仮想時計が、埋め込みアイテムのための要求が未処理であるときかつタスクが準備完了であるとき、依然として停止している、初期化するステップと、を含む。該方法はまた、仮想時計がタスクリストの停止タスクのためのランタイムに一致するとき、ウェブページのためのレンダリング結果を生成するステップと、バッチプロセスのためのレンダリング結果を生成するステップと、を含む。

本明細書に記載される主題の１つ又は複数の実施形態は、以下の特徴の内の１つ又は複数を含むことができる。例えば、タスクリストを初期化するステップが、ランタイムセットを備えた停止タスクを仮想時計に追加された所定の時間に追加するステップを含んでもよい。所定の時間は少なくとも５秒であってもよい。別の例として、該方法は、埋め込みアイテムに対する要求が未処理ではない、かつ仮想時計よりも大きいランタイムを有するただ一つのタスクがタスクリストにあるとき、仮想時計をタスクリスト内のタスクのランタイムに進めるステップをさらに含んでもよい。別の例として、該方法は、ウェブページの埋め込み画像を識別するステップと、埋め込み画像のためのコンテンツを要求するステップと、要求に応答して、埋め込み画像のためにサイズを指定するが、空のコンテンツを有するモック画像を受信するステップと、レンダリング結果を生成するときにモック画像を使用するステップと、を含んでもよい。別の例として、バッチプロセスは、インデックスエンジンであってもよく、かつ該方法は、レンダリング結果の情報に基づいて、ウェブページのためのランクを降格させるステップをさらに含み、及び／又は動的に生成されたコンテンツにインデックスを付けるためにレンダリング結果を使用するステップをさらに含む。

別の態様において、方法は、ウェブページ内の埋め込みアイテムのユニフォームリソースロケータ（ＵＲＬ）のためのバッチレンダリングプロセスから要求を受信するステップと、書き換えられたＵＲＬを判断する書き換え規則を適用するステップを含む。該方法は、書き換えられたＵＲＬのためのコンテンツがデータストアに存在するか否かを判断するステップと、コンテンツが存在するとき、コンテンツを前記バッチレンダリングプロセスに提供するステップを含んでもよい。コンテンツが存在しないとき、該方法は、コンテンツのフェッチを初期化し、ここでバッチレンダリングプロセスがフェッチの間にタイムアウトなしで待機するように構成される、初期化するステップと、ウェブ巡回エンジンからコンテンツを受信するステップと、バッチレンダリングプロセスのためのコンテンツを提供するステップと、データストアのコンテンツを保存するステップを含んでもよい。コンテンツは、ウェブページのレンダリング結果をウェイ請求項するためにバッチレンダリングプロセスによって使用されてもよい。

本明細書に記載される主題の１つ又は複数の実施形態は、以下の特徴の内の１つ又は複数を含むことができる。例えば、書き換え規則を適用するステップは、ＵＲＬをリダイレクトＵＲＬと関連しているテンプレートに照合させるステップを含んでもよく、ここでＵＲＬがテンプレートに一致するとき、前記リダイレクトＵＲＬが、書き換えられたＵＲＬであると判断され、およびＵＲＬがテンプレートに一致しないとき、ＵＲＬが書き換えられたＵＲＬであると判断される。別の例として、該方法は、変更率またはデータストアに保存された埋め込みアイテムのタイプに基づいて、書き換えられたＵＲＬのための前記コンテンツが古いと判断するステップと、書き換えられたＵＲＬのためのコンテンツが古いと判断するステップに応答して、ウェブ巡回エンジンから更新されたコンテンツを受信するステップと、更新されたコンテンツを備えたデータストアを更新するステップと、書き換えられたＵＲＬのためのコンテンツとして、更新されたコンテンツを提供するステップを含んでもよい。

別の態様として、コンピュータシステムは、少なくとも１つのプロセッサと、画像識別によって格納されたサイズのテーブルおよび少なくとも１つのプロセッサによって実行されたときにシステムに動作を行わせる命令を保存するメモリと、含む。該動作は、ウェブページの埋め込みアイテムを識別することと、サイズのテーブルから埋め込み画像のためのサイズを判断し、サイズを使用してモック画像を生成することと、を含むことができる。該動作は、モック画像を使用してウェブページのためのレンダリング結果を生成することを含んでもよい。

別の態様として、コンピュータ実装された方法は、ウェブページをレンダリングするための要求をバッチプロセスから受信するステップと、ウェブページの少なくとも１つの埋め込み画像を識別するステップと、を含む。該方法は、フェッチサーバからモック画像を受信するステップと、モック画像を使用してウェブページのためのレンダリング結果をレンダリングするステップも含み、モック画像は埋め込み画像のサイズと空のコンテンツを有する。いくつかの実施形態において、該方法は、レンダリング結果をウェブページを要求したバッチプロセスに提供してもよい。

別の態様において、非一時的コンピュータ可読媒体は、コンピュータシステムに１つ又は複数の上述した方法を実行させる、回路基板に形成された少なくとも１つのプロセッサによって実行可能な命令を含んでもよい。

本明細書に記載される主題の１つまたは複数の実施形態は、１つまたは複数の以下の利点を実現するように実装されることができる。一例として、バッチレンダリングエンジンが入力デバイス（例えば、キーボード、マウス）あるいは出力デバイス（例えば、ディスプレイ、タッチスクリーンなど）に結合されていないため、レンダリングエンジンは、例えばユーザフレンドリーなＡＰＩではなくマシンフレンドリーなＡＰＩを有する、実際のブラウザレンダラ（browser renderer）よりも簡素で洗練されたものにすることができる。また、レンダリングエンジンは、レンダリングされた最終ページを表示する、あるいはユーザと対話する必要がないので、レンダリングエンジンは、実際の時間ではなく終了したタスクに基づいて進む仮想時計を使用することができ、これはレンダリングプロセスの処理速度を上げ、および一般的なエラーを避けることができる。例えば、バッチ環境でのフェッチは、個人のウェブ環境よりもはるかに遅くなることがあり、多くのタイムアウトエラーを引き起こす可能性がある。仮想時計は、フェッチ待ち時間を隠し、タイムアウトエラーを回避する。仮想時計は、より確定的な結果も可能にする。例えば、日付/時刻コンポーネントを含むＵＲＬにおいて、日付/時刻コンポーネントを固定された時間に置き換えるのではなく、システムは仮想時計の値を使用してもよい。これは、ウェブページのすべての時間パラメータが同じ値を有するわけではないが、ウェブページがレンダリングされるたびに特定の時間パラメータが同じ値を有することを意味する。この柔軟性は、システムが時間を進めることを可能にし、これはレンダリングされた結果の正確性のためにいくつかのウェブページにおいて重要であるが、要求された一連のＵＲＬがレンダリング全体で同じまままであることが常に保証される（クロール要求を少なくする）。システムは、例えばブラックリストに載せられたアイテムのような不要なアイテムをフェッチすることを回避してもよい。画像の実際のコンテンツではなく、画像のためのサイズを保存することは、フェッチサーバにおいて画像のためのストレージ要件を削減し、レンダリングエンジンに転送されるデータが少なくて済み、およびレンダリングエンジンでレンダリング時間がさらに向上する。ＵＲＬを書き換えることは、重複したコンテンツをフェッチすることを回避し、バッチレンダリングプロセスをさらに高速にする。

開示された主題に従ったシステム例を図示する。 埋め込みアイテムを有するウェブページのブロック図である。 実施形態に従った、バッチレンダリングエンジンのブロック図である。 実施形態に従った、バッチレンダリングエンジンが、埋め込みオブジェクトを備えたウェブページをレンダリングすることができるプロセス例を図示する流れ図である。 実施形態に従った、バッチレンダリングエンジンが、仮想時計を進めるプロセス例を図示する流れ図である。 実施形態に従った、フェッチサーバが埋め込みアイテムのためのコンテンツをバッチレンダリングエンジンに提供するプロセス例を図示する流れ図である。 実施形態に従った、フェッチサーバがモック画像をバッチレンダリングエンジンに提供するプロセス例を図示する流れ図である。 開示した技術を実装するために使用されることができるコンピュータデバイスの例を示す。 開示した技術を実装するために使用されることができる分散型コンピュータデバイスの例を示す。

ウェブページを完全にレンダリングするために、ウェブページの全ての埋め込み外部リソースのコンテンツを最初に取得する必要がある。そのようなリソースは、外部画像、JavaScriptコード、およびスタイルシートを含むが、これらに限定はしない。しばしば、同じ外部リソースが多くの異なるウェブページに埋め込まれている。単一のユーザのウェブブラウザがGoogle Analytics JavaScriptコードのような外部ウェブページリソースをリアルタイム（すなわち、リソースが埋め込まれたウェブページがレンダリングされたとき）で要求することは効率的であるが、バッチレンダリングエンジンがそうすることは実現可能でも効率的でもない。例えば、ウェブページインデックスプロセスのためのバッチレンダリングエンジンは、効率的かつ迅速に、一度に多数のウェブページを素早くレンダリングするように設計されている。しかし、埋め込み外部リソースをフェッチすることは、遅くなる可能性があり、そのようなリソースはバッチ処理の目的（例えば、人間のユーザが最終的にレンダリングされた製品を見ることなしに）のために重要ではないことがある。バッチ環境においてウェブページをレンダリングする処理時間を改善するために、レンダリングエンジンは、仮想時計を使用して動作し、重複および不要なフェッチを避けるためにフェッチサーバと連動し、および視覚の処理あるいはウェブページにおける他のユーザ指向の要素を最小限にしてもよい。

図１は、実施形態例に従ったシステムのブロック図である。システム１００は、要求プロセスのためにバッチモードでウェブページを効率よく迅速にレンダリングするために使用されてもよい。システム１００に図示される要求プロセスは、インターネット検索エンジンのためのインデックスエンジンであるが、実装はレンダリングされたウェブページのダウンストリームユーザとしてのインデックスエンジンに限定しない。例えば、要求プロセスは、ページを分析して遅さを障害追跡する分析エンジンであってもよく、あるいはGoogle Analyticsのようなツールが正しくセットアップされているかを判断する分析エンジンであってもよく、または広告システム、または複雑なウェブページとの、例えばフォームの記入や要素のクリックなどの自動対話に依存する別のシステムであってもよい。したがって、システム１００は、インデキシングのためにバッチ生成されたレンダリング結果を使用するものとして説明されてもよく、システム１００は、レンダリング結果で提供される情報が有用である他のバッチシステムのために使用されることができる。

システム１００は、コンピューティングデバイスであってもよく、あるいは多くの異なるデバイスの形を有するデバイスであってもよい。例えば、システム１００は、巣単打オードサーバ、そのようなサーバのグループ、クライアントサーバシステム、あるいはラックサーバシステムであってもよい。さらに、システム１００は、パーソナルコンピュータで実装されてもよい。システム１００は、図８で図示するような、コンピュータデバイスの例８００、あるいは図９で図示するようなコンピュータデバイス９００であってもよい。

システム１００は、ウェブ巡回エンジン１３０、インデックスエンジン１１０のような要求プロセス、レンダリングサーバ１４０、およびフェッチサーバ１５０を含む。ウェブ巡回エンジン１３０、レンダリングサーバ１４０、およびフェッチサーバ１５０は、ワールドワイドウェブ上に見られるウェブページのような多数のウェブページを効率的にレンダリングするためにともに動作してもよい。

インデックスエンジン１００は、インデックス１１５を作成するために、１つまたは複数の機械実行可能な命令またはソフトウェアの一部、ファームウェア、またはそれらの組合せを実行するように構成された１つ又は複数のプロセッサを含むことができる。たとえば、インデックスエンジン１１０は、ウェブ巡回エンジン１３０を介してサーバから情報を受信してもよい。インデックスエンジン１１０は、インデックス１１５を生成するために受信したウェブページのコンテンツを処理してもよい。サーバ１９０は、１つまたは複数のウェブページまたは１つ又は複数のウェブページに埋め込まれたリソースをホストするインターネットを介してアクセス可能な任意のタイプのコンピューティングデバイスであってもよい。巡回エンジン１３０によってアクセスされるウェブページは、スタイルシート、Java Script、画像などの埋め込みアイテムを含んでもよく、そのうちのいくつかは、レンダリングされたウェブページのコンテンツおよびレイアウトを変更してもよい。インデックスエンジン１１０は、巡回エンジン１３０を介して提供されたものにインデックス付けができるが。インデックスエンジンは、レンダリングサーバ１４０に、レイアウト情報およびインデックスエンジン１１０にそれ以外は利用できない動的コンテンツを含むブラウザレンダリングされたウェブページのレンダリング結果を提供するように要求することができる。インデックスエンジン１１０は、インデックス１１５のドキュメントについて利用可能な情報を向上するためにレンダリング結果コンテンツを使用することができる。例えば、インデックスエンジン１１０は、ウェブページの画像のテキストの位置あるいはサイズに基づいて、ウェブページのテキスト要素のランクを変更してもよい。例として、一大ニュースを表すテキスト（例えば、スクロールなしで見ることができる）は、広告のテキストよりもより重要であると考えられ得る。別の例として、広告内のテキストは、ウェブページにとってあまり重要ではないと考えられ得る。さらに、いくつかのコンテンツが動的に生成されるとき、例えばウェブページがレンダリングされるまで利用可能でないとき、インデックスエンジン１１０は、レンダリング結果を動的に生成されたコンテンツをインデックス付けするために使用してもよい。簡潔にするために図１には示されていないが、いくつかの実施形態において、インデックスエンジン１１０は、１つまたは複数の別個のコンピューティングデバイスに分散されてもよい。

インデックスエンジン１１０と同様に、クエリエンジン１２０は、例えば従来または別の情報検索技術を使用して、クエリ１８２の検索結果を識別するためにインデックス１１５を使用する１つ又は複数のサーバを含んでもよい。クエリエンジン１２０は、クライアント１８０のようなリクエスタからクエリ１８２を受信する１つまたは複数のサーバを含んでもよい。クエリエンジン１２０は、インデックス１１５を使用して、クエリに応答してドキュメントを識別してもよく、および検索結果１８４として応答ドキュメントからの情報をリクエスタに提供してもよい。いくつかの実施形態において、クエリエンジン１２０は、検索結果１８４の一部としてサムネイルを提供するために、レンダリング結果データストア１４８のレンダリング結果を使用してもよい。クエリエンジン１２０は、例えば、１つまたは複数のランク付け信号を使用して、クエリに応答してドキュメントのためのスコアを計算するランク付けエンジンを含んでもよい。１つまたは複数のランク付け信号は、ドキュメントに関連するレンダリング結果から取得されたコンテンツに基づくことができる。ランク付けエンジンは、スコアを使用してクエリに応答して見つかったドキュメントをランク付けしてもよい。

システムは、ウェブ巡回エンジン１３０を含んでもよい。ウェブ巡回エンジン１３０は、１つまたは複数の機械実行可能命令あるいはソフトウェアの一部、ファームウェア、あるいはそれらの組合せを実行するように構成された１つ又は複数のプロセッサを含むことができる。ウェブ巡回エンジン１３０は、標準サーバ、そのようなサーバのグループ、クライアントサーバシステム、あるいはラックサーバシステムのようなコンピューティングデバイスであってもよい。いくつかの実施形態において、ウェブ巡回エンジン１３０は、フェッチサーバ１５０またはインデックスエンジン１１０のようなシステム１００の別のコンポーネントと、メモリまたはハードウェアプロセッサのようなコンポーネントを共有してもよい。ウェブ巡回エンジン１３０は、ワールドワイドウェブ上で見つけられることができるウェブページをクロールしてもよい。ウェブ巡回エンジン１３０は、クロールされたウェブページを受信したとき、すなわち、クロールされたウェブページのためのコンテンツを受信すると、ウェブ巡回エンジン１３０は、インデックスエンジン１１０あるいはフェッチサーバ１５０であってもよいリクエスタにコンテンツを提供してもよい。ウェブ巡回エンジン１３０は、データストア（図示せず）にコンテンツを格納し、およびリクエスタにその位置を提供してもよい。本明細書で使用されるウェブページのコンテンツは、ウェブページレンダリングエンジンに提供されかつウェブブラウザに表示するためのウェブページをレンダリングするために使用されるHTMLコードを参照し、例えばスタイルシート、Java Script、別のウェブページ、あるいは画像ファイルなどのウェブページに埋め込まれた外部オブジェクトへの任意のリンクを含む。ウェブ巡回エンジン１３０は、これらの埋め込みアイテムのコンテンツをフェッチするためにフェッチサーバ１５０によって使用されてもよい。ウェブ巡回エンジン１３０は、フェッチサーバ１５０に埋め込みアイテムのコンテンツを提供してもよく、あるいは埋め込みアイテムテーブル１５２のようなデータストアにフェッチされたコンテンツを格納してもよい。ウェブ巡回エンジン１３０は、埋め込みアイテムがクロールされたときにリクエスタに通知してもよい。

前述したように、システム１００は、フェッチサーバ１５０を含む。フェッチサーバ１５０は、１つまたは複数の機械実行可能な命令またはソフトウェアの一部、ファームウェア、あるいはそれらの組合せを実行するように構成された１つまたは複数のプロセッサを含むことができる。フェッチサーバ１５０は、標準サーバ、そのようなサーバのグループ、クライアントサーバシステム、あるいはラックサーバシステムのようなコンピューティングデバイスであってもよい。いくつかの実施形態において、フェッチサーバ１５０は、レンダリングサーバ１４０、ウェブ巡回エンジン１３０、またはインデックスエンジン１１０のようなシステム１００の別のコンポーネントと、メモリまたはハードウェアプロセッサのようなコンポーネントを共有してもよい。フェエッチサーバ１５０は、ウェブ巡回エンジン１３０が特定の埋め込みアイテムのコンテンツを、例えばそのURLによってフェッチすることを要求し、要求された埋め込みアイテムのフェッチされたコンテンツとクロール時間を受信するように構成される。フェッチサーバ１５０は、ウェブ巡回エンジン１３０から直接、またはウェブ巡回エンジンが更新する埋め込みアイテムテーブル１５２から、コンテンツとフェッチ時間を受信してもよい。フェッチサーバ１５０は、レンダリングエンジン１４２から埋め込みアイテムのための要求を受信してもよい。フェッチサーバ１５０は、要求しているレンダリングエンジン１４２に応答を提供してもよい。応答は、埋め込みアイテムテーブル１５２にフェッチされた、または格納されたコンテンツ、画像寸法テーブル１５６に基づくモック画像、あるいはエラー応答を含んでもよい。いくつかの実施形態において、フェッチサーバ１５０は、埋め込みアイテムのコンテンツおよびクロール時間を、埋め込みアイテムを要求したレンダリングサーバ１４０のレンダリングエンジン１４２に送信することによって、埋め込みアイテムのコンテンツを提供することができる。あるいは、フェッチサーバ１５０は、埋め込みアイテムテーブル１５２の指定の位置を介して埋め込みアイテムのコンテンツおよびクロール時間が利用可能であることをレンダリングエンジン１４２に通知することによってコンテンツを提供することができ、およびレンダリングエンジン１４２は、データストアからウェブページのコンテンツおよびクロール時間を取得することができる。

フェッチサーバ１５０は、要求された埋め込みアイテム（例えば、要求されたURL）にURL書き換え規則１５４を適用してもよい。URL書き換え規則１５４は、URLが別のURLと同一のコンテンツに関連付けられているとき、URLを書き換えるための規則を含む。これは、ウェブサイトの所有者が、リソースがリクエストされる度にコンテンツをダウンロードすることをブラウザに望み、そのために動的に生成されたURLあるいはキャッシュバスティング（cache-busting）URLを提供する場合によく発生する。このようなURLは、URLの一部としてタイムスタンプまたは埋め込まれたランダム文字列を有することが多く、例えば、キャッシュバスティングURLを生成するJavaScriptによってウェブページがレンダリングされる度に、URLが一意になるようにする。しかしながら、ホスティングサーバから提供された動的に生成されたURLのためのコンテンツは、変更されない、あるいはバッチレンダリングの目的で意味のある方法で変更されない。フェッチサーバ１５０は、埋め込みアイテムに対する要求により効率的に応答するためにURL書き換え規則１５４を使用してもよい。例えば、URL書き換え規則１５４は、パターンまたはテンプレートを含んでもよく、および規則のテンプレートに一致するURLは、同一のコンテンツ、例えば重複コンテンツを返す。いくつかの実施形態において、テンプレートは、オフライン、またはフェッチログを使用して様々なURLのコンテンツを比較し重複コンテンツを有するURLに共通のURLのパターンを識別するバッチプロセスによって、決定されてもよい。フェッチログは、例えばウェブ巡回エンジン１３０またはフェッチサーバ１５０によって維持されてもよい。テンプレートは、ユーザ入力であってもよい。要求された埋め込みアイテムがテンプレートのうちの一つに一致するURLを有する場合、URL書き換え規則１５４は、フェッチサーバ１５０に要求されたアイテムが重複であることを伝えてもよく、要求されたURLをリダイレクトURLで書き換えるように命令してもよい。これは、以前にフェッチされたコンテンツ、例えば埋め込みアイテムテーブル１５２のコンテンツを有するURLと関連する。以前にフェッチされた埋め込みアイテムのURLは、リダイレクトURLと見なされてもよい。これは、フェッチサーバが１５０が、必要のないフェッチを避けることを可能にし、要求しているバッチレンダリングエンジン１４２への応答を迅速化し、過度のフェッチ要求によって引き起こされるホスティングサーバへのストレスを取り除く。もちろん、要求されたURLがURL書き換え規則１５４のテンプレートに一致しない場合、URLを書き換えることは、要求されたURLは変更されない結果となる。

URL書き換え規則１５４は、ブラックリストに載せられたURLのパターンあるいはテンプレートを含んでもよい。要求された埋め込みアイテムがフラックリストに載せられたURLパターンと一致する場合、システムは、URLのためのコンテンツをフェッチしようとするのではなく、所定のエラーを返してもよい。ブラックリストに載せられたURLは、コンテンツがバッチレンダリングの目的のために必要とされないことを決定したあとに、ユーザによってURL書き換え規則１５４にURLを入力されてもよい。この一例は、多くのウェブページに含まれるGoogle Analytics JavaScriptコードである。このJavaScriptコードは、レンダリングされたページのレイアウトに重要であると見なされなくともよく、バッチレンダリングエンジンの目的のために実行される必要はない。したがって、レンダリング効率のために、いくつかの埋め込みアイテムはURL書き換え規則１５４を使用してブラックリストに載せられてもよい。いくつかの実施形態において、ブラックリストに載せられたURLのためのエラーを返すのではなく、システムは、期限切れにならない、および埋め込みアイテムに適した所定のコンテンツを有する埋め込みアイテムテーブル１５２のエントリに、上述したリダイレクトURLを使用してURLを書き換えてもよい。いくつかの実施形態において、URL書き換え規則は、テンプレートに一致するときブラックリストに載せられたものとしてURLにフラグを立ててもよい。URL書き換え規則１５４は、ウェブ巡回エンジン１３０を介してフェッチされた埋め込みアイテムの数を劇的に減少することができ、フェッチサーバ１５０のリソースのための任意の要求への応答時間を改善し、特定のサーバ１９０のフェッチ量を最小限にする。フェッチ量を最小限にすることは、システムがフェッチ要求でサーバ１９０に負担をかけないことを保証する。いくつかの実施形態において、フェッチサーバ１５０及び／又はウェブ巡回エンジン１３０は、サーバ１９０に向けられたフェッチ要求の数を制限するように構成されてもよく、要求が制限を超える場合、システムは要求をキューに入れ始めてもよい。キューが大きすぎる場合、システムはフェッチ要求を失敗する可能性がある。従って、URL書き換え規則１５４はまた、フェッチ量を最小化することができる。

いくつかの実施形態において、フェッチサーバ１５０は画像寸法テーブル１５６を含んでもよい。画像寸法テーブル１５６は、画像URLを画像のための既知のサイズと関連付けるキー値記憶装置であってもよい。既知のサイズは、画像がフェッチされたときに決定されてもよい。要求された画像のサイズを使用して、フェッチサーバ１５０は要求された画像と同じサイズを有するが、空のコンテンツであるか、コンテンツとして単純なタイルを有するモック画像を生成してもよい。モック画像は、要求された画像と同じサイズを有するが同じ画像データではない、有効な画像である。フェッチサーバ１５０はバッチレンダリングエンジンのためのコンテンツをフェッチするので、実際の画像はレンダリング結果にとって重要ではなくてもよいが、画像のサイズはレンダリングされたページのレイアウトに影響を及ぼし得る。実際の画像ではなくモック画像を使用することは、ファイルサイズが非常に小さくなり（例えば、画像あたり数十バイト）、これはモック画像を転送する際のネットワーク帯域幅、およびバッチレンダリングエンジンのためのプロセッサおよびメモリリソースを節約する。いくつかの実施形態において、画像寸法テーブル１５６は、SSTableなどのキー値記憶装置であってもよいが、寸法テーブル１５６は、画像識別子によってサイズを格納する任意のデータ構造体であってもよい。

システム１００は埋め込みアイテムテーブル１５２を含んでもよい。埋め込みアイテムテーブル１５２ｈ、URLによってキー付されてもよく、およびウェブ巡回エンジン１３０から返された埋め込みアイテムのためのフェッチされたコンテンツを格納してもよい。いくつかの実施形態において、埋め込みアイテムテーブル１５２は、クロール履歴も格納してもよい。例えば、いくつかの実施形態において、埋め込みアイテムテーブル１５２は、例えば７日間、２週間などの期間にわたってフェッチされたコンテンツを含んでもよい。埋め込みアイテムテーブル１５２は、クロール履歴に基づいて変更率を含んでもよい。いくつかの実施形態において、埋め込みアイテムテーブル１５２は、BigTable、関係型データベース、Hadoop Distributed Fileなどとして実装されてもよい。フェッチサーバ１５０は、以前にフェッチされた埋め込みアイテムのためのコンテンツを素早く返すために、埋め込みアイテムテーブル１５２を使用してもよい。フェッチサーバ１５０は、何千ものバッチレンダリングシステムに対する要求を処理することができるので、要求された埋め込みアイテムが前のフェッチ要求に応答して以前にフェッチされている可能性が高い。フェッチされたコンテンツが埋め込みアイテムテーブル１５２に位置するとき、ウェブ巡回エンジン１３０にコンテンツを提供するように求めるのではなく、フェッチサーバ１５０は埋め込みアイテムテーブル１５２のコンテンツを使用して要求に応答してもよい。これにより、フェッチされたコンテンツを格納するサーバ１９０の負担が軽減され、フェッチサーバ１５０が埋め込みアイテムのための要求により迅速に応答することを可能にする。フェッチサーバ１５０は、URL書き換え規則１５４を使用して、重複を排除するURLによってクロール要求をさらに減らすことができる。

レンダリングプロセスの任意の段階で、１つ又は複数の要求された埋め込みアイテムのコンテンツが埋め込みアイテムテーブル１５２に格納されていない、あるいは古い場合、フェッチサーバ１５０は、要求された埋め込みアイテムのクロールをスケジュールするためにウェブ巡回エンジン１３０に指示してもよい。一旦ウェブ巡回エンジン１３０がレンダリングされた埋め込みアイテムをクロールすると、フェッチサーバ１５０に通知する。フェッチサーバ１５０は、次いでフェッチされたコンテンツアイテムをクロール時間とともに埋め込みアイテムテーブル１５２に格納してもよい。埋め込みアイテムが画像である場合、フェッチサーバ１５０は、代わりに、または追加で、フェッチされた画像のサイズをクロール時間とともに画像寸法テーブル１５６に格納してもよい。フェッチサーバ１５０は、次いで要求されたコンテンツを、すなわち画像サイズを有するモック画像が送信されてもよい画像ファイルの代わりに、要求しているレンダリングエンジン１４２に送り返してもよい。

システム１００は、レンダリングサーバ１４０を含む。レンダリングサーバ１４０は、１つまたは複数の機械実行可能な命令またはソフトウェアの一部、ファームウェア、あるいはそれらの組合せを実行するように構成された１つまたは複数のプロセッサを含むことができる。レンダリングサーバ１４０は、標準サーバ、そのようなサーバのグループ、クライアントサーバシステム、あるいはラックサーバシステムのようなコンピューティングデバイスであってもよい。いくつかの実施形態において、レンダリングサーバ１４０は、レンダリングサーバ１４０、フェッチサーバ１５０、またはインデックスエンジン１１０のようなシステム１００の別のコンポーネントと、メモリまたはハードウェアプロセッサのようなコンポーネントを共有してもよい。レンダリングサーバ１４０は、特定のウェブページをレンダリングするために、インデックスエンジン１１０または別の要求プロセスから要求を受信する。言い換えると、レンダリングサーバ１４０は、要求されたウェブページのURLを受信してもよい。レンダリングサーバ１４０は、１つ又は複数のレンダリングエンジン１４２を含んでもよい。いくつかの実施形態において、レンダリングサーバ１４０は、数万のレンダリングエンジン１４２を含み、およびウェブページをレンダリングするレンダリングエンジン１４２を選択するためにロードバランシングを実行してもよい。一旦レンダリングエンジン１４２が選択されると、レンダリングエンジン１４２は、レンダリング結果のためにウェブページをレンダリングしようとする。ウェブページは、通常は追加の埋め込みアイテムを含むので、埋め込むウェブページと呼ばれてもよい。

各レンダリングエンジン１４２は、パーソナルウェブブラウザ用のレンダラをエミュレートするように構成されるが、バッチレンダリングのための最適化を伴う。従って、レンダリングエンジン１４２が埋め込むウェブページを受信したあと、レンダリングエンジン１４２がレンダリング結果を生成するために行う作業を表すタスクをタスクリストに投入し始めてもよい。多くのタスクがすぐに実行されるようにスケジュールされていてもよいが、いくつかのタスクは将来スケジュールされてもよい。レンダリングエンジン１４２のバッチ最適化の一つは、仮想時計を使用し、レンダリングが特定の時間に完了したことを示すタスクリストにタスクを追加することである。例えば、いくつかの実施形態において、タスクは、レンダリングが現在の時間＋２０秒で完了することを示してもよい。所定の時間は、多数のウェブページ設計者が完全に見えるようにウェブページを設計する時間に基づいてもよく、例えば、任意のアニメーションあるいはレイアウト変更が所定の時間内に終わるように設計される。ほとんどのユーザは、ページが読み込まれるまで非常に長く待つことを快く思わないので、所定の時間は５から２０秒の間であってもよいが、状況によってはそれより長くなる可能性がある。レンダリングエンジン１４２は、仮想時計を使用するために２０秒全部かかることはなく、および埋め込みアイテムがクロールされていない場合（例えば、フェッチサーバ１５０が埋め込みアイテムテーブル１５２のコンテンツを示すことができる）、しばしばフルレンダリングが数秒で発生する可能性がある。従って、最終的なレンダリング結果を生成するタスクは、現在の時間から２０秒の開始時刻でタスクリストに追加されてもよい。現在の時間は、仮想時計の初期化時間に基づいており、これはゼロまたは実際の時計の現在の時間とすることができる。

レンダリングプロセスの一部、例えば、レンダリングタスクの一つとして、レンダリングエンジン１４２は、埋め込むウェブページが、スタイルシート、画像ファイル、Java Scriptなどの任意の埋め込みアイテムを含むか否かを決定してもよい。これらの埋め込みアイテムは、プライマリ埋め込みオブジェクトと呼ばれる。ウェブページが任意の埋め込みオブジェクトを含まない場合、レンダリングエンジンは、ウェブページをレンダリング結果に即座に処理することができ、およびレンダリング結果をレンダリング結果データストア１４８に格納してもよい。しかし、ウェブページが埋め込みアイテムを含む場合、レンダリングエンジン１４２は、埋め込みアイテムをすべて抜き出し、埋め込みアイテムのコンテンツのために要求をフェッチサーバ１５０に送信してもよい。要求された埋め込みアイテムは、それぞれのURLによって各々表される。レンダリングエンジン１４２は、しかしながら、フェッチされたリソースを待つ間、レンダリングを停止するか、タイムアウトすることはない。むしろ、レンダリングエンジン１４２は仮想時計を使用するので、以下でより詳細に説明するように、ウェブ巡回エンジン１３０を介してフェッチされるリソースを待つことは、時計を進めず、レンダリングエンジンはタイムアウトしない。

要求された埋め込みアイテムのためのコンテンツが受信されたとき、レンダリングエンジン１４２は、コンテンツを処理するためにタスクリストにタスクを追加してもよい。コンテンツ処理の一部は、要求された埋め込みオブジェクト（すなわち、プライマリ埋め込みオブジェクト）自身が埋め込みオブジェクト（すなわち、セカンダリ埋め込みオブジェクト）を有するか否かを見つけることを含んでもよい。プライマリ埋め込みオブジェクトがセカンダリ埋め込みオブジェクトを含まない場合、レンダリングエンジン１４２は、画像のプロパティを変更するレンダリングタスク（例えば、JavaScriptコードを実行する）に取り組むことを続けることができる。しかし、プライマリ埋め込みオブジェクトが１つ又は複数のセカンダリ埋め込みオブジェクトを含む場合、レンダリングエンジン１４２は、フェッチサーバ１５０からセカンダリ埋め込みオブジェクトを要求する。埋め込みオブジェクトを発見し要求するこのプロセスは、レンダリングエンジンが、レンダリングされるウェブページに埋め込まれた全てのオブジェクト（例えば、プライマリ、セカンダリ、第３の、など）を発見し、要求し、および受信するまで、繰り返される。

各埋め込みアイテム要求は、フェッチサーバ１５０が一旦その時間のコンテンツを返すと削除されるタスクリスト内のタスクであってもよい。コンテンツが返されるとき、レンダリングエンジン１４２は、コンテンツを処理するためのタスクを追加してもよく、これは、画像の不透明度の変更、スクリプトの実行など、追加のタスクを順に追加してもよい。各タスクは、ランタイムに関連付けられてもよい。いくつかのタスクは、将来のランタイムを有してもよい。例えば、イメージをフェードイン（またはアウト）するために、ブラウザはタスクリストにいくつかのタスクを追加してもよく、時間のインターバルにわたって画像の不透明度をそれぞれ変更する。以下でより詳細に説明するように、レンダリングエンジン１４２は、タスクが実行準備が整った時点を決定するために、タスクリストに関してリアルタイムではなく仮想時計を使用してもよい。

レンダリングエンジン１４２は、レンダリングが完了するまで、例えば、レンダリング結果が生成されるまで、タスクリストのタスクをレンダリングするプロセスに取り組む。次いでレンダリングエンジン１４２は、レンダリング結果をレンダリング結果データストア１４８に格納し、及び／又はレンダリング結果をレンダリングプロセス（例えば、インデックスエンジン１１０）に提供してもよい。インデックスエンジン１１０のようなレンダリングプロセスは、次いでウェブページを処理する際にレンダリング結果から抽出された情報を使用してもよい。例えば、要求プロセスは、JavaScriptエラー、レイアウト情報、スタイル情報、広告スペース情報、フェッチされたリソースのリスト、性能統計等を使用してもよく、そのすべてはレンダリング結果に含まれるが、要求プロセスにとってはそれ以外使用できない。

システム１００は、ネットワーク１７０を介してクライアント１８０およびサーバ１９０と通信してもよい。ネットワーク１７０は、例えばインターネット、または有線あるいは無線ローカルエリアネットワーク（ＬＡＮ）であってもよいネットワーク１７０、ワイドエリアネットワーク（ＷＡＮ）、これらの組合せであってもよく、例えばゲートウェイデバイス、ブリッジ、スイッチ、あるいは同様のものを使用して実装されてもよい。ネットワーク１７０を介して、クエリエンジン、ウェブ巡回エンジン１３０及び／又はフェッチサーバ１５０は、クライアント１８０及び／又はサーバ１９０と通信し、かつデータを送受信してもよい。

システム１００は、簡潔にするために図示されていない他のコンポーネントを含んでもよい。例えば、インデックスエンジン１１０、クエリエンジン１２０、ウェブ巡回エンジン１３０、レンダリングサーバ１４０、およびフェッチサーバ１５０のうちの１つまたは複数は、１つまたは複数のコンピューティングデバイスにわたって分散されてもよい。同様に、インデックス１１５、レンダリング結果データストア１４８、埋め込みアイテムテーブル１５２、および画像寸法テーブル１５６は、複数のコンピューティングデバイスにわたって格納されてもよい。いくつかの実施形態において、システム１００の様々なコンポーネントは、コンピューティングデバイスのハードウェアコンポーネントを共有してもよく、あるいは同じコンピューティングデバイスの論理パーティションであってもよい。

図２は、埋め込みオブジェクトを有するウェブページのブロック図である。図に示すように、ウェブページ２００は、複数の埋め込みアイテムを含むことができる。これらの埋め込みオブジェクトは、他のウェブページ２１０、スタイルシート２２０、画像ファイル２３０、いわゆるキャッシュバスティングURL２４０、およびJavaScriptコード２５０を含むことができるが、これらに限定されない。追加された、埋め込みオブジェクトの異なるタイプはもちろん可能である。さらに、ウェブページ２００に埋め込まれたそれぞれのオブジェクトは、他のオブジェクトを埋め込んでもよい。例えば、ウェブページ２００に埋め込まれたウェブページ２１０は、他のウェブページ、画像ファイル、スタイルシートなどを埋め込んでもよい。同様に、ウェブページ２００に埋め込まれたスタイルシート２２０は、背景画像ファイルのような他のオブジェクトを埋め込んでもよい。さらに、ウェブページ２１０またはスタイルシート２２０に埋め込まれたオブジェクトのそれぞれは、さらにオブジェクトを埋め込んでもよい。このようなウェブページを画像ファイルに完全にレンダリングするために、バッチレンダリングエンジンは、埋め込みオブジェクト２１０−２５０（プライマリ埋め込みオブジェクト）のそれぞれを要求し、埋め込みオブジェクト２１０−２５０に埋め込まれたすべてのオブジェクト（セカンダリ埋め込みオブジェクト）、および埋め込みオブジェクト２１０−２５０に埋め込まれたオブジェクトに埋め込まれたすべてのオブジェクト（第３埋め込みオブジェクト）およびその他を要求しなければならない。

上述したように、個々のユーザのウェブブラウザはこれらの埋め込みオブジェクトの全てを効率的に要求し、および完全にレンダリングするためにそれらを使用し、およびリアルタイムでウェブページ200を表示することができるが、バッチレンダリングエンジンは、重複あるいは不要なコンテンツをフェッチしないように、埋め込みオブジェクトのコンテンツを待ってタイムアウトしないように、およびタスクの内部タイミングに関係なく、できるだけ早くレンダリングが完了するように、最適化されることができる。したがって、多数のクロールされたウェブページを効率的にレンダリングするために、図１に開示されたようなシステムが使用されることができる。

図３は、一実施形態に従った、バッチレンダリングエンジン１４２のいくつかのコンポーネントのブロック図である。バッチレンダリングエンジンは、図３に示されていない追加のコンポーネントを含んでもよい。バッチレンダリングシステム１４２は、ページタスクリスト３０５、仮想時計３１０、およびレンダリング結果３１５を含む。仮想時計３１０は、ウェブページをロードするためにタイムラインを歪ませ、フェッチされたリソースを待つことによって発生する可能性がある多数のエラーを回避するために使用されてもよい。仮想時計３１０は、レンダリングプロセスの開始時間にゼロまたは現在のクロック時間に初期化されてもよく、およびレンダリングエンジンが埋め込みアイテムのフェッチを待っていないときおよびページタスクリスト３０５に現時点で実行の準備ができているタスクがあるときのみ進んでもよい。仮想クロックが進められたとき、レンダリングエンジン１４２はページタスクリスト３０５に基づいて仮想時計３１０を進める。言い換えると、レンダリングエンジン１４２は、仮想時計３１０を次に発生するタスクによって表される時間に進める。この意味において、埋め込みアイテムをフェッチしてJava Scriptを実行することは仮想時間がかからず、ライブ（または個人）ブラウザによって発生したエラーのクラス全体を回避することができる。さらに、レンダリングプロセスは、タスクリストで指定された時間よりもずっと早くリアルタイムで終了してもよい。たとえば、”最終レンダリングを生成する”タスクは、２０秒で発生するように設定されているが、仮想時計は通常は、ページタスクリスト３０５のタスクを実際に完了するのにかかる時間に応じて、実際の数秒で２０秒進む。ページタスクリスト３０５の”最終レンダリングを生成する”タスクは、レンダリングが完了したとき、バッチレンダリングエンジン１４２に伝える停止タスクの一例である。

レンダリングエンジン１４２は、埋め込むウェブページのレンダリング結果３１５をレンダリングしてもよい。レンダリング結果３１５は、様々なコンポーネントを含んでもよい。たとえば、レンダリング結果３１５は、レンダリングされたページの画像３１６を含むことができる。画像３１６は、ライブ（または個人）ウェブブラウザのユーザに表示される画像であってもよく、たとえばレンダリングされたページのサムネイルをユーザに表示するために使用されることができる。レンダリング結果３１５は、ドキュメント・オブジェクト・モデル（Document Object Model、DOM）ツリー３１７も含むことができる。DOMツリー３１７は、ウェブページのHTML構造を表す。たとえば、システムは、DOMツリーを処理することによって、トークンまたはユーザに見えるドキュメントのテキストを決定してもよい。レンダリング結果３１５は、レイアウト３１８を含んでもよい。レイアウト３１８は、ウェブページの各要素に対するボックスを含み、ボックスは画像３１６の要素の座標を決定する。たとえば、レイアウトは、DOMツリーのDOMノードのボックス表現を含むことができる（すべてのDOM要素が対応するレンダリングボックスを有するわけではない）。ボックスは、レンダリングツリーと呼ばれるツリー構造で編成されることができる。したがって、たとえば、テーブルは、レイアウトのボックスによって表されてもよく、パラグラフはレイアウトの別のボックスによって表されてもよい。したがって、レイアウト３１８は、ウェブページ上のどこに要素が発生するか、ウェブページ上でどれくらいのスペースを要するのか、などの指示を提供する。したがって、レイアウト３１８は、ウェブページ上のどれだけが広告であるか、パラグラフがどれくらい目立つか（たとえば、アバブ・ザ・フォールド（above-the-fold）またはビロウ・ザ・フォールド（below-the-fold））、要素が見えるか否かなどの情報を提供する。したがって、レイアウト３１８は、ウェブページの要素についての幾何学的情報を提供する。レンダリング結果３１５は、エラー３２０を含んでもよい。エラー３２０は、たとえばJava Scriptなどのスクリプトの実行結果として引き起こされるエラーを含む。レンダリング結果３１５は、レンダリングの間にフェッチされた埋め込みリソース３１９のリストを含んでもよく、レンダリングプロセスの一部として生成された別の要素を含むことができる。したがって、レンダリング結果３１５は、ホスティングサーバからのコンテンツのフェッチを介してだけ、要求プロセスに利用可能でない情報を提供する。たとえばインデックスエンジンは、インデックスの要素をランク付けし、目に見えない要素を断片の一部として提供し、および動的に生成されたコンテンツにインデックス付けするためにレンダリング結果情報を使用することができる。動的に生成されたコンテンツは、ウェブページをレンダリングしたあとに存在するコンテンツであり、クロールされたコンテンツには存在しない。

図４は、実施形態に従った、バッチレンダリングエンジンが、埋め込みオブジェクトを備えたウェブページをレンダリングすることができるプロセス例４００を図示する流れ図である。プロセス４００は、図１のシステム１００のようなシステムによって実行されてもよい。広告システム、またはインターネットインデックスシステムのようなシステムは、ダウンストリームプロセスの要求でバッチモードのウェブページのレンダリング結果を生成するために、プロセス４００を使用してもよい。いくつかの実施形態において、プロセス４００は、レンダリングサーバのバッチレンダリングエンジンによって実行されてもよく、および要求プロセスからの要求に応答して開始されてもよい。

プロセス４００は、ウェブページをレンダリングする要求を受信することから開始してもよい（４０５）。いくつかの実施形態において、要求は、要求されたウェブページのURLおよび／またはフェッチされたコンテンツと、関連するメタデータ（たとえばクロール時間）とを含んでもよい。いくつかの実施形態において、ウェブページのコンテンツを受信するのではなく、バッチレンダリングエンジンは、ウェブページのコンテンツがデータベースで利用可能であるという通知を受信し、データベースからコンテンツおよび関連するメタデータ（たとえば、クロール時間）を取り出すことができる。フェッチされたコンテンツは、たとえば、要求されたプロセスがすでにコンテンツをフェッチしているという理由で提供されてもよい。バッチレンダリングエンジンは、仮想時計を初期化し、タスクリストに停止タスクを追加することによって開始してもよい（４１０）。たとえば、バッチレンダリングエンジンは、仮想時計をゼロに設定し、レンダリングエンジンが所定の時間で完了したとレンダリングエンジンに判断させる停止タスクをタスクリストに追加してもよい。この停止タスクに関連付けられたランタイムは、個々のユーザのマシンでほとんどのウェブページが読み込みを完了までの時間であってもよい。たとえば、時間は１５または２０秒であってもよい。レンダリング開始の一部として、バッチレンダリングエンジンは、ウェブページのコンテンツをフェッチする（コンテンツが提供されなかった場合）、およびウェブページのコンテンツを処理する、などの他のタスクをタスクリストに追加してもよい。これらのタスクは、仮想時間ゼロで追加されてもよく、したがって、たとえばすぐに開始することができる。

次いでバッチレンダリングエンジンは、タスクリスト内のタスクに取り掛かることを開始してもよい（４１５）。たとえば、ウェブページのコンテンツの処理の一部として、バッチレンダリングエンジンは、１つまたは複数の埋め込みアイテムを識別してもよい（４２０）。次いでバッチレンダリングエンジンは、フェッチサーバから埋め込みアイテムのコンテンツを要求してもよい（４２５）。フェッチサーバは、図１のフェッチサーバ１５０であってもよい。いくつかの実施形態において、バッチレンダリングエンジンは、識別された埋め込みアイテムおよびフェッチサーバがそれぞれの埋め込みアイテムのためのコンテンツを返したか否かを追跡してもよい。いくつかの実施形態において、この埋め込みアイテムのリストは、ウェブページのレンダリング結果に含まれてもよい。バッチレンダリングエンジンが埋め込みアイテムを要求したあと、バッチレンダリングエンジンは、フェッチサーバがコンテンツを返すのを待つ間に実行する準備ができている別のタスク（４１５）上で作業を継続してもよい。現在の仮想時間に実行する準備ができているタスクがない場合、さもなければバッチレンダリングエンジンがフェッチサーバからの応答を待ってもよい。フェッチが未処理であるが、バッチレンダリングエンジンは仮想時計を進めないので、したがってバッチレンダリングエンジンはフェッチを待つのでタイムアウトしない。

フェッチサーバからの応答を受信したとき、バッチレンダリングエンジンは、埋め込みアイテムのコンテンツを処理する（４３０）。たとえば、コンテンツの受信に応答して、バッチレンダリングエンジンは、埋め込みアイテムの受信したコンテンツを解析するなどのタスクをタスクリストに追加してもよい。これらのタスクは、現在の仮想時計の開始時間を与えられてもよく、これはタスクが実行準備ができていることを示す（たとえば、仮想時計上の現在の時間）。受信したコンテンツを解析し、最初に要求されたウェブページのためあるいは埋め込みアイテムのためであるかにかかわらず、バッチレンダリングプロセスが追加のタスクをタスクリストに追加してもよい。たとえば、埋め込みアイテムのコンテンツを解析することは、追加の埋め込みアイテム（たとえば、セカンダリ埋め込みアイテム）を検出してもよく、これはバッチレンダリングエンジンに埋め込みアイテムを要求させ、および返されたときにコンテンツを解析させてもよい。コンテンツがたとえばJavaScriptなどのスクリプトを含む場合、スクリプトを実行することは、追加のタスクにレイアウトの生成やウェブページの1つまたは複数の要素の概観の変更などの追加のタスクを実行させてもよい。これらのタスクのいくつかは、将来開始することがスケジュールされてもよい。たとえば、画像の不透明度を一定の間隔で変更すると、画像がフェードインしているかのようにユーザに表示される。不透明度の各変化はタスクであり、スクリプトはタスクリストに、いくつかのそのようなタスクを追加させ、それぞれ現在の仮想時計のランタイムに指定された量を加えたものとなる。

レンダリングプロセスの一部として、バッチレンダリングエンジンは、レンダリングが完了したか否かを判断してもよい（４３５）。この判断は、例えば、バッチレンダリングエンジンがタスクを完了する度に、あるいは所定の時間の間隔などで行われてもよい。仮想時計が停止タスクで指定された時間に達すると、レンダリングは終了してもよい。埋め込みアイテムのフェッチが未処理である間、仮想時計が進まないので、仮想時計が停止タスクで指定された時間に達したとき、バッチレンダリングエンジンは各フェッチリクエストの要求を受信することが保証される。したがって、バッチレンダリングエンジンは、リソースの待機をタイムアウトすることはない。

レンダリングが完了していない場合（４３５、いいえ）、バッチレンダリングエンジンは、タスクリスト内のタスクに取り掛かることを継続し、１つまたは複数の埋め込みアイテムの要求に対する応答などを待ってもよい。レンダ理暗愚が完了した場合（４３５、はい）バッチレンダリングエンジンは、要求されたウェブページのためのレンダリング結果をファイナライズし（４４０）、レンダリング結果を要求プロセスに返してもよい。レンダリング結果の要素は、バッチレンダリングエンジンによって完了されたタスクの結果として以前に生成されたものでもよい。たとえば、スクリプトの実行中にフェッチされた埋め込みアイテムのリストおよび遭遇したエラーがレンダリングが完了する前に生成されてもよい。レイアウトを決定するなどの別の要素がレンダリングが完了したあとに発生してもよい。いくつかの実施形態において、レンダリングプロセスの一部として実行されるスクリプトが要素の位置を要求しない限り、バッチレンダリングエンジンは、レンダリングが終了するまでレイアウトを決定しない。レンダリングが完了する前にレイアウトが生成されたとしても、バッチレンダリングエンジンは、レンダリング結果のファイナライズの一部としてレイアウトを最終的に生成してもよい。したがって、レンダリング結果をファイナライズすることは、新しい要素を生成することおよびすでに生成された要素を集めることを含んでもよい。いくつかの実施形態において、バッチレンダリングエンジンは、レンダリング結果をメモリに格納し、レンダリング結果の位置を要求プロセスに提供してもよい。いくつかの実施形態において、システムは、いつ生成されたかを示すタイムスタンプとともにレンダリング結果を格納してもよく、レンダリング結果の２つ以上のバージョンを格納してもよい。バッチ処理の最適化とともにバッチモードでレンダリング結果を生成し、次いでプロセス４００は終了する。

図５は、一実施形態に従った、バッチレンダリングエンジンが仮想時計を進めるプロセス例５００を示す流れ図である。プロセス５００は、レンダリングが終了したか否かを判断すうｒ一部として実行されてもよいが（例えば、図４のステップ４３５）、他の時間に（例えば、定期的に）実行されてもよい。プロセス５００は、バッチレンダリングエンジンが埋め込みアイテムの要求を待っているか否かを判断することから開始してもよい（５０５）。例えば、バッチレンダリングエンジンがフェッチサーバから埋め込みアイテムを要求し、フェッチサーバからまだ応答を受信していない場合、バッチレンダリングエンジンは待機中である。バッチレンダリングエンジンが待機中である場合（５０５、はい）、仮想時計は進められず、バッチレンダリングエンジンは、存在するならば現在の仮想時間で実行する準備ができているタスクに取り組んでもよく、あるいは待機してもよい（５１０）。このステップは、図４のステップ４１５の一部として実行されてもよい。バッチレンダリングエンジンがフェッチ要求を待っていない場合（５０５、いいえ）、バッチレンダリングエンジンは、タスクリスト内に実行準備ができているタスクが存在するか否かを判断してもよい（５１５）。たとえば、タスクリスト内のタスクが仮想時計と等しいランタイムを有する場合、タスクは実行準備ができている。タスクが実行準備ができている場合（５１５、はい）、バッチレンダリングエンジンはタスクに取り組んでもよい（５２０）。タスクに取り組むことは、タスクリストに別のタスクを追加してもよく、そのうちのいくつかは実行準備ができていてもよく、そのうちの他のものは将来のランタイムを有していてもよい（例えば、現在の仮想時間プラス所定の時間）。このステップは、図４のステップ４１５の一部として実行されてもよい。実行準備が整っている保留中のタスクが存在しない場合（５１５、いいえ）、バッチレンダリングエンジンは仮想時計をタスクリストで指定された次のランタイムに進めてもよい。言い換えると、バッチレンダリングエンジンは、仮想時計を先に歪めてもよく、そうすることによってタスクリスト内のラインの次のタスクはすぐに実行できる。

タスクリスト内のラインの次のタスクが停止タスクである場合（５３０、はい）、レンダリングは完了する。そうでなければ、バッチレンダリングエンジンは、保留中のタスクに取り組むことを継続してもよい（５２０）。プロセス５００は、実行準備ができている保留中のタスクがある間、あるいは埋め込みアイテムのフェッチを待機している間に、仮想時計がどのように進まないかを示す。したがって、これらのイベントに対して仮想時計が“停止して”おり、レンダリングエンジンが実際のクロックを使用するときに遭遇したエラーのクラスを避けることができる。さらに、プロセス５００は、仮想時計がどのように前に歪ませられることができるかを示し、そうすることによっていくつかの例において、レンダリングプロセスは、タスクによって指示されたタイミング（例えば、画像のフェードインするまたはアニメーションの再生をする時間間隔を待機する）よりも実時間をかけないことができる。これは、本明細書でより詳細に説明するように、埋め込みアイテムがクロールなしで返されるときに特に当てはまる。もちろん、保留中のタスクのチェック（５１５）およびフェッチ要求（５０５）の順序を逆にすることもでき、および実施形態は、図５に示された順序に限定されないことが理解される。

図６は、実施形態に従った、フェッチサーバが埋め込みアイテムのコンテンツをバッチレンダリングエンジンに提供するプロセス例を図示する流れ図である。プロセス６００は、図１のシステム１００のようなシステムによって実行されてもよい。システムは、複数のバッチレンダリングシステムから、埋め込みアイテムのためのフェッチリソースに対応するプロセス６００を使用してもよい。いくつかの実施形態において、プロセス６００は、フェッチサーバによって実行されてもよく、およびバッチレンダリングエンジンの1つからの要求に応答して開始されてもよい。

プロセス６００は、埋め込みアイテム（６０５）のためのＵＲＬをフェッチサーバが受信することから開始してもよい。ＵＬＲは、バッチレンダリングエンジンによって提供されてもよく、およびバッチレンダリングエンジンによって要求された複数のＵＲＬの１つであってもよい。フェッチサーバは、要求された埋め込みアイテム（６１０）のＵＲＬに書き換え規則を適用してもよい。書き換え規則は、図１のＵＲＬ書き換え規則１５４であってもよい。書き換え規則は、テンプレートおよびリダイレクトＵＲＬを含んでもよい。書き換え規則を適用することは、ＵＲＬが書き換え規則の一つのためのパターンまたはテンプレートに一致するか否かを判断することを含んでもよい。例えば、テンプレートは、任意のクエリ文字列が削除されたＵＲＬであってもよく、およびシステムはテンプレートに一致するかを調べるために要求された埋め込みアイテムのＵＲＬからクエリ文字列を削除してもよい。別の例として、テンプレートは、任意の文字または文字列がワイルドカード文字と一致することができる場所を示す、*および？のようなワイルドカード文字を含んでもよい。

ＵＲＬがパターンと一致した場合、書き換え規則は、リダイレクトＵＲＬを提供してもよく、およびフェッチサーバは、リダイレクトＵＲＬを備えた要求された埋め込みアイテムのＵＲＬを代用してもよい。書き換え規則を適用するための理由の一つは、フェッチサーバが、ＵＲＬを識別し、および同じコンテンツを返すＵＲＬを識別し、不要なフェッチをスケジュールする必要がないようにするためにリダイレクトＵＲＬを使用できるようにするためである。一般的に埋め込まれたアイテムの特定のタイプは、動的に生成されたＵＲＬを有する。例えば、いくつかの埋め込みアイテムのＵＲＬは、乱数発生器によって生成される乱数、または日付と時刻関数によって返される現在の日付と時間に依存する。キャッシュバスティング（cache-busting）トラッキングＵＲＬと呼ばれるこれらの埋め込みオブジェクトは、一般的に、広告費用または収益を測定する目的で、ウェブページの固有のヒット数またはビュー数を測定するために使用される。このような埋め込みオブジェクトのコンテンツは、通常は同一であるが、固有のＵＲＬは、レンダリングエンジンによって検出される度にそのオブジェクトに対して生成される。したがって、そのような埋め込みアイテムを含むウェブページのために、レンダリングエンジンは、ウェブページのレンダリングを試みる度にオブジェクトのための新しく異なるＵＲＬを見て、書き換え規則を適用することなく、フェッチサーバは同じコンテンツを何度もフェッチする。これを避けるために、書き換え規則は、フェッチサーバにこれらのＵＲＬを識別させ、フェッチ要求をリダイレクトＵＲＬの下に格納された以前に取得されたコンテンツにリダイレクトするためのテンプレートを適用してもよい。

書き換え規則を適用するもう一つの理由は、ブラックリストに載っているＵＲＬを識別するためである。書き換え規則は、ブラックリストに載っているＵＲＬを識別する規則、あるいはブラックリストに載っているＵＲＬのためのパターンあるいはテンプレートを含んでもよい。例えば、書き換え規則は、テンプレート、および関連したリダイレクトＵＲＬ、エラー、あるいはフラグを含んでもよい。要求された埋め込みアイテムのためのＵＲＬがブラックリストに載っているＵＲＬあるいはブラックリストに載っているＵＲＬのためのテンプレートと一致した場合、フェッチサーバは、ＵＲＬをブラックリストに載っているものとして識別してもよい。いくつかの実施形態において、書き換え規則を適用することは、ＵＲＬがリダイレクトＵＲＬに置き換えられる要因となってもよい。いくつかの実施形態において、書き換え規則を適用することは、URLがブラックリストに載っているものとしてフラグを立ててもよく、あるいはURLによって識別された埋め込みアイテムのための要求に対する応答として返すためにエラーを提供してもよい。

ＵＲＬがブラックリストに載っている場合（６１５、はい）、フェッチサーバは要求しているバッチレンダリングエンジン（６２０）にエラーを返してもよい。エラーは、リソースが見つからなかったことを示す標準的なエラー、あるいはリソースが必要ではない、またはスキップができることなどをレンダリングエンジンに知らせる特定のエラーであってもよい。エラーは、書き換え規則がリダイレクトURLを提供したとき、埋め込みアイテムテーブルから、書き換え規則、ハードコードなどのフラグに基づいて選択された一致させている書き換え規則によって、埋め込みアイテムテーブルから提供されてもよい。次いでこのURLのためのフェッチ要求が完了し、プロセス６００は終了する。

URLがブラックリストに載っていない場合（６１５、いいえ）、フェッチサーバは、埋め込みアイテムデータストア（６２５）内の書き換えられたURLを探してもよい。埋め込みアイテムデータストアは、図１の埋め込みアイテムテーブル１５２であってもよい。オリジナルURLが書き換え規則の識別されたパターンと一致した場合、書き換えられたURLは、書き換え規則によって提供されたリダイレクトURLであってもよい。URLが書き換え規則の任意のテンプレートと一致しない場合、書き換えられたURLは、オリジナルURLであってもよい。URLが埋め込みアイテムデータストア（６２５、はい）内にある場合、フェッチサーバは、要求されたURLが画像用であるか否かを任意に決定してもよい（６３０）。これは任意であり、画像のためのテストをしない実施形態において、ステップ６３０は省略されてもよい。要求された埋め込みアイテムが画像であるか否かは、要求の情報、URL自体に基づいて、あるいは書き換えられたURLのための埋め込みアイテムデータストア内のフィールドに基づいて、決定されてもよい。埋め込みアイテムが画像である場合（６３０、はい）、図７のプロセス７００に関してより詳細に説明されるように、システムは、画像のサイズについてサイズテーブル内を調べ、およびサイズを有するモック画像を返してもよい。いくつかの実施形態において、フェッチサーバは、埋め込みアイテムデータストアを前に、またはエントリが古いかどうかを判定した後に、書き換え規則を適用する前にステップ６３０を実行してもよいことが理解される。

要求された埋め込みアイテムが画像でない場合（６３０、いいえ）、フェッチサーバは、埋め込みアイテムテーブル内のエントリが古いか否かを判断してもよい（６４５）。エントリが古いか否かは、アイテムの変更率、埋め込みアイテムのタイプ（例えば、スクリプト、スタイルシート、画像など）、ブラウザレンダリングエンジンがレンダリングしているウェブページの重要度、などのいくつかの要因に依存してもよい。いくつかの実施形態において、埋め込みアイテムテーブルは、例えばブラックリストに載っている埋め込みアイテムのURLのリダイレクトURLのためのように、エントリが古くならないことを示すフィールドあるいは値を有してもよい。エントリが古くない場合（６４５、いいえ）、フェッチサーバは、書き換えられたURLについての埋め込みアイテムテーブルのコンテンツを、要求しているバッチレンダリングエンジン（６５０）に返してもよく、この埋め込みアイテムについてのプロセス６００は終了する。いくつかの実施形態において、コンテンツを返すことは、フェッチサーバが埋め込みアイテムテーブル内のエントリの位置を応答として提供することと、バッチレンダリングプロセスが位置を使用してコンテンツにアクセスすることと、を含んでもよい。

埋め込みアイテムテーブル内のエントリが古い場合（６４５、はい）または書き換えられたURLが埋め込みアイテムデータストア内に無い場合（６２５、いいえ）、フェッチサーバは、例えば図1のウェブ巡回エンジン１３０のようなウェブ巡回からURLのフェッチを要求してもよい（６３５）。フェッチサーバがクロールコンテンツを受信するとき、通信あるいはさらなる処理をせずに、受信したコンテンツを埋め込みアイテムデータストアにエントリとして格納してもよい（６４０）。いくつかの実施形態において、フェッチサーバは、埋め込みアイテムの以前のクロールのコンテンツおよびクロール時間に上書きせずに、埋め込みアイテムのコンテンツおよびクロール時間を保存することができる。いくつかの実施形態において、フェッチサーバは、埋め込みアイテムテーブルに１つのエントリをキープしてもよく、および埋め込みアイテムの以前のクロールを維持しなくてもよい。いずれにせよ、埋め込みアイテムテーブル内に一旦保存されると、コンテンツはキャッシュされ、および古くなるまで再度フェッチされる必要はない。フェッチサーバは、フェッチされたコンテンツを要求しているバッチレンダリングエンジンに返してもよく（６５０）、プロセス６００は終了する。

図7は、一実施形態に従った、フェッチサーバがモック画像をバッチレンダリングエンジンに提供するプロセス例７００を図示する流れ図である。プロセス７００は、図１のシステム１００のようなシステムによって実行されてもよい。システムは、複数のバッチレンダリングエンジンからの、ウェブページに埋め込まれた画像のためのフェッチ要求に応答するために、プロセス７００を使用してもよい。いくつかの実施形態において、プロセス７００は、フェッチサーバによって実行されてもよく、およびバッチレンダリングエンジンの１つからの要求に応答して開始されてもよい。いくつかの実施形態において、フェッチサーバは、他の埋め込みアイテム（例えば、図６のプロセス６００）とは無関係にプロセス７００を実行してもよい。別の実施形態において、フェッチサーバは、プロセス７００の要素を他の埋め込みアイテムを含むプロセス、例えば図６のプロセス６００に組み込んでもよい。

プロセス７００は、要求された画像がサイズテーブル（７０５）にエントリを有するか否かをフェッチサーバが判断することから開始してもよい。画像サイズテーブルは、図1の画像サイズテーブル１５６であってもよい。画像サイズテーブルは、画像のためのサイズを含み、これはＵＲＬのような画像のための識別子によって格納される。画像がサイズテーブルにない場合（７０５、いいえ）、あるいは画像がサイズテーブルにあるが（７０５、はい）古い（７１０、はい）場合、フェッチサーバは、例えば図１のウェブ巡回エンジン１３０のようなウェブ巡回エンジンを介して、画像のフェッチ（７１５）をスケジュールしてもよい。いくつかの実施形態において、フェッチサーバは、エントリが古いか否かを判断するためにサイズテーブルの情報を使用してもよい。いくつかの実施形態において、フェッチサーバは、サイズが古いか否かを判断するために、図６のステップ６４５に関して上述したように、別個の埋め込みアイテムテーブルからの情報を使用してもよい。したがって、いくつかの実施形態において、フェッチサーバは図６のステップ６４５と併せて、あるいはその一部としてステップ７１０を実行してもよい。画像のためのコンテンツが受信されたとき、フェッチサーバは、サイズテーブルに画像のためのエントリを追加してもよく、エントリはフェッチされた画像のサイズを含む（７２０）。いくつかの実施形態において、フェッチサーバは、図６のステップ６４０の一部として上述されたように、フェッチされたコンテンツを埋め込みアイテムテーブルに格納してもよい。

画像がサイズテーブルにあり（７０５、はい）、かつ古くない（７１０、いいえ）場合、あるいは画像がフェエッチされて格納された（７２０）後、システムはサイズテーブル（７２５）からサイズを使用してモック画像を生成してもよい。モック画像は、要求された画像と同じサイズであるが空のコンテンツを指定する画像ファイルフォーマットデータを有してもよい。システムは、モック画像（７３０）を要求バッチレンダリングエンジンに返し、プロセス７００は終了する。

いくつかの実施形態において、プロセス７００のステップのいくつかは、任意であるかまたは他の処理の一部として実行されてもよいことが理解される。例えば、画像のサイズが古いか否かを判断するステップは、図６のステップ６４５の一部として実行されてもよく、埋め込みアイテムテーブルの情報に基づいてもよい。さらに、ステップ７１５は、図６のステップ６３５の一部として、あるいはそれと併せて実行されてもよい。言い換えると、フェッチサーバは、画像のためのコンテンツをフェッチする、キャッシュされフェッチされたコンテンツが古いか否かを判断する、などのようなプロセス６００の態様とプロセス７００の態様を組み合わせてもよい。もちろん、フェッチサーバは、プロセス６００と完全に独立したプロセス７００を実行してもよい。したがって、実装はプロセス７００の変形を含んでもよい。

図６は、汎用コンピュータデバイス８００の例を示しており、それは、図１のシステム１００、及び／又はクライアント１７０として動作し得、また、本明細書に記載される技法を用いて使用され得る。コンピューティングデバイス８００は、コンピューティングデバイスの種々の形態例、例えば、ラップトップ、デスクトップ、ワークステーション、パーソナルデジタルアシスタント、携帯電話、スマートフォン、タブレット、サーバ、ならびにウェアラブルデバイスを含む他のコンピューティングデバイスなどを表わすことが意図される。本明細書に示される構成要素、それらのつながりや関係、およびそれらの機能は、単なる例であることを意味するものであり、この文書において記載される及び／又は請求される発明の実施形態を限定することを意味するものではない。

コンピューティングデバイス８００は、インターフェース８０８経由で接続される、例えばシリコーンベースのハードウェアプロセッサ等のプロセッサ８０２、メモリ８０４、ストレージデバイス８０６、および拡張ポート８１０を含む。いくつかの実施形態において、コンピューティングデバイス８００は、インターフェース８０８経由で接続される、いくつかある構成要素の中でも、送受信機８４６、通信インターフェース８４４、およびＧＰＳ（全地球測位システム）レシーバモジュー８４８を含み得る。デバイス８００は、通信インターフェース８４４を通して無線で通信し得、それは、必要に応じて、デジタル信号処理回路を含み得る。構成要素８０２、８０４、８０６、８０８、８１０、８４０、８４４、８４６、および８４８のそれぞれは、必要に応じて、一般的なマザーボード上にまたは他の様式で搭載され得る。

プロセッサ８０２は、メモリ８０４内またはストレージデバイス８０６上に記憶された命令を含む、コンピューティングデバイス８００内の実行のための命令を処理することができ、外部入出力デバイス、例えばディスプレイ８１６などの上にＧＵＩのためのグラフィカル情報を表示する。ディスプレイ８１６は、モニタまたはフラットタッチスクリーンディスプレイであり得る。いくつかの実施形態において、複数のプロセッサ及び／又は複数のバスが、必要に応じて、複数のメモリや複数の種類のメモリと共に、使用され得る。また、複数のコンピューティングデバイス８００は、（例えば、サーババンク、ブレードサーバのグループ、またはマルチプロセッサシステムとして）必要な動作の一部分を提供する各デバイスと、接続され得る。

メモリ８０４は、コンピューティングデバイス８００内に情報を記憶する。一実施形態において、メモリ８０４は、揮発性メモリのユニットまたは複数ユニットである。別の実施形態において、メモリ８０４は、不揮発性メモリのユニットまたは複数ユニットである。メモリ８０４はまた、コンピュータで読み取り可能な媒体の別の形態、例えば磁気もしくは光学ディスクなどであり得る。いくつかの実施形態において、メモリ８０４は、拡張インターフェースを通して提供される拡張メモリを含み得る。

ストレージデバイス８０６は、コンピューティングデバイス８００のためのマスストレージを提供することができる。一実施形態において、ストレージデバイス８０６は、コンピュータで読み取り可能な媒体、例えば、フロッピーディスクデバイス、ハードディスクデバイス、光学ディスクデバイス、またはテープデバイス、フラッシュメモリもしくは他の類似の固体メモリデバイス、あるいはストレージエリアネットワークもしくは他の構成におけるデバイスを含む、デバイスのアレイなどであり得るか、それらを含み得る。コンピュータプログラム製品は、そのようなコンピュータで読み取り可能な媒体に明白に具体化され得る。コンピュータプログラム製品はまた、実行されるときに、例えば上記したものなどの、１つ以上の方法を行う命令を含み得る。コンピュータまたはマシンで読み取り可能な媒体は、ストレージデバイス、例えばメモリ８０４、ストレージデバイス８０６、またはプロセッサ８０２上のメモリなどである。

インターフェース８０８は、コンピューティングデバイス８００のための帯域消費型の動作を扱う高速コントローラ、またはより低い帯域消費型の動作を扱う低速コントローラ、あるいはそのようなコントローラの組み合わせであり得る。外部インターフェース８４０は、他のデバイスとのデバイス８００の近接領域通信を可能にするように、提供され得る。いくつかの実施形態において、コントローラ８０８は、ストレージデバイス８０６および拡張ポート８１４に結合され得る。種々の通信ポート（例えば、ＵＳＢ、ブルートゥース（登録商標）、イーサネット（登録商標）、無線イーサネット（登録商標））を含み得る拡張ポートは、例えば、ネットワークアダプタを通して、１つ以上の入出力デバイス、例えば、キーボード、ポインティングデバイス、スキャナ、または例えばスイッチもしくはルータなどのネットワーキングデバイスに結合され得る。

コンピューティングデバイス８００は、図面に示されるように、多くの異なる形態で実装され得る。例えば、それは、標準サーバ８３０として、またはそのようなサーバのグループにおいて複数回、実装され得る。それはまた、ラックサーバシステムの一部として実装され得る。加えて、それは、パーソナルコンピュータ、例えばラップトップコンピュータ８３２、デスクトップコンピュータ８３４、あるいはスマートフォン８３６などで実装され得る。システム全体は、互いに通信する複数のコンピューティングデバイス８００で構成され得る。他の構成が可能である。

図９は、汎用コンピュータデバイス９００の例を示しており、それは、図１のシステム１００であり得るとともに本明細書に記載される技法を用いて使用され得る。コンピューティングデバイス９００は、大規模データ処理デバイス、例えばサーバ、ブレードサーバ、データセンター、メインフレーム、および他の大規模コンピューティングデバイスなどの種々の形態例を表わすことが意図される。コンピューティングデバイス９００は、場合によっては１つ以上の通信ネットワークによって相互接続されるネットワーク接続ストレージノードを含む、複数プロセッサを有する分散型システムであり得る。本明細書に示された構成要素、それらのつながりや関係、およびそれらの機能は、単なる例示であることを意味するものであり、この文書において記載されるか請求される発明の実施形態を限定することを意味するものではない。

分散型コンピューティングシステム９００は、任意の数のコンピューティングデバイス９８０を含み得る。コンピューティングデバイス９８０は、ローカルもしくはワイドエリアネットワーク、専用光学リンク、モデム、ブリッジ、ルータ、スイッチ、有線もしくは無線ネットワーク等の上で通信する、サーバまたはラックサーバ、メインフレーム等を含み得る。

いくつかの実施形態において、各コンピューティングデバイスは、複数のラックを含み得る。例えば、コンピューティングデバイス９８０ａは、複数のラック９５８ａ〜９５８ｎを含む。各ラックは、１以上のプロセッサ、例えばプロセッサ９５２ａ〜９５２ｎおよび９６２ａ〜９６２ｎなどを含み得る。プロセッサは、データプロセッサ、ネットワーク接続ストレージデバイス、および他のコンピュータ制御デバイスを含み得る。いくつかの実施形態において、１つのプロセッサは、マスタープロセッサとして動作し得、スケジューリングおよびデータ分散タスクを管理し得る。プロセッサは、１以上のラックスイッチ９５８を通して相互接続され得、１以上のラックが、スイッチ９７８を通して接続され得る。スイッチ９７８は、複数の接続されたコンピューティングデバイス９００間の通信に対処し得る。

各ラックは、メモリ、例えばメモリ９５４やメモリ９６４など、およびストレージ、例えば９５６および９６６などを含み得る。ストレージ９５６および９６６は、マスストレージを提供し得、揮発性もしくは不揮発性ストレージ、例えばネットワーク接続ディスク、フロッピーディスク、ハードディスク、光学ディスク、テープ、フラッシュメモリもしくは他の類似の固体メモリデバイス、あるいはストレージエリアネットワークまたは他の構成におけるデバイスを含む、デバイスのアレイなどを含み得る。ストレージ９５６または９６６は、複数のプロセッサ、複数のラック、または複数のコンピューティングデバイス間で共有され得、1つ以上のプロセッサによって実行可能な命令を記憶するコンピュータで読み取り可能な媒体を含み得る。メモリ９５４および９６４は、例えば、揮発性メモリのユニットまたは複数ユニット、不揮発性メモリのユニットもしくは複数ユニット、及び／又はコンピュータで読み取り可能な媒体の他の形態、例えば、磁気もしくは光学ディスク、フラッシュメモリ、キャッシュ、ランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、およびそれらの組み合わせなどを含み得る。メモリ、例えばメモリ９５４などはまた、プロセッサ９５２ａ〜９５２ｎ間で共有され得る。索引などのデータ構造は、例えば、ストレージ９５６やメモリ９５４にわたって、記憶され得る。コンピューティングデバイス７００は、図示されない他の構成要素、例えば、コントローラ、バス、入出力デバイス、通信モジュール等を含み得る。

システム１００などのシステム全体は、互いと通信する複数のコンピュータデバイス９００で構成され得る。例えば、デバイス９８０aは、デバイス９８０ｂ、９８０ｃ、および９８０ｄと通信し得、これらは、集合的にシステム１００として知られ得る。別の例として、図１のシステム１００は、１以上のコンピュータデバイス９００を含み得る。コンピュータデバイスのうちのいくつかは、互いに地理的に近く位置し得、その他は、地理的に離れて位置し得る。コンピュータデバイス９００のレイアウトは、単なる例であり、システムは、他のレイアウトまたは構成を取り得る。

さまざまな実施形態は、ストレージシステム、少なくとも１つの入力デバイス、および少なくとも１つの出力デバイスからデータや命令を受信するように、並びにそれらにデータや命令を送信するように、結合される、特殊目的もしくは一般の目的であり得る、回路基板に形成された少なくとも1つのプログラム可能なプロセッサを含むプログラム可能なシステム上で実行可能または解釈可能である1つ以上のコンピュータプログラムにおける実施形態を含むことができる。

これらのコンピュータプログラム（プログラム、ソフトウェア、ソフトウェアアプリケーション、またはコードとしても知られる）は、プログラム可能なプロセッサに対する機械語命令を含み、高レベル手続言語及び／又はオブジェクト指向プログラミング言語で、ならびに／あるいはアセンブリ／機械言語で実装することができる。本明細書で使用される場合、「機械可読媒体」「コンピュータ可読媒体」という用語は、機械語命令及び／又はデータをプログラム可能なプロセッサに提供するために使用される任意の非一時的コンピュータプログラム製品、装置、及び／又はデバイス（例えば、磁気ディスク、光ディスク、メモリ（読み取り専用メモリを含む）、プログラマブル論理デバイス（PLD））を指す。

本明細書で述べたシステムおよび技術は、バックエンドコンポーネント（例えば、データサーバとして）を含むコンピューティングシステム、またはミドルウェアコンポーネント（例えば、アプリケーションサーバ）を含むコンピューティングシステム、またはフロントエンドコンポーネント（例えば、ユーザが本明細書で述べたシステムおよび技術の実装と相互作用することができるグラフィカルユーザインタフェースまたはウェブブラウザを備えたクライアントコンピュータ）を含むコンピューティングシステム、またはこのようなバックエンド、ミドルウェア、またはフロントエンドコンポーネントの任意の組合せで、実装されることができる。前記システムのコンポーネントは、デジタルデータ通信（例えば通信ネットワーク）の任意の形式または媒体で接続されることができる。通信ネットワークの例としては、ローカルエリアネットワーク（”LAN”）、ワイドエリアネットワーク（”WAN”）、およびインターネットを含む。

コンピューティングシステムは、クライアントおよびサーバを含むことができる。クライアントおよびサーバは、通常、相互に離れており、および通常は、通信ネットワークを通じて相互作用する。クライアントとサーバの関係は、それぞれのコンピュータ上で動作し、互いにクライアント−サーバ関係を有するコンピュータプログラムの効力によって生じる。

多くの実施形態が説明されてきた。それにもかかわらず、本発明の精神および範囲から逸脱することなく、さまざまな変更がなされ得る。さらに、図に示された論理フローは、望ましい結果を達成するために、図示された特定の順序または連続する順序である必要はない。さらに、他のステップを設けても、または記載されたフローから複数のステップを除いてもよく、また、記載されたシステムに他の要素を追加してもよく、またはそこから除去してもよい。従って、他の実施形態は、添付の特許請求の範囲に含まれる。

１１０ インデキシングエンジン
１１５ インデックス
１２０ クエリエンジン
１３０ ウェブ巡回エンジン
１４０ レンダリングサーバ
１４２ レンダリングエンジン
１４８ レンダリング結果
１５０ フェッチサーバ
１５２ 埋め込みアイテムテーブル
１５４ ＵＲＬ書き換え規則
１５６ 画像寸法テーブル
１７０ ネットワーク
１８０ クライアント
１８２ クエリ
１８４ レスポンス
１９０ サーバ
２２０ スタイルシート
２３０ 画像ファイル
２４０ キャッシュバスティングＵＲＬ
３０５ ページタスクリスト
３１０ バーチャル時計
３１５ レンダリング結果
３１６ 画像
３１７ DOMツリー
３１８ レイアウト
３１９ 埋め込みリソース
３２０ エラー

Claims (18)

1. ウェブページをレンダリングするための要求をバッチプロセスから受信するステップと、
   少なくとも１つのプロセッサを使用して、仮想時計と前記ウェブページをレンダリングするためのタスクリストを初期化するステップであって、前記仮想時計が、埋め込みアイテムのための要求が未処理であるときかつタスクが準備完了であるとき、依然として静止している、初期化するステップと、
   前記仮想時計に従って前記タスクリスト内のタスクを実行するステップと、
   前記仮想時計が前記タスクリスト内の停止タスクのためのランタイムに一致するとき、前記少なくとも１つのプロセッサを使用して、前記ウェブページのためのレンダリング結果を生成するステップと、
   前記バッチプロセスのための前記レンダリング結果を提供するステップと、を含む、方法。
2. 前記タスクリストを初期化するステップが、ランタイムセットを備えた前記停止タスクを前記仮想時計に追加された所定の時間に追加するステップを含む、請求項１に記載の方法。
3. 前記バッチプロセスが、インデックスエンジンを含み、かつ前記方法が、インデックスのトークンをランク付けするために前記レンダリング結果を使用するステップをさらに含む、請求項１に記載の方法。
4. 埋め込みアイテムに対する要求が未解決でない、かつ前記仮想時計よりも大きいランタイムを有するただ一つのタスクが前記タスクリストにあるとき、前記仮想時計を前記タスクリスト内のタスクのランタイムに進めるステップをさらに含む、請求項１に記載の方法。
5. 前記バッチプロセスが、インデックスエンジンであり、かつ前記方法が、前記レンダリング結果の情報に基づいて、前記ウェブページのためのランクを降格させるステップをさらに含む、請求項１に記載の方法。
6. 前記バッチプロセスが、インデックスエンジンであり、かつ前記方法が、動的に生成されたコンテンツにインデックスを付けるために前記レンダリング結果を使用するステップをさらに含む、請求項１に記載の方法。
7. 前記仮想時計に従って前記タスクリスト内のタスクを実行するステップが、埋め込みアイテムに対する要求が未解決でないかつ前記仮想時計に一致するランタイムを有するタスクが存在しないと決定したことに応答して、前記仮想時計を前記タスクリスト内の次に発生するタスクによって表される時間に進めるステップを含む、請求項１に記載の方法。
8. 前記ウェブページの埋め込みアイテムを識別するステップと、
   前記埋め込みアイテムのためのコンテンツを要求するステップと、
   前記要求に応答して、前記コンテンツを受信するステップと、
   前記コンテンツを処理するために前記タスクリストにタスクを追加するステップであって、前記追加されたタスクが、前記仮想時計と等しいランタイムを有する、追加するステップと、をさらに含む、請求項１に記載の方法。
9. 前記埋め込みアイテムのためのコンテンツを要求するステップが、
   前記要求されたコンテンツを受信したことに応答して、前記コンテンツを処理するために前記タスクリストにタスクを追加するステップであって、前記追加されたタスクが、前記仮想時計と等しい開始時間を有する、追加するステップを含む、請求項８に記載の方法。
10. 前記タスクリストを処理するために費やされた実際の時間が、前記コンテンツを待機する時間の量による所定の時間より大きい、請求項８に記載の方法。
11. 前記仮想時計と等しい開始時間を備えたタスクのすべてが完了したと決定すると、前記仮想時計は、前記タスクリスト内の次に発生するタスクによって表される時間に進む、請求項１に記載の方法。
12. 少なくとも１つのプロセッサと、
    バッチレンダリングエンジンと、を含むコンピュータシステムであって、前記バッチレンダリングエンジンが、
    要求プロセスからウェブページをレンダリングするための要求を受信することと、
    前記ウェブページのための仮想時計を初期化することと、
    前記ウェブページをレンダリングするためにタスクリストを生成することであって、前記タスクリスト内の各タスクが、関連する開始時間を有する、生成することと、
    停止タスクを前記タスクリストに追加することと、
    前記ウェブページのための前記仮想時計に従って前記タスクリスト内の前記タスクを実行することであって、前記ウェブページのための前記仮想時計が、前記ウェブページのためのタスクリスト内の次に発生するタスクによって表される時間に設定することによって進み、前記仮想時計が、前記タスクリスト内の保留中のタスクが前記仮想時計に一致するランタイムを有している間は変化しないままである、実行することと、
    前記仮想時計が前記タスクリスト内の停止タスクのための開始時間に一致するとき、前記ウェブページのためのレンダリング結果を生成することと、
    前記要求プロセスに前記レンダリング結果を提供することと、
    を行うように構成される、コンピュータシステム。
13. 前記停止タスクが、所定の時間に設定された開始時間を有する、請求項１２に記載のコンピュータシステム。
14. 前記タスクリストを処理するために費やされた実際の時間が、埋め込みアイテムがクロールされていない場合、前記所定の時間未満である、請求項１３に記載のコンピュータシステム。
15. 前記タスクリストは、第１の開始時間を備えた第１のタスクと、第１の開始時間を備えた第２のタスクとを含み、前記第１のタスクが、埋め込みリソースのフェッチであり、前記レンダリングエンジンが、
    サーバから前記埋め込みリソースを要求することと、
    前記要求を待っている間に前記第２のタスクに取り組むことと、
    を行うように構成される、請求項１２に記載のコンピュータシステム。
16. 前記レンダリングエンジンが、
    前記サーバから前記埋め込みリソースのためのコンテンツを受信することと、
    前記埋め込みアイテムのためのコンテンツを受信したことに応答して、前記タスクリストにタスクを追加することであって、前記タスクが、前記仮想時計の現在の値と等しいそれぞれの開始時間セットを有する、追加することと、
    を行うようにさらに構成される、請求項１５に記載のコンピュータシステム。
17. 前記タスクリストに追加された前記タスクが、前記埋め込みアイテムのためのコンテンツにおいて識別されたスクリプトを実行する、請求項１６に記載のコンピュータシステム。
18. 前記タスクリストに追加された前記タスクが、前記コンテンツにおいて識別された第２の埋め込みアイテムをフェッチする、請求項１６に記載のコンピュータシステム。

Images