[
https://issues.apache.org/jira/browse/TAP5-769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12729711#action_12729711
]
Andy Blower commented on TAP5-769:
----------------------------------
That sounds like a good solution to me (hardly surprising since I suggested it
as an alternative solution above) and extending base stack for additional files
sounds very good.
What data is encoded into the filename? What's it used for?
> 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.
