Slow Time To First Byte

Erik,
The function you mention is an intensive function. That's why one of the first lines in that block is:That check is to load the results from cache if they are available. You mention that you have JFBC cache enabled. Can you tell us:
* What is the setting for the cache duration in JFBConnect?
* Do you have the Debug Mode option enabled in JFBConnect?
If debug is enabled, the cache is off automatically. If the cache duration is too short, or you're clearing your cache between GTMetrix runs, then you're testing the worst case scenario.

You can also try to add some code into that block to echo out if the tags are being re-parsed. If they are being re-built on every page load, then something is definitely going wrong. The cache is crucial to good performance for that block.

Another issue I see is how we do the parsing of tags altogether. To find and replace tags, we have to scan the page using a regular expression to find any tags that look like they are from JFBConnect. Your site looks to be using inline images in the page, which increases the overall response size. While that can improve the downloading of image performance, it can slow down our scanning time. I wouldn't expect an additional 1s to do so, but a larger HTML response would cause some delay in our parsing.

I hope that helps get you started, but please let me know if there's anything else we can help with.

Thanks,
Alex

Erik,
I'm glad you've found something that works for you. Unfortunately, I don't understand how or honestly believe that not scanning for the {JFBCFan} tag would have that sort of performance improvement. That block of code is simply 'scanning' for that tag in the page. If the tag isn't found on the page, absolutely no additional code is executed. That means that if the fix you presented is really what was necessary on your site, there's something wrong with regular expressions searches on your server. That could be a PHP or underlying server OS issue.

On your main site, I'm still seeing the 1.6s wait. However, if I test your home page, initially I see a redirect to the /en/ page. That redirect alone takes .56s, which means that *even before* JFBConnect does the regex you're changing above, there's a .56s delay built-in to the page load time.

Finally, we haven't seen this issue before and do a ton of work to keep loading times down. You're free to test this site and see that the 'waiting' time is well under 1s on all pages. The post you showed above also was ultimately narrowed down to *not* be from JFBConnect. There was a post from me which showed there was huge variability on the server. Also, most of the loading time came from the SCSocialStream module which was causing the delay because it was loading many avatar images from Facebook. That's not similar to the issue you're explaining.

I hope that helps,
Alex