Re: Far Future Expiration Headers of Assets
Howard, just a thought. It appears as if the files with the 60 sec cache are mostly Tapestry core files. Since we are unable to put a checksum in the URI, would it be possible to put a version in the filename? Example, bootstrap3.xx.css etc. I would think we could then use a far future expiration on the modules, it would also make it easy for us to keep track of what library version we are running too. The downside might just be the library maintenance during upgrades. I'm only pushing on this topic do to the fact a websites speed is one of the few known ranking factors of Google's algorithm. A website that scores high for speed will move up the page rank as Google believes the users will have a much better experience. Currently Google's scoring tool is scoring me in the low 70's for mobile which is primarily do to browser caching and render blocking css and js which we spoke about this before for future releases. I also think if we get this figured out it would help to reduce some of the hosting cost associated with the cloud. On Tue, Jan 27, 2015 at 3:10 PM, George Christman wrote: > In production mode Google / yslow have both been complaining about > assets missing expiration dates as well as the modules being too > short. You can see an example here. > > https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fwww.cardaddy.com%2F > > Now do to my lack of Tapestry knowledge on the proper way to handle > expiration for asset headers, I ended up setting the expiration date > for 1 year within apache httpd with the assumption the checksum would > change. > > So as of right now it just appears google is complaining about the > modules short expiration date "90", I'm not familiar with etag, but > would that help to resolve my issues. > > On Tue, Jan 27, 2015 at 1:56 PM, Howard Lewis Ship wrote: >> Further, for both modules and normal assets, there's etag support ... so >> most requsts for a module get a 304 and the browser can use its local cache. >> >> On Tue, Jan 27, 2015 at 10:55 AM, Howard Lewis Ship >> wrote: >> >>> Modules can't have a far-future expires header, because we can't put a >>> fingerprint (asset checksum) into a module URI. >>> >>> All other assets have a checksum in the URI and get the far future expires >>> header. >>> >>> The handling of this is different between development mode and production >>> mode. Short or no expires headers in development. >>> >>> The naming may be a bit wonky, but the Javadoc should explain the >>> reasoning. Basically, this is the cache control header for when the >>> OMIT_EXPIRATION flag is passed to the relevant service. When the flag is >>> not passed, we get the far-future expires header. >>> >>> >>> On Tue, Jan 27, 2015 at 6:41 AM, George Christman >> > wrote: >>> So I figured out how to change the 60sec, configuration.add(SymbolConstants.OMIT_EXPIRATION_CACHE_CONTROL_HEADER, "max-age= 2419200,must-revalidate"); OMIT_EXPIRATION is a bit misleading as I thought it meant to remove the expiration dates. Now I just need to figure out how to ad expiration dates to the other core css style sheets (no expires) http://localhost:8080/etss/assets/meta/z64038ad2/tapestry5/tapestry.css (no expires) http://localhost:8080/etss/assets/meta/ze8a5779c/tapestry5/exception-frame.css (no expires) http://localhost:8080/etss/assets/meta/zceffa0e4/tapestry5/tapestry-console.css (no expires) http://localhost:8080/etss/assets/meta/z57b9a823/tapestry5/tree.css Any thoughts? On Tue, Jan 27, 2015 at 8:48 AM, George Christman wrote: > Hi Guys, I'm back on this topic again. Does anybody know how to bump > up the default 60 second time to something further in the future? > > On Mon, Dec 22, 2014 at 4:01 PM, Harry Zhou wrote: >> Hi George, >> >> It does sound like the same issue. >> >> Regarding the "leverage browser caching" warning, I did not "solve" >> the problem -- it appears to be a false alarm by Chrome PageSpeed: (i) >> if one keeps the Chrome developer panel up and click around in a >> Tapestry webapp, one should see that the assets are indeed cached >> after the initial round of full requests ("200 from cache" will be >> shown for cached assets). No requests for these assets will actually >> be sent to server unless the user clicks the refresh button or run an >> audit with page reload from Chrome PageSpeed. The latter case is >> where PageSpeed will complain about the assets, because although it >> sees the 10-year-in-the-future headers in the responses, which Chrome >> does honor and will cache accordingly, PageSpeed will, however, want >> to see a "Cache-Control" header in responses. It is likely a >> non-issue because during ordinary browsing client caching is >> leveraged. >> >> The 60 seconds for modules
Re: Far Future Expiration Headers of Assets
In production mode Google / yslow have both been complaining about assets missing expiration dates as well as the modules being too short. You can see an example here. https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fwww.cardaddy.com%2F Now do to my lack of Tapestry knowledge on the proper way to handle expiration for asset headers, I ended up setting the expiration date for 1 year within apache httpd with the assumption the checksum would change. So as of right now it just appears google is complaining about the modules short expiration date "90", I'm not familiar with etag, but would that help to resolve my issues. On Tue, Jan 27, 2015 at 1:56 PM, Howard Lewis Ship wrote: > Further, for both modules and normal assets, there's etag support ... so > most requsts for a module get a 304 and the browser can use its local cache. > > On Tue, Jan 27, 2015 at 10:55 AM, Howard Lewis Ship > wrote: > >> Modules can't have a far-future expires header, because we can't put a >> fingerprint (asset checksum) into a module URI. >> >> All other assets have a checksum in the URI and get the far future expires >> header. >> >> The handling of this is different between development mode and production >> mode. Short or no expires headers in development. >> >> The naming may be a bit wonky, but the Javadoc should explain the >> reasoning. Basically, this is the cache control header for when the >> OMIT_EXPIRATION flag is passed to the relevant service. When the flag is >> not passed, we get the far-future expires header. >> >> >> On Tue, Jan 27, 2015 at 6:41 AM, George Christman > > wrote: >> >>> So I figured out how to change the 60sec, >>> configuration.add(SymbolConstants.OMIT_EXPIRATION_CACHE_CONTROL_HEADER, >>> "max-age= >>> 2419200,must-revalidate"); >>> >>> OMIT_EXPIRATION is a bit misleading as I thought it meant to remove >>> the expiration dates. >>> >>> Now I just need to figure out how to ad expiration dates to the other >>> core css style sheets >>> >>> (no expires) >>> http://localhost:8080/etss/assets/meta/z64038ad2/tapestry5/tapestry.css >>> (no expires) >>> http://localhost:8080/etss/assets/meta/ze8a5779c/tapestry5/exception-frame.css >>> (no expires) >>> http://localhost:8080/etss/assets/meta/zceffa0e4/tapestry5/tapestry-console.css >>> (no expires) >>> http://localhost:8080/etss/assets/meta/z57b9a823/tapestry5/tree.css >>> >>> Any thoughts? >>> >>> On Tue, Jan 27, 2015 at 8:48 AM, George Christman >>> wrote: >>> > Hi Guys, I'm back on this topic again. Does anybody know how to bump >>> > up the default 60 second time to something further in the future? >>> > >>> > On Mon, Dec 22, 2014 at 4:01 PM, Harry Zhou >>> wrote: >>> >> Hi George, >>> >> >>> >> It does sound like the same issue. >>> >> >>> >> Regarding the "leverage browser caching" warning, I did not "solve" >>> >> the problem -- it appears to be a false alarm by Chrome PageSpeed: (i) >>> >> if one keeps the Chrome developer panel up and click around in a >>> >> Tapestry webapp, one should see that the assets are indeed cached >>> >> after the initial round of full requests ("200 from cache" will be >>> >> shown for cached assets). No requests for these assets will actually >>> >> be sent to server unless the user clicks the refresh button or run an >>> >> audit with page reload from Chrome PageSpeed. The latter case is >>> >> where PageSpeed will complain about the assets, because although it >>> >> sees the 10-year-in-the-future headers in the responses, which Chrome >>> >> does honor and will cache accordingly, PageSpeed will, however, want >>> >> to see a "Cache-Control" header in responses. It is likely a >>> >> non-issue because during ordinary browsing client caching is >>> >> leveraged. >>> >> >>> >> The 60 seconds for modules are discussed here: >>> >> http://tapestry.apache.org/javascript-modules.html >>> >> >>> >> "By default, Tapestry sets a max age of 60 (seconds) on modules, so >>> >> you won't see module requests on every page load. This is configurable >>> >> and you may want a much higher value in production. If you are rapidly >>> >> iterating on the source of a module, you may need to force the browser >>> >> to reload after clearing local cache. Chrome has an option to disable >>> >> the client-side cache when its developer tools are open." >>> >> >>> >> The page lists solutions as well. >>> >> >>> >> Harry >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> On Mon, Dec 22, 2014 at 12:44 PM, George Christman >>> >> wrote: >>> >>> I'm having this same issue which I posted up a couple weeks ago >>> >>> without any response. >>> >>> >>> http://apache-tapestry-mailing-list-archives.1045711.n5.nabble.com/5-4-asset-expire-header-td5729478.html >>> >>> >>> >>> So my first question is what did you do to resolve the issue? >>> >>> >>> >>> Secondly I am running in production mode, so I'm not sure what the >>> >>> cause could be. I'll have to check the cdn, but this is what google is >>> >>> complaini
Re: Far Future Expiration Headers of Assets
Further, for both modules and normal assets, there's etag support ... so most requsts for a module get a 304 and the browser can use its local cache. On Tue, Jan 27, 2015 at 10:55 AM, Howard Lewis Ship wrote: > Modules can't have a far-future expires header, because we can't put a > fingerprint (asset checksum) into a module URI. > > All other assets have a checksum in the URI and get the far future expires > header. > > The handling of this is different between development mode and production > mode. Short or no expires headers in development. > > The naming may be a bit wonky, but the Javadoc should explain the > reasoning. Basically, this is the cache control header for when the > OMIT_EXPIRATION flag is passed to the relevant service. When the flag is > not passed, we get the far-future expires header. > > > On Tue, Jan 27, 2015 at 6:41 AM, George Christman > wrote: > >> So I figured out how to change the 60sec, >> configuration.add(SymbolConstants.OMIT_EXPIRATION_CACHE_CONTROL_HEADER, >> "max-age= >> 2419200,must-revalidate"); >> >> OMIT_EXPIRATION is a bit misleading as I thought it meant to remove >> the expiration dates. >> >> Now I just need to figure out how to ad expiration dates to the other >> core css style sheets >> >> (no expires) >> http://localhost:8080/etss/assets/meta/z64038ad2/tapestry5/tapestry.css >> (no expires) >> http://localhost:8080/etss/assets/meta/ze8a5779c/tapestry5/exception-frame.css >> (no expires) >> http://localhost:8080/etss/assets/meta/zceffa0e4/tapestry5/tapestry-console.css >> (no expires) >> http://localhost:8080/etss/assets/meta/z57b9a823/tapestry5/tree.css >> >> Any thoughts? >> >> On Tue, Jan 27, 2015 at 8:48 AM, George Christman >> wrote: >> > Hi Guys, I'm back on this topic again. Does anybody know how to bump >> > up the default 60 second time to something further in the future? >> > >> > On Mon, Dec 22, 2014 at 4:01 PM, Harry Zhou >> wrote: >> >> Hi George, >> >> >> >> It does sound like the same issue. >> >> >> >> Regarding the "leverage browser caching" warning, I did not "solve" >> >> the problem -- it appears to be a false alarm by Chrome PageSpeed: (i) >> >> if one keeps the Chrome developer panel up and click around in a >> >> Tapestry webapp, one should see that the assets are indeed cached >> >> after the initial round of full requests ("200 from cache" will be >> >> shown for cached assets). No requests for these assets will actually >> >> be sent to server unless the user clicks the refresh button or run an >> >> audit with page reload from Chrome PageSpeed. The latter case is >> >> where PageSpeed will complain about the assets, because although it >> >> sees the 10-year-in-the-future headers in the responses, which Chrome >> >> does honor and will cache accordingly, PageSpeed will, however, want >> >> to see a "Cache-Control" header in responses. It is likely a >> >> non-issue because during ordinary browsing client caching is >> >> leveraged. >> >> >> >> The 60 seconds for modules are discussed here: >> >> http://tapestry.apache.org/javascript-modules.html >> >> >> >> "By default, Tapestry sets a max age of 60 (seconds) on modules, so >> >> you won't see module requests on every page load. This is configurable >> >> and you may want a much higher value in production. If you are rapidly >> >> iterating on the source of a module, you may need to force the browser >> >> to reload after clearing local cache. Chrome has an option to disable >> >> the client-side cache when its developer tools are open." >> >> >> >> The page lists solutions as well. >> >> >> >> Harry >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Mon, Dec 22, 2014 at 12:44 PM, George Christman >> >> wrote: >> >>> I'm having this same issue which I posted up a couple weeks ago >> >>> without any response. >> >>> >> http://apache-tapestry-mailing-list-archives.1045711.n5.nabble.com/5-4-asset-expire-header-td5729478.html >> >>> >> >>> So my first question is what did you do to resolve the issue? >> >>> >> >>> Secondly I am running in production mode, so I'm not sure what the >> >>> cause could be. I'll have to check the cdn, but this is what google is >> >>> complaining about. The images are being called from a sprite map in >> >>> css where the context binding prefix can't be used. >> >>> >> >>> Leverage browser caching >> >>> >> >>> Setting an expiry date or a maximum age in the HTTP headers for static >> >>> resources instructs the browser to load previously downloaded >> >>> resources from local disk rather than over the network. >> >>> Leverage browser caching for the following cacheable resources: >> >>> >> >>> https://d39chrhoz7kxwa.cloudfront.net/1f1a90de-ed5_300.jpg >> (expiration >> >>> not specified) >> >>> https://d39chrhoz7kxwa.cloudfront.net/29fb2b34-55d_300.jpg >> (expiration >> >>> not specified) >> >>> https://d39chrhoz7kxwa.cloudfront.net/3902d130-3b1_300.jpg >> (expiration >> >>> not specified) >> >>> https://d39chrhoz7kxwa.cloudfront.net/75713aa2-bec_30
Re: Far Future Expiration Headers of Assets
Modules can't have a far-future expires header, because we can't put a fingerprint (asset checksum) into a module URI. All other assets have a checksum in the URI and get the far future expires header. The handling of this is different between development mode and production mode. Short or no expires headers in development. The naming may be a bit wonky, but the Javadoc should explain the reasoning. Basically, this is the cache control header for when the OMIT_EXPIRATION flag is passed to the relevant service. When the flag is not passed, we get the far-future expires header. On Tue, Jan 27, 2015 at 6:41 AM, George Christman wrote: > So I figured out how to change the 60sec, > configuration.add(SymbolConstants.OMIT_EXPIRATION_CACHE_CONTROL_HEADER, > "max-age= > 2419200,must-revalidate"); > > OMIT_EXPIRATION is a bit misleading as I thought it meant to remove > the expiration dates. > > Now I just need to figure out how to ad expiration dates to the other > core css style sheets > > (no expires) > http://localhost:8080/etss/assets/meta/z64038ad2/tapestry5/tapestry.css > (no expires) > http://localhost:8080/etss/assets/meta/ze8a5779c/tapestry5/exception-frame.css > (no expires) > http://localhost:8080/etss/assets/meta/zceffa0e4/tapestry5/tapestry-console.css > (no expires) > http://localhost:8080/etss/assets/meta/z57b9a823/tapestry5/tree.css > > Any thoughts? > > On Tue, Jan 27, 2015 at 8:48 AM, George Christman > wrote: > > Hi Guys, I'm back on this topic again. Does anybody know how to bump > > up the default 60 second time to something further in the future? > > > > On Mon, Dec 22, 2014 at 4:01 PM, Harry Zhou > wrote: > >> Hi George, > >> > >> It does sound like the same issue. > >> > >> Regarding the "leverage browser caching" warning, I did not "solve" > >> the problem -- it appears to be a false alarm by Chrome PageSpeed: (i) > >> if one keeps the Chrome developer panel up and click around in a > >> Tapestry webapp, one should see that the assets are indeed cached > >> after the initial round of full requests ("200 from cache" will be > >> shown for cached assets). No requests for these assets will actually > >> be sent to server unless the user clicks the refresh button or run an > >> audit with page reload from Chrome PageSpeed. The latter case is > >> where PageSpeed will complain about the assets, because although it > >> sees the 10-year-in-the-future headers in the responses, which Chrome > >> does honor and will cache accordingly, PageSpeed will, however, want > >> to see a "Cache-Control" header in responses. It is likely a > >> non-issue because during ordinary browsing client caching is > >> leveraged. > >> > >> The 60 seconds for modules are discussed here: > >> http://tapestry.apache.org/javascript-modules.html > >> > >> "By default, Tapestry sets a max age of 60 (seconds) on modules, so > >> you won't see module requests on every page load. This is configurable > >> and you may want a much higher value in production. If you are rapidly > >> iterating on the source of a module, you may need to force the browser > >> to reload after clearing local cache. Chrome has an option to disable > >> the client-side cache when its developer tools are open." > >> > >> The page lists solutions as well. > >> > >> Harry > >> > >> > >> > >> > >> > >> > >> > >> On Mon, Dec 22, 2014 at 12:44 PM, George Christman > >> wrote: > >>> I'm having this same issue which I posted up a couple weeks ago > >>> without any response. > >>> > http://apache-tapestry-mailing-list-archives.1045711.n5.nabble.com/5-4-asset-expire-header-td5729478.html > >>> > >>> So my first question is what did you do to resolve the issue? > >>> > >>> Secondly I am running in production mode, so I'm not sure what the > >>> cause could be. I'll have to check the cdn, but this is what google is > >>> complaining about. The images are being called from a sprite map in > >>> css where the context binding prefix can't be used. > >>> > >>> Leverage browser caching > >>> > >>> Setting an expiry date or a maximum age in the HTTP headers for static > >>> resources instructs the browser to load previously downloaded > >>> resources from local disk rather than over the network. > >>> Leverage browser caching for the following cacheable resources: > >>> > >>> https://d39chrhoz7kxwa.cloudfront.net/1f1a90de-ed5_300.jpg (expiration > >>> not specified) > >>> https://d39chrhoz7kxwa.cloudfront.net/29fb2b34-55d_300.jpg (expiration > >>> not specified) > >>> https://d39chrhoz7kxwa.cloudfront.net/3902d130-3b1_300.jpg (expiration > >>> not specified) > >>> https://d39chrhoz7kxwa.cloudfront.net/75713aa2-bec_300.jpg (expiration > >>> not specified) > >>> https://www.cardaddy.com/modules.gz/autocomplete-custom.js (60 > seconds) > >>> https://www.cardaddy.com/modules.gz/bootstrap/collapse.js (60 seconds) > >>> https://www.cardaddy.com/modules.gz/bootstrap/dropdown.js (60 seconds) > >>> https://www.cardaddy.com/modules.gz/bootstrap/transition.js (60 > se
Re: Far Future Expiration Headers of Assets
So I figured out how to change the 60sec, configuration.add(SymbolConstants.OMIT_EXPIRATION_CACHE_CONTROL_HEADER, "max-age= 2419200,must-revalidate"); OMIT_EXPIRATION is a bit misleading as I thought it meant to remove the expiration dates. Now I just need to figure out how to ad expiration dates to the other core css style sheets (no expires) http://localhost:8080/etss/assets/meta/z64038ad2/tapestry5/tapestry.css (no expires) http://localhost:8080/etss/assets/meta/ze8a5779c/tapestry5/exception-frame.css (no expires) http://localhost:8080/etss/assets/meta/zceffa0e4/tapestry5/tapestry-console.css (no expires) http://localhost:8080/etss/assets/meta/z57b9a823/tapestry5/tree.css Any thoughts? On Tue, Jan 27, 2015 at 8:48 AM, George Christman wrote: > Hi Guys, I'm back on this topic again. Does anybody know how to bump > up the default 60 second time to something further in the future? > > On Mon, Dec 22, 2014 at 4:01 PM, Harry Zhou wrote: >> Hi George, >> >> It does sound like the same issue. >> >> Regarding the "leverage browser caching" warning, I did not "solve" >> the problem -- it appears to be a false alarm by Chrome PageSpeed: (i) >> if one keeps the Chrome developer panel up and click around in a >> Tapestry webapp, one should see that the assets are indeed cached >> after the initial round of full requests ("200 from cache" will be >> shown for cached assets). No requests for these assets will actually >> be sent to server unless the user clicks the refresh button or run an >> audit with page reload from Chrome PageSpeed. The latter case is >> where PageSpeed will complain about the assets, because although it >> sees the 10-year-in-the-future headers in the responses, which Chrome >> does honor and will cache accordingly, PageSpeed will, however, want >> to see a "Cache-Control" header in responses. It is likely a >> non-issue because during ordinary browsing client caching is >> leveraged. >> >> The 60 seconds for modules are discussed here: >> http://tapestry.apache.org/javascript-modules.html >> >> "By default, Tapestry sets a max age of 60 (seconds) on modules, so >> you won't see module requests on every page load. This is configurable >> and you may want a much higher value in production. If you are rapidly >> iterating on the source of a module, you may need to force the browser >> to reload after clearing local cache. Chrome has an option to disable >> the client-side cache when its developer tools are open." >> >> The page lists solutions as well. >> >> Harry >> >> >> >> >> >> >> >> On Mon, Dec 22, 2014 at 12:44 PM, George Christman >> wrote: >>> I'm having this same issue which I posted up a couple weeks ago >>> without any response. >>> http://apache-tapestry-mailing-list-archives.1045711.n5.nabble.com/5-4-asset-expire-header-td5729478.html >>> >>> So my first question is what did you do to resolve the issue? >>> >>> Secondly I am running in production mode, so I'm not sure what the >>> cause could be. I'll have to check the cdn, but this is what google is >>> complaining about. The images are being called from a sprite map in >>> css where the context binding prefix can't be used. >>> >>> Leverage browser caching >>> >>> Setting an expiry date or a maximum age in the HTTP headers for static >>> resources instructs the browser to load previously downloaded >>> resources from local disk rather than over the network. >>> Leverage browser caching for the following cacheable resources: >>> >>> https://d39chrhoz7kxwa.cloudfront.net/1f1a90de-ed5_300.jpg (expiration >>> not specified) >>> https://d39chrhoz7kxwa.cloudfront.net/29fb2b34-55d_300.jpg (expiration >>> not specified) >>> https://d39chrhoz7kxwa.cloudfront.net/3902d130-3b1_300.jpg (expiration >>> not specified) >>> https://d39chrhoz7kxwa.cloudfront.net/75713aa2-bec_300.jpg (expiration >>> not specified) >>> https://www.cardaddy.com/modules.gz/autocomplete-custom.js (60 seconds) >>> https://www.cardaddy.com/modules.gz/bootstrap/collapse.js (60 seconds) >>> https://www.cardaddy.com/modules.gz/bootstrap/dropdown.js (60 seconds) >>> https://www.cardaddy.com/modules.gz/bootstrap/transition.js (60 seconds) >>> https://www.cardaddy.com/modules.gz/t5/core/messages/en_US.js (60 seconds) >>> https://www.cardaddy.com/modules.gz/t5/core/select.js (60 seconds) >>> https://www.cardaddy.com/modules.gz/t5/core/zone.js (60 seconds) >>> >>> Any thoughts? >>> >>> On Sun, Dec 21, 2014 at 5:14 PM, Harry Zhou wrote: Hi Bob and Thiago, thank you for pointing me to the right direction! Problem solved. It is NOT Tapestry related: Chrome's PageSpeed audit tool chooses to ignore Tapestry's 10-year-in-the-future "Expires" response header. But during actual browsing the assets are actually cached (seeing "200 from cache"). Google seems to take the position that "Expires" response headers are "superseded." While Chrome honors "Expires" during browsing, it will also look for a "Cache-Control" in re
Re: Far Future Expiration Headers of Assets
Hi Guys, I'm back on this topic again. Does anybody know how to bump up the default 60 second time to something further in the future? On Mon, Dec 22, 2014 at 4:01 PM, Harry Zhou wrote: > Hi George, > > It does sound like the same issue. > > Regarding the "leverage browser caching" warning, I did not "solve" > the problem -- it appears to be a false alarm by Chrome PageSpeed: (i) > if one keeps the Chrome developer panel up and click around in a > Tapestry webapp, one should see that the assets are indeed cached > after the initial round of full requests ("200 from cache" will be > shown for cached assets). No requests for these assets will actually > be sent to server unless the user clicks the refresh button or run an > audit with page reload from Chrome PageSpeed. The latter case is > where PageSpeed will complain about the assets, because although it > sees the 10-year-in-the-future headers in the responses, which Chrome > does honor and will cache accordingly, PageSpeed will, however, want > to see a "Cache-Control" header in responses. It is likely a > non-issue because during ordinary browsing client caching is > leveraged. > > The 60 seconds for modules are discussed here: > http://tapestry.apache.org/javascript-modules.html > > "By default, Tapestry sets a max age of 60 (seconds) on modules, so > you won't see module requests on every page load. This is configurable > and you may want a much higher value in production. If you are rapidly > iterating on the source of a module, you may need to force the browser > to reload after clearing local cache. Chrome has an option to disable > the client-side cache when its developer tools are open." > > The page lists solutions as well. > > Harry > > > > > > > > On Mon, Dec 22, 2014 at 12:44 PM, George Christman > wrote: >> I'm having this same issue which I posted up a couple weeks ago >> without any response. >> http://apache-tapestry-mailing-list-archives.1045711.n5.nabble.com/5-4-asset-expire-header-td5729478.html >> >> So my first question is what did you do to resolve the issue? >> >> Secondly I am running in production mode, so I'm not sure what the >> cause could be. I'll have to check the cdn, but this is what google is >> complaining about. The images are being called from a sprite map in >> css where the context binding prefix can't be used. >> >> Leverage browser caching >> >> Setting an expiry date or a maximum age in the HTTP headers for static >> resources instructs the browser to load previously downloaded >> resources from local disk rather than over the network. >> Leverage browser caching for the following cacheable resources: >> >> https://d39chrhoz7kxwa.cloudfront.net/1f1a90de-ed5_300.jpg (expiration >> not specified) >> https://d39chrhoz7kxwa.cloudfront.net/29fb2b34-55d_300.jpg (expiration >> not specified) >> https://d39chrhoz7kxwa.cloudfront.net/3902d130-3b1_300.jpg (expiration >> not specified) >> https://d39chrhoz7kxwa.cloudfront.net/75713aa2-bec_300.jpg (expiration >> not specified) >> https://www.cardaddy.com/modules.gz/autocomplete-custom.js (60 seconds) >> https://www.cardaddy.com/modules.gz/bootstrap/collapse.js (60 seconds) >> https://www.cardaddy.com/modules.gz/bootstrap/dropdown.js (60 seconds) >> https://www.cardaddy.com/modules.gz/bootstrap/transition.js (60 seconds) >> https://www.cardaddy.com/modules.gz/t5/core/messages/en_US.js (60 seconds) >> https://www.cardaddy.com/modules.gz/t5/core/select.js (60 seconds) >> https://www.cardaddy.com/modules.gz/t5/core/zone.js (60 seconds) >> >> Any thoughts? >> >> On Sun, Dec 21, 2014 at 5:14 PM, Harry Zhou wrote: >>> Hi Bob and Thiago, thank you for pointing me to the right direction! >>> Problem solved. >>> >>> It is NOT Tapestry related: Chrome's PageSpeed audit tool chooses to >>> ignore Tapestry's 10-year-in-the-future "Expires" response header. >>> But during actual browsing the assets are actually cached (seeing "200 >>> from cache"). >>> >>> Google seems to take the position that "Expires" response headers are >>> "superseded." While Chrome honors "Expires" during browsing, it will >>> also look for a "Cache-Control" in response headers. See >>> https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching#cache-control >>> >>> >>> On Sun, Dec 21, 2014 at 2:54 PM, Thiago H de Paula Figueiredo >>> wrote: Another thing to check: production mode is off? On Sun, 21 Dec 2014 17:34:39 -0200, Bob Harner wrote: > Be sure production mode is on and that your links to the asset are using > the asset: or context: binding prefix. > > Can you give us a typical asset URL (as seen by the browser)? That might > give us some hints. > > Also be sure the expires headers aren't being removed by a proxy or CDN. > Hint: doest the issue happen on your desktop with local host, or only when > running on a server? > On Dec 21, 2014 11:55 AM, "Harry Zhou" wrote: > >> Hi! >>
Re: Far Future Expiration Headers of Assets
Hi George, It does sound like the same issue. Regarding the "leverage browser caching" warning, I did not "solve" the problem -- it appears to be a false alarm by Chrome PageSpeed: (i) if one keeps the Chrome developer panel up and click around in a Tapestry webapp, one should see that the assets are indeed cached after the initial round of full requests ("200 from cache" will be shown for cached assets). No requests for these assets will actually be sent to server unless the user clicks the refresh button or run an audit with page reload from Chrome PageSpeed. The latter case is where PageSpeed will complain about the assets, because although it sees the 10-year-in-the-future headers in the responses, which Chrome does honor and will cache accordingly, PageSpeed will, however, want to see a "Cache-Control" header in responses. It is likely a non-issue because during ordinary browsing client caching is leveraged. The 60 seconds for modules are discussed here: http://tapestry.apache.org/javascript-modules.html "By default, Tapestry sets a max age of 60 (seconds) on modules, so you won't see module requests on every page load. This is configurable and you may want a much higher value in production. If you are rapidly iterating on the source of a module, you may need to force the browser to reload after clearing local cache. Chrome has an option to disable the client-side cache when its developer tools are open." The page lists solutions as well. Harry On Mon, Dec 22, 2014 at 12:44 PM, George Christman wrote: > I'm having this same issue which I posted up a couple weeks ago > without any response. > http://apache-tapestry-mailing-list-archives.1045711.n5.nabble.com/5-4-asset-expire-header-td5729478.html > > So my first question is what did you do to resolve the issue? > > Secondly I am running in production mode, so I'm not sure what the > cause could be. I'll have to check the cdn, but this is what google is > complaining about. The images are being called from a sprite map in > css where the context binding prefix can't be used. > > Leverage browser caching > > Setting an expiry date or a maximum age in the HTTP headers for static > resources instructs the browser to load previously downloaded > resources from local disk rather than over the network. > Leverage browser caching for the following cacheable resources: > > https://d39chrhoz7kxwa.cloudfront.net/1f1a90de-ed5_300.jpg (expiration > not specified) > https://d39chrhoz7kxwa.cloudfront.net/29fb2b34-55d_300.jpg (expiration > not specified) > https://d39chrhoz7kxwa.cloudfront.net/3902d130-3b1_300.jpg (expiration > not specified) > https://d39chrhoz7kxwa.cloudfront.net/75713aa2-bec_300.jpg (expiration > not specified) > https://www.cardaddy.com/modules.gz/autocomplete-custom.js (60 seconds) > https://www.cardaddy.com/modules.gz/bootstrap/collapse.js (60 seconds) > https://www.cardaddy.com/modules.gz/bootstrap/dropdown.js (60 seconds) > https://www.cardaddy.com/modules.gz/bootstrap/transition.js (60 seconds) > https://www.cardaddy.com/modules.gz/t5/core/messages/en_US.js (60 seconds) > https://www.cardaddy.com/modules.gz/t5/core/select.js (60 seconds) > https://www.cardaddy.com/modules.gz/t5/core/zone.js (60 seconds) > > Any thoughts? > > On Sun, Dec 21, 2014 at 5:14 PM, Harry Zhou wrote: >> Hi Bob and Thiago, thank you for pointing me to the right direction! >> Problem solved. >> >> It is NOT Tapestry related: Chrome's PageSpeed audit tool chooses to >> ignore Tapestry's 10-year-in-the-future "Expires" response header. >> But during actual browsing the assets are actually cached (seeing "200 >> from cache"). >> >> Google seems to take the position that "Expires" response headers are >> "superseded." While Chrome honors "Expires" during browsing, it will >> also look for a "Cache-Control" in response headers. See >> https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching#cache-control >> >> >> On Sun, Dec 21, 2014 at 2:54 PM, Thiago H de Paula Figueiredo >> wrote: >>> Another thing to check: production mode is off? >>> >>> >>> On Sun, 21 Dec 2014 17:34:39 -0200, Bob Harner wrote: >>> Be sure production mode is on and that your links to the asset are using the asset: or context: binding prefix. Can you give us a typical asset URL (as seen by the browser)? That might give us some hints. Also be sure the expires headers aren't being removed by a proxy or CDN. Hint: doest the issue happen on your desktop with local host, or only when running on a server? On Dec 21, 2014 11:55 AM, "Harry Zhou" wrote: > Hi! > > About my T5.4 site, Google is complaining that "resources are missing > a cache expiration. Resources that do not specify an expiration may > not be cached by browsers . . . " > > I read that "assets get a far-future expires header" and will be > "client browsers will aggressively cache downloaded ass
Re: Far Future Expiration Headers of Assets
The cdn should handle the expire headers. Tapestry only tells the client where to get the files. As for the modules I've never had a look at their expiration time, but a simple test app in production mode also reposts 60secs here. - Guess that could be something to dig into. -- Chris On Mon, Dec 22, 2014 at 6:44 PM, George Christman wrote: > I'm having this same issue which I posted up a couple weeks ago > without any response. > > http://apache-tapestry-mailing-list-archives.1045711.n5.nabble.com/5-4-asset-expire-header-td5729478.html > > So my first question is what did you do to resolve the issue? > > Secondly I am running in production mode, so I'm not sure what the > cause could be. I'll have to check the cdn, but this is what google is > complaining about. The images are being called from a sprite map in > css where the context binding prefix can't be used. > > Leverage browser caching > > Setting an expiry date or a maximum age in the HTTP headers for static > resources instructs the browser to load previously downloaded > resources from local disk rather than over the network. > Leverage browser caching for the following cacheable resources: > > https://d39chrhoz7kxwa.cloudfront.net/1f1a90de-ed5_300.jpg (expiration > not specified) > https://d39chrhoz7kxwa.cloudfront.net/29fb2b34-55d_300.jpg (expiration > not specified) > https://d39chrhoz7kxwa.cloudfront.net/3902d130-3b1_300.jpg (expiration > not specified) > https://d39chrhoz7kxwa.cloudfront.net/75713aa2-bec_300.jpg (expiration > not specified) > https://www.cardaddy.com/modules.gz/autocomplete-custom.js (60 seconds) > https://www.cardaddy.com/modules.gz/bootstrap/collapse.js (60 seconds) > https://www.cardaddy.com/modules.gz/bootstrap/dropdown.js (60 seconds) > https://www.cardaddy.com/modules.gz/bootstrap/transition.js (60 seconds) > https://www.cardaddy.com/modules.gz/t5/core/messages/en_US.js (60 seconds) > https://www.cardaddy.com/modules.gz/t5/core/select.js (60 seconds) > https://www.cardaddy.com/modules.gz/t5/core/zone.js (60 seconds) > > Any thoughts? > > On Sun, Dec 21, 2014 at 5:14 PM, Harry Zhou wrote: > > Hi Bob and Thiago, thank you for pointing me to the right direction! > > Problem solved. > > > > It is NOT Tapestry related: Chrome's PageSpeed audit tool chooses to > > ignore Tapestry's 10-year-in-the-future "Expires" response header. > > But during actual browsing the assets are actually cached (seeing "200 > > from cache"). > > > > Google seems to take the position that "Expires" response headers are > > "superseded." While Chrome honors "Expires" during browsing, it will > > also look for a "Cache-Control" in response headers. See > > > https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching#cache-control > > > > > > On Sun, Dec 21, 2014 at 2:54 PM, Thiago H de Paula Figueiredo > > wrote: > >> Another thing to check: production mode is off? > >> > >> > >> On Sun, 21 Dec 2014 17:34:39 -0200, Bob Harner > wrote: > >> > >>> Be sure production mode is on and that your links to the asset are > using > >>> the asset: or context: binding prefix. > >>> > >>> Can you give us a typical asset URL (as seen by the browser)? That > might > >>> give us some hints. > >>> > >>> Also be sure the expires headers aren't being removed by a proxy or > CDN. > >>> Hint: doest the issue happen on your desktop with local host, or only > when > >>> running on a server? > >>> On Dec 21, 2014 11:55 AM, "Harry Zhou" wrote: > >>> > Hi! > > About my T5.4 site, Google is complaining that "resources are missing > a cache expiration. Resources that do not specify an expiration may > not be cached by browsers . . . " > > I read that "assets get a far-future expires header" and will be > "client browsers will aggressively cache downloaded assets." So I am > not sure why responses for my assets all come with > "Cache-Control:no-cache" and "Pragma:no-cache". > > Any help would be appreciated. Thanks! > > Best Regards > Harry > > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > > > >> > >> > >> -- > >> Thiago H. de Paula Figueiredo > >> Tapestry, Java and Hibernate consultant and developer > >> http://machina.com.br > >> > >> > >> - > >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > >> For additional commands, e-mail: users-h...@tapestry.apache.org > >> > > > > > > > > -- > > Best Regards > > Harry Zhou > > > > - > > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > > For additional commands, e-mail: users-h...@tapestry.apache.org > > > > > > -- > George Christman > CEO > www.CarDa
Re: Far Future Expiration Headers of Assets
I'm having this same issue which I posted up a couple weeks ago without any response. http://apache-tapestry-mailing-list-archives.1045711.n5.nabble.com/5-4-asset-expire-header-td5729478.html So my first question is what did you do to resolve the issue? Secondly I am running in production mode, so I'm not sure what the cause could be. I'll have to check the cdn, but this is what google is complaining about. The images are being called from a sprite map in css where the context binding prefix can't be used. Leverage browser caching Setting an expiry date or a maximum age in the HTTP headers for static resources instructs the browser to load previously downloaded resources from local disk rather than over the network. Leverage browser caching for the following cacheable resources: https://d39chrhoz7kxwa.cloudfront.net/1f1a90de-ed5_300.jpg (expiration not specified) https://d39chrhoz7kxwa.cloudfront.net/29fb2b34-55d_300.jpg (expiration not specified) https://d39chrhoz7kxwa.cloudfront.net/3902d130-3b1_300.jpg (expiration not specified) https://d39chrhoz7kxwa.cloudfront.net/75713aa2-bec_300.jpg (expiration not specified) https://www.cardaddy.com/modules.gz/autocomplete-custom.js (60 seconds) https://www.cardaddy.com/modules.gz/bootstrap/collapse.js (60 seconds) https://www.cardaddy.com/modules.gz/bootstrap/dropdown.js (60 seconds) https://www.cardaddy.com/modules.gz/bootstrap/transition.js (60 seconds) https://www.cardaddy.com/modules.gz/t5/core/messages/en_US.js (60 seconds) https://www.cardaddy.com/modules.gz/t5/core/select.js (60 seconds) https://www.cardaddy.com/modules.gz/t5/core/zone.js (60 seconds) Any thoughts? On Sun, Dec 21, 2014 at 5:14 PM, Harry Zhou wrote: > Hi Bob and Thiago, thank you for pointing me to the right direction! > Problem solved. > > It is NOT Tapestry related: Chrome's PageSpeed audit tool chooses to > ignore Tapestry's 10-year-in-the-future "Expires" response header. > But during actual browsing the assets are actually cached (seeing "200 > from cache"). > > Google seems to take the position that "Expires" response headers are > "superseded." While Chrome honors "Expires" during browsing, it will > also look for a "Cache-Control" in response headers. See > https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching#cache-control > > > On Sun, Dec 21, 2014 at 2:54 PM, Thiago H de Paula Figueiredo > wrote: >> Another thing to check: production mode is off? >> >> >> On Sun, 21 Dec 2014 17:34:39 -0200, Bob Harner wrote: >> >>> Be sure production mode is on and that your links to the asset are using >>> the asset: or context: binding prefix. >>> >>> Can you give us a typical asset URL (as seen by the browser)? That might >>> give us some hints. >>> >>> Also be sure the expires headers aren't being removed by a proxy or CDN. >>> Hint: doest the issue happen on your desktop with local host, or only when >>> running on a server? >>> On Dec 21, 2014 11:55 AM, "Harry Zhou" wrote: >>> Hi! About my T5.4 site, Google is complaining that "resources are missing a cache expiration. Resources that do not specify an expiration may not be cached by browsers . . . " I read that "assets get a far-future expires header" and will be "client browsers will aggressively cache downloaded assets." So I am not sure why responses for my assets all come with "Cache-Control:no-cache" and "Pragma:no-cache". Any help would be appreciated. Thanks! Best Regards Harry - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org >> >> >> -- >> Thiago H. de Paula Figueiredo >> Tapestry, Java and Hibernate consultant and developer >> http://machina.com.br >> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: users-h...@tapestry.apache.org >> > > > > -- > Best Regards > Harry Zhou > > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > -- George Christman CEO www.CarDaddy.com P.O. Box 735 Johnstown, New York - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Far Future Expiration Headers of Assets
Hi Bob and Thiago, thank you for pointing me to the right direction! Problem solved. It is NOT Tapestry related: Chrome's PageSpeed audit tool chooses to ignore Tapestry's 10-year-in-the-future "Expires" response header. But during actual browsing the assets are actually cached (seeing "200 from cache"). Google seems to take the position that "Expires" response headers are "superseded." While Chrome honors "Expires" during browsing, it will also look for a "Cache-Control" in response headers. See https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching#cache-control On Sun, Dec 21, 2014 at 2:54 PM, Thiago H de Paula Figueiredo wrote: > Another thing to check: production mode is off? > > > On Sun, 21 Dec 2014 17:34:39 -0200, Bob Harner wrote: > >> Be sure production mode is on and that your links to the asset are using >> the asset: or context: binding prefix. >> >> Can you give us a typical asset URL (as seen by the browser)? That might >> give us some hints. >> >> Also be sure the expires headers aren't being removed by a proxy or CDN. >> Hint: doest the issue happen on your desktop with local host, or only when >> running on a server? >> On Dec 21, 2014 11:55 AM, "Harry Zhou" wrote: >> >>> Hi! >>> >>> About my T5.4 site, Google is complaining that "resources are missing >>> a cache expiration. Resources that do not specify an expiration may >>> not be cached by browsers . . . " >>> >>> I read that "assets get a far-future expires header" and will be >>> "client browsers will aggressively cache downloaded assets." So I am >>> not sure why responses for my assets all come with >>> "Cache-Control:no-cache" and "Pragma:no-cache". >>> >>> Any help would be appreciated. Thanks! >>> >>> Best Regards >>> Harry >>> >>> - >>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >>> For additional commands, e-mail: users-h...@tapestry.apache.org >>> >>> > > > -- > Thiago H. de Paula Figueiredo > Tapestry, Java and Hibernate consultant and developer > http://machina.com.br > > > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > -- Best Regards Harry Zhou - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Far Future Expiration Headers of Assets
Another thing to check: production mode is off? On Sun, 21 Dec 2014 17:34:39 -0200, Bob Harner wrote: Be sure production mode is on and that your links to the asset are using the asset: or context: binding prefix. Can you give us a typical asset URL (as seen by the browser)? That might give us some hints. Also be sure the expires headers aren't being removed by a proxy or CDN. Hint: doest the issue happen on your desktop with local host, or only when running on a server? On Dec 21, 2014 11:55 AM, "Harry Zhou" wrote: Hi! About my T5.4 site, Google is complaining that "resources are missing a cache expiration. Resources that do not specify an expiration may not be cached by browsers . . . " I read that "assets get a far-future expires header" and will be "client browsers will aggressively cache downloaded assets." So I am not sure why responses for my assets all come with "Cache-Control:no-cache" and "Pragma:no-cache". Any help would be appreciated. Thanks! Best Regards Harry - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org -- Thiago H. de Paula Figueiredo Tapestry, Java and Hibernate consultant and developer http://machina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Far Future Expiration Headers of Assets
Be sure production mode is on and that your links to the asset are using the asset: or context: binding prefix. Can you give us a typical asset URL (as seen by the browser)? That might give us some hints. Also be sure the expires headers aren't being removed by a proxy or CDN. Hint: doest the issue happen on your desktop with local host, or only when running on a server? On Dec 21, 2014 11:55 AM, "Harry Zhou" wrote: > Hi! > > About my T5.4 site, Google is complaining that "resources are missing > a cache expiration. Resources that do not specify an expiration may > not be cached by browsers . . . " > > I read that "assets get a far-future expires header" and will be > "client browsers will aggressively cache downloaded assets." So I am > not sure why responses for my assets all come with > "Cache-Control:no-cache" and "Pragma:no-cache". > > Any help would be appreciated. Thanks! > > Best Regards > Harry > > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > >
Far Future Expiration Headers of Assets
Hi! About my T5.4 site, Google is complaining that "resources are missing a cache expiration. Resources that do not specify an expiration may not be cached by browsers . . . " I read that "assets get a far-future expires header" and will be "client browsers will aggressively cache downloaded assets." So I am not sure why responses for my assets all come with "Cache-Control:no-cache" and "Pragma:no-cache". Any help would be appreciated. Thanks! Best Regards Harry - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org