Webpage loads slow with JFBConnect active

Can you run 2 different tests with GTMetrix, below, and link to the result reports from each, like:
gtmetrix.com/reports/www.study-smart.net/JLEfPhgj

On that report, the full page load time was 6 seconds, which is a bit long. However, many of the files and assets that were loaded were after the page is rendered, like avatars from Facebook and other such things that aren't critical. The biggest issue I see is in the "Timeline" section. The page itself takes 2.74s just to be generated on the server before anything is sent back to the user. That could mean:
* Too many extensions installed. Try disabling any system plugins or removing whole components that you aren't using
* Your server is overused. If you're on a shared, very cheap host, I'd consider upgrading

I hope that helps get you started, but if not, let us know the reports with JFBConnect enabled and disabled so we can investigate further.

Thanks,
Alex

There seems to be a bit of variability here. My original report, with JFBConnect enabled, is very similar to your report *without* JFBConnect.

My Report:
Time to load: 6.29s
Assets loaded: 83
Page size: 1.06MB

Yours without JFBConnect
Time to load: 5.29s (-1s)
Assets loaded: 59 (-24)
Page size: .99MB (-.07MB)

Yours with JFBConnect
Time to load: 7.4s (+1.11s)
Assets loaded: 83 (-)
Page size: 1.1MB (+.04MB)

As you can see, there is some improvement without JFBConnect from *my* test. Your test with JFBC seems much worse than what I saw. I'd have a look at where the extra time and variability is coming in, which again, I'd suggest is mostly in the initial GET request for your page. Re-running the tests multiple times may help to provide a better average of how different the load time is between enabled and disabled as well.

Beyond that, can you explain more about how you're disabling JFBConnect as well? Are you only disabling the SCLogin module, or are you disabling the plugins as well?

Thanks,
Alex

The variability could come from the network latency. I am testing closer to my server and I don't get as much variability.

The benefit of using a tool like GTMetrix is that all the tests are run from their servers, which eliminates latency between you or I. There's definitely some latency and variability between the 3 tests that were run, and again, I'd suggest re-running tests from GTMetrix, or another online tool, repeatedly to get the overall range of response times.

As for what you're testing, there's a lot of features in JFBConnect that would still be enabled if you are only disabling the SCSocialStream module. If that issue is the problem, that helps narrow down quite a few things. Can you try the following:
* Make sure the "Cache Duration" setting is non-zero. I'd recommend something like 30, which means the feeds shown will only update every 30 minutes.
* Make sure the "Enable Debug Mode" setting is "Off".

Thanks,
Alex

Cedric,
That's the whole purpose of the caching. When it's enabled, then the outgoing communication to Facebook is only performed every 'x' minutes, where 'x' is whatever time you've set for the caching.

For example, if caching is set to 15 minutes, it means that 1 page load every 15 minutes will take a little longer to load. The amount of extra time that page will take will depend on:
* How many feeds are being shown in the social stream
** Each feed, even from the same social network, will add some extra time
* The speed of your server
* The internet connection of your server
* The location of *your server* in relation to the nearest social network server that you are pulling data from

Outside of that one page load that is slightly slower, the Social Stream module completely caches the feed data and output HTML, which means that the render time on cache-hit pages should not have any performance impact.

The above has been tested and proven out on multiple dev sites and thousands of user sites that are using the Social Stream module.

I hope that helps explain more, but if you're still running into issues, here's what I'd recommend:
* In the Social Stream module, disable all the streams from showing. Test again (a few times) to see the difference.
* Re-enable each feed one by one and re-test. Determine if there is one feed that is causing more of a delay than others. That could indicate a mis-configuration, expired token (preventing caching) or some other problem.

Thanks,
Alex