Tapestry
  1. Tapestry
  2. TAPESTRY-2159

YSlow Recommendation: Version bundled javascript and use far-future expires header

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 5.0.10
    • Fix Version/s: 5.0.12
    • Component/s: None
    • Labels:
      None
    • Environment:
      Any

      Description

      Jesse Kuhnert has already implemented this in T4. (Jira issue TAPESTRY-2122.)

      Prevents client side errors that occur if user doesn't flush browser's cache between Tapestry upgrades. (And javascript has changed.)

      See: http://developer.yahoo.com/performance/rules.html#expires

      This really applies to classpath resources. Context resources can also be versioned and (via some kind of servlet container ju-ju) hack the expires header ... but that's an application development and deployment issue seperate from Tapestry.

      Part of this requires that the Tapestry release number be available and incorporated into the mapped path for the classpath asset. See TAPESTRY-2231.

        Activity

        Mark Thomas made changes -
        Workflow Default workflow, editable Closed status [ 12568401 ] jira [ 12591457 ]
        Mark Thomas made changes -
        Workflow jira [ 12423536 ] Default workflow, editable Closed status [ 12568401 ]
        Howard M. Lewis Ship made changes -
        Fix Version/s 5.0.12 [ 12313048 ]
        Resolution Fixed [ 1 ]
        Assignee Howard M. Lewis Ship [ hlship ]
        Fix Version/s 5.1 [ 12312964 ]
        Status Open [ 1 ] Closed [ 6 ]
        Hide
        Howard M. Lewis Ship added a comment -

        This was bundled with some other changes.

        Show
        Howard M. Lewis Ship added a comment - This was bundled with some other changes.
        Hide
        Howard M. Lewis Ship added a comment -

        I was resistent to this idea in the beginning since it makes URLs a bit longer, but I'm fully behind it now.

        The question is, do we supply a real or "extended" expires date for the files in the folder? Probably a fake one, and we need to document that any files packaged inside a JAR (such as a third party library) should also require a version number in the path.

        Show
        Howard M. Lewis Ship added a comment - I was resistent to this idea in the beginning since it makes URLs a bit longer, but I'm fully behind it now. The question is, do we supply a real or "extended" expires date for the files in the folder? Probably a fake one, and we need to document that any files packaged inside a JAR (such as a third party library) should also require a version number in the path.
        Howard M. Lewis Ship made changes -
        Description Jesse Kuhnert has already implemented this in T4. (Jira issue TAPESTRY-2122.)

        Prevents client side errors that occur if user doesn't flush browser's cache between Tapestry upgrades. (And javascript has changed.)
        Jesse Kuhnert has already implemented this in T4. (Jira issue TAPESTRY-2122.)

        Prevents client side errors that occur if user doesn't flush browser's cache between Tapestry upgrades. (And javascript has changed.)

        See: http://developer.yahoo.com/performance/rules.html#expires

        This really applies to classpath resources. Context resources can also be versioned and (via some kind of servlet container ju-ju) hack the expires header ... but that's an application development and deployment issue seperate from Tapestry.

        Part of this requires that the Tapestry release number be available and incorporated into the mapped path for the classpath asset. See TAPESTRY-2231.
        Summary Version bundled javascript YSlow Recommendation: Version bundled javascript and use far-future expires header
        Hide
        Filip S. Adamsen added a comment - - edited

        Davor's approach of adding the file's timestamp to the URL seems like it would work. And it's, as he points out, not invasive towards the developer.

        So something like a ?ts=20080226124800 at the end if the file was last modified on February 26th, 2008 at 1:48:00 PM.

        The same would be useful for CSS files, by the way.

        Show
        Filip S. Adamsen added a comment - - edited Davor's approach of adding the file's timestamp to the URL seems like it would work. And it's, as he points out, not invasive towards the developer. So something like a ?ts=20080226124800 at the end if the file was last modified on February 26th, 2008 at 1:48:00 PM. The same would be useful for CSS files, by the way.
        Hide
        Ville Virtanen added a comment -

        Have seen same behavior, the js should be updated by the browser but it isn't. I don't know how Jesse solved this issue, but sometimes when browsers have old version in local cache it can cause all sorts of problems. And, after that the support center gets angry calls, which in turn increases negative attitude towards the software amongst other bad things....

        The different-url-per-version approach is the only that works for sure afaik.

        I would estimate that the priority of this is quite low, but should be kept in the list. (Just my opinion, you may disagree )

        Show
        Ville Virtanen added a comment - Have seen same behavior, the js should be updated by the browser but it isn't. I don't know how Jesse solved this issue, but sometimes when browsers have old version in local cache it can cause all sorts of problems. And, after that the support center gets angry calls, which in turn increases negative attitude towards the software amongst other bad things.... The different-url-per-version approach is the only that works for sure afaik. I would estimate that the priority of this is quite low, but should be kept in the list. (Just my opinion, you may disagree )
        Hide
        Davor Hrg added a comment -

        Unfortunately, it is the only way make browser reload files.

        Firefox for example will stop asking server(If-Modified-Since) for changes if a .js file
        has not changed for a while.

        I've experienced this on large project on daily basis,
        so I've started to incorporate file timestamp into url
        to make sure it is reloaded on every change.

        it is even worse for .css files I have to clear cache manually often to get fresh css.

        adding timestamp to js url and css url is not invasive towards developer
        and is guaranteed to refresh every time

        Show
        Davor Hrg added a comment - Unfortunately, it is the only way make browser reload files. Firefox for example will stop asking server(If-Modified-Since) for changes if a .js file has not changed for a while. I've experienced this on large project on daily basis, so I've started to incorporate file timestamp into url to make sure it is reloaded on every change. it is even worse for .css files I have to clear cache manually often to get fresh css. adding timestamp to js url and css url is not invasive towards developer and is guaranteed to refresh every time
        Howard M. Lewis Ship made changes -
        Field Original Value New Value
        Fix Version/s 5.0.11 [ 12312968 ]
        Fix Version/s 5.1 [ 12312964 ]
        Hide
        Howard M. Lewis Ship added a comment -

        How necessary is this? Tapestry does the correct thing w.r.t. reporting time stamps, a new version of tapestry-core.jar will show updates to any of the JavaScript files

        Show
        Howard M. Lewis Ship added a comment - How necessary is this? Tapestry does the correct thing w.r.t. reporting time stamps, a new version of tapestry-core.jar will show updates to any of the JavaScript files
        Ville Virtanen created issue -

          People

          • Assignee:
            Howard M. Lewis Ship
            Reporter:
            Ville Virtanen
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development