Twitter platform JavaScript is not gzipped

[paulschreiber]

The Twitter platform JavaScript (https://platform.twitter.com/js/button.56d4a00aea1af069615f067f4e79aaba.js) is not sent gzipped. Sending it gzipped would result in a 66% savings.

Request Headers:

Accept: */*
Accept-Encoding: gzip, deflate, br
Accept-Language: en-CA,en;q=0.8,en-US;q=0.6,fr;q=0.4
Cache-Control: no-cache
Connection: keep-alive
Host: platform.twitter.com
Pragma: no-cache
User-Agent: Mozilla/5.0 (Linux; Android 6.0; Nexus 5 Build/MRA58N) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.90 Mobile Safari/537.36

Here are the response headers:

Accept-Ranges: bytes
Cache-Control: public, max-age=315360000
Content-Length: 4293
Content-Type: application/javascript; charset=utf-8
Date: Mon, 07 Aug 2017 18: 22: 09 GMT
Etag: "a8bc1f57d6ea37f29bbfdfa7d72500cd"
Last-Modified: Thu, 27 Jul 2017 23: 31: 34 GMT
P3P: CP="CAO DSP LAW CURa ADMa DEVa TAIa PSAa PSDa IVAa IVDa OUR BUS IND UNI COM NAV INT"
Server: ECS (lga/13CE)
X-Cache: HIT

[saysmax]

Hi Paul - thanks for bringing this to our attention! I’ve been able to reproduce this issue, and am currently looking into the cause. I’ll update this thread once resolved.

[saysmax]

Just wanted to follow up on this. The issue at hand here is that the asset falls below a configured minimum threshold for which compression is enabled. At ~4k uncompressed, there’s no reason this shouldn’t be compressed, however, and we’ll work to have this corrected.

[system]

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.