Both client-side and server-side caching make a difference for most WordPress applications out there.
Client-side caching usually happens in the browser – traditional expire header for assets (cached locally and fetched just during the initial request), using the application storage of your browser to store some results, cookies, HTML5 caching to mimic progressive web applications, and the like.
Server-side caching occurs on the web server in different forms:
- Page caching – rendering a page once and caching it as static HTML files and assets (JS, CSS, images, fonts). No computational power for PHP requests and database queries happens.
- Object caching – WordPress supports transients (among a couple of other hacks), providing you the opportunity to cache specific results or expressions. This includes 3rd party calls to other services – such as the current exchange rates for forex or the weather forecast for the day.
- Database caching – the ability to cache the database results of commonly executed queries. A website can easily generate over a hundred database requests for a heavy page, and this adds up quickly when hundreds of users browse a site with no caching available (most of the time it’s hardly possible). Caching common requests with Redis or Memcached is a common best practice to sort this out – at least for a short interval of 5 to 30 minutes.
- OPcode – PHP itself can be precompiled to bytecode, thus operations are optimized to run much faster through the virtual machine. This makes PHP execution a lot faster by far – especially if you have to run raw PHP scripts at scale.
Additionally, you can leverage other forms of caching such as CDN caching, offloading assets to hundreds of nodes across the world, and then passing cached data both on a browser level (client-side) and server-level, but hosted by the CDN, not your own web server.
In a nutshell, there are two reasons you should opt for more caching layers whenever possible:
Some operations and use cases can benefit more from certain types of caching than others. If you only run a couple of DB queries per page for a small database, DB caching won’t help “that much” unless you run at scale. If every user navigates to a different, unique page (especially valid for membership sites), page caching won’t be super effective (though you can use fragment cache to store most of the page except for the truly dynamic elements).
Even if one caching layer is available, you’ll still execute raw requests without caching which will become a problem once you scale a bit. The fact that page caching doesn’t execute queries doesn’t mean that all of your users will hit the same pages available in the cache pool, thus they will still run DB queries (a lot of them). Even if you’re offloading a portion of the direct hits to the server, you’re still leaving some loopholes that could be fixed.
Check out the WordPress development guide to access more of my resources on WordPress website development.