AU2012261599B2 - Content server latency determination - Google Patents
Content server latency determination Download PDFInfo
- Publication number
- AU2012261599B2 AU2012261599B2 AU2012261599A AU2012261599A AU2012261599B2 AU 2012261599 B2 AU2012261599 B2 AU 2012261599B2 AU 2012261599 A AU2012261599 A AU 2012261599A AU 2012261599 A AU2012261599 A AU 2012261599A AU 2012261599 B2 AU2012261599 B2 AU 2012261599B2
- Authority
- AU
- Australia
- Prior art keywords
- instructions
- client
- content
- web page
- advertisements
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Ceased
Links
- 238000000034 method Methods 0.000 claims description 35
- 230000004044 response Effects 0.000 claims description 18
- 230000008569 process Effects 0.000 description 21
- 238000009877 rendering Methods 0.000 description 10
- 238000010586 diagram Methods 0.000 description 6
- 230000001934 delay Effects 0.000 description 2
- 230000003111 delayed effect Effects 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 230000001360 synchronised effect Effects 0.000 description 2
- 230000004075 alteration Effects 0.000 description 1
- 238000004422 calculation algorithm Methods 0.000 description 1
- 238000004364 calculation method Methods 0.000 description 1
- 230000007717 exclusion Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000003334 potential effect Effects 0.000 description 1
Landscapes
- Information Transfer Between Computers (AREA)
Abstract
A performance of a publisher server, a first content server, and a second content server is determined. Latency time information is determined based on the publisher server performance, the first content server performance, and the second content server performance, the latency time information representing a length of time to load content associated with each of the publisher server, the first content server, and the second content server.
Description
AUSTRALIA Regulation 3.2 Patents Act 1990 Complete Specification Standard Patent Divisional APPLICANT: Google Inc. Invention Title: CONTENT SERVER LATENCY DETERMINATION The following statement is a full description of this invention, including the best method of performing it known to me: CONTENT SERVER LATENCY DETERMINATION 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, JavaScript may execute and request an advertisement from a first content server. In turn, the first content server may request an advertisement from a second content server. If the advertisement is retrieved synchronously, the rendering of the web page is delayed until a requested advertisement is received from a content 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 is that if a content item server is slow, then the rendering of the remainder of the web page will be delayed. To mitigate the potential effects of synchronous content item processing, web page publishers attempt to identify the source of the delay, i.e., the content item server that may be slow or temporarily inoperable, and to calculate the total latency times. However, it is often a complex task to compile the multiple HTTP requests and responses from the rendering of a web page in order to calculate the latency times associated with the different servers. For example, the multiple HTTP requests and responses can look unfamiliar, as they do not appear on the web page itself, but are returned by the first content server. Furthermore, if it is determined that a particular server, e.g., the second content server, is the source of the delay, it is difficult to demonstrate the delay to the operator of the second content server. SUMMARY According to some implementations, a performance of a publisher server, a first content server, and a second content server is determined. Latency time information is determined based on the publisher server performance, the first content server performance, 1 and the second content server performance. The latency time information can represent a length of time to load content associated with each of the publisher server, the first content server, and the second content server. According to some implementations, a Uniform Resource Locator (URL) of a document containing a reference to a script with a first behavior can be specified, wherein a first argument is added to the URL. The URL of the document containing a reference to the script with a second behavior can be specified, wherein a second argument is added to the URL. The document containing the script is received in response to the requests. The script with the first behavior is executed to determine a publisher server latency time, and the script with the second behavior is executed to determine a first content server latency time. A second content server latency time is determined based on the publisher server latency time and the first content server latency time. According to some implementations, a system includes a processor configurable to determine a performance associated with a publisher server, a first content server, and a second content server. A client device is configurable to determine latency time information based on the publisher server performance, the first content server performance, and the second content server performance, the latency time information representing a length of time to load content associated with each of the publisher server, the first content server, and the second content server. According to some implementations, a system includes a processor configurable to request content from one or more remote locations, wherein the content includes computer executable instructions to determine latency information associated with the request. An interface that is operatively coupled to the processor is configurable to display the latency information, the latency information including latency times associated with the one or more remote locations associated with the display of the content in the interface. According to some implementations, content is requested, wherein the request is a Uniform Resource Locator (URL) directed to the content, and the URL includes an added argument. The requested content can be loaded into a content page in a first user interface. A second user interface can then be displayed. One or more content items associated with the content page can then be displayed in the second user interface in accordance with the argument added to the URL. In addition, one or more attributes associated with the one or more content items can be displayed in the second user interface. According to some implementations, a first portion of a content page can be loaded in a first user interface, where the first portion includes content received from a publisher server.
A second user interface can then be displayed. A second portion of the content page can be loaded in the second user interface, where the second portion includes one or more content items received from one or more content servers. In addition, one or more attributes associated with the one or more content items can be displayed in the second user interface. According to some implementations, a system includes a publisher server configurable to transmit a first portion of a content page to a client device, wherein the first portion includes publisher content. Additionally, one or more content servers can be configurable to transmit a second portion of the content page to the client device, where the second portion includes one or more content items. The client device can be configurable to load the first portion of the content page in a first user interface, load the second portion of the content page in a second user interface, and display one or more attributes associated with the one or more content items in the second user interface. According to some implementations, a system includes a client device configurable to save a copy of one or more content items associated with a content page received from one or more content servers. Additionally, a processor is configurable to generate a user interface; generate a combined source code for the one or more saved content items; and insert the combined source code into the user interface. According to some implementations, a system includes a publisher server configurable to capture one or more content item identifications associated with one or more content items. A server processor is configurable to generate a user interface; generate a request to a first content server requesting the one or more content items associated with the one or more content item identifications; and render the one or more content items into the user interface. Throughout the specification the term "comprising" shall be understood to have a broad meaning similar to the term "including" and will be understood to imply the inclusion of a stated integer or step or group of integers or steps but not the exclusion of any other integer or step or group of integers or steps. This definition also applies to variations on the term "comprising" such as "comprise" and "comprises". BRIEF DESCRIPTION OF THE DRAWINGS Fig. 1 is a block diagram of an example system for requesting content from a content server. Fig. 2 is an example process for determining latency contributions. Fig. 3 is another example process for determining latency contributions. Fig. 4 illustrates an example interface displaying the output of NoFetch mode. Fig. 5 illustrates an example interface displaying the output of NoRender mode. Fig. 6 is an example process for determining a source of latency issues.
Fig. 7 is an example process for determining the latency time associated with one or more content servers. Fig. 8 is another example process for determining the latency time associated with one or more content servers. Fig. 9 is another example process for determining the latency time associated with one or more content servers. Fig. 10 is an illustration of an example user interface. DETAILED DESCRIPTION Fig. 1 is a block diagram of an example system 10 for requesting content from one or more content servers. In one implementation, the content may include advertisements, and the content servers can be content servers. Different types of content can also be requested. In one implementation, a client system 100 is configured to view content (e.g., visit web pages) accessible through a network, e.g., the Internet. The client system 100 can, for example, be a web browser, or a computing device executing network navigation software, etc. A web address (e.g., Uniform Resource Locator (URL)) visited by the client system 100 can be resolved to identify a publisher 102, e.g. a server, hosting a corresponding web page. In this example, a client system 100 can send a web page content request 104 to the publisher 102 for the web page content 106. The publisher 102, in response to the request, provides the web page content 106 to the client system 100 as, e.g., an HTML document containing JavaScript. The web page content 106 can include one or more content presentations. In an implementation, the content presentations can include advertisement slots for advertisements to be served by a content server. Other content presentations can also be used. The web page content 106 provided by the publisher 102 includes a reference to a set of instructions 108. In an implementation, the instructions 108 include storing instructions 108a, timing instructions 108b and request instructions 108c that are used to render and present the requested content, e.g., advertisements. In an implementation, the instructions 108 are provided by a first content server 134, e.g., a content server, and are stored at the client system 100, such as in a cache associated with a web browser. The web page content 106 can define content slots 112 - 120 that are configured to display content from the one or more content servers. In an implementation, the content slots 112 - 120 are advertisement slots that are defined within HTML tags. The instructions 108 generate content requests 122 - 130 that are issued to request content to fill the content slots 112 to 120. In an implementation, the requests 122 to 130 are stored in a data store 132, such as a buffer 132, and then sent to the content server 134 in one or more requests 136.
In an implementation, the first content server 134 processes the received individual or combined requests 136 and returns identified content 138 to the client system 100. In another implementation, the first content server 134 processes the received individual or combined requests 136 from the client system 100 and sends a combined response 137 to the client system 100. For example, the response can be in HTML or JavaScript. The combined response 137 to the client system 100 from the first content server 134 can instruct the client system 100 to send one or more requests 140 to a second content server 142 requesting content items. The second content server 142 can then, for example, return identified content 144 to the client system 100. The identified content 138 and/or 144 can then be displayed as part of the publisher's web page in the corresponding content slots, e.g., content slots 112, 114 and 116. An example of the first content server 134 can include a GoogleTM content server. Requests can be made to the GoogleTM content server to fill content slots on the web page with advertisements. In turn, the GoogleTM content server can identify and provide advertisements, or the GoogleTM content server can requests advertisements from the second content server 142, i.e., a third party content server. While reference is made to only two content servers 134 and 142, more than two content servers can provide content to a single web page. When the client system 100 requests content from the publisher 102, the first content server 134, and/or the second content server 142, latency delays can occur. For example, the latency delays can be related to a variety of issues, such as a slow network speed, the publisher server 102 is slow, the first content server 134 is slow, and/or the second content server 142 is slow. A user of the client system 100 can only see a total latency time it takes for the web page to load. Therefore, determining the latency delay contributions attributed to the publisher server 102, first content server 134, and second content server 142 can be difficult to demonstrate. As described in the example above, a total latency time (L) to display a web page can be attributed to the speed of the network, the publisher server 102 speed (LI), which includes network latency time, the first content server 134 speed (L2), and the second content server 142 speed (L3). Therefore, by way of example, the calculation for the total latency time can be determined by L = LI + L2 + L3. With reference to Fig. 2, in accordance with some implementations, an example process 200 to determine latency contributions begins with determining a performance of a publisher server (step 202). To determine the performance of the publisher server 102, a 1S request for content from a publisher server 102 can be made by including an argument (or other indicator) with the request. For example, the argument "google nofetch" can be added to the URL of a web page content location as follows: http://www.webpage.com?googlenofetch to implement a NoFetch mode. A document associated with the requested URL can be received from a content location. The document can include web page content, media, text, a downloadable file, etc. The performance, i.e., a latency time, associated with the publisher server 102 can be determined. In some implementations, the content serving (e.g., JavaScript) tags within the web page content 106 implement diagnostic logic. For example, a script file within the web page content 106 can test for various conditions, such as the latency time associated with the publisher server 102, and write information to a user interface. In a NoFetch mode, a script file within the web page content 106 can prevent the retrieval of content items from the first content server 134, i.e., requests made to the first content server 134 for advertisements. For example, any requests transmitted to the first content server 134 can be replaced with a NO-OP instruction, such that they do nothing (other than generating a debug trace). Therefore, running in NoFetch mode can establish a baseline performance for the publisher server 102 for a web page, i.e., a NoFetch latency time (LI) a user would experience if the publisher did not add any advertisements to the web page. Next, a performance associated with the first content server 134 is determined (step 204). To determine the performance of the first content server 134, an argument (or other indicator) can be included with the URL of a web page location. For example, the argument "googlenorender" can be added to the URL of a web page content location as follows: http://www.webpage.com?googlenorender to implement a NoRender mode. In some implementations, the content serving (e.g., JavaScript) tags within the web page content 106 implement diagnostic logic. For example, a script file within the web page content 106 can test for various conditions, such as the performance, i.e., the latency time, associated with the first content server 134, and write information to a user interface. In a NoRender mode, a script file within the web page content 106 can return content items from the first content server 134, i.e., requests can be sent to first content server 134 to retrieve advertisements. However, after the first content server 134 retrieves the advertisements, the script file can prevent the advertisements from being rendered on the web page. For example, instead of rendering the actual advertisement on the web page in content slots 112, 114 and 116, the code associated with the advertisement in the content slots 112, 114 and 116 is displayed. Therefore, running the NoRender mode can establish a r; performance, i.e., a latency time, for a first content server 134 to retrieve the advertisements, but not render them. The latency time associated with the first content server 134 can be calculated by subtracting the NoFetch latency time from the NoRender latency time, i.e., L2 = NoRender latency time - NoFetch latency time (LI). In step 206, a performance of the second content server 142 can be determined. To determine the performance of the second content server 142, a request for content from the first content server 134 can be made by requesting the URL of a web page content location, without an argument, as follows: http://www.webpage.com. The total page load time associated with requesting and rendering the URL is equivalent to the total latency time (L). Thus, the latency time associated with the second content server 134 can be calculated by subtracting the NoRender latency time from the total latency time, i.e., L3 = total latency time (L) - NoRender (L2). After the performance of the publisher server, first content server, and second content server are determined, a determination of latency time information can be determined based on the publisher server performance, the first content server performance, and the second content server performance (step 208). The latency time information can represent a length of time to load content associated with each of the publisher server, the first content server, and the second content server. For example, a user interface can be spawned and information regarding the latency times attributed to the different components is written to the user interface. In some implementations, the user interface is created by JavaScript code that provides a separate browser window. Fig. 3 is another example process 300 for determining latency contributions. The example process 300 for determining the latency contributions begins with submitting a Uniform Resource Locator (URL) to request a document containing a reference to a script, the request including a first argument added to the URL (step 302). For example, the first argument "google nofetch" can be added to the URL of a web page content location as follows: http://www.web page.com?google_nofetch to implement a NoFetch mode. Next, the process 300 can submit the URL to request the document containing a reference to the script, the request including a second argument added to the URL (step 304). For example, an argument "googlenorender" can be added to the URL of a web page content location as follows: http://www.web page.com?google_norender to implement a NoRender mode. In response to the requests in steps 302 and 304, the document containing the script can be received (step 306). After receiving the document, the script can be executed to 7 determine the publisher server latency time and the first content server latency time in accordance with the first argument and the second argument (step 308). For example, the script can execute the NoFetch mode in accordance with the first argument, and the script can execute the NoRender mode in accordance with the second argument. Based on the publisher server latency time and the first content server latency time, a second content server latency time can be determined (step 310). Fig. 4 illustrates an example interface 400 displaying the output of the script with the first behavior executing the NoFetch mode. Column 402 of Fig. 4 indicates the latency time associated with the executed instructions of the NoFetch mode. For example, the latency time is presented as a running time that increases as the script executes. Column 404 of Fig. 4 provides a message type for the instructions that are being processed by the script executing the NoFetch mode. Column 406 of Fig. 4 provides a summary message indicating the instructions that are being processed by the script executing the NoFetch mode. In NoFetch mode, the executing script file within the web page content 106 can prevent the retrieval of advertisements from the one or more content servers. As indicated at 408 of Fig. 4, the script suppresses the fetching of the ads; therefore, the latency time information in NoFetch mode can be associated with the publisher server. After executing the script with the first behavior, the script with the second behavior can be executed to determine the first content server latency time (step 310). The script with the second behavior can execute the NoRender mode. Fig. 5 illustrates an example interface 500 displaying the output of NoRender mode. Column 502 of Fig. 5 indicates the latency time associated with the script executing the NoRender mode. For example, the latency time is presented as a running time that increases as the script executes. Column 504 of Fig. 5 provides a message type for the instructions that are being processed by the script executing the NoRender mode. Column 506 of Fig. 5 provides a summary message indicating the instructions that are being processed by the script executing the NoRender mode. Running the NoRender mode can establish a performance for a first content server 134 to retrieve the advertisements, but not render them, as displayed at 508 of Fig. 5. The latency time associated with the first content server 134 can be calculated by subtracting the NoFetch latency time from the NoRender latency time, i.e., L2 = NoRender latency time - NoFetch latency time (LI). After running the document in NoFetch and NoRender mode, the second content server latency time can be determined based on the publisher server latency time and the first content server latency time. To determine the performance of the second content server 134, a request for content from the first content server 134 can be made by submitting the URL of a web page content location to the publisher server 102, without an argument, as follows: http://www.web page.com. The total page load time associated with requesting and rendering the URL is substantially equivalent to the total latency time (L). Thus, the latency time associated with the second content server 134 can be calculated by subtracting the NoRender latency time from the total latency time, i.e., L3 = total latency time (L) NoRender latency time (L2). Fig. 6 is an example process 600 for determining the source of a latency effect. Based on the determination of the latency times associated with a publisher server, a first content server, and a second content server, the source of the slow load times associated with a content page can be determined. If LI is determined to be slow in decision step 602, then the source of the latency is most likely attributed to the publisher server 102 (step 604). However, if LI is determined to be fast in decision step 602, the process 600 moves to decision step 606. In decision step 606, if L2 is determined to be slow, then the source of the latency is most likely attributed to the first content server 134 (step 608). If L2 is determined to be fast in decision step 606, the process 600 moves to decision step 610. In decision step 610, if L3 is determined to be fast, latency with the content page load time can be deemed as low ( LI, L2, and L3 are all determined to be fast) (step 612). However, if L3 is determined to be slow in decision step 610, then the source of the latency is most likely attributed to the second content server 142 (step 614). Based on the example processes described above, it can be determined that the source of the latency is most likely attributed to the second content server 142. Based on this determination, an example process 700 for determining the latency time associated with one or more content servers, such as the second content server 142, is illustrated in Fig. 7. First, content can be requested, wherein the request is a Uniform Resource Locator (URL) directed to the content, the URL comprising an added argument (step 702). The content received in response to the request can be loaded into a content page in a first user interface (step 704). In one implementation, the content loaded into the content page can includes a first portion of content, where the first portion of content only includes content from a publisher server 702. Next, a second user interface can be displayed (step 706). To display the second user interface, a document containing a script can be requested, where the request includes an indicator. For example, the request can be a Uniform Resource Locator (URL) directed to receive a document and the indicator is an argument added to the URL. The document can then, for example, be received in response to the request. The script can then be executed to 0 display the second user interface in response to receipt of the indicator. For example, the second user interface can be a browser window that is separate from a browser window displaying the content page. In another implementation, the first and second user interfaces can be displayed in the same interface. The first and second user interfaces can be rendered by a common browser on a common client device. For example, the first and second user interfaces can be rendered in a single user interface, such as a browser window, executing on the client device. Subsequently, one or more content items e.g., advertisements, associated with the content page can be displayed in the second user interface in accordance with the argument added to the URL (step 708). In addition, one or more attributes for each content item in the second user interface can be displayed (step 710). For example, the displayed attributes can include a load time associated with each content item and a total load time. In one implementation, displaying the one or more content items can be accomplished by utilizing a client-side implementation. For example, a copy of the one or more content items to be inserted into a content item slot can be received from one or more content servers and saved. An onload callback can then be registered for the content page. During the onload callback, the second user interface is displayed, and a scan is made through the content item slots. After making a scan through the content item slots, all of the code, e.g., HTML code, associated with the content items can be combined. The combined HTML code can then be inserted into the second user interface and all of the content items can be generated. In another implementation, displaying the one or more content items in the second user interface can be accomplished by utilizing a server-side implementation. For example, one or more content item identifications associated with one or more content items can be captured with JavaScript. A second user interface can then be opened, and a request can be made to one or more content servers for the one or more content items by utilizing the one or more advertisement identifications. The one or more content items received from the one or more content servers can then, for example, be rendered in the second user interface. In an implementation, a load time associated with each content item can be displayed in the second user interface. In an implementation, a total load time can be displayed in the second user interface. In some implementations, the source code associated with the second user interface can be saved. For example, the user can view and save the source code of the page in the second user interface. Saving the source code can be useful in demonstrating the latency of 1 ( one or more content items to an operator of a content server responsible for the latency. Specifically, the source code can be used to pinpoint which content item(s), i.e., advertisement(s), produce the most delay in load time. The source code can, for example, be emailed directly to the operator of the content server. The source code can then, for example, be loaded in a user interface, such as a browser, to demonstrate the latency with a particular content item(s). Another example process 800 for determining the latency time associated with one or more content servers, such as the second content server 142, is illustrated in Fig. 8. After determining the source of latency associated with a content page, a first portion of a content page can be loaded in a first user interface, where the first portion includes content received from a publisher server (step 802). For example, the first portion of content may not include one or more content items from one or more content servers. Next, a second user interface can be displayed (step 804). Subsequently, source code, i.e., HTML code, associated with a second portion of the content page can be displayed in the second user interface, where the second portion includes one or more content items received from one or more content servers (step 806). To display the source code, e.g., HTML code, associated with the one or more content items in the second user interface, a document containing a script can be requested, where the request includes an indicator. For example, the request can be a Uniform Resource Locator (URL) directed to receive a document and the indicator is an argument added to the URL. The document can then, for example, be received in response to the request. The script can then be executed to display the second user interface including the source code associated with the one or more content items in response to receipt of the indicator. For example, the argument "google capture norender" can be added to the URL of a web page content location as follows: http://www.webpage.com?google_capturenorender. In response, a second user interface can be displayed that contains the source code associated with the one or more content items. The source code can then, for example, be copied (step 808), pasted into an editor (step 810), and then saved to a file (step 812), such as a local HTML file. Thereafter a user interface, such as a browser or other user interface, can be utilized to open the file, e.g., the local HTML file, which contains the source code associated with the one or more content items (step 814). When opened, the file can render the one or more content items associated with the content page in the user interface (step 816). In addition, one or more attributes associated with the one or more content items can be displayed in the user interface (step 818). For example, the attributes can include a load time 1 1 associated with each content item and a total load time associated with the one or more content items. Fig. 9 is another example process 900 for determining the latency time associated with one or more content servers, such as the second content server 142. The process 900 begins by loading a first portion of a content page in a first user interface, where the first portion includes content received from a publisher server (step 902). For example, the portion of the content page loaded into the first user interface may not include content from one or more content servers. Next, a second user interface is displayed (step 904). For example, the second user interface can be a window, such as a pop-up window, that is displayed in addition to the first user interface. A second portion of the content page can then, for example, be displayed in the second user interface, where the second portion includes one or more content items received from one or more content servers (step 906). In addition, one or more attributes associated with the one or more content items can be displayed in the second user interface (step 908). For example, the attributes can include a load time associated with each content item and a total load time associated with the one or more content items. Fig. 10 is an illustration of an example second user interface 1000 as described in the processes above. As described, one or more attributes associated with the one or more content items can be displayed in the second user interface 1000. In one implementation, location and size information 1002 associated with each content item can be displayed in the second user interface 1000. In another implementation, the content item 1004 can be displayed in the second user interface 1000. In another implementation, a load time 1006 associated with each advertisement can be displayed in the second user interface 1000. For example, an individual load time 1006 can be associated with the advertisement 1004 displayed with the location and size information 1002. In another implementation, a total load time 1006 can be displayed in the second user interface 1000. 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 12 This written description sets forth the best mode of the invention and provides examples to describe the invention and to enable a person of ordinary skill in the art to make and use the invention. This written description does not limit the invention to the precise terms set forth. Thus, while the invention has been described in detail with reference to the examples set forth above, those of ordinary skill in the art may effect alterations, modifications and variations to the examples without departing from the scope of the invention. The reference to any prior art in this specification is not, and should not be taken as, an acknowledgement or any form of suggestion that the prior art forms part of the common general knowledge in Australia.
Claims (20)
1. A computer-implemented method comprising: receiving requests for advertisements from a client for a plurality of respective advertisement slots of a first web page; obtaining respective instructions for each of a plurality of advertisements identified as being responsive to the requests, wherein the obtained respective instructions, when executed by the client, cause the client to present one of the advertisements; generating first instructions that, when executed by the client, cause the client to present the obtained respective instructions in the first web page without executing the obtained respective instructions; generating second instructions that, when executed by the client, cause the client to execute the obtained respective instructions to present each of the advertisements in a second web page along with a respective load time, wherein the respective load time is a latency attributable to a content server from which the advertisement was requested; and sending the first and second instructions to the client in response to receiving the requests, wherein when executed by the client, the first instructions cause the client to present the obtained respective instructions in the first web page such that a user of the client can electronically provide a copy of at least a part of the obtained respective instructions to a third party for review of the respective load time.
2. The method of claim 1, wherein the second instructions further cause the client to present a total load time in the second web page, wherein the total load time is a load time for all of the advertisements.
3. The method of claim 1, further comprising: receiving a request including an argument indicating that the first instructions are to be presented in the first web page.
4. The method of claim 3, further comprising providing the first instructions for presentation in the first web page.
5. The method of claim 3, wherein the first instructions are in Hypertext Markup Language (HTML).
6. The method of claim 3, wherein the first instructions are in JAVASCRIPT.
7. The method of claim 1, wherein one of the received advertisements was identified by a content server.
8. A system comprising: one or more computers configured to perform operations comprising: receiving requests for advertisements from a client for a plurality of respective advertisement slots of a first web page; obtaining respective instructions for each of a plurality of advertisements identified as being responsive to the requests, wherein the obtained respective instructions, when executed by the client, cause the client to present one of the advertisements; generating first instructions that, when executed by the client, cause the client to present the obtained respective instructions in the first web page without executing the obtained respective instructions; generating second instructions that, when executed by the client, cause the client to execute the obtained respective instructions to present each of the advertisements in a second web page along with a respective load time, wherein the respective load time is a latency attributable to a content server from which the advertisement was requested; and sending the first and second instructions to the client in response to receiving the requests, wherein when executed by the client, the first instructions cause the client to present the obtained respective instructions in the first web page such that a user of the client can electronically provide a copy of at least a part of the obtained respective instructions to a third party for review of the respective load time.
9. The system of claim 8, wherein the second instructions further cause the client to present a total load time in the second web page, wherein the total load time is a load time for all of the advertisements.
10. The system of claim 8, wherein the operations further comprise receiving a request including an argument indicating that the first instructions are to be presented in the first web page.
11. The system of claim 10, wherein the operations further comprise: providing the first instructions for presentation in the first web page.
12. The system of claim 10, wherein the first instructions are in Hypertext Markup Language (HTML).
13. The system of claim 10, wherein the first instructions are in JAVASCRIPT.
14. The system of claim 8, wherein one of the received advertisements was identified by a content server.
15. The method of claim 1, wherein the first instructions comprise instructions to register an onload callback for the first web page, wherein the second web page is presented during the onload callback.
16. The method of claim 15, wherein the second instructions comprise instructions of the onload callback that, when executed by the client, cause the client to scan the advertisement slots, generate HTML code for each respective advertisement, and combine the generated HTML code.
17. The method of claim 16, wherein the onload callback is called when the first web page is loaded by the client.
18. The method of claim 1, wherein the advertisements are not presented in the first web page.
19. The system of claim 8, wherein the first instructions comprise instructions to register an onload callback for the first web page, wherein the second web page is presented during the onload callback.
20. The system of claim 19, wherein the second instructions comprise instructions of the onload callback that, when executed by the client, cause the client to scan the advertisement slots, generate HTML code for each respective advertisement, and combine the generated HTML code.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| AU2012261599A AU2012261599B2 (en) | 2007-08-08 | 2012-12-07 | Content server latency determination |
Applications Claiming Priority (4)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US11/836,019 | 2007-08-08 | ||
| US11/836,069 | 2007-08-08 | ||
| AU2008285354A AU2008285354B2 (en) | 2007-08-08 | 2008-08-07 | Content server latency determination |
| AU2012261599A AU2012261599B2 (en) | 2007-08-08 | 2012-12-07 | Content server latency determination |
Related Parent Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| AU2008285354A Division AU2008285354B2 (en) | 2007-08-08 | 2008-08-07 | Content server latency determination |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| AU2012261599A1 AU2012261599A1 (en) | 2013-01-10 |
| AU2012261599B2 true AU2012261599B2 (en) | 2014-02-27 |
Family
ID=47520534
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| AU2012261599A Ceased AU2012261599B2 (en) | 2007-08-08 | 2012-12-07 | Content server latency determination |
Country Status (1)
| Country | Link |
|---|---|
| AU (1) | AU2012261599B2 (en) |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20010010059A1 (en) * | 1998-10-28 | 2001-07-26 | Steven Wesley Burman | Method and apparatus for determining travel time for data sent between devices connected to a computer network |
| US20020099818A1 (en) * | 2000-11-16 | 2002-07-25 | Russell Ethan George | Method and system for monitoring the performance of a distributed application |
| US20060253546A1 (en) * | 2005-05-04 | 2006-11-09 | Koling Chang | Method and apparatus for increasing performance of HTTP over long-latency links |
-
2012
- 2012-12-07 AU AU2012261599A patent/AU2012261599B2/en not_active Ceased
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20010010059A1 (en) * | 1998-10-28 | 2001-07-26 | Steven Wesley Burman | Method and apparatus for determining travel time for data sent between devices connected to a computer network |
| US20020099818A1 (en) * | 2000-11-16 | 2002-07-25 | Russell Ethan George | Method and system for monitoring the performance of a distributed application |
| US20060253546A1 (en) * | 2005-05-04 | 2006-11-09 | Koling Chang | Method and apparatus for increasing performance of HTTP over long-latency links |
Also Published As
| Publication number | Publication date |
|---|---|
| AU2012261599A1 (en) | 2013-01-10 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11809511B2 (en) | Speeding up document loading | |
| US10911554B2 (en) | Method and system for tracking web link usage | |
| JP6351611B2 (en) | Distributing and displaying page previews during page acquisition events | |
| US7657611B2 (en) | Content request optimization | |
| US9805135B2 (en) | Systems and methods for updating rich internet applications | |
| US9032282B2 (en) | Method and web content management system for A/B testing or multivariate testing of websites on computers being connected to a web content management system | |
| US8949405B2 (en) | Content server latency determination | |
| US9232011B2 (en) | Tracking navigation flows within the same browser tab | |
| US20100313129A1 (en) | Self-Expanding AD Unit | |
| JP2010500689A (en) | Method for enabling web analysis of interactive web applications | |
| US8516041B1 (en) | Pre-fetching asynchronously requested content | |
| AU2008285354B2 (en) | Content server latency determination | |
| US8429544B2 (en) | Content server latency demonstration | |
| AU2012261599B2 (en) | Content server latency determination | |
| JP6683835B2 (en) | Reduced waiting time when downloading electronic resources using multiple threads |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| FGA | Letters patent sealed or granted (standard patent) | ||
| MK14 | Patent ceased section 143(a) (annual fees not paid) or expired |