Piwigo is flexible and once we install some plugins, fancy themes we quickly end up with many javascript and css files. This will degrade the "user experience" because of several round trips to server, because we put all scripts in the head, because browsers do not start rendering before every css is loaded ... (see these links: http://code.google.com/speed/page-speed/docs/rtt.html adn http://code.google.com/speed/page-speed … rLoadingJS)
I propose to get rid of known_script and replace it with combine_script. Below are some examples of usages. Piwigo will take in charge to insert the scripts in the right order in the head or at the bottom. Later on I count on adding the possibility to merge several scripts at runtime into a single file.
Examples:
{combine_script id="jquery" load="top" path=...}
{combine_script id="jquery.toto" load="bottom" require="jquery" path=...}
{combine_script id="jquery.ui" load="bottom" require="jquery" path=...}
{combine_script id="jquery.ui.datepicker" load="bottom" require="jquery.ui" path=...}
{combine_script id="core.scripts" load="async" path=scripts.js}
{combine_script id="rating" load="async" require="core.scripts" path=rating.js}
When the {combine_script} feature is done, we could easily extend it to {combine_css} (everything in the head, but files could be merged).
Offline
Hi rvelices,
Yes, I fully agree with that : there are more and more scripts/stylesheets loaded. Anything that can reduce this number would be good. I understand that merging is a second step and that first step is to load javascript files only when it's useful, on the bottom most of the time.
Can you explain:
1) why jQuery must be loaded on top
2) what load="async" means (I suppose it means that it is a conditionnal load, but please confirm)
(next step would be CSS sprites for images : 1 themes = 1 images for all backgrounds & icons)
Offline
Excellent ideas!
plg wrote:
2) what load="async" means (I suppose it means that it is a conditionnal load, but please confirm)
I think that async load mean javascript file is loaded after page is displayed.
Deferring loading of JavaScript functions that are not called at startup reduces the initial download size, allowing other resources to be downloaded in parallel, and speeding up execution and rendering time.
Offline
Can we imagine an option for priority (same as plugins, for example, default will be 50)?
{combine_script id="mootools" priority=40 load="top" path=...}
Offline
plg wrote:
1) why jQuery must be loaded on top
It is not a requirement. It can be at the bottom. However all jQuery().ready inline script calls must be inserted after in the DOM. I will add this feature like this
{combine jquery bottom}
{footer_script}
jQuery().ready
{/footer_script}
Offline
P@t wrote:
plg wrote:
2) what load="async" means (I suppose it means that it is a conditionnal load, but please confirm)
I think that async load mean javascript file is loaded after page is displayed.
It is loading at any time (head, bottom or 10 seconds after page is loaded). I applied it for the nice rating form see [Subversion] r7957 end of rating.js and changes in picture.tpl
Offline
P@t wrote:
Can we imagine an option for priority (same as plugins, for example, default will be 50)?
{combine_script id="mootools" priority=40 load="top" path=...}
This should not be necessary. the dependencies that you define in require should automatically handle it ... It is true that in some cases we will have multiple choices, but it is better to leave the core do it ...
Offline
rvelices wrote:
P@t wrote:
Can we imagine an option for priority (same as plugins, for example, default will be 50)?
{combine_script id="mootools" priority=40 load="top" path=...}
This should not be necessary. the dependencies that you define in require should automatically handle it ... It is true that in some cases we will have multiple choices, but it is better to leave the core do it ...
I agree... but for example, with some js framework (like mootools), it must be loaded before jQuery for compatibility reasons...
Offline
P@t wrote:
I agree... but for example, with some js framework (like mootools), it must be loaded before jQuery for compatibility reasons...
I know... Should be the same with prototype ... I just wanted to hard code these 2 dependencies and it should be enough ...
Offline
[Subversion] r7975 and [Subversion] r7987
almost there (javascript files are not yet combined, but css are)
Any feedback before working on admin tempaltes ?
Offline
Hi rvelices,
rvelices wrote:
Any feedback before working on admin templates ?
(I didn't inspect the code enough, so I have questions)
Did you take into account a new/updated local/css/*.css?
How do you decide to regenerate the local/combined/y5ihob.css?
Will you add a maintenance action to purge combined cache files?
Note for myself: I must start a discussion about making the "local" directory path as a configuration setting, it is already a problem for a few themes but with this core feature, it becomes absolutely necessary
Offline
plg wrote:
Did you take into account a new/updated local/css/*.css?
How do you decide to regenerate the local/combined/y5ihob.css?
Will you add a maintenance action to purge combined cache files?
Updated files: config['compile_template_check'] works here as for templates (if true we check mtime otherwise we go fast but need manual purge to take into account new modifs)
New files: need purge
The maintanance will do both templates and combined js/css.
Offline
ok so basically here we are. it works. the nice things to do
- minify javascript using some php lib from the web
- have the thing working if we try to combine js from remote sites (such as jquery from google cdn)
- comment the code
Offline
With my last commit, we can now omit script path for all jquery.ui and jquery.effects scripts...
It's really clearer like this:
{combine_script id="jquery" load="async"} {combine_script id="jquery.ui" load="async"} {combine_script id="jquery.ui.draggable" load="async"}
But maybe we can do better: template class can automaticaly load required script with this simple function:
private function load_known_required_script($id, $load_mode) { if ( isset(self::$known_paths[$id]) or strncmp($id, 'jquery.ui.', 10)==0 or strncmp($id, 'jquery.effetcs.', 15)==0 ) { $this->add($id, $load_mode, array(), null); return true; } return false; }
We call this function in add_inline function (before fatal error) and at the end of add function if required script are missing.
For example, we will be able to write {footer_script require='jquery.ui.xxxx'} without any combine_script before.
What do you think?
Offline
the only issue is if the script is already defined with load='async' on some other tpl already processed, and this inline script requires it on the footer.
note that I didn't have the time to do the dev but I will do it one day.
- Today: a footer script that requires script X; X cannot be loaded async because I didn't implement deferred execution of the inline script
tomorrow
{combine jquery.tiptip async}
{footer_script require jquery.tiptip}
will execute the footer script later on ...
A little bit tricky ... not sure if I was clear enough
Offline