Firstly, you can combine all permutations into one file using the so-called "soft permutations" .
Then you can embed * .nocache.js on the HTML host page (for example, using the JSP @include directive) to cut one additional request (you may need to add <meta name=gwt:property content='baseUrl=myapp'> , where myapp is the subfolder where the .nocache files are located.). AFAIK, what Google is doing for its GWT applications.
Alternatively, you can choose server-side permutations if you can completely replace script (* .nocache.js) choices with server-side content matching (based on User-Agent and Accept-Language requests, for example, headers) directly generate the <script> for the corresponding * .cache.js file (if you use the xsiframe linker).
AFAIK, Google uses all these methods for its GWT applications (e.g. Google Groups). However, for a small application, I'm not sure if it is worth the effort ...
In addition, the last two methods work best when your HTML host page is already dynamic and therefore no longer cacheable; otherwise, you are basically moving the problem, not solving it.
I wonder if the sso linker can be used when you reset all properties and soft permutations to one hard permutation.
source share