The timeline shown here (captured using IE’s F12 developer tools) illustrates how IE handles a page
where an <img> tag is located after of a bunch of text :
The second row shows the retrieval of the image. Since the image is small, all of the image data is included with the HTTP response headers in the same packet.
However - The next timeline shows what happens when the <img> tag is located close to the beginning of the file so that it’s in the first packet of data received by IE:
However, the request for the image starts shortly after the first packet of HTML arrives.
As a result, it takes less total time to retrieve the page and the image
But (IMHO) it is better to put images (with defined dimensions) on the bottom of that page. ( so that the page will load faster)
However - by my example it shows that the page is loading faster when the img is on top.
What am I missing ?
P.S. my question is a briefly summarized text of this section
You are missing several points.
First, the best practices are not only about downloading, but about rendering as well, because if the whole page is downloaded for 3s but in require another 2s to be rendered, the user waits 5s, not 3s. I don't know best practice for putting images at the bottom (there is such for scripts), the best practice I know is to include width and height attributes so you do not block rendering while the image is being downloaded.
Another thing you are missing in your test is parallel downloading, as browsers limit the number of concurrent connections and you are testing with only one image. Make your tests with more images, or best - with a real web page, in order to have reliable results.
I'd rather bother about lessing number of connections, - loading whole page at once. Split interface and content parts. Once interface loaded - it can ask user to wait and inform him about connection speed. Then put a progress bar and inform user about how things go.
Related
I've been working for a few months on loading most pages of our website with ajax, using jQuery and history.js (https://github.com/browserstate/history.js). Technically this has been working very well, there are no serious issues. The basic process is:
bind handlers to clicks
on clicks, prevent default and do a History.pushState
Then on statechange:
scroll to top, showing a loading animation
hide the main content div, then erase it's contents with a .empty()
run the ajax request ($.post to the target URL)
when data is received, put it in the main content div, show that div, and hide the loading animation
Note that I'm specifically changing the request to a post instead of a get, because I need to send a post flag telling the server that this is an ajax request, so it knows to only return the necessary content.
However, google analytics reports that the page load times are, on average, about 1 second longer for users with ajax browsing turned on (I'm doing a 50/50 split test).
For a while I assumed this was just inaccurate reporting, because I've read that google's speed reports can get very screwed up by one or two visitors from across the globe who get longer load times.
Today I opened two browser windows side by side (chrome and chrome incognito) and clicked around the site, and sure enough the window using ajax did have somewhat slower load times. It wasn't consistent, sometimes it was faster, but never by a lot. When it was slower, it was significantly slower. Usually this happened when the ajax request just seemed to be slow (the loading animation remained visible for an extra second or so). Meanwhile the full load window had consistent load times.
I can't imagine why this would be the case. The ajax request should always be faster. Anyone encounter this before and discover the same thing?
I have two frames in my page. The upper frame is a jsp which takes the parameters entered by the user, the lower frame is a Crystal Report viewer which shows teh report once we click on View report button (located in upper frame). I do get a status bar on the bottom of the window (IE property). It is a back-end process carried out by Crystal Reports to process and populate the data in the report. I want a loading image or a message which stays until the report gets loaded. However, there is no pointer where the process is stuck on my jsp that i can monitor the starting or ending of the process. So, my idea is to monitor the status bar of Internet explorer. The moment it starts i want my image to get loaded in the centre of the screen and once the status bar is complete, the image should go away. I shall use something like setInterval(checkStatusBar(),500) which will check every 500 miliseconds for the existence of status bar. My question is what code would be there in the checkStatusBar() ? I need javascript code.
Instead, you might want to detect when the second frame's load event is fired. You can do this rather simply with some help from jQuery. Something like the following should do what you are looking for:
$(selectorForTheSecondFrame).load(function(){
stopShowingLoadingIndicator();
});
Where selectorForTheSecondFrame is a CSS selector that will select the frame you want to check and stopShowingLoadingIndicator is a function that does what you want to do once the frame has loaded.
Obviously, this would make your project dependent on jQuery. You could do the same in pure JavaScript if you wanted, it would just be a bit more work.
I have a web app which displays a Java Script image carousel.
Showing one image at a time for n seconds.
When the html page (index.html) loads it loads all n images in an hidden parent html DIV and the app (JavaScript) is responsible for showing and hiding the parent divs for the images at a given interval.
This usually works fine, but some times (randomly) only half of the image is loaded (eg. just half of the image is displayed on the screen).
Sometimes only "half" of the index.html response is loaded making the HTML kode to bleed out to the display.
Unfortunatly I do not have any tools like Firebug etc. to debug the problem yet since the screen is a kiosk (screen hanging on the wall)
To me this seems like a network problem but I am no network administrator so I will just be guessing here.
As I said this happens randomly.
The image starts loading but only half of the image. Sometimes after maybe 15 seconds the rest of the image is suddenly displayed.
If this could be a network problem the what could it be?
Best regards,
bob
Sounds like it could be a network issue. Why not try and cache the images on the browser so you don't have to wait for them to load every time. Also try looking in the Firebug/Web Inspector Net panel and you should be able to see if the browser is waiting on a network response or not.
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.
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.