Abstract:
A method of optimising web page access and speeding up web page download through high-latency communications networks, such as mobile communications networks. When a user requests a web page, such page is retrieved from a web server and the image and non-image portions of the original web page are separated. Then, there are prepared an image-free web page including the non-image portions of the original page and having the images replaced by correspondingly sized and positioned placeholders, and an image in which the non-image portions are made transparent and the original images are grouped into a single composite image, while keeping their positions and their sizes. The image-free page and the image page are superimposed to form an optimised web page having the same appearance as the original one, which is downloaded to the user.

Description:
FIELD OF THE INVENTION  
       [0001]     The present invention refers to wireless communication networks, and more particularly it concerns a method of optimising access to and speeding up download of web pages in said networks.  
       BACKGROUND OF THE INVENTION  
       [0002]     Conventionally, domestic access to the Internet has taken place through the PSTN (Packet Switched Telephone Network), by using analogue modems. Such access is characterised by a rather limited latency between the page request and the page presentation on the user&#39;s equipment.  
         [0003]     With such kind of access, download time of a web page depends, in a first approximation, only on the ratio between the page size (in bytes) and the channel throughput. Thus, most web pages currently available have been designed so as to ensure limited download times through a reduction of their overall sizes.  
         [0004]     With the increasing use of wireless techniques, such as those conforming to GPRS (General Packet Radio Service), EDGE (Enhanced Data rates for GSM and IS-136 Evolution) and UMTS (Universal Mobile Telecommunication System) standards, for access to the Internet, the criterion of reducing the overall page sizes is no longer adequate, due to the very high latency time that characterises mobile wireless networks.  
         [0005]     In a high latency network, the download time of a web page depends not only on the page size, but also on the number of objects referenced therein. In fact, a HTTP (Hyper Text Transfer Protocol) negotiation is necessary for downloading each object, and such negotiation needs a minimum time corresponding to the round trip time (RTT) of the network, which time is the sum of the network latencies in both directions.  
         [0006]     Consequently, for a same nominal throughput of a PSTN and a wireless link (e.g. a GPRS link), access to and download of a web page through a GPRS link is much slower than through a PSTN modem.  
         [0007]     A number of products, generally designed as Performance Enhancing Proxies (PEP), intended to decrease web page download time in high-latency networks, have become commercially available and are described in the literature. The general principles of the PEPs and of their application can be found in document RFC 3135 of The Internet Society, “Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations”, by J. Border et al., which document is available at the site http:/Iwww.ietf.org/rfc3135.txt.  
         [0008]     Essentially, two classes of PEPs exist: client-server PEPs, demanding installation of a software on the client device, and client-free PEPs, which do not have such requirement.  
         [0009]     An example of client-free PEP is disclosed in WO 03/15330 A, which teaches a parallelisation of a number of HTTP requests and, consequently, of the objects being downloaded. A data compression is further performed before forwarding the images to the user.  
         [0010]     The client-server architectures are generally based on replacing the standard HTTP protocol by more performant protocols, and thus they are intrinsically more efficient.  
         [0011]     Examples are disclosed in WO 01/63420 A, which teaches a system where use of predictive requests and a predictive server is made, or in US 2003/197725 A and U.S. Pat. No. 6,704,024 B, which disclose systems where web pages and other visual contents are rasterised and displayed on the client device as bitmap images.  
         [0012]     US 2001/003823 A discloses a system, based on a client-server architecture, for downloading a web page in a manner suitable for display on a television screen. This document discloses a web page conversion aimed, inter alia, at reducing the latency time. To this end, such system separates the text and image portions of an original page by downloading first the text portion of the page with any image replaced by a corresponding placeholder; then the images are retrieved and downloaded, in order to fill the placeholders. Applicants remark that, due to the use of a client-server architecture, this system has the general drawbacks inherent in this type of architecture. Moreover, downloading the text and the images in subsequent phases reduces only the apparent time of the page download, since this procedure is based on the assumption that the latency is due to the time needed by the server to provide the images themselves. The actual latency time, related to the number of HTTP negotiations, is not however reduced by such systems, since the images are individually downloaded. Moreover displaying first the text only, and then the whole page with the images, can be uncomfortable for the user.  
       SUMMARY OF THE INVENTION  
       [0013]     The Applicant has observed that the approach outlined by prior-art client-free Performance Enhancing Proxies find a limitation in the fact that known solutions are scarcely effective, as they are inherently limited by the HTTP protocols. Moreover, the degree of parallelisation of HTTP requests, cannot exceed certain limits, in order to avoid saturation of the available upstream bandwidth.  
         [0014]     On the other hand, the Applicant observes that PEP systems based on client-server architectures have however the drawback that they need a specific client software, which is difficult to install and to maintain.  
         [0015]     In view of the outlined state of the art and related problems, drawbacks and limitations, the Applicant has tackled the problem of how to provide a system which is implemented by a client-free proxying server (in short, “proxy”), which is able to reduce the download time of web pages and which displays at once the whole page to the user.  
         [0016]     According to the invention, there is provided a method in which, after separation of the image and non-image portions of a requested original web page and replacement of the images by correspondingly sized and located placeholders, at least some of the non-animated images present in the original web page are combined into a single composite image, an optimised web page is created by superimposing the composite image onto an image-free web page comprising the non-image portions of the original web page and the placeholders, and said optimised page is downloaded to a requesting user.  
         [0017]     The creation of the optimised page comprises the steps of: 
        building and temporarily storing the image-free web page;     building and temporarily storing an image page containing the composite image, with the component images located in their original positions, and a transparent area in place of the non-image portion;     building a first list with all links and buttons contained in the original web page, associating said first list with the composite image, and temporarily storing the first list associated with the composite image;     building and temporarily storing a second list with all forms contained in the original web page;     superimposing said first list associated with the composite image onto said image-free web page, and superimposing said second list onto the image-free web page having the first list associated with the composite image superimposed thereon.        
 
         [0023]     Advantageously, the superimposition is obtained by means of a layering technique.  
         [0024]     The invention also provides a computer program product loadable in the memory of at least one computer and comprising software code portions for performing the steps of the method of the invention when the product is run on a computer. As used herein, reference to such a computer program product is intended to be equivalent to reference to a computer-readable medium containing instructions for controlling a computer system to coordinate the performance of the method of the invention. Reference to “at least one” computer is obviously intended to highlight the possibility for the arrangement of the invention to be implemented in a de-centralized fashion.  
         [0025]     The invention provides also an apparatus for performing the method. The apparatus is essentially a client-free proxy, which can be configured either as an explicit proxy or as a user-transparent proxy.  
         [0026]     Grouping several images of the original page into a single image significantly reduces the number of objects referenced in the page and hence the number of HTTP negotiations, and thus actually results in a significant reduction of the download time without need of employing special client software. 
     
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0027]     Further objects, characteristics and advantages of the invention will become apparent from the following description of preferred embodiments, given by way of non-limiting example and illustrated in the accompanying drawings, in which:  
         [0028]     FIGS.  1  to  3  show three examples of architectures where the invention is applied;  
         [0029]      FIG. 4  is a general flow chart of the operation of the invention;  
         [0030]      FIG. 5  is a flow chart of the preparation of an optimised page; and  
         [0031]      FIGS. 6A, 6B  are HTML codes of a standard page and of the corresponding optimised page. 
     
    
     DESCRIPTION OF THE PREFERRED EMBODIMENTS  
       [0032]     Three typical architectures in which the invention can be applied are disclosed with reference to FIGS.  1  to  3 . In such Figures, like elements are denoted by like reference numerals, beginning with digit  1  or  2  or  3 , respectively.  
         [0033]      FIG. 1  shows the application of the invention to the optimisation of the web surfing by a user. In such a situation the invention is used to speed up the access to web pages present on any public web server connected to the Internet.  
         [0034]     In this architecture, a computer  100  has access to a mobile wireless network (GPRS/EDGE/UMTS)  103  through a mobile terminal  101  communicating with a network base station, schematised by antenna  102 .  
         [0035]     Wireless network  103  is connected to the Internet  105  through a high-throughput link  104 . Through wireless network  103  and the Internet  105  the users have access to all public servers hosting the contents downloadable by the users. The drawing shows by way of example a single web server  106 , connected to the Internet  105  through a link  107 .  
         [0036]     A web page processing unit  108 , implementing a page conversion according to the method of the invention, is also connected to the Internet  105  through a link  109 .  
         [0037]     Processing unit  108 , referred to hereinafter as “page slicer”, is essentially a client-free performance enhancement proxy exploiting the standard HTTP protocol. It attains a reduction in the latency time through a reduction of the number of images referenced in a page, and hence of the HTTP negotiations, obtained by grouping at least part of such images into a single, bigger image. Through such conversion, page slicer  108  builds and sends to the user an optimised page whose graphical aspect and functionality are the same as in the original page.  
         [0038]     In this application page slicer  108  is to be configured as an explicit proxy, and the users are to insert the page slicer address into the web browser settings.  
         [0039]      FIG. 2  shows the application of the invention to the optimisation of a web site. In such a situation the invention is used to speed up the access to web pages inside the network of a content provider, denoted by reference numeral  210 .  
         [0040]     As before, computer  200  has access to GPRS/EDGE/UMTS network  203  through a mobile terminal  201  communicating with a base station  202  of network  203 , which is then connected to the Internet  205  through high-throughput link  204 .  
         [0041]     Content provider network  210  is connected to the Internet  205  through a high-throughput link  211  and an edge router  212 . Web server  206  and page slicer  208  are located in content provider network  210  and are connected together by a link  213  with suitable throughput. Another link  214  with suitable throughput connects page slicer  208  to edge router  212 .  
         [0042]     In this architecture, page slicer  208  is transparent for the user, who therefore is not to set his/her browser so that the latter includes the page slicer address.  
         [0043]      FIG. 3  shows the application of the invention to the optimisation of the navigation by the mobile network operator. Like in the architecture shown in  FIG. 1 , the invention is used to speed up the access to web pages on any public web server, like server  306 , connected to the Internet. Yet, in this architecture, page slicer  308  is transparent for the user and all HTTP traffic of GPRS/EDGE/UMTS network  303  is redirected towards page slicer  308  by the control units in the wireless network. In this architecture, page slicer  308  is located between GPRS/EDGE/UMTS network  303  and the Internet  305 , and is connected thereto by means of high-throughput links  315 ,  316 , respectively.  
         [0044]     The operations performed by page slicer  108  (or  208 ,  308 ) will now be described in detail with reference to  FIGS. 4 and 5 .  
         [0045]      FIG. 4  is the general flow chart of the operation.  
         [0046]     The first step after the start of the operation is the usual request by a user (computer  100 ,  200  or  300 /mobile terminal  101 ,  201  or  301 , depending on the architecture) of the web page of interest through its browser (step  400 ). The request arrives at page slicer  108  ( 208 ,  308 ), which stores the URL (Universal Resource Location) of the requested page (step  401 ) in a suitable memory area  406  for subsequent use.  
         [0047]     Then page slicer  108  ( 208 ,  308 ) gathers and stores some information about the user&#39;s browser (steps  402 ,  407 ), i.e. it performs an identification of the client/browser pair.  
         [0048]     Such identification is aimed at foreseeing how the original page would be rendered onto the browser, for the optimised page, which will be created according to the invention, to have exactly the same rendering. The manner in which the information about the user&#39;s browser is gathered will be discussed in detail below.  
         [0049]     Then, at steps  403 , page slicer  108  ( 208 ,  308 ) requests the original page (hereinafter and in the flow charts referred to as “OriginalPage”) to server  106  ( 206 ,  306 ) and stores it in a suitable memory area  408 . At step  404 , the page slicer converts OriginalPage into an optimised web page (hereinafter “OptimisedPage”), which has a structure optimising access and download time through wireless network  103  ( 203 ,  303 ) and has the same appearance as the original page.  
         [0050]     At step  405 , page slicer  108  ( 208 ,  308 ) sends OptimisedPage to the user&#39;s browser, and at the same time it saves a copy thereof (as shown at  409 ) in a cache memory, in association with the URL and the browser characteristics, for use in case of subsequent requests.  
         [0051]     The page slicer also implements a fallback mechanism for the case in which the client/browser pair is not recognised. In such case the conversion of step  404  is disabled to avoid supplying the user with a wrongly formatted page, and the user is supplied with the original page.  
         [0052]     The client/browser identification also allows using the optimisation technique in connection with mobile terminals and PDAs (Personal Digital Assistants) equipped with non-standard HTML (Hyper Text Mark-up Language) browsers, which convert the format of a page according to proprietary modalities in order, for instance, to adapt the page to the display size. If the identification reveals that the browser is one such non-standard browser, and page slicer  108  ( 208 ,  308 ) has the information about such browser, the page will be transformed correspondingly. Otherwise, the fallback mechanism provides for sending the original page to the user.  
         [0053]     Turning back to the acquisition of information on the browser, the most important information items are the following ones:  
         [0054]     type of device being used (e.g. personal computer, PDA, Smart Phone . . . );  
         [0055]     type, release and language of the operating system;  
         [0056]     type, release and language of the browser;  
         [0057]     resolution and colour depth of the display;  
         [0058]     size of the viewport of the display.  
         [0059]     To get such information, after the browser has requested OriginalPage and the page slicer  108  ( 208 ,  308 ) has stored the URL thereof, the page slicer sends to the browser a page containing a particular piece of JavaScrip™ code collecting all of the information requested and inserts the above URL into said page, through a proper JavaScrip™ variable.  
         [0060]     Subsequently, the JavaScrip™ code, after having read and stored the parameters requested, makes the browser request again OriginalPage, and the parameters are passed to the page slicer appending them to the URL of OriginalPage according to the conventional technique of the variable-value pairs.  
         [0061]     Then, when a URL relevant to a request, with the appended parameters, arrives at the page slicer, the latter gets OriginalPage from the server, converts the page depending on the parameters and sends the converted page back to the browser.  
         [0062]     Turning now to  FIG. 5 , OptimisedPage is built from OriginalPage, by using the information gathered about the client/browser pair, so as to join all non-animated images contained in a page into a single composite image. In the described embodiment, GIF (Graphical Interface Format) image format has been used, although other image formats are possible. Animated images are not processed and are still to be individually requested.  
         [0063]     The first step  500  is a check about the existence of an optimisation algorithm for the particular browser.  
         [0064]     If that algorithm does not exist, this means that the client/browser pair has not been identified and the fallback mechanism is implemented: OriginalPage is copied into OptimisedPage (step  507 ) and is downloaded to the user. The caching is performed also in this case, as shown at  514 .  
         [0065]     If the algorithm exists, page slicer  108  ( 208 ,  308 ) downloads the HTML code of OriginalPage from web server  106  ( 206 ,  306 ), performs a parsing of the code to identify all non-animated GIF images referenced therein and replaces all references by a reference to a same transparent GIF image of 1×1 pixel (steps  501 ,  509 ). Replacement of each image is performed by maintaining the same size as the original image. If that size is not contained in the HTML code, the physical size of the image is determined and inserted into the HTML code. In this way, the graphical proportions of the page are maintained, and a transparent area or blank (placeholder) of the same size as each image is left on the page. The page so built will be referred to as “No-GIF page”. The No-GIF page is stored in a temporary storage area  510 , in the page slicer memory or on a disk.  
         [0066]     At step  502 , the page slicer performs the memory rendering of OriginalPage (read from memory area  509 ), by taking into account the client/browser pair characteristics previously gathered. Such characteristics are read from storage area  508 . The page slicer eliminates all elements except the non-animated images from the page, by making such elements transparent. The result of step  502  is a single image having the same size as the browser viewport and containing only the GIF images of OriginalPage in their proper positions, whereas the remaining page portion (i.e. the text, Macromedia Flash™ content, etc.) is transparent. This image will be referred to as “GIFImage”. At the same time, the page slicer converts GIFImage into GIF format, thereby creating a suitable optimised palette that is saved, as shown at  511 .  
         [0067]     Should JPEG (Joint Picture Experts Group) or PNG (Portable Network Graphics) images be contained in the page, they will be converted into GIF format so that the transparent placeholders can be built.  
         [0068]     At step  503 , a list of all links and buttons contained in OriginalPage is built, said list including the target URL and the physical position of each said link and button. Such list is associated with GIFImage in an imagemap, and an HTML code block containing said imagemap is built. This block, referred to as “GlFwithLinksBlock”, is also stored in a temporary storage area in the page slicer memory or on a disk, as shown at  512 .  
         [0069]     Then, at step  504 , the page slicer builds a list of all forms present in OriginalPage, together with their physical positions on the page. A further HTML code block, the “FormBlock”, is built containing all said forms. FormBlock is stored in a temporary storage area in the page slicer memory or on a disk, as shown at  513 .  
         [0070]     Then the optimised page is built by the following sequence of operations. 
    1. OptimisedPage is initialised by creating a copy of No-GIF page; this copy forms a base layer having a co-ordinate Z=0;     2. a layer, delimited by tags &lt;DIV&gt; as requested by the HTML rules and positioned with absolute co-ordinates, is appended to this initial OptimisedPage and HTML code block “GIFwithLinksBlock” is inserted into said layer; the layer is associated with co-ordinate Z=1 (that is, the co-ordinate of No-GIF page increased by 1), so that the layer is superimposed to the No-GIF page (step  505 ); the page so built is saved in storage area  514 .     3. a further layer, also delimited by tags &lt;DIV&gt; and positioned with absolute coordinates, is appended to the OptimisedPage obtained by the previous step, and HTML code block “FormBlock” is inserted into said layer; the layer is associated with a co-ordinate Z=2, so that the layer is superimposed to the previous layers (step  506 ). The page so built is saved at  514 .    
 
         [0074]     OptimisedPage is thus ready for being forwarded to the browser and displayed to the user.  
         [0075]     An example of HTML code of OptimisedPage is shown in  FIG. 6B . The different layers mentioned above are clearly apparent in the body of the HTML code.  
         [0076]     Thanks to the way in which it has been built, OptimisedPage is aesthetically and functionally identical to OriginalPage, even if it has a different HTML code (compare  FIGS. 6A, 6B ).  
         [0077]     OptimisedPage contains a lower number of objects, as all GIF images have been combined into and replaced by a single composite image. Moreover, since most of the objects referenced inside web pages are typically GIF images, the reduction of the objects present in a page to be downloaded is actually significant. Since, as said above, the download time in high latency networks is strongly dependent on said number, a significant reduction of the download time of the converted page is achieved. The reduction of the objects present in a page entails a corresponding reduction of the traffic due to HTTP negotiations and thus a more advantageous exploitation of the network resources is also obtained. Moreover, building of the optimised page is independent of the browser installed on the user equipment.  
         [0078]     Note also that, as clearly apparent from the flow charts of  FIGS. 4 and 5 , a caching mechanism has been introduced to save the already optimised pages. In this manner, when a page already processed in the past is requested again, such page can be simply read from the cache without need of reprocessing it. This is important in view of the fact that the method is computationally complex.  
         [0079]     The reduction of the download time can further be enhanced through a compression of the text (HTML codes, JavaScrip™, CSS (Cascading Style Sheet) . . . ) which is to be effected by the standard compression methods for the browser to be able to automatically perform decompression.  
         [0080]     Similarly, also GIFImage could be compressed to reduce its size: for instance, it is possible to reduce the number of colours, or to reduce the amount of details while keeping unchanged the resolution.  
         [0081]     It is evident that the above description has been given by way of non-limiting example and that changes and modifications are possible without departing from the scope of the invention.  
         [0082]     For instance, even if the invention has been disclosed with particular reference to mobile communication networks, it can be applied also for optimising access through satellite links, which have features comparable to those of mobile communications links.  
         [0083]     Moreover, even if it has been assumed hereinbefore that all GIF images in a page are joined into a single image, an alternative solution could be joining groups of GIF images physically close or adjacent to one another, thereby forming a number of composite images. The composite images can then be inserted in a layer in place of the original ones, like the single image discussed above. This alternative solution entails a smaller reduction in the download time, but it reduces implementation complexity.  
         [0084]     Should the original page already comprise multiple layers, another alternative solution could be joining the images separately for each layer. In such situation, the caching mechanism could be performed at the layer level and thus could be more effectively exploited in case different layers have different expiry times: upon request by the browser of layers containing objects already downloaded and having an expiry time not yet elapsed, the optimised layer can be read from the cache, without need of processing again the whole page.