• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Question Nginx caching on websites

tomaszt

New Pleskian
Hello, I got a question because I have turned the gzip on with the following lines

gzip on;
gzip_disable "MSIE [1-6]\\.(?!.*SV1)";
gzip_proxied any;
gzip_comp_level 5;
gzip_types text/plain text/css application/javascript application/x-javascript text/xml application/xml application/rss+xml text/javascript image/x-icon image/bmp image/svg+xml;
gzip_vary on;

I did it because not the full content was gzip after I turned the Nginx caching on the websites but when I test it on WebPageTest - Website Performance and Optimization Test my Cache Static Content is the same like before have someone a solution for this or need it more time than one day to get better cache or something?
 

Attachments

  • screencapture-plesk-titson-pl-smb-web-web-server-settings-id-3-2021-08-14-15_12_17.png
    screencapture-plesk-titson-pl-smb-web-web-server-settings-id-3-2021-08-14-15_12_17.png
    274.7 KB · Views: 30
Caching and compression are two different things.

The compression settings seem fine to me at first sight. These will compress static files (the mime types given), so that less traffic is needed. Normally compression is faster than the traffic transfer time the uncompressed file version needs, so it's a good thing to compress all the static stuff. You can test whether a file is being compressed or not here: GZIP Compression Test

Nginx caching works different. It does not compress files, but it stores static files that have been requested recently in RAM. When the same file is requested again, no hard disk access is required, but Nginx delivers that file from its cache. In your setting you have configured that static files only remain in the cache for 5 seconds. If you want to improve this, change the duration to something much longer. But: To flush the cache in case longer caching periods are causing issues (e.g. if an image is not updated properly in the user's browser), you'd need to remove the cache on the Linux console, because there is no "flush cache" function on the GUI.
 
Caching and compression are two different things.

The compression settings seem fine to me at first sight. These will compress static files (the mime types given), so that less traffic is needed. Normally compression is faster than the traffic transfer time the uncompressed file version needs, so it's a good thing to compress all the static stuff. You can test whether a file is being compressed or not here: GZIP Compression Test

Nginx caching works different. It does not compress files, but it stores static files that have been requested recently in RAM. When the same file is requested again, no hard disk access is required, but Nginx delivers that file from its cache. In your setting you have configured that static files only remain in the cache for 5 seconds. If you want to improve this, change the duration to something much longer. But: To flush the cache in case longer caching periods are causing issues (e.g. if an image is not updated properly in the user's browser), you'd need to remove the cache on the Linux console, because there is no "flush cache" function on the GUI.
Okay what do you prefer to set the time to remain cache?
 
It depends on your application. On Sites that are rather static, you can easily set this to a day or even longer. On sites that have new content frequently, e.g. a shop or a blog, a much shorter time is probably better.
 
It depends on your application. On Sites that are rather static, you can easily set this to a day or even longer. On sites that have new content frequently, e.g. a shop or a blog, a much shorter time is probably better.
I have some shops and some static pages so maybe shop with low traffic and sales 2/3 per day will be 1 hour good and static one day what you think about that?
 
But: To flush the cache in case longer caching periods are causing issues (e.g. if an image is not updated properly in the user's browser), you'd need to remove the cache on the Linux console, because there is no "flush cache" function on the GUI.
This is really one of my biggest gripes. If Plesk offers caching OOTB but not a way to clear it, it's really quite useless except for micro caching. Does Plesk expect everyone to implement purging themselves?

Also it do not cache it :/
I doubt that is properly detecting caching. Look for the x-proxy-cache header to see if caching is working

Do I need maybe to change it to Nginx
No.

You may need to, however, add cookie bypasses - by default, most applications will set some sort of cookie - wp-settings, wp_logged_in, PHPSESSID, etc. If any cookies are present, NGINX is configured to bypass the cache by default.
 
This is really one of my biggest gripes. If Plesk offers caching OOTB but not a way to clear it, it's really quite useless except for micro caching. Does Plesk expect everyone to implement purging themselves?


I doubt that is properly detecting caching. Look for the x-proxy-cache header to see if caching is working


No.

You may need to, however, add cookie bypasses - by default, most applications will set some sort of cookie - wp-settings, wp_logged_in, PHPSESSID, etc. If any cookies are present, NGINX is configured to bypass the cache by default.

Okay according to the last one I'm not sure or do I understand it correct.

Now I need to find out witch cookies does WP store and set it to do not cache in the Plesk or is it already in Plesk set up?
I turned it on trough the WordPress websites page in Plesk so I was thinking that it's know what need to be not cached, also if woocomemrce says do not cache pages like /cart /my-account etc do I need to set this there to? and if how can I do it because I do not see there an option to exclude some url.
 

Attachments

  • Schermafbeelding 2021-08-19 152151.png
    Schermafbeelding 2021-08-19 152151.png
    24.9 KB · Views: 10
The cache expiration header is something different from Nginx caching. Nginx caching is a RAM cache on the server that keeps static files in RAM to avoid additional, unnecessary requests to the hard disk when a static resource that has previously been delievered is requested again. This is normally a short time cache. That cache is server-side only. The browser does not know about it, there is no header in the HTML stream for it. You control the expiration of that cache in the Nginx cache settings.

The cache expiration header you are talking about is a browser-side cache. The web server tells the web browser, how long it shall cache resources. This setting can be controlled by settings in the web server configuration, either Nginx or Apache or both. For example as described in How to enable leverage browser caching for nginx? or How to enable leverage browser caching for Apache in Plesk .
 
The cache expiration header is something different from Nginx caching. Nginx caching is a RAM cache on the server that keeps static files in RAM to avoid additional, unnecessary requests to the hard disk when a static resource that has previously been delievered is requested again. This is normally a short time cache. That cache is server-side only. The browser does not know about it, there is no header in the HTML stream for it. You control the expiration of that cache in the Nginx cache settings.

The cache expiration header you are talking about is a browser-side cache. The web server tells the web browser, how long it shall cache resources. This setting can be controlled by settings in the web server configuration, either Nginx or Apache or both. For example as described in How to enable leverage browser caching for nginx? or How to enable leverage browser caching for Apache in Plesk .
Okay I saw this to and did like on the links you have send but when I do it I have still the same issue it's not working :/
Maybe some other options?
 

Attachments

  • screencapture-plesk-titson-pl-smb-web-web-server-settings-id-3-2021-08-19-18_53_40.png
    screencapture-plesk-titson-pl-smb-web-web-server-settings-id-3-2021-08-19-18_53_40.png
    365.3 KB · Views: 26
  • Schermafbeelding 2021-08-19 185458.png
    Schermafbeelding 2021-08-19 185458.png
    271.5 KB · Views: 25
Back
Top