How do we enable gzip to reduce latency on both mobile and desktop users of static web resources?
You can upload Google Cloud Storage objects with a gzip Content Encoding, and they'll be served zipped to clients that send Accept-Encoding: gzip, which most browsers do.
See Transcoding of gzip-compressed files for more information.
Related
My company is thinking of moving from AWS to GCP. One of the feature we want to support from CloudCDN is brotli encoding. We have a techstack that will bundle our javascript into 3 files:
chunk.js
chunk.js.gz
chunk.js.br
If CloudCDN receives client request headers Accept-Encoding: br, gzip is CloudCDN smart enough to serve up Brotli file? Moreover, will it be cached? If not, are there any other approaches in achieving this in CloudCDN.
AWS Cloudfront only offers this feature with the use of 2 lamdbas. Which I think is a bad idea.
Yes, Cloud CDN can cache all 3 representations and serve the correct one based on the client's Accept-Encoding header so long as the response from your origin server includes a Vary: Accept-Encoding header. There's more information at https://cloud.google.com/cdn/docs/caching#vary_headers.
Update:
I didn't realize you were using a Cloud Storage bucket as the origin. Unfortunately, neither Cloud CDN nor Cloud Storage have functionality that will rewrite client requests for /chunk.js to /chunk.js.br based on whether the client supports Brotli. I agree that would useful, so I filed an internal feature request.
When an origin server such as nginx is configured to select the appropriate file, Cloud CDN needs to go back to the origin server only on a cache miss. So long as the origin server's responses contain a Vary: Accept-Encoding header, Cloud CDN can serve cache hits directly from the edge by comparing the client's Accept-Encoding request header with the Accept-Encoding value specified when the response was cached. Clients that specify Accept-Encoding: br, gzip will be served from one cache entry while clients that specify Accept-Encoding: gzip will be served from another.
CloudFront now supports Brotli compression natively. If you're using S3 as your origin (or any origin that returns uncompressed content), CloudFront can automatically compress at the edge using Brotli or Gzip. You don't need to create three versions of the file or use Lambda#Edge.
https://aws.amazon.com/about-aws/whats-new/2020/09/cloudfront-brotli-compression/
My backend, in Rocket (Rust), does not have compression built in. So, it is dependent on the proxy to compress it. Though nginx ingress controller supports it, I thought whether the default one had it too as it has high availability.
If it does not have, then how should I setup?
UPDATE(2018-01-31): It looks like Cloud HTTP(S) Load Balancer supports GZIP. You just have to serve compressed content from your backend and the load balancer will pass it on.
However, NGINX is confused because of the Via header (it thinks proxies don't support GZIP, and on most cloud providers this is correct, but not Google). See this FAQ: https://cloud.google.com/cdn/docs/troubleshooting#compression-not-working
If you are using the nginx web server software, modify the nginx.conf
configuration file to enable compression. The location of this file
depends on where nginx is installed. In many Linux distributions, the
file is stored at /etc/nginx/nginx.conf. To allow nginx compression to
work with HTTP(S) load balancing, add the following two lines to the
http section of nginx.conf:
gzip_proxied any;
gzip_vary on;
I believe nginx does not compress requests via a proxy by default.
You can change its config to enable that:
gzip_proxied any;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;
Source: https://blog.percy.io/tuning-nginx-behind-google-cloud-platform-http-s-load-balancer-305982ddb340
We are using IBM CDN and which is mapped to our IIS server. If the resource is getting fetched directly from the server, gzip compression is enabled. But if the same resource is fetched through CDN it is not compressed.
How can I enable gzip compression for IBM CDN resources?
First I think the IBM CDN you mentioned is the CDN service documented here IBM CDN Service
By default, the IBM CDN service will use gzip to compress the response if the content type is one if text/html*, text/css*, application/x-javascript*.
If you found the IBM CDN doesn't compress the content as your origin, then can you share the detailed request and response header from the origin and the CDN?
Bali
I'm bit new to Cloud Storage.
We have an application which uploads files to our FTP server.
Now as our system grows, we would go for Cloud Storage service like Google Cloud Storage.
The main issue is our client software is already distributed to thousands of customers. This client software uploads file with FTP commands.
Now if we plan to change our storage to Google Cloud Storage, is it possible to upload file using FTP commands from our client software to Google Cloud Storage.
You could try running an FTP server on top of a directory mounted with gcs-fuse:
https://cloud.google.com/storage/docs/gcs-fuse
I have a webserver without content-coding (boa and not enough ressources). is there a possibility to put ziped javascript-file on the webserver and unzip it at the browser after downloading like content-coding?
In theory yes. You would need to add the Content-Encoding: deflate header to your http response.
You can not place a zip file created by a zip program on the server to be transferred, as it contains a header with the file structure before the deflate payload begins.
Also mind the differences between gzip and deflate. With gzip, similar is possible, too.