Hey Michael, Yeah respond.js is exactly what we are using. However, I overlooked that it kind of supports CDN/X-Domain via a local proxy. The solution looks a bit complicated but I'll give it a try now. If it works it would solve my original issue.
Cheers, Thomas On Tue, Jun 18, 2013 at 10:11 AM, Michael Haitz <michael.ha...@1und1.de>wrote: > Hi, > > if you describe your process a bit more, i could help you out. In one of > my projects we render additional/browser specific css files like all > other css files (except the browser checks based on ClientProperties, no > conditional comments and so on). > > Do you know https://github.com/scottjehl/Respond? > > best, > Michael > > Am 17.06.2013 um 17:30 schrieb Thomas Heigl <tho...@umschalt.com>: > > > Hey Michael, > > > > but isn't it enough to send the correct cache headers + a calculated > >> filename that contains the hash of file? > > > > > > I actually have aggressive caching and a CDN in front of my resources. So > > in 90% of cases, a resource is only generated once per deployment. My > > problem is that I need to fetch some resources directly from my origin to > > support media queries for IE<=8 and avoid running into cross-domain > issues. > > So between 5 and 10% of users directly hit my origin for CSS resources > and > > the load generated by this is getting too high. > > > > Thanks a lot for your suggestions. I'll try to think of a solution that > > does not involve Wicket. > > > > Cheers, > > > > Thomas > > > > > > > > On Mon, Jun 17, 2013 at 4:57 PM, Michael Haitz <michael.ha...@1und1.de > >wrote: > > > >> Hi, > >> > >> but isn't it enough to send the correct cache headers + a calculated > >> filename that contains the hash of file? > >> I think caching on your container isn't the best option (using nginx or > >> varnish or a CDN like Akamai or something similar is way better), else > >> you've to compile each resource on all your containers and you need some > >> heap space for the content. > >> > >> best, > >> Michael > >> > >> Am 17.06.2013 um 16:02 schrieb Michael Haitz <michael.ha...@1und1.de> > >> : > >> > >>> Hi Thomas, > >>> > >>> it depends on your deployment mode: > >>> > >>> if (application.usesDevelopmentConfig()) > >>> { > >>> // development mode: > >>> // use last-modified timestamp of packaged resource for resource > >> caching > >>> // cache the version information for the lifetime of the current > >> http request > >>> resourceVersion = new RequestCycleCachedResourceVersion( > >>> new LastModifiedResourceVersion()); > >>> } > >>> else > >>> { > >>> // deployment mode: > >>> // use message digest over resource content for resource caching > >>> // cache the version information for the lifetime of the > >> application > >>> resourceVersion = new CachingResourceVersion(new > >> MessageDigestResourceVersion()); > >>> } > >>> > >>> best, > >>> Michael > >>> > >>> > >>> Am 17.06.2013 um 15:21 schrieb Thomas Heigl <tho...@umschalt.com>: > >>> > >>>> Hi all, > >>>> > >>>> I was wondering if Wicket has a built-in mechanism for caching the > >>>> generated byte[] of package resources. I use concatenated resource > >> bundles > >>>> that are compressed using the YUI CSS/JS compressors. > >>>> > >>>> Using the default settings, compression is performed for every request > >> that > >>>> does not have it in the client cache. Since this compression is a very > >>>> complex operation I'd like to perform it only once. > >>>> > >>>> Cheers, > >>>> > >>>> Thomas > >>> > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > >>> For additional commands, e-mail: users-h...@wicket.apache.org > >>> > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > >> For additional commands, e-mail: users-h...@wicket.apache.org > >> > >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
