Performance and Facebook Fan Page

There really aren't any great things we can do on our end, and we've been noticing a bit more of a slowdown recently than normal as well. It's all loaded through an iFrame, which is created through Javascript. The best suggestion we can give, although not a great one, is to disable user faces/avatars. That alone is where a lot of the requests are made to load each avatar. Additionally, there's no way to tell Facebook how many avatars to load, so even if your Fan box only shows 1 row of faces (let's say 5 total), a lot more are loaded by Facebook 'in case' more rows (height) is selected. Again, not a great option, but you may want to test without them to see how that improves your speed.

On a side note though, the Javascript to load the Fan module doesn't begin executing until the full HTML has rendered and all Javascript is loaded. So, it shouldn't slow any other elements on your page down.. it should just take a while, itself, to load. Hope that makes sense. Again, not ideal as you want it to load fast.. and when it doesn't, it can make the overall page seem slow, even though nothing else should be...

As always, keep us posted on anything you find in case there's some magic setting or idea you come up with!
Alex

Bob,
Good sleuthing, as always You didn't say what the time was before disabling the JFBCSystem plugin.. just that with it disabled, it was 1.5s. Curious to know what the rough times were for #1-3.

As to your main question, we always include the JFBConnect / Facebook Javascript on every page. The reason for that is consistency and ease of use. While it may not be used on every page, it's impossible for us to know that ahead of time. There are some Javascript features like Requests or even the custom Login With Facebook button (using your own image/text) that can be inserted on any page manually without JFBConnect's knowledge until the page loads. To keep that flexibility, we have to know that our stuff functions on every page as well. Some features, such as auto-logging in Facebook users, also requires that the Javascript be loaded on every page just so we know if the user is logged into Facebook.

Regarding performance, the Facebook Javascript itself should almost all be fully cacheable, so after the first load of it, on subsequent pages, the only time requires is your browser execution time. So, your tests for #1-3 above *may* be slow. Further navigation on any page of the site though, not just the test page, should show an overall improvement. This is outside of any https requests, which can never be cached.. which is why we focus on removing as many of those as possible.

With that said, what we do load, we try to be extremely conservative about it. Simply disabling the Auto-login feature of JFBConnect saves an https lookup, connection, and download (usually about .25-.5s per page). The auto-login work is also only done for guests, and even then, there are cases where we know to disable it.. so registered users never get hit by that slowdown.

Finally, for PHP/database performance, we're always trying to optimize and verify things. I believe by enabling the JFBCSystem plugin, you add a *max* of 8 queries per page. Most pages don't even have that many. There are even ways we're looking into decreasing that query count a bit as well.

Anyways, hope that explains a bit of the performance side that we're aware of and what we do to keep things speedy. Integrating with other networks will slow any site down, but we try to make that hit in performance as negligible as possible.

As always, feedback/thoughts/yelling welcome!
Alex

Understand what you're saying. A couple of notes:
1) With a load time like that, where is most of the 'load' coming from? Is it the connection time to your site, or the downloading of resources? One great thing to check is turning on the Joomla Debug features and seeing how long the server processing side is taking. If that's above 2s (or even really 1s), that's bad. Either too slow of a server, too many extensions, or just one or two sloppy extensions. A lot of time the speed slowdown isn't as much the connection or transfer of files as it is the site generating the page.
2) Turning on System - Cache (when Global Config cache is on as well) is a great way to determine the server impact as well. Even if you don't want to use the System - Cache (there are issues with it), just seeing the improvement may be a good frame of reference.
3) Things like JCH Optimize (what we use) or any of the other various compresses *can* help a lot. They also *can* hurt a lot if your server is slow (the extra horsepower can actually cause a slow down) or if they aren't optimized well to use caching, etc.
4) Try Pingdom as well. It's a 3rd party loader that may be useful is finding slowdowns (and free!). If you see long yellow bars, that's the sign that it's the server taking too long to actually create the page.

With all that said, the only real caveat I see with your test is that it's the worst, worst, worst case scenario. Mainly, things like the Facebook Javascript library may already be cached for the user simply by visiting other websites. Clearing your browser cache would get ride of a lot of the optimizations that browsers take advantage of, and shared resources like the FB JS, Google Analytics JS (assuming you have it) or other 3rd party Javascript are then being loaded 'fresh' on your page. That will slow any site down more than the average since at least some of that code would have been loaded on the users browser before hitting your page.

I'll have to think about ways to auto-load our Javascript as needed. It's really something we haven't considered and doing it through AJAX will cause a big hit after the user clicks the login button or if you are using a Fan module. If you think the Fan module is slower now, it'd be much worse after an AJAX cause because the full page would have to load, our AJAX would have to fire (another roundtrip to the server), the FB JS library would then have to be loaded and initialized and *then* the Fan box would start loading...

Hope that makes sense. Obviously, I'm shying away from that idea. Hopefully, we can find much lower hanging fruit to pluck off the speed tree

Alex

Bob,
Sorry for the delay. I actually had your post on one of my lists to definitely get back to today.

Caching

Apples to apples - I'm doing this on conservative 1.5 bps speed. What are you running with?
Worst case scenario, or is that worst worst worst? I can live with that. So there is the assumption that many of the folks who visit the internet have a lot of this stuff cached. What about those who don't? I read a stat the other day that around 50% of Americans over 12 are now on Facebook. Even though the other 50% aren't, will it still be cached?

We're on a Time Warner 8Mbs download connect, which of course never hits that. Regardless though, I haven't seen the page you're working with, so I haven't even tried to load it

For the worst case scenario I mentioned, that is the absolute worst case. Something like 90%+ of sites have Google Analytics installed. I'm guessing that at least 25% (likely more depending on your users preferences) will have Facebook's Javascript. If so, that means when the user visits your page, that will already be loaded. Heck, you can try your same test, with one change.. close browser, clear all caches, visit sourcecoast.com and then your page. We load FB and Google Javascript, so that the visit to your site won't have to. The caching is all if a user visits a site that loads the same libraries that your site does, regardless of whether the user uses Google or Facebook.

Compressors
Yup, compressors can wreak all sorts of havoc with Javascript and CSS files. It can take a while to get the right combination of exclusions, ordering, and other things. The benefits are generally worth it (in my opinion), but it can be a pain. Less requests is always good. And that scales exponentially... if you get hit with a lot of traffic, each user will request less, meaning your site has a better chance to keep up. On 'slow' sites, the difference is less dramatic as your server better be able to handle a few connections at a time.

Rsrc.php
This file is Facebook's remote source inclusion script. Basically, when a page loads, they call this script dynamically depending on any other scripts, images, or CSS they need to pull into the page. So, while it looks like it may be duplicates, each request is for different 'stuff'. The more widgets you load on the page, the more calls you'll get to that script. If you check our home page , you'll see that there are (I think) no calls to rsync because we don't have any Facebook widgets there (like, fanbox, etc). If you do it to the JFBConnect home page . So, removing extra widgets, or minimizing the features (no avatars, etc) of some of the widgets can help decrease the calls and extra inclusions that Facebook has to make. If you can post, or PM, the page you're working with, I may be able to help narrow down where the extra inclusions are coming from.

I'd really recommend disabling the JFBCContent and any modules/{JFBCxx} tags you have on your page to see if the rsrc.php inclusions go away. If so, add incrementally and see what makes them explode.

Debug
The .5s between afterDispatch and afterRender is indicative of plugins or modules bogging down PHP and taking a while to render. System - Cache can help (since the page doesn't have to re-render every time, or you can try disabling plugins/modules and see where you get speedups.. though, of course, at the risk of loosing functionality. The component on that page is only taking ~100ms to execute (onAfterRoute -> onAfterDispatch), so that's good.

PHP Version
You mention enabling PHP 3.1.5. You have some numbers transposed there, so I don't know what you're actually using. 5.3.x is definitely faster than 5.2, which was faster than 5.1 though. So, the higher, usually, the better.. though Joomla has some issues with PHP 5.4, just so you know.

Hope that explains a bunch of stuff. Best of luck,
Alex