the matters defined in this detailed description are provided to assist in a comprehensive understanding of the described embodiments . accordingly , those of ordinary skill in the art will recognize that variation changes and modifications of the embodiments described herein can be made without departing from the scope and spirit of the described embodiments . also , description of well - known functions and elements are omitted for clarity and conciseness . note that in this text , the term “ comprises ” and its derivations ( such as “ comprising ”, etc .) should not be understood in an excluding sense , that is , these terms should not be interpreted as excluding the possibility that what is described and defined may include further elements , steps , etc . fig1 presents the architecture of a conventional intermediate node for web content caching in a communication network . the node comprises a web caching application ( 1 ), which is in charge of managing web content requests from users , requesting web content to a remote server , and generating read and write requests to the data storage media of the node , that is , a ram memory and a hard disk . the node may also comprise any other additional application ( 2 ). the node further comprises kernel application programming interfaces ( 3 ) to manage the different resources of the operating system of the node , such as a central processing unit ( cpu ) scheduler ( 7 ). both the web caching application ( 1 ) and any other additional application ( 2 ) share the system memory through a memory manager ( 6 ) that also implements , typically , virtual memory and memory access protection . all devices are accessed through specific device drivers ( 4 ). a file system ( 5 ) manages all hard disks and offers the logical new of disks , in form of files and directories . in conventional web caching systems , in order to access files in hard disks , the web caching application ( 1 ) calls different kernel apis ( 3 ), but all calls are treated uniformly because operating systems are typically designed to provide a fair service to all applications . being agnostic to the characteristics of each application , web caching applications ( 1 ) implemented in conventional storage systems can suffer unnecessary response time degradations due to sudden disk write operations . fig2 presents a schematic of a web caching application ( 1 ) implemented in an intermediate node according to the system and method of the described embodiments . the described embodiments use a conventional web caching network delivery plane ( 13 ) while only affecting the web caching object management ( 14 ). the operating system plane ( 15 ) is also unaffected by the described embodiments . as any other web caching system , web caching network delivery plane ( 13 ) comprises a request manager ( 8 ) and a download manager ( 9 ). the request manager ( 1 ) is in charge of accepting web content requests ( typically hypertext transfer protocol , http , requests ) from end users and generating the required answer . the download manager ( 2 ) is responsible of generating requests to the origin servers to retrieve web content missing in the intermediate node . the web caching object management ( 14 ) plane comprises a web caching object pool ( 10 ), which acts as first scheduling means ; a device performance monitor ( 11 ), which monitors the data throughput of the hard disk , and therefore its saturation level ; and an object persistence manager ( 12 ) which acts as second scheduling means . fig3 shows in greater detail the operation of the web caching object pool ( 10 ). when a request of web content is received ( 16 ) at the node , the web caching object pool ( 10 ) checks ( 17 ) if said web content is cached in the node ( either in the ram or in the hard disk ). if the content is not cached ( 18 ), a request to the download manager ( 9 ) is issued ( 19 ), and said download manager ( 9 ) requests the web content to the origin servers . the web caching object pool ( 10 ) finishes ( 26 ) the process until the content is received from the server . if the requested web content is cached in the node ( 20 ), the web caching object pool ( 10 ) verifies ( 21 ) if said web content is stored in the ram . if not ( 22 ), a request to retrieve the web content is sent ( 23 ) to the object persistence manager ( 12 ). otherwise ( 24 ), the web content is delivered ( 25 ) to the user from the ram . in both cases , the process at the web caching object pool ( 10 ) finishes ( 26 ). additionally , the web caching object pool ( 10 ) manages all stored web content objects in the node , tracks a fixed amount of ram memory , and keeps the most popular web content cached in the ram according to any of the object replacement policies for cached data known in the state of the art . when the web caching object pool ( 10 ) determines that a web content that is stored in the ram is to be removed , the web caching object pool ( 10 ) checks if the web content object is already stored in the hard disk . if that is the case , the web content is simply removed from the ram and no further actions are taken . if the object is not stored in the ram , and according to particular embodiments , the caching object pool ( 10 ) may decide to store it in the hard disk , or not to take further actions , in which case the object is effectively removed from web caching at the node and the next request for said object will generate a new request to the origin server . once a web content object is downloaded from the origin server , the download manager ( 9 ) informs the web caching object pool ( 10 ) of the reception of the new object . the web caching object pool ( 10 ) checks if the object has to be cached depending , for example , on http headers and expiring information , or on any other cache management criteria . if the web caching object pool ( 10 ) decides to cache the object , the object persistence manager ( 12 ) is requested to store the object in the hard disk . otherwise , the object is only stored in the ram and no other operation is performed at the hard disk . fig4 presents the components of the object persistence manager ( 12 ) in order to manage write requests ( 27 ) and read requests ( 29 ) directed towards the hard disk . write requests ( 27 ), that is , requests to store web content in the hard disk , are queued in a first queue ( 28 ) by the web caching object pool ( 10 ). read requests ( 29 ), that is , requests to retrieve web content from the hard disk are queued in a second queue ( 30 ) by the web caching object pool ( 10 ), having the second queue ( 30 ) a greater priority than the first queue ( 28 ). a disk operation scheduler ( 31 ) comprised in the object persistence manager ( 12 ) receives information about the status of the hard disk , regarding its data throughput and therefore its saturation level , from the device performance monitor ( 11 ), and schedules requests queued in the first queue ( 28 ) and second queue ( 30 ) into a disk operation queue ( 32 ). when the throughput of the hard disk is above a given first threshold , that is , when the hard disk is performing many read and / or write operations , no write requests ( 27 ) from the first queue ( 27 ) are scheduled through the disk operation queue ( 32 ), thus giving priority to read requests ( 29 ). however , in scenarios with a low operation load at the hard disk , that is , when the hard disk data throughput is below a second threshold , lower than the first threshold , multiple write requests ( 27 ) queued at the first queue ( 28 ) may be scheduled through the disk operation queue ( 32 ). the hard disk accesses the items of the disk operation queue ( 32 ), that is , the queued read operations ( 29 ) and read operations ( 27 ) and performs the corresponding tasks ( write data into the hard disk or retrieve data from said hard disk ). when a disk operation ( that is , a read or write operation in the hard disk ) is completed ( 33 ), the disk operation scheduler may queue more operations in the disk operation queue ( 32 ), prioritizing read requests ( 29 ). all the queues of the object persistence manager ( 12 ) are fifo queues . since requests queued at the object persistence manager ( 12 ) may correspond to web content of different sizes , the disk operation scheduler ( 31 ) converts these requests into disk operations with a fixed size , that is , disk operations that retrieve or write a fixed number of bits . also , since write requests ( 27 ) can be infinitely delayed in the first queue ( 28 ), the object persistence manager ( 12 ) periodically checks if the web content related to the write request ( 27 ) is expired . if the web content is expired or is close to be expired , the write request ( 27 ) is cancelled by the object persistence manager ( 12 ), avoiding unnecessary write operations . the disclosed scheduling architecture and policies allow to prioritize users requests for web content cached in the hard disk versus data storing operations issued by the web caching object pool ( 10 ), and therefore improving the overall experience of the user , who perceives a shorter delay when asking for data cached in the hard disk . also , the method and system may be advantageously combined with any other web caching optimizing technique regarding hardware , allocation criteria , or object replacement techniques .