I am a beginning programmer and I really want to have good habits and practices. I have yet to slice up a PSD and code it. Is this a bad practice? I have heard it creates bad code that had to be fixed anyway so why do it? I want to create clean code even if it takes longer. Just wondering if it is as bad as I have heard. Are there advantages to doing it this way? Do I need to learn this skill to make good sites? Thanks.
If your images are very large, then sometimes slicing them into pieces and generating the right HTML that lines up all the pieces can be a better user experience. These days, this seems to matter more for those on very slow links (like dial-up) or very poor links (lots of errors) and less for those on typical internet links unless the images are very large.
Overall, slicing images is more overhead for the browser (more HTML, more separate image request for both client and server) so it's only beneficial when specifically needed to solve a problem. I would not do it by default unless you had a specific problem you were trying to solve with the image slicing.
Your background image shouldn't be a very complex image and if it is try to make it as optimized as possible so the load time is efficient for slower downloads. As for slicing I wouldn't use it all that often as it does cause alot of browser requests, again be sure all are optimized so the download time is very minor. Something to look into is using sprites (I know it wasn't the question) these are very useful for images that don't really matter to SEO of the site (buttons, arrows, bullets, etc. The big thing anymore is download speed you want to keep the images cached, optimized and as minimal bandwidth as possible. If your page takes too long to load then your users will leave, that should drive your image create more than best-practices.
Related
On my page, I'm populating quite a few images, they aren't SUPER high resolution, but I aggregate the images, so I don't have the stored in smaller sizes. When I start putting lots on the page, it gets sluggish. Is there something I can do to fix this? Like some kind of on-the-fly image compression?
Have you looked into techniques of lazy-loading your images? http://www.appelsiini.net/projects/lazyload
Looks like the problem happened because you were using the full-res pictures to display thumbnails. This is a performance nightmare! You might benefit from reading:
http://ask-leo.com/why_do_some_website_pictures_display_so_slowly.html
You really need to make thumbs of these images to make it quicker. It makes no sense to download all high-res images at the same time.
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.
I've been working on a website, and we've managed to reduce the total content for a page load from 13.7MiB's to 2.4, but the page still takes forever to load.
It's a joomla site (ick), and it has a lot of redundant DOM elements (2000+ for the home page), and make 60+ HttpRequest's per page load, counting all the css, js, and image requests. Unlike drupal, joomla won't merge them all on the fly, and they have to be kept separate or else the joomla components will go nuts.
What can I do to improve load time?
Things I've done:
Added colors to dom elements that have large images as their background so the color is loaded, then the image
Reduced excessively large images to much smaller file sizes
Reduced DOM elements to ~2000, from ~5000
Loading CSS at the start of the page, and javascript at the end
Not totally possible, joomla injects it's own javascript and css and it does it at the header, always.
Minified most javascript
Setup caching and gziping on server
Uncached size 2.4MB, cached is ~300KB, but even with so many dom elements, the page takes a good bit of time to render.
What more can I do to improve the load time?
Check out this article.
http://www.smashingmagazine.com/2010/01/06/page-performance-what-to-know-and-what-you-can-do/
If the link gets removed or lost the tools mentioned are:
YSlow (by Yahoo)
Google's Page speed
AOLs web page test
Smush.it (Image compression tool)
It sounds like you've done a great job of working around the real problem: those giant graphics. You can probably squeeze some more efficiency out of caching, minifying, etc., but there has to be a way to reduce the size of the images. I worked with a team of some of the pickiest designers on Earth and they never required uncompressed JPEGs. Do you mean images cut out of Photoshop and saved on full quality (10)? If so, the real solution (and I appreciate that you may not be able to accomplish this) is to have a hard conversation where you explain to the design company, "You are not your users." If the purpose of the site is to only impress other visual designers with the fidelity of your imagery, maybe it's ok. If the purpose of the site is to be a portfolio that gains your company work, they need to re-asses who their audience is and what the audience wants. Which, I'm guessing, is not 2 minute load times.
Have you enabled HTTP Compression (gzip) on your web servers? That will reduce the transfer size of all text-based files by 60-90%. And your page will load 6-10x faster.
Search StackOverflow or Google for how to enable it. (It varies per server software: Apache, IIS, etc).
Are all the DOM elements necessary? If they are, is it possible to hide them as the page loads? Essentially, you would have your important need-to-be-there dom elements render with the page, and then when the document is loaded, you could unhide the rest of the elements as necessary
$('.hidden').removeClass('hidden')
Evidently, there are plugins for compressing and combining JS/CSS files:
http://extensions.joomla.org/extensions/site-management/site-performance
http://extensions.joomla.org/extensions/site-management/site-performance/7350
I would say you can't do anything. You're close to the absolute limit.
Once you get to a critical point, you'll have to compare the amount of effort you'd need to input into further compressing the site against the effort of throwing the most bandwidth expensive components out the window. For example, you might spend 20 hours further compressing your site by 1%. You might also spend 40 hours on throwing the Joomla theme away and starting again saving 50%. (though probably not).
I hope you find an easy answer. I feel your pain as I am struggling to finish a Drupal project than has been massacred by a designer who hasn't implemented his own code in years and has become institutionalized in a cubicle somewhere near a tuna salad sandwich.
When designing my homepage, I feel like the common knowledge is that it is bad to just have one big picture in the center that gives all of the content. The "right" way to do it would be to chop up the large layed out image into several small backgrounds and make the text use standard html with css background images for layout.
Is the only reason one big image is bad SEO reasons?
A search engine can't make sense of it.
A blind or otherwise visually-impaired person can't make sense of it.
Someone blocking images because he's on a mobile phone with expensive internet can't make sense of it.
There are a few reasons :-)
Also important:
Changes are not easily made to whole, pre-composited images, unless you still have access to the original layered variants. And hopefully they contain text as well, not just pixel data. (Mentioned by others before already. Credits go to pierre and Kendrick)
If you're using background images don't forget to set a text and background color too. Otherwise people not seeing any images might have a hard time deciphering your text (black on black isn't nice to read :-))
You can still use one large image as background. How the text is layed out above that is another matter entirely. In fact, chopping up the image and piecing the pieces together is painful using CSS too. In my experience it's best and easiest to leave background images unchopped and instead composite the rest of the layout above them, using other images or backgrounds if needed. This gives you a little more flexibility when changing a layout again, too.
SEO is one. Handicapped accessibility is another big one -- a screen reader can't read text within an image, typically. Page load time is another one; a user with a slow connection won't see anything useful while the image loads. Lastly, many browsers will use multiple connections to request resources such as images, so they can be loaded simultaneously. If there's just one image, only one connection can be used.
Updating will be tedious; you can also no longer rely on many benefits of CSS.
It's also bad for accessibility (screen readers, text-resizing, different monitor sizes)
It also removes your ability to easily edit text content.
I certainly wouldn't do it if you're looking for a web-developer job, but if you really don't care about the above, you won't be the first person to do it...
I see no reason at all in using imagea to represent something what can easily be achieved with HTML and CSS.
You're putting up a web site to enable communication between you and your visitors. Images and Flash prevent that.
Generally, you design a site with HTML/CSS and text. Only when you wish to add some design that cannot be expressed with standard means, then you use images. But have your site degrade gracefully for those who cannot or does not wish to see images. Let images be an addition, like an advanced version, in no case a replacement for text.
So I was looking at the facebook HTML with firebug, and I chanced upon this image
and came to the conclusion that facebook uses this large image (with tricky image positioning code) rather than many small ones for its graphical elements. Is this more efficient than storing many small images?
Can anybody give any clues as to why facebook would do this.
These are called CSS sprites, and yes, they're more efficient - the user only has to download one file, which reduces the number of HTTP requests to load the page. See this page for more info.
The problem with the pro-performance viewpoint is that it always seems to present the "Why" (performance), often without the "How", and never "Why Not".
CSS Sprites do have a positive impact on performance, for reasons that other posters here have gone into in detail. However, they do have a downside: maintainability; removing, changing, and particularly resizing images becomes more difficult - mostly because of the alterations that need to be made to the background-position-riddled stylesheet along with every change to the size of a sprite, or to the shape of the map.
I think it's a minority view, but I firmly believe that maintainability concerns should outweigh performance concerns in the vast majority of cases. If the performance is necessary, then go ahead, but be aware of the cost.
That said, the performance impact is massive - particularly when you're using rollovers and want to avoid that effect you get when you mouseover an image then the browser goes away to request the rollover. It's appropriate to refactor your images into a sprite map once your requirements have settled down - particularly if your site is going to be under heavy traffic (and certainly the big examples people have been pulling out - facebook, amazon, yahoo - all fit that profile).
There are a few cases where you can use them with basically no cost. Any time you're slicing an image, using a single image and background-position tags is probably cheaper. Any time you've got a standard set of icons - especially if they're of uniform size and unlikely to change. Plus, of course, any time when the performance really matters, and you've got the budget to cover the maintenance.
If at all possible, use a tool and document your use of it so that whoever has to maintain your sprites knows about it. http://csssprites.org/ is the only tool I've looked into in any detail, but http://spriteme.org/ looks seriously awesome.
The technique is dubbed "css sprites".
See:
What are the advantages of using CSS
Sprites in web applications?
Performance of css sprites
How do CSS sprites speed up a web
site?
Since other users have answered this already, here's how to do it, and another way is here.
Opening connections is more costly than simply continuing a transfer. Similarly, the browser only needs to cache one file instead of hundreds.
yet another resource: http://www.smashingmagazine.com/2009/04/27/the-mystery-of-css-sprites-techniques-tools-and-tutorials/
One of the major benefits of CSS sprites is that it add virtually 0 server overhead and is all calculated client side. A huge gain for no server side performance hit.
Simple answer, you only have to 'fetch' one image file and it is 'cut' for different views, if you used multiple images that would be multiple files you would need to download, which simply would equate into additional time to download everything.
Cutting up the large image into 'sprites' makes one HTTP request and provides a no flicker approach as well to 'onmouseover' elements (if you reuse the same large image for a mouse over effect).
Css Sprites tecnique is a method for reducing the number of image requests using background position.
Best Practices for Speeding Up Your Web Site
CSS Sprites: Image Slicing’s Kiss of Death
Google also does it - I've written a blog post on it here: http://www.stevefenton.co.uk/Content/Blog/Date/200905/Blog/Google-Uses-Image-Sprites/
But the essence of it is that you make a single http request for one big image, rather than 20 small http requests.
If you watch a http request, they spend more time waiting to start downloading than actually downloading, so it's much faster to do it in one hit - chunky, not chatty!