google
Google PageSpeed says to enable compression for code.getmdl.io
I don't know if this is being reported correctly, but when I run my site through PageSpeed, it reports this:
Enable compression Compressing resources with gzip or deflate can reduce the number of bytes sent over the network. Enable compression for the following resources to reduce their transfer size by 49.4KiB (81% reduction). Compressing https://code.getmdl.io/1.1.3/material.min.js could save 49.4KiB (81% reduction).
In Chrome dev tools, the size is reported as 60.9 KB and I can't see anything about compression in the response headers (but I'm not sure if it's normally visible here).
Is this expected?
@crhym3 Can we enable gzip compression on the CDN using Google Cloud Storage? Checking the response headers it certainly isn't being zipped.
gzip compression is enabled. getmdl.io is served in exact same way as code.getmdl.io, it's just a matter of how files are uploaded to code.getmdl.io
whoever deploys assets to code.getmdl.io (@sgomes maybe?), they need to do it with gzip enabled.
@sgomes and I debugged this a bit just now. It became clear this is happening at serving time but not for all browsers. For instance, Firefox seems to be getting gzipped content, while Chrome, Safari and Opera don't.
I'll assign this bug to myself for now. Will investigate more.
This is how gzipped content is served at the moment:
We use a combination of request headers (Accept-Encoding, User-Agent) and response headers (Content-Type) to determine whether or not the end-user can take advantage of gzipped content. This approach avoids some well-known bugs with gzipped content in popular browsers. To force gzipped content to be served, clients may supply 'gzip' as the value of both the Accept-Encoding and User-Agent request headers. Content will never be gzipped if no Accept-Encoding header is present.
Is this something you think could be tweaked? If Chrome, Safari, Opera and PageSpeed are all being served uncompressed content, it sounds like the logic might not be working as well as expected!
Running against https:://getmdl.io currently isn't yielding any compression issues which is using the code subdomain for resources. Therefore this seems to have been fixed.
Thanks for the report.
Is it actually fixed? Google PageSpeed is actually complaining about version 1.2.1
Compressing https://code.getmdl.io/1.2.1/material.min.js could save 49,6 KB (81% reduction).
Just tested it too, and I can confirm the file is coming back with gzip compression, looking at the response headers. And that site is definitely not Google PageSpeed :)
True, same on my end. Any idea why PageSpeed is complaining?
EDIT: Included screenshot from PageSpeed.
@LsKs Just tested by running an MDL-using site through PageSpeed Insights, and I can confirm that it does indeed complain about compression not being enabled, even though opening the site in the browser does show compression headers being used. This may be a bug with the tool.
I just tested here by opening the same JS file in Chrome and checking the headers, I do not see gzip in mine. Looks like the server is only gzipping in some cases and not others.
Re-opening for investigation.
This might be an App Engine issue, our host. I'll report back here when I find out more.
Worst case, we might just move off of App Engine, if gzip is worth it and we can't fix it in the current environment.
Gzip is extremely important. Worth moving off App Engine if it can't be stable there.
Any progress on this? Still getting gzip errors on my website using the CDN.
It's 2017 and still material.min.js is served not gzip-ed.
Compressing https://code.getmdl.io/1.3.0/material.min.js could save 49.6KiB (81% reduction).
Therefore I have switched to Cloudflare CDN: https://cdnjs.cloudflare.com/ajax/libs/material-design-lite/1.3.0/material.min.js
@niutech Unfortunately, that's a problem with our current infrastructure, and we need to wait for an upstream solution. unpkg might also work.
Any updates on this? Still getting an F rating on pagespeed and GTMetrix with relation to the inclusion of https://code.getmdl.io/1.3.0/material.min.css https://code.getmdl.io/1.3.0/material.min.js via CDN. This is a major issue for SEO purposes that should be addressed immediately if MDL is intended for using a production environment. Note, the above cloudflare CDN works. Alternatively, listing the cloudflare CDN instead of code CDN may prevent headaches for future devs. Is that possible?
This isn't that major for SEO. Let's not act like your rankings are going to change because one asset is flaky getting compressed. Because that isn't going to happen at all. If you feel it is that important, then you shouldn't use a CDN at all most likely. Self host the asset with http2 enabled and you'd get better performance than a CDN provides.
The problem is debugging the issue in the first place since it is compressed with some requests and not for others. There hasn't yet been a clear pattern as to when and why.
I use another link instead.
https://storage.googleapis.com/code.getmdl.io/1.3.0/material.indigo-pink.min.css
The content is gziped :D
