Font-awesome: font-awesome kits using poor Cache-Control headers

[StevenMapes]

Font-Awesome Kits are great but they use a terrible cache-control header of just 60 seconds which is pretty poor for a CDN. Ideally this value should be able to be customised at the kit level but it could certainly be cached safely for an hour or a day. With kits that are fixed to versions then it could even use a longer cache of a month or even 6 months since it's a version locked release

The current header is cache-control: max-age=60, private, must-revalidate

[tagliala]

Hi!

Thanks for being part of the Font Awesome Community.

Are you referring to the main kit .js file?

I think that this is an intended choice because:

1. kits are small files updatable by user files with new settings
2. filenames they are not hashed, otherwise users should update their code
3. long cache times will prevent to see changes

@robmadole any thoughts on this?

[StevenMapes]

@tagliala - Yes, as the kit URL loads in the main js file but its never cache as a CDN so it means that browsers are always fetching the full files which is bad practice.

Users could break the caching by adding querystring parameters to the kit url which would cause most browsers to invalidate the cache and treat it as a new fetch.

The kit.js files use these response headers

accept-ranges: bytes
access-control-allow-methods: GET
access-control-allow-origin: *
access-control-max-age: 3000
cache-control: max-age=60, private, must-revalidate
content-encoding: gzip
content-length: 2126
content-type: text/javascript
date: Fri, 31 Jan 2020 22:00:23 GMT
etag: "003937fa1ef6efb4ddf3114511dd63da"
last-modified: Sun, 29 Dec 2019 17:51:54 GMT
status: 200
vary: Access-Control-Request-Headers, Access-Control-Request-Method, Accept-Encoding
x-hw: 1580508023.cds258.lo4.hn,1580508023.cds042.lo4.c

Then the full pro.min.js uses these

accept-ranges: bytes
access-control-allow-methods: GET
access-control-allow-origin: *
access-control-max-age: 3000
cache-control: max-age=60, private, must-revalidate
content-encoding: gzip
content-length: 14108
content-type: application/javascript
date: Fri, 31 Jan 2020 22:00:23 GMT
etag: "1576018248"
last-modified: Tue, 10 Dec 2019 22:50:48 GMT
status: 200
vary: Access-Control-Request-Headers, Access-Control-Request-Method, Accept-Encoding
x-hw: 1580508023.cds206.lo4.hc,1580508023.cds256.lo4.c

In both cases the only issue a 60 second cache

[tagliala]

@StevenMapes thanks for the heads-up

Then the full pro.min.js uses these

Sorry again, but I think this is referring to the __latest__ pro.min.js. As per its nature, again, it could not be cached for a long expire time, otherwise you will not see changes.

If you are worried about cache, you should not use latest and go for a specific version

Here it is how a Pro kit looks like with 5.12.0:

Request URL: https://kit-pro.fontawesome.com/releases/v5.12.0/js/pro.min.js
Request Method: GET
Status Code: 200  (from memory cache)
Remote Address: 151.139.128.10:443
Referrer Policy: strict-origin-when-cross-origin
accept-ranges: bytes
access-control-allow-methods: GET
access-control-allow-origin: *
access-control-max-age: 3000
cache-control: max-age=31556926

Let me know if you can see the same with a specific version

[seezee]

Following this. FWIW, the short cache headers apply to the individual SVGs as well as the Javascript when using the kit set to "latest."

[StevenMapes]

https://kit-pro.fontawesome.com/releases/v5.12.0/js/pro.min.js

I can confirm that it is this and only effects latest. 60 seconds still feels very short. Personally I feel like it should be increased to perhaps an hour, it's still short but it will at least save some bandwidth for clients and is a 60 minute delay the worst thing in the world? If not then a warning should be added to the website to discourage it's use unless people know and accept the impact it could have on their users.