I just came across the window.stop()
The stop() method is exactly equivalent to clicking the stop button in the browser. Because of the order in which scripts are loaded, the stop() method cannot stop the document in which it is contained from loading, but it will stop the loading of large images, new windows, and other objects whose loading is deferred.
https://developer.mozilla.org/en-US/docs/Web/API/Window.stop
I am wondering:
What do 'windows' and 'other objects whose loading is deffered' refer to? Can somebody give me a practical example?
If I append an image to the body and call window.stop() when 30% has been loaded, and then append the same image at a later time; will the latter image only have 70% left load?
What do 'windows' and 'other objects whose loading is deffered' refer
to? Can somebody give me a practical example?
new windows could be iframes or regular frames. Scripts themselves can be marked as defer which loads them after the document and after other inline scripts so these could also be stopped with window.stop(). So practical examples of objects that might have their loading stopped are: iframes, embedded objects (like Adobe Flash), scripts marked defer and images. The idea here is that if you're going to call window.stop() from a script in the page, it can only apply to resources that have not yet completed loading. By definition, at least part of the document and your script have already completed loading or the script wouldn't be running so you could call window.stop() so it is primarily going to apply to resources that are loaded later in the load process such as the ones above.
If I append an image to the body and call window.stop() when 30% has
been loaded, and then append the same image at a later time; will the
latter image only have 70% left load?
The browser cache is very unlikely to cache 30% of an image and then resume loading only the remaining 70% the next time you ask for that resource. Most caches just refuse to cache an object if it is not completely loaded. In any case, this would be entirely browser dependent as this type of behavior of the cache is outside of the standards.
What do 'windows' and 'other objects whose loading is deffered' refer
to? Can somebody give me a practical example?
I use to do a practical to keep window calm when page reloading like this example.
window.stop();
(do some staff here..)
window.location.reload(true);
The window will automatically active by itself when page is reloaded.
So it stop only the browser, not the script.
Related
I was watching this video, and found some elements of it going over my head.
He says that scripts are 'serialized' and also block subsequent files from being loaded. If this is the case then Script 1 would finish loading and then Script 2 would begin loading and then the CSS files would load.
I do not see how loading the CSS files before would inhibit this behaviour. Since the script files should have a set waiting time even if they are loaded one after the other, swapping around the order should not change this behaviour?
Thanks in advance.
Blocking the CSS file won't block the page load, but it will cause the page to be re-rendered; possibly causing a noticeable flicker. This is because each time the browser encounters another block of CSS it needs to re-render the DOM, in case the new styles change anything.
This is all about user experience / perceptual load speed:
Put CSS as high as possible (pref in <head>) to negate the chance of the DOM being re-rendered
Keep JS scripts as low as possible (pref just before </body>) because it ensures the DOM is loaded into the browser (and therefore visible to the user) before any potentially blocking external scripts are loaded
Browsers are now better about allowing things to "load" in parallel, but scripts will be executed in the order they appear on the page. The video's advice applies best to older browsers. The best thing you can do is move script tags to just before the closing of the body tag so that the page will be rendered before needing to execute all of your javascript. Here is the Google Best Practices recommendation about this: https://developers.google.com/apps-script/guides/html/best-practices#load_javascript_last
Also note that it is potentially a great performance benefit if you load scripts from a CDN. For example, if you include your own copy of jQuery, every person that visits your site the first time must download it. If you link to jQuery from its CDN, your users have likely already downloaded that same file while visiting another site, and that same file will be used when they visit your site, thus no reason to download it again from you. Also, if you're loading a lot of scripts at once from your server, the download of some of them could be delayed, so loading from other sources opens that up as well.
Regarding the video (outdated):
He's saying that the css files will begin downloading if they come before the script tags. If your script tags are already loading, the css files won't begin loading until the scripts are done.
To exaggerate the issue, imagine that if one script begins to load, we won't allow anything else to start loading at all. On the other hand, if a css file starts to load, the next script can begin to load immediately after the css file starts to load. This way, they are both loading at the same time. However, if a script begins to load, the css file CANNOT begin to load until the script is fully loaded.
Its generally good practice to load your JS files at the bottom of your page as you then give HTTP request priority to other elements on the page such as styles (CSS), images and text etc. These will be shown visually to the user first instead of waiting for scripts to load in the background.
There is an example of javascript blocking from Steve Souders from his Book 'High Performance Web Sites': http://stevesouders.com/hpws/js-blocking.php
Javascripts don't block Downloads anymore, but still do block rendering.
.. but there is a strange download activity:
There are 5 parallel downloads (max 6 are possible in Firefox 3 or IE 8 from the same server/host)
4 Images (2 from host1, 2 from host2)
1 Javascript in between
there is also a 5th image in the page, but the loading of this fifth image does not occure in parallel, but only after Javascript has finished loading.
so why does that Image not load in parallel with the other components? and the other 4 images do?
If you use the Net panel of Firebug you may see what I mean!
Imagine a cursor moving through the HTML document from top to bottom.
At each element the cursor is at, it resolves the element/image.
When an image is encountered, an image load is started and the cursor moves on, the image doesn't need to be loaded for the renderer to continue.
Once the cursor hits a script tag it first loads that script and then executes it before proceeding to the next element. It basically holds that script tag to be high priority and will only proceed once the script is fully resolved; loading, evaluation and execution.
So any HTML (image or otherwise) that comes after the script tag is put on hold.
This is what is meant with JS Blocking and occurs when scripts are inserted using plain HTML.
This can be avoided by inserting scripts using JavaScript, because though you create HTML elements and append them to the DOM, it does not interrupt the HTML rendering cursor since thats another process entirely.
not an answer, just a screenshot to illustrate the question: why is the download of the last image only started after the javascript has stopped downloading?
and here a possible answer: i put the html of the example on my server (all images and javascripts still on souders's server) and then looked at firebug: now i see the traditional blocking behavior:
loading the first javascript (util.js) blocks the loading of all the following images, loading the second javascript (the slow on) blocks the loading of all images after that.
maybe having the html and the scripts on the same server is some kind of special case that is treated differently by the browsers.
I have seen JavaScript libraries being loaded at the top and bottom of the page.
I would love to know when to make these choices. All the JavaScript code I've written all work at the top of the page, which includes jquery plugins.
When do i load my script at any of these positions?
Top: When having JavaScript events function on elements immediately is more important (so if you use a DOM Ready event to load everything, this is the wrong place)
Bottom: When loading the content is more important
Yahoo says to Put Scripts at the Bottom. Google says something similar but not as clearly.
The reason you do it at the bottom of the page is because if you put it at the top of your page then the rendering of your page will wait for these files before it renders. This is why a lot of people put JavaScript at the bottom of the page as it allows the entire page to be rendered then the JavaScript is loaded.
There's very rarely any reason you'd want to put the JavaScript at the top of the page, and unless you have an explicit reason you want the JavaScript loaded in before the main page then put it at the bottom. Most optimization guides suggest putting it at the bottom for this reason.
I place all CSS in the HEAD to avoid excessive screen paintings and flashes of style.
I place most JavaScript file requests at the bottom of the page so that the page can render quickly (HTML/CSS loading will block until script tags above them have been loaded and processed). Any code that needs to be executed after the library files have loaded are executed onDOMReady, which is all code except for library initialization. I pretty much followed Google's PageSpeed recommendations.
I've been thinking about using LABjs as well to further decrease page load times, but this works well enough right now.
When the browser encounters a script element it has to evalute the JavaScript contained in that element because the script might alter the content of the page (via document.write) or inspect the current state of the page.
If the script element loads script using the src attribute, loading of other resources (JavaScript, CSS, images, etc.) will be blocked until the current script is loaded.
Both of these factors can slow down the perceived load time of your page.
If your JavaScript does not alter the page or if it doesn't need to inspect the state of the page until it has loaded you can mark your script element with defer="defer" (supported by IE 6+ and Firefox 3.5+) which indicates that the evaluation of the script can happen "later". Moving your script elements to the bottom of the page effectively does the same thing - since your scripts appear at the end of the document they'll be evaluated after CSS, images, etc. are loaded and the HTML is rendered.
Because of the fact that browsers have to pause displaying content of a page when it's parsing a Javascript file, the recommendation is to load the Javascript at the bottom of the page to speed up displaying a page's content. This works best if your website can be rendered without any Javascript executing to modify the page because the page will be available for user interaction even if a script hangs for longer than expected.
I put all external scripts (such as Google analytics) at the bottom so their lag does not effect the loading of the DOM.
Simply put, if your script have snippets that would start executing right away (outside all function(){} bodies) and that access DOM elements, it should go at the end of the page so that DOM would have been built and be ready to be accessed by the time the script starts executing.
If you are accessing DOM only from function calls (like onload, onclick etc), you can put the script safely in the head section itself.
I put a small script in the head that does anything I want done before the rest of the page renders, and loads any other required scripts onload, or as needed after the document loads.
On a lot of the pages I work with there are a lot of external(non-critical) external images and js files that get called that affect the load time. One of these is a tracking pixel for an ad company that sometimes can take a few seconds to load and you can see this hanging in the browser so it gives a poor user experience. Is there a way that I can load these and not have them count as the initial page load? I've seen similar things that launch a timer and once the timer fires they load but I'm worried that if the user leaves the page too quickly the tracking pixel wont have time to load.
Not really - the point of tracking using a gif is to track users regardless of whether they have javascript or not. Delaying the load of the gif would require javascript, so would defeat the point and potentially mess up your stats.
The best method is to put these 'unnecessary for page load' things at the end of the code, inside the closing body tag.
If you can load the tracking pixel further down on the webpage, preferably as close to the end BODY tag as possible, it will likely process all other content prior to that image first, making the page load appear to occur faster in the event the image isn't loading very fast.
This can be explained (if taken slightly out of context) by Yahoo YSlow's "Best Practices for Speeding up your Website" section on put scripts at the bottom.
I work for a large website. Our marketing department asks us to add ever more web ad tracking pixels to our pages. I have no problem with tracking the effectiveness of ad campaigns, but the servers serving those pixels can be unreliable. I'm sure most of you have seen web pages that refuse to finish loading because a pixel from yieldmanager.com won't finish downloading.
If the pixel never finishes downloading, onLoad never fires, and, in our case, the page won't function without that.
We have the additional problem of Gomez. As you may know they have bots all over the world that measure site speed, and it's important for us to look good in their measurements, despite flaws in their methodology. Their bots execute onLoad handlers. So even if I use a script that runs onLoad to add the pixels to the page after everything else finishes, we can still get crappy Gomez scores if the pixel takes 80 seconds to load.
My solution was to add the pixels to the page via an onMouseMove handler, so only humans will trigger them. Do you guys have any better ideas ?
jQuery and other JavaScript frameworks can help handle the problem by using a method such as the" document ready" function, which fire when the document is ready and don't need to wait for all the images.
I'll quote direct from the jQuery tutorial:
The first thing that most Javascript programmers end up doing is adding some code to their program, similar to this:
window.onload = function(){ alert("welcome"); }
Inside of which is the code that you want to run right when the page is loaded. Problematically, however, the Javascript code isn't run until all images are finished downloading (this includes banner ads). The reason for using window.onload in the first place is due to the fact that the HTML 'document' isn't finished loading yet, when you first try to run your code.
To circumvent both problems, jQuery has a simple statement that checks the document and waits until it's ready to be manipulated, known as the ready event:
$(document).ready(function(){
// Your code here
});
You could use this event to load those problematic images.
See this link for further info.
http://docs.jquery.com/Tutorials:How_jQuery_Works
I also work for a large website and here is what we did:
Moved the ad calls to the bottom of
the page, so the content would show
up first (because JS is
synchronous).
Loaded the ads using Ajax Calls (to
allow the page to be usable while
the ads are loading) into a hidden
element.
The position is moved to the correct
place in the DOM and "unhidden."
Depending upon the page, we either
wait for the ad to finish loading
before move the position, or we move
the position immediately.