4 Replies Latest reply on Feb 7, 2007 12:20 PM by Chris Lowe

    Caching pages in browser

    jk;l jkl; Expert

      I seem to be getting conflicting info from different resources...people say to make sure browsers don't cache your pages, while page caching is a huge part of increasing performance that others thoroughly recommend

      Should you set response headers or meta tags for caching pages to off or on? Does this apply to every single page in your application or does it depend on certain criteria? (I read that for Seam's MVC style with redirects to work browsers shouldn't cache your pages...) Why?

      Are there certain criteria (e.g. don't cache any page with a form, or an s:link, or something like that) that make a good rule of thumb for which pages can be cached and which shouldn't?

      (I imagine it's still okay to cache purely static pages, but in a Seam application where a "static" page might still be composed of multiple templates, that'll never apply...)

        • 1. Re: Caching pages in browser
          Gavin King Master

          Perhaps by "page caching" they mean stuff like s:cache

          • 2. Re: Caching pages in browser
            jk;l jkl; Expert

            I'm not quite sure what you're saying ... so we should not cache pages in browser but can still use things like s:cache?

            How does s:cache change anything...doesn't the page in the cache still need to be re-executed when accessed? And if not (i.e. it's already in HTML), then how's it any better than browser caching?

            Is it true that browser caching with Seam is never a good combo?

            • 3. Re: Caching pages in browser
              adsf adsf Newbie

              With s:cache you cache part of pages serverside - i.e. a dynamic part of a page that changes from time to time but is expensive to compute.

              With meta tags in html headers you cache whole pages clientside - you can tell the client to ask everytime if theres a newer version available, to use the current page for 24 hours, ... (have a look at the html spec)!

              Those 2 have nothing to do with each other. Simply use client side caching if your page hasn't changed and the client has the current version - this saves you cpu time & bandwith and cost just a bit of thinking ;)

              • 4. Re: Caching pages in browser
                Chris Lowe Apprentice

                I assume you mean browser page caching. I came across this problem with an application that required a login to see customer transaction data. Essentially you could login, view financial data and then log out, after which hitting the back button would show browser cached pages from the previous session. Obviously this caching could potentially reveal sensitive data to a user other than the original customer.

                Adding the following meta tags to all my pages (regardless of whether they contained forms, s:link, etc) prevented the browser from caching the pages:

                <meta http-equiv="Expires" content="-1" />
                 <meta http-equiv="Cache-Control" content="no-cache" />
                 <meta http-equiv="Pragma" content="no-cache" />

                This worked well and our application functioned normally after retro fitting the meta tags, however it did cause a problem for our client which may or may not be an issue for you. Our application made heavy use of the commandLink for navigation. This mechanism requires a HTTP post when the link is selected. The side effect of this is that whenever the user selects the browsers' back button, after adding the meta tags the browser has to request a fresh page from the server. Because the original page was generated as the result of a HTTP post, this causes the browser to issue a "Resend Posted information" warning (or something like that) every time the back button is used. This is ugly and is not particularly intuitive and was unacceptable to our client (understandably).

                We got around this by replacing all commandLinks that were used purely for navigational purposes with s:link. s:link generates a regular HTML link that allows navigation using HTTP get which solves the browser message problem. One caveat to this solution is that if any navigation requires values from other components on the page or those values are to be saved for later you still have to use commandLink to submit the form data.

                Regarding performance: in our case (in fact most cases), security requirements superseded performance requirements, so we had no choice but to turn off browser page caching. That said, you can still get good performance by adopting one or more of the following:

                1. As mentioned in previous posts, if a page is particularly expensive to render then caching the expensive page fragments using s:cache is a simple and very effective strategy (e.g. a table bound to a datamodel that requires a complex database query).
                2. Introducing appropriate caching policies for external page resources (css, js, images etc) can help to reduce unnecessary server requests and save bandwidth.
                3. If your generated pages are large and your users? connections are slow you could add a compression filter to your application. I've used the following compression filter successfully in a Seam application which will cut HTML page sizes by 80% over the wire:


                Hope this helps,