Caching to the limit
If you use a WordPress caching plugin, you can at least make sure that your blog does not have to be dynamically generated every time you call it up. This brings performance, but the end is not reached yet. With the so-called browser caching it can be ensured that the pages are cached directly at the user. The advantage is quickly explained, because if the page is stored by the browser itself, there is no need for real contact with the server. This in turn means that the user gets the page displayed with virtually no real loading time. Ingenious, isn't it? If you want to learn more about caching itself, you should read my other article on the subject see where I explain it in detail again. This is now about browser caching.
Browser Cache: An example
But wait. It is best if I explain the process to you very simply using an example. Let's assume you look at a page with 10 pictures. A list of beautiful artwork, photos or whatever. The first time you call up the page, each image will now reload one by one and very slowly, because the images were stored in the highest quality, so they need a lot of memory and have to be downloaded from the server first. So one graphic after the other builds up before they are finally displayed completely. I'm sure it took 10 to 20 seconds. Really annoying then.
If the browser cache is activated, the first call takes just as long, but the second call does not take any longer. The browser stores all 10 photos on the user's hard disk and depending on their validity, it keeps them in the browser cache for a certain period of time, maybe even for several weeks or months. This means: If you go back to the blog now, for example because you want to share one of the photos with your friends, all photos will be displayed in a flash and directly. This takes less than 1 second, as everything is stored in the browser cache, i.e. on your own hard drive. So even the previously slow loading pictures don't have to be downloaded again and again, because they are already in the cache of the browser.
Browser Cache: The Problem
But now there is a problem with the browser cache. Namely, that cached contents are not automatically renewed. If the user has the images in the cache for a year, they will be displayed for one year (apart from the reload or cache reload in the browser), even if the graphics have changed. Do you understand? What's in the browser cache doesn't notice if something has changed on the server, because the server doesn't have to be contacted anymore. But there is also an example for this:
At 3:00 p.m., a user comes to your blog. At 15:30, you will publish a new article. When the user comes back to your blog at 15:45, he does not see this new article yet, because his browser cache for HTML pages (1 hour in the example) still shows him the old version. Only at 16:00 he would see the new article, because only then the cache loses its validity of one hour. Is that bad now? Not really, but the advantage in terms of performance is enormous and so I always advise to use long cache times if you don't have time-critical news. After all, what does it matter on a normal blog if some users see the new article a little later? Well, actually nothing.
In the end there is of course still a trick to force reloading files in the browser cache if you have changed something spontaneously and want users to see the new version. Either you simply rename the file so that it needs to be reloaded, or you set dynamic values on the file. How to do this I have long since declared. Actually not difficult, but actually also superfluous, if previously optimized with consideration.
Using Cache Control Headers
The most commonly used (and most effective) method for browser caching are the so-called cache control headers. These determine the exact sequence of a file, so that it remains in the browser cache of the respective visitor for only one week, one month, one year, or perhaps even only for one hour. So you should consider how often your content changes and adjust the value accordingly.
Header set Cache control "max-age=31536000, public" Header set Cache control "max-age=2628000, public"Header set Cache control "max-age=3600, public"
No fear of browser caching
Many bloggers are really afraid of the browser cache, because it cannot be emptied just like that. This is unfounded, in my opinion, because the browser cache is one of the most sensible and strongest optimization measures, which can also take a lot of load off the server and ensure perfect loading times for the users. Especially if images and CSS files etc. do not change, it is easy to provide more performance because once stored, they can always be accessed from your own hard disk. The best thing to do is to try it out.
You can find much more information about caching, for example how exactly the WordPress Cache actually works, on the Subpage for WordPress Performance. There are a lot of other tips and also more information about caching (further down the page). Just have a look.