Patent Application
20140280677
This disclosure relates in general to techniques for accelerating the delivery and rendering of web files over the Internet.
Webpage designers continue to add increasingly more data to web files. A web file contains instructions for displaying a webpage. Where it was once common for a webpage to have only a few images, it is now common to find webpages with more than a dozen images. Additionally, more webpage designers are using higher-level programming languages. When web files are written in a higher-level programming language, the web file is often written not as efficiently as it could be.
For handling web files that are often data intensive, webpage hosts are turning to Content Delivery Networks (CDNs) to fulfill end-user requests for webpages. A CDN is one or more servers that receive requests from end users and respond to the requests. But adding an additional server between an origin server and the end user can potentially introduce a delay in the delivery and rendering of a web file.
Sometimes a CDN will introduce an instance-specific web file based on an origin web file. For an instance-specific web file, an initial response is added as a new section to the origin web file. The instance-specific web file would then have its own Uniform Resource Locator (URL). But introducing a new URL can break the browser history. Additionally, copying or forwarding the URL to the instance-specific web file can result in a broken link and a web browser not being able to render the origin web file to display a corresponding webpage.
A system and a method for accelerating delivery of a webpage by using a preloader file during a delay in fetching the web file are disclosed. When an end user makes a request through a client computer for a webpage, a Content Delivery Network (CDN) server sends the client a preloader file. The preloader file contains requests for resources that are likely to be part of the web file. The client downloads the resources, and the resources are saved in a browser cache. The preloader file also directs the client to request the webpage again. While the client is downloading the resources, the CDN server requests the web file from an origin server. The origin server composes the webpage and delivers the webpage to the CDN server. When the client makes a second request for the web file, the CDN server delivers the web file to the client. When the client renders the web file to display the webpage, the client can retrieve the resources from the browser cache.
A system for accelerating the loading of a webpage by providing a preloader file to a client's request for the webpage is disclosed. The system comprises a preloader engine configured to receive a first request from the client for a first file. The first request comprises a first Uniform Resource Identifier (URI), and the first URI identifies the first file. The first file is renderable by a browser as the webpage. The preloader engine determines a second URI, where the second URI identifies a second file. The second file is different from the first file, and the second file is the preloader file. The preloader file is configured to request a first resource for download. The first resource is likely to be a resource of a first plurality of resources of the first file. The preloader file also contains instructions to request the first file again. The preloader engine sends the client a first response, the first response comprises the URI of the preloader file. The preloader engine requests the first file from a server. The preloader engine receives a second request from the client for the first file. The second request comprises a third URI identifying the first file. The preloader engine determines that the second request for the first file is received later in time than the first request for the first file. The preloader engine receives the first file from the server and transmits the first file to the client in response to the second request for the first file. The system also comprises a preloader cache containing a plurality of preloader files.
A method for accelerating the loading of the webpage by providing the preloader file to a client's request for the webpage is disclosed. The method includes receiving a first request from the client for a first file, the first request comprises a first URI. The first URI identifies the first file, wherein the first file is renderable by a browser as the webpage. The method includes determining a second URI, where the second URI identifies a second file. The second file is different from the first file. The second file is the preloader file, and the preloader file is configured to request a first resource for download, where the first resource is likely to be a resource of a first plurality of resources of the first file. The preloader file is also configured to request the first file again. The method includes sending the client a first response, the first response comprising the second URI directing the client to the preloader file. The method includes requesting the first file from a server. The method includes receiving a second request from the client for the first file, where the second request comprises a third URI. The third URI identifies the first file. The method also includes determining that the second request for the first file is received later in time than the first request for the first file; receiving the first file from the server; and transmitting the first file to the client in response to the second request for the first file.
A system and method for accelerating the loading of a webpage by providing a preloader file to a client's request for the webpage is disclosed. The system comprises a preloader engine configured to receive a first request from the client for a first file. The first request comprises a first URI, and the first URI identifies the first file. The first file is renderable by a browser as the webpage. The preloader engine composes a first preloader response. The first preloader response includes instructions for downloading a first resource that is likely to be a resource of the first file. The preloader engine sends the client the first preloader response. The preloader engine requests the first file from a server. The preloader engine composes a second preloader response with additional instructions for downloading a second resource that is likely to be a resource of the first file. The preloader engine sends the client the second preloader response. The preloader engine receives a second request for the client for the first file. The preloader engine receives the first file, or an accelerated version of the first file, from the server. The preloader engine composes a third preloader response. The third preloader response includes the first file, or the accelerated version of the first file. The preloader engine sends the third preloader response to the client.
Further areas of applicability of the present disclosure will become apparent from the detailed description provided hereinafter. It should be understood that the detailed description and specific examples, while indicating various embodiments, are intended for purposes of illustration only and are not intended to necessarily limit the scope of the disclosure.
The present disclosure is described in conjunction with the appended figures:
In the appended figures, similar components and/or features may have the same reference label. Further, various components of the same type may be distinguished by following the reference label by a dash and a second label that distinguishes among the similar components. If only the first reference label is used in the specification, the description is applicable to any one of the similar components having the same first reference label irrespective of the second reference label.
The ensuing description provides preferred exemplary embodiment(s) only, and is not intended to limit the scope, applicability or configuration of the disclosure. Rather, the ensuing description of the preferred exemplary embodiment(s) will provide those skilled in the art with an enabling description for implementing a preferred exemplary embodiment. It is understood that various changes may be made in the function and arrangement of elements without departing from the spirit and scope as set forth in the appended claims.
Referring first to
An end user 128 may request a set of content objects, e.g., by requesting a web file associated with one or more of content objects, such as an HTML file. A web file is a content object that contains instructions for generating a webpage and/or instructions for retrieving other content objects. Content objects that are associated with a web file are considered resources of that web file. A source of each of the content objects and/or the web file may be on an edge server, a host server within the CDN, a resource store 108 of the origin server 112, the origin file 116, or on a cache in another POP 120.
A content originator 106 produces and/or distributes content objects as the originator of content in a digital form for distribution with the Internet 104. The content originator 106 includes an origin server 112, a resource store 108, and an origin file 116. The figure shows a single origin server 112, but it is to be understood embodiments could have multiple origin servers 112 that each can serve content objects. For example, the content originator 106 could have multiple origin servers 112 and assign any number of them to serve the content object. The origin servers 112 for a given origin file 116 could be widely distributed with some even being hosted by the CDN 110. Additionally, it is to be understood embodiments could have multiple resource stores 108. For example, one origin server 112 could have multiple resource stores 108. In another example, resources to a first origin file 116 associated with a first origin server 112 could be kept in a resource store 108 of a second origin server 112.
Although this figure only shows a single content originator 106 and a single CDN 110, there may be many of each in other embodiments. The content object is any web file or content stream and could include, for example, video, pictures, advertisements, applet, data, audio, software, HTTP content, and/or text. The content object could be live, delayed, or stored. Throughout the specification, references may be made to a content object and/or content, but it is to be understood that those terms could be generally used interchangeably wherever they may appear.
Many content originators 106 use the CDN 110 to deliver resources and origin files 116 over the Internet 104 to end users 128. When a content object or the origin file 116 is requested by an end user 128, the CDN 110 may retrieve the content object from the resource store 108 for loading in a cache or hosting for a period of time. The origin file 116 could be hosted in the resource store 108 or separately. In the embodiment shown, the origin file 116 is stored separately from the resource store 108. Alternatively, the origin server 112 may directly provide resources and the origin file 116 to the CDN 110 for hosting, i.e., in advance of a first request or in servicing the first request.
The origin file 116 is a web file that is published by the content originator 106. The origin file contains instructions that, when rendered, displays a webpage referred to as the origin webpage. A webpage is a visual display of a web file after the web file is rendered by a browser. Thus the rendering of the origin file by a browser displays the origin webpage.
The CDN 110 includes a number of points of presence (POPs) 120, which are geographically distributed through the content distribution system 100. Various embodiments may have any number of POPs 120 within the CDN 110 that are generally distributed in various locations around the Internet 104 to be proximate, in a network quality of service (QoS) sense, to end user systems 124. A wide area network (WAN), the Internet 104 and/or other backbone may couple the POPs 120 with each other and also couple the POPs 120 with other parts of the CDN 110.
When an end user 128 requests a resource, or the origin file 116, through its respective end user system 124, the request is passed either directly or indirectly via the Internet 104 to the content originator 106. The request, for example, could be an HTTP Get command sent to an IP address of the content originator 106 after a look-up that finds the IP address. The content originator 106 may also be the source or re-distributor of resources for the origin file 116. The origin server 112 can redirect content requests to any CDN 110 after they are made, or can formulate the delivery path beforehand when a web file is formulated to point to the CDN 110. In any event, the request for content is handed over to the CDN 110 for fulfillment in this embodiment.
Once the request for content is passed to the CDN 110, the request is associated with a particular POP 120 within the CDN 110. The particular POP 120 then assigns or routes the request to an edge server. The particular POP 120 may retrieve the origin file 116 and/or resources through the origin server 112. Alternatively, the origin server 112 may directly provide the origin file 116 and resources to the CDN 110 and its associated POPs 120, i.e., in advance of the first request. In this embodiment, the content objects are provided to the CDN 110 and stored in one or more CDN servers such that the requested content may be served from the CDN 110. The resource store 108 holds a copy of content objects for the content originator 106.
An edge server serving the request to the end user system 124 may access the origin file 116 and/or resources either by locally retrieving part or all of the content or requesting it from another server. In some instances, the edge server determines a source for part or all of the requested content within the CDN 110 by querying other peer servers within or remote from the particular POP 120. This embodiment dynamically discovers peer servers, which have already cached or stored the requested content. The peer server that already holds the requested content could be an edge server or a server that doesn't service end user requests, for example, a relay server or ingest server. If part or all of the content cannot be found in the POP 120 originally receiving the request, neighboring POPs 120 could serve as the source in some cases, or the content could be sourced from the content originator 106.
Thus, a request from an end user system 124 for content may result in requests for content from one or more servers in the CDN 110. A CDN server (e.g., an edge server, peer servers, an origin server, etc.) may analyze requested content objects (e.g., requested HTML files), determine versions of the content objects that are cached locally, and transmit to other CDN servers a modified request for content objects.
The end user system 124 processes the content for the end user 128 upon receipt of the content object. The end user system 124 could be a personal computer, media player, handheld computer Internet appliance, phone, IPTV set top, streaming radio, or any other device that can receive and play content objects. An end user system 124 is also sometimes referred to as a client. End user system 124 and client can generally be used interchangeably wherever they may appear. In some embodiments, a number of end user systems 124 can be networked together sharing a single connection to the Internet 104. Changes could be made by the CDN 110 that do not affect the end user realization of the content except to speed delivery.
With reference to
In the depicted example, the end user system 124 requests a web file and/or resource. The request is assigned to a fifth POP 120-5. The request is assigned to the fifth POP 120-5 based on a proximity between the end user system 124 and the fifth POP 120-5, i.e., the fifth POP 120-5 was the closest POP 120 to the end user system 124 in a network context. But there are other ways a POP 120 can be assigned to a request by an end user system 124. A POP could be selected based on load balancing within the CDN 110, a quality of service requirement, or other method. After receiving the request, the fifth POP 120-5 would check a cache in the fifth POP 120-5 for the web file and/or resource. If the web file and/or resource is not in the cache of the fifth POP 120-5, then the fifth POP 120-5 would request the web file and/or resource from the origin server 112.
There is a delay in the fifth POP 120-5 receiving the origin file 116 based on the location of the fifth POP 120-5, the quality of service of the network 204 connecting the fifth POP 120-5 to the origin server 112, and the time it takes the origin server 112 to process the request from the fifth POP 120-5. For example, take an origin server 112 located in San Francisco and a first POP 120-1 located in San Diego. If the fifth POP 120-5 is located in Dubai, it will likely take longer for the fifth POP 120-5 to receive a response from the origin server 112 than the first POP 120-1 located in San Diego.
Referring next to
An end user system 124 is assigned to the fifth POP 120-5 of the CDN 110. The end user system 124 requests a first web file corresponding to the origin file 116. If the fifth POP 120-5 does not have a copy of the origin file 116 cached, the fifth POP 120-5 requests the origin file 116 from the first origin server 112-1. The fifth POP 120-5 then sends a copy of the origin file 116 to the end user system 124. The end user system 124 attempts to render the origin file 116. In attempting to render the origin file 116, the end user system is instructed to request a first resource. The end user system 124 requests the first resource from the fifth POP 120-5. But the request for the first resource does not necessarily need to go through the fifth POP 120-5. The request for the first resource could have been routed through a different POP 120, such as the fourth POP 120-4. The fifth POP 120-5 will check the cache of the fifth POP 120-5. If the fifth POP 120-4 does not have the resource cached, then the fifth POP 120-5 requests the first resource from the second origin server 112-2. In this way, the origin file 116 and resources can be spread out among the network 204.
Referring next to
Referring next to
The browser 404 has a browser cache 420 to store web files, resources, and other content objects. Generally, a browser 404 stores content objects in the browser cache 420 that the browser 404 has recently downloaded. Content objects in the browser cache 420 are organized by Uniform Resource Identifiers (URIs). A URI is a string of characters that identifies a content object. A URI could be a Uniform Resource Locator (URL) and/or a Uniform Resource Name (URN). For example, http://www.google.com, is a URL to the web file of Google's™ Internet search engine (“Google™ web file”). When an end user 128 enters the URL of the Google™ web file into the browser 404, the browser 404 requests and renders the Google™ web file to display a webpage. The webpage has a Google™ logo on it. The Google™ logo is an image, and thus the Google™ logo is a resource of the Google™ web file. The Google™ logo has its own URI. After retrieving the Google™ web file and the Google™ logo, the browser 404 would save both to the browser cache 420. When the end user enters http://www.google.com into the browser 404 a second time, the browser first checks for the Google™ web file in the browser cache 420. As the browser 404 renders the Google™ web file, the Google™ web file will request the Google™ logo as a resource. The browser 404 will first check the browser cache 420 for the URI corresponding to the Google™ logo before requesting the Google™ logo from a server.
The webpage environment 408 is where the browser 404 renders a web file to display a webpage for the end user 128. After a browser 404 receives a web file, the browser 404 reads an origin element 412 of the web file. Web files are commonly written in a runtime language such as HTML or JavaScript™. Different acceleration techniques modify, delete, and add to parts of the origin file 116. The origin element 412 is a part of the origin file 116 that remains unchanged. If no acceleration is used, then the origin element 412 is equivalent to the origin file 116. The browser 404 runs the origin element 412. During the running of the origin element 412, the origin element 412 contains instructions for the browser 404 to download one or more resources.
When a resource is called for in the webpage environment 408, the request for the resource first goes to a reference requestor 424. The requestor contains a list of content objects in the browser cache 420, organized by URI. The reference requestor 424 would query the list of content objects for a URI of the resource. If the URI of the resource is on the list of content objects stored in the browser cache 420, then the browser 404 retrieves the resource from the browser cache 420 and brings the resource into the webpage environment 408. If the resource is not in the browser cache 420, then the browser 404 requests the resource from the POP 120. After the browser 404 receives the resource, the browser 404 saves a copy of the resource in the browser cache 420. The list of content objects maintained by the reference requestor 424 is then updated with the URI of the resource.
With reference to
The parts of the new web file that the acceleration engine modified is the acceleration element 416. The origin element 412 and the acceleration element 416 do not need to be isolated from each other. In a given web file, parts of the acceleration element may be intermixed with parts of the origin element. For example, an origin file 116 could have ten images. The acceleration engine could combine image one and image two into a first image file; combine image four and image five into a second image file; and combine image nine and image ten into a third image file. The acceleration engine would then remove requests for images one, two, four, five, nine, and ten. The acceleration engine would add a request for the first image file, as part of the acceleration element 416, before a request for the third image; insert a request for the second image file, as another part of the acceleration element 416 between the request for the third image and a request for the sixth image; and add a request for the third image file, as still another part of the acceleration element 416 after a request for the eighth image. Thus the origin element 412 and the acceleration element 416 would be intermixed.
Referencing next to
The preloader engine 512 could be a server computer or part of the edge server. When the preloader engine 512 receives the first request, the preloader engine 512 determines whether there has been an earlier request for the first web file from the end user system 124. If there has not been an earlier request for the first web file from the end user system 124, the preloader engine 512 makes a second request for the first web file. The preloader engine 512 requests the first web file via the network 204 from the origin server 112 or another CDN server 524.
Either before or after making the second request for the first web file, the preloader engine 512 composes a preloader response. The preloader response is sent to the end user system 124. The preloader response could be an HTTP redirect to a preloader file and/or instructions written in a scripting language. For a redirection (e.g., HTTP 303 redirect), the preloader response comprises a URI of the preloader file. The preloader engine 512 can encrypt the preloader response or portions of the preloader response, such as encrypting the URI of the preloader file. The end user system 124 then requests the preloader file using the URI of the preloader file. For instructions written in a scripting language (e.g., JavaScript™), the instructions direct the browser 404 to download one or more resources that are likely to be requested by the first web file. The instructions written in the scripting language further direct the browser 404 to request the first web file again using a URI of the first web file. In one embodiment, the preloader response also includes an application for a temporary display of one or more content objects while the first web file is being retrieved. The temporary display could include video, audio, an interactive game (including a quiz or trivia), status bar, animation, and/or advertisement(s).
The preloader file is a web file that contains instructions for the browser 404. The instructions include downloading a list of resources that are likely to be used in the rendering of the first web file. The preloader file also contains instructions for the browser 404 to request the first web file again, a third request for the first web file. The third request is a request from the end user system 124 to the HTTP request server 504. The third request includes a URI of the first web file. In one embodiment, the URI of the first web file in the first request and the URI of the first web file in the third request are the same. The preloader file could be constructed automatically based on statistics of prior requests routed though the CDN 110 or manually. In the present embodiment, the preloader file is constructed before the first request and is stored in the preloader cache 516. In another embodiment, the preloader file also contains instructions for the browser 404 to modify an HTTP request header of the third request for the first web file. The instructions to modify the HTTP request header are instructions to include the URI, or portions of the URI, of the preloader file in the referer HTTP header of the third request. In some embodiments the preloader file loads more quickly into the browser 404 than the first web file. In one embodiment, the preloader file is written in HTML code using HTML constructs to instruct the browser 404 to request resources and/or request the first web file again. In another embodiment, comprises a scripting language such as JavaScript to provide instructions.
To identify the preloader file, the preloader engine 512 queries a preloader-file mapper 520. The preloader-file mapper 520 contains a list of a first set of URIs corresponding to a plurality of cached preloader files and a second set of URIs corresponding to a plurality of web files. The first set of URIs, corresponding to the plurality of cached preloader files, is mapped to the second set of URIs, corresponding to the plurality of web files. A particular preloader file could be mapped to a particular website domain, sub domain, or specific web page. For example, one preloader file could be created for all requests where a URI contains “Wikipedia.org.” In another example, one preloader file could be created for the specific web page: http://en.wikipedia.org/wiki/Programming. A particular preloader file could be different between different POPs 120. For example, referring back to
Preloader files are stored in a preloader cache 516. The preloader cache 516 could store preloader files in a memory of its own or the preloader cache 516 could be part of the edge cache 508. When the end user system 124 requests the preloader file, the HTTP request server 504 retrieves the preloader file (through the preloader engine 512) from the preloader cache 516. The HTTP request server 504 then delivers the preloader file to the end user system 124. Additionally, when the preloader engine 512 creates a new preloader file, the preloader engine 516 stores the preloader file in the preloader cache 516.
Referring to Table I, an example of a subset of information contained in the resource map 532 is given. The subset of information is the response time between the POP 120 and various domains. For example, the response time between the POP 120 and Franklin.info is 430 milliseconds (ms). The preloader engine 512 can estimate how long it will take to receive a response from the origin server 112 based on response times. The response time can be static, such as an average response time based on several days. Or the response time can be dynamic, such as updating the response time with the response time of a previous request or a rolling average of the last five requests to a particular domain.
Similar methods could be used to create a preloader response with a scripting language, such as JavaScript™, with instructions similar to the instructions on the preloader file. In this embodiment, the client would not need to request the second URI to the preloader file. The preloader response would contain the instructions for downloading resources and instructing the client to request the first web file again.
Referring next to
The value of the reloader-URL in Table II is constructed from the page-URL and a randomly generated transaction ID, such that the page-URL and the transaction ID can be extracted from the reloader-URL unambiguously. The end user system 124 begins downloading resources by requesting resources from the HTTP request server 504, step 916. In parallel to requesting the resources, the end user system 124 requests content for a reloader script in the iframe. To retrieve the reloader script, the end user system 124 sends a reloader request, including the reloader-URL, to the HTTP request server 504, step 920. An example of the request for the reloader-URL is given in Table III below.
The HTTP request server 504 ties the reloader-URL in Table III to the original GET request. One way the HTTP request server 504 ties the reloader request to the original GET request is by extracting the page-URL from the reloader-URL. In this example, a referer header has a value of the original GET request (i.e., the page-URL). If the page-URL is equal to the value extracted from the reloader-URL, and if a cookie “transaction-ID” is sent with a value of “ACTIVE,” then the headers are “correct” and the reloader-URL is tied to the original GET request. Other embodiments require at least one of the referer header, the cookie transaction-ID, the cookie status, or the reloader-URL to be correct for the headers to be considered “correct.”
The HTTP request server 504 withholds a response to the reloader request until the HTTP request server 504 receives a response from the origin 112. In the meantime, the HTTP request server 504 sends resources to the end user system 124 in step 924. The origin 112 sends the web file to the HTTP request server 504 in step 928. Once the HTTP request server 504 has the web file, HTTP request server 504 sends the end user system 124 a reloader response, step 932. An example of a reloader response is given in Table IV below.
In the reloader response, if the headers were “correct” in the reloader request, then the reload-URL in Table IV is equal to the page-URL. If headers are not correct, then the reload-URL is equal to a disposable-URL, wherein the disposable-URL is a recognizable URL constructed from the page-URL, transaction-ID, and a randomly generated URL-ID.
The end user system 124 executes the reload response above triggering a replacement of the webpage by a page specified by the reload-URL. The end user system 124 makes a second web file request, step 936. An example of the second web file request is given below in Table V. If the headers were correct, then the reload-URL is equal to the page-URL; if the headers were not correct, then the reload-URL is equal to the disposable-URL.
The HTTP request server 504 recognizes the second web file request as a final request. In several embodiments, the HTTP request server 504 recognizes the second web file request as the final request by comparing the page-URL to the referer header (reloader-URL) and/or the cookie transaction-id and/or status. A second way the HTTP request server 504 recognizes the second web file request is a final request is by recognizing the disposable-URL. If the second web file request is not recognized as a final request, then the second web file request is treated as an initial request. If the second web file request is a final request, the HTTP request server 504 responds to the end user system 124 with the web file, step 940. A sample response instruction to the second web file request by the HTTP request server 504 is given in Table VI below.
Referring next to
In several embodiments, the second entity has an agreement with the first entity for the resource server to deliver content objects. The resource server is a cache in an terminal network providing internet service to the end user. The terminal network chooses, sua sponte, to deliver one or more resources to the end user device 124 without receiving specific direction from the second entity. The terminal network notifies the second entity that the terminal network delivered one or more resources. In other embodiments, the terminal network does not notify the second entity that the terminal network delivered the one or more resources.
Referring next to
Referring next to
The end user system 124 requests resources in the iframe in step 916. In several embodiments, the resources are requested from the HTTP request server 504. The HTTP request server 504 sends the resources to the end user system 124, step 924. In several embodiments, the end user system 124 requests and/or receives resources from the resource server.
In step 928, the origin 112 sends the web file to the HTTP request server 504. After obtaining the resources listed in the iframe, the end user system 124 executes the replacement script and makes a second web file request for the web file, step 930. An example of the second web file request is given in table VIII below.
The HTTP request server 504 recognizes the second web file request is a final request based on the page-url in the referer header. The HTTP request server 504 responds with the web file, step 940. Other embodiments include using a cookie and/or other header to identify the second web file request is a final request.
In several embodiments, the HTTP request server 504 records request and delivery IP address information. If a preloader file for a given webpage, for a given delivery IP address, is provided a certain number of times within a certain timeframe, the HTTP request server 504 recognizes the request as a final request. For example, if the HTTP request server 504 provided a preloader file for a given webpage, for a given delivery IP address, three times in the last five seconds, then the HTTP request server 504 would respond with the given webpage instead of another preloader file.
Specific details are given in the above description to provide a thorough understanding of the embodiments. However, it is understood that the embodiments may be practiced without these specific details. For example, circuits may be shown in block diagrams in order not to obscure the embodiments in unnecessary detail. In other instances, well-known circuits, processes, algorithms, structures, and techniques may be shown without unnecessary detail in order to avoid obscuring the embodiments.
Implementation of the techniques, blocks, steps and means described above may be done in various ways. For example, these techniques, blocks, steps and means may be implemented in hardware, software, or a combination thereof. For a hardware implementation, the processing units may be implemented within one or more application specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), processors, controllers, micro-controllers, microprocessors, other electronic units designed to perform the functions described above, and/or a combination thereof.
Also, it is noted that the embodiments may be described as a process which is depicted as a flowchart, a flow diagram, a swim diagram, a data flow diagram, a structure diagram, or a block diagram. Although a depiction may describe the operations as a sequential process, many of the operations can be performed in parallel or concurrently. In addition, the order of the operations may be re-arranged. A process is terminated when its operations are completed, but could have additional steps not included in the figure. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, its termination corresponds to a return of the function to the calling function or the main function.
Furthermore, embodiments may be implemented by hardware, software, scripting languages, firmware, middleware, microcode, hardware description languages, and/or any combination thereof. When implemented in software, firmware, middleware, scripting language, and/or microcode, the program code or code segments to perform the necessary tasks may be stored in a machine readable medium such as a storage medium. A code segment or machine-executable instruction may represent a procedure, a function, a subprogram, a program, a routine, a subroutine, a module, a software package, a script, a class, or any combination of instructions, data structures, and/or program statements. A code segment may be coupled to another code segment or a hardware circuit by passing and/or receiving information, data, arguments, parameters, and/or memory contents. Information, arguments, parameters, data, etc. may be passed, forwarded, or transmitted via any suitable means including memory sharing, message passing, token passing, network transmission, etc.
For a firmware and/or software implementation, the methodologies may be implemented with modules (e.g., procedures, functions, and so on) that perform the functions described herein. Any machine-readable medium tangibly embodying instructions may be used in implementing the methodologies described herein. For example, software codes may be stored in a memory. Memory may be implemented within the processor or external to the processor. As used herein the term “memory” refers to any type of long term, short term, volatile, nonvolatile, or other storage medium and is not to be limited to any particular type of memory or number of memories, or type of media upon which memory is stored.
Moreover, as disclosed herein, the term “storage medium” may represent one or more memories for storing data, including read only memory (ROM), random access memory (RAM), magnetic RAM, core memory, magnetic disk storage mediums, optical storage mediums, flash memory devices and/or other machine readable mediums for storing information. The term “machine-readable medium” includes, but is not limited to portable or fixed storage devices, optical storage devices, and/or various other storage mediums capable of storing that contain or carry instruction(s) and/or data.
While the principles of the disclosure have been described above in connection with specific apparatuses and methods, it is to be clearly understood that this description is made only by way of example and not as limitation on the scope of the disclosure.
This application is a continuation of U.S. patent application Ser. No. 13/887,187, filed May 3, 2013, entitled “TWO-FILE PRELOADING FOR BROWSER-BASED WEB ACCELERATION,” which claims the benefit of Provisional Application No. 61/794,794, filed Mar. 15, 2013. This application further claims priority to Provisional Application No. 61/880,572, filed Sep. 20, 2013. Additionally, this application is related to U.S. patent application Ser. No. 13/946,777, filed Jul. 19, 2013. Each of these applications is incorporated by reference for all purposes.
| Number | Date | Country | |
|---|---|---|---|
| 61794794 | Mar 2013 | US | |
| 61880572 | Sep 2013 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 13887187 | May 2013 | US |
| Child | 14139501 | US |
