Image optimization use cases

This page provides examples for advanced image processing behavior, pipeline ordering effects, and automatic image normalization rules.

Order of transformations

Operations in the imop query parameter string run sequentially from left to right with an exception of metadata or scale running first and canvas running last. Because every operation acts directly on the visual output of the preceding operation, the sequence of your parameters affects the final visual quality and detail preservation of the derivative image.

Consider a source image that is 1,000 pixels wide by 1,000 pixels high:

Example: Resize followed by Crop

https://www.example.com/image.jpg?imop=Resize,height=200;Crop,left=0.5

  1. Resize: The image is first scaled down from 1,000 × 1,000 px to 200 × 200 px to meet the height=200 parameter.

  2. Crop: the left=0.5 operation removes the left half of the already-downscaled image.

Result: A 100 x 200 px final image representing the right 50% of the content. Because the entire image was downscaled before cropping, the final region retains significantly less detail.

Example : Crop followed by Resize

https://www.example.com/image.jpg?imop=Crop,left=0.5;Resize,height=200

  1. Crop: The left=0.5operation extracts the right 50% of the high-resolution source image first, creating a 500 x 1000 px intermediate image.

  2. Resize: The height=200 operation resizes that cropped section down to its final height.

Result: A 100 * 200 px final image. Because the original image was cropped first and resized later, the final output retains much greater detail and clarity.

Stretch and upscaling behavior

By default, the image optimization service enforces a strict, downscale-only strategy to conserve edge delivery bandwidth and protect visual quality. If you request dimensions larger than the original image, Cloud CDN ignores the enlargement and outputs the image at its original size.

To override this behavior and force an asset to upscale, you must explicitly declare the stretch value.

Validation requirements for upscaling

  • Dual sizing rule: the stretch value is permitted only if you explicitly provide both the width and height parameters in the Resize operation

  • Single dimension constraint: If you include scaling=stretch while defining only a single dimension, such as width or height, image optimization service rejects the entire request.

For example,

Valid request: ?imop=resize,width=500,height=500,scaling=stretch

Invalid request: ?imop=resize,width=500, scaling=stretch

Caching and cache invalidation

When you update an original image on your origin server, you must invalidate the cached version to ensure Cloud CDN retrieves and serves the updated asset.

Caching behavior

Every unique combination of transformation parameters appended to an image URL creates a separate, distinct cache entry at the edge. To optimize your cache-hit ratio, avoid creating excessive numbers of unique parameter variations. For example, single-pixel changes.

Cloud CDN normalizes cache keys to group identical transformation parameters regardless of their order in the query string.

Invalidation behavior

When you update an original image on your origin server, you only need to submit a single invalidation request for the base image URL. The enhanced Cloud CDN automatically purges both the cached original image and all of its automatically generated variants (such as WebP or optimized versions) globally.

How Variant Invalidation Works

When you issue a cache invalidation request using a path pattern that matches a base image URL, for example,/images/my-picture.jpg, Cloud CDN automatically identifies and purges:

  • The original cached source image.

  • All of its previously generated variants

You can apply Cloud CDN cache invalidation using:

  • Google Google Cloud console: navigate to Network Services > Cloud CDN, select the origin, and go to the Cache Invalidation tab. Alternatively, go to Network Services > Load Balancing, select your load balancer, and use the Cache Invalidation tab.

  • Google Cloud CLI: use the Google Cloud CLI compute url-maps invalidate-cdn-cache command.

  • Cache Tags : Cache tags is the recommended approach for managing optimized images. This lets you issue invalidation requests targeting a specific tag, which purges the content associated with it for more granular control.

For example:

To invalidate /images/my-picture.jpg and all of its optimized variants globally:

  • Path: specify the exact path /images/my-picture.jpg.

  • Host (Optional): specify the host if you only want to clear the image for a specific domain.

When submitted, this single action removes all optimized versions of the image from edge caches globally, ensuring users immediately receive the updated version on their next request.

Color profile and image orientation in EXIF (normalization)

Modern smartphones and digital cameras frequently save images with raw, unrotated pixel grids and rely on an embedded EXIF orientation tag to to instruct the viewing device to rotate the image. For example, 90 degrees clockwise for portrait orientation. Similarly, embedded ICC color profiles define how colors display across different monitors.

To help ensure predictable operations, the image optimization edge pipeline automatically normalizes images before running any transformations.

Normalization process

  • Prior to executing transformations, the edge engine reads EXIF orientation tags and ICC color profile metadata and physically applies them to the pixel grid. This helps ensure coordinate predictability for subsequent crop and resize parameters.

  • Operations, such as crop, resize or scale execute correctly against the true visual dimensions to prevent visual errors.

  • After applying adjustments to the core pixels, the edge engine removes all non-essential metadata from the file to maximize size savings. By default, it retains copyright unless a specific value is requested in metadata operation.

What's next