[Adan]

I’m going with the Cache-Control max-age for caching and Last-Modified for validation. I am using the following code for cache-control in my .htaccess:

FileETag None
Header unset ETag
Header unset Pragma
Header unset Cache-Control
#Header unset Last-Modified

# default cache 1 year = 31556926 s
Header set Cache-Control "max-age=31556926, public, no-transform, must-revalidate"




# cache markup for 1 second
Header set Cache-Control "max-age=1, public, no-transform, must-revalidate"



# cache for 1 week = 604800 seconds
Header set Cache-Control "max-age=604800, public, no-transform, must-revalidate"



# cache image files for 1 month = 2629744 seconds
Header set Cache-Control "max-age=2629744, public, no-transform, must-revalidate"



# cache fonts and media files for 1 month = 2629744 seconds
Header set Cache-Control "max-age=2629744, public, no-transform, must-revalidate"

So I have a question.

YSlow complains that I’m not using any Expires headers. Is that any important nowadays or should I ignore it?

If both Expires and Cache-Control: max-age exist, Cache-Control has priority so the max-age directive overrides the maximum age specified by the Expires header. Also, Cache-Control is http/1.1 standard and Expires is http/1.0. If the client browser does not support http/1.1 Cache-Control will be ignored, but it’s unlikely that there is a browser that doesn’t support it.

Expires depends on accuracy of user’s clock, so it’s mostly a bad choice (as most browsers support HTTP/1.1).

So I guess I should stick to Cache-Control and that I should never use Expires, and ignore YSlow’s recommendation.

[Zaragoza]

I’m going to take a wild guess and say you need to change the default FilesMatch rule to force your own max-age?

Not really familiar with the syntax, but I’m guessing something like this:

#Change this:
# default cache 1 year = 31556926 s
Header set Cache-Control "max-age=31556926, public, no-transform, must-revalidate"

#To this:
# default cache 1 second
Header set Cache-Control "max-age=1, public, no-transform, must-revalidate"

Or add a FilesMatch tag after all the others, but I guess this would technically be slower to process than just specifying the default as above:

# cache for 1 week = 604800 seconds
Header set Cache-Control "max-age=604800, public, no-transform, must-revalidate"



# cache image files for 1 month = 2629744 seconds
Header set Cache-Control "max-age=2629744, public, no-transform, must-revalidate"



# cache fonts and media files for 1 month = 2629744 seconds
Header set Cache-Control "max-age=2629744, public, no-transform, must-revalidate"

# NEW SECTION

# cache fonts and media files for 1 second
Header set Cache-Control "max-age=1, public, no-transform, must-revalidate"

Oh and one last thing, the Content-Type response header is used for rendering (the request header Content-Type is used for transforming the payload for processing) so /my-page/ can be application/xml, text/html or whatever and the page extension could be something else like .pdf or .whatever … It is handy for dynamic pages.

Not an expert in these things, so forgive me if my terminology is incorrect.

[ShikhaTan]

The pages of WordPress use PHP templates so the page extension should be .php. I just needed someone to verify that.

So I proceeded to add php in FilesMatch and it worked.
Do you know anything about my first question? (I’ve edited my post and removed the second)

[Adan]

I’m sure your first quote is based on this:

If a response includes a Cache-Control field with the max-age
directive (Section 5.2.2.8), a recipient MUST ignore the Expires
field.

https://tools.ietf.org/html/rfc7234#section-5.2.2.8

That doesn’t mean that you shouldn’t specify both, it just means that the user agent has to use Cache-Control instead of Expires if it is available. So specifying expires when max-age is present has no impact on HTTP/1.1 compliant user agents, but has the benefit of providing backwards compatibility for HTTP/1.0.

As you noted, this is probably redundant these days, but on the other hand there is no negative impact to specifying it – in fact, it creates better support in case someone uses an HTTP/1.0 compliant user agent.

Something else I’m wondering about, what is the point of caching something for 1 second? Unless you’re concerned about some kind of DoS (in which case the attacker would just ignore the caching headers), a user would probably not try to refresh a page more than once a second unless you’re doing the refresh from a client-side script. Would it perhaps not make sense to set max-age=0 and expires= a date older than now by default and for the other resources you set both max-age and expires to the appropriate values?

[ShikhaTan]

There is a negative impact in performance, because the more directives you use the slower your server becomes, especially if you have to place the code in per-directory configuration files such as .htaccess instead of the main configuration file (e.g. httpd.conf). Plus, your response headers will be a bit bigger if you send both Cache-Control and Expires headers.

HTTP/1.0 browsers have been extinct over a decade ago and there’s little chance of requests from HTTP/1.0 user agents (bots, crawlers, web server scanners etc.). Support for browsers is certainly not the case. But I’ll probably end up using Expires to cover all kinds of clients.

[Adan]

Well I guess if you’re concerned about your payload size, then having your CSS and JS resources minified or even moving all your static resources to a CDN would have a greater impact on size reduction than minimizing header meta-data.

I doubt that it would have a drastic slowdown on your server, unless you’re running a site that serves a massive amount of users simultaneously, in which case it would probably be of greater benefit to scale web servers horizontally than removing a header or two I do get your point though, if it’s not used, why include it…