Caching static files is the cheapest speed there is: the browser does not ask at all. The risk is the opposite one - a stylesheet cached for a year that you then need to change, on a machine you cannot reach.

The rule that makes long caching safe

Cache aggressively ONLY files whose name changes when their content does. Then a change is a new name, the old cache is irrelevant, and no visitor is ever holding the wrong file.

/css/site.a1b2c3.css        <- safe to cache for a year\n/css/site.css?v=1788541047   <- the same idea, from the file mtime

What to set

location ~* \.(css|js|woff2|jpg|png|webp|svg)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
}

location ~* \.(html|php)$ {
    add_header Cache-Control "no-cache";
}

immutable tells the browser not even to revalidate. no-cache on HTML does not mean "do not cache" - it means "check with me first", which is exactly right for a page whose content changes without its address changing.

Never cache a file with a stable name for a long time. /css/site.css cached for a year is a year of visitors on the old design, and there is nothing you can do from your side to shorten it.

Check what you are sending

curl -sI https://yourdomain.com/css/site.css | grep -iE "cache-control|expires|etag"

ETag and Last-Modified

These make the CHECK cheap rather than the request unnecessary: the browser asks, the server answers 304 Not Modified, and no body is sent. Good for HTML, and second best to not asking at all for assets.

Behind a CDN, remember two caches. Purging the CDN does not reach a browser that has the file for a year - which is the reason the name has to change.