I set dynamic compression and static compression on in iis7 manager. So html,css,js content is compressed ok and i see in headers Content-Encoding:gzip, but not with image formats: jpeg, gif and even bmp.
Generally speaking, you wouldn't want to. JPEG, GIF, and most (internet) image formats are already compressed. Compressing them a second time would add a lot of server overhead for very little size gain (and possibly a loss).
Related
Is it possible to configure NGINX to compress PNG files it serves. For example I have some PNG files generated by a third party tool and they are uncompressed (do not use PNG compression). I would like to get them compressed before serving them through NGINX. I do not mean gzip, but real PNG compression. Is it even possible ?
As #Tarun mentioned, Google's pagespeed project could help with that. I have used it in the past with some level of success. However, I would advise against it unless you really optimize NGINX's caching as well. You really don't want to be compressing images on the fly every time your server receives a request. Instead, I would compress the png images before they even get to your server. I personally use kraken.io for this, but there are a zillion great compression tools. Then, you are just compressing them one time and not performing the same compression on the fly every time a visitor requests the image.
I noticed a flash of invisible text (FOIT) in Chromium based browsers (Google Chrome and Opera) on some websites, even when the web font file is already cached (browsing on the same site beyond the first load).
A more in-depth look reveals that this has something to do with the caching behavior. A FOIT only happens when the file is loaded from disk cache. Everything looks pretty steady, when the file is served from memory cache (following the built-in web inspector tool).
How can we influence in which cache the web fonts are placed?
Chromium based browsers seem to load gzipped content to disk cache. At least that’s the reason why the used .woff2 files weren’t loaded to memory cache.
As long as woff/woff2 files are already compressed, further gzipping is not necessary (http://www.phpied.com/font-face-gzipping-take-ii/). The bespoken FOIT was gone when I disabled compression for these files (some web servers enable compression for all files by default).
When using Apache as web server this can be archived with the following line of code:
SetEnvIfNoCase Request_URI \.(?:woff|woff2)$ no-gzip
IIS supports two types of compression: static content compression and dynamic content compression. According to applicationHost.config, they are handled by different modules: DynamicCompressionModule (compdyn.dll) and StaticCompressionModule (compstat.dll), and they are configured to compress different types of requests. Also, I’m guessing that the dynamic compression does not cache the compressed requests as opposed the static compression (by default, the compressed files are saved to %SystemDrive%\inetpub\temp\IIS Temporary Compressed Files).
However, besides those obvious differences, I suspect that there is something else. I think that they hook to the IIS pipeline to a slightly different way. Would anybody have an inside into the some more details?
The way I found out was that I was toying with a custom module for modifying CSS files on fly. When the static compression was turned on (and set to handle the default set of files, i.e. also text/css), on cached request my custom module was served the already gzipped content. When I moved text/css to the list of dynamically compressed request, it all started working. But I would like to have a more solid proof that it is really the correct way to do it. Are there some other known consequences / problems?
Update: I think I may have a theory as to why it’s happening. It may not be 100% correct, but it at least it may explain the observed behavior. I think that the static compression module registers itself to the following events (among some others):
RQ_MAP_REQUEST_HANDLER
RQ_EXECUTE_REQUEST_HANDLER
Then when a request for a static file is served, the static compression module in OnMapRequestHandler checks whether the file has been compressed before and whether the actual file has not been changed. If so, it will re-map the request to itself (returning the appropriate redirection using IMapHandlerProvider). When it later actually serves the response in OnExecuteRequestHandler, it sends the compressed file. If, on the other hand, the file has not been compressed before or if it has changed, it does not do the mapping redirect and lets the static content module serve the request and then later in OnPostExecuteRequestHandler compresses the content (and updates its cache). As mentioned above, I'm not saying that this is exactly what's happening (I don't know the source code), it may be only an approximation. Also, the dynamic compression module does not most likely do any of this. It simply compresses the outgoing responses sometimes after RQ_EXECUTE_REQUEST_HANDLER.
Your question is not quite clear, so I will answer a question and hope that it is your question.
The intent of static compression is to compress files that would otherwise be served direct from the hard drive (Css/images/javascript) and as such it compresses each file once and saves the compressed file to disk. This enables very quick very cheap serving of compressed content for static files that change infrequently. It is a pretty safe recommendation to say most website should have static compression enabled.
The intent of dynamic compression is to compress the dynamic responses from ISS modules (asp, asp.net, php, etc.). As this response can be different for each request the compressed output can not be cached. This feature is new from IIS6, though the effect has been achievable in some environments, e.g. by implementing a HttpFilter in ASP.Net. As each request needs to be compressed on the fly this is far more CPU intensive then static compression. So if a server is CPU bound this may not be a good option. Most sites are network and/or database bound so the is often a good idea.
So the dynamic and static refer to the content and effect what strategies can be used.
Some References
http://www.iis.net/overview/DynamicCachingAndCompression
http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/92f627a8-4ec3-480c-b0be-59a561091597.mspx?mfr=true
Experimenting with IIS compression feature, it appeared to me that dynamic module and static module are not so tied to dynamic or static content (especially for dynamic module).
Activate compression for text/html (or text/*) mime type on dynamic module, and not on static module. Access a .html file. Checks the http response in browser: it is compressed. (Tested on IIS 7.5 on 2008R2 server.)
It appears dynamic compression module is not limited to dynamic content. It does compressed static content providing it matches its mime types list and is not already compressed. So I consider it should be understood as a dynamic "compression module", in the sense it gets triggered on each response (based on its mime type criteria, and on accept-encoding request header).
While the static compression module gets triggered a bit like a background process working on files, and starts serving compressed output only once it has them in its cache. Since static compression module does execute farer in the modules stack, it does handle the response prior to dynamic compression module, and so take precedence over dynamic one if it has compressed output to serve.
So for your specific use case, you should disable static compression module on text/css mime type (beware of removing text\* too if present) in order to avoid caching issues defeating your custom css patching module.
You may in addition activate compression of text/css in dynamic compression module for replacing static compression module on this case. But of course, it will then not leverage the static compression module caching ability.
Unfortunately, I have not found any documentation for backing up above statements.
Another option could be trying to alter IIS module execution order. You would have to remove them all in your site configuration, then re-add them, inserting your custom module maybe before the static compression one. But this could be a tricky path.
we wrote CMS apps with asp.net. the user can attach file documents, pdfs to their forms and send to each other. the user can easily download the pdf and other documents but when they want to download jpg file their IE render the jpg file as a binary and show the binaries of jpg file? the IE didn't show the save as dialogue such as other files!
where is problem? and how can I handle this in asp.net? Is it relate to HTTPS? because the user used the https to connect to this cms.
As I understand it, users need to download the files and they are able to do so for some files but not for JPEG? And it shows as binary, what do you mean, it shows the byte codes?
Keep in mind each request has a content type header in the response which will identify to the browser what kind of content it is. This is set a known MIME type such as image/jpeg, ...
Content-Type: text/html; charset=utf-8
Browser loads each resource based on the content type. Having said that, it is up to the browser to load the resource the way it wants. I can personalise and change my browser setting to some point so you have to look at the user's browser if you cannot reproduce it on each machine.
In any case, you need to see the content-type header in the response for the resource (using Fiddler as someone else also suggested) and make sure it is set to a correct value. If it is set to image/jpeg, it will render it as image but if it is set to application/octet-stream it will download it. My hunch is it is set to something else (such as text/html or text/plain) and that is why browser tries to show it as a text.
I'm trying to find the best way to speed up the delivery of the static images that compose the design of an mvc site. The images are not gzipped, nor cached in the server or on the client (with content expire). Options are:
Find why images are not cached and gzipped direcly from IIS6
Write a specialized http handler
Register a special route for static images and write a bynary actionresult method
What could be the best solution in terms of performance?
Best solution is to let IIS do it.
IIS6 Compression - most likely you need to specify file types to be compressed like .jpg, .png, .gif types, etc.
Caching will come from making sure that the correct headers are being sent to the client from code, and i believe there is a setting you can set in IIS that enables it for static content, but i'm not sure on that one.
Surely the gain from gzipping most images is negligable since they're already compressed ?
Naybe you have some really badly compressed PNG files or something?
You might want to check out yahoo's performance advice site which includes some useful tips on optimizing images including links to utilities such as pngcrush.
its much better to use an image optimizing utility ONCE than to rely on IIS to compress them (possibly inefficiently) on the fly.
There's a nice library up on the MSDN Code Gallery that does this. It's called FastMVC.