I was out of office for some weeks. Thanks for writing this post – I am very eager to try it out

Thanks again,
andr

Concerning Amazaon CloudFront, I can’t say more than that: it simply works for us, as we’re in their environment anyway. It wasn’t more than a click of a button to get started.

Pricing doesn’t matter too much either, since we are in the lower 3-digit numbers ($) with our monthly traffic. I simply doubt that switching providers could be worth the effort. But actually, we never seriously considered other CDNs

Nevertheless, if you know any particularly cheap and reliable services, please let me know.

Cheers, Stefan

thanks for your quick reply. I have used cloudfiles so far based on the first option. Frankly, I haven’t heard of the second option so far, but it sound interesting.

Could you quickly point out your experiences with amazon or the reasons why you chose it, since from my point of view they seem just more expensive as a CDN provider. But they offer interesting services like Beanstalk though…

thanks,
andr

that’s actually something I’ve planned to do for a while now.

What type of CDN are you most interested in? One that requires uploading content to it’s server or one that fetches content from the your application on demand? We actually implemented and used both approaches with Amazon CloudFront.

I’ll try to publish the code some time soon, I promise

Cheers, Stefan

regards,
andr

And hey, good luck with the project!

the new home of wicketstuff-merged-resources is now at Github:

http://github.com/molindo/wicketstuff-merged-resources

Right now, I don’t have time to look into the issue. But if I remember correctly, there was an issue raised in Wicketstuff JIRA before it went offline (for good?). Please raise a new issue at Github:

https://github.com/molindo/wicketstuff-merged-resources/issues

It’s certainly a valid issue (which I actually thought was solved a while ago). Nevertheless, I’ll try to have a look at it next week.

Cheers, Stefan

Only after I had submitted my response it occured to me to check the svn log. At r5343 there was an attempt at solving the inheritance issue but it was reverted at r5354 due to some problems. So apparently this is not an trivial issue.

There is one problem though. I have tried both the 3.0 release and the svn trunk but both fail to contribute the required headers when component inheritance is involved. To be more clear, I have component A that declares some CSS contributions and component B that extends A. If I include component B on a page, then the CSS contributions of component A are not added to the headers.

For our project this is a no go issue. However, I might be able to work on solving the issue if we discover that we can’t live without wicketstuff-merged-resources.

I found this thread about the same problem:
http://mail-archives.apache.org/mod_mbox/wicket-users/201005.mbox/%3cAANLkTilgZuVfxLE_OvOSSpNuh-fuvi6gYde7USArFR42@mail.gmail.com%3e

Stefan, what is your take on this issue?

You could also take a look on your site’s access statistics to check which page is the most important entry page. Assuming it’s Page1, you could merge Page1.css and common.css and keep Page2.css separate. If a user accesses Page2 there’s a good chance that the merged common.css is already in cache.

Unfortunately, I don’t know of a way to measure cache hit rates for resources (as you can see at http://stackoverflow.com/questions/3300891/how-to-measure-http-cache-hit-rates). Hence tuning is all about such assumptions.

Hope this helps.