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.
Related
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)
So I'm building a portfolio and sales website for a painter (my wife) based on WooComerce (WordPress). This is a side project that I have plenty of time to finish. I want to build a live/moving photo wall, with perspective. The following photo will give you a (albeit, very rough) idea.
Basically, I want to start off with 16 images (the number is actually arbitrary), apply perspective to them and allow the visitor to click any of the pics and go to that images associated page. Now, after a given time, I want new photos to show up.
I'm not particularly concerned if I flip these pics, randomly, like tiles to introduce new ones OR if a column slides off and a new column is added (i.e. the adding of 17-20 in my picture). This is a semantic difference in the way I build this code and isn't part of my question (I don't think). All of the original pictures are going to be square and will be uploaded by the user, whom we assume is of novice/intermediate computer experience.
So my question is about the approach. Do I:
Make my wall script (likely using jQuery and HTML < map > and < area >) take care of the flipping and linking, but the perspective and scaling is done and cached on the backend.
Every image I upload to the server, for the photo wall, run it through a ImageMagick script that will transform (i.e. apply perspective of the largest size for the wall) and then scale it down for the other columns using a naming convention like: orignalthumnail_marilyn.png perspective0_marilyn.png perspective1_marilyn.png etc. (with the number for the different columns, relating to the scaled sizes). This is will be harder on bandwidth (maybe not, if compressed correctly) and easiest on the user's hardware (assuming non-mobile).
Use Javascript & CSS (and possibly HTML5) to do everything. I load the images into and use the CSS3 skewed/transformed < div >s, JS to flip/moves the tiles (I could do CSS I suppose). I feel that this option is the worst, as far as looks. This is because CSS clips horribly using the transform attribute (on my browser, FF 30) (I also made a quick demo at http://jsbin.com/febatohi/2/edit). Also, it requires the user's hardware to be able to handle all of the transforms, which is not always appreciated online. Maybe there is a way to handle this with a JS library I'm not aware of.
Use Flash. This is my least desirable option. It requires me to either not build this myself or pay someone else (pfft!) or that I acquire and learn Flash from Adobe (I said time wasn't an object, but patience can be). However, it can produce the best looking result, as I have seen things done similarly to this is Flash. It also is a middle ground of hardware and bandwidth, but to me the most time consuming and also limiting to those browsers and users who use Flash (though I feel this is only a small percentage of users).
Other suggestions?
My webpage uses a lot (1000+) gifs and displays different gifs using 'if' and 'getElementbyId', would it run quicker if I dropped the if(map(x,y)!=0){... to change the scr and just used a gif which was transparent?
Googled to heck but it's a hard question to word, if a same/similar has been posted please point me there.
Many Thanks
First you said about getElementById which is a part of javascript - A client side scripting language, so that is not a big reason to be worried about.
You said 1000+ .gif images.
Use concept of Sprites in this case
This will allow you to download all your images in one go.
This will also reduce some of downloading burden from your server.
To work with sprite technology, Visit this link, I believe this is what you need.
Create an Object Pool with Images and load them on the initialization step. Load them in batches and extend pool with new images if required.
While loading images show spinner. It will be loaded long for a first time, after that a browser will put them in cache.
If you have an opportunity to combine different little images in one (sprite), do it! because it is faster to load one big image, then a lot of little.
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
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.