| This 41 message thread spans 2 pages: < < 41 ( 1  ) || |
|Image Optimization: Are you still concerned about your image file sizes?|
| 3:42 pm on Mar 9, 2008 (gmt 0)|
On any given day, I may perform at least 1-2 quality tests on various websites. Part of that testing includes "Time to Download" and number of "Objects" being served (http requests). Over the years, I've noticed a gradual trend towards the lack of image optimization for the web. Just last week I was reviewing a site which had over 700k of images being served on the home page. Three of those images weighed in at just under 125k, that's pretty big if you ask me.
I've used Fireworks now for years when it comes to image editing for the web. I also use Photoshop and Illustrator when applicable. I'll even fire up Image Ready if I'm feeling frisky. Fireworks and the others offer me a wide range of image optimization options. I still take each and every image and optimize it to the nth degree. It takes all of a few seconds to do so and I'm probably shaving off a few seconds of load time for my visitors.
What's your routine these days? Are you squeezing those file sizes down as far as you can? Or, have you joined the movement that feels "all" of the world is on broadband? Are you compressing using 72 or 96 dpi?
| 11:38 pm on Mar 11, 2008 (gmt 0)|
CSS sprites, image, css, js, and HTML cacheing, gzipped content + multiple domains do wonders on one of my sites - page loads in a split second. Not to mention the low server load.
Image optimization is just one of the many things one can do in order to improve browsing experience.
my 2 cents.
| 12:41 pm on Mar 12, 2008 (gmt 0)|
thecoalman, I agree in many ways. Although I'm not sure that people are any clearer about pixel sizes than any other concept. I think that not only is the general population often confused about dpi, but many web and print professionals are also. The problem with newspapers or printers needing to resize or resample artwork is that there is often a cost for this service. I certainly charge for it. ;) So I have always found the "#*$!dpi at the intended print size" phrase to be the most educational and effective.
| 4:11 pm on Mar 14, 2008 (gmt 0)|
> Are you squeezing those file sizes down as far as you can? <
One tries. Photoshop has probably been as good or better than anything else for at least a decade. Saving as progressive jpg starts the display of the entire image faster rather than scrolling it down. It's useful to enlarge the image as one reduces the quality setting to see how it's being mangled. Low resolution screens will be able to see that. With .gifs, all you can do is reduce the color pallette size.
Perhaps what one can do is serve out a .jpg at one size, clean, not pixellated, as it were, no obvious stair-stepping, but still with crisp transitions to edges, and scale it up in the page with script or just height and width attributes. If it's a lined gif, a chart, etc, then it's probably 100% scale or nothing, or illegible otherwise in other words.
The idea of having some graphics on another server is supposed to be faster, they say. I haven't tried it.
Another thing is to load the graphics, later. Put up the page, and load the images with script at the very end. So the page is up, and the graphics are filling in. Some you'll want to 'progressively' display. But others you want to show just when completely loaded. So in script one can create a new Image, or assign to an existing image object, the url or relative url of the image using the "src" property. But just before that, one sets the "onload" handler to some function that displays the image, or uses it as part of another object, etc.
I don't know that servers get hung up at any particular file size. You'll get 'chunks' set, anyway, for various files over the same open connection with the 'keep alive'. But maybe. I don't know. Maybe it's best to keep the files under 30K or whatever, for particularly good speed. Someone else may know.
| 4:14 pm on Mar 14, 2008 (gmt 0)|
> multiple domains <
travelorama - are these yimg or similar servers, or just your own subdomains on the same server? And what's the real speed improvement if say you take half the files off your domain, and half off another or a subdomain of yours? as opposed to all coming from your domain.
| 5:07 pm on Mar 14, 2008 (gmt 0)|
I have found 80% compression (in Picture Window) is best for my clients. Most are real estate sites and below 80% the sky can start to be distorted.
That said, my widest pix are 400 pixels and usually come in under 40K. When I started doing the sites, broadband wasn't available, but even now my clients like having quick loading pages.
| 8:36 pm on Mar 23, 2008 (gmt 0)|
been seeing a lot of pictures sliced to small pieces.. what would that help?
| 10:34 am on Mar 24, 2008 (gmt 0)|
It allows you to 'spot' optimise different areas of an image and so reduce overall file size. Especially when mixing .gif and .jpeg formats for one large image.,
| 12:24 pm on Mar 24, 2008 (gmt 0)|
To add to what bouncybunny said it would also be useful if you had a large image with just small portion of it animated.
| 5:11 pm on Mar 25, 2008 (gmt 0)|
| 8:09 am on Apr 20, 2008 (gmt 0)|
I, too, deploy a lot of CSS to minimize the imaging on a site, but overall, I think it depends on the site. If I'm designing a portfolio site for a photographer, or some variety of brochure site requiring a rich visual experience, I might increase the number of images used, but still try to squeeze every last bit of compression from every images.
E-commerce sites are a different animal altogether. Visitors might notice the visuals at a site on the first visit, but as they return, they're on a mission to accomplish an objective, which is usually to spend money. Far be it from me to erect obstacles to succeeding in THAT task! Site speed is golden in the world of commerce. Anorexic imaging is imperative! Less is more...
| 5:28 pm on May 5, 2008 (gmt 0)|
I discovered that the GIMP on wins
does what I consider the best job in img optimization
give it a try (it's free :) )
| This 41 message thread spans 2 pages: < < 41 ( 1  ) |