A big tip-of-the-hat to Seiden Group's Alan Seiden for this month's highly useful Valence tip-of-the-month...
To clarify, modern web architectures rely on pre-loading the majority of the app's code at startup. Once the app is running, subsequent communication with the server is mostly limited to exchanging small chunks of data (typically via AJAX), thereby keeping the app's performance snappy. On high-bandwidth connections, or in cases where the app is already cached in the browser, this initial app load delay is barely perceptible. But on slower connections it's a different ballgame, and the size of the app can make a noticeable difference to the users.
There are a number of ways to reduce the volume of data that must stream from server to client when launching apps in the browser. For instance, tools like Sencha Cmd can significantly reduce Ext JS app size, which when coupled with the browser's natural tendency to cache previously loaded items can do a lot to shave precious seconds from app load times. But these efforts can still be dwarfed by a slow communication pipeline, which cripples the perceived snappiness of an app when a user is launching it for the first time, or after code changes were made, in which case the app load does not benefit from browser caching.
Fortunately there is a highly effective weapon available in the HTTP arsenal to help slay the slow load-time dragon: Apache's mod_deflate module.
In a nutshell, mod_deflate compresses the output from the HTTP server prior to being being sent to the client. The compressed content's smaller size means clients are able to download streamed files faster, resulting in a noticeable time-to-render boost even factoring in the overhead of the browser decompressing the data.
The improvement in load time from activating this Apache module can be quite remarkable. To give you a first-hand anecdote: Recently we were demonstrating Valence at a conference where attendees and exhibitors alike were hamstrung with a rather subpar wifi connection. While the slow internet was a persistent annoyance for everyone, we managed to cut through that hurdle with a jaw-dropping 68% reduction in the initial load time of newly created Valence apps once mod_deflate was turned on.
After testing this compression feature on various versions of IBM i OS (7.1 and higher), as well as the latest builds of all the major browsers, the CNX dev team feels confident in having mod_deflate activated by default in Valence. So if you're installing Valence 5.2 for the first time with the latest build (5.2.20180817.0), you will benefit from this change right away. However if you already have Valence 5.2 installed, the installation utility does not touch your existing Apache configuration so you'll need to make the change yourself manually as follows:
- Log into your IBM i HTTP Server Administration page at http://999.999.999.999:2001/HTTPAdmin (replacing 999.999.999.999 with the IP address of your IBM i system). You may need to start the Admin instance first via STRTCPSVR SERVER(*HTTP) HTTPSVR(*ADMIN).
- Select your Valence 5.2 instance in the "Server" combo box.
- Click on "Edit Configuration File" in the lower left.
- Copy and paste the following text to the bottom of the file, then click the OK button:
# Load extension to deflate (compress) content:
LoadModule deflate_module /QSYS.LIB/QHTTPSVR.LIB/QZSRCORE.SRVPGM
- Restart the Valence server instance
Repeat this process for each Valence 5.2 instance you have created. You can roughly gauge the performance impact of the mod_deflate module on your system by clearing your browser cache and seeing how long it takes to load a few apps prior to making the Apache configuration adjustments. Then repeat this process after mod_deflate has been implemented. While the effect on users internal to your network may be relatively small, users accessing your Valence instance from outside the network (i.e., via VPN) will likely find the reduction in load time to be quite noticeable.
For additional perspective on mod_deflate, please see Seiden's IT Jungle article.