Consider a customer service desk:
A customer phones in with a request. The customer service agent has no idea what the answer is and puts the customer on hold and phones the product support desk. The product specialist has no idea what the answer is and puts the service desk on hold and phones the product technical department. The technician has no idea what the answer is and puts the support desk on hold and get the manual out.
The manual provides the answer to the technician in complex technical terms. The technician understands the complex technical terms and reconnects to the product support desk and tells the product specialist the answer in technical jargon. The product specialist understands the technical jargon and reconnects to the support desk and tells customer service agent the answer in product jargon. The customer service agent understands the product jargon and reconnects to the customer and tells the customer the answer in plain English. The customer is happy with the answer but not with the time it took waiting on the phone.
If each person in the chain started to keep notes (a cache of information) on the different requests and their answers, they would not always have to phone through or check the manual to get the answer. This speeds things up considerably. However, if the product development team changes the product, the answers that have been noted down might now be out of date.
And so it is with data caching. At each level the answer to a request can be stored to speed things up when the same request is made; but, there needs to be a mechanism to handle changes. When visiting, or working on, a WordPress site, data is cached at a number of levels to reduce the amount of data being sent across the network and to reduce repeated processing.
The cache that most of us are aware of is the browser cache on our own computer or laptop.
The browser cache is a temporary store of the files that were downloaded by the browser to display the website pages we have visited. When you revisit the same page of a website, the browser sends a request to the web server. This request includes details of the relevant files it already has in its cache. The server uses this request to determine what files, if any, need to be downloaded to the browser for it to display the web page.
The next level of caching is handled by the server infrastructure where the website is hosted. (There can be additional intermediate caching, for example, implemented on servers within an Internet Service Provider.)
The web server receives the request from the browser and determines what files the browser needs. WordPress files are always PHP files which the web server has to send to the PHP interpreter. The PHP interpreter identifies and runs any PHP scripts and return HTML files for the requested web pages. When you consider that PHP will often be running the same scripts to produce the same web pages, this is clearly not efficient.
To address this inefficiency, between the web server and the PHP interpreter is the HTTP cache. The HTTP cache is either a WordPress page caching plugin or a server component. The server component will be either a HTTP cache module of the web server itself, or an additional dedicated HTTP cache server like Varnish.
Generally speaking, the caching facility will check its cache to see if it has already responded to this request and if so, return the appropriate page. If the response has not been cached, the request is made to PHP in the normal way and the response now cached as well as being returned to the web server. The difference between using a plugin and a dedicated cache server, is that the plugin uses PHP to check the cache whereas the dedicated cache server can return cached request responses without using PHP at all.
If a requested page is not in the HTTP Cache, it is send to the PHP interpreter for processing.
Like many PHP web servers, WordPress stores its data in a database and used PHP scripts to run database queries to retrieve the data to process the request. To reduce the overhead of repeating database queries, WordPress stores query results in its inbuilt Object Cache. The WordPress Object Cache is created by a core WordPress PHP script so that while the PHP interpreter is processing the request, the Object Cache is in memory on the server. This means that if WordPress identifies the same query, it can get the result directly from the Object Cache without reference to the database.
There are some aspects of the WordPress Object Cache that need to be borne in mind. Core WordPress PHP makes use of the Object Cache by design whereas for plugins and themes to benefit they need to have be designed and developed to make use of the Object Cache through its API. Another aspect is that cached data is held in memory only for the current request and will not be stored persistently across page loads unless you install a persistent caching plugin.