Need all JavaScript and Images to be local
(function(d, s, id){
var js, fjs = d.getElementsByTagName(s)[0];
if (d.getElementById(id)) {return;}
js = d.createElement(s); js.id = id;
[color=#ff3300]js.src = "//connect.facebook.net/en_GB/sdk.js"[/color];
fjs.parentNode.insertBefore(js, fjs);
}(document, 'script', 'facebook-jssdk'));What portion of the load time was improved? Was it the server processing time or was it the browser loading time? What tool are you using to check the loading overall? I'd recommend gtmetrix.com, but there are plenty of great tools out there.When I disabled the SCSocial Stream module I shaved 2 seconds off the load time.
Again, there are a few things that aren't valid with this statement:The Facebook SDK.js file takes 768 ms to load from Facebook. By having that file on our server, it would be cached by CloudFlare, eliminating that 768 ms of wait time.
There are plenty of extensions for Joomla that can convert images in the output of your page to be lazy load. That's not an optimization we'd make in JFBConnect as it can be very tricky to implement properly across all sites.Also if I can lazy load the Twitter and Facebook data, that would help; or load the Facebook and Twitter data after the page has loaded through and XMLHTTPRequest.
1. It was server specific wait time from fetching the content from Twitter and Facebook that was eliminated when I disabled the SCSocial Stream module.What portion of the load time was improved? Was it the server processing time or was it the browser loading time? What tool are you using to check the loading overall? I'd recommend gtmetrix.com, but there are plenty of great tools out there.
1. Yes they are both CDNs, however if one CDN already has the content present in it's cache it doesn't have to fetch that from another CDN. So I don't understand this.Again, there are a few things that aren't valid with this statement:
* Most users will have already visited a site that has the sdk.js file loaded on it, which means it would already be cached in their browser. That results in a 0s load time.
* Cloudflare is a CDN. Facebook also uses it's own CDN. Moving from one to another won't necessarily speed things up further and Cloudflare doesn't actually cache all contents from every site. Just the frequently loaded ones.. whereas the sdk.js file from Facebook is always loaded over a CDN.
There are plenty of extensions for Joomla that can convert images in the output of your page to be lazy load. That's not an optimization we'd make in JFBConnect as it can be very tricky to implement properly across all sites.
That means that the SCSocial Stream is fetching content on every page load, which means that either:1. It was server specific wait time from fetching the content from Twitter and Facebook that was eliminated when I disabled the SCSocial Stream module.
Facebook's Javascript is absolutely always available in their CDN. Cloudflare may or may not have your files in the nearest cache and they can be agressive on lower trafficked sites to not keep data cached as long (since it's not used as much compared to more popular sites):1. Yes they are both CDNs, however if one CDN already has the content present in it's cache it doesn't have to fetch that from another CDN. So I don't understand this.
We load the sdk.js file asynchronously and after the page load. It shouldn't cause the onDomReady signal to be delayed. Again, this is an optimization that Facebook recommends and we perform.3. As you say, sdk.js is most likely already loaded in the Browser, so there is no need to fetch it. But GMetrix doesn't know that. I am trying to get load times under 4 seconds so Facebook and Twitter will approve the JFBConnect Apps on the site. Actually the load time for sdk.js is blocking time, which from my understanding means it is just waiting for something else to be loaded, so it may not be contributing to the total "onload" time. I am just looking at things that appear to be taking the most time.
While possible, that's a ton of work. It also will require work every time you upgrade any extension. JCH Optimize also uses caching to store the compressed and minified files on your server so that it doesn't have to regenerate them every page load. You can do what you're doing, but JCH is likely better at it and certainly less error prone.Understood, I am using one called JCHOptimize. But I really want to go through and consolidate everything into one .css file and one .js file, eliminating all duplication while adding comments to delimit different sections for different components, modules and plugins and then minify those files and eliminate JCHOptimize which itself has a load time footprint..
Yes I realized that it would be a ton of work and I realized that I would have to update my unified file every time a component, module or plugin was updated. JCH has to make generalizations in order for the plugin to work on every Joomla installation. But since you have expressed confidence in this plugin,I will do what I can to optimize it rather than discard it.While possible, that's a ton of work. It also will require work every time you upgrade any extension. JCH Optimize also uses caching to store the compressed and minified files on your server so that it doesn't have to regenerate them every page load. You can do what you're doing, but JCH is likely better at it and certainly less error prone.
This is a great idea, why didn't I think of it. I still need to have this site load under 4 seconds, but while I am going through code with a fine tooth comb, this will get us posting to Facebook and Twitter sooner rather than later..Thank you so much for this idea.Bottom line
ingist, there's not much we can do to help. If you're really under the 4s threshold, I'd recommend disabling anything you can to get under that watermark. Then, get approved and re-enable whatever you need. Then, test and go from there to test from a real user perspective and not what some automated tools see that don't emulate a real browser.
Thanks, and thanks for all the other suggestions as well.By the way, GTMetrix has a test for what is seen after a page is properly cached by a browser, which would be much more indicative of real world use.
Join our newsletter to get alerts for Joomla releases, tips and tricks and extension updates.
