14 HTTP requests

ChrisGwynne

Pretty sure I brought this up with version 1 of Vanilla too..

Is there really a need to make 14 http requests for each page before it's even rendered? There's so many calls for separate JQuery files its unbelievable.

Louis

v1.2 has apparently received much optimization in browser performance like this. As for v2, I've been raising the idea of compiling all CSS and JS into one minified file each in a production mode, and updating it manually or when plugins/apps/themes are enabled/disabled. Not sure yet of the specifics, though I'd also like to see an option for using jQuery hosted by Google, since lots of people will have that cached already.

See also:

http://vanillaforums.org/discussion/10677/vanilla-2-inbrowser-speed-optimization/

http://vanillaforums.org/discussion/10690/theme-controller-overriding-and-javascript-excluding/

SubJunk

@ChrisGwynne: As Louis said, 1.2 is very optimised for that. We have raised the YSlow rating from 60 (D) in 1.1 to 91 (A) in 1.2.
We still have a few things to fix before it is released, but it shouldn't be too long now, and of course you can always grab the latest version from our SVN repository if you are feeling adventurous

luc

If you set up your web server correctly, it will only be requested once a while (depending on your expiry cache date), and not for everypage, and even once expired it will only be a 304/not modified, not the full file that will be sent.

Being modular, and being able to enable/disable application/plugins/themes that can add css and/or js adds an order of magnitude of things to think of before being able to put everything into a single minified js and a single minified css.

Stash

Yes, but it's still better to have it all concatenated and minified as a single, or fewer files and THEN compressed and cached

Given that 1.2's getting minify I wouldn't be surprised to see it ported to V2 as well.

garymardell

Don't combine the files into 1 single file as it will prevent concurrent downloading of files by the browser.

Also putting the javascript at the bottom will mean more can be downloaded at once by the browser.

Stash

Well you can argue the toss on anything being better/worse than anything else because not all situations are the same. Sometimes inline JS and CSS is the best thing to do from the point of view of speed - just look at some of Google's code. However, as a general catch-all improvement 1 single JS and 1 single CSS file is better than 5+ of each! Concurrent downloads be damned.

As a relatively simple improvement to the "1 big file" solution, perhaps we could have

$Footer->AddScript('javascript.js');

in addition to the

$Head->AddScript('javascript.js');

we already have. That way, scripts that can be deferred until the content has loaded could be specified to go in the footer. Then we'd have 2 big JS files, one set in the head and one set in the footer. Thoughts?

Dinoboff

@garymardell: For what I understand, parallel download is only good for libraries, not for dozens of tiny js or css files.

garymardell

@Dinoboff I just meant if you are combining tiny js files into larger js files then you could keep parallel downloading, by sticking them at the bottom of the body the page can be loaded at the same time.

Stash

Right, so what about my idea of enabling plugin authors to specify the footer for JS files? :P

Louis

@[-Stash-] (I hope the nickname highlighting works on *that*)

I agree about the footer bit. And I suppose scripts could also specify jQuery.ready for on-DOM load, although Google's idea of having JS that loads to write in further JS might be worth a look. The idea of turning JS from something dumbly loaded via HTML into something smartly loaded by JS as a platform itself might be worth considering. I love all the new MVC frameworks for JavaScript, or something I just discovered the other day-- CoffeeScript. I don't see why we can't treat JS more like PHP and optimize its hooks/execution the same way we do in Garden for PHP.

SubJunk

Yes, the footer idea is a good one. I think we can look at that for 1.2.1, because I want to release 1.2 as soon as we have resolved the current issues

Dinoboff

For Vanilla 2, the equivalent of Head::AddScript and Foot::AddScript would be too low level. Controllers and plugins should not have to guess how the scripts and style-sheets they require should be loaded.

Applications and plugins should instead list the ressources they can serve. A resource should have a name, a default location, a list of dependency (some other js or css script) and some flags (like "can be packed", "can be minified", "can be loaded asynchronously", "is a library", etc...)

Then the controllers should list the ressources a page needs and let Vanilla or a plugin add the scripts and stylesheets. Vanilla should have a naive implementation, adding all ressources inside the Head elements in the correct order. Plugins could implement different way to optimize loading so that admin can test and pick the best solutions for their forum (a forum that get most of its traffic from google will have different needs than a private forum).

Louis

@Dinoboff I agree about AddScript being too low-level, though I'm not sure if I want to require scripts by default to specify all that or list their resources. And themes should be able to override the JS of plugins where necessary, as JavaScript often refers to HTML which could change if views are overridden. My comment was perhaps we should add or integrate some kind of JavaScript framework for both loading and overriding JS in the same way that we can use hooks within PHP. Ideally, we could mimic something of our views structure now, in JS, such that a plugin modifies JS objects which are then applied using JS in the theme to the HTML given, and all that is compressed when moving into production mode.

Dinoboff

When trying to optimize css and js file load you need some information about the files: can a script be packed (eg: Scriptaculous cannot), has it been tested minified, in which order should the files be loaded, etc...

It is better for the developers who will use these libraries if the providers of the library define all metadata; it's also "DRYer".

In Vanilla 1.2, to add jQuery and your plugin (and allow them to be packed), you will have to remember the recommended order of loading for jQuery and its plugins:

$Head->AddScript('js/jquery.js', '~', 190);
$Head->AddScript('extensions/MyExtension/functions.js', '~', 350);

If you are using MooTools, you have to guess since the framework or the plugins Vanilla 1.2 includes don't use MooTools.

I would have like better:

$Context->RegisterScript('extension/Myextension/function.js', ['js/jquery.js']);
$Page->Require(''extension/Myextension/function.js'')

About js and themes, there are patterns that allow default settings to be customised:

(function($){


	$.askConfirmation = {
		selector: definition('askConfirmation.selector', 'form.important'),
		prompt: definition('askConfirmation.prompt', 'Are you sure?'),

		init: function() {
			var self = $.askConfirmation,
				e = $.Event("askConfirmationInitStarting");

			$(window).trigger(e);
			if ( e.isDefaultPrevented() ) {
				return;
			}

			$(self.selector).submit(self.onSubmit);
		},

		onSubmit: function() {
			return confirm($.askConfirmation.prompt);
		}
	};

	$().ready($.askConfirmation.init);

})(jQuery.noConflict());

To overwrite the selector, the theme can add the following script at the end of the head element:

jQuery(window).bind('askConfirmationInitStarting', function() {
	jQuery.askConfirmation.selector = 'form.very.import';
});

Or If I understand what Garden's "definition()" can be used for, it can just add an entry for the "askConfirmation.selector" definition.

Louis

I wonder, though, if applying jQuery-claypool as a JavaScript MVC layer might not result in a better, clearer experience? Models can then be cleanly modified before being applied using views that can be overridden in themes, just as in PHP, but with JS. The only question might then be how tightly could they be integrated before becoming inflexible like some of the current code. The only problem with hooks or metadata is remembering to provide it in the first place!

Stash

As a plugin developer I would be happy to provide meta data in the plugin if it meant less people had problems using the it (read: there were less support questions!).

Dinoboff

@louis I agree about metadata. However if by default all your ressources are suppose to be packable for example, the developer will have to update the metadata when a user report something went wrong when a packer extension was on.

It is too late for Vanilla 1; packer extensions can break extension's js and css loading, not many developer will debug and update their extensions.

Stash

Never say die!