ExpiresByType for css and javascript

[brandozz]

If I'm interpreting the information below correctly, CSS and Javascript files would be cached for 1 month from the first day of access?

# Cache all files for 2 weeks after access (A).
ExpiresDefault A1209600

-and-

ExpiresActive On
ExpiresDefault "access plus 1 month"
ExpiresByType text/css "access 1 month.
ExpiresByType text/x-javascript "access plus 1 month"
ExpiresByType application/javascript "access plus 1 month"
ExpiresByType application/x-javascript "access plus 1 month"

[not2easy]

I don't think so:

ExpiresByType text/plain "access plus 1 month"
ExpiresByType image/x-icon "access plus 1 year.

Notice the period . at the end of the image/x-icon where the close " should be. You would have an error using that. It may not show up as an error, but it can't work as expected.

# Cache all files for 2 weeks after access (A).
ExpiresDefault A1209600

Back to the top, what purpose does this serve if it goes on to increase that in the next set of Expires and use an unspecified format? I understand this is an inherited problem, just trying to understand the reason behind it. I would not be surprised to find that nothing is being cached or else everything is 2 weeks only.

It looks like they are mixing directives and adding in typos.
The ExpiresDefault (Default expiration number and format) sets up the format you plan to use.
The ExpiresByType directive allows you to specify MIME-type and then the kind of number, then the number. The "kind of number" refers to the declaration above where it specifies A (access or now) followed by the number of seconds in two weeks..Then it goes on to throw all that out and use a different format than the one that was set.

Some advice is to double the number shown in your ExpiresDefault A1209600 to A2419200 and take out the rest below that so everything defaults to 1 month if that is the object.

Best advice is to read the documentation and decide which format works best for you and replace all of that with the proper instructions. For Apache 2.4 that information is here: [httpd.apache.org...]

[brandozz]

Thank you taking a look at this. I actually inherited the site from a group of outsourced developers so I'm not actually sure what the purpose of setting the Default is when everything is changed in the next mod_expires group. Could it be to just have a default fall back in case an asset is undefined?

If I'm going through and making updates and changes to items on the site, including css and javascript, what is the best way to ensure that those changes are seen to individuals that are revisiting the site?

As an example, an individual brought a javascript error to my attention. I told them it was fixed but when they revisted the site they received the error since the browser used the cache.

[not2easy]

Normally you would want the browser to cache javascript for a longer term than files that might be updated frequently such as .html files. In this case where you want the browser to get the new version you have two choices:

Temporarily turn off caching for the .js MIME-type and then after the amount of time that it would have expired anyway (say 2 weeks) you can reset .js to have a longer Expiration time. Downside is temporarily slower page loads as every page needs to request a new copy of the .js file and slightly higher bandwidth for the extra requests if that is any issue at all.

The other option is more work for you but handles it easily and faster for users: Upload the corrected script with a new name and update the site to request the new .js file. In this method, a lot depends on how your site is structured (is the .js part of an include that can be updated in one file only - are the pages dynamically or statically generated - is there a CMS involved - or is it a page by page project to change the src="filename.js" request?) If you have the right tools, you can do find/replace actions throughout all related files with one click, if you don't, it is tedious work.

Others may have better suggestions, but you can see that it largely depends on how and where this script is used for the options mentioned.

[brandozz]

I do like that second option. That may provide a good way to stay organized too, perhaps implementing some version control on my javascript files.

[brandozz]

Reading through the Google developer docs to Optimize caching, they recommend "fingerprinting". I was hoping to simply add a query string to the end of the url e.g., styles.css?v=12, would also be an effective solution but it looks like that is not recommended.

[developers.google.com...]

[edited by: engine at 4:47 pm (utc) on Aug 8, 2014]
[edit reason] fixed url [/edit]

[not2easy]

Fingerprinting might be the best way to go for you if your pages are dynamically generated. As mentioned before, the right answer depends on the question. You know what kind of platform you use for your site. The best answer for static html is not the best answer for AJAX for example.

Fingerprinting never interested me because Cache control headers does fine for my sites and gives me control based on file type. I can't help with ETAG generation, sorry. The Link you posted is where I got my information also. :)

[brandozz]

So for something like a WordPress or Drupal site the best approach would probably be fingerprinting?