Combining JavaScript and CSS files for more performance

All,

See our latest blog entry on this topic:

http://www.orbeon.com/blog/2007/03/12/combining-javascript-and-css-files-for-more-performance/

This feature is available in nightly builds.

-Erik

--
Orbeon Forms - Web Forms for the Enterprise Done the Right Way
http://www.orbeon.com/



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Erik,

this is great news. OPS is by far my preferred platform of choice
because of its speed of development, which is the most important
criteria for me (Time is my most priced asset).

But the biggest concern I have so far, is the page loading speed and
scalability (i.e. cost/user), which seems to have been secondary to
adding features and XForms compliance. This is of course very
understandable - You need to have the features in before you can
optimize them, and 3.5 was a milestone in this regard.

Which brings me back to why I think this is great news - Looks like
the OPS team have now made lots of important optimizations to the
framework. Indeed, several ops-users members have also been posting
important performance statistics and suggested relevant improvements -
this must be one of the better development communities out there :-)

Thank you, OPS team, and keep up the good work!

Sincerely,
Henrik Pettersen

On 3/12/07, Erik Bruchez <[hidden email],

--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Hi Eric,

thanks. Interesting post.

At one time ;-) you could configure your browser to say how many  
connections you would allow to open concurrently - from which one  
could infer that breaking a site up into multiple files would produce  
a faster download.

There are perhaps still a couple of points to bear in mind as to  
whether this is a universally applicable solution (which is  
presumably why you have made it optional)

If you are serving the site through Apache instead of directly from  
tomcat, and have broken out the ops-resources-*.jars, then this isn't  
going to work - have you been able to do any testing to demonstrate  
that one method is more effective than the other (that is, apache and  
static files relative to tomcat and dynamically combined files)?

It would seem this will be most beneficial when each of the form  
pages on a site all use the same subset of css/js files (or a visitor  
typically only visits one forms page) - otherwise you are trading off  
the benefits of the browser caching the css/js files against the  
faster downloading of different composite css/js files being  
downloaded for different form pages (hope I've expressed that clearly  
enough).

If there is truly a major benefit from this combining, we will have  
to reconsider how we build our own css files - for convenience in  
maintaining multiple sites, we have multiple css files (various  
common and site specific files) - perhaps we will need to add a step  
to combine them for production use.

Thanks again
best regards
Colin


On Mar 12, 2007, at 10:31 AM, Erik Bruchez wrote:



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Henrik,

Thanks for the positive comments! XForms performance is one of our two
main priorities for this year. But as already said in previous posts,
there is still a lot that can be done!

-Erik

Henrik Pettersen wrote:
--
Orbeon Forms - Web Forms for the Enterprise Done the Right Way
http://www.orbeon.com/



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Colin O'Brien wrote:
> Hi Eric,
>
> thanks. Interesting post.
>
> At one time ;-) you could configure your browser to say how many
> connections you would allow to open concurrently - from which one could
> infer that breaking a site up into multiple files would produce a faster
> download.

Yes, in many cases downloads will be faster with more connections, but
this doesn't work for JavaScript files which are loaded sequentially
(notwithstanding the funny "defer" option in IE) - it will only work for
CSS, images, and other resources.

Also, you cannot realistically tell users to change that setting. But a
related trick consists in using several distinct domain names to load
resources - for example, load your images from one or two secondary
domain names. This way, you get 2 browser connections for each domain
and you are likely to get better performance.

> There are perhaps still a couple of points to bear in mind as to whether
> this is a universally applicable solution (which is presumably why you
> have made it optional)
>
> If you are serving the site through Apache instead of directly from
> tomcat, and have broken out the ops-resources-*.jars, then this isn't
> going to work - have you been able to do any testing to demonstrate that
> one method is more effective than the other (that is, apache and static
> files relative to tomcat and dynamically combined files)?

It will work if you use the option in properties.xml to cache these
files on disk. There is a little but which is that the files should be
produce in the cache when the page is loading, but we hope to fix this soon:

http://forge.objectweb.org/tracker/index.php?func=detail&aid=306782&group_id=168&atid=350207

> It would seem this will be most beneficial when each of the form pages
> on a site all use the same subset of css/js files (or a visitor
> typically only visits one forms page) - otherwise you are trading off
> the benefits of the browser caching the css/js files against the faster
> downloading of different composite css/js files being downloaded for
> different form pages (hope I've expressed that clearly enough).

That's right. One additional option in this mode would consist in always
producing JS and CSS files with all the features, or with a certain
number of baseline features used by your application. This way you can
get a good trade-off. I entered an RFE to track this:

http://forge.objectweb.org/tracker/index.php?func=detail&aid=306783&group_id=168&atid=350207

> If there is truly a major benefit from this combining, we will have to
> reconsider how we build our own css files - for convenience in
> maintaining multiple sites, we have multiple css files (various common
> and site specific files) - perhaps we will need to add a step to combine
> them for production use.

Oh yes, there is a benefit in combining files. But as you correctly
point out, with the current implementation in Orbeon Forms, this benefit
can be offset if all your pages use different combinations of CSS or JS
files, and if you are in an environment where users are likely to have
these CSS and JS files in cache anyway.

At this point I don't think there is a one-size-fits-all solution.

-Erik

--
Orbeon Forms - Web Forms for the Enterprise Done the Right Way
http://www.orbeon.com/



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws