Hello, I have been building sites for years and have had a lot of trouble in making the images on them load faster. I usually use .PNGs, as they are faster, secondly, I use .JPG for more complex images, such as photos. Overall my pages appear sluggishly with slowly loading images. I use CSS, of course, I separate content from code as much as possible. How can I make images load much faster? Like they do on other sites...
Keeping in mind that you said you use CSS I might not be very helpful, but would like to point out some usages of it, whether or not you have been practicing them. When you finish making a design for a site in a painting software such as Photoshop or whatever you feel comfortable with, you should look at what parts of the design are repetitive and can cut just a long enough piece of them so that you can make a CSS div and specify it's background image to be drawn multiple times across the screen. If that is not your case, then I'm sorry. What I can think up of for making images load faster is probably find a balance between quality and size. For example you could use a graphics editing software such as Photoshop to change the quality of the image and see a preview of it, along with it's potential new size in kb. Other things you can do is use .gif images when you don't have too many important colors on your image so that it won't suffer from having only 256 colors to work with. My final thought is, if you are having good quality/large photos (which can take anything from 1-2mb to 10mb) you can have thumbs of them on the main page and have the user click on them in order to load the larger version of the image. Another idea that comes to mind is to use prefetching of images that aren't drawn currently but would probably be needed, using javascript which could save you some time when the user goes further in your website. Using any kind of compression or working with images which fit their size (instead of letting the browser shrink large images in tiny boxes) can greatly diminish the page load time. If nothing here helps then perhaps you should consider using less images and more inventive uses of CSS in order to speed your page loading times.
Hello Alejandro, Thank you for the tips. I might particularly be interested in the "prefetching of images " you mentioned. All the rest I am already doing... I've seen plenty of sites with far more complex graphics and lightning-fast loading times. Even my simplest sites load too slow (in my opinion), so I'd like to learn more about how to speed them up. Thanks!
Check a free performance scan here by entering your website url. http://zoompf.com/free This will show your original image sizes in your site and how much bandwidth you can save by optimizing the images.
One good step is to just use less images -- by combining existing ones together into single files using the so-called CSS sprites. If you are practicing proper separation of presentation from content this is quite often easy to do... less files means less handshaking and faster page loads. At the same time splitting up really big files can ALSO provide improvements -- this is particularly true of jpegs... JPEG is great on filesizes and compression for photographs, while PNG is superior on line-art. The artifacts JPEG adds are barely noticeable at up to 25% lossy, while on a lineart even 5% lossy can be painfully obvious. You mention 256 color -- gif really doesn't do anything more than 16 color well, in which case you are better off using 8 bit png instead... as a rule of thumb GIF doesn't really shine until down below 4k pixels in 16 color. If you are referring to the site in your signature -- well, I'll go ahead and use that as an example. The broken layout caused by the fixed height elements indicates an over-reliance on images and declaring heights on things that, to be frank, shouldn't have heights on them! (have you seen your site at large fonts/120dpi?) This is borne out by the use of images for text on the menu (that's also contrast-wise below accessibility minimums) and 23 images on a page that by my count only needs 7... From what I'm seeing in the source code you are NOT practicing separation of presentation from content, semantic markup, or even modern coding practices... multiple paragraph tags around single paragraphs, not allowing flow to do it's job, presentational classes everywhere, paragraphs doing heading's job, presentational images in the markup, an iframe for a tiny little bit of static content, no lists around obvious lists, doctype that is (and likely never will be) real world deployable... all of that would have to be cleaned up LONG before worrying about file sizes and/or counts. Hmm... do I smell a WYSIWYG at use here?.. you've got zero graceful degredation images off, or CSS off... javascript doing CSS' job, invalid/improper markup like wrapping block level elements in inlines, and those alone could be contributing to your woes as that too takes time for the browsers to 'fix'. I would also advise against sticking every sub-page in it's own directory -- subdirectories are fine for things called by the markup, but your use of that structure means up-tree linking (parent directories), which can be slower than down-tree (child directories)... this is particularly true when your subpages should be sharing images and other files like the CSS. You're using separate CSS files and different URL's for the same files/appearance across multiple pages, and that takes longer... If that's the type of site you're having issues with, loading times are just the tip of the iceberg... I'm a bit busy this evening, but later on I may do a quick 'rewrite' of that page to show you what I mean and show you how to make it more accessible, faster loading, and in general cleaner/easier to maintain.
Just to illustrate what I meant by broken, I took a screencap: http://www.cutcodedown.com/for_others/mrDog/images/broken.jpg All those manual line-breaks (done with P, when the P should be wrapping with the breaks inside if you're gonna do that) just result in a broken page at large fonts -- and locks you into not being able to have a semi-fluid layout. I did that rewrite, took me about 20 minutes altogether. http://www.cutcodedown.com/for_others/mrDog/template.html as with all my examples the directory is open for easy access to the bits and pieces: http://www.cutcodedown.com/for_others/mrDog/ It takes a few visual liberties, but it also takes it down from the original's 210k in 22 files, to a mere 46k in 11 files. The filecount reduction ALONE can cut as much as fifteen seconds off the page load on a really poor connection or a really poor server. (I do think you may also be plagued by the latter). Gets rid of the stupid malfing iFrame nonsense, opens it up semi-fluid, uses text for text where possible, and has for-the-most-part graceful degradation CSS off or Images off. (the social icons are always a problem with images off, oh well). In testing for me, the original took ~5 seconds to load -- the waterfall in Dragonfly showing that it's mostly the smaller png files that are taking ridiculous amounts of time (3 seconds for the social icons for example)... welcome-grn-img-001.png was really absurd, accounting for 4 and a half seconds of that five second page load! Size isn't always the determining factor in handling an image, the 'wait' for transfer on a few of those is so high I suspect your hosting is misconfigured or overburdened. The changes made in my version alleviates that burden by reducing the number of files... Take those social icons -- your three files totalling 3.5k were replaced by this single 3.5k image: Which not only replaces those 3 handshakes to the server with just one, it also adds three more images to the mix for hover states! In the original, welcome-grn-img-001.png is 90% of the page's size... 110k for a line-art is a little ridiculous. My replacement does have some dithering, but I was able to get the size WAY down by dropping it to a 8 bit palette with single color transparency. I used a light 5% floodfill to make the single color transparent area leaving the edging/anti-aliasing pixels for the most part in place. This is called 'close enough' anti-aliasing. PNG and GIF can both take long runs of the same color and shrink them to nothing, so having a uniform background cut the file size down even further. Net result? A 25k image -- 75% reduction in size. One of the biggest bits of savings is the menu -- I know people get their heart set on a certain font, but to be brutally frank, even with CSS3's webfonts you're just pissing away bandwidth on trying to intentionally make it illegible. People will be far more impressed with a fast loading well laid out site than they will stupid image tricks with a menu... as such I just used background-image for the gradient, and have actual text there. If you REALLY had your heart set on the "stupid image tricks" there, combine them into a single file as per what I did with the social icons. The home page banner area, and the 'four across' content sections below are a royal PITA -- because they reek of the "But I can do it in Photoshop" mentality. -- emphasis on the "mental". Both are what I like to call "not viable for web deployment" as they prevent you from even trying to have what people are now calling "responsive layout". I did the best I could with them, but really it's something that doesn't belong on a website in the first place! A number of things I did, like the "See Offers" button involved not using images in the first place... CSS3 now lets you round corners, add shadows, whole host of other niceties... without images or with simply using an image for a gradient. CSS3 can even provide those gradients, though I avoid those for now because they're still slow and memory hogging. Naturally IE8/lower users won't get the shadows or rounded corners -- OH WELL. It is no longer worth supporting 100% identical layout in what is a rapidly dwindling portion of the community. That does NOT mean your page should not work for those users -- this rewrite is functional all the way back to IE 5.5 -- just don't go nuts fiving them all the bells and whistles. Don't even waste your time on stupid javascripted shiv's and polyfills -- they get a lesser experience, who cares. Does it work? That's what's important. Again, people do NOT visit websites for the goofy graphics you hang around the content, they visit FOR THE CONTENT! That's actually one of the entire POINTS of using HTML and CSS - you start out with semantic markup saying what things ARE, NOT what they are going to look like, then you progressively enhance that content with css, images and scripting. If you build with progressive enhancement, the page will gracefully degrade when/if/should those fancy technologies not be available. Which is also why I put hanging images on the layout LAST in the design process. It's easier to make a flexible tileable image and attach it to content, than it is to shoe-horn content into a fixed size image... and if you work that way, you often find yourself using less and less images for the same effects -- ESPECIALLY with CSS3 now reasonably viable. If you'll notice, I didn't consider ANY of the images you had on the page to even be content -- which is why there's not a IMG tag to be found anywhere. IMG is for CONTENT -- what's on that site is presentation. Hope this helps clarify or get you thinking on different ways of handling things. -- edit -- PS, I don't know what you were saving those images in (I suspect photoshop), but it's file optimization was rubbish. Many of your images I could simply load into Paint Shop Pro, hit save, and knock 20% off the filesize... but again, Adobe wouldn't know file optimization from the hole in a Photoshop DVD.