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.
Related
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
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.
I'm using several PNG images (via CSS) into a site's template, xhtml and CSS,.
I've kept the pngs as small as possible, and optimised as possible, but when testing it in any browser (Safari, Firefox, IEs) it takes at least 2 seconds to render.
Unfortunately I can't share the code here, but I can say that I've removed all javascript and my html code is fairly small (about 250 lines and no tables) and validates correctly.
I would like to know if the PNGs are the "guilty" part as this is my first site done almost exclusively with pngs (instead of gifs + jpegs) (I won't support IE6 so no need for hacks).
No, they do not take time to render (unless you have a really slow computer). What does take time, is the retrieving of a lot of small files. When you query a web-server for a small file, the time retrieving the file itself does not take long. But to setup the connection etc. etc. adds up.
So, what you should do, is to make what is called a "sprite". Combine all the small images to one large and "cut" them with CSS. How it is done and what it is exactly is explained here:
http://css-tricks.com/css-sprites/
and here
http://www.smashingmagazine.com/2009/04/27/the-mystery-of-css-sprites-techniques-tools-and-tutorials/
If you have many images (doesn't have to be PNGs), then download times will be impacted. By default browsers have a limited number of threads to download content with (IIRC FF has 4), so the more images you have, the longer things will take.
Additionally, if you don't specify dimensions on your images, the browser can only correctly layout the page when an image arrives. It will need to reflow the layout for every such image, which is both expensive and time consuming.
In short, ensure you don't have too many images to download and that the HTML markup has the right dimensions for them.
One workaround for having many images is to use CSS sprites.
Check this link. Read under the "Optimize Images" tab.
Best Practices for Speeding Up Your Web Site
Speed up Images Load Time
I hope this was the thing you needed.
On a website I'm creating, I have about 100 various thumbnails (64x64) that get displayed at different times. On some pages, only 5-15 thumbnails may be displayed. On others, all 100 are loaded.
I'm considering using a technique like CSS sprites to display the images. That is, rather than have image tags for each thumb, do something like:
<span class=thumb1"></span>
And then use CSS to take a slice of one single image with all the thumbs stitched together. That is, one image with all 100 thumbs (in this scenario, a 640x640 image).
My questions:
Is this a good idea?
If yes,
should I do it on all pages the
images occur, or only on the pages
with all the images?
Is there
another technique other than sprites
that may be better than simply
including the images with img tags?
If you think that an ordinary user would visit at least two different pages with these thumbnails than my opinion is that using sprites would really be a good idea!
I would in fact make a single big image with all the thumbnails and then use it in all the pages!
Why?
Fewer http requests (from 100 to 1)! And this is one of the most important thing about web site optimizations (read here from Yahoo Performance Team speed optimization rules )
This way users will download the whole image only the first time and then they will get a super quick loading of that images in all the following pages
The most famous websites on the internet already do that! See sprites used in Yahoo, Amazon or Youtube pages.
You can add other UI or layout images to your sprite
Optimize the resulting PNG:
After you have generated your sprite, if a PNG, you can optimize the PNG even more using this tool: http://www.sitepoint.com/blogs/2009/09/18/squishing-the-last-drops-from-your-pngs/
When not to use sprites:
When part of the images in the sprite change frequently
In this specific case: when the majority of users would need less than the (about) 10% of the images
I'm not quite sure what you mean with "sprites", but this is what I think you mean: instead of 100 images seperately, you create 1 image, with a 10x10 raster. Each coordinate (x,y) contains one of the images you like to show.
Now, if you display an image, you use CSS to set background-location: i.e. x * -64px and y * -64px, perhaps using JavaScript to calculate the x and y for each image-span, or Server-Side scripting to print out a dynamic CSS.
Yes, this is a good idea: it reduces load time, since one only has to download one big image, instead of hundreds of smaller ones.
It depends. If you have caching-abilities for a page, then you can "stitch" all thumbnails into one image file. If you have a very dynamic webpage, then it's quite harsh to build this stitched image every time the thumbnales are updated.
Not sure, if this is what you ment with "sprites", then no, if you ment something else with "sprites", then yes: this answer is an example of one.
It is a good idea if
Speed matters
You don't care about accessibility (screen readers reading the ALT text of an image, etc, all that is gone when you use sprites)
You don't care that your thumbnails are not going to be printed by default in any browser
You can do it without it becoming a maintenance nightmare (which image was on position 461 again?)
As to your second question, it is probably advisable to put all sprites into one or very few container images to minimize loading times.
I don't have much experience with the sprite approach to images (http://www.alistapart.com/articles/sprites). Anyone care to share some pros/cons of sprites vs. old-school slices?
The main advantage of sprites is that the browser has to request less pictures from the webserver. That reduces the number of HTTP requests and makes it possible to compress the parts of the design more effectively. These two points also represent the disadvantages of sliced images.
Here you can see some good examples how sprites improve the loading speed of web pages:
http://css-tricks.com/css-sprites/
Pros:
It's far easier on the server to serve a single large image than many small ones.
It's (slightly) faster for a web browser to load such an image.
Browsers only load images as they needs them - if you are using multiple images in a rollover, the browser would "pause" the first time you roll over the element. This can be solved using sprites, because there is only one image to load.
Cons:
It's kind of a pain to code (more so than using multiple images at least)
One often overlooked downside of using CSS sprites is memory footprint:
https://web.archive.org/web/20130605000516/http://blog.vlad1.com/2009/06/22/to-sprite-or-not-to-sprite/
Unless the sprite image is carefully constructed, you end up with
incredible amounts of wasted space. My favourite example is from WHIT
TV’s web site, where this image is used as a sprite. Note that
this is a 1299×15,000 PNG. It compresses quite well — the actual
download size is around 26K — but browsers don’t render compressed
image data. When this image is downloaded and decompressed, it will
use almost 75MB in memory (1299 * 15000 * 4).
When sprites get loaded into the browser, they are stored uncompressed. A 26 KB file can uncompress to take up a whopping 75 MB of RAM. You should be mindful of using sprites with very large dimensions.
There's also the issue of what happens in browsers with poor CSS support (legacy browsers). The sprites may end up totally broken.
Sprites
Pros:
Less HTTP connections to the server
Faster loading on broadband
Cons:
No encapsulation: If you want to change one image, you have to change the sprite
It is difficult to setup individual images in CSS without a tool
Don't degrade: If the browser don't support CSS, you are in trouble
CSS Sprites:
Pros:
Graceful degrade in unsupported browsers (text can be shown when background images for links are not allowed)
Fewer HTTP requests
Each image has a separate overhead like color table so image slicing will be having more overhead than CSS sprites
Cons:
Poses a problem if images are turned off in the browsers (rare case though)
Image slicing:
Pros:
User perceives a faster load since loaded piece by piece.
Load on demand like when the user places his mouse on the image
Cons:
The webpages might have a large size on the client side even thought it might not be the case on the server side.
The main drawback of sprites is it makes it hard to read/maintain/modify your CSS. It can be difficult to remember the exact pixel offsets within the sprite.
pros using sprites :
since it is using 1 images for all, it require less load on http server.
cons:
- hard to code. you must know the coordinate each images inside sprites so you can display it correctly. once you change the size of the image, you need to adjust all ...
- big images could creates long waited page to display. while using images, user with slow internet connection can see one by one.
best practices.
use it for example roll over images.
Look into using a CSS sprite generator (we use SmartSprites). That way you can do slices locally, and have your build process generate a spritemap. It's the best of both worlds.
Also is SmartSprites isn't for you, there's definitely others, however I like it because it reduces the amount of work up front AND during changes.
Cons
- slower on older browsers/ maybe not working on them with hover effect (opera6)
- if not used correctly can get very/too huge (group them adequately!)
- tedious work to set them up
Pros
- less bytes transfered, because one big image is smaller then all individual images combined (one header/ color table)
- less http requests
I prefer going the middle ground of grouping similar images (normal, hover, selected page, the parent page of selected page) than having all the images in one file. To make these, you image slice like normal in Photoshop or Illustrator, open the files up and combine them with a shortcut key. I wrote the Photoshop script that combines images into CSS sprites. You will have multiple HTTP connections, but won't have the load delay on hover.