dynamic cache for accessing a web service deployed on a server through a telecommunications network

By dynamically assigning cache durations based on server traffic, the method alleviates server load during peak times in web TV applications, optimizing user experience and reducing energy consumption.

FR3159280A1Pending Publication Date: 2025-08-15ORANGE SA
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
FR2024001430
Authority / Receiving Office
FR · FR
Patent Type
Applications
Current Assignee / Owner
Filing Date
2024-02-14
Publication Date
2025-08-15

AI Technical Summary

Technical Problem

Web TV applications face significant server load due to high variability in request rates and large traffic peaks, leading to inefficiencies in server sizing and increased energy consumption, which is costly and ecologically detrimental.

Method used

A method for dynamically assigning a cache duration for web pages based on server traffic measurements, reducing server load during peak times by caching pages for a duration proportional to the measured traffic, and incorporating this information into HTTP headers.

Benefits of technology

Balances server load with user experience by minimizing server requests during high traffic periods, ensuring timely updates during normal conditions while reducing energy consumption and operational costs.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 00000000_0000_ABST
    Figure 00000000_0000_ABST
Patent Text Reader

Abstract

Method for access by a client (C) to a web service deployed on a server (S) through a telecommunications network (N), said method comprising steps of: reception (S1) of a request (mr) designating a requested page associated with said web service, measurement (S2) of traffic relating to said server, and allocation (S3) of a cache duration for said requested page as a function of said measurement Figure for the abstract: Fig. 3
Need to check novelty before this filing date? Find Prior Art

Description

Title of the invention: dynamic cache for accessing a web service deployed on a server through a telecommunications network FIELD OF THE INVENTION

[0001] The present invention relates to the downloading from a server to a telecommunications client of a web page referencing a set of elements to be dynamically determined. It applies particularly to web pages of web applications that may face significant traffic peaks, such as "web TV" type applications.

[0002] A Web TV type application aims to offer the usual services of a connected television from a browser that can connect to a website. A user of a computer or any telecommunications device (such as a digital tablet, smartphone, etc.) can thus connect to the “web TV” application and view a chosen audio or audio-video program via their browser.

[0003] “Web TV” type applications thus aim to offer a bouquet of audio and / or video content to users, this content being able to be broadcast live (or “live streaming” in English) or delayed in the form of videos on demand.

[0004] Such an application can aggregate content from different sources.

[0005] The content offering may vary over time, particularly because audio-video content is inherently linked to current events, but also because content providers may regularly update their offering for marketing reasons.

[0006] Also, the content offering may vary depending on the users. They may be registered with the application and have access to content that may therefore depend on their profile, including channels or packages to which they have subscribed.

[0007] It therefore appears that the application cannot present a static web page, at least as a home page, but a page dynamically constructed according to the time at which the request is received and the user from whom this request comes.

[0008] The web page then typically consists of a minimal static frame and references to elements that are dynamically incorporated into the page, in order to construct this web page on demand so that it can be produced on the human-machine interface of the user's browser.

[0009] These elements can in particular be determined by computer code (typically in Javascript language) incorporated or referenced in the frame of the web page. This computer code is intended to retrieve the dynamic elements in databases based on, for example, contextual parameters (user ID, current time, etc.) and the logic implemented by the computer code.

[0010] When it receives a request from a user's client (telecommunications terminal, computer, etc. hosting a web browser), the server hosting the web application can return the web page frame, leaving it up to the client to execute the computer code and determine and then download the various constituent elements of the web page, in order to produce it on the terminal screen.

[0011] However, a "web TV" type application may have a commercial purpose. It is then desirable to adapt it in order to obtain the greatest possible visibility on the Web. This visibility requires good referencing with the various search engines.

[0012] Therefore, the server hosting the web application cannot return only this web page frame and the computer code because they would not be correctly processed by search engines. In particular, these search engines are not adapted to execute the computer code and therefore could not retrieve the different constituent elements of the web page. They could then not take into account the content of these pages and therefore could not reference them correctly.

[0013] The web page must therefore be constructed by the server and transmitted to the clients, once constructed, that is to say after integration of the different constituent elements, dynamically determined.

[0014] This type of operation is generally called SSR for “Server Side Rendering” in English.

[0015] This is a technique used in web development that involves using scripts on a web server that produce a customized response for each user (client) request on the website. Scripts can be written in any of the available server-side scripting languages ​​(such as Javascript, PHP, Python, etc.). SSR is distinct from client-side rendering, in which embedded scripts are executed client-side in a web browser, but the two techniques are often used together. The alternative to either or both types of scripting is for the web server itself to provide a static web page.

[0016] This technique therefore places a significant load on the server, which must be able to construct web pages on the fly for each request received from a user. Conventionally, servers are sized to cope with the load induced by this operation. However, in the context of a Web TV type application, as previously explained, the server must cope with a high variability in the number of requests over time and extremely large peaks.

[0017] For example, before an important event (speech by the President of the Republic, start of a sports competition match, announcement of a catastrophe, etc.), the server may receive a number of requests several dozen times higher than the nominal rate (a few minutes before).

[0018] Sizing the server on the basis of these load peaks would be theoretically possible, but would require on the one hand to predict the maximum intensity of these peaks, and in addition to having resources that are far too large for the nominal regime. To the extent that these load peaks can be relatively exceptional or in any case infrequent, this oversizing would be non-optimal in terms of costs for the server operator and detrimental in ecological terms.

[0019] There is therefore a need to improve the current state-of-the-art proposals.

[0020] It is therefore appropriate to find other solutions to improve the experience of terminal users when switching them on, while minimizing the energy impact. Summary of the invention

[0021] For these purposes, a method is proposed for access by a client to a web service deployed on a server through a telecommunications network, said method comprising steps of - receipt of a request designating a requested page associated with said web service, - measurement of traffic relating to said server, and, - assignment of a cache duration for said requested page based on said measurement.

[0022] In this way, a cache duration can be dynamically assigned based on at least one traffic measurement relating to the server. In particular, this cache duration can be assigned so that the server is less solicited when it is in a loaded state, in order to relieve it. The cache duration can, according to one embodiment, be assigned a zero or minimal value when the server is not loaded. It is thus possible to establish an optimized balance between the load resting on the servers which can impact the user experience and the need to have a requested page in its most recent version.

[0023] According to preferred embodiments, the invention comprises one or more of the following features which can be used separately or in partial combination with each other or in total combination with each other: - the requested page references a set of so-called dynamic elements requiring to be dynamically determined, at least some of said dynamic elements corresponding to audio-video content. The method can thus be applied to the distribution of audio-video content, for example in a CDN type network. - the assignment includes a comparison between the measurement and a specified threshold, and the duration corresponds to a default value when the measurement is below the threshold. Thus, with a default value of 0, the caching mechanism can be triggered only when a certain load is detected, allowing users to access the most up-to-date data in the nominal operating mode. - the duration is proportional to said measurement, which allows a simple implementation of the proposed method, but other embodiments are possible, such as for example a duration established according to levels determined by a set of thresholds to which said measurement is compared. - said assignment includes an incorporation of information relating to said duration in a header of a response to said request. The method can thus be inserted into the protocol exchanges set up, without adding additional messages, and therefore traffic. - this information is inserted into a “Cache-control” field within a response conforming to the HTTP protocol. - said allocation includes an estimate of a change in said traffic measurement and a comparison of said change with an objective to determine said duration. It is thus possible to avoid, or at least limit, the occurrence of traffic peaks by reducing access to servers even before the occurrence of a peak.

[0024] Another aspect of the invention relates to a server comprising at least one processor adapted to deploy a web service and to - receive a request designating a requested page associated with said web service, - measure traffic relating to said server, and - assign a cache duration for said requested page based on said measurement.

[0025] Another aspect of the invention relates to a computer program comprising code instructions which, when executed by a processor of a server, carries out the steps of the method as previously described.

[0026] Another aspect of the invention relates to a data medium on which at least one series of program code instructions has been stored for the execution of a method as previously described.

[0027] Other characteristics and advantages of the invention will appear on reading the following description of a preferred embodiment of the invention, given by way of example and with reference to the accompanying drawings. BRIEF DESCRIPTION OF THE FIGURES

[0028] The attached drawings illustrate the invention: - [Fig. 1] illustrates a telecommunications network allowing the implementation of a method according to embodiments of the invention; - [Fig.2] schematizes an architecture - [Fig.3] illustrates a timing diagram according to one embodiment of the invention. DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION

[0029] [Fig. 1] illustrates an implementation context of a server S capable of hosting a web application A.

[0030] This server S is accessible to clients through a telecommunications network N.

[0031] This telecommunications network can typically be composed of several interconnected networks, in particular an access network allowing customers to connect to a main network (itself made up of an interconnection of subnetworks) or “backbone” in English.

[0032] The clients may be locally connected to a local area network, LN, for example a wireless local area network, allowing them to access a gateway P to the access network. This wireless local area network, commonly called WLAN for "Wireless Local Area Network" in English, may comply with the Wi-Fi protocols, or wifi, as specified in the IEEE 802.11 family (or ISO / IEC 8802-11) standards documents.

[0033] The customer can also directly access the access network, for example a third, fourth, fifth generation cellular network (3G / 4G / 5G) for example.

[0034] Clients can be of different types, their common feature being the availability of means enabling connection to the network. These are essentially radiocommunication components and electronic and computer components enabling the implementation of the protocol stacks necessary for managing the protocols associated with the network and for receiving and transmitting data packets.

[0035] In [Fig.l], three types of clients are represented: a computer ORD, a mobile communication terminal, MOB, and a connected television TV.

[0036] The mobile terminal MOB is typically a smartphone of the type "smartphone" or a digital tablet.... The computer can be a fixed computer (or "desktop" according to the English vocabulary) or portable (or "laptop").

[0037] The TV can be natively connected or connected through a associated device such as an HDMI key connected to the TV.

[0038] An example of an external device communicating with a TV is Chromecast. Chromecast is a real-time media streaming device (media gateway) developed and marketed by Google. The device plugs into the HDMI port of a TV and communicates, via Wi-Fi, with another device connected to the Internet (computer, smartphone, tablet, etc.), in order to display on the TV the multimedia content received from an application compatible with Google Cast technology, from the Google Chrome browser on a computer, or from certain Android devices.

[0039] In the illustrative example of [Fig.l], the ORD and TV clients can access the web application A via the local network LN and the gateway P. The MOB client accesses the web application A directly through the telecommunications network N.

[0040] Access nodes NA1, NA2 allow access to the telecommunications network N, respectively from a mobile client MOB or from a gateway P. These access nodes can be of different types and correspond to different Internet access technologies, allowing a client to access a remote web server.

[0041] The two types of access illustrated are essentially intended to show the diversity of possible connections between a client and the web application A, but are in no way limiting of the different possibilities available according to the state of the art and still to come.

[0042] It should be noted that different intermediate nodes can thus be located on the path of traffic between clients and web servers.

[0043] Clients have software tools adapted to allow the user to connect to a web application and to view content transmitted from this web application. In particular, in the case of a web application of the “Web TV” type, the software tool (commonly called “browser” or “web browser” in English) is adapted to allow the production of audio or audio-video content on a human-machine interface associated with the client (client screen, external screen connected to the client, etc.)

[0044] Audio or audio-video content includes live broadcast content that may be linked to television channels, radio broadcasts, etc. It may also be on-demand content (podcast, video on demand, VoD (“video on demand”), etc.).

[0045] The web application A is intended to provide, upon request from clients, web pages referencing different elements.

[0046] These elements may correspond to areas of the web page, the content of which may be individually determined. For example, in the case of a “web TV” type application, the elements may correspond to channels, video content individuals, to menus, to advertising spaces, etc.

[0047] The elements may be associated with both a visual or graphical representation, and a behavior, particularly when pointed at or selected by the user.

[0048] For example, video content may be highlighted or animated differently when the user points at it (e.g., using a mouse or remote control), and triggered to play full screen when selected.

[0049] Selecting other items may result in other actions, such as opening a new web page.

[0050] In particular, the first page, or home page, can thus be dynamically determined. The web application can also contain dynamically determined pages and static pages (pure HTML code). Some pages can also be a mix of the two, i.e. contain static elements and elements to be determined dynamically.

[0051] As previously stated, this page may be compliant with SSR technology.

[0052] Server-side rendering (SSR) is how traditional websites work: the browser sends a request to the server, the server processes the information and returns an http request containing the complete HTML to the browser, which can then easily perform the rendering.

[0053] Server-side rendering, SSR, allows for better compliance with search engine optimization (SEO) constraints.

[0054] According to this mechanism, the server S constructs a page dynamically when it receives a request from a client from a static frame and referenced elements. The server transmits to the client a complete page in HTML language (for "HyperText Markup Language" in English) with all the tags allowing its proper referencing by search engines.

[0055] These referenced elements (called dynamic) need to be dynamically determined. At least some correspond to audio-video content.

[0056] [Fig.2] illustrates an example of a graphical interface that can be displayed by a screen associated with a client. This example page can be a home page.

[0057] It can correspond to a page transmitted by the server S in response to a request from the client, and constructed dynamically according to the server-side rendering mechanism, SSR.

[0058] This graphical interface can display, concomitantly, a video content, or stream, in a zone Cl, and a navigation zone NAV allowing interactions with the user of the terminal and in particular allowing the video stream to be displayed in the zone CL to be changed.

[0059] The navigation zone NAV comprises a set of zones CS1, CS2, CS3, CS4, CS5 intended for the display of secondary video streams, or content. These secondary contents may, for example, correspond to other television channels.

[0060] Selecting a secondary zone can trigger the display of secondary video content in the main zone CL. The content previously displayed in this main zone Cl can then be displayed in a secondary zone. The user can thus zap from one video content to another video by means of this graphical interface.

[0061] The navigation area may also include menus M1, M2, M3, M4, M5, allowing other navigation options, for example changing the source of multimedia content: this may for example involve connecting to another content server SC, retrieving locally stored multimedia content, etc.

[0062] The graphical interface may include other elements not shown in the figure: menus, drop-down menus or others, accessible for example by means of the selection of a menu M1, M2, ML3, M4, M5, or a key on a remote control associated with the terminal 10, etc. These elements may allow access to still other options, for example to all the available television channels.

[0063] As previously specified, elements of this page can be dynamically determined in order to reflect the different contents, in particular audio-videos, available and accessible to the user according to his profile and the current time (date and time). The web page therefore references these elements which must be determined dynamically, and which will subsequently be called “dynamic elements”.

[0064] The web page may also include static elements, i.e. elements that do not have to be dynamically determined. These static elements do not depend on current events or the user: they may be general information, graphic elements of the web page that are always present, the CSS style sheet, etc.

[0065] According to one embodiment, the web page may be a canvas, or a frame, comprising very few static elements and mainly consisting of elements that must be determined dynamically (dynamic elements).

[0066] Referencing elements in a web page can be done by any known means. These are typically tags or keywords from the HTML language (HyperText Markup Language).

[0067] In particular, the referencing of an element to be dynamically determined can be done by technical means making it possible to automatically trigger this determination. These technical means can be links to resources containing computer code.

[0068] This computer code can be scripts written in one of the available server-side scripting languages ​​(such as Javascript, PHP, Python...).

[0069] It is intended to retrieve dynamic elements in databases in

[0070]

[0071]

[0072]

[0073]

[0074]

[0075]

[0076]

[0077]

[0078]

[0079]

[0080] function for example of contextual parameters (user ID, current time, etc.) and the logic implemented by the computer code. In particular, it can be designed to retrieve the visuals of a video broadcast, a television channel, a menu, as well as the associated actions (in particular allowing the triggering of the downloading of the associated multimedia content from a content server). [Fig. 3] shows a diagram of a timeline according to one embodiment of the invention. In a step S1, the server S receives a request mr designating a requested page. This page may typically be a home page of a web service deployed on the server S. It may, for example, be a home page of a portal for accessing audio-visual content, constructed dynamically, as previously explained with reference to illustrative figures 1 and 2. The request can be issued by any client C, and can pass through at least one intermediate node NI, allowing the routing of messages between the client and the server S. The mr request can be HTTP (HyperText Transfer Protocol) compliant. It can be a GET request from this HTTP protocol. In a step S2, the server performs, or retrieves, a measurement of traffic relating to this server S. This measure may concern the load of the server S and therefore its capacity to respond to requests targeting the page concerned or other pages in general, according to a time constraint (i.e. without significantly impacting the experience of users of clients C.). Thus, this step S2 can include monitoring of one or more load criteria of the server S. These load criteria may include - a number of requests received in a unit of time; - a volume of data transmitted in a unit of time; - a load on the server's microprocessor and / or the occupation of its memory live ; - a number of clients transmitting requests in a unit of time; - etc. One or more criteria can be evaluated and provide a single or multi-valued measure representative of the server load (and therefore of its capacity to process mr requests in a satisfactory manner for users of C clients). In a step S3, the server S allocates, or assigns, a cache duration for the requested page based on the measurement made in the previous step.

[0081] This cache duration can be associated with a response, ma, transmitted by the server S and corresponding to the request mr. This response ma typically corresponds to the page requested and designated by the request mr.

[0082] These intermediate nodes may be all or part of the nodes through which this response ma is routed to the client C.

[0083] This cache duration can be transmitted independently or via this response message ma.

[0084] According to one embodiment, information relating to this duration is incorporated in a header of the response ma to the request.

[0085] In particular, this information can for example be inserted into a “Cache-control” field within a response compliant with the http protocol.

[0086] "Cache-control" is a header (or header field) of the HTTP protocol that specifies the caching behavior of software modules interpreting HTTP messages, notably the C client's browser responsible for displaying the requested web page, but also at least some of the intermediate nodes. These particular intermediate nodes have the means to interpret HTTP messages in order to cache data and reuse it to respond to requests from C clients.

[0087] A "cache-control" header contains a set of key / value pairs. Optionally, several values ​​can be associated with a key.

[0088] A "max-age" key allows you to specify a caching duration. You can therefore insert a cache duration based on the measurement previously carried out.

[0089] A “public” key makes it possible to specify that suitable NI intermediate nodes can also cache data (and not only the recipient C clients). Preferably, this “public” key is also inserted in order to allow caching of the requested page on these intermediate nodes.

[0090] Alternatively, the information can be inserted into the header of the web page that conforms to the HTML language. For example, an attribute "http-equiv="cache-control" can be provided to control the behavior of the cache memory by applications interpreting the web page.

[0091] Thus, step S3 makes it possible to assign a cache duration for the requested page to at least some of the equipment by which the response ma is transmitted, i.e. the client C and the intermediate equipment NI (as a reminder: not all the intermediate equipment is necessarily suitable for performing caching).

[0092] The cache duration is determined based on a measurement of traffic relating to the server S.

[0093] In particular, according to one embodiment, this step S3 comprises a reactive mechanism, S31, according to which the cache duration is directly determined as a function of a measurement. According to this reactive mode, S31, the detection of a traffic peak can thus directly cause the increase of a cache duration in order to curb it.

[0094] According to one embodiment, an anticipatory mode S32 can also be implemented, aimed at determining a future traffic peak. This anticipation can be based on the detection of a progressive increase in the traffic measurement, and / or on a regression from a history of traffic measurements, making it possible to predict a change in the traffic.

[0095] In particular, the cache duration can be determined in order to relieve the server S in case of high traffic, by assigning a high cache duration. Thus, the clients C will use the cached data corresponding to the requested page and, during the caching duration, the server S will not be requested.

[0096] In return, users of client C will not have access to any updates to the requested page (this being constructed dynamically by server S). They will therefore view a potentially old version, out of step with the updates made on server S. To the extent that traffic peaks are usually short-lived, however, the resulting lag, on the one hand, does not last and, on the other hand, is not statistically very significant. It is thus considered that this degradation in data quality is acceptable in view of the performance gain brought about by the reduced load on server S.

[0097] Outside of a traffic peak, the value of the caching duration can be low, so that each call to the web page is the subject of a request to the server S, and the latter dynamically constructs this page. In this situation, the data concerning this page and stored in the caches of the client and / or the intermediate nodes NI will only be used during a short time window (which can possibly be reduced to zero).

[0098] According to one embodiment, a rule can be defined to automatically determine the cache duration from the traffic measurement. This rule can be a function, in particular an increasing function, for example linear. In particular, this duration can be proportional to the measurement.

[0099] The duration can also be established according to levels determined by a set of thresholds to which the measurement is compared. This embodiment will be described more particularly later using a concrete example.

[0100] According to one embodiment, a reactive mode S31 comprises a comparison between the measurement and a determined threshold. The cache duration can then correspond to a default (low) value when the measurement is lower than said threshold.

[0101] When the measurement is greater than the threshold, the cache duration may correspond to a second default value, greater than the first. Or, the cache duration may be determined by an increasing function depending on the measurement, as explained previously.

[0102] In the case of an anticipatory mode, S32, an estimate of an evolution of the traffic measurement can be compared with an objective in order to determine the cache duration. This objective can be a threshold, but also depend on a time distance at which this threshold can be crossed: for example, a traffic peak can be detected if it is estimated that the measurement will cross a threshold in less than X minutes.

[0103] Over time, the server may be required to continuously modify the cache durations in order to adapt to traffic fluctuations. Thus, even in the case of an anticipatory mode, the estimates may be continuously revised, in order to adapt the cache duration to the traffic conditions as measured.

[0104] In a step S34, the cache duration assigned by the server S is used to configure different equipment transmitting the response message ma corresponding to the requested page.

[0105] The cache duration is thus used for at least one device among the client C and an intermediate node NI connecting the client C and the server S.

[0106] These devices (for example the client C and / or at least one intermediate node NI) can store the requested page and the elements composing it in an associated memory, during a period corresponding to the cache duration.

[0107] During subsequent requests, the equipment may, depending on the situation, use the contents of the memory to respond directly to the client, if the contents are still valid (i.e. within the cache duration), or transmit the request to the server S.

[0108] The same applies to client C which, according to the usual mechanisms, checks the contents of its own memory before triggering the transmission of a request to server S.

[0109] One use case of the method concerns audio-video content distribution networks known by the acronym CDN (for "Content Delivery Network" in English). In such a context, as previously described, users of a WebTV service access the service through its home page. This home page is built dynamically by the server. The page contains HTML code with all the tags and metadata for SEO purposes (search engine optimization). The content of the page is dynamic and depends on the programs currently being broadcast (which have just started, the most watched, etc.) as well as the rebroadcast or on-demand (VOD for "Video On Demand") content highlighted (promotion of the most watched content, etc.).

[0110] In order to make this content as dynamic as possible (the most up-to-date information), in the nominal situation, the server does not rely on the cache management of the CDN network nodes or the client's web browsers.

[0111] For this, the server positions the following parameter as the http header of the responses: “Cache-Control: no-cache, no-store, must-revalidate”

[0112] During load peaks, the server is very heavily used.

[0113] In order to limit the impact of these load peaks, the server will dynamically position cache management headers.

[0114] As previously described, the data caching duration is dynamically adjusted in the server so that the exposed information is not too old while ensuring a reasonable server load. The longer the caching duration, the older the data will be and the less loaded the server. The shorter the caching duration (or even zero), the more up-to-date the data will be and the more loaded the server will be.

[0115] The cache management directive is transmitted by the server to the CDN nodes and also to the client's browser by the cache management http header: "Cache-Control: public, max-age=xxx" where xxx is the cache duration in seconds.

[0116] The value of xxx can therefore vary from 1 to a large value (30 for example). The server, depending on its CPU load, can therefore set a more or less large value. A possible rule would be: - If CPU load < 30% No cache - If CPU load between 30 and 50% Cache at 1 second - If CPU load between 30 and 40% Cache at 3 seconds - If CPU load between 50 and 60% Cache at 5 seconds - If CPU load between 60 and 70% Cache at 10 seconds - If CPU load > 70% Cache at 30 seconds

[0117] As seen previously, other types of rules can be considered, as well as a predictive approach, for example based on a regression of the evolution of the load.

[0118] So if the value is set to 5, the server will build a page for a client, set the "max-age" parameter to 5. The HTML page will then be cached in the different nodes of the CDN. The following users in this 5-second window who pass through this same CDN will then directly use the page cached in the node without requesting any resources from the server.

[0119] Of course, the present invention is not limited to the examples and the embodiment described and shown, but is defined by the claims. It is in particular susceptible of numerous variants accessible to those skilled in the art.

Claims

Claims

1. Method for access by a client (C) to a web service deployed on a server (S) through a telecommunications network (N), said method comprising steps of: reception (SI) of a request (mr) designating a requested page associated with said web service, measurement (S2) of traffic relating to said server, and allocation (S3) of a cache duration for said requested page as a function of said measurement.

2. Method according to the preceding claim, in which said requested page references a set of so-called dynamic elements requiring to be dynamically determined, at least some of said dynamic elements corresponding to audio-video content.

3. Method according to one of the preceding claims, in which said assignment (S3) comprises a comparison (S31) between said measurement and a determined threshold, and said duration corresponds to a default value when said measurement is lower than said threshold.

4. Method according to one of claims 1 to 3, wherein said duration is proportional to said measurement.

5. Method according to one of the preceding claims, in which said allocation (S3) comprises an incorporation (S33) of information relating to said duration in a header of a response (ma) to said request.

6. Method according to the preceding claim, in which said information is inserted into a “Cache-control” field within a response conforming to the HTTP protocol.

7. Method according to one of the claims, in which said allocation (S3) comprises an estimation (S32) of an evolution of said traffic measurement and a comparison of said evolution with an objective to determine said duration.

8. Server (S) comprising at least one processor adapted to deploy a web service and to: receive (SI) a request (mr) designating a requested page associated with said web service, measure (S2) traffic relating to said server, and allocate (S3) a cache duration for said requested page based on said measurement.

9. A computer program capable of being implemented on a server, the program comprising code instructions which, when executed by a processor, performs the steps of the method defined in claims 1 to 7.

10. Data carrier on which at least one series of program code instructions has been stored for executing a method according to one of claims 1 to 7.