Caching strategy using ETag and Expires/Cache-control with no assets version/ID

Question

After reading a lot about caching validators (more intensively after reading this answer on SO), I had a doubt that didn't find the answer anywhere.

My use-case is to serve a static asset (a javascript file, ie: https://example.com/myasset.js) to be used in other websites, so messing with their Gpagespeed/gmetrix score matters the most. I also need their users to receive updated versions of my static asset every time I deploy new changes.

For this, I have the following response headers:

Cache-Control: max-age=10800
etag: W/"4efa5de1947fe4ce90cf10992fa"

In short, we can see the following flow in terms of how browser behaves using etag

For the first request, the browser has no value for the If-None-Match Request Header, so the Server will send back the status code 200 (Ok), the content itself, and a Response header with ETag value.

For the subsequent requests, the browser will add the previously received ETag value in a form of the If-None-Match Request Header. This way, the server can compare this value with the current value from ETag and, if both match, the server can return 304 (Not Modified) telling the browser to use the latest version of the file, or just 200 followed by the new content and the related ETag value instead.

However, I couldn't find any information in regards to using the Cache-Control: max-age header and how will this affect the above behavior, like:

1. Will the browser request for new updates before max-age has met? Meaning that I can define a higher max-age value (pagespeed/gmetrix will be happy about it) and force this refresh using only etag fingerprint.
2. If not, then what are the advantages of using etag and adding extra bits to the network?

Answer 1

1. No, the browser will not send any requests until max-age has passed.

2. The advantage of using ETag is that, if the file hasn't changed, you don't need to resend the entire file to the client. The response will be a small 304.

Note that you can achieve the best of both worlds by using the stale-while-revalidate directive, which allows stale responses to be served while the cache silently revalidates the resource in the background.