× Joomla Facebook Connect support forum

Topic-icon JFBConnect modules and page load speed performance

Active Subscriptions:

None
Page load speed when employing JFBconnect and other social modules (or non-Social) and such is becoming an issue. On one of the websites where I'm employing JFBConnect, Facebook and some other social modules page load speed is suffering. I dug and pulled out some general KB stats on various plugins/modules. Here are some rough statistics:

JFBConnect:

JFBConnect System Plugin - JFBCSystem - 157 KB (58.6 KB gzip)
mod_sclogin (JFBC Login) - 2 KB (insignificant)
mod_jfbcrequest (JFBConnect Request) - 9 KB (insignificant)
mod_jfbcfan - 300-350 KB (big...)

And a few other social components / modules:

com_community (Jomsocial home page) - 640 KB
mod_sociable - 92 KB
mod_JoomlaShareThis - 268 KB

Add a few other slick modules, slideshows, content sliders, videos etc and this stuff adds up fast and takes a nasty toll. It doesn't take long for a 500 KB page to become a 1500 KB page. With JFBConnect it's the Fan page which really stands out. Is there anything that can be done to improve the situation? We want both cake and pie.
The topic has been locked.
Support Specialist
12 years 2 months ago #19658 by alzander
Our System plugin does the heavy lifting of what's required for JFBConnect. It includes the Facebook JS library, the JFBConnect.js library, and a few other thins. As you can tell (from what you post), we're pretty 'light' in the scheme of things. We have gone to great pains to make JFBConnect as fast as possible.

I'm not sure what you're measuring for the System plugin.. is that just how big the HTML returned is after page load? Another test is turning on Debug and seeing SQL queries and render time. Most of our stuff, if disabled, should be insignificant on the server side times, just so you know.

The JFBCFan module is 'fat' because you likely have user faces enabled. Each of those images, though small in looks, can be big. Facebook also isn't terribly efficient about loading them and can load more than are actually displayed on the page. If you turn off faces, you should be able to lighten that a bit, if you want.

Unfortunately, there's not a huge amount we can recommend as a lot of the stuff that's loaded is through Facebook. That causes requests to other servers and what comes back is generally out of our hands. With JFBConnect, I believe we have a max of 8 queries per page and try to load as little as possible.. as you can see above. It doesn't always mean things speed along, but there isn't much more to be done.

Hope that helps explain the situation, even though it doesn't necessarily answer anything.
The topic has been locked.
Support Specialist
12 years 2 months ago #19662 by alzander
I did just look at the source of your page, and you're extensions are loading jQuery multiple times. 1.4.4 is loaded once, 1.4.3 is loaded twice, and jQuery.noConflict is called like 3 or 4 times either on the page or through separate script files.

All of that takes processing time and extra trips for the browser to the server to fetch the files. There's lots of other examples of things that could be improved along those lines. Simply decreasing page size helps, but doesn't solve everything. Lookup requests and opening new connections for each file is a huge burden on browsers (and your server sometimes).

We use JCH_Optimize on this site to condense CSS and Javascript files together. It can be a bit tricky to make it work perfectly as some things don't like being compressed, but the benefit can be worth it:
extensions.joomla.org/extensions/site-ma...te-performance/12088

Hope that helps some more!
Alex
The topic has been locked.
Active Subscriptions:

None
12 years 2 months ago #19701 by bobmeetin
Yes Alex I'm just trying to sort out how to make things a little lighter wherever possible. Before "social media" it was certainly a lot simpler maintaining a fast website. Facebook offers some great value but with cost. Programs like jomsocial also offer value but with even heavier cost. At some point once I do have this stuff running as fast as I know how, then my job is to inform the site owner that this is the way it is...

The point about JFBCFan is a good one. I'll check into the avatars and such and run some tests. I use ySlow with Firebug for performance testing and look into the Components tab then at Images and JavaScript primarily. I also keep around a "simple page" without additional modules hanging around for comparison.

Jomsocial and some of the Jomsocial extensions are just plain fat. The extension, mod-activitystream, is a Jomsocial offshoot. so rather than forcing folks to access Jomsocial for recent activities, you enable this in a column. As 'configured' it carries the weight of about 335 KB. That's hefty in itself. I plan to develop a simpler PHP script to replace it. I'm certain that I can get it down to 30 KB or less, but it will take a little time.

I'm not using K3, but seems to me it comes with a monster stylesheet.

Loading jQuery multiple times - I have no doubt. Perhaps if I were a JavaScript, Mootools, jQuery developer I could sort this stuff out a little easier. Yes you see that jQuery gets loaded but sorting out how to disable the extras without breaking modules is a bit complicated. That's on my list, somewhere above draining the swamp. It would probably do me some justice to learn how to create a Joomla module or plugin (in my copious spare time) and see how/where to disable some of the extraneous stuff. Some modules offer functionality to load jQuery or not, even various versions of Mootools depending on the phase of the moon. I use to have a fling with Mootools.... There is also a lot of AJAX stuff to confuse the issue.

I've looked into various compression type components and plugins and have even do some performance testing on many. I don't have it enabled now on UR, but on some sites I have a CDN enabled. The performance testing I've done with the CDN (Amazon) shows modest gain at best, nothing to solve world hunger. The long and short of all of this is that too many bells and whistles bring a price. Page load speed is important. I welcome any/all suggestions along this path.
The topic has been locked.
Support Specialist
12 years 2 months ago #19706 by alzander
For jQuery, I wouldn't recommend mucking too much with the code unless you have too. As you mention, a lot of modules actually have a setting to enable/disable the jQuery inclusion if you know something else (JomSocial) is going to include it anyways. You should check the Ari Image Slider and YT Content Slideshow for that option.

K2 with a monster stylesheet is a great description. However, Javascript is what slows down the page the most. It takes time to execute, and it must execute on every page load. Things like CSS can be cached by the browser. Not that you shouldn't try to minimize where you can, but it gets into the realm of diminishing returns eventually.

CDNs are great for 2 reasons:
1) You'll get a bigger speed improvement as you have more load. Since your server isn't doling out static content, it can focus more on generating pages for users and getting them there quickly. On a 'new' site, you won't see a big improvement, but it's good to have and Amazon is dirt cheap (we spend like $2-4 per month for CDN through them)
2) CDNs are excellent if you have visitors from many regions. If you just visit from your site which may be around the corner from the server, a CDN may show no improvement or actually slow things down. For someone visiting from Japan though, your static content will actually be in Japan and load a ton faster than loading from Chicago (or wherever).

For suggestions, I'd recommend using Pingdom's Page Load Time Tool (free). It can check from different servers and give a history of results, which is nice:
tools.pingdom.com/fpt/

The main number is the # of seconds to load. That will include the render time on your server (server speed/component execution slowness, the transit time (file size), and domready time (time for Javascript to execute). If you see anything odd in there, let us know. I use that tool a lot and can decipher where likely issues lie.

One final note, if you're not using the Automatically login Facebook Users feature of JFBConnect, you can make the following quick change which has a (relatively) big impact on Javascript execution time. In the /plugins/system/jfbcsystem.php file, search for "status: true". You'll see it in a line that starts with FB.init. Change it to false. We'll be including that change in the 4.2 release.

Best of luck,
Alex
The topic has been locked.