fabrik 3 : merging and compressing JS files

[dee]

hi there, i just noticed that when i enable the module using a fabrik form (which basically consists of 8 input fields and some validation = email, required and also no datefield and no calendar), the additional JS-files that are being loaded are adding 430 KB to the site! this is a bit too much for my taste...

i found out that in previous fabrik versions one could do the following in order to use merging and compression of JS files:

administration -> components->fabrik->tables

click on the parameters tab

select yes for "Merged JS files" to create a single file containing all the necessary js files for you forms and tables.

select "JS Min" from the "Compress merged JS file" drop down to compress the files (the dean edwards packer option generates JS errors at the moment do dont use it)

​

QUESTIONS:

1. couldnt find those options ins fabrik 3, are there somewhere else, or is there a workaround?

2. furthermore, is the whole minified version of mootools-more really needed? (232,7 KB) is there a way to find out what more-files are really needed for ones fabrik-form, and then custom-build mootools-more?

3. are all those files really needed for my fabrik-form:
(as mentioned before, it basically consists of 8 input fields and some validation = email, required and also no datefield and no calendar)

art.js = 75,2 KB
calendar.js = 29,6 KB
form-min.js = 27,1 KB
encoder-min.js = 11,5 KB
date-min.js = 11,3 KB
element-min.js = 8,1 KB
window-min.js = 6,9 KB
head-min.js = 6,5 KB
core.js = 4,7 KB (being loaded by joomla already)
tips-min.js = 4 KB
fabrik-min.js = 4 KB
calendar-setup.js = 3 KB
icons-min.js = 2,3 KB
Form.Placeholder.js = 2.2 KB
Event.mock.js = 2,1 KB
mootools-ext-min.js = 1,3 KB
icongen-min.js = 830 B
field-min.js = 264 B
internalid-min.js = 118 B

4. is it possible that someone tells me briefly what they are doing and if i can manually load only the ones i need?

 

[jfquestiaux]

I can partially respond:
Fabrik3 uses a third party library - called head.js I think - that loads the Fabrik JS. This library requires that the files are not merged to work properly, so this options is not present in the settings anymore.
For compression, if you leave the default setting as is, the minified versions of the Fabrik JS are loaded (with some exceptions maybe according to your list). Its is only if you set debug JS to "ON" that you have the full version (for debugging purposes).

Regarding the need of loading all theses files, it is a question I asked myself many times and I'd be interested too in the answer.

 

[felixkat]

I believe the main reason to use head.js was to make sure the JS files are available, (i.e loaded), when they are called in a form.

I'm not totally convinced that head.js is more efficient in terms of a networking perspective but it does ensure the files are there at the right time and should theoretically prevent browser lock ups.

also no datefield and no calendar

Well you do kind of... Every new list automatically creates a datetime element which uses the same js as a normal date element.... which has a calendar facility.... hence the loading of the js files.

4. is it possible that someone tells me briefly what they are doing and if i can manually load only the ones i need?

The needed js files are compiled during Fabrik's core code and any published elements will load a js file regardless as to whether it is actually displayed or not. (You may choose not display elements via a custom template but the js file will still load).

If you look through your list pretty much all the js files are identifiable by their names. Everything that has some form of action has a js file, tooltips, date, calendar etc.


I know Rob was looking at alternatives to head.js but it isn't the most straight forward of processes changing to an alternative. As usual every time things start to settle down there's a new version of Joomla to destroy Fabrik's code... whilst Fabrik 3.0 and 3.1 are running side by side I doubt any major changes would take place.

 

[cheesegrits]

We use head.js to manage the intricacies of loading required files in things like popups, via AJAX, etc.

The mootools-more.js is managed by J!, not us.

And yes, all the files you listed are necessary.

-- hugh

 

[dee]

thanks so far!
i understand that all files are required.

but i think mootools-more.js is not managed by J!, but by fabrik, because if i disable the fabrik-module, mootools-more is not loaded. if i enable it, it is loaded... for me this is an indication that something in fabrik is loading this

am i right? could you please doublecheck?

you could try unset this in the index.php of the template, and you will see it will be loaded anyway if you have a fabrik module enabled (at least with my custom template it behaves this way). my custom template does not load mootools-more, i am 100% sure. i just even checked by adding unset($doc->_scripts[$this->baseurl.'/media/system/js/mootools-more.js']);
it gets never loaded! only if i enable the fabrik-module

 

[cheesegrits]

It's loaded by J! in the mootools behavior framework, if $extras is specified. See libraries/joomla/html/html/behavior.php.

We specify $extras, as there are some moo classes we use which aren't part of the core.

In the past, we used to maintain our own 'extras' library for Mootools, with only those classes we needed, prior to J! providing the Moo framework as standard in 2.5. But that would cause nasty conflict issues if we tried to do that now. So it's an "all or nothing" proposition, using whatever J! configured their -more lib to contain.

-- hugh

 

[dee]

i understand. thanks for clarifying this! as i see this now, fabrik3 is a great tool to use for easy to build bigger DB-apps (where loading all this overhead would make sense), rather than for just small-to-large custom forms (which one could code himself using mootools, or use other form-extension if the features needed are present)

 

[cheesegrits]

It works perfectly well for smaller to large custom forms. The JS loading really isn't much of an overhead. If you look in something like Firebug, at the Net tab, and see the async load times, it's very rare that the JS is still loading after all the other assets on a typical page.

People get hung up on file size, which may have been an issue 5 years ago, but with ubiquitous nature of broadband, improvements in browser async loading and caching, and the overall increase in payload size for the typical page ... JS file size really isn't a big deal.

If it is, and shaving a few hundred KB off of the first page load (before your client has the files cached) really matters, due to server load and speed requirements, then a generic application builder probably isn't for you anyway. You'll be needing to worry more about saving cycles and memory usage on the server side and other performance improvements that you can't get out of anything but a custom built app.

-- hugh

 

[felixkat]

Just to put a friendly argument on two points....

JS file size really isn't a big deal

It is when you pay for bandwidth usage.

However something like this could fix that.

http://extensions.joomla.org/extensions/core-enhancements/performance/content-networking/6981

then a generic application builder probably isn't for you anyway

Some people don't have a choice, they use Joomla because it's easy to use and \ or they don't have the finance or knowledge to build something from scratch.


Just my honest opinion though....

However I think the point ...

In the past, we used to maintain our own 'extras' library for Mootools,

.... outweighs most arguments anyway as that used to be a nightmare and that's just coming from somebody who used to just read about the issues.


.

 

[cheesegrits]

I'd argue that if one JS file is making a significant difference to the bandwidth cap on your hosting plan, then you need a different plan. But yeah, point taken. Although as you surmised, it'd have to be a cold day in Hell before we went back to maintaining our own Moo libs.

-- hugh

 

[rob]

it'd have to be a cold day in Hell before we went back to maintaining our own Moo libs.

Just to clarify why we did have this. It was nothing to do with mootools-more, but rather the fact we were trying to maintain compatibilty between mootools 1.1 and 1.2 whist using the same code base.

I'm almost done with replacing head.js with requirejs which from my testing handles the js file dependancies in a much more robust fashion. This is going into the joomla3 branch, and thus won't get implemented in Fabrik 3.0.x / Joomla 2.5

art.js = 75,2 KB
icons-min.js

- these 2 may get deprecated in Fabrik 3.1 for Joomla 3 - it depends if I can replace them with bootstrap alternatives. They're used to render popup window buttons as svg's

 

[dee]

thanks for clarifiying.

@cheesegrits:
i was looking at the file-size / bandwidth issue from a SEO point-of-view... it IS important nowadays that pages load fast (even though bandwith is not anymore an issue for most users) because this gives you an SEO-advantage. also it is an issue for mobile-users, where the bandwidth for their smartphone might be limited or their internet-flatrate-surfing-speed is leveled down after a certain amount of MBs...

 

[davez]

I seem to have a problem where, even if I set allow fabrikdebug to No, it is still loading the non-minimized javascript files. I've tested it. What could I be doing wrong here?

 

[rob]

do you have Joomla's global debug option turned on?

 

[cheesegrits]

I understand that pleasing The Goog and friends is good for SEO, but there really isn't much we can do about that. Our JS is (pretty much) all essential for the functionality of a general purpose application building toolkit. Our focus is on rapid development of apps and their user interfaces. We play nicely with J!'s SEF routing, and do what we can to keep our page loads as small and efficient as we can. But it's always going to be a trade off.

If your priority is SEO rankings, then you may need to look at developing your own app, from the ground up.

-- hugh