Discussion on "Wicket Interface Speed-Up"
I just finished the 4th and last entry of my series "Wicket Interface Speed-Up" on my blog. To give a short summary: I investigated one of my apps with YSlow and started optimizing it's interface rendering speed [1]. Especially Wicket's way of handling resources, i.e. JS and CSS files, causes interfaces to load rather slowly. In my articles, I explain how to modify the cache interval [2], how to mount resources with a version (e.g. /css/all-1234.css) in order to use aggressive client-side caching (e.g. resources expire after a year) [3]. Finally, I show how to merge resources at application startup (using a class classed MergedResourceStream) to reduce the number of resources a client has to download [4], including code). I was able to increase interface loading times considerably, so it's surely worth a look. I feel that it would also be worth to discuss, whether this work could be part of upcoming Wicket versions. For the time being I'd like to make the code attached to [4] a wicketstuff project - sfussenegger needs commit access ;) - and wait for your feedback. The links: [1] http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up.html Wicket Interface Speed-Up [2] http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-modifying.html Wicket Interface Speed-Up: Modifying Expires and Cache-Control Headers [3] http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-caching.html Wicket Interface Speed-Up: Caching Resources Forever [4] http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-merging.html Wicket Interface Speed-Up: Merging Resources for Fewer HTTP Requests - --- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- View this message in context: http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19197540.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Discussion on "Wicket Interface Speed-Up"
Again, great work Stefan! The basics already work fine, allowing me to keep a maintenance friendly style of development while heavily optimizing frontend performance. The biggest isse now is the public API: I have to duplicate a lot of information in the application and the page/component classes. Eventually something like this could remove the duplication while making it very easy to add new components and resources: @HeaderContribution( scripts={"jquery.js", "Example.js"}, stylesheets={"theme.js", "Example.css"} ) public class Example { public Example() { HeaderContribution.addResources(this); } } With something similar to wicketstuff-annotation in the Application#init method: new AnnotatedResourcesMountScanner().scanPackage("my.package").mount(this); A small issue, but still important: Please consider setting JDK 5 as the goal for the project. JDK 6 is still unavailable on most OSX installations and the one or two new methods aren't worth the trouble. If you don't have plans to support JDK 1.4, it would be nice to replace the various array-arguments with (generic) varargs/collections. Jörn On Thu, Aug 28, 2008 at 11:59 AM, Stefan Fußenegger <[EMAIL PROTECTED]> wrote: > > I just finished the 4th and last entry of my series "Wicket Interface > Speed-Up" on my blog. To give a short summary: I investigated one of my apps > with YSlow and started optimizing it's interface rendering speed [1]. > Especially Wicket's way of handling resources, i.e. JS and CSS files, causes > interfaces to load rather slowly. In my articles, I explain how to modify > the cache interval [2], how to mount resources with a version (e.g. > /css/all-1234.css) in order to use aggressive client-side caching (e.g. > resources expire after a year) [3]. Finally, I show how to merge resources > at application startup (using a class classed MergedResourceStream) to > reduce the number of resources a client has to download [4], including > code). I was able to increase interface loading times considerably, so it's > surely worth a look. > > I feel that it would also be worth to discuss, whether this work could be > part of upcoming Wicket versions. For the time being I'd like to make the > code attached to [4] a wicketstuff project - sfussenegger needs commit > access ;) - and wait for your feedback. > > The links: > [1] http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up.html > Wicket Interface Speed-Up > [2] > http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-modifying.html > Wicket Interface Speed-Up: Modifying Expires and Cache-Control Headers > [3] > http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-caching.html > Wicket Interface Speed-Up: Caching Resources Forever > [4] > http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-merging.html > Wicket Interface Speed-Up: Merging Resources for Fewer HTTP Requests > > - > --- > Stefan Fußenegger > http://talk-on-tech.blogspot.com // looking for a nicer domain ;) > -- > View this message in context: > http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19197540.html > Sent from the Wicket - User mailing list archive at Nabble.com. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: Discussion on "Wicket Interface Speed-Up"
sfussenegger now has access to wicketstuff... i dont know which parts should go into wicket itself, i can tell you that the part where you merge the files by listing them out upfront is probably not going to make it in because it breaks encapsulation... -igor On Thu, Aug 28, 2008 at 2:59 AM, Stefan Fußenegger <[EMAIL PROTECTED]> wrote: > > I just finished the 4th and last entry of my series "Wicket Interface > Speed-Up" on my blog. To give a short summary: I investigated one of my apps > with YSlow and started optimizing it's interface rendering speed [1]. > Especially Wicket's way of handling resources, i.e. JS and CSS files, causes > interfaces to load rather slowly. In my articles, I explain how to modify > the cache interval [2], how to mount resources with a version (e.g. > /css/all-1234.css) in order to use aggressive client-side caching (e.g. > resources expire after a year) [3]. Finally, I show how to merge resources > at application startup (using a class classed MergedResourceStream) to > reduce the number of resources a client has to download [4], including > code). I was able to increase interface loading times considerably, so it's > surely worth a look. > > I feel that it would also be worth to discuss, whether this work could be > part of upcoming Wicket versions. For the time being I'd like to make the > code attached to [4] a wicketstuff project - sfussenegger needs commit > access ;) - and wait for your feedback. > > The links: > [1] http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up.html > Wicket Interface Speed-Up > [2] > http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-modifying.html > Wicket Interface Speed-Up: Modifying Expires and Cache-Control Headers > [3] > http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-caching.html > Wicket Interface Speed-Up: Caching Resources Forever > [4] > http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-merging.html > Wicket Interface Speed-Up: Merging Resources for Fewer HTTP Requests > > - > --- > Stefan Fußenegger > http://talk-on-tech.blogspot.com // looking for a nicer domain ;) > -- > View this message in context: > http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19197540.html > Sent from the Wicket - User mailing list archive at Nabble.com. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Discussion on "Wicket Interface Speed-Up"
@stefan: did you take into account getApplication ().getResourceSettings ().setAddLastModifiedTimeToResourceReferenceUrl(true)?? Cheers Peter Am 28.08.2008 um 18:20 schrieb Igor Vaynberg: sfussenegger now has access to wicketstuff... i dont know which parts should go into wicket itself, i can tell you that the part where you merge the files by listing them out upfront is probably not going to make it in because it breaks encapsulation... -igor On Thu, Aug 28, 2008 at 2:59 AM, Stefan Fußenegger <[EMAIL PROTECTED]> wrote: I just finished the 4th and last entry of my series "Wicket Interface Speed-Up" on my blog. To give a short summary: I investigated one of my apps with YSlow and started optimizing it's interface rendering speed [1]. Especially Wicket's way of handling resources, i.e. JS and CSS files, causes interfaces to load rather slowly. In my articles, I explain how to modify the cache interval [2], how to mount resources with a version (e.g. /css/all-1234.css) in order to use aggressive client-side caching (e.g. resources expire after a year) [3]. Finally, I show how to merge resources at application startup (using a class classed MergedResourceStream) to reduce the number of resources a client has to download [4], including code). I was able to increase interface loading times considerably, so it's surely worth a look. I feel that it would also be worth to discuss, whether this work could be part of upcoming Wicket versions. For the time being I'd like to make the code attached to [4] a wicketstuff project - sfussenegger needs commit access ;) - and wait for your feedback. The links: [1] http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up.html Wicket Interface Speed-Up [2] http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-modifying.html Wicket Interface Speed-Up: Modifying Expires and Cache-Control Headers [3] http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-caching.html Wicket Interface Speed-Up: Caching Resources Forever [4] http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-merging.html Wicket Interface Speed-Up: Merging Resources for Fewer HTTP Requests - --- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- View this message in context: http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19197540.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Discussion on "Wicket Interface Speed-Up"
nice we are also taking efforts in optimizing the webapp as we serve the resources (images/css/js) using 3rd content provider, our approach is different from your wicket-focus turning; but it indeeds give me some insight, thanks we also want to "merge" the css/js files, but after thinking carefully, it can't work for us because we are using "header contribution" at different panels, it is very flexible for the designers to split the css/js files according to the panel and they like it very much for the flexibility, maintainability and reusability however, since a panel can hide/show dynamically for the same url in different times (though not common, but we can't avoid that), that means we can't simply "merge" different css/js files from different panels for the given page Stefan Fußenegger wrote: > > I just finished the 4th and last entry of my series "Wicket Interface > Speed-Up" on my blog. To give a short summary: I investigated one of my > apps with YSlow and started optimizing it's interface rendering speed [1]. > Especially Wicket's way of handling resources, i.e. JS and CSS files, > causes interfaces to load rather slowly. In my articles, I explain how to > modify the cache interval [2], how to mount resources with a version (e.g. > /css/all-1234.css) in order to use aggressive client-side caching (e.g. > resources expire after a year) [3]. Finally, I show how to merge resources > at application startup (using a class classed MergedResourceStream) to > reduce the number of resources a client has to download [4], including > code). I was able to increase interface loading times considerably, so > it's surely worth a look. > > I feel that it would also be worth to discuss, whether this work could be > part of upcoming Wicket versions. For the time being I'd like to make the > code attached to [4] a wicketstuff project - sfussenegger needs commit > access ;) - and wait for your feedback. > > The links: > [1] > http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up.html > Wicket Interface Speed-Up > [2] > http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-modifying.html > Wicket Interface Speed-Up: Modifying Expires and Cache-Control Headers > [3] > http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-caching.html > Wicket Interface Speed-Up: Caching Resources Forever > [4] > http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-merging.html > Wicket Interface Speed-Up: Merging Resources for Fewer HTTP Requests > -- View this message in context: http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19212465.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Discussion on "Wicket Interface Speed-Up"
honestly, no, I didn't. however, using last modified times still results in an HTTP request and a "304 Not Modified" reply. better than nothing, but client-side caching is still preferable. regards Peter Ertl wrote: > > @stefan: did you take into account > > > getApplication > ().getResourceSettings > ().setAddLastModifiedTimeToResourceReferenceUrl(true)?? > > Cheers > Peter > > > Am 28.08.2008 um 18:20 schrieb Igor Vaynberg: > >> sfussenegger now has access to wicketstuff... >> >> i dont know which parts should go into wicket itself, i can tell you >> that the part where you merge the files by listing them out upfront is >> probably not going to make it in because it breaks encapsulation... >> >> -igor >> >> On Thu, Aug 28, 2008 at 2:59 AM, Stefan Fußenegger >> <[EMAIL PROTECTED]> wrote: >>> >>> I just finished the 4th and last entry of my series "Wicket Interface >>> Speed-Up" on my blog. To give a short summary: I investigated one >>> of my apps >>> with YSlow and started optimizing it's interface rendering speed [1]. >>> Especially Wicket's way of handling resources, i.e. JS and CSS >>> files, causes >>> interfaces to load rather slowly. In my articles, I explain how to >>> modify >>> the cache interval [2], how to mount resources with a version (e.g. >>> /css/all-1234.css) in order to use aggressive client-side caching >>> (e.g. >>> resources expire after a year) [3]. Finally, I show how to merge >>> resources >>> at application startup (using a class classed MergedResourceStream) >>> to >>> reduce the number of resources a client has to download [4], >>> including >>> code). I was able to increase interface loading times considerably, >>> so it's >>> surely worth a look. >>> >>> I feel that it would also be worth to discuss, whether this work >>> could be >>> part of upcoming Wicket versions. For the time being I'd like to >>> make the >>> code attached to [4] a wicketstuff project - sfussenegger needs >>> commit >>> access ;) - and wait for your feedback. >>> >>> The links: >>> [1] >>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up.html >>> Wicket Interface Speed-Up >>> [2] >>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-modifying.html >>> Wicket Interface Speed-Up: Modifying Expires and Cache-Control >>> Headers >>> [3] >>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-caching.html >>> Wicket Interface Speed-Up: Caching Resources Forever >>> [4] >>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-merging.html >>> Wicket Interface Speed-Up: Merging Resources for Fewer HTTP Requests >>> >>> - >>> --- >>> Stefan Fußenegger >>> http://talk-on-tech.blogspot.com // looking for a nicer domain ;) >>> -- >>> View this message in context: >>> http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19197540.html >>> Sent from the Wicket - User mailing list archive at Nabble.com. >>> >>> >>> - >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > - --- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- View this message in context: http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19214276.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Discussion on "Wicket Interface Speed-Up"
you're right with the encapsulation, but i feel that resource versioning (and aggressive client side caching) could be a nice addition to wicket. but maybe sombody can think of another way to reduce (merge) resources without breaking encapsulation ... btw, resource versioning also works with wicket-ajax.js and wicket-event.js: protected void init() { final String version = getFrameworkSettings().getVersion(); final String suffix = ("n/a".equals(version) ? "" : "-" + version) + ".js"; getSharedResources().add(WicketAjaxReference.INSTANCE.getName(), getResourceReference(WicketAjaxReference.class, "wicket-ajax.js").getResource()); mountSharedResourceWithCaching("/scripts/wicket-ajax" + suffix, WicketAjaxReference.INSTANCE.getSharedResourceKey()); getSharedResources().add(WicketEventReference.INSTANCE.getName(), getResourceReference(WicketEventReference.class, "wicket-event.js").getResource()); mountSharedResourceWithCaching("/scripts/wicket-event" + suffix, WicketEventReference.INSTANCE.getSharedResourceKey()); } // it's getting dirty ... protected void mountSharedResourceWithCaching(final String path, final String resourceKey) { mount(new SharedResourceRequestTargetUrlCodingStrategy(path, resourceKey) { public IRequestTarget decode(final RequestParameters requestParameters) { final SharedResourceRequestTarget t = (SharedResourceRequestTarget) super.decode(requestParameters); if (t != null) { // wrap target return new IRequestTarget() { public void detach(final RequestCycle requestCycle) {t.detach(requestCycle);} public void respond(final RequestCycle requestCycle) { t.respond(requestCycle); final WebResponse response = (WebResponse) requestCycle.getResponse(); response.setDateHeader("Expires", System.currentTimeMillis() + CACHE_DURATION * 1000L); response.setHeader("Cache-Control", "max-age=" + CACHE_DURATION); } }; } else { return null; } } }); } regards igor.vaynberg wrote: > > sfussenegger now has access to wicketstuff... > > i dont know which parts should go into wicket itself, i can tell you > that the part where you merge the files by listing them out upfront is > probably not going to make it in because it breaks encapsulation... > > -igor > > On Thu, Aug 28, 2008 at 2:59 AM, Stefan Fußenegger > <[EMAIL PROTECTED]> wrote: >> >> I just finished the 4th and last entry of my series "Wicket Interface >> Speed-Up" on my blog. To give a short summary: I investigated one of my >> apps >> with YSlow and started optimizing it's interface rendering speed [1]. >> Especially Wicket's way of handling resources, i.e. JS and CSS files, >> causes >> interfaces to load rather slowly. In my articles, I explain how to modify >> the cache interval [2], how to mount resources with a version (e.g. >> /css/all-1234.css) in order to use aggressive client-side caching (e.g. >> resources expire after a year) [3]. Finally, I show how to merge >> resources >> at application startup (using a class classed MergedResourceStream) to >> reduce the number of resources a client has to download [4], including >> code). I was able to increase interface loading times considerably, so >> it's >> surely worth a look. >> >> I feel that it would also be worth to discuss, whether this work could be >> part of upcoming Wicket versions. For the time being I'd like to make the >> code attached to [4] a wicketstuff project - sfussenegger needs commit >> access ;) - and wait for your feedback. >> >> The links: >> [1] >> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up.html >> Wicket Interface Speed-Up >> [2] >> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-modifying.html >> Wicket Interface Speed-Up: Modifying Expires and Cache-Control Headers >> [3] >> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-caching.html >> Wicket Interface Speed-Up: Caching Resources Forever >> [4] >> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-merging.html >> Wicket Interface Speed-Up: Merging Resources for Fewer HTTP Requests >> >> - >> --- >> Stefan Fußenegger >> http://talk-on-tech.blogspot.com // looking for a nicer domain ;) >> -- >> View this message in context: >> http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19197540.html >> Sent from the Wicket - User mailing list archive at Nabble.com. >> >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > - --- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- View this message in context
Re: Discussion on "Wicket Interface Speed-Up"
That's not true. this settings will generate urls like: /resources/[package+class]/javascript.js?lm=[lastmodified] read it again : "add Last Modified Time To Resource Reference Url" getApplication ().getResourceSettings ().setAddLastModifiedTimeToResourceReferenceUrl(true)?? It will not sent the "LastModified" header as you think. So whenever the resource changes the url changes, too. Try it out and see :-) I did test it in Firefox. There will be no "IfModified" requests from the browser. Everything will be completely cached in the browser until the resource has changed. Cheers Peter Am 29.08.2008 um 08:17 schrieb Stefan Fußenegger: honestly, no, I didn't. however, using last modified times still results in an HTTP request and a "304 Not Modified" reply. better than nothing, but client-side caching is still preferable. regards Peter Ertl wrote: @stefan: did you take into account getApplication ().getResourceSettings ().setAddLastModifiedTimeToResourceReferenceUrl(true)?? Cheers Peter Am 28.08.2008 um 18:20 schrieb Igor Vaynberg: sfussenegger now has access to wicketstuff... i dont know which parts should go into wicket itself, i can tell you that the part where you merge the files by listing them out upfront is probably not going to make it in because it breaks encapsulation... -igor On Thu, Aug 28, 2008 at 2:59 AM, Stefan Fußenegger <[EMAIL PROTECTED]> wrote: I just finished the 4th and last entry of my series "Wicket Interface Speed-Up" on my blog. To give a short summary: I investigated one of my apps with YSlow and started optimizing it's interface rendering speed [1]. Especially Wicket's way of handling resources, i.e. JS and CSS files, causes interfaces to load rather slowly. In my articles, I explain how to modify the cache interval [2], how to mount resources with a version (e.g. /css/all-1234.css) in order to use aggressive client-side caching (e.g. resources expire after a year) [3]. Finally, I show how to merge resources at application startup (using a class classed MergedResourceStream) to reduce the number of resources a client has to download [4], including code). I was able to increase interface loading times considerably, so it's surely worth a look. I feel that it would also be worth to discuss, whether this work could be part of upcoming Wicket versions. For the time being I'd like to make the code attached to [4] a wicketstuff project - sfussenegger needs commit access ;) - and wait for your feedback. The links: [1] http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up.html Wicket Interface Speed-Up [2] http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-modifying.html Wicket Interface Speed-Up: Modifying Expires and Cache-Control Headers [3] http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-caching.html Wicket Interface Speed-Up: Caching Resources Forever [4] http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-merging.html Wicket Interface Speed-Up: Merging Resources for Fewer HTTP Requests - --- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- View this message in context: http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19197540.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - --- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- View this message in context: http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19214276.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Discussion on "Wicket Interface Speed-Up"
Okay, sorry, you're right. Too bad, I didn't ever stumble upon this option. However, changing filename instead of using query string has certain advantages, see http://www.stevesouders.com/blog/2008/08/23/revving-filenames-dont-use-querystring/ Furthermore, setting this option does not effect expires or cache-control headers. still only one hour, which is far from being aggressive. If you want to change that, you'll still have to explicitly mount all resources with your desired cache duration. Johan suggested (comment on http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-modifying.html my second article ) "what i can do is make it a setting: IResourceSettings.getResourceCacheDuration()". If such a setting is available, using IResourceSettings.setAddLastModifiedTimeToResourceReferenceUrl(true) would make more sense. I still think though that this isn't enough and resources should get a focus in upcoming wicket versions. Some might argue, that resources shouldn't be served by Wicket at all, but I really don't like to use proxies, CDNs or whatever voodoo for low traffic web sites: server-side performance isn't an issue there while client-side performance is. regards Peter Ertl wrote: > > That's not true. > > this settings will generate urls like: > >/resources/[package+class]/javascript.js?lm=[lastmodified] > > read it again : "add Last Modified Time To Resource Reference Url" > >>> getApplication >>> ().getResourceSettings >>> ().setAddLastModifiedTimeToResourceReferenceUrl(true)?? > > It will not sent the "LastModified" header as you think. > > So whenever the resource changes the url changes, too. > > Try it out and see :-) > > I did test it in Firefox. There will be no "IfModified" requests from > the browser. > > Everything will be completely cached in the browser until the resource > has changed. > > Cheers > Peter > > > Am 29.08.2008 um 08:17 schrieb Stefan Fußenegger: > >> >> honestly, no, I didn't. however, using last modified times still >> results in >> an HTTP request and a "304 Not Modified" reply. better than nothing, >> but >> client-side caching is still preferable. >> >> regards >> >> >> Peter Ertl wrote: >>> >>> @stefan: did you take into account >>> >>> >>> getApplication >>> ().getResourceSettings >>> ().setAddLastModifiedTimeToResourceReferenceUrl(true)?? >>> >>> Cheers >>> Peter >>> >>> >>> Am 28.08.2008 um 18:20 schrieb Igor Vaynberg: >>> sfussenegger now has access to wicketstuff... i dont know which parts should go into wicket itself, i can tell you that the part where you merge the files by listing them out upfront is probably not going to make it in because it breaks encapsulation... -igor On Thu, Aug 28, 2008 at 2:59 AM, Stefan Fußenegger <[EMAIL PROTECTED]> wrote: > > I just finished the 4th and last entry of my series "Wicket > Interface > Speed-Up" on my blog. To give a short summary: I investigated one > of my apps > with YSlow and started optimizing it's interface rendering speed > [1]. > Especially Wicket's way of handling resources, i.e. JS and CSS > files, causes > interfaces to load rather slowly. In my articles, I explain how to > modify > the cache interval [2], how to mount resources with a version (e.g. > /css/all-1234.css) in order to use aggressive client-side caching > (e.g. > resources expire after a year) [3]. Finally, I show how to merge > resources > at application startup (using a class classed MergedResourceStream) > to > reduce the number of resources a client has to download [4], > including > code). I was able to increase interface loading times considerably, > so it's > surely worth a look. > > I feel that it would also be worth to discuss, whether this work > could be > part of upcoming Wicket versions. For the time being I'd like to > make the > code attached to [4] a wicketstuff project - sfussenegger needs > commit > access ;) - and wait for your feedback. > > The links: > [1] > http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up.html > Wicket Interface Speed-Up > [2] > http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-modifying.html > Wicket Interface Speed-Up: Modifying Expires and Cache-Control > Headers > [3] > http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-caching.html > Wicket Interface Speed-Up: Caching Resources Forever > [4] > http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-merging.html > Wicket Interface Speed-Up: Merging Resources for Fewer HTTP > Requests > > - > --- > Stefan Fußenegger > http://talk-on-tech.blogspot.com // looking for a nicer domain ;) > -- > View this message in context: > http://www.nabble.com/Discussion-on-
Re: Discussion on "Wicket Interface Speed-Up"
I totally agree that having the version in the filename and not in the query string will be a-lot-better. Just wanted to point you to that option so you can include it in your excellent analysis on caching *thanks* :-) People can use that option right now and get a more decent version later (e.g. your versioned resource filenames, which is the *correct* way) Resources need some more love in wicket 1.5 - full ack! Cheers Peter Am 29.08.2008 um 09:24 schrieb Stefan Fußenegger: Okay, sorry, you're right. Too bad, I didn't ever stumble upon this option. However, changing filename instead of using query string has certain advantages, see http://www.stevesouders.com/blog/2008/08/23/revving-filenames-dont-use-querystring/ Furthermore, setting this option does not effect expires or cache- control headers. still only one hour, which is far from being aggressive. If you want to change that, you'll still have to explicitly mount all resources with your desired cache duration. Johan suggested (comment on http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-modifying.html my second article ) "what i can do is make it a setting: IResourceSettings.getResourceCacheDuration()". If such a setting is available, using IResourceSettings.setAddLastModifiedTimeToResourceReferenceUrl(true) would make more sense. I still think though that this isn't enough and resources should get a focus in upcoming wicket versions. Some might argue, that resources shouldn't be served by Wicket at all, but I really don't like to use proxies, CDNs or whatever voodoo for low traffic web sites: server-side performance isn't an issue there while client-side performance is. regards Peter Ertl wrote: That's not true. this settings will generate urls like: /resources/[package+class]/javascript.js?lm=[lastmodified] read it again : "add Last Modified Time To Resource Reference Url" getApplication ().getResourceSettings ().setAddLastModifiedTimeToResourceReferenceUrl(true)?? It will not sent the "LastModified" header as you think. So whenever the resource changes the url changes, too. Try it out and see :-) I did test it in Firefox. There will be no "IfModified" requests from the browser. Everything will be completely cached in the browser until the resource has changed. Cheers Peter Am 29.08.2008 um 08:17 schrieb Stefan Fußenegger: honestly, no, I didn't. however, using last modified times still results in an HTTP request and a "304 Not Modified" reply. better than nothing, but client-side caching is still preferable. regards Peter Ertl wrote: @stefan: did you take into account getApplication ().getResourceSettings ().setAddLastModifiedTimeToResourceReferenceUrl(true)?? Cheers Peter Am 28.08.2008 um 18:20 schrieb Igor Vaynberg: sfussenegger now has access to wicketstuff... i dont know which parts should go into wicket itself, i can tell you that the part where you merge the files by listing them out upfront is probably not going to make it in because it breaks encapsulation... -igor On Thu, Aug 28, 2008 at 2:59 AM, Stefan Fußenegger <[EMAIL PROTECTED]> wrote: I just finished the 4th and last entry of my series "Wicket Interface Speed-Up" on my blog. To give a short summary: I investigated one of my apps with YSlow and started optimizing it's interface rendering speed [1]. Especially Wicket's way of handling resources, i.e. JS and CSS files, causes interfaces to load rather slowly. In my articles, I explain how to modify the cache interval [2], how to mount resources with a version (e.g. /css/all-1234.css) in order to use aggressive client-side caching (e.g. resources expire after a year) [3]. Finally, I show how to merge resources at application startup (using a class classed MergedResourceStream) to reduce the number of resources a client has to download [4], including code). I was able to increase interface loading times considerably, so it's surely worth a look. I feel that it would also be worth to discuss, whether this work could be part of upcoming Wicket versions. For the time being I'd like to make the code attached to [4] a wicketstuff project - sfussenegger needs commit access ;) - and wait for your feedback. The links: [1] http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up.html Wicket Interface Speed-Up [2] http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-modifying.html Wicket Interface Speed-Up: Modifying Expires and Cache-Control Headers [3] http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-caching.html Wicket Interface Speed-Up: Caching Resources Forever [4] http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-merging.html Wicket Interface Speed-Up: Merging Resources for Fewer HTTP Requests - --- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- View this message in context: http://www.nabble.com/Discussion-on
Re: Discussion on "Wicket Interface Speed-Up"
I thing we should look at what that append to url does, because i dont like the query string either, i also rather have it in the url path itself. Also such a resource cache duration can be added. But i also rather have it configured by resoure(reference) like HeaderContributor.getCSSResourceReference('my.css',cachetime,urlmod) Johan On 8/29/08, Stefan Fußenegger <[EMAIL PROTECTED]> wrote: > > Okay, sorry, you're right. Too bad, I didn't ever stumble upon this option. > However, changing filename instead of using query string has certain > advantages, see > http://www.stevesouders.com/blog/2008/08/23/revving-filenames-dont-use-querystring/ > > Furthermore, setting this option does not effect expires or cache-control > headers. still only one hour, which is far from being aggressive. If you > want to change that, you'll still have to explicitly mount all resources > with your desired cache duration. > > Johan suggested (comment on > http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-modifying.html > my second article ) "what i can do is make it a setting: > IResourceSettings.getResourceCacheDuration()". If such a setting is > available, using > IResourceSettings.setAddLastModifiedTimeToResourceReferenceUrl(true) would > make more sense. > > I still think though that this isn't enough and resources should get a focus > in upcoming wicket versions. Some might argue, that resources shouldn't be > served by Wicket at all, but I really don't like to use proxies, CDNs or > whatever voodoo for low traffic web sites: server-side performance isn't an > issue there while client-side performance is. > > regards > > > Peter Ertl wrote: >> >> That's not true. >> >> this settings will generate urls like: >> >>/resources/[package+class]/javascript.js?lm=[lastmodified] >> >> read it again : "add Last Modified Time To Resource Reference Url" >> getApplication ().getResourceSettings ().setAddLastModifiedTimeToResourceReferenceUrl(true)?? >> >> It will not sent the "LastModified" header as you think. >> >> So whenever the resource changes the url changes, too. >> >> Try it out and see :-) >> >> I did test it in Firefox. There will be no "IfModified" requests from >> the browser. >> >> Everything will be completely cached in the browser until the resource >> has changed. >> >> Cheers >> Peter >> >> >> Am 29.08.2008 um 08:17 schrieb Stefan Fußenegger: >> >>> >>> honestly, no, I didn't. however, using last modified times still >>> results in >>> an HTTP request and a "304 Not Modified" reply. better than nothing, >>> but >>> client-side caching is still preferable. >>> >>> regards >>> >>> >>> Peter Ertl wrote: @stefan: did you take into account getApplication ().getResourceSettings ().setAddLastModifiedTimeToResourceReferenceUrl(true)?? Cheers Peter Am 28.08.2008 um 18:20 schrieb Igor Vaynberg: > sfussenegger now has access to wicketstuff... > > i dont know which parts should go into wicket itself, i can tell you > that the part where you merge the files by listing them out > upfront is > probably not going to make it in because it breaks encapsulation... > > -igor > > On Thu, Aug 28, 2008 at 2:59 AM, Stefan Fußenegger > <[EMAIL PROTECTED]> wrote: >> >> I just finished the 4th and last entry of my series "Wicket >> Interface >> Speed-Up" on my blog. To give a short summary: I investigated one >> of my apps >> with YSlow and started optimizing it's interface rendering speed >> [1]. >> Especially Wicket's way of handling resources, i.e. JS and CSS >> files, causes >> interfaces to load rather slowly. In my articles, I explain how to >> modify >> the cache interval [2], how to mount resources with a version (e.g. >> /css/all-1234.css) in order to use aggressive client-side caching >> (e.g. >> resources expire after a year) [3]. Finally, I show how to merge >> resources >> at application startup (using a class classed MergedResourceStream) >> to >> reduce the number of resources a client has to download [4], >> including >> code). I was able to increase interface loading times considerably, >> so it's >> surely worth a look. >> >> I feel that it would also be worth to discuss, whether this work >> could be >> part of upcoming Wicket versions. For the time being I'd like to >> make the >> code attached to [4] a wicketstuff project - sfussenegger needs >> commit >> access ;) - and wait for your feedback. >> >> The links: >> [1] >> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up.html >> Wicket Interface Speed-Up >> [2] >> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-modifying.html >> Wicket Interface Speed-Up: Modifying Expires and Cache-Control >> Headers >> [3] >> http:/
Re: Discussion on "Wicket Interface Speed-Up"
On Fri, Aug 29, 2008 at 9:41 AM, Peter Ertl <[EMAIL PROTECTED]> wrote: > I totally agree that having the version in the filename and not in the query > string will be a-lot-better. > > Just wanted to point you to that option so you can include it in your > excellent analysis on caching *thanks* :-) > > People can use that option right now and get a more decent version later > (e.g. your versioned resource filenames, which is the *correct* way) > > Resources need some more love in wicket 1.5 - full ack! > And they are going to get it :) Resources are going to be much simpler in 1.5 - current code is too tangled and ambiguous. -Matej > Cheers > Peter > > > Am 29.08.2008 um 09:24 schrieb Stefan Fußenegger: > >> >> Okay, sorry, you're right. Too bad, I didn't ever stumble upon this >> option. >> However, changing filename instead of using query string has certain >> advantages, see >> >> http://www.stevesouders.com/blog/2008/08/23/revving-filenames-dont-use-querystring/ >> >> Furthermore, setting this option does not effect expires or cache-control >> headers. still only one hour, which is far from being aggressive. If you >> want to change that, you'll still have to explicitly mount all resources >> with your desired cache duration. >> >> Johan suggested (comment on >> >> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-modifying.html >> my second article ) "what i can do is make it a setting: >> IResourceSettings.getResourceCacheDuration()". If such a setting is >> available, using >> IResourceSettings.setAddLastModifiedTimeToResourceReferenceUrl(true) would >> make more sense. >> >> I still think though that this isn't enough and resources should get a >> focus >> in upcoming wicket versions. Some might argue, that resources shouldn't be >> served by Wicket at all, but I really don't like to use proxies, CDNs or >> whatever voodoo for low traffic web sites: server-side performance isn't >> an >> issue there while client-side performance is. >> >> regards >> >> >> Peter Ertl wrote: >>> >>> That's not true. >>> >>> this settings will generate urls like: >>> >>> /resources/[package+class]/javascript.js?lm=[lastmodified] >>> >>> read it again : "add Last Modified Time To Resource Reference Url" >>> > getApplication > ().getResourceSettings > ().setAddLastModifiedTimeToResourceReferenceUrl(true)?? >>> >>> It will not sent the "LastModified" header as you think. >>> >>> So whenever the resource changes the url changes, too. >>> >>> Try it out and see :-) >>> >>> I did test it in Firefox. There will be no "IfModified" requests from >>> the browser. >>> >>> Everything will be completely cached in the browser until the resource >>> has changed. >>> >>> Cheers >>> Peter >>> >>> >>> Am 29.08.2008 um 08:17 schrieb Stefan Fußenegger: >>> honestly, no, I didn't. however, using last modified times still results in an HTTP request and a "304 Not Modified" reply. better than nothing, but client-side caching is still preferable. regards Peter Ertl wrote: > > @stefan: did you take into account > > > getApplication > ().getResourceSettings > ().setAddLastModifiedTimeToResourceReferenceUrl(true)?? > > Cheers > Peter > > > Am 28.08.2008 um 18:20 schrieb Igor Vaynberg: > >> sfussenegger now has access to wicketstuff... >> >> i dont know which parts should go into wicket itself, i can tell you >> that the part where you merge the files by listing them out >> upfront is >> probably not going to make it in because it breaks encapsulation... >> >> -igor >> >> On Thu, Aug 28, 2008 at 2:59 AM, Stefan Fußenegger >> <[EMAIL PROTECTED]> wrote: >>> >>> I just finished the 4th and last entry of my series "Wicket >>> Interface >>> Speed-Up" on my blog. To give a short summary: I investigated one >>> of my apps >>> with YSlow and started optimizing it's interface rendering speed >>> [1]. >>> Especially Wicket's way of handling resources, i.e. JS and CSS >>> files, causes >>> interfaces to load rather slowly. In my articles, I explain how to >>> modify >>> the cache interval [2], how to mount resources with a version (e.g. >>> /css/all-1234.css) in order to use aggressive client-side caching >>> (e.g. >>> resources expire after a year) [3]. Finally, I show how to merge >>> resources >>> at application startup (using a class classed MergedResourceStream) >>> to >>> reduce the number of resources a client has to download [4], >>> including >>> code). I was able to increase interface loading times considerably, >>> so it's >>> surely worth a look. >>> >>> I feel that it would also be worth to discuss, whether this work >>> could be >>> part of upcoming Wicket versions. For the time being I'd like to >>> make the >>> code attached to [4] a wi
Re: Discussion on "Wicket Interface Speed-Up"
I would love to see an approach where Wicket itself tries to determine a version. If a version is available, wicket would than add it to the filename and use an aggressive caching duration, e.g. 1 year. (no version, no caching) Additionally, what I currently don't like is that resource creation isn't flexible at all. The current approach (ResourceReference.newResource() called in ResourceReference.bind(Application) if resource isn't already bound) doesn't allow to change default resources, as one can't change the used ResourceReference type. I'd suggest - just thinking aloud right now - to change the current implementation to either Application.get().getResourceFactory().newResource(ResourceReference) instead of ResourceReference.newResource() or to make the ResourceReference type used within HeaderContributor.for...(..) changeable: response.renderJavascriptReference(new JavascriptResourceReference(scope, path)); // current response.renderJavascriptReference(Application.get().getResourceFactory().newJavascriptResourceReference(scope, path)); both approaches would allow to customize resource creation. regards Johan Compagner wrote: > > I thing we should look at what that append to url does, because i dont > like the query string either, i also rather have it in the url path > itself. > > Also such a resource cache duration can be added. But i also rather > have it configured by resoure(reference) like > > HeaderContributor.getCSSResourceReference('my.css',cachetime,urlmod) > > Johan > > On 8/29/08, Stefan Fußenegger <[EMAIL PROTECTED]> wrote: >> >> Okay, sorry, you're right. Too bad, I didn't ever stumble upon this >> option. >> However, changing filename instead of using query string has certain >> advantages, see >> http://www.stevesouders.com/blog/2008/08/23/revving-filenames-dont-use-querystring/ >> >> Furthermore, setting this option does not effect expires or cache-control >> headers. still only one hour, which is far from being aggressive. If you >> want to change that, you'll still have to explicitly mount all resources >> with your desired cache duration. >> >> Johan suggested (comment on >> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-modifying.html >> my second article ) "what i can do is make it a setting: >> IResourceSettings.getResourceCacheDuration()". If such a setting is >> available, using >> IResourceSettings.setAddLastModifiedTimeToResourceReferenceUrl(true) >> would >> make more sense. >> >> I still think though that this isn't enough and resources should get a >> focus >> in upcoming wicket versions. Some might argue, that resources shouldn't >> be >> served by Wicket at all, but I really don't like to use proxies, CDNs or >> whatever voodoo for low traffic web sites: server-side performance isn't >> an >> issue there while client-side performance is. >> >> regards >> >> >> Peter Ertl wrote: >>> >>> That's not true. >>> >>> this settings will generate urls like: >>> >>>/resources/[package+class]/javascript.js?lm=[lastmodified] >>> >>> read it again : "add Last Modified Time To Resource Reference Url" >>> > getApplication > ().getResourceSettings > ().setAddLastModifiedTimeToResourceReferenceUrl(true)?? >>> >>> It will not sent the "LastModified" header as you think. >>> >>> So whenever the resource changes the url changes, too. >>> >>> Try it out and see :-) >>> >>> I did test it in Firefox. There will be no "IfModified" requests from >>> the browser. >>> >>> Everything will be completely cached in the browser until the resource >>> has changed. >>> >>> Cheers >>> Peter >>> >>> >>> Am 29.08.2008 um 08:17 schrieb Stefan Fußenegger: >>> honestly, no, I didn't. however, using last modified times still results in an HTTP request and a "304 Not Modified" reply. better than nothing, but client-side caching is still preferable. regards Peter Ertl wrote: > > @stefan: did you take into account > > > getApplication > ().getResourceSettings > ().setAddLastModifiedTimeToResourceReferenceUrl(true)?? > > Cheers > Peter > > > Am 28.08.2008 um 18:20 schrieb Igor Vaynberg: > >> sfussenegger now has access to wicketstuff... >> >> i dont know which parts should go into wicket itself, i can tell you >> that the part where you merge the files by listing them out >> upfront is >> probably not going to make it in because it breaks encapsulation... >> >> -igor >> >> On Thu, Aug 28, 2008 at 2:59 AM, Stefan Fußenegger >> <[EMAIL PROTECTED]> wrote: >>> >>> I just finished the 4th and last entry of my series "Wicket >>> Interface >>> Speed-Up" on my blog. To give a short summary: I investigated one >>> of my apps >>> with YSlow and started optimizing it's interface rendering speed >>> [1]. >>> Especially Wicket's way of handling resources, i.e. JS and CSS >>> files,
Re: Discussion on "Wicket Interface Speed-Up"
Sounds promising ... and little mysterious ;) Any concrete plans/ideas so far? Matej Knopp-2 wrote: > > On Fri, Aug 29, 2008 at 9:41 AM, Peter Ertl <[EMAIL PROTECTED]> wrote: >> I totally agree that having the version in the filename and not in the >> query >> string will be a-lot-better. >> >> Just wanted to point you to that option so you can include it in your >> excellent analysis on caching *thanks* :-) >> >> People can use that option right now and get a more decent version later >> (e.g. your versioned resource filenames, which is the *correct* way) >> >> Resources need some more love in wicket 1.5 - full ack! >> > And they are going to get it :) Resources are going to be much simpler > in 1.5 - current code is too tangled and ambiguous. > > -Matej >> Cheers >> Peter >> >> >> Am 29.08.2008 um 09:24 schrieb Stefan Fußenegger: >> >>> >>> Okay, sorry, you're right. Too bad, I didn't ever stumble upon this >>> option. >>> However, changing filename instead of using query string has certain >>> advantages, see >>> >>> http://www.stevesouders.com/blog/2008/08/23/revving-filenames-dont-use-querystring/ >>> >>> Furthermore, setting this option does not effect expires or >>> cache-control >>> headers. still only one hour, which is far from being aggressive. If you >>> want to change that, you'll still have to explicitly mount all resources >>> with your desired cache duration. >>> >>> Johan suggested (comment on >>> >>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-modifying.html >>> my second article ) "what i can do is make it a setting: >>> IResourceSettings.getResourceCacheDuration()". If such a setting is >>> available, using >>> IResourceSettings.setAddLastModifiedTimeToResourceReferenceUrl(true) >>> would >>> make more sense. >>> >>> I still think though that this isn't enough and resources should get a >>> focus >>> in upcoming wicket versions. Some might argue, that resources shouldn't >>> be >>> served by Wicket at all, but I really don't like to use proxies, CDNs or >>> whatever voodoo for low traffic web sites: server-side performance isn't >>> an >>> issue there while client-side performance is. >>> >>> regards >>> >>> >>> Peter Ertl wrote: That's not true. this settings will generate urls like: /resources/[package+class]/javascript.js?lm=[lastmodified] read it again : "add Last Modified Time To Resource Reference Url" >> getApplication >> ().getResourceSettings >> ().setAddLastModifiedTimeToResourceReferenceUrl(true)?? It will not sent the "LastModified" header as you think. So whenever the resource changes the url changes, too. Try it out and see :-) I did test it in Firefox. There will be no "IfModified" requests from the browser. Everything will be completely cached in the browser until the resource has changed. Cheers Peter Am 29.08.2008 um 08:17 schrieb Stefan Fußenegger: > > honestly, no, I didn't. however, using last modified times still > results in > an HTTP request and a "304 Not Modified" reply. better than nothing, > but > client-side caching is still preferable. > > regards > > > Peter Ertl wrote: >> >> @stefan: did you take into account >> >> >> getApplication >> ().getResourceSettings >> ().setAddLastModifiedTimeToResourceReferenceUrl(true)?? >> >> Cheers >> Peter >> >> >> Am 28.08.2008 um 18:20 schrieb Igor Vaynberg: >> >>> sfussenegger now has access to wicketstuff... >>> >>> i dont know which parts should go into wicket itself, i can tell you >>> that the part where you merge the files by listing them out >>> upfront is >>> probably not going to make it in because it breaks encapsulation... >>> >>> -igor >>> >>> On Thu, Aug 28, 2008 at 2:59 AM, Stefan Fußenegger >>> <[EMAIL PROTECTED]> wrote: I just finished the 4th and last entry of my series "Wicket Interface Speed-Up" on my blog. To give a short summary: I investigated one of my apps with YSlow and started optimizing it's interface rendering speed [1]. Especially Wicket's way of handling resources, i.e. JS and CSS files, causes interfaces to load rather slowly. In my articles, I explain how to modify the cache interval [2], how to mount resources with a version (e.g. /css/all-1234.css) in order to use aggressive client-side caching (e.g. resources expire after a year) [3]. Finally, I show how to merge resources at application startup (using a class classed MergedResourceStream) to reduce the number of resources a client has to download [4], including code). I was able to increase interface loading times considerab
Re: Discussion on "Wicket Interface Speed-Up"
Code is now available through wicketsuff: https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-merged-resources/ wicketstuff-merged-resources and https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-merged-resources-examples/ wicketstuff-merged-resources-examples Now I want to make it available through http://wicketstuff.org/maven/repository/. I therefore registered at wicketstuff.org/teamcity (sfussenegger). What's next? Stefan Fußenegger wrote: > > I just finished the 4th and last entry of my series "Wicket Interface > Speed-Up" on my blog. To give a short summary: I investigated one of my > apps with YSlow and started optimizing it's interface rendering speed [1]. > Especially Wicket's way of handling resources, i.e. JS and CSS files, > causes interfaces to load rather slowly. In my articles, I explain how to > modify the cache interval [2], how to mount resources with a version (e.g. > /css/all-1234.css) in order to use aggressive client-side caching (e.g. > resources expire after a year) [3]. Finally, I show how to merge resources > at application startup (using a class classed MergedResourceStream) to > reduce the number of resources a client has to download [4], including > code). I was able to increase interface loading times considerably, so > it's surely worth a look. > > I feel that it would also be worth to discuss, whether this work could be > part of upcoming Wicket versions. For the time being I'd like to make the > code attached to [4] a wicketstuff project - sfussenegger needs commit > access ;) - and wait for your feedback. > > The links: > [1] > http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up.html > Wicket Interface Speed-Up > [2] > http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-modifying.html > Wicket Interface Speed-Up: Modifying Expires and Cache-Control Headers > [3] > http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-caching.html > Wicket Interface Speed-Up: Caching Resources Forever > [4] > http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-merging.html > Wicket Interface Speed-Up: Merging Resources for Fewer HTTP Requests > - --- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- View this message in context: http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19216657.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Discussion on "Wicket Interface Speed-Up"
Here is a first patch for the RevisionVersionProvider: Index: src/main/java/org/wicketstuff/mergedresources/versioning/RevisionVersionProvider.java === --- src/main/java/org/wicketstuff/mergedresources/versioning/RevisionVersionProvider.java (revision 4147) +++ src/main/java/org/wicketstuff/mergedresources/versioning/RevisionVersionProvider.java (working copy) @@ -15,7 +15,7 @@ public int getVersion(final Class scope, final String fileName) throws VersionException { final String file = getResourcePath(scope, fileName); - final InputStream in = ClassLoader.getSystemResourceAsStream(file); + final InputStream in = RevisionVersionProvider.class.getClassLoader().getResourceAsStream(file); if (in == null) { throw new VersionException(scope, fileName, "can't find " + file); } ClassLoader.getSystemResourceAsStream in my deployment enviroment, it always returned null for classpath resources. Using the RevisionVersionProvider classloader works fine. Let me know where I should post further patches etc. Jörn On Fri, Aug 29, 2008 at 11:29 AM, Stefan Fußenegger <[EMAIL PROTECTED]> wrote: > > Code is now available through wicketsuff: > https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-merged-resources/ > wicketstuff-merged-resources and > https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-merged-resources-examples/ > wicketstuff-merged-resources-examples > > Now I want to make it available through > http://wicketstuff.org/maven/repository/. I therefore registered at > wicketstuff.org/teamcity (sfussenegger). What's next? > > > Stefan Fußenegger wrote: >> >> I just finished the 4th and last entry of my series "Wicket Interface >> Speed-Up" on my blog. To give a short summary: I investigated one of my >> apps with YSlow and started optimizing it's interface rendering speed [1]. >> Especially Wicket's way of handling resources, i.e. JS and CSS files, >> causes interfaces to load rather slowly. In my articles, I explain how to >> modify the cache interval [2], how to mount resources with a version (e.g. >> /css/all-1234.css) in order to use aggressive client-side caching (e.g. >> resources expire after a year) [3]. Finally, I show how to merge resources >> at application startup (using a class classed MergedResourceStream) to >> reduce the number of resources a client has to download [4], including >> code). I was able to increase interface loading times considerably, so >> it's surely worth a look. >> >> I feel that it would also be worth to discuss, whether this work could be >> part of upcoming Wicket versions. For the time being I'd like to make the >> code attached to [4] a wicketstuff project - sfussenegger needs commit >> access ;) - and wait for your feedback. >> >> The links: >> [1] >> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up.html >> Wicket Interface Speed-Up >> [2] >> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-modifying.html >> Wicket Interface Speed-Up: Modifying Expires and Cache-Control Headers >> [3] >> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-caching.html >> Wicket Interface Speed-Up: Caching Resources Forever >> [4] >> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-merging.html >> Wicket Interface Speed-Up: Merging Resources for Fewer HTTP Requests >> > > > - > --- > Stefan Fußenegger > http://talk-on-tech.blogspot.com // looking for a nicer domain ;) > -- > View this message in context: > http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19216657.html > Sent from the Wicket - User mailing list archive at Nabble.com. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: Discussion on "Wicket Interface Speed-Up"
why don't you open up an issue in JIRA? Am 29.08.2008 um 12:22 schrieb Jörn Zaefferer: Here is a first patch for the RevisionVersionProvider: Index: src/main/java/org/wicketstuff/mergedresources/versioning/ RevisionVersionProvider.java === --- src/main/java/org/wicketstuff/mergedresources/versioning/ RevisionVersionProvider.java (revision 4147) +++ src/main/java/org/wicketstuff/mergedresources/versioning/ RevisionVersionProvider.java (working copy) @@ -15,7 +15,7 @@ public int getVersion(final Class scope, final String fileName) throws VersionException { final String file = getResourcePath(scope, fileName); - final InputStream in = ClassLoader.getSystemResourceAsStream(file); + final InputStream in = RevisionVersionProvider .class.getClassLoader().getResourceAsStream(file); if (in == null) { throw new VersionException(scope, fileName, "can't find " + file); } ClassLoader.getSystemResourceAsStream in my deployment enviroment, it always returned null for classpath resources. Using the RevisionVersionProvider classloader works fine. Let me know where I should post further patches etc. Jörn On Fri, Aug 29, 2008 at 11:29 AM, Stefan Fußenegger <[EMAIL PROTECTED]> wrote: Code is now available through wicketsuff: https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-merged-resources/ wicketstuff-merged-resources and https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-merged-resources-examples/ wicketstuff-merged-resources-examples Now I want to make it available through http://wicketstuff.org/maven/repository/. I therefore registered at wicketstuff.org/teamcity (sfussenegger). What's next? Stefan Fußenegger wrote: I just finished the 4th and last entry of my series "Wicket Interface Speed-Up" on my blog. To give a short summary: I investigated one of my apps with YSlow and started optimizing it's interface rendering speed [1]. Especially Wicket's way of handling resources, i.e. JS and CSS files, causes interfaces to load rather slowly. In my articles, I explain how to modify the cache interval [2], how to mount resources with a version (e.g. /css/all-1234.css) in order to use aggressive client-side caching (e.g. resources expire after a year) [3]. Finally, I show how to merge resources at application startup (using a class classed MergedResourceStream) to reduce the number of resources a client has to download [4], including code). I was able to increase interface loading times considerably, so it's surely worth a look. I feel that it would also be worth to discuss, whether this work could be part of upcoming Wicket versions. For the time being I'd like to make the code attached to [4] a wicketstuff project - sfussenegger needs commit access ;) - and wait for your feedback. The links: [1] http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up.html Wicket Interface Speed-Up [2] http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-modifying.html Wicket Interface Speed-Up: Modifying Expires and Cache-Control Headers [3] http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-caching.html Wicket Interface Speed-Up: Caching Resources Forever [4] http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-merging.html Wicket Interface Speed-Up: Merging Resources for Fewer HTTP Requests - --- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- View this message in context: http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19216657.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Discussion on "Wicket Interface Speed-Up"
Good point, I forgot that wicketstuff has its own JIRA installation. Though the entry for the project is missing. Let me know once its there, and I'll create the report. Jörn On Fri, Aug 29, 2008 at 12:26 PM, Peter Ertl <[EMAIL PROTECTED]> wrote: > why don't you open up an issue in JIRA? > > > Am 29.08.2008 um 12:22 schrieb Jörn Zaefferer: > >> Here is a first patch for the RevisionVersionProvider: >> >> Index: >> src/main/java/org/wicketstuff/mergedresources/versioning/RevisionVersionProvider.java >> === >> --- >> src/main/java/org/wicketstuff/mergedresources/versioning/RevisionVersionProvider.java >>(revision >> 4147) >> +++ >> src/main/java/org/wicketstuff/mergedresources/versioning/RevisionVersionProvider.java >>(working >> copy) >> @@ -15,7 +15,7 @@ >> >>public int getVersion(final Class scope, final String fileName) >> throws VersionException { >>final String file = getResourcePath(scope, fileName); >> - final InputStream in = >> ClassLoader.getSystemResourceAsStream(file); >> + final InputStream in = >> RevisionVersionProvider.class.getClassLoader().getResourceAsStream(file); >>if (in == null) { >>throw new VersionException(scope, fileName, "can't >> find " + file); >>} >> >> >> ClassLoader.getSystemResourceAsStream in my deployment enviroment, it >> always returned null for classpath resources. Using the >> RevisionVersionProvider classloader works fine. >> >> Let me know where I should post further patches etc. >> >> Jörn >> >> On Fri, Aug 29, 2008 at 11:29 AM, Stefan Fußenegger >> <[EMAIL PROTECTED]> wrote: >>> >>> Code is now available through wicketsuff: >>> >>> https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-merged-resources/ >>> wicketstuff-merged-resources and >>> >>> https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-merged-resources-examples/ >>> wicketstuff-merged-resources-examples >>> >>> Now I want to make it available through >>> http://wicketstuff.org/maven/repository/. I therefore registered at >>> wicketstuff.org/teamcity (sfussenegger). What's next? >>> >>> >>> Stefan Fußenegger wrote: I just finished the 4th and last entry of my series "Wicket Interface Speed-Up" on my blog. To give a short summary: I investigated one of my apps with YSlow and started optimizing it's interface rendering speed [1]. Especially Wicket's way of handling resources, i.e. JS and CSS files, causes interfaces to load rather slowly. In my articles, I explain how to modify the cache interval [2], how to mount resources with a version (e.g. /css/all-1234.css) in order to use aggressive client-side caching (e.g. resources expire after a year) [3]. Finally, I show how to merge resources at application startup (using a class classed MergedResourceStream) to reduce the number of resources a client has to download [4], including code). I was able to increase interface loading times considerably, so it's surely worth a look. I feel that it would also be worth to discuss, whether this work could be part of upcoming Wicket versions. For the time being I'd like to make the code attached to [4] a wicketstuff project - sfussenegger needs commit access ;) - and wait for your feedback. The links: [1] http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up.html Wicket Interface Speed-Up [2] http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-modifying.html Wicket Interface Speed-Up: Modifying Expires and Cache-Control Headers [3] http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-caching.html Wicket Interface Speed-Up: Caching Resources Forever [4] http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-merging.html Wicket Interface Speed-Up: Merging Resources for Fewer HTTP Requests >>> >>> >>> - >>> --- >>> Stefan Fußenegger >>> http://talk-on-tech.blogspot.com // looking for a nicer domain ;) >>> -- >>> View this message in context: >>> http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19216657.html >>> Sent from the Wicket - User mailing list archive at Nabble.com. >>> >>> >>> - >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: Discussion on "Wicket Interface Speed-Up"
just applied your patch could somebody please create wicketstuff-merged-resources in JIRA and teamcity? Jörn Zaefferer-2 wrote: > > Here is a first patch for the RevisionVersionProvider: > > Index: > src/main/java/org/wicketstuff/mergedresources/versioning/RevisionVersionProvider.java > === > --- > src/main/java/org/wicketstuff/mergedresources/versioning/RevisionVersionProvider.java > (revision > 4147) > +++ > src/main/java/org/wicketstuff/mergedresources/versioning/RevisionVersionProvider.java > (working > copy) > @@ -15,7 +15,7 @@ > > public int getVersion(final Class scope, final String fileName) > throws VersionException { > final String file = getResourcePath(scope, fileName); > - final InputStream in = > ClassLoader.getSystemResourceAsStream(file); > + final InputStream in = > RevisionVersionProvider.class.getClassLoader().getResourceAsStream(file); > if (in == null) { > throw new VersionException(scope, fileName, "can't find > " + file); > } > > > ClassLoader.getSystemResourceAsStream in my deployment enviroment, it > always returned null for classpath resources. Using the > RevisionVersionProvider classloader works fine. > > Let me know where I should post further patches etc. > > Jörn > > On Fri, Aug 29, 2008 at 11:29 AM, Stefan Fußenegger > <[EMAIL PROTECTED]> wrote: >> >> Code is now available through wicketsuff: >> https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-merged-resources/ >> wicketstuff-merged-resources and >> https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-merged-resources-examples/ >> wicketstuff-merged-resources-examples >> >> Now I want to make it available through >> http://wicketstuff.org/maven/repository/. I therefore registered at >> wicketstuff.org/teamcity (sfussenegger). What's next? >> >> >> Stefan Fußenegger wrote: >>> >>> I just finished the 4th and last entry of my series "Wicket Interface >>> Speed-Up" on my blog. To give a short summary: I investigated one of my >>> apps with YSlow and started optimizing it's interface rendering speed >>> [1]. >>> Especially Wicket's way of handling resources, i.e. JS and CSS files, >>> causes interfaces to load rather slowly. In my articles, I explain how >>> to >>> modify the cache interval [2], how to mount resources with a version >>> (e.g. >>> /css/all-1234.css) in order to use aggressive client-side caching (e.g. >>> resources expire after a year) [3]. Finally, I show how to merge >>> resources >>> at application startup (using a class classed MergedResourceStream) to >>> reduce the number of resources a client has to download [4], including >>> code). I was able to increase interface loading times considerably, so >>> it's surely worth a look. >>> >>> I feel that it would also be worth to discuss, whether this work could >>> be >>> part of upcoming Wicket versions. For the time being I'd like to make >>> the >>> code attached to [4] a wicketstuff project - sfussenegger needs commit >>> access ;) - and wait for your feedback. >>> >>> The links: >>> [1] >>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up.html >>> Wicket Interface Speed-Up >>> [2] >>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-modifying.html >>> Wicket Interface Speed-Up: Modifying Expires and Cache-Control Headers >>> [3] >>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-caching.html >>> Wicket Interface Speed-Up: Caching Resources Forever >>> [4] >>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-merging.html >>> Wicket Interface Speed-Up: Merging Resources for Fewer HTTP Requests >>> >> >> >> - >> --- >> Stefan Fußenegger >> http://talk-on-tech.blogspot.com // looking for a nicer domain ;) >> -- >> View this message in context: >> http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19216657.html >> Sent from the Wicket - User mailing list archive at Nabble.com. >> >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > - --- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- View this message in context: http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19218353.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Discussion on "Wicket Interface Speed-Up"
wicketstuff-merged-resources is now available in JIRA: http://wicketstuff.org/jira/browse/WMR and from wicketstuff maven repo: wicket-snaps http://wicketstuff.org/maven/repository true true org.wicketstuff wicketstuff-merged-resources 1.3.4-SNAPSHOT i am also going to add a short wiki page at wicketstuff.org regards, Stefan Jörn Zaefferer-2 wrote: > > Good point, I forgot that wicketstuff has its own JIRA installation. > Though the entry for the project is missing. Let me know once its > there, and I'll create the report. > > Jörn > > On Fri, Aug 29, 2008 at 12:26 PM, Peter Ertl <[EMAIL PROTECTED]> wrote: >> why don't you open up an issue in JIRA? >> >> >> Am 29.08.2008 um 12:22 schrieb Jörn Zaefferer: >> >>> Here is a first patch for the RevisionVersionProvider: >>> >>> Index: >>> src/main/java/org/wicketstuff/mergedresources/versioning/RevisionVersionProvider.java >>> === >>> --- >>> src/main/java/org/wicketstuff/mergedresources/versioning/RevisionVersionProvider.java >>>(revision >>> 4147) >>> +++ >>> src/main/java/org/wicketstuff/mergedresources/versioning/RevisionVersionProvider.java >>>(working >>> copy) >>> @@ -15,7 +15,7 @@ >>> >>>public int getVersion(final Class scope, final String >>> fileName) >>> throws VersionException { >>>final String file = getResourcePath(scope, fileName); >>> - final InputStream in = >>> ClassLoader.getSystemResourceAsStream(file); >>> + final InputStream in = >>> RevisionVersionProvider.class.getClassLoader().getResourceAsStream(file); >>>if (in == null) { >>>throw new VersionException(scope, fileName, >>> "can't >>> find " + file); >>>} >>> >>> >>> ClassLoader.getSystemResourceAsStream in my deployment enviroment, it >>> always returned null for classpath resources. Using the >>> RevisionVersionProvider classloader works fine. >>> >>> Let me know where I should post further patches etc. >>> >>> Jörn >>> >>> On Fri, Aug 29, 2008 at 11:29 AM, Stefan Fußenegger >>> <[EMAIL PROTECTED]> wrote: Code is now available through wicketsuff: https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-merged-resources/ wicketstuff-merged-resources and https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-merged-resources-examples/ wicketstuff-merged-resources-examples Now I want to make it available through http://wicketstuff.org/maven/repository/. I therefore registered at wicketstuff.org/teamcity (sfussenegger). What's next? Stefan Fußenegger wrote: > > I just finished the 4th and last entry of my series "Wicket Interface > Speed-Up" on my blog. To give a short summary: I investigated one of > my > apps with YSlow and started optimizing it's interface rendering speed > [1]. > Especially Wicket's way of handling resources, i.e. JS and CSS files, > causes interfaces to load rather slowly. In my articles, I explain how > to > modify the cache interval [2], how to mount resources with a version > (e.g. > /css/all-1234.css) in order to use aggressive client-side caching > (e.g. > resources expire after a year) [3]. Finally, I show how to merge > resources > at application startup (using a class classed MergedResourceStream) to > reduce the number of resources a client has to download [4], including > code). I was able to increase interface loading times considerably, so > it's surely worth a look. > > I feel that it would also be worth to discuss, whether this work could > be > part of upcoming Wicket versions. For the time being I'd like to make > the > code attached to [4] a wicketstuff project - sfussenegger needs commit > access ;) - and wait for your feedback. > > The links: > [1] > http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up.html > Wicket Interface Speed-Up > [2] > > http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-modifying.html > Wicket Interface Speed-Up: Modifying Expires and Cache-Control Headers > [3] > > http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-caching.html > Wicket Interface Speed-Up: Caching Resources Forever > [4] > > http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-merging.html > Wicket Interface Speed-Up: Merging Resources for Fewer HTTP Requests > - --- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- View this message in context: http://ww
Re: Discussion on "Wicket Interface Speed-Up"
Thanks Stefan! Just removed my local checkout and it works fine. Jörn On Tue, Sep 2, 2008 at 8:46 AM, Stefan Fußenegger <[EMAIL PROTECTED]> wrote: > > wicketstuff-merged-resources is now available in JIRA: > > http://wicketstuff.org/jira/browse/WMR > > and from wicketstuff maven repo: > > >wicket-snaps >http://wicketstuff.org/maven/repository > >true > > >true > > > > > > org.wicketstuff > wicketstuff-merged-resources > 1.3.4-SNAPSHOT > > > i am also going to add a short wiki page at wicketstuff.org > > regards, Stefan > > > > Jörn Zaefferer-2 wrote: >> >> Good point, I forgot that wicketstuff has its own JIRA installation. >> Though the entry for the project is missing. Let me know once its >> there, and I'll create the report. >> >> Jörn >> >> On Fri, Aug 29, 2008 at 12:26 PM, Peter Ertl <[EMAIL PROTECTED]> wrote: >>> why don't you open up an issue in JIRA? >>> >>> >>> Am 29.08.2008 um 12:22 schrieb Jörn Zaefferer: >>> Here is a first patch for the RevisionVersionProvider: Index: src/main/java/org/wicketstuff/mergedresources/versioning/RevisionVersionProvider.java === --- src/main/java/org/wicketstuff/mergedresources/versioning/RevisionVersionProvider.java (revision 4147) +++ src/main/java/org/wicketstuff/mergedresources/versioning/RevisionVersionProvider.java (working copy) @@ -15,7 +15,7 @@ public int getVersion(final Class scope, final String fileName) throws VersionException { final String file = getResourcePath(scope, fileName); - final InputStream in = ClassLoader.getSystemResourceAsStream(file); + final InputStream in = RevisionVersionProvider.class.getClassLoader().getResourceAsStream(file); if (in == null) { throw new VersionException(scope, fileName, "can't find " + file); } ClassLoader.getSystemResourceAsStream in my deployment enviroment, it always returned null for classpath resources. Using the RevisionVersionProvider classloader works fine. Let me know where I should post further patches etc. Jörn On Fri, Aug 29, 2008 at 11:29 AM, Stefan Fußenegger <[EMAIL PROTECTED]> wrote: > > Code is now available through wicketsuff: > > https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-merged-resources/ > wicketstuff-merged-resources and > > https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-merged-resources-examples/ > wicketstuff-merged-resources-examples > > Now I want to make it available through > http://wicketstuff.org/maven/repository/. I therefore registered at > wicketstuff.org/teamcity (sfussenegger). What's next? > > > Stefan Fußenegger wrote: >> >> I just finished the 4th and last entry of my series "Wicket Interface >> Speed-Up" on my blog. To give a short summary: I investigated one of >> my >> apps with YSlow and started optimizing it's interface rendering speed >> [1]. >> Especially Wicket's way of handling resources, i.e. JS and CSS files, >> causes interfaces to load rather slowly. In my articles, I explain how >> to >> modify the cache interval [2], how to mount resources with a version >> (e.g. >> /css/all-1234.css) in order to use aggressive client-side caching >> (e.g. >> resources expire after a year) [3]. Finally, I show how to merge >> resources >> at application startup (using a class classed MergedResourceStream) to >> reduce the number of resources a client has to download [4], including >> code). I was able to increase interface loading times considerably, so >> it's surely worth a look. >> >> I feel that it would also be worth to discuss, whether this work could >> be >> part of upcoming Wicket versions. For the time being I'd like to make >> the >> code attached to [4] a wicketstuff project - sfussenegger needs commit >> access ;) - and wait for your feedback. >> >> The links: >> [1] >> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up.html >> Wicket Interface Speed-Up >> [2] >> >> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-modifying.html >> Wicket Interface Speed-Up: Modifying Expires and Cache-Control Headers >> [3] >> >> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-caching.html >> Wicket Interface Speed-Up: Caching Resources Forever >> [4] >> >> http://talk-on-tech.blogspot.com/2008/08/wicket-
Re: Discussion on "Wicket Interface Speed-Up"
The problem of breaking encapsulation: I did some work on this problem on my own a few months ago, my solution was to use a header contrib manager, and instead of adding files with a header contributer i add them to the manager, then get a single contributer per page from the manger. for example in a panel you would do @Override protected void onBeforeRender() { super.onBeforeRender(); ResourceReference rr = new ResourceReference(getClass(), "test.js"); WicketApplication.get().getHcm().add(rr, getPage().getClass()); } See how it uses getPage().getClass(), so the manager knows which class the panel is being added into then in the main page class @Override protected void onBeforeRender() { super.onBeforeRender(); add(WicketApplication.get().getHcm().getHeaderContributor(getClass())); } since the manager knows all of the resources added for the page at this point, it is easy to compress them all together and serve a single file, and you dont have to list the files up front. What do you think of this idea? My code is here: http://www.nabble.com/file/p19279269/HeaderContribManagerTest.zip HeaderContribManagerTest.zip It still has bugs etc in it, and doesnt really work cos ive messed up the registerResource method, but you should be able to get the idea from it Richard - http://www.richard-wilkinson.co.uk My blog: http://www.richard-wilkinson.co.uk -- View this message in context: http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19279269.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Discussion on "Wicket Interface Speed-Up"
problem with this is that pages can have dynamic components which dynamic header contributions. so either you have to somehow collect all possible header contributions from all possible component combinations - breaking encapsulation in the process, or you have to do what you do - ending up with many many possible and big javascript files to serve to the user. -igor On Tue, Sep 2, 2008 at 2:57 PM, richardwilko <[EMAIL PROTECTED]> wrote: > > The problem of breaking encapsulation: > > I did some work on this problem on my own a few months ago, my solution was > to use a header contrib manager, and instead of adding files with a header > contributer i add them to the manager, then get a single contributer per > page from the manger. > > for example in a panel you would do > > @Override >protected void onBeforeRender() { >super.onBeforeRender(); >ResourceReference rr = new ResourceReference(getClass(), > "test.js"); >WicketApplication.get().getHcm().add(rr, getPage().getClass()); >} > > See how it uses getPage().getClass(), so the manager knows which class the > panel is being added into > > then in the main page class > > @Override >protected void onBeforeRender() { >super.onBeforeRender(); > >add(WicketApplication.get().getHcm().getHeaderContributor(getClass())); >} > > since the manager knows all of the resources added for the page at this > point, it is easy to compress them all together and serve a single file, and > you dont have to list the files up front. > > What do you think of this idea? > > My code is here: > http://www.nabble.com/file/p19279269/HeaderContribManagerTest.zip > HeaderContribManagerTest.zip > > It still has bugs etc in it, and doesnt really work cos ive messed up the > registerResource method, but you should be able to get the idea from it > > Richard > > > > - > http://www.richard-wilkinson.co.uk My blog: > http://www.richard-wilkinson.co.uk > -- > View this message in context: > http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19279269.html > Sent from the Wicket - User mailing list archive at Nabble.com. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Discussion on "Wicket Interface Speed-Up"
im not sure we could help in the cases where you have dynamic header contributors, like you say you would either have to specify them up front (ie add them into the page not the panel, breaking encapsulation) or just serve via the normal header contributor. But i dont see how this would result in many many large files. you would have a single file for the static stuff, and then each dynamic one would have its own file (assuming not specified up front). This would still bring down the total number. eg a page has 6 static js and 2 dynamic js which would get turned into 1 static js and the same 2 dynamic js. cases where a component and resulting header contributers are added via ajax wouldnt be important for the initial page load speed anyway, as they are added after the page has loaded. Richard igor.vaynberg wrote: > > problem with this is that pages can have dynamic components which > dynamic header contributions. > > so either you have to somehow collect all possible header > contributions from all possible component combinations - breaking > encapsulation in the process, or you have to do what you do - ending > up with many many possible and big javascript files to serve to the > user. > > -igor > > On Tue, Sep 2, 2008 at 2:57 PM, richardwilko > <[EMAIL PROTECTED]> wrote: >> >> The problem of breaking encapsulation: >> >> I did some work on this problem on my own a few months ago, my solution >> was >> to use a header contrib manager, and instead of adding files with a >> header >> contributer i add them to the manager, then get a single contributer per >> page from the manger. >> >> for example in a panel you would do >> >> @Override >>protected void onBeforeRender() { >>super.onBeforeRender(); >>ResourceReference rr = new ResourceReference(getClass(), >> "test.js"); >>WicketApplication.get().getHcm().add(rr, >> getPage().getClass()); >>} >> >> See how it uses getPage().getClass(), so the manager knows which class >> the >> panel is being added into >> >> then in the main page class >> >> @Override >>protected void onBeforeRender() { >>super.onBeforeRender(); >> >> >> add(WicketApplication.get().getHcm().getHeaderContributor(getClass())); >>} >> >> since the manager knows all of the resources added for the page at this >> point, it is easy to compress them all together and serve a single file, >> and >> you dont have to list the files up front. >> >> What do you think of this idea? >> >> My code is here: >> http://www.nabble.com/file/p19279269/HeaderContribManagerTest.zip >> HeaderContribManagerTest.zip >> >> It still has bugs etc in it, and doesnt really work cos ive messed up the >> registerResource method, but you should be able to get the idea from it >> >> Richard >> >> >> >> - >> http://www.richard-wilkinson.co.uk My blog: >> http://www.richard-wilkinson.co.uk >> -- >> View this message in context: >> http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19279269.html >> Sent from the Wicket - User mailing list archive at Nabble.com. >> >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > - http://www.richard-wilkinson.co.uk My blog: http://www.richard-wilkinson.co.uk -- View this message in context: http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19289766.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Discussion on "Wicket Interface Speed-Up"
It's not the pages that have these files. Let's say I have a page that uses jquery and a textfield with a button that toggles tinymce. If we do what you say then there are two possible files: jquery and jquery+tinymce. Than let's say I add Ajax to the page, now there are 6 possibilities depending on which components are currently on the page. IMHO much cheaper to just cache jquery, tinymce, wicket-Ajax individually. -Igor On 9/3/08, richardwilko <[EMAIL PROTECTED]> wrote: > > im not sure we could help in the cases where you have dynamic header > contributors, like you say you would either have to specify them up front > (ie add them into the page not the panel, breaking encapsulation) or just > serve via the normal header contributor. > > But i dont see how this would result in many many large files. you would > have a single file for the static stuff, and then each dynamic one would > have its own file (assuming not specified up front). This would still bring > down the total number. > > eg a page has 6 static js and 2 dynamic js which would get turned into 1 > static js and the same 2 dynamic js. > > cases where a component and resulting header contributers are added via ajax > wouldnt be important for the initial page load speed anyway, as they are > added after the page has loaded. > > Richard > > > igor.vaynberg wrote: >> >> problem with this is that pages can have dynamic components which >> dynamic header contributions. >> >> so either you have to somehow collect all possible header >> contributions from all possible component combinations - breaking >> encapsulation in the process, or you have to do what you do - ending >> up with many many possible and big javascript files to serve to the >> user. >> >> -igor >> >> On Tue, Sep 2, 2008 at 2:57 PM, richardwilko >> <[EMAIL PROTECTED]> wrote: >>> >>> The problem of breaking encapsulation: >>> >>> I did some work on this problem on my own a few months ago, my solution >>> was >>> to use a header contrib manager, and instead of adding files with a >>> header >>> contributer i add them to the manager, then get a single contributer per >>> page from the manger. >>> >>> for example in a panel you would do >>> >>> @Override >>>protected void onBeforeRender() { >>>super.onBeforeRender(); >>>ResourceReference rr = new ResourceReference(getClass(), >>> "test.js"); >>>WicketApplication.get().getHcm().add(rr, >>> getPage().getClass()); >>>} >>> >>> See how it uses getPage().getClass(), so the manager knows which class >>> the >>> panel is being added into >>> >>> then in the main page class >>> >>> @Override >>>protected void onBeforeRender() { >>>super.onBeforeRender(); >>> >>> >>> add(WicketApplication.get().getHcm().getHeaderContributor(getClass())); >>>} >>> >>> since the manager knows all of the resources added for the page at this >>> point, it is easy to compress them all together and serve a single file, >>> and >>> you dont have to list the files up front. >>> >>> What do you think of this idea? >>> >>> My code is here: >>> http://www.nabble.com/file/p19279269/HeaderContribManagerTest.zip >>> HeaderContribManagerTest.zip >>> >>> It still has bugs etc in it, and doesnt really work cos ive messed up the >>> registerResource method, but you should be able to get the idea from it >>> >>> Richard >>> >>> >>> >>> - >>> http://www.richard-wilkinson.co.uk My blog: >>> http://www.richard-wilkinson.co.uk >>> -- >>> View this message in context: >>> http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19279269.html >>> Sent from the Wicket - User mailing list archive at Nabble.com. >>> >>> >>> - >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> > > > - > http://www.richard-wilkinson.co.uk My blog: > http://www.richard-wilkinson.co.uk > -- > View this message in context: > http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19289766.html > Sent from the Wicket - User mailing list archive at Nabble.com. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Discussion on "Wicket Interface Speed-Up"
There is yet another thing to consider. Iphone doesn't cache resources bigger than 25kb (after unzipping). So instead of grouping files together sometimes it even might be appropriate to split them... -Matej On Wed, Sep 3, 2008 at 4:11 PM, <[EMAIL PROTECTED]> wrote: > It's not the pages that have these files. Let's say I have a page that > uses jquery and a textfield with a button that toggles tinymce. > > If we do what you say then there are two possible files: jquery and > jquery+tinymce. > > Than let's say I add Ajax to the page, now there are 6 possibilities > depending on which components are currently on the page. > > IMHO much cheaper to just cache jquery, tinymce, wicket-Ajax individually. > > -Igor > On 9/3/08, richardwilko <[EMAIL PROTECTED]> wrote: >> >> im not sure we could help in the cases where you have dynamic header >> contributors, like you say you would either have to specify them up front >> (ie add them into the page not the panel, breaking encapsulation) or just >> serve via the normal header contributor. >> >> But i dont see how this would result in many many large files. you would >> have a single file for the static stuff, and then each dynamic one would >> have its own file (assuming not specified up front). This would still bring >> down the total number. >> >> eg a page has 6 static js and 2 dynamic js which would get turned into 1 >> static js and the same 2 dynamic js. >> >> cases where a component and resulting header contributers are added via ajax >> wouldnt be important for the initial page load speed anyway, as they are >> added after the page has loaded. >> >> Richard >> >> >> igor.vaynberg wrote: >>> >>> problem with this is that pages can have dynamic components which >>> dynamic header contributions. >>> >>> so either you have to somehow collect all possible header >>> contributions from all possible component combinations - breaking >>> encapsulation in the process, or you have to do what you do - ending >>> up with many many possible and big javascript files to serve to the >>> user. >>> >>> -igor >>> >>> On Tue, Sep 2, 2008 at 2:57 PM, richardwilko >>> <[EMAIL PROTECTED]> wrote: The problem of breaking encapsulation: I did some work on this problem on my own a few months ago, my solution was to use a header contrib manager, and instead of adding files with a header contributer i add them to the manager, then get a single contributer per page from the manger. for example in a panel you would do @Override protected void onBeforeRender() { super.onBeforeRender(); ResourceReference rr = new ResourceReference(getClass(), "test.js"); WicketApplication.get().getHcm().add(rr, getPage().getClass()); } See how it uses getPage().getClass(), so the manager knows which class the panel is being added into then in the main page class @Override protected void onBeforeRender() { super.onBeforeRender(); add(WicketApplication.get().getHcm().getHeaderContributor(getClass())); } since the manager knows all of the resources added for the page at this point, it is easy to compress them all together and serve a single file, and you dont have to list the files up front. What do you think of this idea? My code is here: http://www.nabble.com/file/p19279269/HeaderContribManagerTest.zip HeaderContribManagerTest.zip It still has bugs etc in it, and doesnt really work cos ive messed up the registerResource method, but you should be able to get the idea from it Richard - http://www.richard-wilkinson.co.uk My blog: http://www.richard-wilkinson.co.uk -- View this message in context: http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19279269.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> - >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >>> >> >> >> - >> http://www.richard-wilkinson.co.uk My blog: >> http://www.richard-wilkinson.co.uk >> -- >> View this message in context: >> http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19289766.html >> Sent from the Wicket - User mailing list archive at Nabble.com. >> >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > --
Re: Discussion on "Wicket Interface Speed-Up"
I see your point, essentially we have 1 (relativity large) bundle file per page, and if you have 5 pages which use jquery, tinymce and ajax then you are worse off, since the normal way you would have already cached the 3 individual files (this is what you meant right?) Maybe there is some way to automatically work out the best bundles to create depending on usage, so dont create bundles based on page, but based on contents? I think the real answer is that everyones usage is different and what is good for one system isn't good for another. igor.vaynberg wrote: > > It's not the pages that have these files. Let's say I have a page that > uses jquery and a textfield with a button that toggles tinymce. > > If we do what you say then there are two possible files: jquery and > jquery+tinymce. > > Than let's say I add Ajax to the page, now there are 6 possibilities > depending on which components are currently on the page. > > IMHO much cheaper to just cache jquery, tinymce, wicket-Ajax individually. > > -Igor > On 9/3/08, richardwilko <[EMAIL PROTECTED]> wrote: >> >> im not sure we could help in the cases where you have dynamic header >> contributors, like you say you would either have to specify them up front >> (ie add them into the page not the panel, breaking encapsulation) or just >> serve via the normal header contributor. >> >> But i dont see how this would result in many many large files. you would >> have a single file for the static stuff, and then each dynamic one would >> have its own file (assuming not specified up front). This would still >> bring >> down the total number. >> >> eg a page has 6 static js and 2 dynamic js which would get turned into 1 >> static js and the same 2 dynamic js. >> >> cases where a component and resulting header contributers are added via >> ajax >> wouldnt be important for the initial page load speed anyway, as they are >> added after the page has loaded. >> >> Richard >> >> >> igor.vaynberg wrote: >>> >>> problem with this is that pages can have dynamic components which >>> dynamic header contributions. >>> >>> so either you have to somehow collect all possible header >>> contributions from all possible component combinations - breaking >>> encapsulation in the process, or you have to do what you do - ending >>> up with many many possible and big javascript files to serve to the >>> user. >>> >>> -igor >>> >>> On Tue, Sep 2, 2008 at 2:57 PM, richardwilko >>> <[EMAIL PROTECTED]> wrote: The problem of breaking encapsulation: I did some work on this problem on my own a few months ago, my solution was to use a header contrib manager, and instead of adding files with a header contributer i add them to the manager, then get a single contributer per page from the manger. for example in a panel you would do @Override protected void onBeforeRender() { super.onBeforeRender(); ResourceReference rr = new ResourceReference(getClass(), "test.js"); WicketApplication.get().getHcm().add(rr, getPage().getClass()); } See how it uses getPage().getClass(), so the manager knows which class the panel is being added into then in the main page class @Override protected void onBeforeRender() { super.onBeforeRender(); add(WicketApplication.get().getHcm().getHeaderContributor(getClass())); } since the manager knows all of the resources added for the page at this point, it is easy to compress them all together and serve a single file, and you dont have to list the files up front. What do you think of this idea? My code is here: http://www.nabble.com/file/p19279269/HeaderContribManagerTest.zip HeaderContribManagerTest.zip It still has bugs etc in it, and doesnt really work cos ive messed up the registerResource method, but you should be able to get the idea from it Richard - http://www.richard-wilkinson.co.uk My blog: http://www.richard-wilkinson.co.uk -- View this message in context: http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19279269.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> - >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >>> >> >> >> - >> http://www.richard-wilkinson.co.uk My blog: >> http://www.richard-wilkinson.co.uk >> -- >> View this message in context: >> http://www.nabble.com/Discussion-on-%22Wi
Re: Discussion on "Wicket Interface Speed-Up"
Hmmm. As you say, there's no easy one-size-fits-all. There is an obvious improvement you could make, though. All JS/CSS contributions initially rendered on the home page could be batched up. This will typically provide the biggest improvement anyway. You could then keep a reference to this batch, and use it instead of individually including any of these constituent contributions elsewhere. This would also give fairly intuitive behaviour - if you want to pre-load your JS/CSS in a single batch, just add the headercontributors to your home page, and Wicket will figure it out. I've long hated having to specify the component class in header contributors, as 99% of the time the resources live in the same package (or in a subpackage) as the component they belong to. I'd even go so far as to remove the need for HeaderContributor code entirely in 80% of the cases. Wicket could automatically pick up css and js files that are named the same as your component. MyComponent.java MyComponent.html MyComponent.properties So why not: MyComponent.css MyComponent.js ? Heck, you could even include i18n for dealing with language-specific layout issues: MyComponent_jp.css Regards, Al 2008/9/3 richardwilko <[EMAIL PROTECTED]> > > I see your point, essentially we have 1 (relativity large) bundle file per > page, and if you have 5 pages which use jquery, tinymce and ajax then you > are worse off, since the normal way you would have already cached the 3 > individual files (this is what you meant right?) > > Maybe there is some way to automatically work out the best bundles to > create > depending on usage, so dont create bundles based on page, but based on > contents? > > I think the real answer is that everyones usage is different and what is > good for one system isn't good for another. > > > igor.vaynberg wrote: > > > > It's not the pages that have these files. Let's say I have a page that > > uses jquery and a textfield with a button that toggles tinymce. > > > > If we do what you say then there are two possible files: jquery and > > jquery+tinymce. > > > > Than let's say I add Ajax to the page, now there are 6 possibilities > > depending on which components are currently on the page. > > > > IMHO much cheaper to just cache jquery, tinymce, wicket-Ajax > individually. > > > > -Igor > > On 9/3/08, richardwilko <[EMAIL PROTECTED]> wrote: > >> > >> im not sure we could help in the cases where you have dynamic header > >> contributors, like you say you would either have to specify them up > front > >> (ie add them into the page not the panel, breaking encapsulation) or > just > >> serve via the normal header contributor. > >> > >> But i dont see how this would result in many many large files. you > would > >> have a single file for the static stuff, and then each dynamic one would > >> have its own file (assuming not specified up front). This would still > >> bring > >> down the total number. > >> > >> eg a page has 6 static js and 2 dynamic js which would get turned into 1 > >> static js and the same 2 dynamic js. > >> > >> cases where a component and resulting header contributers are added via > >> ajax > >> wouldnt be important for the initial page load speed anyway, as they are > >> added after the page has loaded. > >> > >> Richard > >> > >> > >> igor.vaynberg wrote: > >>> > >>> problem with this is that pages can have dynamic components which > >>> dynamic header contributions. > >>> > >>> so either you have to somehow collect all possible header > >>> contributions from all possible component combinations - breaking > >>> encapsulation in the process, or you have to do what you do - ending > >>> up with many many possible and big javascript files to serve to the > >>> user. > >>> > >>> -igor > >>> > >>> On Tue, Sep 2, 2008 at 2:57 PM, richardwilko > >>> <[EMAIL PROTECTED]> wrote: > > The problem of breaking encapsulation: > > I did some work on this problem on my own a few months ago, my > solution > was > to use a header contrib manager, and instead of adding files with a > header > contributer i add them to the manager, then get a single contributer > per > page from the manger. > > for example in a panel you would do > > @Override > protected void onBeforeRender() { > super.onBeforeRender(); > ResourceReference rr = new > ResourceReference(getClass(), > "test.js"); > WicketApplication.get().getHcm().add(rr, > getPage().getClass()); > } > > See how it uses getPage().getClass(), so the manager knows which class > the > panel is being added into > > then in the main page class > > @Override > protected void onBeforeRender() { > super.onBeforeRender(); > > > > add(WicketApplication.get().getHcm().getHeaderContributor(getClass())); > } > > since the
Re: Discussion on "Wicket Interface Speed-Up"
On Wed, Sep 03, 2008 at 04:34:34PM +0100, Al Maw wrote: > > I'd even go so far as to remove the need for HeaderContributor code entirely > in 80% of the cases. > Wicket could automatically pick up css and js files that are named the same > as your component. > MyComponent.java > MyComponent.html > MyComponent.properties > So why not: > MyComponent.css > MyComponent.js > ? > > Heck, you could even include i18n for dealing with language-specific layout > issues: > MyComponent_jp.css > > Regards, > > Al +1. I even tried this once since it seemed like such an intuitive thing. jk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Discussion on "Wicket Interface Speed-Up"
in html: some foo Which has the added bonus of being previewable. Martijn On Wed, Sep 3, 2008 at 5:34 PM, Al Maw <[EMAIL PROTECTED]> wrote: > Hmmm. As you say, there's no easy one-size-fits-all. > There is an obvious improvement you could make, though. All JS/CSS > contributions initially rendered on the home page could be batched up. This > will typically provide the biggest improvement anyway. You could then keep a > reference to this batch, and use it instead of individually including any of > these constituent contributions elsewhere. > > This would also give fairly intuitive behaviour - if you want to pre-load > your JS/CSS in a single batch, just add the headercontributors to your home > page, and Wicket will figure it out. > > I've long hated having to specify the component class in header > contributors, as 99% of the time the resources live in the same package (or > in a subpackage) as the component they belong to. > > I'd even go so far as to remove the need for HeaderContributor code entirely > in 80% of the cases. > Wicket could automatically pick up css and js files that are named the same > as your component. > MyComponent.java > MyComponent.html > MyComponent.properties > So why not: > MyComponent.css > MyComponent.js > ? > > Heck, you could even include i18n for dealing with language-specific layout > issues: > MyComponent_jp.css > > Regards, > > Al > > 2008/9/3 richardwilko <[EMAIL PROTECTED]> > >> >> I see your point, essentially we have 1 (relativity large) bundle file per >> page, and if you have 5 pages which use jquery, tinymce and ajax then you >> are worse off, since the normal way you would have already cached the 3 >> individual files (this is what you meant right?) >> >> Maybe there is some way to automatically work out the best bundles to >> create >> depending on usage, so dont create bundles based on page, but based on >> contents? >> >> I think the real answer is that everyones usage is different and what is >> good for one system isn't good for another. >> >> >> igor.vaynberg wrote: >> > >> > It's not the pages that have these files. Let's say I have a page that >> > uses jquery and a textfield with a button that toggles tinymce. >> > >> > If we do what you say then there are two possible files: jquery and >> > jquery+tinymce. >> > >> > Than let's say I add Ajax to the page, now there are 6 possibilities >> > depending on which components are currently on the page. >> > >> > IMHO much cheaper to just cache jquery, tinymce, wicket-Ajax >> individually. >> > >> > -Igor >> > On 9/3/08, richardwilko <[EMAIL PROTECTED]> wrote: >> >> >> >> im not sure we could help in the cases where you have dynamic header >> >> contributors, like you say you would either have to specify them up >> front >> >> (ie add them into the page not the panel, breaking encapsulation) or >> just >> >> serve via the normal header contributor. >> >> >> >> But i dont see how this would result in many many large files. you >> would >> >> have a single file for the static stuff, and then each dynamic one would >> >> have its own file (assuming not specified up front). This would still >> >> bring >> >> down the total number. >> >> >> >> eg a page has 6 static js and 2 dynamic js which would get turned into 1 >> >> static js and the same 2 dynamic js. >> >> >> >> cases where a component and resulting header contributers are added via >> >> ajax >> >> wouldnt be important for the initial page load speed anyway, as they are >> >> added after the page has loaded. >> >> >> >> Richard >> >> >> >> >> >> igor.vaynberg wrote: >> >>> >> >>> problem with this is that pages can have dynamic components which >> >>> dynamic header contributions. >> >>> >> >>> so either you have to somehow collect all possible header >> >>> contributions from all possible component combinations - breaking >> >>> encapsulation in the process, or you have to do what you do - ending >> >>> up with many many possible and big javascript files to serve to the >> >>> user. >> >>> >> >>> -igor >> >>> >> >>> On Tue, Sep 2, 2008 at 2:57 PM, richardwilko >> >>> <[EMAIL PROTECTED]> wrote: >> >> The problem of breaking encapsulation: >> >> I did some work on this problem on my own a few months ago, my >> solution >> was >> to use a header contrib manager, and instead of adding files with a >> header >> contributer i add them to the manager, then get a single contributer >> per >> page from the manger. >> >> for example in a panel you would do >> >> @Override >> protected void onBeforeRender() { >> super.onBeforeRender(); >> ResourceReference rr = new >> ResourceReference(getClass(), >> "test.js"); >> WicketApplication.get().getHcm().add(rr, >> getPage().getClass()); >> } >> >> See how it uses getPage().getClass(), so the manager knows which class >>
Re: Discussion on "Wicket Interface Speed-Up"
Ignoring the iPhone - not everyone has that as a target platform - the bruteforce method of packaging everything into one file isn't that bad. The initial bandwidth hit is outweighed be reducing requests to one (or two, one js, one css file). That means the first page loads a bit longer, which is normal in most cases anyway, while all other pages loaded afterwards need no additional css/js at all, therefore being potentially lightning fast. Putting all page specific scripts into one file isn't trivial. I've found that its very easy to handle by starting each script to check if a certain dom element, selected via ID, exists. In my case, using jQuery, something like this: Subpage.js jQuery(function($) { if ($("#somePageSpecificId").length) { // Subpage is active, do something } }); ID selectors should have no performance impact at all, as long as there aren't thousands of them, which is very unlikely in this scenario. The same applies to CSS, where page specific styles are "namespaces" with parent ids - same concept, easier to write. If you *are* targeting the iPhone, you proably shouldn't load a full library and tinymce and what not anyway... Jörn On Wed, Sep 3, 2008 at 4:21 PM, Matej Knopp <[EMAIL PROTECTED]> wrote: > There is yet another thing to consider. Iphone doesn't cache resources > bigger than 25kb (after unzipping). So instead of grouping files > together sometimes it even might be appropriate to split them... > > -Matej > > On Wed, Sep 3, 2008 at 4:11 PM, <[EMAIL PROTECTED]> wrote: >> It's not the pages that have these files. Let's say I have a page that >> uses jquery and a textfield with a button that toggles tinymce. >> >> If we do what you say then there are two possible files: jquery and >> jquery+tinymce. >> >> Than let's say I add Ajax to the page, now there are 6 possibilities >> depending on which components are currently on the page. >> >> IMHO much cheaper to just cache jquery, tinymce, wicket-Ajax individually. >> >> -Igor >> On 9/3/08, richardwilko <[EMAIL PROTECTED]> wrote: >>> >>> im not sure we could help in the cases where you have dynamic header >>> contributors, like you say you would either have to specify them up front >>> (ie add them into the page not the panel, breaking encapsulation) or just >>> serve via the normal header contributor. >>> >>> But i dont see how this would result in many many large files. you would >>> have a single file for the static stuff, and then each dynamic one would >>> have its own file (assuming not specified up front). This would still bring >>> down the total number. >>> >>> eg a page has 6 static js and 2 dynamic js which would get turned into 1 >>> static js and the same 2 dynamic js. >>> >>> cases where a component and resulting header contributers are added via ajax >>> wouldnt be important for the initial page load speed anyway, as they are >>> added after the page has loaded. >>> >>> Richard >>> >>> >>> igor.vaynberg wrote: problem with this is that pages can have dynamic components which dynamic header contributions. so either you have to somehow collect all possible header contributions from all possible component combinations - breaking encapsulation in the process, or you have to do what you do - ending up with many many possible and big javascript files to serve to the user. -igor On Tue, Sep 2, 2008 at 2:57 PM, richardwilko <[EMAIL PROTECTED]> wrote: > > The problem of breaking encapsulation: > > I did some work on this problem on my own a few months ago, my solution > was > to use a header contrib manager, and instead of adding files with a > header > contributer i add them to the manager, then get a single contributer per > page from the manger. > > for example in a panel you would do > > @Override >protected void onBeforeRender() { >super.onBeforeRender(); >ResourceReference rr = new ResourceReference(getClass(), > "test.js"); >WicketApplication.get().getHcm().add(rr, > getPage().getClass()); >} > > See how it uses getPage().getClass(), so the manager knows which class > the > panel is being added into > > then in the main page class > > @Override >protected void onBeforeRender() { >super.onBeforeRender(); > > > add(WicketApplication.get().getHcm().getHeaderContributor(getClass())); >} > > since the manager knows all of the resources added for the page at this > point, it is easy to compress them all together and serve a single file, > and > you dont have to list the files up front. > > What do you think of this idea? > > My code is here: > http://www.nabble.com/file/p19279269/HeaderContribManagerTest.zip > HeaderContribManagerTest.zip > > It still has bugs etc in it, and doe