JP2013168156A - コンテンツサーバの待ち時間の決定 - Google Patents

Abstract

【課題】コンテンツサーバの待ち時間を決定する。
【解決手段】コンピュータ実施方法は、第１ウェブページの広告スロットに対する広告リクエストをクライアントから受信する段階と、リクエストへの応答として識別された広告に対する該広告をクライアントに表示させる命令を取得する段階と、クライアントに、取得した命令を実行することなく、該命令を第１ウェブページに表示させる第１命令を生成する段階と、クライアントに、取得した命令を実行して、広告を、該広告を要求されたコンテンツサーバに起因する待ち時間である読み込み時間とともに第２ウェブページに表示させる第２命令を生成する段階と、リクエストに応答して第１及び第２命令をクライアントに送信する段階とを有する。
【選択図】図１

Description

本開示は、情報の取り出しに関する。

ウェブページ上に表示されるコンテンツは、クライアントデバイスによるウェブページのレンダリングの間に生成された複数のコンテンツアイテムリクエストに応答して、１つ以上のコンテンツアイテムサーバによって生成されることがある。複数のコンテンツアイテムリクエストは、ウェブページのレンダリングと同期して生成される。同様に、複数のコンテンツアイテムリクエストに応答して受信された複数のコンテンツアイテムは、ウェブページのレンダリングと同期して処理される。例えば、ウェブページがレンダリングされる際、ＪａｖａＳｃｒｉｐｔが実行され、第１コンテンツサーバに広告をリクエストする。同様に、第１コンテンツサーバは、第２コンテンツサーバに広告をリクエストする。広告が同時に取り出された場合、ウェブページのレンダリングは、リクエストした広告がコンテンツサーバから受信されるまで待たされる。広告が受信され、レンダリング、例えば、ウェブページ上に広告が表示されると、ウェブページの残りの部分のレンダリングが再開される。

同期的なコンテンツアイテム取り出しの欠点は、コンテンツアイテムサーバの処理が遅い場合に、ウェブページの残りの部分のレンダリングが遅れることである。同期的なコンテンツアイテム処理の潜在的な影響を軽減するために、ウェブページ発行者は、遅延源、すなわち、低速な又は一時的に動作不能なコンテンツアイテムサーバを特定するとともに、総待ち時間を算出することを試みている。しかしながら、異なるサーバに関連した複数の待ち時間を算出するために、ウェブページのレンダリングから複数のＨＴＴＰリクエスト及びレスポンスをコンパイルすることは、多くの場合、複雑な作業となる。例えば、複数のＨＴＴＰリクエスト及びレスポンスは、第１コンテンツサーバによって返されるが、ウェブページ自体には現れないので、それらを扱い慣れていない。さらに、特定のサーバ、例えば、第２コンテンツサーバ、が遅延源であると判断できたとしても、第２コンテンツサーバの運用者にその遅延を説明することは困難である。

いくつかの実施態様によれば、発行者サーバ、第１コンテンツサーバ、及び第２コンテンツサーバのパフォーマンスの決定が行われる。発行者サーバのパフォーマンス、第１コンテンツサーバのパフォーマンス、及び第２コンテンツサーバのパフォーマンスに基づいて、待ち時間情報が決定される。待ち時間情報は、発行者サーバ、第１コンテンツサーバ、及び第２コンテンツサーバのそれぞれに関連したコンテンツ読み込み時間の長さを表す。

いくつかの実施態様によれば、第１動作に対するスクリプトへの参照を含んだドキュメントのユニフォームリソースロケータ（ＵＲＬ）が指定される。ＵＲＬには、第１引数が付加される。第２動作に対するスクリプトへの参照を含んだドキュメントのＵＲＬが指定される。ＵＲＬには、第２引数が付加される。リクエストに応答して、スクリプトを含んだドキュメントが受信される。第１動作に対するスクリプトが実行され、発行者サーバ待ち時間が決定される。第２動作に対するスクリプトが実行され、第１コンテンツサーバ待ち時間が決定される。発行者サーバ待ち時間及び第１コンテンツサーバ待ち時間に基づいて、第２コンテンツサーバ待ち時間が決定される。

いくつかの実施態様によれば、システムは、発行者サーバ、第１コンテンツサーバ、及び第２コンテンツサーバに関連したパフォーマンスを決定するように構成されたプロセッサと、発行者サーバのパフォーマンス、第１コンテンツサーバのパフォーマンス、及び第２コンテンツサーバのパフォーマンスに基づいて、待ち時間情報を決定するように構成されたクライアントデバイスとを具備する。待ち時間情報は、発行者サーバ、第１コンテンツサーバ、及び第２コンテンツサーバのそれぞれに関連したコンテンツ読み込み時間の長さを表す。いくつかの実施態様によれば、システムは、１つ以上のリモートロケーションにコンテンツをリクエストするように構成されたプロセッサと、該プロセッサに動作可能なように接続され、待ち時間情報を表示するように構成されたインタフェースとを具備する。コンテンツには、リクエストに関連した待ち時間情報を決定するための複数のコンピュータ実行可能命令が含まれる。待ち時間情報には、インタフェースへのコンテンツの表示に関連した１つ以上のリモートロケーションに関連した待ち時間が含まれる。

いくつかの実施態様によれば、コンテンツのリクエストが行われる。ここで、リクエストは、コンテンツを指し示すユニフォームリソースロケータ（ＵＲＬ）であり、該ＵＲＬは、付加された引数を含む。リクエストされたコンテンツは、第１ユーザインタフェース中のコンテンツページ内に読み込まれる。次いで、第２ユーザインタフェースが表示される。次いで、ＵＲＬに付加された引数に従って、コンテンツページに関連した１つ以上のコンテンツアイテムが、第２ユーザインタフェースに表示される。さらに、１つ以上のコンテンツアイテムに関連した１つ以上の属性が、第２ユーザインタフェースに表示される。

いくつかの実施態様によれば、コンテンツページの第１部分が、第１ユーザインタフェースに読み込まれる。ここで、第１部分は、発行者サーバから受信したコンテンツから成る。次いで、第２ユーザインタフェースが表示される。コンテンツページの第２部分が、第２ユーザインタフェースに読み込まれる。ここで、第２部分は、１つ以上のコンテンツサーバから受信した１つ以上のコンテンツアイテムから成る。さらに、１つ以上のコンテンツアイテムに関連した１つ以上の属性が、第２ユーザインタフェースに表示される。

いくつかの実施態様によれば、システムは、発行者サーバと、１つ以上のコンテンツサーバと、クライアントデバイスとを具備する。発行者サーバは、コンテンツページの第１部分をクライアントデバイスに送信するように構成される。ここで、第１部分は、発行者コンテンツから成る。さらに、１つ以上のコンテンツサーバは、コンテンツページの第２部分をクライアントデバイスに送信するように構成される。ここで、第２部分は、１つ以上のコンテンツアイテムから成る。クライアントデバイスは、コンテンツページの第１部分を第１ユーザインタフェースに読み込み、コンテンツページの第２部分を第２ユーザインタフェースに読み込み、１つ以上のコンテンツアイテムに関連した１つ以上の属性を第２ユーザインタフェースに表示するように構成される。

いくつかの実施態様によれば、システムは、クライアントデバイスと、プロセッサと
を具備する。クライアントデバイスは、１つ以上のコンテンツサーバから受信したコンテンツページに関連した１つ以上のコンテンツアイテムのコピーを保存するように構成される。さらに、プロセッサは、ユーザインタフェースを生成し、保存された１つ以上のコンテンツアイテムの結合ソースコードを生成し、結合ソースコードをユーザインタフェースに掲載するように構成される。

いくつかの実施態様によれば、システムは、発行者サーバと、サーバプロセッサとを具備する。発行者サーバは、１つ以上のコンテンツアイテムに関連した１つ以上のコンテンツアイテム識別子を取得するように構成される。サーバプロセッサは、ユーザインタフェースを生成し、１つ以上のコンテンツアイテム識別子に関連した１つ以上のコンテンツアイテムをリクエストする第１コンテンツサーバへのリクエストを生成し、１つ以上のコンテンツアイテムをユーザインタフェースにレンダリングするように構成される。

コンテンツサーバにコンテンツをリクエストするための例示的なシステムの構成図である。 待ち時間寄与率を決定するための例示的なプロセスである。 待ち時間寄与率を決定するための別の例示的なプロセスである。 ＮｏＦｅｔｃｈモードの出力を表示する例示的なインタフェースを図示する。 ＮｏＲｅｎｄｅｒモードの出力を表示する例示的なインタフェースを図示する。 待ち時間発生源を決定するための例示的なプロセスである。 １つ以上のコンテンツサーバに関連した待ち時間を決定するための例示的なプロセスである。 １つ以上のコンテンツサーバに関連した待ち時間を決定するための別の例示的なプロセスである。 １つ以上のコンテンツサーバに関連した待ち時間を決定するための別の例示的なプロセスである。 例示的なユーザインタフェースを図示したものである。

図１は、１つ以上のコンテンツサーバにコンテンツをリクエストするための例示的なシステム１０の構成図である。一実施形態において、コンテンツは、広告であってよく、コンテンツサーバは、コンテンツサーバであってよい。また、異なるタイプのコンテンツがリクエストされてもよい。

一実施形態において、クライアントシステム１００は、ネットワーク、例えば、インターネットを介してアクセス可能なコンテンツ（例えば、訪問したウェブページ）を表示するように構成される。クライアントシステム１００は、例えば、ウェブブラウザ、又は、ネットワークナビゲーションソフトウェアを実行する演算デバイスなどであってよい。クライアントシステム１００が訪問したウェブアドレス（例えば、ユニフォームリソースロケータ（ＵＲＬ））は、対応するウェブページをホスティングする発行者１０２、例えば、サーバ、を特定するために解析される。この実施例では、クライアントシステム１００は、ウェブページコンテンツ１０６のために、発行者１０２にウェブページコンテンツリクエスト１０４を送信する。発行者１２０は、リクエトに応答して、ウェブページコンテンツ１０６を、例えば、ＪａｖａＳｃｒｉｐｔを含むＨＴＭＬドキュメントとして、クライアントシステム１００に提供する。ウェブページコンテンツ１０６は、１つ以上のコンテンツ表示を含んでよい。一実施形態では、コンテンツ表示は、コンテンツサーバによって供給される広告のための広告スロットを有する。また、その他のコンテンツ表示が用いられてもよい。

発行者１０２によって提供されるウェブページコンテンツ１０６は、一連の命令群１０８への参照を含む。一実施形態では、命令群１０８は、格納命令１０８ａと、タイミング命令１０８ｂと、リクエスト命令１０８ｃとを含む。それらの命令は、リクエストしたコンテンツ、例えば、広告をレンダリング及び表示するために使用される。一実施形態では、命令群１０８は、第１コンテンツサーバ１３４、例えば、コンテンツサーバ、によって提供されるとともに、クライアントシステム１００において、例えば、ウェブブラウザに関連したキャッシュなどに格納される。

ウェブページコンテンツ１０６は、１つ以上のコンテンツサーバからのコンテンツを表示するように構成された複数のコンテンツスロット１１２〜１２０を定義してよい。一実施形態では、複数のコンテンツスロット１１２〜１２０は、ＨＴＭＬタグで定義される広告スロットである。命令群１０８は、複数のコンテンツリクエスト１２２〜１３０を生成する。複数のコンテンツリクエスト１２２〜１３０は、複数のコンテンツスロット１１２〜１２０を満たすコンテンツをリクエストするために発行される。一実施形態では、複数のリクエスト１２２〜１３０は、データ格納部１３２、例えば、バッファ１３２、に格納され、次いで、１つ以上のリクエスト１３６としてコンテンツサーバ１３４に送信される。

一実施形態では、第１コンテンツサーバ１３４は、受信した個々の又は結合されたリクエスト１３６を処理し、特定したコンテンツ１３８をクライアントシステム１００に返す。別の実施形態では、第１コンテンツサーバ１３４は、クライアントシステム１００から受信した個々の又は結合されたリクエスト１３６を処理し、結合されたレスポンス１３７をクライアントシステム１００に送信する。例えば、レスポンスは、ＨＴＭＬ又はＪａｖａＳｃｒｉｐｔであってよい。第１コンテンツサーバ１３４からクライアントシステム１００への結合されたレスポンス１３７は、コンテンツアイテムをリクエストする１つ以上のリクエスト１４０を第２コンテンツサーバ１４２に送信するように、クライアントシステム１００に命令する。次いで、第２コンテンツサーバ１４２は、例えば、特定したコンテンツ１４４をクライアントシステム１００に返す。次いで、特定されたコンテンツ１３８及び／又は特定されたコンテンツ１４４は、対応するコンテンツスロット、例えば、複数のコンテンツスロット１１２，１１４，１１６に発行者のウェブページの一部分として表示される。

第１コンテンツサーバ１３４の一例として、Ｇｏｏｇｌｅ（登録商標）コンテンツサーバが挙げられる。リクエストは、Ｇｏｏｇｌｅコンテンツサーバに、ウェブページ上のコンテンツスロットを広告で埋めるよう求める。続いて、Ｇｏｏｇｌｅコンテンツサーバは、広告を特定及び提供するか、又は、第２コンテンツサーバ１４２、例えば、第三者のコンテンツサーバ、に広告をリクエストする。２つのコンテンツサーバ１３４，１４２だけに言及したが、１つのウェブページに対して、２つ以上のコンテンツサーバがコンテンツを提供してもよい。

クライアントシステム１００が発行者１０２、第１コンテンツサーバ１３４、及び／又は第２コンテンツサーバ１４２にコンテンツをリクエストした際、待ち時間による遅延が生じることがある。例えば、待ち時間遅延は、低いネットワーク速度、発行者サーバ１０２の遅れ、第１コンテンツサーバの遅れ、及び／又は、第２コンテンツサーバの遅れなどのさまざまな問題に関係している。クライアントシステム１００のユーザは、ウェブページの読み込みに要する総待ち時間しか認識できない。したがって、発行者サーバ１０２、第１コンテンツサーバ１３４、及び第２コンテンツサーバ１４２に起因する待ち時間遅延寄与率を決定することは、実証困難である。

以上の例で説明したように、ウェブページを表示するための総待ち時間（Ｌ）は、ネットワークの速度と、ネットワークの待ち時間を含む発行者サーバ１０２の速度（Ｌ１）と、第１コンテンツサーバ１３４の速度（Ｌ２）と、第２コンテンツサーバ１４２の速度（Ｌ３）とに起因する。したがって、例えば、総待ち時間の算出は、式Ｌ＝Ｌ１＋Ｌ２＋Ｌ３によって行うことができる。

図２を参照すると、いくつかの実施形態によれば、待ち時間寄与率を決定するための例示的なプロセス２００は、発行者サーバのパフォーマンスの決定から始まる（ステップ２０２）。発行者サーバ１２０のパフォーマンスを決定するために、発行者サーバ１０２へのコンテンツのリクエストは、引数（又は、その他の指示子）を含むように生成される。例えば、「http://www.webpage.com?google_nofetch」のように、引数「google_nofetch」がウェブページコンテンツ所在地のＵＲＬに付加される。この場合、ＮｏＦｅｔｃｈモードが実行される。

リクエストしたＵＲＬに関連したドキュメントが、コンテンツの所在地から受信される。ドキュメントは、ウェブページコンテンツ、メディア、テキスト、ダウンロード可能なファイル等であってよい。発行者サーバ１０２に関連したパフォーマンス、すなわち、待ち時間が決定される。いくつかの実施形態では、ウェブページコンテンツ１０６内のコンテンツサービング（例えば、ＪａｖａＳｃｒｉｐｔ）タグは、診断ロジックを実行する。例えば、ウェブページコンテンツ１０６内のスクリプトファイルは、発行者サーバ１０２に関連した待ち時間などのさまざまな条件についてテストを行い、ユーザインタフェースに情報を書き出す。

ＮｏＦｅｔｃｈモードでは、ウェブページコンテンツ１０６内のスクリプトファイルは、第１コンテンツサーバ１３４からのコンテンツアイテムの読み込み、すなわち、広告のために第１コンテンツサーバ１３４になされるリクエストを止めさせる。例えば、第１コンテンツサーバ１３４に送信されたすべてのリクエストは、ＮＯ−ＯＰ命令に置き換えられ、それらのリクエストは、（デバッグトレースを除き、）何も行わない。したがって、ＮｏＦｅｔｃｈモードでの動作は、ウェブページに対する発行者サーバ１０２のベースラインパフォーマンス、すなわち、発行者がウェブページに１つも広告を追加しなかった場合にユーザが体験するＮｏＦｅｔｃｈ待ち時間（Ｌ１）を確定する。

次に、第１コンテンツサーバ１３４に関連したパフォーマンスが決定される（ステップ２０４）。第１コンテンツサーバ１３４のパフォーマンスを決定するために、引数（又は、その他の指示子）がウェブページ所在地のＵＲＬに含められる。例えば、「http://www.webpage.com?google_norender」のように、引数「google_norender」がウェブページコンテンツ所在地のＵＲＬに追加される。この場合、ＮｏＲｅｎｄｅｒモードが実行される。

いくつかの実施形態では、ウェブページコンテンツ１０６内のコンテンツサービング（例えば、ＪａｖａＳｃｒｉｐｔ）タグは、診断ロジックを実行する。例えば、ウェブページコンテンツ１０６内のスクリプトファイルは、第１コンテンツサーバ１３４に関連したパフォーマンス、すなわち、待ち時間などのさまざまな条件をテストするとともに、ユーザインタフェースに情報を書き出す。

ＮｏＲｅｎｄｅｒモードでは、ウェブページコンテンツ１０６内のスクリプトファイルは、第１コンテンツサーバ１３４がコンテンツアイテムを返すこと、すなわち、リクエストが第１コンテンツサーバ１３４に送信され、広告が取り出されることは許可する。しかしながら、第１コンテンツサーバ１３４が広告を取り出した後、スクリプトファイルは、ウェブページ上に広告をレンダリングさせない。例えば、ウェブページ上の複数のコンテンツスロット１１２，１１４，１１６に実際の広告をレンダリングする代わりに、複数のコンテンツスロット１１２，１１４，１１６中の広告に関連したコードが表示されてもよい。したがって、ＮｏＲｅｎｄｅｒモードの動作は、広告を取り出すがそれをレンダリングしない場合の第１コンテンツサーバ１３４のパフォーマンス、すなわち、待ち時間を確定する。第１コンテンツサーバ１３４に関連した待ち時間は、ＮｏＲｅｎｄｅｒ待ち時間からＮｏＦｅｔｃｈ待ち時間を差し引くこと、すなわち、Ｌ２＝ＮｏＲｅｎｄｅｒ待ち時間−ＮｏＦｅｔｃｈ待ち時間（Ｌ１）によって算出できる。

ステップ２０６において、第２コンテンツサーバ１４２のパフォーマンスが決定される。第２コンテンツサーバ１４２のパフォーマンスを決定するために、第１コンテンツサーバ１３４へのコンテンツのリクエストは、ウェブページコンテンツ所在地のＵＲＬを、「http://www.webpage.com」のように、引数なしでリクエストすることによって生成される。ＵＲＬのリクエスト及びレンダリングに関連したページ読み込み総時間は、総待ち時間（Ｌ）に相当する。故に、第２コンテンツサーバ１４２に関連した待ち時間は、総待ち時間からＮｏＲｅｎｄｅｒ待ち時間を差し引くこと、すなわち、Ｌ３＝総待ち時間（Ｌ）−ＮｏＲｅｎｄｅｒ（Ｌ２）によって算出できる。

発行者サーバ、第１コンテンツサーバ、及び第２コンテンツサーバのパフォーマンスが決定された後、発行者サーバのパフォーマンス、第１コンテンツサーバのパフォーマンス、及び第２コンテンツサーバのパフォーマンスに基づき、待ち時間情報が決定される（ステップ２０８）。待ち時間情報は、発行者サーバ、第１コンテンツサーバ、及び第２コンテンツサーバのそれぞれに関連したコンテンツ読み込み時間の長さを表す。例えば、ユーザインタフェースが生成され、かつ異なる構成要素に起因した待ち時間に関する情報が、そのユーザインタフェースに書き出される。いくつかの実施形態では、ユーザインタフェースは、ＪａｖａＳｃｒｉｐｔコードによって生成され、単独のブラウザウィンドウを提供する。

図３は、待ち時間寄与率を決定するための別の例示的なプロセス３００である。待ち時間寄与率を決定するための例示的なプロセス３００は、スクリプトへの参照を含んだドキュメントをリクエストするために、ＵＲＬ（Uniform Resource Locator）を提示することから始まる（ステップ３０２）。上記リクエストには、ＵＲＬに付加された第１引数が含まれる。例えば、第１引数「google_nofetch」が、「http://www.webpage.com?google_nofetch」のように、ウェブページコンテンツの所在地のＵＲＬに付加される。この場合、ＮｏＦｅｔｃｈモードが実行される。

次に、プロセス３００は、スクリプトへの参照を含んだドキュメントをリクエストするためのＵＲＬを提示する（ステップ３０４）。上記リクエストには、ＵＲＬに付加された第２引数が含まれる。例えば、引数「google_norender」が、「http://www.webpage.com?google_norender」のように、ウェブページコンテンツの所在地のＵＲＬに付加される。この場合、ＮｏＲｅｎｄｅｒモードが実行される。

ステップ３０２及びステップ３０４でのリクエストに応答して、スクリプトを含んだドキュメントが取り出される（ステップ３０６）。ドキュメントを受信した後、スクリプトは、第１引数及び第２引数に従って、発行者サーバの待ち時間及び第１コンテンツサーバの待ち時間を決定するために実行される。例えば、スクリプトは、第１引数に従って、ＮｏＦｅｔｃｈモードを実行するとともに、第２引数に従って、ＮｏＲｅｎｄｅｒモードを実行する。発行者サーバの待ち時間及び第１コンテンツサーバの待ち時間に基づいて、第２コンテンツサーバの待ち時間が決定される（ステップ３１０）。

図４は、ＮｏＦｅｔｃｈモードを実行するスクリプトの第１動作の出力を表示する例示的なインタフェース４００を示す。図４の列４０２は、ＮｏＦｅｔｃｈモードで実行される命令に関連した待ち時間を示す。例えば、待ち時間は、スクリプト実行に応じて増大する実行時間として表される。図２の列４０４は、ＮｏＦｅｔｃｈモードを実行するスクリプトによって処理される命令のメッセージタイプを提供する。図４の列４０６は、ＮｏＦｅｔｃｈモードを実行するスクリプトによって処理される命令を示す要約メッセージを提供する。ＮｏＦｅｔｃｈモードでは、ウェブページコンテンツ１０６内のスクリプトファイルの実行は、１つ以上のコンテンツサーバからの広告の取り出しを止めさせる。図４に符号４０８で示すように、スクリプトが広告（ads）のフェッチを抑制することによって、ＮｏＦｅｔｃｈモードでの待ち時間情報は、発行者サーバに依存したものとなる。

スクリプトの第１動作を実行した後、スクリプトの第２動作が、第１コンテンツサーバの待ち時間を決定するために実行される（ステップ３１０）。スクリプトの第２動作は、ＮｏＲｅｎｄｅｒモードを実行する。図５は、ＮｏＲｅｎｄｅｒモードの出力を表示する例示的なインタフェース５００を示す。図５の列５０２は、ＮｏＲｅｎｄｅｒモードを実行するスクリプトに関連した待ち時間を示す。例えば、待ち時間は、スクリプトの実行とともに増大する実行時間として表される。図５の列５０４は、ＮｏＲｅｎｄｅｒモードを実行するスクリプトによって処理される命令のメッセージタイプを提供する。図５の列５０６は、ＮｏＲｅｎｄｅｒモードを実行するスクリプトによって処理される命令を示す要約メッセージを提供する。ＮｏＲｅｎｄｅｒモードの実行は、図５に符号５０８で示すように、広告を取り出すが、それをレンダリングしない場合の第１コンテンツサーバ１３４のパフォーマンスを確定する。第１コンテンツサーバ１３４に関連した待ち時間は、ＮｏＲｅｎｄｅｒ待ち時間からＮｏＦｅｔｃｈ待ち時間を差し引くこと、すなわち、Ｌ２＝ＮｏＲｅｎｄｅｒ待ち時間−ＮｏＦｅｔｃｈ待ち時間（Ｌ１）によって算出できる。

ＮｏＦｅｔｃｈ及びＮｏＲｅｎｄｅｒモードでのドキュメント実行の後、発行者サーバの待ち時間及び第１コンテンツサーバの待ち時間に基づいて、第２コンテンツサーバの待ち時間が決定される。第２コンテンツサーバ１４２のパフォーマンスを決定するために、ウェブページコンテンツの所在地のＵＲＬを、「http://www.webpage.com」のように、引数なしで発行者サーバ１０２に提示することによって、第１コンテンツサーバ１３４へのコンテンツリクエストが生成される。ＵＲＬのリクエスト及びレンダリングに関連したページ読み込み総時間は、総待ち時間（Ｌ）に実質的に等しい。故に、第２コンテンツサーバ１４２に関連した待ち時間は、総待ち時間からＮｏＲｅｎｄｅｒ待ち時間を差し引くこと、すなわち、Ｌ３＝総待ち時間（Ｌ）−ＮｏＲｅｎｄｅｒ待ち時間（Ｌ２）によって算出できる。

図６は、待ち時間の発生源を決定するための例示的なプロセス６００である。発行者サーバ、第１コンテンツサーバ、及び第２コンテンツサーバに関連した待ち時間の決定に基づき、コンテンツページに関連した読み込み時間遅延源が決定される。判断ステップ６０２においてＬ１が低速であると判断された場合、待ち時間源は、発行者サーバ１０２に起因する可能性が最も高い（ステップ６０４）。しかしながら、判断ステップ６０２においてＬ１が高速であると判断された場合、プロセス６００は判断ステップ６０６に進む。判断ステップ６０６においてＬ２が低速であると判断された場合、待ち時間源は、第１コンテンツサーバ１３４に起因する可能性が最も高い（ステップ６０８）。判断ステップ６０６においてＬ２が高速であると判断された場合、プロセス６００は判断ステップ６１０に進む。判断ステップ６１０においてＬ３が高速であると判断された場合、コンテンツページ読み込み待ち時間は小さいとみなされる（Ｌ１、Ｌ２、及びＬ３はすべて高速であると判断される）（ステップ６１２）。しかしながら、判断ステップ６１０においてＬ３が低速であると判断された場合、待ち時間源は、第２コンテンツサーバ１４２に起因する可能性が最も高い（ステップ６１４）。

上記の例示的なプロセスに基づき、待ち時間源が第２コンテンツサーバ１４２に起因する可能性が最も高いと判断されたとする。この判断に基づき、第２コンテンツサーバ１４２など、１つ以上のコンテンツサーバに関連した待ち時間を決定するための例示的なプロセス７００が図７に示される。最初に、コンテンツがリクエストされる（ステップ７０２）。ここで、リクエストは、コンテンツを指し示すユニフォームリソースロケータ（ＵＲＬ）であり、ＵＲＬには、付加された引数が含まれる。リクエストに応答して受信したコンテンツは、第１インタフェースのコンテンツページに読み込まれる（ステップ７０４）。一実施形態では、コンテンツページに読み込まれたコンテンツは、コンテンツの第１部分である。ここで、コンテンツの第１部分は、発行者サーバ１０２からのコンテンツのみを含む。

次に、第２ユーザインタフェースが表示される（ステップ７０６）。第２ユーザインタフェースを表示するために、スクリプトを含んだドキュメントがリクエストされる。ここで、リクエストには、指示子が含まれる。例えば、リクエストは、ドキュメントを受信するよう指示するユニフォームリソースロケータ（ＵＲＬ）であり、指示子は、ＵＲＬに付加された引数である。次いで、ドキュメントは、例えば、リクエストに応答して受信される。次いで、指示子の受信に応答して第２ユーザインタフェースを表示するように、スクリプトが実行される。例えば、第２ユーザインタフェースは、コンテンツページを表示するブラウザウィンドウとは別個のブラウザウィンドウであってよい。

別の実施形態では、第１及び第２ユーザインタフェースは、同一のインタフェースに表示される。第１及び第２ユーザインタフェースは、共通のクライアントデバイス上の共通のブラウザによってレンダリングされる。例えば、第１及び第２ユーザインタフェースは、クライアントデバイス上で実行されるブラウザウィンドウのような１つのユーザインタフェース中にレンダリングされる。

続いて、コンテンツページに関連した１つ以上のコンテンツアイテム、例えば、広告が、ＵＲＬに付加された引数に従って、第２ユーザインタフェースに表示される（ステップ７０８）。さらに、第２ユーザインタフェース中のコンテンツアイテム毎に１つ以上の属性が表示される（ステップ７１０）。例えば、表示される属性は、各コンテンツアイテムに関連した読み込み時間及び総読み込み時間である。

一実施形態では、１つ以上のコンテンツアイテムの表示は、クライアント側の処理系を使用することによって達成される。例えば、コンテンツアイテムスロットに挿入するための１つ以上のコンテンツアイテムのコピーが、１つ以上のコンテンツサーバから受信され、保存される。次いで、読み込み時コールバックが、コンテンツページに対して登録される。読み込み時コールバックの間、第２ユーザインタフェースが表示され、かつコンテンツアイテムスロットのスキャンが行われる。コンテンツアイテムスロットのスキャンが行われた後、コンテンツアイテムに関連したすべてのコード、例えば、ＨＴＭＬコードが結合される。次いで、結合されたＨＴＭＬコードは、第２ユーザインタフェースに挿入され、かつすべてのコンテンツアイテムが生成される。

別の実施形態では、第２ユーザインタフェースへの１つ以上のコンテンツアイテムの表示は、サーバ側処理系を使用することによって達成される。例えば、１つ以上のコンテンツアイテムに関連した１つ以上のコンテンツアイテム識別子は、ＪａｖａＳｃｒｉｐｔを用いて取得される。次いで、第２ユーザインタフェースが開かれ、かつ１つ以上の広告識別子を使用することによって、１つ以上のコンテンツアイテムのためのリクエストが、１つ以上のコンテンツサーバに対して生成される。次いで、１つ以上のコンテンツサーバから受信した１つ以上のコンテンツアイテムが、例えば、第２ユーザインタフェースにレンダリングされる。ある実施形態では、各コンテンツアイテムに関連した読み込み時間が、第２ユーザインタフェースに表示される。ある実施形態では、総読み込み時間が、第２ユーザインタフェースに表示される。

いくつかの実施形態では、第２ユーザインタフェースに関連したソースコードが保存される。例えば、ユーザは、第２ユーザインタフェース中のページのソースコードを閲覧及び保存できる。ソースコードの保存は、１つ以上のコンテンツアイテムの待ち時間を、待ち時間の原因であるコンテンツサーバの運用者に説明するために有用である。特に、ソースコードは、どの（複数の）コンテンツアイテム、すなわち、（複数の）広告が読み込み時間の最も大きい遅れを生み出しているのかを特定するために使用される。ソースコードは、例えば、コンテンツサーバの運用者に、直接、電子メールできる。次いで、ソースコードは、ユーザインタフェース、例えば、ブラウザ、に読み込まれ、特定の（複数の）コンテンツアイテムの待ち時間を説明する。

第２コンテンツサーバ１４２などの１つ以上のコンテンツサーバに関連した待ち時間を決定するための別の例示的なプロセス８００が図８に示される。コンテンツページに関連した待ち時間源が決定された後、コンテンツページの第１部分が、第１ユーザインタフェースに読み込まれる（ステップ８０２）。ここで、第１部分は、発行者サーバから受信したコンテンツを含む。例えば、コンテンツの第１部分は、１つ以上のコンテンツサーバからの１つ以上のコンテンツアイテムを含まない。

次に、第２ユーザインタフェースが表示される（ステップ８０４）。続いて、コンテンツページの第２部分に関連したソースコード、すなわち、ＨＴＭＬコードが、第２ユーザインタフェースに表示される（ステップ８０６）。ここで、第２部分は、１つ以上のコンテンツサーバから受信した１つ以上のコンテンツアイテムを含む。１つ以上のコンテンツアイテムに関連したソースコード、すなわち、ＨＴＭＬコードを第２ユーザインタフェースに表示するために、スクリプトを含んだドキュメントがリクエストされる。ここで、リクエストは、指示子を含む。例えば、リクエストは、ドキュメントを受信するように指示するユニフォームリソースロケータ（ＵＲＬ）であり、指示子は、ＵＲＬに付加された引数である。次いで、ドキュメントは、例えば、リクエストに応答して受信される。次いで、指示子の受信に応答して、１つ以上のコンテンツアイテムに関連したソースコードを含んだ第２ユーザインタフェースを表示するように、スクリプトが実行される。

例えば、「http://www.webpage.com?google_capture_norender」のように、引数「google_capture_norender」がウェブページコンテンツ所在地のＵＲＬに付加される。それに応答して、１つ以上のコンテンツアイテムに関連したソースコードを含んだ第２ユーザインタフェースが表示される。次いで、ソースコードは、例えば、コピーされ（ステップ８０８）、エディタにペーストされ（ステップ８１０）、次いで、ローカルＨＴＭＬファイルなどのファイルに保存される（ステップ８１２）。その後、インタフェース、例えば、ブラウザ又はその他のユーザインタフェースは、ファイル、例えば、ローカルＨＴＭＬファイル、を開くために使用される（ステップ８１４）。ファイルには、１つ以上のコンテンツアイテムに関連したソースコードが含まれる。ファイルを開いたとき、ファイルは、コンテンツページに関連した１つ以上のコンテンツアイテムをユーザインタフェースにレンダリングする（ステップ８１６）。さらに、１つ以上のコンテンツアイテムに関連した１つ以上の属性が、ユーザインタフェースに表示される（ステップ８１８）。例えば、属性は、各コンテンツアイテムに関連した読み込み時間及び１つ以上のコンテンツアイテムに関連した総読み込み時間を含む。

図９は、第２コンテンツサーバ１４２などの１つ以上のコンテンツサーバに関連した待ち時間を決定するための別の例示的なプロセス９００である。プロセス９００は、コンテンツページの第１部分を第１ユーザインタフェースに読み込むことから開始される（ステップ９０２）。ここで、第１部分は、発行者サーバから受信したコンテンツを含む。例えば、第１ユーザインタフェースに読み込まれたコンテンツページの第１部分は、１つ以上のコンテンツサーバからのコンテンツを含まない。次に、第２ユーザインタフェースが表示される（ステップ９０４）。例えば、第２ユーザインタフェースは、ポップアップウィンドウのようなウィンドウであり、第１ユーザインタフェースに追加的に表示される。

次いで、コンテンツページの第２部分が、例えば、第２ユーザインタフェースに表示される（ステップ９０６）。ここで、第２部分は、１つ以上のコンテンツサーバから受信した１つ以上のコンテンツアイテムを含む。さらに、１つ以上のコンテンツアイテムに関連した１つ以上の属性が、第２ユーザインタフェースに表示される（ステップ９０８）。例えば、属性は、各コンテンツアイテムに関連した読み込み時間と、１つ以上のコンテンツアイテムに関連した総読み込み時間とを含む。

図１０は、上記のプロセスで説明した例示的な第２ユーザインタフェース１０００を示す。先に記載したように、１つ以上のコンテンツアイテムに関連した１つ以上の属性が、第２ユーザインタフェース１０００に表示される。一実施形態では、各コンテンツアイテムに関連した位置及びサイズ情報１００２が、第２ユーザインタフェース１０００に表示される。別の実施形態では、コンテンツアイテム１００４が、第２ユーザインタフェース１０００に表示される。別の実施形態では、各広告に関連した読み込み時間１００６が、第２ユーザインタフェース１０００に表示される。例えば、個々の読み込み時間１００６は、位置及びサイズ情報１００２と共に表示される広告１００４に関連する。別の実施形態では、総読み込み時間１００６が、第２ユーザインタフェース１０００に表示される。

本明細書に記載された装置、方法、フロー図、及び構成図は、コンピュータ処理システムによって実行可能な複数のプログラム命令から成るプログラムコードを含んだコンピュータ処理システムで実現されてよい。また、他の実施形態が用いられてもよい。さらにまた、特定の方法、及び／又は、複数のステップをサポートする対応する動作及び記載された構造的手段をサポートする対応する機能を説明した本明細書に記載されたフロー図及び構成図は、対応するソフトウェアストラクチャ及びアルゴリズム、並びにその均等物を実現するために使用されてもよい。

明細書中の記載は、発明の最良の形態を示すとともに、発明を説明するための、かつその発明を当業者が実施及び利用できるようにするための実施例を提供する。明細書中の記載は、そこに示された詳細な条件に発明を限定するものではない。故に、発明は上記に示された実施例を参照して詳細に説明されるが、当業者は、発明の範囲から逸脱することなく、そのような実施例に置換、修正、及び変更を行うことができる。

１０ コンテンツリクエストシステム
１００ クライアントシステム
１０２ 発行者
１０４ ウェブページコンテンツリクエスト
１０６ ウェブページコンテンツ
１０８，１１０ 命令群
１０８ａ，１１０ａ 格納命令
１０８ｂ，１１０ｂ タイミング命令
１０８ｃ，１１０ｃ リクエスト命令
１１２，１１４，１１６，１１８，１２０ コンテンツスロット
１２２，１２４，１２６，１２８，１３０ コンテンツリクエスト
１３２ データ格納部（バッファ）
１３４ 第１コンテンツサーバ
１３６，１４０ リクエスト
１３７ レスポンス
１３８，１４４ 特定されたコンテンツ
１４２ 第２コンテンツサーバ

Claims (22)

1. コンピュータ実施方法であって、
   第１ウェブページの複数の広告スロットに対する広告を要求する広告リクエストをクライアントデバイスから受信する段階と、
   前記広告リクエストへの応答として識別された複数の広告の各々に対する個々の命令を取得する段階と、
   第１命令を生成する段階と、
   第２命令を生成する段階と、
   前記広告リクエストを受信したことに応答して、前記第１及び第２命令を前記クライアントデバイスに送信する段階と
   を有し、
   取得した前記個々の命令は、前記クライアントデバイスによって実行されたとき、前記クライアントデバイスに、前記複数の広告のうちの１つの広告を表示させるように構成され、
   前記第１命令は、前記クライアントデバイスによって実行されたとき、前記クライアントデバイスに、取得した前記個々の命令を実行することなく、取得した前記個々の命令を前記第１ウェブページに表示させるように構成され、
   前記第２命令は、前記クライアントデバイスによって実行されたとき、前記クライアントデバイスに、取得した前記個々の命令を実行して、前記複数の広告の各々を、対応する読み込み時間とともに、第２ウェブページに表示させるように構成され、
   前記対応する読み込み時間は、広告を要求されたコンテンツサーバに起因する待ち時間であり、
   前記第１命令は、前記クライアントデバイスによって実行されたとき、前記クライアントデバイスに、取得した前記個々の命令を前記第１ウェブページに表示させることにより、前記クライアントデバイスのユーザが、取得した前記個々の命令の少なくとも一部分のコピーを前記対応する読み込み時間の評価を行う第三者に電子的に提供可能とすることを特徴とする方法。
2. 前記第２命令は、前記クライアントデバイスによって実行されたとき、前記クライアントデバイスに、総読み込み時間を前記第２ウェブページに表示させるようにさらに構成され、
   前記総読み込み時間は、前記複数の広告のすべてを対象とした読み込み時間であることを特徴とする請求項１に記載の方法。
3. 前記第１命令を前記第１ウェブページに表示することを指示する引数を含んだリクエストを受信する段階をさらに有することを特徴とする請求項１に記載の方法。
4. 前記第１ウェブページでの表示のために第１命令を提供する段階をさらに有することを特徴とする請求項３に記載の方法。
5. 前記第１命令が、ハイパーテキストマークアップランゲージ（ＨＴＭＬ）で記述された命令であることを特徴とする請求項３に記載の方法。
6. 前記第１命令が、ＪａｖａＳｃｒｉｐｔで記述された命令であることを特徴とする請求項３に記載の方法。
7. 前記複数の広告のうちの１つの広告が、コンテンツサーバによって識別された広告であることを特徴とする請求項１に記載の方法。
8. 第１ウェブページの複数の広告スロットに対する広告を要求する広告リクエストをクライアントデバイスから受信する手順と、
   前記広告リクエストへの応答として識別された複数の広告の各々に対する個々の命令を取得する手順と、
   第１命令を生成する手順と、
   第２命令を生成する手順と、
   前記広告リクエストを受信したことに応答して、前記第１及び第２命令を前記クライアントデバイスに送信する手順と
   を実行するように構成された１つ以上のコンピュータを具備し、
   取得した前記個々の命令は、前記クライアントデバイスによって実行されたとき、前記クライアントデバイスに、前記複数の広告のうちの１つの広告を表示させるように構成され、
   前記第１命令は、前記クライアントデバイスによって実行されたとき、前記クライアントデバイスに、取得した前記個々の命令を実行することなく、取得した前記個々の命令を前記第１ウェブページに表示させるように構成され、
   前記第２命令は、前記クライアントデバイスによって実行されたとき、前記クライアントデバイスに、取得した前記個々の命令を実行して、前記複数の広告の各々を、対応する読み込み時間とともに、第２ウェブページに表示させるように構成され、
   前記対応する読み込み時間は、広告を要求されたコンテンツサーバに起因する待ち時間であり、
   前記第１命令は、前記クライアントデバイスによって実行されたとき、前記クライアントデバイスに、取得した前記個々の命令を前記第１ウェブページに表示させることにより、前記クライアントデバイスのユーザが、取得した前記個々の命令の少なくとも一部分のコピーを前記対応する読み込み時間の評価を行う第三者に電子的に提供可能とすることを特徴とするシステム。
9. 前記第２命令は、前記クライアントデバイスによって実行されたとき、前記クライアントデバイスに、総読み込み時間を前記第２ウェブページに表示させるようにさらに構成され、
   前記総読み込み時間は、前記複数の広告のすべてを対象とした読み込み時間であることを特徴とする請求項８に記載のシステム。
10. 前記１つ以上のコンピュータが、前記第１命令を前記第１ウェブページに表示することを指示する引数を含んだリクエストを受信する手順をさらに実行するように構成されることを特徴とする請求項８に記載のシステム。
11. 前記１つ以上のコンピュータが、前記第１ウェブページでの表示のために第１命令を提供する手順をさらに実行するように構成されることを特徴とする請求項１０に記載のシステム。
12. 前記第１命令が、ハイパーテキストマークアップランゲージ（ＨＴＭＬ）で記述された命令であることを特徴とする請求項１０に記載のシステム。
13. 前記第１命令が、ＪａｖａＳｃｒｉｐｔで記述された命令であることを特徴とする請求項１０に記載のシステム。
14. 前記複数の広告のうちの１つの広告が、コンテンツサーバによって識別された広告であることを特徴とする請求項８に記載のシステム。
15. 前記第１命令が、前記第１ウェブページに対する読み込み時コールバックを登録するための命令を含み、
    前記読み込み時コールバックの間、前記第２ウェブページが表示されることを特徴とする請求項１に記載の方法。
16. 前記第２命令が、前記読み込み時コールバックの命令を含み、
    前記読み込み時コールバックの命令は、前記クライアントデバイスによって実行されたとき、前記クライアントデバイスに、前記複数の広告スロットをスキャンさせ、広告毎にＨＴＭＬコードを生成させ、生成した前記ＨＴＭＬコードを結合させるように構成されることを特徴とする請求項１５に記載の方法。
17. 前記読み込み時コールバックは、前記クライアントデバイスによる前記第１ウェブページの読み込み時に呼び出されることを特徴とする請求項１６に記載の方法。
18. 前記複数の広告が、前記第１ウェブページに表示されないことを特徴とする請求項１に記載の方法。
19. 前記第１命令が、前記第１ウェブページに対する読み込み時コールバックを登録するための命令を含み、
    前記読み込み時コールバックの間、前記第２ウェブページが表示されることを特徴とする請求項８に記載のシステム。
20. 前記第２命令が、前記読み込み時コールバックの命令を含み、
    前記読み込み時コールバックの命令は、前記クライアントデバイスによって実行されたとき、前記クライアントデバイスに、前記複数の広告スロットをスキャンさせ、広告毎にＨＴＭＬコードを生成させ、生成した前記ＨＴＭＬコードを結合させるように構成されることを特徴とする請求項１９に記載のシステム。
21. 前記読み込み時コールバックは、前記クライアントデバイスによる前記第１ウェブページの読み込み時に呼び出されることを特徴とする請求項２０に記載のシステム。
22. 前記複数の広告が、前記第１ウェブページに表示されないことを特徴とする請求項８に記載のシステム。