Just some results from some informal speed testing using YSlow:
Moodle 2.0 (http://demo.moodle.net ) takes about 12 seconds to load.
"Grade F on Make fewer HTTP requests
This page has 15 external Javascript scripts. Try combining them into one.
This page has 5 external stylesheets. Try combining them into one."
http://mootools.net/slickspeed/ shows that YUI 2.8.2 is 40 (!) times slower than jQuery 1.5.1 and by far the slowest JavaScript framework. Unfortunately there is no testing for YUI 3 available.
JavaScript performance comparisons (was Re: Dear moodle, can we stop having the YUI lib yet?)
by Frank Ralf -
Number of replies: 22
You can create such tests yourself in www.
Visit http://jsperf.com/yui3-vs-jquery/6 and try the simple selector test there with a couple of browsers. I tested my browsers in a Windows 7 PC (the one I am using right now for writing this post) and the results look a little amazing:
I tested the latest jQuery 1.7 (released yesterday) from http://code.jquery.com/jquery-1.7.min.js and YUI 3.4.1 from http://yui.yahooapis.com/3.4.1/build/yui/yui-min.js with
<div id="test">
<div class="testlink">
<a href="#" id="linkone" title="test">test link</a>
</div>
<div class="testmenu">
<ul>
<li class="menuitem itemone">
<a href="#" title="item 1">menu item 1</a>
</li>
<li class="menuitem itemtwo">
<a href="#" title="item 2">menu item 2</a>
</li>
<li class="menuitem itemthree">
not clickable item 3
</li>
</ul>
</div>
</div>
<script>
var selectors = ['body', 'div', 'body div', 'div a', 'div > a', 'div[class^=test]', 'div, li, a', '.menuitem', 'li.menuitem', '#linkone', 'div#test', 'a[title*=item]', 'a[title=test]', 'li:nth-child(even)', 'li:nth-child(odd)', 'li:last-child', 'li:first-child'];
</script>
and code for jQuery 1.7 was
for (var sel in selectors) {
$(sel);
}
and for YUI 3.4.1
YUI().use('node', function(Y) {
for (var sel in selectors) {
Y.one(sel);
}
});
IE7, IE8 and IE9 are actually different modes of my IE9 so I suppose that native IE7 and IE8 might be slower
In this test YUI is 97% slower than jQuery - different tests may give different results...
Hi Mauno,
Thanks for that link. I can confirm the results:
Testing in Firefox 3.6.23 on Windows 2000: YUI is 96% slower than jQuery
Thanks for that link. I can confirm the results:
Testing in Firefox 3.6.23 on Windows 2000: YUI is 96% slower than jQuery
I had a look at the interesting utitility and thought I would try wrapping the js operations in a for loop to repeat them 100 times. I cannot say why but this seems to drastically reduce the differences in the speed of execution of the YUI and JQuery scripts although jquery still appears to be a just a little faster or up to double the speed in some browsers.
Clearly, the YUI example is including the Y.use line in the timing, but the jQuery code is not including anything equivalent. And clearly the Y.use is dominating the timing.
I don't know YUI3 well enough but is this any better:
http://jsperf.com/yui3-vs-jquery/11
( I added a couple of unnecessary functions to jQuery example to make it more equivalent...) - still jQuery dominates...
In reply to Mauno Korpelainen
Re: Dear moodle, can we stop having the YUI lib yet?
by Christoph Stadlbauer -
"The jQuery and $ objects are globals", so if we want to compare we would have to define Y globally (YUI is sandboxed by default).
As Tim already stated the YUI.use() is dominating the timing.
Defining Y globally leads to much better timings for YUI, jQuery still wins the race (I'm not sure what happened to my Opera).
http://jsperf.com/yui3-vs-jquery/13
It's still not equivalent because in this example yui includes only the 'node' component.
Cheers, Christoph
Jamie,
I am not a javascript guru but most likely using a loop inside function (in your YUI example) is faster than using the same loop without function (in your jQuery example).
Or for example using "normal javascript"
function testfunction() {
var i, s = '';
for( i = 0; i < 20; i++ ) {
s += i;
}
}
testfunction();
is about 30% faster than
var i, s = '';
function testfunction() {
for( i = 0; i < 20; i++ ) {
s += i;
}
}
testfunction();
in most current browsers.
In this case there are differences between browsers but jQuery is still clearly faster than YUI3
Just for reference:
* http://net.tutsplus.com/tutorials/javascript-ajax/10-ways-to-instantly-increase-your-jquery-performance/
* http://addyosmani.com/blog/8-jquery-performance-tips/
Might give some hints what makes certain scripts slower.
hth
Frank
* http://net.tutsplus.com/tutorials/javascript-ajax/10-ways-to-instantly-increase-your-jquery-performance/
* http://addyosmani.com/blog/8-jquery-performance-tips/
Might give some hints what makes certain scripts slower.
hth
Frank
How does that saying go? "There are lies, damned lies, and benchmarks"? I'm not saying that YUI isn't slower then jQuery, but that benchmark on its own has limited applicability. For one thing, YUI is on par with jQuery for everything except for the nth-child-like selectors. I don't see any of those selectors used in Moodle, so those comparisons aren't relevant for core Moodle. (Maybe it's relevant for 3rd-party contributions.) For another thing, selectors are just a tiny part of what the JavaScript does. And finally, for the tiny amount of JavaScript that Moodle has, I think that the user, and not the JavaScript library, is the bottleneck. (Again, it may be more of an issue for 3rd-party contributions, if they do more fancy JavaScript interactions.)
In reply to Hubert Chathi
Re: Dear moodle, can we stop having the YUI lib yet?
by Mauno Korpelainen -
Where is your reference when you say that YUI is on par with jQuery for everything except for the nth-child-like selectors???
Moodle.org is using a powerful server but how about those "normal sites" that may have serious problems with moodle 2 performance - many people have reported in these forums loading times like 15 to 30 seconds in different activities ... on slow computers, connections or sites it might matter how many unnecessary files you need to load or how fast your javascripts run.
But I am not a developer, I did not start this discussion and I have no intention to rewrite javascripts of moodle so maybe it's time to shut my mouth again and wish you all good luck with YUIs
However one thing is sure - USER is not the bottleneck in performance issues...
Hanging here in these moodle.org forums is actually wasting my time a lot more than any javascripts
In reply to Mauno Korpelainen
Re: Dear moodle, can we stop having the YUI lib yet?
by Hubert Chathi -
Just to clarify, since this thread is huge and unwieldy, I was referring to the benchmarks that Frank posted at: http://mootools.net/slickspeed/ If you run that test, and watch the numbers (at least on my machine), YUI 2 keeps up fairly well with the others until the nth-child selectors, where YUI 2's numbers explode.
The user may not be the bottleneck in all performance issues, but as far as JavaScript performance goes (note: I'm not talking about loading times, but about actually running the JavaScript, so the server's power has nothing to do with this), for what Moodle uses JavaScript, which is fairly basic user interaction, I doubt that JavaScript performance is very noticeable.
The one place there is a really noticable performance problem is when you have to wait for the HTML editor to load. It is particularly bad when you are editing a multiple choice question, since that form has a ludicrous number of editors. Fortunately, it does not much longer to initialise 30 intsances of TinyMCE than to initialise one. However, if anyone wants to dig into JS performance, that would be the place to start.
In reply to Mauno Korpelainen
Re: Dear moodle, can we stop having the YUI lib yet?
by sam marshall -
Client-side JavaScript performance should not be impacted, at all, by the server capacity. I'm pretty sure the OU's Moodle 2.1 system has more hardware power than moodle.org, and is used much more lightly at present, but trust me, our JS is still a bit slow (especially if you are using IE7). Similarly, even if you run your server on a 33 MHz 486 that you pulled out of a skip, JavaScript performance for users will still be just as 'good'.
Selector performance differences are probably not significant. I went to some selector test on jsperf.com and it shows essentially the same speed (YUI3 slightly faster) in my browser. This is probably the most common case.
Even if it's not, if you have a selector performance problem the way to optimise it is not to change JS library. The way to optimise it is to ensure you're only searching the correct scope. For example, if you search the whole document tree for .frog this will take a while whatever library you use; if you only search inside a specific, smallish div for a.frog, then it will take basically no time whatever library you use.
Moodle 2 JS performance appears to be poor but I don't know what the reason is. For example, JS libraries should only be loaded once, as in once per user/browser; any future visits should use cached version (unless user clears cache or runs out of cache space etc, or unless we version-up the library). Is this really happening reliably in Moodle or is the browser expensively reloading [or has-it-been-updated testing] junk every page? Not sure. Unfortunately nobody here has had any time to do performance analysis on our Moodle 2-based system. The worst offender here is probably TinyMCE, though, and not YUI at all; that's what seems to really kill it when you're using IE7...
One thing that is clear is that using YUI3 library doesn't have to cause performance problems. I just looked at yahoo.co.uk and it always seems to load acceptably fast, while including YUI3 libraries (about 140KB of them if you do a full reload, seems).
--sam
In reply to sam marshall
Re: Dear moodle, can we stop having the YUI lib yet?
by Mauno Korpelainen -
With server capability I was thinking about my test server that often tends to respond slower than moodle.org server - but you are probably right and in such cases the problem might be somewhere between server and PC...
Anyway I made a quick audits test. Chrome is one of the fastest browsers and when I inspected http://moodle.org/course/view.php?id=5 following things happened (non-busy Saturday, about 10 visitors in moodle.org):
Loading the page took 5.5 seconds - as a normal user (not administrator)
The main file view.php alone would have taken 1.95s (DNS lookup 0 - connecting 0.180s - sending 0 - waiting 1.64s - receiving 0.132s)
and other 42 http requests were 4 stylesheets, 10 javascript files and 28 images.
I have a 100M cable connection at home and receiving of each file took about 1 ms/file so it's not a big time waster.
Time used for loading first 2 yui_combo.php stylesheet files + styles.php took about 0.2s and the last yui_combo.php 0.45s (total 0.65s)
Loading 10 javascript files took about 0.2s to 0.6s per file and the last javascript file was loaded about 3 seconds after view.php
Images were loaded at the same time.
Next I loaded http://moodle.org/mod/forum/discuss.php?d=188627
Loading this long discussion took 10 seconds with 79 http requests ( 5 stylesheet files, 12 javascript files and 61 images )
The main part of extra loading time could be explained by the bigger number of images and some example images are also larger size.
Loading first 3 stylesheet files took about 0.4s, loading the next css file 0.3s and finally the last css file 0.3s (total 1s)
12 javascript files were loaded in about 4 seconds
As a non-performance-expert analysis
- dropping yui css and using only theme css would have given about 0.5s benefit ( 5% )
- dropping yui javascripts or using fewer files might have given 3s benefit ( 30% )
- using one sprite for most course images might drop 1 second from loading times
- loading times of user images and course content images is hard to control
I did not use editor or other tools loading extra javascripts - I was only browsing moodle.org with Chrome Inspector Audits enabled.
PS. see also http://moodle.org/mod/forum/discuss.php?d=188627#p825849 ( TinyMCE part )
Edit: and in my Chrome yahoo.co.uk main page is loading the main file, 3 advertisement iframes, 2 stylesheets and 2 yui + 4 other javascripts + images in about 2 seconds = less files to load, less time to spend waiting.
When you say loading a page here took 5.5s, that does not mean that the user had to wait 5.5 seconds. I just means that it was 5.5 seconds before the last bit if JS and image loaded. When browsing around these forums, particularly when there are only one or two unread messages in a thread, I have normally finished reading before teh browser's loading indicator stops moving. You only have to wait for view.php to load (2s, still to slow. We should be aiming at sub-1s page-loads.) That is, the page looks fine with just the HTML and the basic CSS.
Compare that to http://www.moodlenews.com/. When Moodlenews is running slowly, it just loads the page header (up to, but no including the black bar) and does not reander any more until the rest of the page has loaded. That is irritating.
So, we are avoiding some obvious mistakes in 2.x. I think what we are seeing here is the benefit of moving all the JS to the page footer. I'm glad that wasn't a waste of time.
Still, there is more work to do.
Yes, you are right like always Tim, users don't need to wait 5.5 seconds but most users do wait until all parts of page are loaded
I made a new test today and you can see details from
http://www.webpagetest.org/result/111106_8K_23FAG/1/details/
http://www.webpagetest.org/result/111106_F0_23FBT/1/details/
This test is not made from Finland with Chrome but from Dulles, VA with IE8 and in both cases the main content was done in less than 2 seconds but the interesting point is what happens after the green line and the blue line when you check those details...when moodle loads docks and blocks hiding stuff and other yui widgets finishing after 6.809s in the first case and after 14.477s in the second case.
I agree also that you all have done really great things in tuning the performance of moodle 2 - and I am no way trying to underestimate the value of all the hard work done - for example Petr and You have definitely used a lot of your work time in getting things behave right in all browsers (easy to remember those IE issues) and I believe this layout system of moodle 2 is getting better all the time... Thanks for all those improvements!!!
You can also see from http://www.webpagetest.org/result/111106_8G_23FGC/
and
http://www.webpagetest.org/result/111106_8G_23FGC/1/pagespeed/
why http://www.moodlenews.com has really totally different kinds of problems than moodle.org pages - and it is not a moodle site, it's a WordPress site that could improve it's performace a lot as well. Most "normal moodle sites" on cheap hosts may however have similar problems since they may not be able to tune their site performance the same way as moodle.org or open.ac.uk
In reply to Mauno Korpelainen
Re: Dear moodle, can we stop having the YUI lib yet?
by Mauno Korpelainen -
One funny thing is that when I loaded http://www.moodlenews.com/ from Finland with Chrome Audits it only took 2.7s - the main file was done in 1.64s
Sounds like there might have been something strange going on in godaddy.com / bluehost.com during the test run of http://www.webpagetest.org/
Anyway it's just nice if moodlenews.com is responding again in a reasonable time - it's a really enjoyable site to read...
Mauno - interesting stats. My question (not for you, in general) is why is it loading those JS and CSS files - a typical moodle pageload should make 0 JS and 0 CSS http requests because all those files should be in cache. Definitely this should be true within a session but it should also be true (or nearly true) between sessions if you haven't cleared browser cache. If it isn't true, especially in a session, then this would be why performance is poor.
This could be a problem with the analysis tool you are using or it could be a genuine problem. [One thing to bear in mind: turning on debug options like theme designer mode, etc, explicitly kills cacheing. It's ok if it makes way too many requests with debug options so there is no point looking at performance on dev servers unless you know you turned those options off.]
Regarding TinyMCE performance there is no real problem with TinyMCE performance in Chrome or Firefox (and IMO the problem with 20+ copies of TinyMCE is more a problem for the pages that have kind of bad user interface). Where there is a problem is in IE7 and to a lesser extent IE8 - and this problem exists there with 1 copy of TinyMCE, or is much worse with 2 copies, with 10 it's horrific...
Just a general point about AJAX and JS support - I think there's a real and severe risk of making the interface worse with AJAX (as happens if you turn it on for Moodle course pages). 'Keep it simple, stupid' is a good design principle for projects that don't have a very strong design lead. If you look at real-world AJAX use there are some great examples but if you look at it on smaller sites there is also a lot of horrible junk out there.
I think in Moodle it would be very helpful for usability if any AJAX use focuses strongly on progressive enhancement that does not majorly change the interface over the non-JS version. (Like, a search box where it updates in the page when you search instead of having to load a whole new page; that kind of thing that makes it better but isn't an obvious change.)
--sam
Well, as for the "tiny" amount of JavaScript:
* http://demo.moodle.net/ loads in 12.5 seconds with JavaScript and in 3.5 seconds with JavaScript turned off
* Moodle's YUI folder is more than 20 MB large, the whole JavaScript of Drupal is 900 KB for comparison.
(I know this is over simplifying things, but nonetheless ...)
* http://demo.moodle.net/ loads in 12.5 seconds with JavaScript and in 3.5 seconds with JavaScript turned off
* Moodle's YUI folder is more than 20 MB large, the whole JavaScript of Drupal is 900 KB for comparison.
(I know this is over simplifying things, but nonetheless ...)
The YUI folder contains
- 3 versions of each JS file (minified, normal and with debug statements)
- images and CSS as well as .js
- all the different YUI modules, including the ones Moodle does not use (yet)
Attached are the files sizes of all the -min.js files in YUI. (Total 1.2MB)
(The command-line magic to get this is ls -l 3.4.1/build/*/*-min.js | cut -c 34-41,61-)
How many of those 251 files you listed are actually used by moodle?
In jQuery you only load one main file - 32kb, 92KB or 244KB - and if you create themes with jQuery UI css + icons (13 sprites) usually take about 50 or 100 kB depending on UI (mobile or desktop). If you want to use jQueryTools instead of jQuery UI you get the whole package in extra 4.45kB
So when you use jQuery you load kilobytes - not megabytes of files.
If you use
<script src="http://cdn.jquerytools.org/1.2.6/jquery.tools.min.js"></script>
you need only one http request and get both the latest jQuery library and all the jQueryTools in a single file... the same widgets you see in http://flowplayer.org/tools/index.html
Rule number one in YUIs principles for best performance was
1. Make fewer HTTP requests
In reply to Mauno Korpelainen
Re: Dear moodle, can we stop having the YUI lib yet?
by Hubert Chathi -
Here is my understanding of the "Make fewer HTTP requests" situation: YUI only loads the parts of itself that it actually uses, which is good, because you don't want to load all 1.2MB of it all the time. However, that means that it's split into a whole lot of files. Different pages use different parts of YUI (and plugins may use other parts that aren't used by core Moodle), se we can't just "still everything that Moodle uses in one file and load it". However, we probably don't need all the granularity that YUI gives us. So I think that the only way to make fewer HTTP requests is to figure out what components are always used together (or what can be rolled together without harming much), which files are always used, etc., which seems like a very big task.
BTW, it may be useful to look into using SimpleYUI, which bundles together a bunch of common YUI functions into one file (although that blog post says to not use SimpleYUI when performance matters).