[ https://issues.apache.org/jira/browse/TAP5-769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12730532#action_12730532 ]
Fernando commented on TAP5-769: ------------------------------- I also would love it for someone to enhance that class to properly support external js files better. I have particular pages/components that depend on YUI js files, as well a facebook js files. But because they are included, means that none of my pages will use js combining.. I am very confident that someone could make the combiner smart enough to combine stretches of files.. so that a series of js files, so that the following will work! :) 1) internal.js 2) internal2.js 3) http://external.js 4) internal3.js 5) internal4.js 6) http://external2.js combined to: 1) combo.js?internal.js&internal2.js 2) http://external.js 3) combo.js?internal2.js&internal4.js 4) http://external2.js > JavaScript aggregation can be inefficient across multiple pages with > different JS requirements > ---------------------------------------------------------------------------------------------- > > Key: TAP5-769 > URL: https://issues.apache.org/jira/browse/TAP5-769 > Project: Tapestry 5 > Issue Type: Bug > Components: tapestry-core > Affects Versions: 5.1.0.5 > Reporter: Andy Blower > > I think Tapestry's JavaScript combination functionality is flawed. Each page > & component specifies which JS files it needs, which means that JS can be > split into functional units (good for development & maintenance) and only the > JS that's actually needed for that page is added for the client to download. > The consequence of this is that pages can have lots of JS files to download, > all of which has to be downloaded before the page is loaded/rendered now that > the script link tags are enforced to be back in the head section. Our search > results page has 34 JS files for instance. > Yahoo's YSlow tool recommends that these files are combined and minified, and > Tapestry includes functionality to do the first (minifying is on the TODO > list I believe) probably as a response to this recommendation which is good. > Unfortunately the implementation based on only having the JS files required > for a page means that the combined JS can easily be unique for most pages of > a site. This means that the client browser has to download & cache lots of > large JS multiple times (prototype, scriptaculous, tapestry etc) as part of > bigger combined files, which I think is probably worse than requesting them > separately, but only downloading stuff once and using that for all pages. > To solve this issue, Tapestry script combination could combine all of the > scripts needed for the site, and not just the unique set for each page. That > way only a single JS file needs to be downloaded and cached by the client > browser. I'm aware that this may not be that easy given the existing way only > scripts needed for the page are put on it, so an alternative solution that > may be easier to implement would be to combine scripts into two files for > each page. The first file would contain all of the commonly Tapestry provided > JS such as prototype.js, scriptaculous.js, effects.js, tapestry.js, etc in > one file that's the same for every page, and have the rest in a second file > that is unique for the page but that is not likely to include very large JS > files, just many little ones. > A second flaw that the combination has is that if an external JS file is > requested, script combination is aborted rather than just excluding the > external file from the combination. > One other thing that surprised me about Tapestry's script combination is the > length of the generated filename, for example it's 919 characters long for a > page on our site. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.