Jquery Best Case Scenario - javascript

I am loading a bunch of images for a GUI which will pick attributes for my clients product.
Is it best to pre-load all the images at the start (which I'm guessing would take some time) and then have the GUI have full functionality or is it better to load images on the fly.
Essentially i am working on a picture/poster framing application. I have about 20+ frames that will be able to be selected by the user and when a frame is clicked I change the images for the frame on the display in the GUI.
I am using Jquery. Any insight would be helpful as to the best case scenario for this.
And if I will be pre-loading all the images how do I put one of those loading bars on the screen like you see in Flash or a loading gif like i've seen in Ajax?
Thanks
Mike

Why not do both?
You can load images lazily, but also hook $(document).ready() to pre-load the images. That way, if the user accesses an image before it's preloaded, it comes in then; if the user waits long enough it will be instantaneous.
This technique is common with things like menubar roll-overs.

Depends on frame images' size...if they are small like 1 - 2K, I'd load the images dynamicaly, otherwise you can preload, but be sure to set the headers right so only once are read and fetched from cache next time.
As for progress bar, I suggest you check this article (talks about preloading images in jQuery and includes progress bar) on Ajaxian.

The correct answer depends on many factors. How large are the images and how many are there? Will loading all images at the start cause severe lag? As Jeff Atwood said Performance is a feature.
I would err on the side of a better performing app, rather than loading everything up front.

Related

How many images can be loading at the same time without sacrificing speed

I'm making a webcomic reader that loads 5 to 10 images whenever the user navigates to an episode. Each image is 2 to 3 megabytes. The project is in angular.
The problem is that each episode takes a while to load because all the images of an episode are loading at the same time. You can't even begin reading the episode until the entire episode is done loading.
I tried using the (load) function to stop an image from loading until the previous image is done loading. That way, the user can begin reading the episode while the rest of the episode loads. And while this did load the first image much quicker, it took an eternity to load the entire episode. My guess is because javascript can load a certain number of images at the same time through separate channels, and bottlenecking it to one image at a time takes much longer.
So is there an ideal number of images that javascript can load at the same time without sacrificing speed? Or do I just have a flawed understanding of the system.
One of the rule I know from optimizing frontend app is the less the better.
You see, the page with text only will load faster than with full of images, and page with 1 image loads faster than page with 10 images.
Assuming we have a reliable connection, good backend. Let's focus on what we can do on frontend.
So first thing first: we want users to see the first image immediately, so we load it immediately, similar to what you did, it's just that we don't touch other images, we only explicitly load the first image. For others, we lazy load them (more on that on point 2)
What I wanted to add more is there're also other resources such as JS/CSS/Fonts... We want our images to load first, so we need to hint to browsers that this is a high priority resource. You can find more about this by searching for "preload" keyword
Next, while users scroll down the page as they're reading/viewing the first image/episode, we will start loading the rest, one by one.
This is what called "lay-loading", with this keyword you can find pretty much any kind of examples. You can take advantages of modern browsers's lazy attribute, or use IntersectionObserver to have more control over when to load
Small note: This is more of a performance question than any framework. So you could find some books about performance, they provide the background such as what is blocking and non-blocking resources, what is TTFB, LCP.
Angular recently updated with NgOptimizedImage, it looks promising, we don't have to do those manual works anymore (at least for the images)

load an high number of images

I'm developing a website that allows the user to see and configure a product.
I wanted to start this project using jquery, css3 and html5 with a graceful degradation for older browsers.
I've combined all the smallest images in several sprites to reduce the number of http requests (the images will be served from a cookieless subdomain).
By the way the product must be viewable in 360° for each combination of configurations.
This produces 2252 images (15mb total).
This is not a big issue for the bandwitdh since we have 2 dedicated servers, but I'm just thinking about the best way to improve the user experience.
Actually I only preload images for the default product view, then when the user changes settings I load the needed images (jQuery helps here). When the images are loading the user will se a "loading" gif. Should I preload images also when it does not request them?
Images will be cached by the browser so each image will be a 304 Not Modified response.
Do you have any advice or suggestion to improve the user experience?
Thank you.
if you have 2252 images per product and you preload one, it seems a bit futile to start preloading others. Presumably the viewer changes his selection and you need another one of the 2252 images. That's a very low chance that you'd have that image preloaded.
If there are various "attributes" that are more common than others, you might want to preload a select few? For example, (I don't know what your product is), if you have a red shirt and a pink plaid XXXL shirt, you might want to preload the red one first ;)
One thing I do in situations like this is to play with the animation effects in jQuery (fade, slide, etc). You can fadeOut on attribute change. That animation will take perhaps 600 milliseconds which would be a good chunk of the time required to go and fetch that image from the server. The result is a perceived lower waiting time for the new view/attribute.
Serving the images from a CDN like amazon s3 might improve the load times a little. As for preloading in steps - that might depend on the product. Somethings are more likely to be rotated - for example a car over what landon said. I personally wouldn't bother rotating a t shirt, but a car probably. So the decision might be based on the expected use of your site.

How do you show pictures as fast as Facebook?

Can any of you help me to be able to show pictures as fast as facebook does!
Facebook is incredible to watch pictures at, because the pictures are kind of preloaded I think.
Often ved you view galleries on other sites, it is a pain in the a**, because it is so slow every time you change picture.
I think you need javascript to do it!?
Depending on your implementation, you could do this with some ajax and hidden dom elements.
Suppose you have a gallery with a slideshow.. You could insert a hidden dom element with the picture next picture of the slide show for each load. This would cause the image to be loaded. If you then were to use JS to insert that same image tag later, the browser would rely on it's cache rather than fetching it form the server since it already has that photo.
This is kind of a broad question but I think this approach would work. You would probally be better off not reinventing the wheel and seeing what Image prefetch librarbies based on JQuery or whatever are available to you..
Facebook compresses images to extremes. Try it yourself, take an image you are having trouble with and upload it to Facebook. Then check the size of the image, you will know why. Once I did a small test by uploading 17429 bytes image and it compressed it to 18757 bytes, a complete 7% increase from the original size!
At that compressed size, you can implement some sort of prefetch next image for display. Along with, I think, they have extremely good infrastructure.
Facebook uses Bigpipe, there is an open implementation in the works called openpipe
Bigpipe pushes the content to the browser when server stopped processing, so user will notice that it is faster.
It basically loads pagelets, when they are ready for the user, at the browser the implementation is Javascript based, and you must push the info to the client with your preferred server language.
First of all, facebook heavilycompresses images. Many other websites don't. Facebook also has a faster network than most other websites.
With the small image size, the client can prefetch the next image.
Preloaded would mean loading when the page is loaded, which is what happens with an <img> tag. No, it's simply because the file size is smaller.
If your wanting images to be viewed quicker on your site first make sure the images are decently compressed and aren't any bigger than they have to be. The amount of times I have seen websites using an extremely large image scaled down to fit in an element 5 times smaller is just ridiculous.
You can check out these sites that has many implementations and links on how to pre-load / pre-fetch images (css, JavaScript, ajax)
http://perishablepress.com/press/2009/12/28/3-ways-preload-images-css-javascript-ajax/
Since your question was tagged with 'jquery' here is one just for that.
http://engineeredweb.com/blog/09/12/preloading-images-jquery-and-javascript

What is the most efficient way to store an image? HTML/CSS/JS

I am going to have a lot of images and trying to find the most efficient way of storing these images to keep the page snappy.
So far I have thought of just the two ways: load with javascript eg picture = new Image(); picture.src = "file.jpg"; and append / remove to the page as necessary, or load into <img> and set display:none.
Are there other options? what is considered the best way to do this?
The best way for a photo gallery (if thats what you are building) is usually to have several sizes of the images, at least two:
a smallish size that is highly compressed and thus have a small footprint: this is the image you load into grids and display in a page where there are multiple images
a larger image with lower compression and higher image quality - this is the one you show when people want to see details.
Since people most often come to the detailed image from a page where the small/fast loading version has already been shown, and thus is already in the browsers cache, you do a little trick and have instant photos, without preloading anything.
It goes like this:
On the details page you show the highly compressed small image in an image tag that has the dimension of the larger detailed version. You then load the larger detailed version in the background using new Image() with an onload event attached that changes the source of the image tag with the small compressed version to the large detailed version.
It looks great, works fast and users will love you ;)
PS: the best way to store images is the browsers cache, not js or the DOM, so if you truly wish to preload images, which is generally a bad practice (tho it can be necessary sometimes), make the browser fetch them for you in the background by including a css file that references them in styles that aren't applied to visual areas of your site.
I'm not sure about "efficient", but the most logical way would be not use the JavaScript to load an image (useless if you have JavaScript disabled) or to set the image as hidden via the display property (likewise, and the browser will probably just load the image anyway).
As such, a sensible suggestion would be to use boring old paging and display 'n' images per page. However, to bring this up to date, you could use "lazy" (a.k.a. "deferred") loading and load additional page content via Ajax as the user scrolls. However, it's key that this gracefully degrades into the standard "paged" behaviour if JavaScript is disabled, etc.
The perfect example of this in operation is Google's image search, and if you search here on StackOverflow you see a discussion of possible implementations, etc.
It's better to use javascript the way that you have it and then add it to the DOM as you need, as opposed to first adding it to the to the DOM and then hiding it because DOM manipulation is much slower and you may not use some images

I want to load multiple images very fast on a website, what's the best method?

UPDATE: This question is outdated, please disregard
So.. my idea is to load a full manga/comics at once, with a progress bar included, and make sort of a stream, like:
My page loads the basic (HTML+CSS+JS) (of course)
As done, I start loading the imgs(the URLs are stored on JS var) from my server, one a time (or some faster way) so I can make a sort of progress bar.
ALTERNATIVE: Is there a way to load a compresses file with all imgs and uncompress at the browser?
ALTERNATIVE: I was also thinking of saving then as strings and then decode, they are mostly .jpg
The images don't have to show right away, i just need the callback when they are done.
XTML and HTML5 is acceptable
What is the fastest way to load a series of images for my website?
EDIT
Since #Oded comment.. the question is truly what is the best tech for loading images and the user don't have to wait everytime is turns the 'page'. Targeting a more similar experience like when you read comics in real life.
EDIT2
As some people helped me realize, I'm looking for a pre-loader on steroids
EDIT3
No css techs will do
If you split large images into smaller parts, they'll load faster on modern browsers due to pipelining.
ALTERNATIVE: Is there a way to load a compresses file with all imgs and uncompress at the browser?
Image formats are already compressed. You would gain nothing by stitching and trying to further compress them.
You can just stick the images together and use background-position to display different parts of them: this is called ‘spriting’. But spriting's mostly useful for smaller images, to cut down the number of HTTP requests to the server and somewhat reduce latency; for larger images like manga pages the benefit is not so large, possibly outweighed by the need to fetch one giant image all at once even if the user is only going to read the first few pages.
ALTERNATIVE: I was also thinking of saving then as strings and then decode
What would that achieve? Transferring as string would, in most cases, be considerably slower than raw binary. Then to get them from JavaScript strings into images you'd have to use data: URLs, which don't work in IE6-IE7, and are limited to how much data you can put in them. Again, this is meant primarily for small images.
I think all you really want is a bog-standard image preloader.
You could preload the images in javascript using:
var x = new Image();
x.src = "someurl";
This would work like the one you described as "saving the image in strings".
Spriting
Just have a look how facebook does it: http://b.static.ak.fbcdn.net/rsrc.php/z3JQK/hash/11cngjg0.png
One image that loads FASTER than series of small images. To display the icon you simply create a div with fixed dimensions, and move the background inside it. Your div works as a viewport for the big image. You use background-position to move to appropriate part of the image. Everything else is hidden.
Different domains
Something you probably didn't know - Internet Explorer has a limit of connections per server. You can read about it here: http://support.microsoft.com/?scid=kb;en-us;183110&x=17&y=11 (here are exact numbers).
What it means - if user is using IE7, he will be able to load ONLY 4 (or 2) files at the same time from your server regardless his internet connection speed.
To speed things up, you could create few subdomains: server1.mydomain.com, server2.mydomain.com, server3.mydomain.com etc - and then user can download many files a lot quicker, because you use different hosts to serve different files.
As done, I start loading the imgs(the
URLs are stored on JS var) from my
server, one a time (or some faster
way) so I can make a sort of progress
bar.
Your browser already downloads the HTML first, that's how it knows to load any JS/images you reference. You are trying to invent something that already exists.
Just make sure your manga is made up of lots of images of a known size, which you specify in your img tags. Most browsers have some sort of progress bar to show that it's loading resources for you. You're not going to make loading large images faster unless you improve either the speed at which your server serves them, or your user's internet connection, or you compress them to make your image files smaller (likely at the cost of image quality).
Note: JPG and PNG are already compressed.
You can try using a "CSS sprites" technique. Basically the idea is you use your favorite image editing program to stich all your images into a single image. It's faster to send this because you lose the per/file overhead in terms of encoding the image and sending the image. On the client side you use CSS to only select the portion of the total image that is used in any one place.
http://www.alistapart.com/articles/sprites/
http://www.fiftyfoureleven.com/weblog/web-development/css/css-sprites-images-optimization
AND/OR
You can use lazy loading to only load images when they come into view.
http://www.appelsiini.net/projects/lazyload
Image preloaders have been around for ages. You really do not need to load them all at once, you can do it on demand [when the person loads the next page, you can fetch the image after it]
My page loads the basic (HTML+CSS+JS) (of course)
As done, I start loading the imgs(the URLs are stored on JS var) from my
server, one a time (or some faster way) so I can make a sort of progress bar.
The images don't have to show right away, i just need the callback
when they are done.
If you want to load 10 images as fast as possible, place 10 <img> tags on the page, one for each image. Use Javascript to hide all the but the currently viewed image; add next/back links that use JS to hide the current image and show the next one. Many browser already have some form of progress bar, and by doing things with regular old HTML, it will function correctly.
You're trying to re-invent all this functionality with Javascript for no good reason. You're not going to do it better than the browser.
All that said, this is probably a bad idea. You might dump 15MB of comic pages into the browser window only to have the user leave after reading the first page. Rather than trying to pre-load all images, you should use JS to always keep the next page (or two) pre-loaded, not the entire thing.
Here's something you can try, which by happenstance I just coded up:
(function() {
var imgs = [ "image1.png", "image2.png", ... /* all your image names */ ],
index = 0,
img;
function loader() {
if (index >= imgs.length) return;
(img = new Image()).onload = loader;
setTimeout(function() { img.src = "/path/to/images/" + imgs[index++]; }, 1);
}
loader();
})();
Plop all your image names (or the ones you want to preload) into the array, and make sure this script starts up when your page(s) start loading. It'll work its way through the list of images, loading them, and then moving on to the next one when each image finishes. (The setTimeout call is to make sure that the "onload" handler doesn't get called while you're still inside a handler.)
You'd probably want to do this for lots of the "nuts and bolts" images for your whole site - in other words, each page would try to load images for everything. Once they're in the cache, of course, this won't take a significant amount of time. Alternatively, you could run this script only on a couple pages, like "login" screens and the main "home" page. Of course, if you've got a site like Flickr, then you probably wouldn't want to preload all your images :-)

Categories

Resources