As a web designer, do I still need to aim for under 50kb files?

September 15, 2008 5:48 PM

Web designers, what is the maximum recommended file size for site designs in this day and age?

I'm sitting here putzing around with a website I'm building, trying to optimize images and trim down code and I'm getting frustrated. This site design is for a friend's rock band and it has a lot of imagery and graphics associated with it. I was originally taught to aim for building sites that totaled under 50kbs, but that was in 2003. Here we are five years later and I find myself questioning this, considering how many people must be on DSL or cable internet now.

So, all things considered, can I consider upping my max total to 100kb or maybe even more? I look at other sites and see beautiful, crisp graphics and I'm jealous!

Details that may matter:
-This design is going to be a template for Joomla.
-My client may or may not want to have a streaming MP3 player on the front page, which would obviously add to the size.
-There is a gallery plugin which will show 3-4 thumbnails from a gallery component on the front page.
-I'm going to limit how much content can be shown on the front page - it's a fixed height and any news/tour dates/images will spill over into respective pages.
-The audience for this website is intended to be college age to late twenties. Whether this makes them more likely to have high speed internet, well, I'd have to assume so but I would like to hear what you think.
-This is a tableless design and will be styled by an external style sheet.
-I'm using Photoshop CS3 and Dreamweaver CS3.
-I have a little over half of the images in place so far and the Firefox Web Developer Toolbar is telling me that the site totals 39 KB. It is not attached to Joomla yet. I'd love to bring the quality up on the images that are already implemented in the design.
-I'm planning develop a separate mobile site that loads upon detection.

Any tips for image optimization or code optimization would be very helpful, too.

Thanks in advance!

posted by bristolcat to Computers & Internet (15 answers total)

Best answer: I think you are fine. Broadband is ubiquitous. The last numbers I heard from a couple years ago said that over 70% of web users have broadband access. As long as you are optimizing your images by giving them enough compression to save space, but still high enough quality to look good, you should be fine. Keep in mind also that your header and other repeated graphics only need to load once, and they will be cached for subsequent pages.

The illusion of speedy loading is more important than actual speedy loading. If the visitor sees the heading and some text to read while other elements keep loading, then there's no problem. Users will bail from a site if nothing seems o be happening, or they are staring at a "loading" screen for too long.

Also remember that a visitor to a band site (or an art site) will be more patient than someone who is shopping around for something that can be found in many places.
posted by Fuzzy Skinner at 6:05 PM on September 15, 2008

Best answer: I agree. 100KB (maybe even more) not including Flash should be fine for most anywhere. People expect music on band sites, so they are probably coming prepared. I learned during the last days of dial-up and still find it rather hard to get into the mindset that it's generally okay not to worry about scrimping and saving in exchange for improved quality.

Images: I haven't seen anyone using .gif for anything more than lines recently. Alpha .png is basically everywhere but IE6 and there are always workarounds. Otherwise, anywhere that you can use background colors instead of images will help a little (#requests and total size).

Remember that if for some reason they get popular quickly, the larger filesizes will take up exponentially more traffic bandwidth...
posted by PixelatorOfTime at 6:31 PM on September 15, 2008

Best answer: Install YSlow and use it to check the size and load time of other band websites.
posted by PueExMachina at 6:38 PM on September 15, 2008

Google's home page is 71KB (199KB uncompressed), for what it's worth.

Are you looking at iGoogle? My logged-in Google home page is 17KB (23KB uncompressed), along with all the images. It becomes 21KB (24KB uncompressed) when I log out.

Page load times, a big component of which is the page size, is still important today. Web developers and designers spend a lot of time and effort to reduce load times because for every extra second it takes to load your site, a certain number of visitors will get bored/frustrated/distracted and click away.
posted by qvtqht at 6:54 PM on September 15, 2008

Best answer: Seconding YSlow, it will give you a lot of good feedback.

Page size is obviously important, but users are willing to put up with larger pages if you have a fast response and display time. That is to say, if you can make your page start rendering within the first second or so, users will stick around longer to let the rest of the page render, rather than just having the whole page render in one shot.

Some quick tips to help the render time:

- Use width and height attributes on all of your images.
- Push Javascript as low down on the page as possible, ideally outside any container divs.
- Use container divs sparingly; don't contain the entire page, just contain sections of it at a time.
- Put inline any css that is only used once on the page & site. (Some designers are shouting "heresy!" right now, but trust me, the rendering is actually faster)
- If you're going to have an embed on the page, use a Javascript ondomready event to write out the embed code. This way, the user's browser will render the page before attempting to load the embedded application.
posted by mark242 at 7:22 PM on September 15, 2008

Response by poster: Thanks everyone! I feel a lot better about the site now. And I have a lot of great tips to look into!
posted by bristolcat at 7:47 PM on September 15, 2008

One thing that I know Google concentrates on is keeping the number of requests as low as possible. Your image may be tiny, but it may take longer to request it than it does to send the bytes around, especially with asynchronous broadband connections.
posted by smackfu at 7:59 PM on September 15, 2008

That last point is especially important for people on satellite connections, which tend to have quite reasonable speeds but very slow request-to-response times.
posted by flabdablet at 12:32 AM on September 16, 2008

To get round those request-to-response times, use CSS sprites for all of your CSS background images, and concatenate and minify your CSS and JS.
posted by armoured-ant at 12:38 AM on September 16, 2008

3rding PueExMachina with YSlow but also his comment to check other band websites. You need to compare what you are doing with what the standard is already.
posted by sando at 5:47 AM on September 16, 2008

You can also use the net part of firebug to check out other sites. I think 100kb is fine. Definitely sprite your images. Otherwise, cutting out a few lines of code is really not going to affect the load speed... but for your own sanity keeping it clean might be good =)
posted by shownomercy at 6:50 AM on September 16, 2008

I haven't worried about meeting specific size requirements in years. Obviously, you want to keep everything as slim as possible—prepare images properly, use clean HTML and CSS, compress your JavaScript, make sure gzip is enabled on your server, avoid gratuitous content—but so long as everything on your page serves a purpose and is optimized to a reasonable degree, I wouldn't worry too much about it.

If you haven't already, learn about the PNG image format; it has widespread browser support these days, can sometimes produce smaller image files, and is superior to JPEG and GIF in certain situations.

Eschew text-as-images in favor of HTML and CSS.

Seconding mark242's remarks about render time.
posted by greenie2600 at 6:59 AM on September 16, 2008

Response by poster: OK, I hadn't heard about CSS sprites before, so I followed the links suggested and found this one on CSS tricks, too (which I found a little less over-my-head than the A List Apart link). I have a question about these sprites - do you generally put ALL your graphics into this sprite file or just little things like navigation? Would I put my banner image, my background image, etc into this file? I am a sponge, willing to soak up your advice.

Also, I'm using a transparent PNG to overlay a logo over my header banner. How would this work with sprites?

Thanks for all the great answers I got overnight. It's obvious that I need to pull my ass out of 2003 and get up-to-date on some of the latest tricks. Anyone got any sites that I can use to hone my CSS-fu? I watched some stuff on Lynda.com but it mostly seemed to be stuff that was familiar already.
posted by bristolcat at 9:04 AM on September 16, 2008

Response by poster: This is another stupid question, but I got to thinking and here goes. If I were to make the page using CSS sprites for large images, couldn't I really just save my photoshop mockup as one big image, make it the background in one big div and lay my dynamic content over that? It seems counter to everything I've been taught, but it would only mean like three-four requests total. That is, if I understand this correctly.
posted by bristolcat at 11:24 AM on September 16, 2008

I only use the so-called sprite technique for specific purposes—namely, I make an image that includes both the normal and hover states of a single nav item, and use the background-position property to shift the image on hover. I do it primarily to avoid the hassle of preloading the hover states. You could pretty easily extend this technique to include all normal and hover states of all nav items in a single spritemap, though.

You have to balance the benefit of faster loading with the penalty of more complex development and maintenance, though. It's easy to get carried away with a neat new technique—IMHO, putting all your images in a single file is overkill. Anyway, I'd imagine that would reduce rendering performance at some point.

Of course, you wouldn't want to include photos or complex artwork in your spritemap; JPEG compression is better suited to those kinds of images, and any performance benefit you'd get from spriting would quickly be negated by the performance hit from bloated file sizes.

Saving your Photoshop mockup as one big image would include a huge amount of redundant or unnecessary bitmap data in your image file—whitespace and areas of solid color, gradient fills that would be more efficiently handled by tiling a narrow slice of the gradient, any elements that appear more than once, &c. Anyway, the performance of GIF vs. PNG vs. JPEG (in terms of file size and image fidelity) varies widely depending on the kind of image—and if you're using a single spritemap for everything, you have to choose one image format, which will work well for parts of the image and horribly for others. This is not an advisable approach.

As for the transparent PNG: well, make your spritemap image a PNG, and make the necessary parts transparent.

Really, though, I think you're getting carried away with the spriting thing. I think it makes sense for limited applications, such as graphical nav bars and icons, but that's about it. Remember: browsers cache stuff. And bandwidth, though limited, is not so precious that you must base your entire site architecture around conserving it.
posted by greenie2600 at 3:53 PM on September 16, 2008