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]
-
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
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-%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
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 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
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:
html
head
wicket:head
wicket:link
link href=MyComponent.css rel=stylesheet /
script src=MyComponent.js type=text/javascript
/script
/wicket:link
/wicket:head
/head
body
wicket:panel
some foo
/wicket:panel
/body
/html
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
the
panel is being added into
then in the main page class
@Override
protected void onBeforeRender() {
super.onBeforeRender();
add(WicketApplication.get().getHcm().getHeaderContributor(getClass()));
}
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 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
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:
repositories
repository
idwicket-snaps/id
urlhttp://wicketstuff.org/maven/repository/url
snapshots
enabledtrue/enabled
/snapshots
releases
enabledtrue/enabled
/releases
/repository
/repositories
dependency
groupIdorg.wicketstuff/groupId
artifactIdwicketstuff-merged-resources/artifactId
version1.3.4-SNAPSHOT/version
/dependency
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://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]
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:
repositories
repository
idwicket-snaps/id
urlhttp://wicketstuff.org/maven/repository/url
snapshots
enabledtrue/enabled
/snapshots
releases
enabledtrue/enabled
/releases
/repository
/repositories
dependency
groupIdorg.wicketstuff/groupId
artifactIdwicketstuff-merged-resources/artifactId
version1.3.4-SNAPSHOT/version
/dependency
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://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19216657.html
Sent from the 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
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:
http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19214462.html
Sent from the Wicket - User mailing list archive at
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-%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,
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:
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://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:
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 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]
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 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
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
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]
