8

What are the best practices people follow in respect to images on larger viewports?

What size browser should we design for? Meaning how do we deal with high resolution monitors and what % of users have large screens?

How can we best deal with the height of hero images, as we really need to decide which screen resolution to go with?

Of course, all of this is while keeping to the 12 column grid philosophy ;)

0

5 Answers 5

6

There are several things to keep in mind when serving images to viewers.

  1. Keep the image ratio the same as the original dimensions

We do this to prevent the image from getting skewed and to prevent images from being blurry. We can either keep the dimension ratio the same or clip off parts that don't fit.

When using an <img> element or something similar, this is fairly straight forward, it just requires using a set width or height OR set max-width or max-height.

However in the case of a full viewport width image this is a little more complex. There are several CSS ways to do it, the best of which is background-size:cover like the first linked example in the article and Talkingrock' answer show.

In addition, we now have the ability to use the features found in the responsive images specification including srcset and the <picture> element, which are quite useful. I talk about this more later on in this answer.

  1. Give viewers only the image(s) they need

In order to have a quicker page load and prevent users from needing to transfer more data, it is vitally important to serve the end user only the image(s) that they need, when they need them. This means we serve them an image the same size or just a little larger than the one the viewport they're using and waiting to load images that will not be seen immediately until after the initial page load.

We can serve a more appropriately sized image using CSS by using @media queries when we're using background images. The images not in the media query being used are not loaded. I'd recommend using at least three photo sizes (which means at least 3 media queries), but having a couple more could be heplful performance wise. The following is an example, but it should usually coincide with some general breakpoints for your site's layout.

@media (max-width: 320px) { /* For phones (this breakpoint is the one I'm least sure about) */
    ... background-image(imageURLforPhones.png); ...
}
@media (min-width:501px) and (max-width: 1024px) { /* For tablets and such */
    ... background-image(imageURLforTablets.png); ...
}
@media (min-width: 1025px) { /* For large screens */
    ... background-image(imageURLforLargeScreens.png); ...
}

But, let's face it: we're not good at choosing breakpoints nor are we perfect at choosing image dimensions given a certain screen size. Wouldn't it be great if we could let the have something do this 'magically' for us?

The great news is that now we can!

With the responsive images specification, we can let the browser decide all of this for us, provided we help it out a little. The ever so useful srcset property can be used with an <img> or a <picture> element. For resolution switching like we're doing here, we should use an <img> element.

The following is an example of the HTML needed to allow srcset to do its job. For more, you can read Yoav Weiss' great article on the subject. The example is pulled from it.

<img src="cat_500px.jpg"
     srcset="cat_750px.jpg 1.5x, cat_1000px.jpg 2x"
     width="500" alt="lolcat">

Side note: If you need to serve the same image with different dimensions at certain viewport sizes, you can using the sizes attribute.

I'm not saying that using srcset is necessarily better than using a CSS background image, I haven't done enough work with it myself to say so for sure, but it is potentially a better way.

Also, to help with performance we can "lazy load" images that won't be visible initially. This means that we prevent them from loading initially but start loading them as soon as the initial page is done loading. That way we can get the viewer to see the page as soon as possible and fill in some details later. Here's a way to do that, I won't go into much detail right now.

  1. Make sure that the content in the image you want to show is shown

If we have the correct dimensions and great performance that's awesome, but if the viewer doesn't see what we want them to see there is no point. If we are showing the image completely all of the time this is not a problem, but if we have to crop the image this can be a problem.

We can crop background-images using CSS by using background-size and background-position (and sort of using clip, but that's usually used for more artsy, complex shapes). The exact details of this will vary from image to image depending on how it is being implemented.

The second option is to use the <picture> element. We use this when we only want part of the image to show, as seen here, but here's a simple example of it in practice (pulled from Jason Grigsby's great article on this subject).

<picture>
    <source media="(min-width: 45em)" srcset="large.jpg">
    <source media="(min-width: 32em)" srcset="med.jpg">
    <img src="small.jpg" alt="The president giving an award.">
</picture>

I want to reiterate, if you only need to do resolution switching don't use the <picture> element, just use the <img> element with srcset. The only time we need the <picture> element is for this art direction, meaning clipping, etc.

There's also the possibility of doing some cropping server side, using an SVG mask, or doing some stuff with Canvas, but that's a bit outside of the scope of this answer.


Some other notes

Specific breakpoints are not that important. As with all responsive design, it's important to do the best as we can for all viewports, but there are no media queries that will be perfect for all sites.

Page load time is very important, and images can slow down the initial load time by a lot. Make sure you load images that will be immediately seen first, then others. Try to prevent images (like JPEGs) from showing part of the image while it loads the rest. Also optimize all of your images so that they are the smallest file size possible while still having the amount of quality you require.

It's important to remember that images, in most cases, should be an accessory, not a necessity. I recommend to always test how a webpage looks like without images to make sure it's usable.

Note: We can use a polyfill called Picturefill to serve older browsers that don't support the responsive images specification.

2
  • I'm not sure how lazy loading is a best practice. Consider someone who loads a page on a tablet or laptop, puts the device to sleep, boards a bus, wakes the device, and tries to read. With lazy loading, lack of Wi-Fi on the bus will cause connections to fail. Nov 7, 2014 at 23:32
  • @tepples The point of lazy loading is to load the non-visible images as soon as the page is done loading, so it'd continue to load them as soon as the initial part of the page is loaded and shown. Thank, I'll make it more clear in the answer Nov 7, 2014 at 23:46
5

Asprilla,

While above comments make very good technical points, I suggest tailoring your work to particular client, which starts by looking at their current site's Google Analytics - Reporting / Technology / Browser & OS / Screen Resolution. This way, you will be spending your time and your client's budget wisely by addressing your client's specific needs as opposed to implementing general guidelines. We actually had to advise our clients on occasion against doing fully responsive design simply because their non-desktop traffic would not justify the expense.

4
  • 1
    While this may be true in rare cases, it is by far not the norm Nov 9, 2014 at 14:39
  • 1
    What is "not the norm" - tailoring your work to your client's needs, which is the point of my post? Asprilla asked "what % of users have large screens" and I was stressing that her design should be based on actual user data specific to her client, rather than generic best practices and tricks that can be done with CSS.
    – Max Tokman
    Nov 9, 2014 at 14:57
  • 3
    I was referencing the last part regarding "their non-desktop traffic would not justify [a fully responsive design]" Nov 9, 2014 at 15:36
  • I'm a him :0 & this fella' is really appreciating all the great feedback, thanks - love this community's willingness to share the knowledge ;-)
    – Asprilla
    Nov 10, 2014 at 16:12
5

Guidelines for choosing the dimensions of your full width browser image

I've learnt these through research throughout the last year, and experimentation over the last few days for this specific use case.

  • Choose an image with a single focal point, or no focal point at all.

  • Your source image file will need to be huge (minimum 5000 x 5000) if you want to serve many resolution dependent images.

  • For the portrait version, you should use an aspect ratio of 9w:16h.

  • For the landscape version, you should use an aspect ratio of 4w:3h.

  • Within both images, there is a content safe area where you can guarantee that a part of the image will be seen, or is above-the-fold as they say in Klingon.

  • The content safe areas for both images, based on these five aspect ratios: 3:2, 4:3, 5:3, 16:10 & 16:9, is roughly the top three quarters of both images.

    content safe areas on example images

  • srcset is the Holy Grail of implementing responsive images. <picture> will probably be even better in future, but srcset is king for now. Check Zach Saucier's answer for more info on this.

Here is an example that I've created after extensive experimentation.

These images should cover almost any screen. Resize the preview panel to see the different images. The fallback should be to one of the mid-range images, but I linked to the page where I sourced the image instead as a sort of minor attribution.

I've tried to keep this answer brief (rewritten 3 times), even though I can provide the justifications for my assertions, I haven't because it would bloat this answer a lot. I'm hoping you can infer the justifications from the image above, and see the evidence from my example jsFiddle.

On a 4:3 screen:

enter image description here

On a super-wide screen:

enter image description here

On a portrait mobile:

mobile example

3

Here is some additional information you may find useful.

Screen Size Statistics

Popular screen sizes vary, so here are some statistic sites that list screen size usage by percent, browser trends, operating systems and more.

  1. http://www.w3schools.com/browsers/browsers_display.asp
  2. http://www.netmarketshare.com/

Hero and Large Images

A great, easy CSS solution exists for Hero and other large images. It is background-size:cover. It is useful because it covers the entire div without distorting the image at different screen sizes, or if the parent div changes shape (more/less text...). It works by clipping bits of the image to maintain proper proportions, and you can also position the background so the important parts will always show (center center, right bottom...).

Another advantage is that it displays the image as a background, so text and other information can be easily added to the div. It also works as a full-sized background. Here's a JSFiddle example to play with that uses background-size:cover as a full-screen background, and another that uses a Hero div. Resize the JSFiddle window, and edit the CSS positioning to see it work.

background-image:url(http://i.imgur.com/OaE8VAj.jpg);
background-repeat:no-repeat;
background-position:bottom right;
background-size:cover;
-webkit-background-size:cover;
-moz-background-size:cover;
-o-background-size:cover;

Browser Support for Background-size (CanIUse.com) is very good, and here is a fix for IE7 and IE8.


One popular solution to all the varying device display sizes (desktop/tablet/handheld) is to create a Responsive site that repositions itself to fit the various screen sizes from big-screen TV, to handheld. If you are interested in this, here is a good intermediate level tutorial: http://www.elated.com/articles/responsive-web-design-demystified/.

Responsive designs work with grid layouts, and if the site is pixel based, there is a formula that converts pixel sizes to the percent equivalent. A quick search using the terms "responsive 12 column grid" and "responsive column grid calculator" turned up lots of useful resources like Responsive 12-column wireframes, calculators and more. Here's an example:http://onepcssgrid.mattimling.com/

1

The short version

Try to design for compatibility with the smallest viewport resolution:

Desktops: 800x600 / 1024x768 (in pixels)

older mobile phones: 320x480 (in pixels)

tablets: 800x1280 (in pixels)

By picking the lowest resolution, you ensure that the design will work for people with smaller resolutions as well as larger resolutions.

The long version

It sounds to me like you are both interested in the viewports for different devices rather than browser size.

The browser is the complete window which is used for visual web browsing. This area includes the navigation url input, tabs, & toolbars.

The viewport is the area of the browser which shows a rendered website. This is usually below toolbars and url. This is the area which designers are typically more interested in.

As for deciding on your screen resolution, you first need to ask yourself this: what will it primarily be viewed on? If it is for internal use in a company, we can guess it will most likely be used on a laptop or desktop. If it meant to be used on-the-go, we can guess it will primarily be used on mobile devices.

The current trend for web design is "Mobile First". This is where a website is designed for mobile before being made responsive for other platforms. This is because more and more people are using mobile devices for internet access rather than desktops or laptops.

You may find Viewport Sizes very helpful for learning about viewport dimensions. This site gives the viewport for many mobile devices and a few desktops. It should allow you to explore the variety of viewport sizes.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.