You can still keep metadata on transformation by using the keep_iptc flag.

If a transformation (cropping, scaling, etc) is applied when fetching the image, image metadata gets stripped. Why send them to the browser then? When images are uploaded to Cloudinary, they are kept as-is. One of the things that add to the overall image size is metadata. In this case, we scale ( c_scale) the image but Cloudinary also provides support to fill, fit, crop, thumbnail and more with our images. It’s easier to specify even more sources and sizes using this combination. We can specify the width and height on the fly like so: After uploading the image to Cloudinary, the link is: We can upload our image to Cloudinary and resize it on the fly using adding width ( w_) and height ( h_) transformations. Using the solution above, we would have to create multiple sized images for every image which can be a chore. Older browsers that don’t support these attributes will ignore them and use the src attribute. The second item, in this case, doesn’t have a media condition so it defaults to anything above 600px. Sizes contain a media condition (max-width: 600px) and an intended display size (400px) of the image. Tells the browser the path of the image (images/demo-400.jpeg), followed by a space and then the intrinsic width of the image. In the example above, srcset=”images/demo-400.jpeg 400w” Srcset allows you to define a set of images the browser can choose between and the intrinsic width of each image. One way to improve this is by using srcset and sizes attributes. Not only are we sending down unnecessary bytes to the user, but the browser is also forced to use more CPU resources than required which takes a hit on performance.

picture showing intrinsic size vs scaled sizeĪs can be seen from the picture above, the intrinsic size (actual size) of the image is 1050×700 pixels but setting the width to 400 pixels has forced the browser to rescale the image the fit the specified size. Most times we end up sending down more pixels than the browser needs to display. One technique that can be used to optimize your images is to serve an appropriately sized image. It covers techniques on lazy loading, error handling, and graceful fallback mechanisms when all fails.

In a previous article, I covered this technique extensively. Lazy loading is a technique that involves loading images only when they are needed i.e. You can check the official guide to see what’s possible. We can use the f_auto and Cloudinary will automatically determine a suitable format to send to the browser-based on the browser’s capabilities. But we may want to take advantage of newer image formats like WebP while making sure older browsers can still get a suitable format. Say I want to send a png image, I can use it like so: Įven though the original image is a JPEG, the image delivered to the browser is in PNG format. You can take advantage of Cloudinary’s fetch ( f_) transformation to choose a specify the format you want. This makes it challenging choosing which format to send to the browser. There are also newer formats like WebP, JPEG-XR, with better encoding but are only supported in newer browsers. Raster images for complex scenes (photos).Vector images for simple shapes (logos, icons, texts).Each of these formats has it’s strengths and weaknesses. There are various image formats: SVG, PNG, JPG being some of the popular formats. Once uploaded, you can hover on the image or video to get the URL and use in your web application.

Cloudinary optimize images