I'm looking for good articles around image resolutions, size and quality for web pages, especially around how this affects web sites currently.
I'm working on a web site for a client, and as an honour graduate in arts and design, the client is persistent that her 7mb - 10mb images are sufficient for her web site, totalling in at almost 400mb. I've tried arguing bandwidth limitations and performance but these are not holding ground.
The standard for images are at 72dpi, no larger than your standard screen resolution (1024x768) and above 1mb in size (which is already too large in my opinion). my argument is that loading 7mb+ files into a gallery on page load will seriously hinder the users experience if they have to wait a long period of time for 7 - 10 images to first get streamed into cache before the page is loaded, and even testing this with lazy loading plug-ins (we don't want to go flash) and late-loading has performance penalties.
Does anyone on here have any recommendation around image size, resolution and quality? We don't want to loose the HD quality of the images when users navigate the gallery (obviously we'll have to thumbnail them first)?
i have read guidelines before (when we still used 1Mbps connections or less) and have been following these until now:
high resolution images should not be bigger than 1.5 - 2MB. making it this big is like bigger than the webpage contents itself. try checking http://deviantart.com on how they place big photos in their site and check the image properties using the EXIF if any
dimensions should be enough to be viewable in the browser (and avoid scrolling)
compression is to be tested. it's a case to case basis, no setting is the same for everyone. high quality, high compression without visible quality loss is a practice in web design.
JPEG is best for images, PNG for the layout and GIF for icons.
try loading images in the background when the browser is idle using javascript. that way, they are in the cache before the user knows it.
more on the webpage design, avoid using heavy graphics on the site itself, making the site fast so we only wait for the image.
If you really boil it down you don't have a choice.
You are talking about HUGE file sizes which are not realistic.
You need to download a smaller version. After that you can subsequently download versions with increased quality or offer the full image with an onmouseover or click.
Some general guidelines:
Thumbnails (of course)
Offer multiple image sizes (small, medium, large). While I understand the UX implications of giant images, some people do have fast connections and large displays and/or will be willing to wait for a high-resolution version. But it shouldn't be the only option.
Try different compression levels to see what works best for different sizes. Using one compression level across the board doesn't always work. Again (depending on the source material), there may be a need for near-lossless compression at the high end. For example, images for print, CAD drawings with fine detail, etc.
Use sequential loading techniques if applicable. For example, if you have ten images to load (optimized or not), make sure that the first visible one is the first one actually requested from the server.
When it comes down to it, your client is under the impression that asking to shrink her image represents a 'compromise' that only results in damaging the quality of the image the user receives.
The truth is, of course, that an 8-10MB image is so large that it would take most users many seconds to download, creating a horrible user experience that will increase bounce rates.
Show your client a side-by-side demo of her website loading a handful of web-optimized images, and show her a site loading 8-10MB images, then let her decide. Ultimately, your job as professional is to assist her in making good choices, but she's free to make bad ones if she insists upon it (it's her brand, money, and right).
Something else you can potentially do is detect the size of the window and load larger images if the user is on an ultra-high-resolution monitor or if the window appears to be especially large.
Best of luck!
Related
I want to have a website page load images faster or where the images don't stop the user from seeing the text on the pages before the images finish loading.
1. if I have text on a website page. Does the text render first so the user can see text while the images are still loading?
2. If i have 3 mb of images and have my server that is hosting the website render 1.5 and then move the other 1.5mb to something like flickr and have the image source point to flickr, will that be better and load faster. Or say I just have all the images pull from flickr?
Please help me.
Its a WordPress site, and Clouldflare free cdn does something weird to my theme. So not an option. I also don't want to lazy load for other reason.
EDIT : o yea, if I host all the images on Flickr does that give away link juice (Domain Authority Rank)?
Images do increase overall load time, but they aren't render blocking. The whole page will render (barring render-blocking CSS or Scripts) and images will pop in when they are done. If you want to avoid that flash, you can lazy-load them, or otherwise put the final image's sizes on a container element, so the text is already "moved".
You can't really "Speed Up" image loads. The best thing to do is cut down on the number of images, if applicable, and lazy-load any that don't need to be requested initially. The next best thing (and arguably more important overall, I suppose) is to optimize your images. There are a handful of WordPress plugins that will do this for you, or you can do it in PhotoShop - and even some image CDN's will do it. This basically means, don't load a 1MB image if you don't have to, for "web display" purposes, you can serve a 200kb image that looks almost as good.
A side point, you can "speed them up" a little by having them served from a faster server, but that goes for anything web related. Throw it on better hardware to get better performance (for the most part).
If they are large images, you should first and foremost, optimize them. Make sure they are the smallest file size possible. Also, don't bother splitting "1.5mb" of them over to another host. Either upload them directly all through a CDN (some even tie into your WP Library, like Cloudinary), or keep them local to your site. You'll save yourself some headaches later.
If you have a photo heavy website (photography or other types of galleries), 3mb isn't really an awful lot - but again it's best to serve a more compressed image, you can even link the image or a button to the "full resolution" one.
I am interested in adding a landsacpe footer on my website but the image size is 115KB and will load on every page... Is there any effective way to load an huge image such as this one:
http://gyazo.com/5b1b7312ec4370873368df0181e41b13.png
Here's a few things that may help you:
EDIT: I tried the second tip in the list below (tinypng.com) and it reduced the size of your image with 71% to 39.1 KB. So that's a big win.
Make sure to set the cache headers on your webserver so that the browser can cache the file. Also use the same URL for all other times you use the image. Doing these two simple things will make sure that the image will only get downloaded the first time the browser requests it. All other times it will be loaded from the browser's cache.
Make sure to check if the image is as small as it can be. If you use a PNG then use tools like https://tinypng.com/ to squash all metadata out of the image. If you use a JPEG then maybe lower its quality. If you use Photoshop make sure to "save the image for web". This will also reduce the size. For photographs you are mostly better of using JPEGs, for text or other images that need to be lossless use PNG or GIF.
Loading images will not really slow down your page that much. Not like JavaScript anyway. Loading Javascript will block the rendering of the page until the JS file is downloaded unless you use special loading techniques. That is not the case for images: the page will continue being rendered and the user can start using the page.
If the image is placed using an IMG tag the make sure to set the width and the height of the image in the CSS (or using the img width and height attributes). That will make sure that the browser does not need to reflow the page when the image is downloaded. It will know what size it needs to be even before the image is downloaded.
There is a maximum number of parallel requests per domain that the browser will do. If the image has a very low priority you could postpone its loading and wait for the onLoad event. This will make sure the other resources (with a a higher prio) will be downloaded first. This will require some JavaScript, but not that much (Use an image lazy loader, there are many).
As I said in the previous item the are a maximum number of requests PER DOMAIN. This is why you could also create a new (sub)domain and load some content from there. It will increase the total number of resources that will be downloaded in parallel. using a CDN will also help here because they also have a separate domain (and they are optimised as well).
If you want to read some REALLY GOOD books about this kind of optimising, read these:
http://www.amazon.com/High-Performance-Web-Sites-Essential/dp/0596529309
http://www.amazon.com/Even-Faster-Web-Sites-Performance/dp/0596522304
I have a huge image that is going to be uploaded to my server. The width and height are for example: 2000x2000. I have multiple places in my code where I need the image to be 1000x1000, 250 x 110 or like 100 x 50. When they upload the image, should I make ASP automatically re size to these dimensions and save them on my webserver like image-250x110, image-1000x1000, image-original, and image-100x50 or is it fine to just to get the original image and re size on the fly through the code then show it to the users. I'm asking this because I'm worried that if too many people go on your website, re sizing the original huge image all the time would take alot of processing power and slow down the app. Or would something like this would be fine: http://www.hanselman.com/blog/NuGetPackageOfWeek11ImageResizerEnablesCleanClearImageResizingInASPNET.aspx
Your certainly want to resize the image when its uploaded since resizing a huge image of 2000 by 2000 pixels can easily take 2 seconds, even on a fast server. That's a delay your users are unlikely to appreciate.
What you posted, ImageResizer, is going to be your best solution, for many reasons, including:
There are a lot of potential problems when writing your own resizer, as detailed in 20 Image Resizing Pitfalls, including performance and stability issues.
If you redesign your site and want to change those image dimensions... it will be painful.
With ImageResizer, you only have one image - the nice big original image. All subsequent versions are served up (and cached) via the URL call. Note that the cacheable-version of ImageResizer requires a license.
ImageResizer will likely do a better job resizing images than yours will, both in quality and in file size, and also comes with filters, watermarking, and other features.
Resizing on the fly is a really bad option as it will eat up CPU.
If you can't pay for the cacheable version, you CAN use ImageResizer to resize the images on upload and save off the 3 versions or so of the images that you want.
I've used both methods -- written my own and used ImageResizer... ImageResizer is the way to go in my opinion.
Is there any benefit to use Progressive image display, these days, for JPG, Gif and PNG?
Should we use progressive image in both condition as a <img> and in css background?
Does all mainstream desktop and mobile browsers support progressive display?
mobiles doesn't have much speed? so is it really usefful for mibile phone
Progressive display is useful where there is a slow data link. It allows the person viewing the image to get an idea of what it contains with only a little bit of it transmitted. They might choose to abort transmission if it isn't of interest.
I don't know of any important browsers which don't support progressive display.
It's useful for people on dialup, otherwise I don't think it matters.
Yes, they support it.
Immediate, progressive image display
Lossless image transfer possible
Full true color (no dithering reducing image quality)
No blocking and no color falsity on highly compressed images
Progressive display. Gives quickly a good preview for huge depth 3D images or with slow connection.
All the browsers do support this.
1) Of course - If you are interested in every millisecond that counts in page speed optimization.
The biggest advantage of using progressive browser display images is that the user can view a low quality version of the image very quickly, with gradual improvement as one waits longer. This way, the user will have access faster to the existing information, review images without waiting for the complete download of resources and focus on what he is interested on.
More info here: http://wpy.me/blog/12-progressive-browser-display-images
2) Yes you shouldn't worry about that https://en.wikipedia.org/wiki/Comparison_of_layout_engines_%28graphics%29#JPEG_support
I need to create a site that is very graphics-heavy (torn paper backgrounds with transparent shadows over textured graphics, etc.) One way that I was thinking of saving on file size was to drop all my background elements into one PNG. The issue is that this file is now 180k. If I break it up into various GIFs and a couple PNGs then it would be closer to 70k.
Does it really matter? What is "too large" these days for file size? Will anyone notice if the file is 180 or 70k?
If your users have fast access to your site (like, in an intranet), 180k is hardly a problem. If, on the other hand, the site is used by The Generic Older Person With A Humorously Slow Connection, it's probably going to be a problem. If your users use GPRS, but have endless patience, it's probably not going to be a problem. If the site gives out a million dollar to whoever has the patience to wait out the load time, transfer speeds are not an issue. And so on.
What I'm saying, it really depends on your requirements and constrains. This requires you to know (and subsequently tell us, for us to be more helpful) many things before you can get it close to right.
To avoid those pesky downvotes for very-valid-answers-but-simply-doesn't-please-someone, here's my answer:
180k divided by a standard ADSL modem transfer rate = 180kB / 100kB/s = 1.8s = endurable.
Is there a reason not to use the smaller images? It sounds like you've already broken it up, so why not go with the smaller, faster method?
From a pure relativistic point of view, 70k will take only 38% of the download time that 180k would (approximately). If you're expecting high traffic or want fast load times, every bit helps.
You have to compare the time it takes to request all the separate images and the time it takes to download the one large one. The issue is with HTTP requests.
I suggest you run some tests with Google's Firefox extension, Pagespeed to see if there is a huge difference between the large png or the separate ones.
One benefit I can think of, besides fewer HTTP requests is that your site will load all at once instead of gradually as all the graphics are downloaded. The bottom line however, as Henrik said is that it depends on your requirements.
I'm sure you're aware that splitting into multiple images means additional connections to the server to retrieve them, with associated lag on each, and the additional size of the request and response headers.
Since browsers restrict the number of active connections to each server (browser version dependent) this may end up taking longer than retrieving a single image. The usual workaround to lift the limit is to use a separate "images" server, or a DNS alias that maps to the same host.
And unless you require animation, I'd always recommend PNG over GIF.
Make sure that the site looks fine with images disabled first (so alt tags, width and heights set, correct colours used) and then split the images based up into groups. Group all of your buttons into one image if possible (using css sprite sheets), and all of the borders into another. Keep large images in separate files (so site background, headers).
The more images you have, the more the browser can parallelize the requests. However, if you split them up too much then different images will load at different times, making parts of the site pop in. It's a bit of a trade off, but that's the joy of programming :)
The better your site looks before the images are visible, the less the user will mind the speed of downloading the images.