It is not a trick question. Without a doubt, our expectation would be that the smaller sized file would download faster, regardless of the speed of our network connection to the server. But how can we reduce the size of payload if we cannot trim the actual contents? A quick and easy way to reduce the size would be to compress the content to be sent in the response.
If we apply this principle to Sugar, the compression of payloads sent from the web server to the browser would result in a snappier user experience, due to faster retrieval of data and other necessary components. As a general rule of thumb, we should always implement a compression methodology in order to help us achieve the best experience possible.
But how can one determine if compression is enabled and being utilized by the web server hosting a Sugar instance?
The image in Figure 1.1 helps us answer that question.
 |
| Figure 1.1: Example ListView response |
To answer our question we must examine the web requests exchanged between our web browser and the web server. This can be easily accomplished within Chrome by accessing the Developer Tools and reviewing the contents of the Network tab, as illustrated in Figure 1.1.
Our goal is to review a request that corresponds with actions such as the ListView and then examine the headers on the response. In the provided image, the selected web request, label #1, corresponds with the action of accessing the ListView. Upon selecting it, the details of the request, including the response from the web server, are displayed on the right hand pane.
Label #2 points us to our main area of interest -- the Response Headers. The information contained in this section is provided by the web server and helps describe the payload. Of special interest is the Content-Encoding header, highlighted by label #3. In this example, you will note this header states gzip. This tells us that the content of the response sent by the web server is indeed compressed, which is exactly what we want.
Were we to examine other requests, we will find that not all of them contain this header, or its value may be set to something other than gzip. That behavior is normal and expected, as the web server will only compress files that match certain MIME types. For the purposes of Sugar, the MIME types of concern and which should be compressed are:
- application/json
- application/x-javascript
- application/javascript
- text/html
- text/css
- text/xml
In Figure 1.1 it is also possible to see the Content-Type header on the response, which happens to be set to application/json. Combined with the Content-Encoding value of gzip, this observation helps us confirm that the web server hosting this instance of Sugar is indeed configured to compress JSON responses used by Sugar.
Should you be seeing different behavior upon examining the responses used by your instance, I would recommend you check out the compression settings on your web server to ensure the feature is enabled.
Further information on enabling compression on Apache and IIS can be found here:
Apache: https://httpd.apache.org/docs/2.4/mod/mod_deflate.html
IIS: https://docs.microsoft.com/en-us/iis/configuration/system.webserver/httpcompression/
Side note: Some load balancers include features which allow the compression to occur at the load balancer instead of the web server. Should this be an option for you, I would encourage you to take advantage of it over configuring it at the web server as it would eliminate the need for the web server to perform the task, ultimately helping reduce its workload.
Great stuff!
ReplyDelete