[
https://issues.apache.org/jira/browse/TAP5-769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ben Gidley updated TAP5-769:
----------------------------
Attachment: 0004-TAP-769.patch
0003-TAP-769.patch
0002-TAP-769.patch
Here is a patch that implements a solution for this.
This changes the DocumentLinker and RenderSupportImpl so that scripts can be
'grouped' prior to assembly into a single script.
The default behaviour now is to create one 'group' from the
ClientInfrastructure stack and a second group from everything else.
This should address a good percentage of this problem raised in this issue.
Further enhancements that could be made
* Add method to render support to users to create their own groups
* Add a contribution point (similar to that provided by
http://tapestry.formos.com/projects/ioko-tapestry-commons/tapestry-javascript/)
could be provided to allow inclusion of stacks on certain pages
* A further contribution to allow replacement for a stack rolled up javascript
with a 'production' one e.g. from a CDN.
This patch does not address this issue of the length of the filename for the
'stack'. I can't see an easy, generic and cluster safe way to implement that
(except via the contribution mentioned above)
> 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
> Attachments: 0002-TAP-769.patch, 0003-TAP-769.patch,
> 0004-TAP-769.patch
>
>
> 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.
