I'm trying to make my images optimized for google pagespeed test. I have an image with 1200x393 dimensions. When I optimize the image with Photoshop, its size is approximately 250kb and with Corel it becomes 100kb. Google doesn't accept either. It says Compressing and resizing ... .jpg could save 92.6KiB (90% reduction).
How can I pass pagespeed test?
From Image Optimization:
Image optimization boils down to two criteria: optimizing the number
of bytes used to encode each image pixel, and optimizing the total
number of pixels: the filesize of the image is simply the total number
of pixels times the number of bytes used to encode each pixel. Nothing
more, nothing less.
As a result, one of the simplest and most
effective image optimization techniques is to ensure that we are not
shipping any more pixels than needed to display the asset at its
intended size in the browser. Sounds simple, right? Unfortunately,
most pages fail this test for many of their image assets: typically,
they ship larger assets and rely on the browser to rescale them -
which also consumes extra CPU resources - and display them at a lower
resolution. ...
you should ensure that the number of unnecessary
pixels is minimal, and that your large assets in particular are
delivered as close as possible to their display size
Common error is to have big image in source and scale it down with width and height attributes on UI.
For an image intensive size like 500px, flickr, instagram etc which serve lots of images with different sizes and users constantly upload images whats the best way to store and display different size images.
Same image is usually displayed in different sizes, like thumbnail, modal window size and big size etc (like on ecommerce sites).
Also for dynamic size grids like http://500px.com/flow where images are all dynamic sizes spanning multiple rows and columns.
Do these sites create all these different sizes and store different version of site or its done on the fly?
Usually, these sites create a few versions of the image when they are uploaded. Common examples are small (thumbnail), medium, large, full-size. These transformations are done at upload-time, as there is a large performance penalty of resizing so many images on the fly.
I have a page with many large fluid images. http://altarjewelry.com/gallery
I want to get a smooth 60fps webapp feel while scrolling. The Chrome DevTools tell me my paint times are the biggest problem (which you can check for yourself while scrolling). I'm assuming this is due to my many large fluid images.
I've read every article on HTML5Rocks about performance. I found many good tips on JS performance but no help optimizing large image paint times other then using small fixed size images, which is not an option for me as I'm building a responsive site.
I'm already serving up responsive images depending on the client.
Thank you for your help.
Not really sure about how your gallery looks because it never loaded from the URL in your post, and I don't know if that's a javascript issue or what--but I'll take a stab at helping you come up with a solution. Image optimization is image optimization, regardless of whether or not you're building a responsive site.
Approach and Design Considerations
Do you really need one large, high resolution image for each item, at the same DPI/PPI and compression, that should be responsive?
Or, should you serve appropriately sized images at differing DPI/PPI and compression, to different displays, all of which are still used in a responsive application?
Popular Convention
You're showing a gallery, and typically, you want smaller representations of the actual image--thumbnails or placeholders, generally of lower resolution, which link to the actual image at a higher resolution. This is an accepted design approach, and if you're going to vary from it, be sure it's with good reason.
The Lowest Common Denominator
If you're building a responsive site, some users will obviously be on mobile devices which may have resolutions as small as 320 pixels wide. Consider things like that, and this: even if someone shows up on a desktop, are you going to have huge, full width images loading? They will take forever to load, and visitors will never see your gallery. How is your gallery to look on a wide screen desktop? If your intention is to have one image full width across the entire page, and load the same image regardless of the device accessing your site, you may be using responsive design, but you'll find that's far away from best or even good practice.
The Flip-Side, Large/Wide Screens
Why not have four gallery images going across a desktop? Or more? And if that's the case, they're likely to have a maximum size in any case. I honestly don't know because I've tried to load your site a few times and get nothing. But consider that if there's a maximum size practically for your gallery images in an initial display, say 6 images at 200 pixels each across a 1200 pixel max layout width (Or, are you using a % based framework and using 100% of the display width? Even responsive sites often limit the max width of the content area, and these things all would help determining a more appropriate answer) solutions begin to emerge.
Since no image needs to be larger than 200 pixels in that case, and on a phone where your columns might be displaying only one image that you want full width, you can work with a maximum initial width of 480px wide images.
Higher Quality, Smaller Files
We'll assume you want them high quality. That's fine. You still need to reduce files size, and you do that with compression. Now, you may feel compressing a photo to 50% or even more makes it blurry, and it certainly will at low ppi (pixels per inch) settings.
The Secret To Better Compression
What you need to do is change default image editor settings from traditional defaults like 72 or 90 ppi, and crank them up to 300, 400, 500, or more--and THEN apply compression. If that image is 480px wide, and you've only got 72ppi, compression will quickly erode quality. However, having several hundred extra pixels per inch will allow more information to be stored. Then, you can apply much higher compression rates, and shrink file sizes down quite a bit more.
The Oversized Image Approach
Another trick is to do the same thing, and slightly oversize the image. If 480px is the max size for your thumbnails/small pics, make them actually 540-600 px wide, with 400-500ppi and compress them at really high settings. The browser will resize to the max width of 480 px...but then you have a performance hit there. Everything is a trade off. You can blur backgrounds in images as well, allowing the foreground/main focus of the photo to be of higher quality while the background requires less information, yielding smaller file sizes.
Not Suitable For Batch Processing
This should be done individually for each image, batch editing does not generally get the most out of this technique, because the color information is so different in each photo. One photo might be best quality and smallest size for your purposes at 300ppi and 50% quality, another at 500ppi and 35% quality. You'll want to do this not just for your gallery thumbnails, but multiple images. No point in serving up a 1400px wide full size desktop to someone who's browsing your site with 480px wide/resolution display after all. Use media queries to serve up the appropriate ballpark sized image, and have a small, medium and large variant. Done right, you don't even need to be serving larger images to those browsing with phones...the gallery images they are viewing are good enough.
The compression setting is not so heavily determinate of the final image quality as the number of pixels you have to compress goes up. More pixels to work with, the better quality at higher compression settings.
Design Considerations and Smart Image Loading
Break It Up Into Smaller Content Chunks
Also, consider the process/design of your gallery. Do you have 20 items? 100? 400? Are you trying to show them all on one page? Break it up into small numbers...12-20 per page. Smaller and fewer images will load faster, and can remain responsive, with links for those who want a larger or higher quality image. No need to show a huge, high quality image to someone browsing with their phone.
Pre-fetching and Loading
Server side scripting, and even some javascript solutions can help with this. You might do things like limiting each gallery page to four rows of four images, and then after page load, have a javascript that pre-fetches the first four images that will display on page 2. If your visitor goes to page two after scrolling through page one, the first four images are loaded in cache, and display quickly while the others load normally, giving the experience of a faster page load.
If the visitor goes to another page in the site, you didn't waste bandwidth on 12 images and only cost you the bandwidth of four. Smart design might be to use those first four images on page two of the gallery elsewhere on the site...so that first gallery page visit actually sped up page load elsewhere and does not in fact give up bandwidth for loading 4 unnecessary images. Think the process through, and solutions will suggest themselves.
Resources
Anyway, here are relevant articles/posts/links you may find helpful in understanding all of this:
Are Compressive Images A Good Solution For High Resolution Displays?
http://www.vanseodesign.com/web-design/compressive-image-tests/
Reducing image sizes (ResponsiveDesign.is)
https://responsivedesign.is/articles/reducing-image-sizes
Search benfrain dot com for this post:
How to serve high-resolution website images for retina displays
And a tool you might find useful...
adaptive-images dot com
I recently noticed that every image on this website - the logo, badge colors, up/down voting arrows — the list goes on - are actually part of a single sprite sheet, set as a background image, and repositioned based on the required state. What is the advantage of using this method over using multiple images?
Simple. You're sending less HTTP requests. One for all images, as opposed to one for each image.
Additionally, a large compressed sprite including all images can be compressed better, resulting in a smaller filesize than all the images on their own. E.g. if you have 10 files that are 20kB in size each, the sprite would normally be much less than 200kB.
With a sprite, the browser only has to make one HTTP request for the whole image, instead of N requests for N images. There is significant overhead and delay to creating the TCP connection (three-way handshake), so limiting this to just one request saves a lot of time.
I'm using fancybox.js to load my images. The smaller version of the images load very quickly, however, the large images (the ones that pop out in a modal) take anywhere from 4 to 10 seconds to load. My images are in the jpeg format, but I doubt that that's the problem. I'm hosting on Heroku -- could this be the culprit?
I would guess from what you are saying that the filesize of the images that you are seeing is quite large. Remember that Fancybox resizes images to suit the viewport of the browser.
A really silly mistake as I needed to resize my images.
I didn't think of this simple solution earlier because of deception. All the images loaded up by fancybox are resized to fit the window, which I then thought were the original size of the photos. Turns out that the images were at least 4 times the size of what is shown.