Databases Reference
In-Depth Information
Figure 1-14.
Examining gzip compression in YSlow
You can see in Figure 1-14 that the GZIP (KB) column now has a figure in it, showing that we are
indeed compressing the content on the web server before sending it to the browser. Using the
apex_4.0.js file as an example, which is a standard JavaScript file included by APEX itself, you can see
that before compression, it was 67.2Kb in size, whereas post compression it was reduced to 19Kb in
size— roughly less than a third of the original size. As a rough guide, I typically find that JavaScript, CSS,
and HTML files compress to anywhere between 1/3 to 1/5 of their original size, depending on the
amount and type of content.
Another thing to notice from Figure 1-14 is that very small files, such as
apex interactive reports 4 0.js
, aren't compressed since the potential reduction in size is minimal
compared to the slight processing overhead in compressing the file. This leads us nicely into a question
I'm often asked regarding web server compression:
Is there an overhead in compressing the files?
The answer is, yes, there is, since the CPU has to do some work to compress the content. However,
with the modern CPUs these days the overhead is extremely minimal (compared to, say, 15 years ago
when it was much more noticeable). My stock answer to this question would be
Yes, there is a very minimal overhead, but it's more than outweighed by the benefits.
In the topic
Pro Oracle Application Express
I do some benchmarking to determine the performance
benefit of compressing the files. Again, rather than reproducing it all here, I will share the final results. In
the benchmarking I simulated a large number of end users hitting the web server and requesting
different pages. I tested the response of the server with gzip disabled and then with it enabled. The
difference in the results was surprising even to me.
