WebPerf If Modified Since

should be done automatically if you have wordpress caching setup/configured and browser detects no change to a file - see If Modified Since HTTP Header - KeyCDN Support i.e. with centmin.sh menu option 22's cache enabler plugin

and centmin mod 123.09beta01's /usr/local/nginx/conf/staticfiles.conf include file in each nginx vhost has static assets with Cache-Control must-revalidate set too already. But a HTTP 200 status with cache control max-age set response is still better than 304 as the request would be coming from browser cache for subsequent requests anyway.

FYI, 304 status is only returned if web browser/client on repeated visit sends a If-None-Match header request with the etag of the static file saved in it's browser cache from first visit. If client/browser doesn't sent that If-None-Match header, then Nginx won't return 304 status but 200 status.

Example using curl header 1st request with etag header value = 5cf58039-17a69 with browser cache TTL = 2678400 seconds

Code (Text):

curl -I https://domain.com/wp-includes/js/jquery/jquery.js
HTTP/2 200
date: Sat, 02 Nov 2019 08:48:33 GMT
content-type: application/javascript; charset=utf-8
content-length: 96873
last-modified: Mon, 03 Jun 2019 20:16:57 GMT
vary: Accept-Encoding
etag: "5cf58039-17a69"
x-powered-by: centminmod
expires: Tue, 03 Dec 2019 08:48:28 GMT
cache-control: max-age=2678400
access-control-allow-origin: *
cache-control: public, must-revalidate, proxy-revalidate
link: <https://domain.com/wp-includes/js/jquery/jquery.js>; rel="canonical"
server: nginx centminmod
x-cache-status: HIT
accept-ranges: bytes

On 2nd request manually setting If-None-Match header with 1st request's etag value = 5cf58039-17a69 which web browsers may cache

Code (Text):

curl -I -H 'If-None-Match: "5cf58039-17a69"' https://domain.com/wp-includes/js/jquery/jquery.js
HTTP/2 304
date: Sat, 02 Nov 2019 08:49:11 GMT
last-modified: Mon, 03 Jun 2019 20:16:57 GMT
vary: Accept-Encoding
etag: "5cf58039-17a69"
x-powered-by: centminmod
expires: Tue, 03 Dec 2019 08:48:28 GMT
cache-control: max-age=2678400
access-control-allow-origin: *
cache-control: public, must-revalidate, proxy-revalidate
link: <https://domain.com/wp-includes/js/jquery/jquery.js>; rel="canonical"
server: nginx centminmod
x-cache-status: HIT

But looks like Nginx for gzip or brotli compressed HTTP requests it converts that etag value to a weak etag version due to HTTP specifications mean it's semantically the same file but not exactly due to compression

weak etag with W/ prefix = W/"5cf58039-17a69 for gzip encoded HTTP request

Code (Text):

curl -I -H 'Accept-Encoding: gzip' https://domain.com/wp-includes/js/jquery/jquery.js
HTTP/2 200
date: Sat, 02 Nov 2019 08:56:40 GMT
content-type: application/javascript; charset=utf-8
last-modified: Mon, 03 Jun 2019 20:16:57 GMT
vary: Accept-Encoding
etag: W/"5cf58039-17a69"
x-powered-by: centminmod
expires: Tue, 03 Dec 2019 08:56:36 GMT
cache-control: max-age=2678400
access-control-allow-origin: *
cache-control: public, must-revalidate, proxy-revalidate
link: <https://domain.com/wp-includes/js/jquery/jquery.js>; rel="canonical"
server: nginx centminmod
x-cache-status: HIT
content-encoding: gzip

as such 304 won't be returned as client/browser or in this case curl's weak etag = W/"5cf58039-17a69 doesn't match nginx non-weak etag 5cf58039-17a69

Code (Text):

curl -I -H 'Accept-Encoding: gzip' -H 'If-None-Match: "W/"5cf58039-17a69"' https://domain.com/wp-includes/js/jquery/jquery.js
HTTP/2 200 
date: Sat, 02 Nov 2019 08:57:28 GMT
content-type: application/javascript; charset=utf-8
last-modified: Mon, 03 Jun 2019 20:16:57 GMT
vary: Accept-Encoding
etag: W/"5cf58039-17a69"
x-powered-by: centminmod
expires: Tue, 03 Dec 2019 08:56:36 GMT
cache-control: max-age=2678400
access-control-allow-origin: *
cache-control: public, must-revalidate, proxy-revalidate
link: <https://domain.com/wp-includes/js/jquery/jquery.js>; rel="canonical"
server: nginx centminmod
x-cache-status: HIT
content-encoding: gzip

but your have browser level cache via cache-control: max-age=2678400 so doesn't really matter

 

redis nginx cache uses nginx is weak etags due to gzip/brotli compression won't show 304 statuses