my site is all happily Gzipped according to:
http://www.gidnetwork.com/tools/gzip-test.php
However when I run it through Yslow I get a F for Gzip and it lists all of my scripts as components that are not gzipped.
Any ideas ?
Have a look in the headers in Firebug and check that the browser is sending
Accept-Encoding gzip,deflate
in the request header and that
Content-Encoding gzip
is being sent by the server in the response header (indicating that gzipping has been applied).
If you used the method in the linked pages to gzip your site, it won't have any effect on the scripts as they are not run through PHP. You'll need to either:
1) configure your webserver of choice (apache2 uses mod_deflate)
2) serve your .js files through php:
<?php ob_start('ob_gzhandler'); echo file_get_contents('whatever.js'); ?>
Related
I was testing my website for optimization and I got this recommendation:
The following publicly cacheable, compressible resources should have a "Vary: Accept-Encoding" header:
So, How do I add Vary: Accept-Encoding header using an embedded yaws to css and js files?
I am an arg_rewrite_mod I believe I should do something from there but i am not quite sure how.
According to the yaws.hyber.org:
Yaws will add Accept-Encoding in Vary header if the support of gzip compression is enabled or if the response is compressed.
The Vary header can be set using yaws:outh_set_vary(Fields) or by returning {header, {vary, Fields}} from scripts (where Fields is a list of header names).
I wrote a custom module for the apache http server as described in: http://httpd.apache.org/docs/2.4/developer/modguide.html
ap_rprintf(r, "Hello, world!");
I've been asked about the behavior of mod_deflate http://httpd.apache.org/docs/2.2/mod/mod_deflate.html .
Will response to the client produced by my module will be compressed by mod_deflate if the client accepts the compression with Accept-Encoding: gzip ?
If my response is already gzipped , can I prevent mod_deflate to work ?
Do you have any reference/link about this ?
Thanks.
By default, it would be compressed if it met the normal conditions. You can opt out a few ways (below in rough order of intrusiveness):
set the no-gzip per-request environment variable (r->subprocess_env)
remove the mod_deflate output filter (mod_proxy_wstunnel.c has an example of moving a filter)
unset the accept-encoding header before writing your response
set a Content-Encoding: gzip response header
The only reference is mod_deflate.c + output filter basics.
When downloading a production copy of jQuery, next to the link it says that the file is 32K Minified & Gzipped. I get Minified but what do they mean by Gzipped?
Is it Gzipped by the webserver like Apache deflate?
update: found this website to see which resources are gzipped http://gzipwtf.com/
When your browser sends a HTTP request to a web server, it can specify the Accept-Encoding field to indicate which compression schemas it supports:
GET /scripts/jquery.min.js HTTP/1.1
Host: www.example.com
Accept-Encoding: gzip, deflate
The server can then choose one of these schemas (but doesn't have to) and specify it in the response header:
HTTP/1.1 200 OK
Content-Encoding: gzip
etc.
So, if the web server is configured to gzip javascript files, and the browser supports it (the vast majority does), then the file will be "gzipped".
Yes, it uses an Apache module called mod_gzip:
http://sourceforge.net/projects/mod-gzip/
Which works (in principle) just like mod_deflate.
That download link is to a hosted file that you may hot-link to in your web pages. The file itself is minified JavaScript.
When the file requested from their hosting server by the browser, it is further compressed in transit using Gzip compression as specified in the content header. When the browser receives it, it gets inflated and stored in the browser's cache.
If you were to host the minified file on your own server it would not necessarily be compressed in transit as described unless you configured your server to use compression.
When I look at every page in live http headers, the page contains the below parts in header:
Accept Encoding: gzip, deflate
Content Encoding: Gzip
When I use websites to check whether it is compressed or not, it says it's not compressed. How can we be sure that a page is compressed?
For example I tested this site in Gzip tester and it says it's not compressed, but I see Content Encoding in live http headers.
Your headers are wrong, it should be:
Content-Encoding: gzip
so basically: dashes not spaces between words in the headername
It's your webserver that needs to add those and do the compression, see https://httpd.apache.org/docs/2.0/mod/mod_deflate.html
When using mod_deflate in Apache2, Apache will chunk gzipped content, setting the Transfer-encoding: chunked header. While this results in a faster download time, I cannot display a progress bar.
If I handle the compression myself in PHP, I can gzip it completely first and set the Content-length header, so that I can display a progress bar to the user.
Is there any setting that would change Apache's default behavior, and have Apache set a Content-length header instead of chunking the response, so that I don't have to handle the compression myself?
You could maybe play with the sendBufferSize to get a value big enough to contain your response in one chunk.
Then chunked content is part of the HTTP/1.1 protocol, you could force an HTTP/1.0 response (so not chunked: “A server MUST NOT send transfer-codings to an HTTP/1.0 client.”) by setting the force-response-1.0 in your apache configuration. But PHP breaks this settings, it's a long-known-bug of PHP, there's a workaround.
We could try to modify the request on the client side with an header preventing the chunked content, but w3c says: "All HTTP/1.1 applications MUST be able to receive and decode the "chunked" transfer-coding", so I don't think there's any header like 'Accept' and such which can prevent the server from chunking content. You could however try to set your request in HTTP/1.0, it's not really an header of the request, it's the first line, should be possible with jQuery, certainly.
Last thing, HTTP/1.0 lacks one big thing, the 'host' headers is not mandatory, verify your requests in HTTP/1.0 are still using the 'host' header if you work with name based virtualhosts.
edit: by using the technique cited in the workaround you can see that you could tweak Apache env in the PHP code. This can be used to force the 1.0 mode only for your special gzipped content, and you should use it to prevent having you complete application in HTTP/1.0 (or use the request mode to set the HTTP/1.0 for you gzip requests).