<script type="text/javascript"
src="http://s7.addthis.com/js/250/addthis_widget.js"></script>
I am using this code for facebook, twitter etc, but there is a script in this which makes the page loading speed extremely slow. Can you please help with the solution for this, the entire code is below
<!-- AddThis Button BEGIN -->
<div class="addthis_toolbox addthis_default_style ">
<a class="addthis_button_preferred_1"></a>
<a class="addthis_button_preferred_2"></a>
<a class="addthis_button_preferred_3"></a>
<a class="addthis_button_preferred_4"></a>
<a class="addthis_button_compact"></a>
<a class="addthis_counter addthis_bubble_style"></a>
</div>
<script type="text/javascript">
var addthis_config = {
"data_track_addressbar": true
};
</script>
<script type="text/javascript"
src="//s7.addthis.com/js/300/addthis_widget.js#pubid=ra-4dfeea6f5bf22ac6">
</script>
<!-- AddThis Button END -->
Besides moving everything to the bottom of the page as Mudshark already said, you can also use the async addthis version:
http://support.addthis.com/customer/portal/articles/381221-optimizing-addthis-performance#.USyDXiVuPYo
<script type="text/javascript" src="http://s7.addthis.com/js/250/addthis_widget.js#async=1"></script>
function initAddThis(){
addthis.init()
}
// After the DOM has loaded...
initAddThis();
One of the solutions would be to use deferred JavaScript loading pattern for AddThis library.
There are several nice JavaScript libraries helping you out with that problem. I personally use mostly Modernizr.load (or yepnope.js by itself)
You can read more on that issue and improvement in Improve Your Page Performance With Lazy Loading article.
As a side note, I was able to improve page load by about 35% average in my past projects by using deferred JavaScript loading patter. I hope that will help.
One obvious thing to do would be to move the javascript to the bottom of your page, right before </body> so that everything else can load before it.
put async="async" attribute to your script tag
<script type="text/javascript"
src="//s7.addthis.com/js/300/addthis_widget.js#pubid=ra-4dfeea6f5bf22ac6" async="async">
</script>
There are few things to note:
you really don't need to load addthis immediately, you can load it relatively late during page rendering process,
addthis .js file is huge, currently around 118kb, minimized and gzipped (sic!),
due to its size it will always take relatively a lot of time for browser to compile and process it, especially on mobile devices.
Using async attribute in the script tag might help, however browsers consider mostly network resources when they see the attribute. Browsers don't take into account what impact the script might have on CPU usage, page rendering tree etc. (in browsers defence there's no way for them to determine it). For example scripts that take a long time to execute might block rendering of first frame or other crucial early paints. Even if we ignore network resources (connection slot, bandwidth etc.) required to fetch the addthis .js file it still may turn out that the script has severe impact on page loading process.
Note that while the async attribute hints browser that the resource can be loaded asynchronously it says nothing about the script execution when it is finally retrieved. JS in browsers is mostly single threaded and once browser start to process the .js file it can't back out of it and it has to let it finish running.
On my computer, evaluating the script in Chrome takes ~130-140ms and it blocks ParseHTML event for that long. On less powerful mobile devices it may easily jump to 500ms.
Because addthis is so big it would be best give browsers a little help and defer .js file fetch until other, more important components of page are displayed. You should use dedicated .js deferring library for this task to make sure that it is processed after DOMContentLoaded event and after other important resources are processed. I personally use Lab.js for this as it's small and does its job well.
Note also that there exists defer attribute that you can add to script tag, however specification clearly states that the script with defer tag present has to be processed before DOMContentLoaded event - so no wins here.
Related
I am planning to include a user analytics tool - most likely Clicky to my site.
What worries me is the performance effect it might have on the whole site. It is loaded just before the body tag ends:
<noscript><p><img alt="Clicky" width="1" height="1" src="//in.getclicky.com/100874070ns.gif" /></p></noscript>
<script type="text/javascript" src="clicky.js"></script>
</body>
</html>`
I already evaluated the JS loading time of the solution, which seems to load the script about 2 seconds. As I understand this wouldn't harm the actual page usage, but am I right?
1) Does the js start to log events only after it's loaded (let's say 2 seconds)?
2) Are there any other ways of estimating the script load then the network section's load time in chrome inspector (or similar tool)?
Thanks.
Yes - it can't log anything, unless it attaches an event handler,
and for that it needs to be loaded.
There many online tools, to profile web performance. In the
(far) past I've used WebPagetest, which helped me a lot, but I don't really no what is the best tool nowdays.
Suggestion - Try to use async or defer attributes on the <script> tag, and see if it makes a difference.
I have just realized a major slowdown in my app. I use modal dialogs to load other pages of my site into a pop up. Up until recently these loaded very fast. Lately they are taking a vary long time, about 4 seconds. I did some profiling and it seems that my javascript isn't loading asynchronously, each one waits until the other has completed downloading.
This seems to be the major slow down. Each javascript file is just included in the loaded page like so...
<script src="/js/jquery.ae.image.resize.min.js"></script>
<script type="text/javascript" src="/js/jquery.raty.min.js"></script>
<script type="text/javascript" src ="/js/entry.js"></script>
<script type="text/javascript" src="/js/bjqs-1.3.min.js"></script>
I sort of fixed this by moving these files to the page showing the dialogs, but that seems like a hack, especially when they were loading fast enough in the past. Also, this isn't dynamic javascript so it can be cached, I think the time parameters come from $.ajaxSetup({ cache: false }); but that isn't a recent code addition.
If you want to load scripts asynchronously, async attribute helps:
<script async="true" type="text/javascript" src ="/js/entry.js"></script>
In jQuery Mobile, I can define "mobile pages" as divs with data-role=page.
These can be stored in other HTML files, and injected ad-hoc into the main HTML page.
In such a div I can put a script tag, and that script will also be injected into my main page.
The script does not appear as a script tag in my DOM, but rather seems to be injected inline, and thus it does not appear in a standard way in a debugger e.g. FireBug's script panel.
Has anyone found a normal way to debug these scripts (Hopefully in FF or Chrome) ?
EDIT:
Just to clarify - The script tag in the "other" page is not an inline script. It is a:
<div data-role="page" id="some_id">
<script type="text/javascript" src="MyScript.js"></script>
...
</div>
Still, it is injected as an inline script to the DOM.
BTW - if I put the script tag in the HTML's HEAD it is not loaded at all.
EDIT 2:
More clarifications:
I'm writing a framework into which "extension modules" will be plugged on customer site and decision which module (i.e. additional "pages" with scripts) to load is a runtime decision. Therefore I have no prior knowledge in my main page which scripts to load, and must defer loading to "module load" time.
My end goal here is to allow "module" developers to debug their scripts. For this I would like a solution where the references script files are available in FireBug/ChromeDevTools like any other script.
It seems like it's standard jquery (core, not mobile) behavior to remove the script tag from a AJAX-loaded html and eval it inline, instead of leaving the script tag there and letting the browser load it normally.
I don't really fully understand the motives behind this, and it really hampers my debugging options :-(
BTW, I'm using jQuery 1.5.2 (same behavior with 1.5.1) and jQuery Mobile alpha 4 (same with 3)
The script is appended to document on the fly and therefore it's not normally visible to firebug.
There was an add-on that handled debugging dynamically loaded scripts. Inline Code Finder for Firebug but it's last release was in 2009. You probably can use it if you modify the supported versions.
BTW. I belive you should not use that feature of jquery mobile. It's there for a basic support of huge projects with lots of inline script blocks, etc.
You should include your scripts on every subpage and make it work that way
or
Dynamically load your scripts when needed with .getScript() if they're too big to include all the time.
[edit]
Yes, if you put the script in the head it will not be loaded. I repeat: Put the script in the head of EVERY page and bind pageshow of the right page instead of a normal document.ready
Note: If you are reading this for the fist time, you may jump directly to the UPDATE, since it addresses the issue more accurately.
So I got a web-page.
In the head I have a CSS background-image:
<style>
#foo { background-image:url(foo.gif); }
</style>
At the bottom of the page I load my scripts:
<script src="jquery.js"></script>
<script src="analytics.js"></script>
Since the scripts are located at the bottom of the page, and the CSS at the top of the page, I assumed that browsers will load the image first. However, this seems not to be the case.
This is a screenshot from the Chrome Dev Tools:
http://www.vidasp.net/media/cssimg-vs-script.png
As you can see, the image loads after the scripts.
(The vertical blue line is the page load DOMContentLoaded event. The huge 45ms gap is the time in which Chrome parses the jQuery source code.)
Now, my first question is:
Is this standard behavior in browsers? Do CSS background-images always load after all the scripts on the page?
If yes, how could I make sure that those images load before the scripts? Is there an easy and convenient solution to this problem?
UPDATE
I made a test case. This is the HTML source code:
<!DOCTYPE html>
<html>
<head>
<style> body { background-image: url(image1.jpg) } </style>
</head>
<body>
<div> <img src="image2.jpg"> </div>
<script src="http://ajax.googleapis.com/ajax/.../jquery.min.js"></script>
<script src="http://vidasp.net/js/tablesorter.js"></script>
</body>
</html>
As you can see, I have one CSS background-image, one regular image, and two scripts. And now the results:
INTERNET EXPLORER (9 beta)
http://www.vidasp.net/media/loadorder-results/ie2.png
http://www.vidasp.net/media/loadorder-results/ie1.png
Internet Explorer requests the regular image first, then the two scripts, and the CSS image last.
FIREFOX (3.6)
http://www.vidasp.net/media/loadorder-results/firefox2.png
http://www.vidasp.net/media/loadorder-results/firefox1.png
Firefox is doing it right. All resources are requested in the order in which they appear in the HTML source code.
CHROME (latest stable)
http://www.vidasp.net/media/loadorder-results/chrome2.png
http://www.vidasp.net/media/loadorder-results/chrome1.png
Chrome demonstrates the issue that made me write this question in the first place. The scripts are requested before the images.
OPERA (11)
http://www.vidasp.net/media/loadorder-results/opera1.png
http://www.vidasp.net/media/loadorder-results/opera2.png
Like Firefox, Opera is doing it right, too. :D
To sum up:
Firefox and Opera are requesting the resources as they appear in the source code.
Exceptions so this rule:
Internet explorer requests CSS background-images last
Chrome requests scripts before images even when the scripts appear later in the source code
Now that I laid out the issue, let me move on to my question:
How to make IE and Chrome request the
images before the scripts?
Most latest browsers to this kind of unpredictable parallel preloading of stuff these days, for performance reasons and basically ruining any chance of creating an order for loading components. This of course happens once the full DOM has been loaded.
Same story as with JQuery lazy loading of images, which has been broken for a while now.
Use image preloading capabilities through rel="preload" attribute
<link rel="preload" href="images/mypic.jpg" as="image">
The as attribute indicates the kind of object the browser should expect. So this adds highest priorities among all images you load on page, but not change priority "JS -> Image"
<link rel="preload" href="images/mypic.jpg">
Declaration without as allow to preload images even before js load, increasing Image loading priority.
Preloading feature
A possible option is to load all those images that you need at the start of your script. See this TechRepublic article for more info.
Consider that the browser can't do anything till it builds the DOM. So first it parses the whole page, THEN it loads the images (even if they're from the CSS).
You could load the images in DATA segments inline in the CSS or the page, that might speed those things up, or you could inject the jQuery reference after the page is loaded (say set a timer for 500 ms) but obviously that will affect usability to some extent.
Now, I'm pretty sure this is all implementation dependent, you could always find a browser that would load images as it came to them, but consider what it means to build a DOM and then to fill it in.
http://en.wikipedia.org/wiki/Data_URI_scheme
If SO doesn't strip it, there should be a red dot between here and the code :\
<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAoAAAAKCAYAAACNMs+9AAAABGdBTUEAALGPC/xhBAAAAlwSFlzAAALEwAACxMBAJqcGAAAAAd0SU1FB9YGARc5KB0XV+IAAAAddEVYdENvbW1lbnQAQ3JlYXRlZCB3aXRoIFoZSBHSU1Q72QlbgAAAF1JREFUGNO9zL0NglAAxPEfdLTs4BZM4DIO4C7OwQg2JoQ9LE1exdlYvBBeZ7jqch9//q1uH4Tzw4d6+ErXMMcXuHWxId3KOETnnXXV6MJpcq2MLaI97CER3N0vr4MkhoXe0rZigAAAABJRU5ErkJggg==" alt="Red dot" />
So that's what I meant, use the DATA URI scheme
We solved this problem using .load inside the .ready jquery call
something like:
jQuery(document).ready(function($){
jQuery('#my_container img').load(function($){
/* SCRIPT */
});
});
I am working on optimizing a page that has Flash on it. I am using optimization practices like moving Javascript to the bottom to not block. Removing inline scripts. And minimizing HTTP requests with minified css and js.
The majority of the pages content is in the flash, so loading it as soon as possible is the goal. Currently there is a 2 ~ 3 second delay before the flash is even rendered (using firebug profiling)
I am wondering at what point in the page load does the browser start initializing flash on the page?
Is it once the DOM element containing the flash has been rendered?
Is it once the complete onload event has been fired?
I imagine it probably differs with each browsers as well.
Use a direct embed in the HTML. Don't use swfObject or the JS that the Flash IDE provides. If you use JS, you have to wait for that file to load - and then chances are, the JS is attaching to the window.onload and not rendering the SWF until then.
First, none of the major browsers wait for flash before displaying the page. This means that when the HTML page finishes loading, the Flash content may not be completely loaded yet.
I assume based on these facts that the SWF loads simultaneously with the HTML. Once the HTML is loaded then the SWF is displayed.
To test you could use https://addons.mozilla.org/en-US/firefox/addon/3371/
To improve flash loading try SWF Object:
http://code.google.com/p/swfobject/
Because Flash is treated the same way as CSS and HTML by all browsers, a browser initializes it when loading HTML (they're both loaded at the same time). The browser does not prioritise Flash above anything else.