cdn raygun is not gzipped
aaronjensen
Posted on
Oct 01 2015
https://cdn.raygun.io/raygun4js/raygun.min.js does not appear to get served gzipped. For something that is meant to be loaded fairly early in the page load this is pretty problematic.
curl 'https://cdn.raygun.io/raygun4js/raygun.min.js' -H 'Pragma: no-cache' -H 'Accept-
Encoding: gzip, deflate, sdch' --compressed -I
HTTP/1.1 200 OK
Content-Type: application/x-javascript
Content-Length: 20231
Connection: keep-alive
Date: Fri, 25 Sep 2015 21:02:47 GMT
Cache-Control: max-age=2592000
Last-Modified: Wed, 22 Jul 2015 03:57:54 GMT
ETag: "3d9af349615413341ede9eeb1a3b8d55"
Accept-Ranges: bytes
Server: AmazonS3
Age: 452451
X-Cache: Hit from cloudfront
Via: 1.1 87a5dc4906ffb6323c3ec65df37e46f1.cloudfront.net (CloudFront)
X-Amz-Cf-Id: rE8FvUP_lIw85o3TBRp6F0ooH_e5ZmtRmTV8dBFqLlNNiPYx6EY7Cg==
Callum
Posted on
Oct 02 2015
Hi,
Unfortunately this feature isn't supported by our infrastructure provider (S3 via Cloudfront) - auto gzipping is not currently available - for this an application server is required after CloudFront to rewrite the compressed resource request to uncompressed if the client doesn't support gzipping, which naturally we can't guarantee. We're keeping an eye on this and will ensure it's enabled if Amazon decide to implement it.
You will note however that in the above payload Cache-Control is set and thus the resource is cached in the client (browser) for 30 days, thus making subsequent requests for raygun4js instantaneous as the network request is not performed at all due to it using its cached local copy, and therefore gzipping is redundant after the first load.
To enhance the first load experience we're working on a V2.0 release which has a more sophisticated async loading mechanism which will making the script download time irrelevant. We're aiming to get this released in the near term.
aaronjensen
Posted on
Oct 02 2015
I had no idea. http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/ServingCompressedFiles.html#CompressedS3 blows my mind. Dynamic html based on their content encoding acceptance? nuts. Thanks for getting back to me, 2.0 sounds great. In the meantime we'll probably just include it in our packed js.