When does a browser initialize flash? - javascript

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.

Related

Loading gif is not animating?

On a clients webpage, the page uses js/css to style a tree-style view to the desired look of the client. But on some of the pages with many objects it takes some time for the styles to load. So I suggested adding a loading screen.
Here is an example of the issue: http://zamozuan.com/content/16-search-auto-parts-by-vehicle-chevrolet
My client purchased a little animated icon they like that fits the theme of their site nicely.
I have a very simple addition to the script to add a loading icon, and then on $(document).ready, hiding the load element and showing the main element.
All works fine except the loading gif is not animating until AFTER the page has completely loaded.
It seems that the loop for the js is too intensive so the gif is not animating.
Before anyone chops my head off, I did view the similar questions on here, but those solutions do not work for me - the majority of issues are in IE and my issue is in chrome (not IE), and most of the other options are work-arounds based on clicking buttons to enable/disable, but in my case this is when the page initially loads so that is not viable.
I am wondering, is there any work-around to fix this? Is it possible to pre-load the gif in to an animated status and somehow prevent JS from interfering? Or is there a way to make the js loop not be so intensive that it completely freezes the browser?
As for the code, it is the exact as the link above, with only this added at the end:
$('#loading').hide();
$('.mainsearch').first().css('display', 'block');
The loading element just contains:
<img src="img/loading.gif" class="img-responsive">
<p class="centertext">Loading, please wait...</p>
But as mentioned, the gif does not load, just freezes.
For the javascript that is styling the tree, you can view it here:
http://zamozuan.com/js/tree.js
Any help would be greatly appreciated, as my client would not want to waste this loading icon they bought.
Thanks.
No, there is no work-around. It's not a problem with how the image is loaded, it simply won't be animated while the script is running.
Javascript is single threaded. As long as a script is running, there is no visual updates in the browser. This includes GIF animations, while the script is running animations won't move.
Without being able to work on the actual code and try it, I would suggest trying to break up your looping into separate callbacks. Maybe using setTimeout or requestAnimationFrame for every few recursions to give the browser a chance to update/paint.

How to increase page loading speed with AddThis widget?

<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.

IE9 throws exceptions when loading scripts in iframe. Why?

Precondition:
I have an aspx-page with iframe inside. This iframe points to the url handled by MVC on the same site (it's hybrid site, both standard ASP.NET and ASP.NET MVC). The resulting page rendered by MVC contains a lot of scripts references.
Problem:
IE9 throws an exception on every single script it load in iframe. These exceptions are similar to this one:
Error: 'Function' is undefined
That is, it says that the most basic things every window has is somehow absent. Once you clicked through all of these popups, the page just works as designed!
If I load a URL from <iframe /> src attribute in the browser directly, everything works as expected.
If I open the page in another browser (I tried Opera, Firefox), everything works as expected -- no errors.
So, what IE9 wants?
There is this msdn page about this bug (or feature).
You get these kinds of errors when you move the iframe element around in DOM. In such cases, IE 9 garbage collects the iframe (causing your undefined bug) and reloads it at another position.
In general, you should create the element, set its src attribute only once and then put it somewhere in the DOM tree once. It has nothing to do with the code which runs in the iframe itself.
I have encountered this same situation in the wild. Basic symptoms:
You load script code in an iframe
The script code runs early (from the head section or top of body)
IE complains about some missing native object
I found that it can often be prevented by delaying the execution of the script code until onload or DOMContentLoaded... Not much help I know but this is one of the most difficult IE scripting bugs I have ever encountered. I upped the score of your question, hope it will be found by others as well and we can get a more detailed answer.
Also see this question:
Error in Internet Explorer 9 (not earlier versions or other browsers) when including jQuery in an iframe
Placing the following script block at the very top of the iFrame html <head> seems to resolve the issue in my case. Basically, it forces the iframe to reload, which as some have pointed out, solves the issue. It seems relatively safe, because, without things like 'Object' and 'Date', javascript is essentially useless.
<script type="text/javascript">
if(typeof(Object)==="undefined"){
window.location.reload();
}
</script>
Try loading the javascript at the end after complete web page is loaded. I feel the script is executing even before the iframe is completely loaded.
for some suggestion of scripting in IE9 view the given link below
http://blogs.msdn.com/b/ie/archive/2010/06/25/enhanced-scripting-in-ie9-ecmascript-5-support-and-more.aspx
Further investigation revealed that the solution is to add the offending iframe to it's dom location BEFORE setting the 'src' attribute.
Once the 'src' has been set, changing location of the iframe within the DOM stack forces IE9 to garbage collect it.
Once 'src' has been set, iframe can be resized and changed via css positioning, but cannot change the relative location in the DOM stack.
Often times, plugins like dialogs and lightboxes will stuff an iframe with src already set into the dom, then append / prepend or whatever, triggering the GC to take place.
function waitForjQuery(){
if(typeof jQuery!='undefined'){
//Do yor stuff!
}
else{
setTimeout(function(){
waitForjQuery();
},500);
}
}
waitForjQuery();

How can i stop IE hanging whilst loading Facebook Social plug in (Like box) on my site?

I have implemented the Facebook like button on my site by using the asynchronous JS SDK and it's working great! However it takes a long time to load, which is not a great problem (Would be nicer if it loader quicker though..) as the rest of the page loads fine.
However, if your view the the site in any version of IE the whole page is unresponsive until Facebook Like / comments have loaded... All the images and other scripts are loaded, but the whole page is locked.
Any ideas on how i can rectify this for IE users?
I have seen this post: How do I keep the Facebook like button from delaying the loading on my website? but this was solved by using the Async version, where as mine IS using this and still hanging?
If it helps I can post a link to my site / page that it appears on?
Well, my only advice here is to place your FB JS code just before the </body> tag. But I have other "tips" for your site in general.
Try to minify/combine your CSS and JS files when possible
Try moving your JS code to the body tag (at the end)
Do you really need the Prototype AND jQuery libraries?! try removing one of them and port the functionality to the other (almost all tasks can be done with either library)
In the end, IE was hanging because I had a CSS3 transform on my images and apparently this slows down IE (Even though it cannot render the transform. So i can disable by this via conditional comments in the CSS or in my case modernizr.

Debugging jQuery Mobile injected scripts

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

Categories