Browser caching of text/html too long

Dear SG Optimizer team,

I believe the http headers concerning text/html in the browser caching feature of SG Optimizer is truly configured wrong and causes serious problems for me and other SG customers.

I believe text/html should not be cached at all. And definitely not for 6 months.

Googles advice for txt/html is to NOT have it cached at all as well.
Please look here for instructions by Google in relation to browser caching:

https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching

This problem came to light for us because we had website customers calling us that their customers did not see the “business closed due to corona lockdown” message the put on their homepage.

So because of SG’s browser caching default http header settings they will see this message after six months depending on when they last visited the site.

I read in another topic here (browser caching values too agressive) where someone reported the same issue, they where told that your caching mechanism is more sophisticated etc. I believe it does not matter how sophisticated your mechanism is because the http headers you send instruct all browsers not to contact the server for another 6 months.

Also you stated you set the “last modified” parameter. I don’t see this header at all when I check for responses.

Here is a response I get on a SG site with browser caching enabled:

HTTP/1.1 200 OK =>
Server => nginx
Date => Thu, 02 Apr 2020 12:05:04 GMT
Content-Type => text/html; charset=UTF-8
Connection => close
X-Cache-Enabled => True
X-UA-Compatible => IE=edge
Link => ; rel=”https://api.w.org/”, ; rel=shortlink
Set-Cookie => wpSGCacheBypass=0; expires=Thu, 02-Apr-2020 11:03:28 GMT; Max-Age=0; path=/
Vary => Accept-Encoding
Cache-Control => max-age=15552000
Expires => Tue, 29 Sep 2020 12:03:27 GMT
alt-svc => quic=”:443″; ma=86400; v=”43,39″
Host-Header => 624d5be7be38418a3e2a818cc8b7029b
X-Proxy-Cache => HIT

Both “max-age” and “expires” control when the server is contacted again. Even if you would set “last-modified” it would probably not matter because the browser will just not contact the server and therefore will not get the newer http headers.

I’ve also done manual testing on this. I truly recommend your team to run some manual tests yourself. First load a page/website with SG Optimizer browser caching enabled on a second client than the pc/mac you normally use (to make sure). Let’s call this the test machine. Then change some text on the website you are using for the test via your normal machine. Close browser on test machine. Re-open browser on testmachine (don’t press refresh) and go the site. You will not see the changes you made to the website. Then check the http headers with chrome webdeveloper tools. You will still see the (SG Optimizer) http headers with the max-age of 6 months, they will not have been updated. That is because the server will not be contacted by the browser for another 6 months because of the http headers. It is really that strict.

The bottom-line seems to be this:

You can force a browser to cache something but you can’t force a browser to update their cache.

You can read more here:
https://stackoverflow.com/questions/39417142/if-a-browser-already-has-cached-a-file-with-max-age-31536000-and-i-lower-to-max

or this:
https://stackoverflow.com/questions/8347595/htaccess-how-to-force-the-clients-browser-to-clear-the-cache

I really think this is huge problem for me and my customers but also for SG customers that have browser caching enabled. Browser caching is fine but your http headers are not in my view.

The solution to me seems simple. Just make sure html is not cached like google suggests.

However this does not solve the damage already done to all returning visitors who visited SG websites that have browser caching enabled. They will see an outdated website for a maximum of 6 months until their browsers decide to contact the server or they will do a manual refresh in their browser. Changing http header settings to unset or change the max-age, expires or last-modified http headers will not work since they will not be retrieved for a maximum of 6 months. I’ve also verified this with manual testing.

Hope you can please look into this thoroughly, verify this issue yourself after manual testing and find a solution for this!

Thanks!

Kind regards,

Sander