Some time ago we had a very interesting problem. A customer was running a BSP application via satellite link. On this link, latency was high, bandwidth low, and from my understanding, if the reserved contingent was exceeded, you had to pay per byte of transferred data.
This was in the good old days of handwritten HTML code, and no BSP Extensions were used. (The situation with the BSP extensions is that they provide a much richer user experience, but at the cost of a very much higher level of HTML rendering.)
A typical example of such a page could be (reduced to the absolute minimum for this article):
<!code> <%@page language="abap"%>
<!code>
<!code>
<!code>
<!code>
|
<!code>
1x1 |
<!code>
1x2 |
<!code> </tr>
<!code>
|
<!code>
2x1 |
<!code>
2x2 |
<!code> </tr>
<!code> </table>
<!code> </body>
<!code>
When we test this in the browser, we see:
However, the more interesting thing is to look at the source code in the browser. We see that the HTML code that is displayed in the BSP page lands as-is in the browser.
When writing HTML code, the developer would like to use simple editing techniques such as indentation and empty lines to achieve readable and maintainable HTML code. HTML per se does not require the spaces in the source and ignores it.
We have one huge optimizationpotential here. However, deleting the spaces from the source is not the way we want to go!
Deleting Leading And Trailing Spaces
Of course, the solution is simple. We immediately “improved” the BSP compiler to strip all leading and trailing spaces. This is done during compile time, so that these white space characters play no role at runtime. They are just not there in the compiled code.
This option can be set on the properties tab of each BSP page. Change Page Compression from “None” to “Delete leading and trailing spaces”.
This one compiler option makes no difference to the rendered output seen in the browser. For this simple example, the number of bytes is reduced from 218 to 150 immediately!
Deleting Leading And Trailing Spaces Plus CR-LF
Of course, carriage return/line feed characters (CR-LF) play no role in HTML. With JavaScript source in the page, however, you must be careful. In JavaScript a statement can be terminated with either a ‘;
’-character, or by the CR-LF sequence. The BSP compiler cannot recognize this condition. For any good programmer, the ‘;
’ is automatic in JavaScript source. In this case, the BSP compiler can also be instructed to strip the CR-LF sequences.
The visual output in the browser is still the same; only the byte count has been dramatically reduced again. Now the total is only 118 bytes.
The optimistic reader would conclude at this stage that this option alone provides a nearly 50% reduction. However, in this trivial example, the white space dominates relative to the HTML coding. When this same test was done with a hand-coded BSP page, this optimization reduced the byte count from 3914 to 3203 bytes (about 18%). That is still excellent for just setting one option.
HTTP gzip Compression
Of course, this application-based compression is only the first step. The next interesting aspect is to look at gzip compression. Gzip compression is only available for the HTTP/1.1 protocol (which is the effective standard in nearly all browsers today).
Gzip compression in HTTP is done on a best effort basis. The first criterion is that HTTP/1.1 must be active. This can be checked and verified in the browser, menu: Tools --> Options --> Advanced tab.
Next, the browser must indicate via the ‘Accept-Encoding’ header that it will accept gzip compression.
Last, for the BSP page the checkbox ‘Compression’ in the ‘Transfer Options’ must be checked. This requests that the ICM gzip compress the output as it is streamed to the kernel.
1 Comment
