Hints for improved web performances

[Stephane Boisson <sb...@gmail.com>]

Hi all!

I've just read this articles:
http://developer.yahoo.com/performance/rules.html
http://yuiblog.com/blog/2007/04/11/performance-research-part-4/

It might be interresting to make some changes to Wicket to better handle
some rules..

For example, I was thinking of:

* "Add an Expires Header" -
http://developer.yahoo.com/performance/rules.html#expires
Wicket already set a short term expiration for bundled JS, CSS, images
resources. We could get better caching performance by using ressources names
with versions and than using long term caching..
The drawback is an updated resource must have its name changes..
At least it would be nice to overide this expiration

* "Move Scripts to the Bottom" -
http://developer.yahoo.com/performance/rules.html#js_bottom
Handling this in IHeaderResponse implementation?

* "Configure ETags" -
http://developer.yahoo.com/performance/rules.html#etags
Plugging this with page cache?

* "Maximizing Parallel Downloads"
By using some automatic round-robin absolutes URL for resources
downloading.. It would means more configuration for setting absolute URL
pool for each resources types (CSS, images, JavaScript..)

Stéphane


-- 
View this message in context: http://www.nabble.com/Hints-for-improved-web-performances-tf4206588.html#a11965982
Sent from the Wicket - Dev mailing list archive at Nabble.com.

Re: Hints for improved web performances

[salk31 <sa...@redspr.com>]

Eelco,

Another advantage of putting the version/build number in the URI of JS, CSS
etc is to ensure that browsers fetch the latest version. So no more asking
users to hit SHIFT+Reload. Setting expires headers for anything but "never"
is not very reliable as a surprising number of client clocks are wrong. Only
if-not-modified-since requests can cope with this but they require browser
HTTP request. 

Cheers

Sam


Eelco Hillenius wrote:
> 
> Hi,
> 
>> * "Add an Expires Header" -
>> http://developer.yahoo.com/performance/rules.html#expires
>> Wicket already set a short term expiration for bundled JS, CSS, images
>> resources. We could get better caching performance by using ressources
>> names
>> with versions and than using long term caching..
>> The drawback is an updated resource must have its name changes..
>> At least it would be nice to overide this expiration
> 
> We can look into this, but I thought it was already pretty optimal
> what we do, and it is something people can configure themselves.
> 
>> * "Move Scripts to the Bottom" -
>> http://developer.yahoo.com/performance/rules.html#js_bottom
>> Handling this in IHeaderResponse implementation?
> 
> Technically we could, but I doubt whether that is a good idea for
> header contributions, as they often need to be initialized so that
> javascript event handlers can react on them.
> 
>> * "Configure ETags" -
>> http://developer.yahoo.com/performance/rules.html#etags
>> Plugging this with page cache?
> 
> Don't know much about them. Might be something to look at.
> 
>> * "Maximizing Parallel Downloads"
>> By using some automatic round-robin absolutes URL for resources
>> downloading.. It would means more configuration for setting absolute URL
>> pool for each resources types (CSS, images, JavaScript..)
> 
> Not sure what you mean here. We already have absolute URLs for
> resources and if you have expensive resources, you can already pool
> them as you like (and some resources, like zipped Javascript and CSS
> files for instance are already cached).
> 
> I think a couple of concrete patch proposals are best for discussing
> things.
> 
> Thanks,
> 
> Eelco
> 
> 

-- 
View this message in context: http://www.nabble.com/Hints-for-improved-web-performances-tf4206588.html#a12182399
Sent from the Wicket - Dev mailing list archive at Nabble.com.

Re: Hints for improved web performances

[Eelco Hillenius <ee...@gmail.com>]

Hi,

> * "Add an Expires Header" -
> http://developer.yahoo.com/performance/rules.html#expires
> Wicket already set a short term expiration for bundled JS, CSS, images
> resources. We could get better caching performance by using ressources names
> with versions and than using long term caching..
> The drawback is an updated resource must have its name changes..
> At least it would be nice to overide this expiration

We can look into this, but I thought it was already pretty optimal
what we do, and it is something people can configure themselves.

> * "Move Scripts to the Bottom" -
> http://developer.yahoo.com/performance/rules.html#js_bottom
> Handling this in IHeaderResponse implementation?

Technically we could, but I doubt whether that is a good idea for
header contributions, as they often need to be initialized so that
javascript event handlers can react on them.

> * "Configure ETags" -
> http://developer.yahoo.com/performance/rules.html#etags
> Plugging this with page cache?

Don't know much about them. Might be something to look at.

> * "Maximizing Parallel Downloads"
> By using some automatic round-robin absolutes URL for resources
> downloading.. It would means more configuration for setting absolute URL
> pool for each resources types (CSS, images, JavaScript..)

Not sure what you mean here. We already have absolute URLs for
resources and if you have expensive resources, you can already pool
them as you like (and some resources, like zipped Javascript and CSS
files for instance are already cached).

I think a couple of concrete patch proposals are best for discussing things.

Thanks,

Eelco