skaiuoquer pisze:
> disccomp, Richard, Alex; thanks for your replies.
> The problem with minified compressed versions is that they will never
> get cached on the client side.
> I mean, they will, but you will still be sending them each one of the
> different "combinations"--so instead of loading prototype.js once, the
> user will be loading it -albeit compressed- once on every different
> combination.
> This is a problem, since, like I said, this is a web application that
> is meant to be used several times throughout the day, and taking
> advantage of browser-caching is quite important for us.
> Those ideas are part of the advices that YSlow proposes--and they are
> quite good, thanks =)
> I will look into those solutions, but, I'm not fully convinced yet
> that they are entirely adequate for this particular problem.

Remember that you decide what you want and what you do not want to 

At our company we have two "types" of scripts:
1) Framework scripts, such as prototype, scripty, and our own 
framework additions, widgets (calendars, table filters, etc).
Those are common through all the system. It might be, that some parts 
are not necessary everywhere, but generally they are used across most 
of the pages.

2) Page logic, which are distinct per module, or even per specific 
page. This is the place where we initialize all the event handlers, 
and here we put the scripts specific for the module, and configuration 
for the widgets and so on. Each script used once should be in this 

So, each page grabs a concatenated, minified, compressed, versioned! 
and cacheble! set of ALL files from category 1.

Then the page requests the creation of the concatenated, minified, 
compressed, versioned and cacheble the scripts IT NEEDS from category 
2. This is saved serverside, so it is done once after any change to 
any of used scripts. The framework puts a second <script> tag to 
include page specific concatenated scripts.

So, we end up in two script tags per page load, which both are small 
in size, and are cached client-side after first load of the page.

No need to create one huge file for the whole application. Common part 
are cached separately, and specific parts are also cached, as the user 
of an Application usually uses a number of modules in his/her work 
many times a day.

Best regards,

You received this message because you are subscribed to the Google Groups 
"Prototype &" group.
To post to this group, send email to
To unsubscribe from this group, send email to
For more options, visit this group at

Reply via email to