I feel like this is a stupid question since I'm pretty sure the spritesheet uses memory for the entire sheet, but I just wanted to make 100% sure and can't find the answer any where. For a html project I wanted to be 'smart' and make as little http requests as possible, so I created a 2048x2048 image that only has about 150x150 not being used, which is actually great since it can allow me to add other images in the future if I need.
The problem is, after purchasing and configuring a server, I was afraid if a lot of people connected at once, that the server would be using more memory for the bigger spritesheet? I only use 10% of the images in the sprite sheet at any given time, and when they change, the previous ones get replaced. So was it stupid of me to make one big file, will it only use extra memory for no reason? Would the rule of thumb here be, use big sprite sheets for images that are always being loaded, and then split the remainder into smaller sprite sheets that are used only at certain times?
To answer your question, yes the entire sheet is loaded into memory.
However, only once.
Each CSS displays only a small portion of the sprite.
In theory: As you move from page to page that one large image is already in the cache and not requested from the server again. Making the next page load that much faster.
There is much more on caching v/s the number of requests v/s the combined sizes of images that would go into a more complete answer.
Related
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.
I have been tasked with optimizing a marketing landing page for speed. It already does really well, but the problem is its very graphic heavy.
The entire thing I would guestimate is 30+ pages long all on one page (It must be like this, and everything must be images due to conversion reasons).
Here's what I've done so far but I'm not sure if there's something else I'm missing
I re-compressed over a 140 jpg's on the page to slightly smaller sizes
I played around with sprites but most of the images are all large (like entire testimonial boxes that are 600px wide). The sprite images ended up being like 2mb. That page actually took longer to load for some reason (by almost 2s) so I took them off
The MOST important thing is that everything immediately at the top loads as fast as humanly possible and before anything else so that the sale isn't lost by someone starting at a bunch of images loading out of order. I used some preaching images with this method: http://perishablepress.com/press/2009/01/18/css-image-caching/ - It did seem to work quite well on the smaller images, but when I add the background (which is very graphic intensive) everything seems to slow down at once, like its trying to do a certain number (5?) of images at a time. Ideally I'd love to group the first 4 smaller images being pre-cached, and then follow it up with focusing all bandwidth on the background, then the rest of the entire page in standard order..
Google Page Speed score is 90/100. the only thing its concerned about is unused styles but that I'm not really concerned about because its about 2kb total... the overhead from the 7mb of images is way more important.
I have the option to use a CDN for the images but I'm not sure how I'd go about doing this or if it would actually help?
I feel I've done all I can but then again I could totally be missing something...
A CDN would definitely help. And with 140 pictures, I hope it
contains more than just server. Just link directly to the IP of
the servers, to avoid unnecessary DNS lookup.
Minimize HTTP requests. You mention that you've been experimenting
with sprites. I still believe sprites to be the way to go, but you
might not want to create just one, huge image. If you have 140
images, you should probably have about 10 sprites.
Make sure that you have set headers to make the client cache all
content. Remember ETags.
Gzip/compress content for browsers that allow it.
If the source code is lengthy, make sure to flush the buffer early.
Consider lazily loading images below the fold? There are a number of javascript plugins to accomplish this
scrolling pagination + combining images as sprites on a per-page basis.
Is there any way to do this without bogging down a computer?
I don't know much of the innerworkings of computers and browsers, so I don't know what about a bunch of images on a page takes up so much cpu. My first thought was to hide the images that aren't visible on the page anyway. The ones that have been scrolled past or yet to be scrolled to.
I tried a sample jsfiddle with randomly colored divs instead of pictures, but just scrolling up and down through that makes my computer sound like it's taking off.
What is it about all the pictures that takes up cpu? Can it be avoided?
The question is generally not about the amount of bandwith it might save. It is more about lowering the number of HTTP requests needed to render a webpage.
See this
What takes time, when doing lots of requests to get small contents (like images, icons, and the like) is the multiple round-trips to the server : you end up spending time waiting for the request to go, and the server to respond, instead of using this time to download data.
Less http requests = faster loading overall
If we can minimize the number of requests, we minimize the number of trips to the server, and use our hight-speed connection better (we download a bigger file, instead of waiting for many smaller ones).
That's why CSS sprites are used.
For more informations, you can have a look at, for instance : CSS Sprites: Image Slicing’s Kiss of Death
Other than this you can also use lazy load
One thing I have noticed on some sites is that they use one BIIIIIIIG image containing lots of little images, then use CSS background-position to define the coordinates of each image, rather than use individual images.
Here's where I'm at:
Cons for using big sprite sheet
Need to load a large image to just display even one small image
Need to write (or generate) a long stylesheet with a class for each image
Cluttering CSS with lots of class definitions may impact performance
If one image changes (or another is added), cache problems may be encountered both on the image and the CSS associated with it
Requires a <div> with proper styling (display: inline-block; width: 32px; height: 32px; background-image: url('spritesheet.png');) which adds yet another class to the mix.
Many more that I can't remember now I'm typing them.
Pros for using big sprite sheet
... Erm... none yet.
In fact the only thing that comes close to a pro here is that when I cut up the sheet into individual images the resulting folder took up 3Mb on disk (due to each file being <100 bytes and my allocation size being 4k). The actual files themselves come out less than half the size of the sheet and CSS, so even with the overhead of an HTTP request there is a significant space saving.
Basically, my question is: Does anyone have ANY pros for using a big sheet over individual images?
The aim is to reduce HTTP requests. In addition, sometimes the compressed sprite will weigh less than the original images.
Recently I had a website with a lot of transparent gradients (white to trans, grey to trans) and some black and white on transparent images. By putting them all in a sprite and reducing the colors in the png to 8 I could get the sprite to be smaller in filesize than the original images (just... it was about a 0.5% saving). By reducing the number of HTTP requests from 10 to 1 though meant the site loaded faster (if measuring time from first connection to all data transferred).
In that case, a measurable increase was found.
I agree though that it's possible to mess things up and to end up with a larger sprite than needed, especially if you aren't using PNG compression.
Note two years after posting this – if you are using SSL, you should look into SPDY (my note in a further two years will mention HTTP 2.0 instead of SPDY!). SPDY negates the benefits of spriting.
Not much of what you said as Cons really are cons at all.
When you load one large image, it contains only one of the different attributes that an image needs (color table, mime type etc ex: imagine if you're using a progressive jpg format, one spritesheet will allow the image to be scanned once, whereas many will decrease load time significantly) instead of having the same information in 100 different files, it will lessen the filesize in the big picture.
Also there will only be ONE http request (or two, depending on how many spritesheets you have.) but if handled properly, only one per pageload.
If you're using bg images in CSS, then you already have made the css selectors so there is no extra work, just copy/paste the url.
I've never encountered any cache problems with spritesheets that can't be solved by pressing ctrl+F5.
It doesn't require a div with proper styling in any case at all.
This is not an <img> tag replacement method, it's used primarily for bg images. Like for buttons and icon sets.
The pros far outweigh the cons in this method, the proof is that it has been taken up into use by so very many developers. If it were a terrible method, nobody would have picked it up and somebody would have already raised these issues when it was first put into use.
If anyone has more to add, don't be shy :)
Google describes it here. Basically it should reduce page loading time. Every new connection initialization adds some delay. In some cases it can also reduce data transfer size and therefore also reduce page loading time. It is suitable for images that change rarely or all together (themes). Then browser can use cached image and needs to check only one file for changes not every image one by one.
Sprite sheets are a mess. Period. No need to sugar coat it. They present a massive step backwards in design technology, which probably explains why the only people who like using sprite sheets are old school game developers. Sprite sheets only have one redeeming quality, they are a little faster to load. Other than that, they are garbage. Not to mention a nightmare to set up.
In what world is it "acceptable" to have to include 500 lines of code just to run a simple walk cycle. Hopefully some clever guys will come up with a solution as simple as dragging a self contained, alpha-supporting video format such as flv, but that would also run on tablets...
If you feel like writing a massive list about how great sprites are, I can only wonder how boring your design job must be. The bottom line is that if a "tool" is making it harder for you to do things which should be easy, then it's not a good tool. Throw it away.
Yes - number of requests.
Most browsers will only download around 2 resources per domain in parallel, so if you serve up a lot of small images, the user has to wait for for around half that many HTTP request-response cycles. If you use a sprite, that's only one request and one response (albeit a bigger response).
If you have many images, the browser will need to download each and every one of them. Since the browser can only download a limited number of files simultaneously, this will take time. A single image will only tie one download slot allowing the page to render faster.
Additionally, if used in many other pages, the large sprite sheet will already be cached.
this is specially good for a lot of small images, because the browser only has to do an http request for all the images, and not hundreds of them. So you're web loads much faster on the client browser.
the thing is loading speed. Only one http request is quite faster than dozens of them.
Also, it helps keep your CSS cleaner. For instance, I use sprites for buttons (which also means no extra delay for loading the hover state img)
<button type="submit" class="vorige"><span>Vorige</span></button>
button {display: block; width: 162px; height: 47px; background-position: 0 0;}
button:hover {background-position: 0 94px; cursor: pointer;}
button:active {background-position: 0 47px;}
button span {display: none}
.vorige {background-image: url(../img/button/btn_vorige.png);}
.volgende {background-image: url(../img/button/btn_volgende.png);}
.verstuur {background-image: url(../img/button/btn_verstuur.png);}
because of the sprite I can leave out the code for a seperate hover image:
.vorige:hover {background-image: url(../img/button/btn_vorige_active.png);}
.volgende:hover {background-image: url(../img/button/btn_volgende_active.png);}
.verstuur:hover {background-image: url(../img/button/btn_verstuur_active.png);}
Ok - for a web SITE that loads over and over again this is an obvious question. One sprite sheet (that will probably be cached on the users system) and some fancy css background-position trickery, and you're saving yourself a ton of server requests.
But for a web APP, that loads once, and never again. Is a sprite really the way to go. Yes, breaking it up into individual pngs means that many more requests up front, but in the long run, how does this fair?
I'm guessing it depends entirely on the rendering engine and how the memory management works, but it seems like having a 200k sprite sheet duplicated all over the place might be more costly to performance in the long run...
Normally you will use sprite for change states of particular element, e.g. for the button, not for all the images at once. Benefit of using sprites in that case is not just to save a request, but also to make state changes (say on mouse over) instant.