I am trying to find the best way to load many (say 100) images onto a web page. Some images are large background images for a parallax effect, others are images on cubes (so all sides of the cubes made from divs);
What I am wanting to know is what is the best approach, so far I have a few idea:
method A
1 lazy load all the images and background images when they appear.
2 use a sprite sheet for the smaller images.
3 compress all images for best compression, use Gzip.
method B (experimental)
1 create a separate style sheet with variables for each image converted to base64 (ex :root{--boxImage1:url("data:image/jpeg;base64,/9j/4AAQSkZJRgABA.....)
2 create a service worker for the css as it would become rather large
3 use compression to min the css file.
4 use gzip to transfer from server.
Method c
store the images as binary on a database
(I worry this would actually make them slower as it would be searching the database rather than the file system).
are any of these methods worth doing or is there a way simpler way that I should use ?
I'm currently working on PWA with a lot of user uploaded images, and I can confidently say that using your method A did wonders for our app load time.
Compressing images on upload and converting them to base64 strings drastically reduces their size, and combined with lazy load of 5 images at a time, app is much faster.
Since you have service worker tag in your question, I would also recommend precaching at least the initial batch of images for even faster load speed of your homepage.
Related
I have a web page which loads almost 70-80 images on the web page. I already have implemented lazy loading. Should I keep these images on local server or on some image site like picasa and reference it from there ? or is there any better option ? What would be the best way to load these many images without loosing performance and efficiency ?
Please suggest.
One more question - is it good idea to add css animation effect to those images ?
There are a number of things you can do.
Use a tool like smushit - www.smushit.com to optimise images and reduce loading times.
Make sure that you are not resizing large images by setting incorrect widths and heights.
Call images from a subdomain on your server.
Combine images used as backgrounds/display elements into a single image (known as a sprite), and use css to only call specific areas of the single image - this means it will only be loaded once, reducing HTTP requests.
You can get some advice on using Sprites here: http://css-tricks.com/css-sprites/
You can also get some more info on page loading times, and things you can do to optimise by using GTMetrix tools at http://gtmetrix.com/
How can we speed up the process of loading hundred's of images in as3? it seams to be taking a very long time to load 100's of images.
If you don't have the ability to change the image quality or sizes, then there isn't a lot you can do to speed up such a large load, as you are limited by connection speed and simultaneous browser connections.
You may be benefitted by using a loading manager, like Greensock's LoaderMax. LoaderMax will help make sure you are loading several assets simultaneously - check out the maxConnections parameter.
Also, I suggest not loading everything up front with one preloader. Instead, have placeholders with a spinning loader for each image that then gets replaced by the final image once loaded. This will provide a much smoother user experience and create the illusion of the overall load taking less time.
100s of requests can take quite a long time even if the total size of the images isn't prohibitively large. If you know which images you need in advance, you could embed the images in another swf which you load at runtime.
By the way, what is the reason that you need to load 100s of images right away. Is there any reason you can't load them in the background a little more slowly?
A few suggestions:
Reduce the filesize of your images (obvious but most important).
Don't run all the requests at once - queue the images and load them one at a time (most relevant to least relevant).
There were lots of good advices already. But here a re my 2 cents. One day I had to load about 1000 of really small images. It was taking too long so I used FZip AS3 library. Worked like a charm.
The question does not provide a lot of specifics, so here are some general guidelines.
If the images are large JPEGs, you might be able to sacrifice some quality and recompress the images to make them smaller.
If the images are PNGs and represent, e.g., lots of small, individual tiles for a game, you could try combining many of them into a single image and then parsing them out into images on the client side after loading the image over the network.
Implement download queue, for example simple loader
https://github.com/hydrotik/QueueLoader
Do not load images that
currently out of stage (you can load them in background)
Use texture packer if you have plenty of small images
Optimize pics
quality (i.e. size, type)
Use cache, for instance Local Shared
Object, so for next time you'll get your pics ultimately fast from
LSO.
Is there any way to get thumbnails of the images made? If so, you could use the thumbnails while the larger versions load. Load all the thumbnails first (since they'd load really fast), then load the larger versions in prioritized order.
It sounds like you don't have a lot of control over the images, though. If you don't have any control there, there's very little you can do to speed up the process besides using a loading optimizer as others have suggested.
If I want to show thumbnail view of an image and show the actual size image when the thumbnail is clicked ,
What is the best practice/standard way ? I mean,
1- Keep two files in local storage (say 800x600 and 120x160)and load them separately
2- Keep only the full size image(say 800x600) and show the thumbnail by resizing it in HTML tags
width="160" height="120"
Best practice is to use the two files, i.e.
1- Keep two files in local storage (say 800x600 and 120x160)and load them separately
As resizing is both computationally expensive and uses more bandwidth.
Ideally, each thumbnail image is compressed to about 10 - 30K (JPEG), and has an alt text. That way you can have about 20 or so in a table, easy to see. Like here: http://www.flickr.com/explore/interesting/7days/
And as you likely know, there are thumbnail creators, like this one.
Option 1 - you save bandwidth and you also allow people with download limits to not use up their potential limit (such as on their phones). The only thing you end up giving up (assuming you automate the process) is hard drive space.
I think, that the best is to keep two files. User can load a several big files, not everything. So, to load them all is unnecessary.
It may be very important for phones or such devices.
best thing is keep high resolution version in the server and then based on the requirement dynamically re size the image. and if you want you can cache the file in the server side.if you are using C# this sample shows how to resize dynamically
next option is keep separate files in server.
I have a web app that lets users upload images. The images then appear as thumbnails on the app, and when a user clicks on the thumbnail it shows the full size image. Pretty standard.
Right now I'm storing the images in a MySQL database, and have the entire app running on Jboss. To display the thumbnails, I have an IMG html tag that points to the full size image, and I just set the width and height to 50px. This loads the image out of the db, sends the entire thing to the client, and then resizes it in the browser. Obviously this seems like a big waste of resources and makes the pages take a long time to load, since there could be a lot of thumbnails on the page, so I'm trying to figure out the best way to improve this.
I found an apache module that resizes images on the fly. So I was thinking I could use that to send the thumbnails to the client, reducing the bandwidth and page load time. Since my images are stored in the database, is it possible and efficient for Apache to serve them? Should I be storing the images on the file system instead? Any suggestions on how I should handle this?
I think that all the overhead of processing the request and pulling image data from the database is totally unneeded.
Just handle the resize upon upload, and serve both thumbnails and big images as static files directly via webserver.
Depending on the number of images and image size - for 1 million 4MB images i would prefer not to store images in the database. But for 100 100K images yes it could handle it.
You need to consider Database backup times, and data retreival.
In one of my applications, which relied heavily on reducing database backup times and sizes, i did not store images in the database.
I don't have much experience with the sprite approach to images (http://www.alistapart.com/articles/sprites). Anyone care to share some pros/cons of sprites vs. old-school slices?
The main advantage of sprites is that the browser has to request less pictures from the webserver. That reduces the number of HTTP requests and makes it possible to compress the parts of the design more effectively. These two points also represent the disadvantages of sliced images.
Here you can see some good examples how sprites improve the loading speed of web pages:
http://css-tricks.com/css-sprites/
Pros:
It's far easier on the server to serve a single large image than many small ones.
It's (slightly) faster for a web browser to load such an image.
Browsers only load images as they needs them - if you are using multiple images in a rollover, the browser would "pause" the first time you roll over the element. This can be solved using sprites, because there is only one image to load.
Cons:
It's kind of a pain to code (more so than using multiple images at least)
One often overlooked downside of using CSS sprites is memory footprint:
https://web.archive.org/web/20130605000516/http://blog.vlad1.com/2009/06/22/to-sprite-or-not-to-sprite/
Unless the sprite image is carefully constructed, you end up with
incredible amounts of wasted space. My favourite example is from WHIT
TV’s web site, where this image is used as a sprite. Note that
this is a 1299×15,000 PNG. It compresses quite well — the actual
download size is around 26K — but browsers don’t render compressed
image data. When this image is downloaded and decompressed, it will
use almost 75MB in memory (1299 * 15000 * 4).
When sprites get loaded into the browser, they are stored uncompressed. A 26 KB file can uncompress to take up a whopping 75 MB of RAM. You should be mindful of using sprites with very large dimensions.
There's also the issue of what happens in browsers with poor CSS support (legacy browsers). The sprites may end up totally broken.
Sprites
Pros:
Less HTTP connections to the server
Faster loading on broadband
Cons:
No encapsulation: If you want to change one image, you have to change the sprite
It is difficult to setup individual images in CSS without a tool
Don't degrade: If the browser don't support CSS, you are in trouble
CSS Sprites:
Pros:
Graceful degrade in unsupported browsers (text can be shown when background images for links are not allowed)
Fewer HTTP requests
Each image has a separate overhead like color table so image slicing will be having more overhead than CSS sprites
Cons:
Poses a problem if images are turned off in the browsers (rare case though)
Image slicing:
Pros:
User perceives a faster load since loaded piece by piece.
Load on demand like when the user places his mouse on the image
Cons:
The webpages might have a large size on the client side even thought it might not be the case on the server side.
The main drawback of sprites is it makes it hard to read/maintain/modify your CSS. It can be difficult to remember the exact pixel offsets within the sprite.
pros using sprites :
since it is using 1 images for all, it require less load on http server.
cons:
- hard to code. you must know the coordinate each images inside sprites so you can display it correctly. once you change the size of the image, you need to adjust all ...
- big images could creates long waited page to display. while using images, user with slow internet connection can see one by one.
best practices.
use it for example roll over images.
Look into using a CSS sprite generator (we use SmartSprites). That way you can do slices locally, and have your build process generate a spritemap. It's the best of both worlds.
Also is SmartSprites isn't for you, there's definitely others, however I like it because it reduces the amount of work up front AND during changes.
Cons
- slower on older browsers/ maybe not working on them with hover effect (opera6)
- if not used correctly can get very/too huge (group them adequately!)
- tedious work to set them up
Pros
- less bytes transfered, because one big image is smaller then all individual images combined (one header/ color table)
- less http requests
I prefer going the middle ground of grouping similar images (normal, hover, selected page, the parent page of selected page) than having all the images in one file. To make these, you image slice like normal in Photoshop or Illustrator, open the files up and combine them with a shortcut key. I wrote the Photoshop script that combines images into CSS sprites. You will have multiple HTTP connections, but won't have the load delay on hover.