We are upgrading Oracle Apex behind our hr/payroll popay.net solution, and in the mean time we are looking into minimizing network bandwidth.
The last years we were rolling out many modules within popay.net, like learning, performance management, time management, etc. That focus left us on an older version of Apex. Now time to go to Apex 18..
Our solution uses a few Apex plugins. One is a syntax highlighter for the payroll smart formulas. But the related files of the plugin were not arriving in the browser anymore with Apex 18.
The solution was rather simple. We just set the url prefix in the plugin, we copied the files from the database to the application tier, and the files were served as static files.
One stone. One bird.
Independent of this, we had still a few http-304 calls in our Apex pages, instead of http-200 calls, which are completely handled by browser cache.
A 304 is not that bad, the content is handled locally, but the browser does a ping too much, to be sure he can serve the content locally. Which can be felt for users far away from the server on a slower connection.
These requests were in fact the files of the plugins being served dynamically via the database.
So once again, setting the url prefix of the plugin, copying over the files to the application tier, transformed the call in a static file call, and the browser cache was serving these files locally.
As a result, only the apex page call ../f?p=10000:... was consuming network time, since it need at least to go to the database. All other supporting files come out of the cache, when present.
One stone. Second bird.
The last years we were rolling out many modules within popay.net, like learning, performance management, time management, etc. That focus left us on an older version of Apex. Now time to go to Apex 18..
Our solution uses a few Apex plugins. One is a syntax highlighter for the payroll smart formulas. But the related files of the plugin were not arriving in the browser anymore with Apex 18.
The solution was rather simple. We just set the url prefix in the plugin, we copied the files from the database to the application tier, and the files were served as static files.
One stone. One bird.
Independent of this, we had still a few http-304 calls in our Apex pages, instead of http-200 calls, which are completely handled by browser cache.
A 304 is not that bad, the content is handled locally, but the browser does a ping too much, to be sure he can serve the content locally. Which can be felt for users far away from the server on a slower connection.
These requests were in fact the files of the plugins being served dynamically via the database.
So once again, setting the url prefix of the plugin, copying over the files to the application tier, transformed the call in a static file call, and the browser cache was serving these files locally.
As a result, only the apex page call ../f?p=10000:... was consuming network time, since it need at least to go to the database. All other supporting files come out of the cache, when present.
One stone. Second bird.
