Content request optimization

The occurrence of a request event is monitored during the rendering of a browser page. In response to monitoring the occurrence of the request event, content item request instructions are loaded and executed to generate one or more content item requests based on the content item request instructions.

FIELD

This disclosure relates to information retrieval.

BACKGROUND

Content displayed on a web page can be generated by one or more content item servers in response to content item requests that are generated during the rendering of the web page by a client device. The content item requests can be generated synchronously with respect to the rendering of the web page. Likewise, the content items received in response to the content item requests can be processed synchronously with respect to the rendering of the web page. For example, when a web page is rendered, a javascript may execute and request an advertisement from an advertisement server. If the advertisement is retrieved synchronously, the rendering of the web page is delayed until a requested advertisement is received from the advertisement server. Once the advertisement is received and rendered, e.g., displayed on the web page, the rendering of the remainder of the web page resumes.

A drawback of synchronous content item retrieval, however, is that if a content item server is slow or temporarily inoperable, then the remainder of the web page will not render. To mitigate the potentially deleterious effects of synchronous content item processing, an asynchronous content item environment can be defined, e.g., an iFrame. However, a web page publisher may desire that a content item be an integrated feature of a web page and not defined within an iFrame, or that a content item be presented in a synchronous content item environment. Additionally, it is often a relatively complex task to recode a web page source file to ensure that content items are retrieved asynchronously, e.g., recoding to ensure that content items are rendered in an iFrame.

SUMMARY

Disclosed herein are systems and methods for generating content item requests and retrieving content items requests for a web page in a manner that does not impede the rendering of the remainder of the web page. In an implementation, a system includes a data store storing page instructions, monitoring instructions, and loading instructions. Upon execution by a browser, the page instructions cause the browser to render a web page, and the monitoring instructions cause the browser to monitor for the occurrence of a request event. In response to the monitored occurrence of the request event, the loading instructions are executed, which causes the browser to append content item request instructions to the page instructions, and execution of the content item request instructions by the browser causes the browser to transmit one or more content item requests to a content item server.

In an implementation, a browser renders in a first thread a web page from a source document, and defines in the first thread one or more content item environments in the web page. In a second thread, the browser monitors for an occurrence of a request event. In response to the occurrence of the request event, the browser loads in the second thread content item request instructions and executes the content item request instructions in the second thread to generate one or more content item requests.

In an implementation, a browser renders a browser page according to instructions in a source document, and monitors for an occurrence of a request event. In response to monitoring the occurrence of the request event, the browser loads content item request instructions in the source document and generates one or more content item requests based on the content item request instructions.

These and other example implementations can include one or more of the following features or advantages. In one implementation, the rendering of web page content defined in a source document is handled by a first thread, and the content item request processing and content item rendering are handled by a second thread. Accordingly, a slow or non-responsive content item server will not delay processing and rendering of the web page content handled by the first thread. Additionally, content item environments need not be defined in asynchronous environments, e.g., iFrames, to support asynchronous processing.

DETAILED DESCRIPTION

FIG. 1is a block diagram of an exemplary system10for requesting content from a source, e.g., a content item server. In one implementation, the content may include advertisements (“ads”), and the content item server can be an advertisement server. Different types of content can also be requested, e.g., weather, driving directions, trivia, etc.

The requesting device, in the implementation shown, is a client system100that is configured to visit web pages over a network, e.g., the Internet. The client system100can, for example, be a web browser, a computing device, a mobile communication device, or some other device executing network navigation software and the like. The web address visited by the client system100can be resolved to identify a publisher102, e.g., a server, hosting a corresponding web page. The client system100thus sends a web page content request104to the publisher102for the web page content106, e.g., a hypertext markup language (HTML) source document, and the publisher102, in response to the request, provides the web page content106to the client system100.

In an implementation, the web page content106can, for example, include a head section108and a body section110, each section having interpreted instructions. The head section108can, for example, be interpreted before the body section110. In an implementation, first instructions112are executed in the head section108to define one or more content item environments122,124and126in the web page. For example, the content item environments122,124and126can comprise advertisement slots that are rendered and displayed in the approximate positions as depicted in the body section110of the web page content106. In one implementation, the content item environments122,124and126can be synchronous environments, e.g., within the same frame in which the web page content106is rendered, within a div, etc. In another implementation, the content item environments122,124and126can be asynchronous environments, e.g., iFrames.

In an implementation, the first instructions112can, for example, include a reference to a set of second instructions114, e.g., a function call. For example, the first instructions112can generate a preliminary content item request as a function call, e.g., “fetch_content_items( )” which calls the second instructions114. The second instructions114can, for example, include monitoring instructions114aand loading instructions114bthat are used to monitor for the occurrence of a request event and generate content item request instructions and/or content item requests in response to the occurrence of the request event. In an implementation, the second instructions114are provided by a content item server140, e.g., an advertisement server, and are stored at the client system100, such as in a cache associated with a web browser.

In an implementation, execution of the first instructions112causes the monitoring instructions114ato execute a process that will trigger a request event. The process can, for example, be realized by a timer, the expiration of which is associated with the occurrence of a request event. In response to the monitoring of the request event, the loading instructions114bcan be executed to load content item request instructions116that, upon execution, cause the client system100to generate content item requests for the content environment122,124and126.

In one implementation, a client system100can execute a browser that can instantiate multiple threads. In this example implementation, the monitoring instructions114acan generate a timer of a relatively short duration, e.g., 10 milliseconds, which instantiates a separate thread. The subsequent execution of the loading instructions114blikewise occurs in the separate thread. Thereafter, the issuing of the content item requests upon execution of the content item request instructions116and the rendering of the content items in the corresponding content item environments122,124and126occur in the second thread, while the rendering of the remainder of the web page content106occurs in the original thread. Thus, if a content item server, such as the content item server140, is busy or slow in responding, the rendering of the remainder of the web page content106is not delayed.

For example, while rendering the web page content106, the client system100defines one or more content item environments122,124and126, e.g., advertisement slots, and renders the web page content106in a first thread. Execution of the first instructions112generates a call to the second instructions114. The monitoring instructions114astart a timer that instantiates a second thread. At a time tethe timer expires. In response to the monitoring of the expiration of the timer, the loading instructions114b,also executing in the second thread, load the content item request instructions116.

The content item request instructions116are executed in the second thread after loading and generate the content item requests132,134and136, e.g., advertisement requests, for the content item environments122,124and126. In one implementation, separate advertisement requests132,134and136are generated for each of the content item environments122,124, and126at times t1, t2and t3, respectively. In another implementation, the content item requests132,134and136are generated as a single request. For example, the requests132,134and136can be concatenated and sent to the content item server140as a single content item request.

A content item server140, e.g., an advertisement server, receives the requests132,134and136, and provides the content items142,144and146, respectively, in response. In response to receiving the content items142,144and146, the client system100renders the content items142,144and146in the second content item environments122,124and126, respectively. In an implementation, the rendering of the content items142,144and146can also performed in the second thread.

In one implementation, the first instructions112and the second instructions114can, for example, comprise javascripts. The first instructions112can comprise a javascript for a content item request function call, and be provided by a content item provider to publishers to insert into their respective web page content106to request content items.

The second instructions114can, for example, comprise a javascript that is called by the first instructions112. Upon such a call, the second instructions114are executed and set a timer, and in response to an expiration of the timer, load a script block using, for example, Dynamic Hypertext Markup Language (DHTML). For example, the execution of the instructions112can set the timerwindow.setTimeout(“ContentEngine.reallyFetchContent( );”, this.INITIAL_DELAY);
where INITIAL_DELAY is a timer duration, e.g., 10 milliseconds. Expiration of the timer generates a call to the function reallyFetchContent( ), which then creates a script block using DHTML according to the following script:var head=document.getElementsByTagName(“head”)[0];var script=document.createElement(“script”);script.src=sourcelocation;head.appendChild(script);

Execution of the above script block loads the content item request instructions116stored in the javascript “script” in the head section108of the web page content106. The content item request instructions116are processed in a thread, e.g., a timer thread, that is separate from the main thread that is rendering the web page content106. Accordingly, a non-responsive or slow content item server140will not impede the rendering of the remainder of the web page content106.

In another implementation, the content item request instructions116can be loaded in the body section110of the web page content106.

The content request optimization process described above thus allows for the processing of other instructions, e.g., javascripts, by a main browser thread while rendering the page content106. Because the content item request instructions116are not loaded when the web page content106is initially processed by the main thread, the processing of other javascripts or other instructions need not be temporarily suppressed during the rendering of the web page content106.

In another implementation, the monitoring instructions114acan generate a timer of a relatively long duration, e.g., several seconds, to ensure that the web page content106is rendered before processing the content item request instructions116. This implementation may be utilized in the case of a client100executing a browser that does not implement multiple thread processing.

In one implementation, the instructions114can be provided by the content item server140and stored in a local data store on the client system100.FIG. 2is a block diagram of a source document, e.g., web page content106, and external second instructions114stored in a local data store. For example, upon rendering the web page content106, the client system100can determine if the second instructions114are stored in a local data store, e.g., a cache associated with a browser application. If the second instructions114are not stored in the local data store, the client system100can request the second instructions114from the content item server140. The client system100can determine for each subsequent access to the stored second instructions114whether the stored second instructions114are the most recent version. If the stored second instructions114are not the most recent version, the client system100can request the most recent version of the second instructions114.

FIG. 3is a block diagram of another source document and embedded second instructions114. In this implementation, the second instructions114are stored as part of the web page content106.

FIG. 4is a timing diagram200of an example content request process. The timing diagram200depicts processes associated with a browser main thread202, a browser request thread204, a publisher sever206and a content item server208as time elapses downward along a vertical axis. Instantiation of the browser main thread202and the browser request thread204can, for example, occur in the client system100ofFIG. 1.

At is time t0, a request for page content, e.g., page content request104, is transmitted to the publisher server206, which, in turn, begins to send the page content106to the client system100. At a time t1, the browser main thread issues a preliminary content item request. The preliminary content item request can, for example, be implemented by a function call to a stored library to execute the second instructions114, as depicted inFIG. 2, or can be implemented by executing second instructions114stored within the page content106, as depicted inFIG. 3.

The preliminary content item request, for example, invokes a monitoring process that monitors for a request event, and which instantiates the browser request thread204. In one implementation, the preliminary content item request initiates a timer that expires at a time t3. The monitoring process can, for example, be instantiated in a browser request thread204that is separate from the browser main thread202.

While the browser request thread204processes the monitoring process, the browser main thread202continues to process the page content, e.g., by continuing to receive resources from the publishing server206at the time t2and rendering the page accordingly. At the time t3, the monitoring process associates the expiration of the timer with the request event, and in response the corresponding request instructions, e.g., instructions116, are loaded. The request instructions can, for example, be executed by the browser request thread204, which causes the browser to transmit a content item request to the content item server208. While the browser request thread204processes the content item request, the browser main thread202continues to process the page content, e.g., by continuing to receive resources from the publishing server206at the time t4.

At a time t5, the browser request thread204, having received at least a first content item in response to the content item request transmitted to the content item server208, updates the rendered page with content items received from the content item server208. At a time t6, the browser main thread202continues to render the web page content106.

In an implementation, the browser main thread202and the browser request thread204operate independently, and thus the processing of the events in the browser main thread202at times t2, t4and t6are independent of the processing of the events in the browser request thread204at times t3and t5. Accordingly, a slow or non-responsive publishing server206will not affect the rendering of content items in the web page content106; likewise, a slow or non-responsive content item server208will not affect the rendering of the web page content106.

The event timings ofFIG. 4, e.g., t0-t6, are discretized for illustrative purposes. The event timings need not occur at discrete times, e.g., the browser main thread202may receive web page content multiple times or in a near-continuous manner. Additional processing events can also be generated. For example, the browser request thread204may generate addition content item requests and render additional content items in the web page.

FIG. 5Ais a timing diagram300of an example advertisement request process. The timing diagram300depicts processes associated with a browser main thread302, a browser request thread304, a publisher server306and an advertisement server308as time elapses downward along a vertical axis. Instantiation of the browser main thread302and the browser request thread304can, for example, occur in the client system100ofFIG. 1.

At a time t0, a request for page content, e.g., page content request104, is transmitted to the publisher server306which, in turn, begins to send the page content106to the client system100. At a time t1, the browser main thread302determines if advertisement server instructions, e.g., second instructions114, are stored on the client system100. If the advertisement server instructions are not stored on the client system100, the browser main thread302requests the advertisement server instructions from the advertisement server302.

At a time t2, the browser main thread202issues a preliminary advertisement request, e.g., a function call to the stored advertisement server instructions. The preliminary advertisement request, for example, invokes a monitoring process that monitors for a request event, and which instantiates the browser request thread304. In one implementation, the preliminary advertisement request initiates a timer that expires at a time t4. The monitoring process can, for example, be instantiated in a browser request thread304that is separate from the browser main thread302.

While the browser request thread304processes the monitoring process, the browser main thread302continues to process the page content, e.g., by continuing to receive resources from the publishing server306at the time t3and rendering the page accordingly. At the time t4, the monitoring process associates the expiration of the timer with the request event, and in response corresponding request instructions are loaded and executed by the browser request thread302, which causes the browser to transmit an advertisement request to the advertisement server308. While the browser request thread304processes the advertisement request process, the browser main thread302continues to process the page content, e.g., by continuing to receive resources from the publishing server306at the time t5.

At a time t6, the browser request thread304, having received at least a first advertisement in response to the advertisement request transmitted to the content item sever308, updates the rendered pages with the advertisements received from the content item server308. At a time t7, the browser main thread302continues to render the web page content106.

In an implementation, the browser main thread302and the browser request thread304operate independently, and thus the processing of the events in the browser main thread302at the times t3, t5and t7are independent of the processing of the events in the browser request thread304at the times t4and t6. Accordingly, a slow or non-responsive publishing server206will not affect the rendering of content items in the web page content106; likewise, a slow or non-responsive content item server208will not affect the rendering of the web page content106.

The event timings ofFIG. 5A, e.g., t0-t7, are discretized for illustrative purposes. The event timings need not occur at discrete times, e.g., the browser main thread may receive web page content multiple times or in a near-continuous manner. Additional processing events can also be generated. For example, the browser request thread304may generate addition content item requests and render additional content items in the web page content106.

FIG. 5Bis the timing diagram300of the example advertisement request process illustrating the rendering of a web page for a publisher server306that is responding relatively slowly as compared to the advertisement server308. In this example, the browser main thread302receives the requested advertisements at the time t4, and thereafter the publisher server306begins to provide resources at the time t5.FIG. 5Cis the timing diagram300of the example advertisement request process illustrating the rendering of a web page for a publisher server306that is responding relatively quickly as compared to the advertisement server308. In this example, the browser main thread302receives all web page resources from the publisher server at the time t3, and thereafter the request event occurs at the time t4.FIGS. 5B and 5Cillustrate that the respective performance of each server306and308does not affect the rendering of the content received from each server308and306, respectively.

FIG. 6is a timing diagram400of another content request process. The timing diagram400depicts processes associated with a client browser402, a publisher server404and a content item server406as time elapses downward along a vertical axis. In the example implementation ofFIG. 6, the request event occurs after a relatively long duration, e.g., several seconds, to ensure that the web page content106is rendered before processing the content item request instructions, e.g., instructions116. In this example implementation, the web page content106is rendered prior to the loading of the content item request instructions116. Accordingly, the processing of the content item requests can occur in the same thread as the rendering of the web page content, and a slow or non-responsive content item server406will thus not affect the rendering of the web page content. Additionally, because the content item request instructions are not loaded until at least the occurrence of the request event, there is no need to temporarily suppress processing other instructions, e.g., javascripts, to ensure that the web page content106is timely rendered.

At a time t0, a request for page content, e.g., page content106, is transmitted to the publisher server404, which, in turn, begins to send the page content to the client system100. At a time t1, the client browser402generates a preliminary content item request, which can, for example, instantiate a monitoring process that monitors for the request event. In one implementation, the preliminary advertisement request instantiates a timer that expires at a time t3.

At the time t2, the client browser402has received the remaining resources for the page content. Thereafter, at the time t3, in response to the expiration of the timer, the corresponding request instructions are loaded and executed by the client browser100, which transmits a content item request to the content item server406. Thereafter, the at the time t4, the client browser updates the web page content with the content items received from the content item server406.

FIG. 7is an example process500for generating content item requests. The example process500can, for example, be implemented in the client system100by rendering the web page content106and executing the second instructions114.

Stage502renders a browser page according to instructions in a source document. For example, a client system100running a web browser can render a web page according to the web page content106received form the publisher102.

Stage504generates a preliminary content item request. For example, execution of the first instructions112can generate a preliminary content item request that invokes the execution of the second instructions114.

Stage506monitors for a request event. For example, execution of the monitoring instructions114ainstantiates a process that will trigger a request event. The process can, for example, be realized by a timer, the expiration of which is associated with the occurrence of a request event. If the occurrence of the request event is not detected, the process continues to monitor for the request event. In one implementation, the occurrence of the request event is scheduled to occur at a time sufficient to ensure that the web page content is substantially rendered.

In response to a monitoring of the request event in stage506, stage508loads content item request instructions in the source document in response to the occurrence of the request event. For example, the loading instructions114bcan load content item request instructions that can, upon execution, cause the client system100to generate content item request instructions116for the content environments122,124and126.

Stage510generates one or more content item requests based on the content item request instructions. For example, the content item request instructions116loaded in stage508can be executed to generate the content item requests.

FIG. 8is an example process600for processing a browser page in multiple threads. The example process400can, for example, be implemented in the client system100by rendering the web page content106and executing of the second instructions114.

Stage602renders a browser page in a first thread. For example, a client system100running a web browser can render a web page according to the web page content106received form the publisher102in a first thread, such as the browser main thread202.

Stage604generates the content item request in a second thread. For example, execution of the first instructions112can generate a preliminary content item request that invokes the execution of the second instructions114, which, in turn, generates the content item request instructions116in a second thread, such as the browser request thread204. Thereafter, the content item request instructions116are executed in the second thread to generate the content item requests.

Stage606renders the content items in the browser page in the second thread. For example, the second thread204can receive the content items responsive to the content item requests and update the rendered page content with the content items.

FIG. 9is another example process700for generating content item requests. The example process700can, for example, be implemented in the client system100by rendering the web page content106and executing the second instructions114.

Stage702renders in a first thread a web page from a source document. For example, a client system100running a web browser can render in a first thread, such as the browser main thread202, a web page according to the web page content106received from the publisher102.

Stage704defines in the first thread one or more content item environments in the web page. For example, execution of the first instructions112can define one or more content item environments122,124and126for rendering in the web page106.

Stage706generates a preliminary content item request. For example, execution of the first instructions112can generate a preliminary content item request that invokes the execution of the second instructions114.

Stage708monitors for a request event. For example, execution of the monitoring instructions114acan instantiate a timer, the expiration of which corresponds to as request event.

Stage710loads in the second thread the content item request instructions in the source document in response to the occurrence of the request event. For example, in response to the monitoring of the occurrence of the request event, the loading instructions114bcan be executed in the second thread to load the content item request instructions116in the web page content106.

Stage712generates in the second thread one or more content item requests based on the content item request instructions. For example, the content request instructions116can be executed in the second thread to generate the one or more content item requests.

FIG. 10is an example process800for generating a request event. The example process800can, for example, be implemented in the client system100by rendering the web page content106and executing the second instructions114on the client system100.

Stage802starts a timer to instantiate a second thread. For example, the monitoring instructions114acan define a timer, such as a javascript timer, and the instantiation of the timer instantiates the second thread.

Stage804associates expiration of the timer with the request event. For example, the monitoring instructions114acan define a timer duration, the expiration of which corresponds to the request event, and the loading instructions114bcan be executed in response to the expiration of the timer.

FIG. 11is another example process900for generating advertisement requests. The example process900can, for example, be implemented in the client system100by rendering the web page content106and execution of the second instructions114on the client system100.

Stage902defines advertisement slots. For example, a client system100running a web browser can render a web page according to the web page content106received form the publisher102. The advertisement slots can, for example, be defined by executing instructions stored in a head section of an HTML document.

Stage904retrieves advertisement slot characteristics. For example, the client system100running a web browser can retrieve advertisement slot characteristics from an advertisement server that stores advertisement slot characteristics for the advertisement slots in a publisher's web page. Often a publisher or an advertiser provider may modify an advertisement slot; accordingly, by storing the advertisement slot modifications at the advertisement server, the publisher need not modify the web page content106.

Stage906initiates is timer. For example, execution of the monitoring instructions114acan instantiate a timer. In one implementation, instantiation of the timer likewise instantiates a separate processing thread.

Stage908determines if the timer has expired. If the timer has expired, then stage910loads instructions (e.g., a javascript block) in response to the timer expiring. For example, execution of the loading instructions114bcan load the content item request instructions116realized as a javascript block in the web page content106. In one implementation, stages908and910are processed by the separate thread instantiated in stage906. The javascript block is executed to retrieve advertisements for the advertisement slots.

Stage910renders the advertisement slots and the advertisements. In one implementation, the client system100creates an iFrame for each advertisement slot using an onLoad callback. When the onLoad callback is executed, the advertisements may or may not have arrived. The process is repeated until the advertisements are retrieved and rendered in the advertisement slots, or until a retry limit is reached, e.g., a loop value or a time out. In one implementation, stage912is implemented in the separate thread instantiated in stage906.

The apparatus, methods, flow diagrams, and structure block diagrams described in this patent document may be implemented in computer processing systems including program code comprising program instructions that are executable by the computer processing system. Other implementations may also be used. Additionally, the flow diagrams and structure block diagrams described in this patent document, which describe particular methods and/or corresponding acts in support of steps and corresponding functions in support of disclosed structural means, may also be utilized to implement corresponding software structures and algorithms, and equivalents thereof.