I have used Squishit to minify and bundle JS and to compress Bundled file I enabled option (Enable Static content compression) in IIS 7.5
Issue is Js doesn't get compressed and I just get minified js but if I enable dynamic content compression then Js gets compressed.
Now problem with dynamic compression is that it does not cache the file and on each request it has to do the compression that take time of CPU.
Can someone help me out why js doesn't get compressed in static content compression mode
and is this the ideal way to send js on client side
JS -> Minify JS (Squishit) -> Compress (Static /Dynamic)
The compression of static files is handled dynamically while the file is considered infrequent by IIS. Once the file is considered frequent it will be compressed and cached. The cached version will continue to be served until it becomes infrequent again. There are 2 config settings you can use in IIS to configure frequent files:
system.webServer/serverRuntime:
frequentHitThreshold: How many times should the same file be requested, before it's considered frequent and cached? Defaults to 2.
frequentHitTimePeriod: Time interval in which the same file should be requested {frequentHitThreshold} times, in order to be cached. Defaults to 10 seconds.
Beware that regardless of the frequentHitTimePeriod you set, a frequent file will always become infrequent if it is not requested after 1 minute. I have no idea if there is a setting for this in the config.
Setting frequentHitThreshold to 1, for example, will mean that the file is always considered frequent by IIS, even from the first request. This will in turn bypass the dynamic compression and be treated only by static compression.
Or you could bypass the hit frequency altogether by setting staticCompressionIgnoreHitFrequency to true:
appcmd set config -section:system.webServer/httpCompression /staticCompressionIgnoreHitFrequency:"True"
Note that the compression levels for dynamic (default 0) and static (default 7) compression are different so will return 2 different file sizes.
Also and this is why I got into this issue in the first place: the ETag for the same file is different between dynamic and static compression even if you use the same levels for both.
Hope this helps.
Related
I observed that Content-Encoded response header was missing, notably Content-Encoded: gzip. I'm using static content compression. The dynamic content compression feature was never installed. I installed it, enabled it, and tested again. This time, Content-Encoded: gzip appeared in the response. The question is why does the response header appear for dynamic content compression but not for static content compression? I'm fairly certain that IIS is applying gzip to static content compression. Here's why:
I have an IIS URL Rewrite outbound rule which modifies the response on an HTML page. The outbound rule yielded Error 500.52, URL Rewrite Module error -- Outbound rewrite rules cannot be applied when the content of the HTTP response is encoded ("gzip"). The rule is not the issue, just evidence that gzip is reportedly being applied. I disabled the rule. That's clue #1.
Clue #2 is I enabled Failed Request Tracing and observed that not only static compression was being applied but the StaticFileModule was storing the compressed file in the following location: C:\INETPUB\TEMP\IIS TEMPORARY COMPRESSED FILES\MY WEBSITE\$^_GZIP_D^\INETPUB\WWWROOT\TEST.HTML.
I read the Microsoft document on IIS HTTP Compression and--I could be wrong--I didn't see any language that suggests gzip can be employed with static compression. Based on the two clues above, gzip is being employed with static compression.
So I go back to the original problem, which is Content-Encoded response header is missing for static content impression, yet evidence suggests that IIS is not only compressing static content but compressing it with gzip. Is this simply a bug? Is this by design?
Static Compression will add Content-Encoded header when it work.
If you enable failed request tracing and trace static compression module. You will see this.
It means static compression won't work if a static file didn't get hit frequently.
If you relay this request doezens times. Then you will see that header.
Be careful that, there is a limit for minimum file size for compression. You could modify that value in IIS manager->server node->configuration manager->system.webServer/httpCompression->minfileforcomp
Currently for our application we have set Maximum reponse size as 512KB.
WHat is the use of this? We have configured to cache js and css files.
But there are multiple js files having size more than 400KB. So does this mean that the cache of IIS is not being used.
I want to follow Google's directive in terms of cache headers for images, scripts and styles.
After reading symfony's documentation about http cache, I decided to install FOSHttpCacheBundle. The I set up rules for path like ^/Resources/ or ^/css/. I then fail to see it the proper headers for my images using Chrome's console.
Alternatively, I have read that, since my server is handling the resource, this is not Symfony that deals with this matter (yet I read in the doc that Symfony Proxy was good for shared-hosting servers, which is what I have).
So should I just add lines to my .htaccess as explained in here, or am I simply misusing FOSHttpCacheBundle? (Or both.)
Static files (including javascript files, CSS stylesheets, images, fonts...) are served directly by the web server. As the PHP module is not even loaded for such files, you must configure the server to set proper HTTP headers. You can do it using a .htaccess file if you use Apache but doing it directly in httpd.conf/apache2.conf/vhost conf (depending of your configuration) will be better from a performance point of view.
If you also want want to set HTTP cache headers for dynamic content (HTML generated by Symfony...), then you must use FosHttpCache or any other method provided by Symfonny such as the #Cache annotation.
I was looking for a good way to minifying my css, js and html codes, and found this package at google https://code.google.com/p/minify/. The issue that I have Nginx web server where this minifying application needs mod_rewrite which comes with Apache only. I got this message when I ran the script:
Your webserver does not seem to support mod_rewrite (used in /min/.htaccess). Your Minify URIs will contain "?", which may reduce the benefit of proxy cache servers.
Now I want to know if there is a way I can use this script on my Nginx server or not? if not, then what would be the alternative to that??
I'm looking for minifying css, js and html that make my web pages fast enough so that my clients can browse my site pages quickly...
any idea?
Thanks
Update #1:
I just found out that I had to add a rewrite rule (replacing .htaccess rule) on my nginx server to redirect the folder and its contents.
location / {
rewrite ^/min/([a-z]=.*) /min/index.php?$1 last;
}
but that redirects to error 404... any idea what the correct code is??
The way you have it is actually correct, the issue that you are having is likely the same one I am (and I'm not sure why it is) but basically it comes down to NGINX's rewrite rules ignoring the ? next to the $1 in the rule.
A work around for this is simply instead of going to example.com/min/f=path/to/file.css just put a ? in front of the f example.com/min/?f=path/to/file.css.
A better method would be to just serve the files as a group:
For the best performance you can serve these files as a pre-defined group with a URI like:
/min/g=keyName
To do this, add a line like this to /min/groupsConfig.php:
return array(
'keyName' => array('//path/to/js/file.js', '//path/to/js/otherfile.js')
);
Chances are though, you may need to use /min/?g=keyName.
As a side note, minifying and bundling isn't just ~1kb it can (and tends to be) much more. It has a huge impact on the user (especially on mobile devices). A browser can make 6 concurrent connections, so if you have any more files than that being downloaded, the user is waiting for them, one of the projects I recently have been working on had roughly 60 requests being made for different js and css files (the original coders were... all inclusive in the plugins department). The entire page was roughly 1 Meg and took 3 seconds to download uncached (nothing was cached, because the previous coders don't understand caching). I minified bundled and compressed everything into 3 files (removed the useless stuff too) and got the entire page down to 20kb uncached, 3kb cached, with an uncached load time under 20ms.
That was an extreme example of poor coding though. One final thought... if you don't go into the config and add the cache directories and cache everything, it will cause a slight performance hit on the server (though, probably not as severe as serving up a dozen extra files). I suggest enabling APC or memcache, or at least specifying the cache folder for it to store the files in.
If I configure IIS to use data compression for static files, the first client usually receives uncompressed content, with later clients getting compressed content. Presumably IIS compresses the file in the background and caches it for later requests.
However, I'd prefer the first client to also receive compressed content. That is: I'd prefer to trade latency for bandwidth. Is there any way I can configure IIS to do this?
Well, it actually works a little bit differently. IIS is not compressing the file in the background but it has a threshold to decide whether is should compress the content at all. This prevents it from using CPU resources and cache store for infrequently requested content. By default IIS will only compress content when it receives two requests for that content within 10 seconds.
You can change these defaults by changing the frequentHitThreshold and frequentHitTimePeriod attributes in the <serverRuntime /> element in web.config (see configuraton reference on iis.net). I've not tested it but I expect that just setting frequentHitThreshold to 1 will give you the desired result.
<configuration>
<system.webServer>
<serverRuntime frequentHitThreshold="1" />
</system.webServer>
</configuration>
Hope this helps.