Effective Browser Caching.png

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.

Since the browser cache not only refers to images, but also to HTML pages themselves, as well as CSS and Javascript files that are used on all pages of a blog, caching generally provides more speed. For example, once the CSS file has been cached, it does not need to be reloaded when a subpage etc. is called up. This also applies to logos, scripts and many other elements that are often loaded on all blog pages. This way you save resources and the user has the most important files already on his hard disk, so a new download is unnecessary.

wordpress-browser cache page structure
If the page requested by the browser is already in the cache, contact with the web server is no longer necessary. The page is loaded completely from the browser cache. There is no faster way and the server load is zero.

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.

But if you don't want to do that, you can still load the images, CSS and Javascript files into the browser cache and create an exception for HTML pages so that they are not cached. So at least the resources benefit from the browser cache. For me personally, there is no reason why the browser cache for HTML pages shouldn't be valid for at least an hour, after all, on most blogs something changes at most once or twice a day and the performance generally benefits from the cache.

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.

The example below can basically be transferred to your .htaccess file in exactly the same way. In the example, graphics of any kind for a whole year, CSS and Javascript files for a month and everything else for an hour are placed in the user's browser cache. This default setting is highly recommended for a perfect WordPress performance, because images don't change at all, CSS and Javascript files only rarely and everything else doesn't change very often. Thus the browser cache is used to relieve the server completely and to catapult the loading times into the sky.

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.

About Christian

My name is Christian and I am co-founder of the platform fastWP. Here in the magazine I am responsible for the more "technical" topics but I like to write about SEO, which has been my passion for over 10 years now.

2 thoughts on “Browser Caching verstehen und sinnvoll einsetzten”

  1. Hello Christian, isn't it true that browsers store web pages loaded by themselves in their cache? Has everything I find in my Chrome browser cache, for example, been saved by instructions from the corresponding web pages?

  2. Hi, Jacobus,
    basically yes.
    The browser cache stores images, pages, files, everything that a website brings with it. Depending on the webmaster's settings, the user does not need to reload the files in the cache from the server when visiting the site again, but already has a local copy on his own hard disk.

    The browser therefore automatically saves the page and keeps it as long as the browser cache of the respective website allows. This is very practical, not only for the user who doesn't need loading times for these files anymore, but also for you as a webmaster, because you can reduce the server load extremely. If the image is on the user's computer, it does not have to be downloaded from the server. The result: The user has less loading time and the webmaster generally increases the performance, because the server is relieved significantly. Win-win situation for everyone.

Leave a Comment

Your email address will not be published. Required fields are marked *