GZip Compression of JSON and IIS
Recently in work we've been monitoring the data usage of one of our main products. In today's modern age as developers we often think of bandwidth as cheap and usually have nice fast internet connections and don't overly worry about the *bloat* of our pages and applications.
Our application is often used on 4G connections and whilst they are fast and performance of the application is overall acceptable we found that its data usage was higher than expected and caused us a few concerns over the amount of GB consumed per month.
We've benefited from GZip compression for many years now and most people don't even think about whether its enabled or running as well as it should be. Turning it on and off is usually as simple as turning on the feature in Server Manager and then enabling Static Compression (for your static files, CSS, Javascript etc) and then enabling Dynamic Compression for the generated HTML etc. So it was assumed all was well.
As I'm paranoid about things I started profiling the data use of our application in day to day use using Google Chrome's Web Inspector to monitor the traffic and see its total data usage over the time. It's worth noting here that for this I enabled preserve log so that page reloads etc didn't wipe my history. As a fail safe I also ran Fiddler as this is more than up to the task of performing this task.
Initially everything looked correct, the response headers on general requests indicated things were gzipped, although a few pages look a bit too bloated and have been earmarked for some optimisation in a later release. Then I noticed that our XHR requests returning JSON looked bigger than I expected a quick look at the response headers showed:
So our dynamically generated content wasn't always being compressed. I double checked the dynamic html files again and they were still being compressed so it wasn't a server load issue. I then wondered what mime types does IIS actually compress when dynamic is enabled. Could it be only doing HTML files or text based types. I then jumped onto our staging environment to double check the configuration setup.
It's worth noting that for IIS 7 - 9 compression settings aren't site scoped, they are at the server level, but in IIS 10 you can now configure this per site. To view these settings open up IIS Manager, click your server and then drill into Configuration Manager. Here navigate to your system.webServer section and focus on httpCompression. Here it lists all of the options available. I then found the mimeTypes it was compressing for and found that although application/javascript was application/JSON wasn't!
In previous years we hadn't used JSON responses that often, alot of our pages simply returned HTML via XHR requests but as things have been modernised JSON has become more and more prevalent so this was quite a big deal.
I then used the UI to add this is and applied it to the server with an IIS Restart, all of our JSON requests were then being GZipped resulting in quicker pages and a significant reduction in bandwidth!
It is worth noting that by adding this we have added a small amount of additional CPU load to the server as it compresses this content but it's more than worth the gain in performance and reduction in bandwidth. IIS is also clever enough to stop compressing Dynamic Content if the CPU load gets too high (you can also configure this via the above settings) so it's a fairly safe operation to perform.
Hope this helps and certainly worth checking your servers setup!
Our application is often used on 4G connections and whilst they are fast and performance of the application is overall acceptable we found that its data usage was higher than expected and caused us a few concerns over the amount of GB consumed per month.
We've benefited from GZip compression for many years now and most people don't even think about whether its enabled or running as well as it should be. Turning it on and off is usually as simple as turning on the feature in Server Manager and then enabling Static Compression (for your static files, CSS, Javascript etc) and then enabling Dynamic Compression for the generated HTML etc. So it was assumed all was well.
As I'm paranoid about things I started profiling the data use of our application in day to day use using Google Chrome's Web Inspector to monitor the traffic and see its total data usage over the time. It's worth noting here that for this I enabled preserve log so that page reloads etc didn't wipe my history. As a fail safe I also ran Fiddler as this is more than up to the task of performing this task.
 |
| Ensuring the data isn't lost when pages change |
Initially everything looked correct, the response headers on general requests indicated things were gzipped, although a few pages look a bit too bloated and have been earmarked for some optimisation in a later release. Then I noticed that our XHR requests returning JSON looked bigger than I expected a quick look at the response headers showed:
 |
| Um.. where's my GZIP... |
It's worth noting that for IIS 7 - 9 compression settings aren't site scoped, they are at the server level, but in IIS 10 you can now configure this per site. To view these settings open up IIS Manager, click your server and then drill into Configuration Manager. Here navigate to your system.webServer section and focus on httpCompression. Here it lists all of the options available. I then found the mimeTypes it was compressing for and found that although application/javascript was application/JSON wasn't!
 |
| O JSON, wherefore art thou JSON ? |
I then used the UI to add this is and applied it to the server with an IIS Restart, all of our JSON requests were then being GZipped resulting in quicker pages and a significant reduction in bandwidth!
 |
| Compress that JSON! |
It is worth noting that by adding this we have added a small amount of additional CPU load to the server as it compresses this content but it's more than worth the gain in performance and reduction in bandwidth. IIS is also clever enough to stop compressing Dynamic Content if the CPU load gets too high (you can also configure this via the above settings) so it's a fairly safe operation to perform.
Hope this helps and certainly worth checking your servers setup!
Comments
Post a Comment