首先，您可以使用所谓的soft permutations。

然后，您可以将* .nocache.js内联到HTML主机页面（例如，使用JSP的 @include 指令）以减少一个额外请求（您可能需要添加一个< meta name = gwt：property content ='baseUrl = myapp'> 其中 myapp 是子文件夹，其中 .nocache。文件位于）。
AFAIK这就是Google为他们的GWT应用程序所做的事情。 另外，您也可以如果您可以完全替换选择脚本（* .nocache.js）和服务器端内容协商（基于User-Agent和Accept-Language请求标头，请在服务器端运行 permutation selection 实例），可以直接为t生成一个< script> 标记他适当的* .cache.js文件（提供您使用 xsiframe 链接器）。

AFAIK，Google全部使用这些技巧适用于他们的GWT应用程序（例如Google Groups）。但对于一个小应用程序，我不确定这是否值得付出努力...

另外，当您的HTML主机页面已经是动态的并且因此已经不可缓存时，最后两种技术效果***;否则你主要是解决问题，而不是解决它。

我想知道是否可以使用 sso 链接器当你将所有属性和软排列折叠成单个硬排列。

The compiled JavaScript output of a GWT application is divided into various files, for instance

• *.cache.html
• *.gwt.rpc
• hosted.html
• *.nocache.js

...

I know this is done with the purpose of minimizing the size of the JavaScript, which has to be downloaded by users. For instance so that a Firefox user does not have to load the JavaScript specifically compiled for IE6.

However, especially for small GWT applications it might often be faster to download a single file of say 500kb rather than make two sequential requests first for the 5kb *.nocache.js script and then for the rest of the app (cache.html files, etc.).

This leads me to the question: Is there any framework or procedure to bundle the output of the GWT compiler into a single JavaScript file?

First, you can merge all permutations in a single file by using so-called "soft permutations".

Then, you can inline your *.nocache.js into the HTML host page (e.g. using a JSP's @include directive) to cut one additional request (you might have to add a <meta name=gwt:property content='baseUrl=myapp'> where myapp is the subfolder where the .nocache. files are located).
AFAIK that's what Google are doing for their GWT apps.

Alternatively, you can run the permutation selection on the server-side if you can totally replace the selection script (*.nocache.js) with server-side content negotiation (based on User-Agent and Accept-Language request headers for instance) that can directly generates a <script> tag for the appropriate *.cache.js file (provided you use the xsiframe linker).

AFAIK, Google use all these techniques for their GWT apps (such as Google Groups). For a small app, though, I'm not sure it's worth the effort…
Also, the last two techniques work best when your HTML host page is already dynamic and therefore already non-cacheable; otherwise you're mostly moving the problem, not solving it.

I wonder whether the sso linker can be used when you collapse all properties and soft-permutations down to a single hard permutation.