Unfortunately, there won't be much changes from 3.4 to 3.5. The number of requests will increase with the more plugins you have installed. We are currently looking at better batching support for plugins as well in 4.0 though.

have there been any additional "batching" improvements made between versions 3.4.8 -> 3.5.5? we are still seeing large amounts of data that hang a page session the first time a user views it, and i am curious if futher work has been done.

Google Closure Compiler (http://code.google.com/closure/compiler/) is a free solution that can minify on the fly as well as doing batching of multiple JS files for free. It has been reported to achieve compression and additional speed optimization up to 40-50% over YUI Compressor when used in the Advanced Mode.

Yeah, we're in an enterprise environment with 5000 users and upgrading a wiki version takes months
since we have to regression test, fix look/feel stuff, fiddle with all the plugins, et cetera. The plugin
architecture makes it very hard to do an upgrade without user impact, so at this point as we're mostly through
the testing we will have to defer 3.1 to a later project.

Hey, you may want to consider OEMing something like Aptimize, which does those optimizations on the fly... Maybe
something to put into the enterprise/clustered version as an additional benny to take the sting off the huge
price tag increase. (Another reason we're having to wait on 3.1; we run clustered and when we go to 3.1 we
have to suddenly pony up many thousands of dollars, which makes us unhappy.)

Hi Ernest,

If you are upgrading, I would highly recommend to our latest 3.1 version to get our batching improvements.
Although we weren't able to reduce the number down to one css and js request, we have significantly reduced it from the 30 something requests in 3.0.

The main reason why we don't serve a single static css and js file is due to our support for plugins. Plugins also have css, js resources and they can be installed/uninstalled/upgraded.

Agnes

In fact, why are the static elements being served out through the Java engine at all?
For speed and capacity it's so much better to have them separate and be able to just serve them
via Apache, cache them in load balancers and proxy caches, etc. Putting them "in the app"
jacks many of the tools people use to optimize static content usually...

I was wondering about this. We were running an upgrade from 2.7.1 to 3.0.1 and pages seemed slower.
I looked into it and though the base page loads were faster, our old site was only pushing 3 .js files
and one .css, so everything was pretty fast. The exact same page in 3.0.1 pushes down 30 .js files, 17 CSSes,
and 26 CSS images, doubling the total page size and x4/ing the number of elements - resulting in a net performance
degradation of 2x on an internal network. The users beta testing our 3.0 upgrade have been complaining about performance and
now I know why.

Thanks Agnes. That looks much better than 3.0, which uses batching too, but most of the batched files contained 1-3 source files so the net effect was unnoticeable.

to bundle (almost) all JS and CSS files into one batch each

Means most of the Confluence bundled css/js resources are batched in something we call the super batch.
For example the dashboard (of a default confluence 3.1-beta install) looks like this:

<!-- css -->
<link type="text/css" rel="stylesheet" href="/confluence/s/1711/2/1/_/download/superbatch/css/batch.css" media="all">
<!--[if IE]>
<link type="text/css" rel="stylesheet" href="/confluence/s/1711/2/1/_/download/superbatch/css/batch.css?ieonly=true" media="all">
<![endif]-->
<link type="text/css" rel="stylesheet" href="/confluence/s/1711/2/1/_/download/superbatch/css/batch.css?media=print" media="print">
<link type="text/css" rel="stylesheet" href="/confluence/s/1711/2/1.0/_/download/resources/confluence.web.resources:aui-forms/confluence-forms.css" media="all">
<!--[if IE]>
<link type="text/css" rel="stylesheet" href="/confluence/s/1711/2/1.0/_/download/batch/confluence.web.resources:aui-forms/confluence.web.resources:aui-forms.css?ieonly=true" media="all">
<![endif]-->
<link type="text/css" rel="stylesheet" href="/confluence/s/1711/2/1.4-SNAPSHOT/_/download/batch/com.atlassian.confluence.plugins.dashboard-actions:dashboard-actions-resources/com.atlassian.confluence.plugins.dashboard-actions:dashboard-actions-resources.css" media="all">

<!-- javascript -->
<script type="text/javascript" src="/confluence/s/1711/2/1/_/download/superbatch/js/batch.js" ></script>
<script type="text/javascript" src="/confluence/s/1711/2/1.4-SNAPSHOT/_/download/batch/com.atlassian.confluence.plugins.dashboard-actions:dashboard-actions-resources/com.atlassian.confluence.plugins.dashboard-actions:dashboard-actions-resources.js" ></script>

Per, can you please clarify the following:

to bundle (almost) all JS and CSS files into one batch each

So each file is now represented as one resource batch? Or did you mean something else?