Skip to content

Latest commit

 

History

History
89 lines (56 loc) · 7.93 KB

images.md

File metadata and controls

89 lines (56 loc) · 7.93 KB

Images

This document describes best practices for the use of images on the web at Springer Nature.

Introduction

In a frontend workflow we typically deal with two different categories of images:

  • User interface images. These include icons, logos, buttons, and any other image that is part of the user. Usually managed by the frontend, these are stored with other client-side resources such as templates, CSS and JS. Like those resources, they may be shared between many different pages.

  • Content images. These are unique to a page, or a handful of pages. They will usually be provided from a database or a content management system.

Most best practices described in this document apply to both categories unless otherwise indicated.

Picking the right image format

  • Use SVG for icons, logos, and other images with sharply defined edges.
  • Use JPEG for still images, photographs, and in any other cases where using a PNG would result in an image too large to be delivered over the network effectively.
  • Use PNG for illustrations, graphs, flat-colour graphics, images containing transparency (which JPEG doesn't support), and images containing text.
  • Use MP4 for any kind of animated images.
  • Do not use GIFs. The file size of animated GIF images is usually an order of magnitude bigger than MP4s of similar quality. They can be a barrier that prevents users from accessing our content, especially in markets where slower connections and low performing devices are more common. For static images with transparency, an 8-bit PNG can be used to deliver an indexed colour image, with binary transparency, at a smaller size than a GIF.

A number of more modern image formats can also be used to deliver images:

Image formats

SVG images

Always minify your SVGs using SVGO or a similar tool.

JPEG images

When encoding JPEG images:

  • Use progressive encoding. Progressive JPEGs provide a better user experience and, most of the time, are smaller than baseline. See this yeoman issue for further details.
  • Use 4:2:0 chroma subsampling whenever possible. This encodes the colour information at half the resolution of the luma, which may result in a perceptible loss of colour accuracy. This will usually generate much smaller images, so we suggest to create both of them and compare them for any loss of quality. For tools that can help you with this, see: Comparing the quality of images, below.
  • Use encoders like Mozilla's mozjpeg that can create images with the same visual quality as other encoders but a much smaller file size.

PNG images

Always use the maximum compression level (9).

Optimisation of images

Images can contribute significantly to a page's size, so it's important to optimise them before they are delivered to the user. This helps ensure that our sites stay performant and we're not preventing anyone from accessing them due to increased page weight. Common optimisations include:

  • Making sure that you save images using an sRGB ICC profile. Although modern browsers support images with ICCv2 profiles like Adobe RGB and even ProPhoto RGB, colour space issues are extremely difficult to debug. Saving the images as sRGB and removing the colour profile is encouraged.
  • Stripping the metadata from the image. This includes things like EXIF data, Copyright information (unless required), GPS data, colour profiles, thumbnails (in JPEGs), comments, and others.
  • Setting appropriate cache headers for the images. (See Serving images, below.)

For images that are going to be included in a repository, tools like ImageOptim can be used to optimise them and strip the metadata before committing them to your codebase. There's also an ImageOptim-CLI that can be integrated with CI systems.

If an image is still too big after following all these optimisations, other options can be used that will require editing the image. These can be used to generate images with a much smaller size than otherwise would be possible:

  • Reducing noise or eliminating noise and other complexity from the image, which makes it easier to compress.
  • Blurring unimportant areas will also make the image easier to compress.
  • Finally, decreasing the export quality may be required if the image is still too big.

Serving images

We work under the assumption that images are encoded only once but decoded many times. Therefore, increased encoding times, while undesirable, are usually secondary to other concerns like making the image easier to decompress, or having a smaller file size.

When optimising non-content images that are going to be committed to a repo, make sure you always use the maximum settings if you're using lossless optimisations.

For content images, we encourage using an on-premise or cloud-based image server in order to:

  • Ensure that all images are optimised automatically.
  • Ensure that the appropriate cache headers are always set.

Additionally, future improvements to these tools will result in improvements to the images being served automatically, without the images having to be manually re-encoded.

Comparing the quality of images

When comparing the output of two different image compression formats, algorithms, or quality settings, tools that calculate the similarity between images with algorithms like SSIM and DSSIM can be used to get an objective idea of the trade-off between quality and byte size.