Dramatic Performance Improvements in 2.0

We moved all scripts to the bottom of the page, reducing startup time by a large margin, but this will break some scripts. The best way to stay compatible across 1.x and 2.x is to convert your JavaScript to AMD.

After this change, wait time for first render of community.elgg.org over 2G* will drop from 15 seconds to under 2 seconds. Waiting 15 seconds for anything online is an unacceptably bad experience for any user, so we recently landed a Pull Request which loads all scripts in the footer of the page, and we’re excited about the impact!

Loading scripts in the bottom of the page is a well-known technique for improving first render time, because scripts loaded in <head> prevent the browser from rendering anything until they are downloaded, parsed, and executed. By moving all scripts to the footer, rendering is no longer blocked and the browser can show something to the user as quickly as possible.

We waited until 2.0 to make this change because inline scripts in views will almost certainly break if left unaltered, as resources commonly relied upon will no longer be available until the document footer. To ease working around this issue, we’ve provided a tiny little implementation of AMD’s require function for wrapping your inline scripts.

For example, let’s convert this code snippet:

$(function() {
 $('.my-widgets').widgetize(elgg.echo('widget:title'));
});

This code relies on the elgg library, jQuery, and a jQuery “widgetize” plugin**, so we just have to wrap the script with AMD’s require(), listing those dependencies explicitly:

require(['jquery', 'elgg', 'jquery.widgetize'], function($, elgg) {
 $(function() {
   $('.my-widgets').widgetize(elgg.echo('widget:title'));
 });
});

That’s it! The script content hasn’t changed at all, but now the system will make sure its dependencies are loaded before it’s executed.

In this case we can simplify further: Since this is run asynchronously at the end of the document, we know the DOM is already “ready” and the $(function() {}); wrapper is no longer needed:

require(['elgg', 'jquery', 'jquery.widgetize'], function($, elgg) {
 $('.my-widgets').widgetize(elgg.echo('widget:title'));
});

You can try this out by installing Elgg’s “master” (2.0) branch. Let us know what you think of the speed improvements. We welcome feedback on how to make migration easier/smoother. If you’re feeling especially excited about this change, you can even help us comb through the inline JS within core itself and make the conversion. We’ll need to fix all the new script errors before we release 2.0, so help is appreciated!

* I use 2G as the example because it is the typical connection that the world’s newest internet users will have over the next few years. Also, it helps to test performance under adverse conditions. 2G is a nice approximation of generally slow/flaky connections. If Elgg can perform well even under poor conditions then you can be pretty sure it performs even better under more optimal conditions!

** This widgetize plugin is made up as an example. We’re happy to guide you in setting up real require() dependencies.

  • After 5 hours no WOWs yet? Ok, first is mine.

  • great! i realised this was needed when i was optimising my site a while ago.. and concluded that i would just need to let the core team do it.
    i still have a lot of plugin code to update before i can use any version of elgg newer than 1.8. is it worth me coding my site changes for 2.0 instead of using 1.11 etc ?

  • Code against 1.11 using the best practices like AMD and you'll have a much easier time moving to 2.0. In this case you wouldn't have to make any changes as long as you're using best practices.

    I hope that continues to be true of other breaking changes, but we'll see.

  • "WOW"... yes, on the one hand. Surely, any improvements in performance is welcome. On the other hand, work, work, more work to get the 3rd party plugins updated. :-)

    If you’re feeling especially excited about this change, you can even help us comb through the inline JS within core itself and make the conversion. We’ll need to fix all the new script errors before we release 2.0, so help is appreciated!

    I would like to add that - if you are even more excited - you can also help to update the code of 3rd party plugins. At least for me I can say: any PRs that convert the JS code to AMD modules would be welcome for my plugins. Best would be to fully convert the code to AMD modules right away instead of using the "quick fix" workaround. Then it wouldn't be necessary to touch the code a second time later AND it would also already work on 1.X (at least 1.9 or newer). I don't know what other BC breaking "surprises" might be introduced in Elgg 2.0 but anything that could be already updated in advance would surely reduce the waiting time for updated plugin versions after it got releases. Any frankly speaking, I surely don't have the time to fix all plugins in just a few weeks...

  • Awesome!  I will give it a try to help with this as it seems not too complicated but time-intensive. I will combine it with learning more about git and elgg. But I cannot promise that my still very basic coding skills are good enough to help with this

  • You should include a chat on elgg 2

  • Thanks Evan for great points! 

  • Nice work ! Would it be possible to automate the wrapping, or is that too complicated ?

  • Can someone please share the exact download link for Elgg (master) 2 branch?

    Has any widely used plugins like photo/gallery, wall etc being started to be upgraded for 2 or are they already working with 2? Many thanks.

     

  • Can someone please share the exact download link for Elgg (master) 2 branch?

    https://github.com/Elgg/Elgg/archive/master.zip

    Has any widely used plugins like photo/gallery, wall etc being started to be upgraded for 2 or are they already working with 2?

    They are (almost) already working with Elgg 2.0 if was created for Elgg >1.9

  • Thanks a lot RvR

    I think I already downloaded that, but seem not to find the Elgg 2 mentioned in it, it seems it says 1.11.2. Is it mentioned in any of the files in the master that it is "2"? Just curious, is anyone running any site or demo or test site on Elgg 2 (any url) ?
     

    The plugins working are a great news, so I can test right away, and I wish, if that is so, may the Devs consider releasing an Elgg 2 alpha or beta just now.

  • @kahna, we're not quite ready to start shipping pre-releases of 2.0 yet. Check back again on July 5.

  • @kahna: and it might be a bit too optimistic to expect existing plugins written and released for Elgg 1.9 - 1.11 to work without modifications on Elgg 2.0. The most noticeable BC breaking change is the handling of script elements that might require the plugins using them to be rewritten (the script elements at least). If a plugin doesn't use own JS code changes are good that it will work without modifications on Elgg 2.0. But the larger, more complex plugins will need some updates.

    I would suggest not to hurry. As Evan said, feature freeze for 2.0 is to be expected on July 5. Then it might take a bit more time until the final 2.0 release is ready. And then it might take even a bit longer until the plugins are getting updated. Hopefully, it's not as bad as with Elgg 1.8 but it's better to wait with testing and releasing updated plugin until Elgg 2.0 is feature complete.

Evan Winslow

Software Engineer at Google. Elgg enthusiast. I wrote the Javascript and CSS frameworks for 1.8.

Latest comments