Delivered image is larger in bytes than the pristine image
On occasion, Image & Video Manager serves an image that is larger in bytes than the original pristine image. When the processed image is larger, why doesn't Image & Video Manager deliver the pristine image instead?
The answer lies in one of Image & Video Manager 's core tenants: images are served only if they are “visually correct”. In this context, visually correct means the selected breakpoint and all transformations in the policy have been applied.
Image & Video Manager cannot serve a pristine image unless:
- It’s in a format that the requesting browser recognizes
- The applicable policy does not contain image transformations
- The requested breakpoint is greater than or equal to the width of the pristine image
Transformations include operations such as resizing, facial recognition, max colors, unsharp mask, and so on that modify the visual qualities of an image. While not immediately obvious, automatic breakpoint selection (scaling for mobile) is also considered a transformation because it’s a type of resizing.
The pristine image cannot be delivered, even if it’s fewer bytes than the derivatives, because it wouldn’t be a visual match to the policy specifications. Serving the pristine image instead of one of the derivatives would also risk "breaking" your site.
To understand why a delivered image might be larger in bytes than the pristine image, consider the following example:
An image policy includes automatic breakpoint selection and image quality of 85 but the quality of the customer's pristine images is already encoded at 65. Because Image & Video Manager will be applying a higher quality number than is already encoded in the pristine images, the derivatives, even with smaller dimensions, may be larger in byte size.
If a derivative image is larger than the pristine image, one of two things will happen:
If no transformations are included in the applicable policy and the pristine image satisfies the other two conditions listed above, Image & Video Manager will serve the smaller pristine image.
If transformations are applied or the pristine image does not satisfy the other two conditions,Image & Video Manager will serve the derivative image, even if the pristine image is fewer bytes. Image & Video Manager cannot serve the pristine image, even if it's fewer bytes, because it would be visually incorrect according to the policy specifications.
To minimize the chances of Image & Video Manager delivering an image that is larger in bytes than the pristine original, keep in mind:
Resize transformations will never crop images. Aspect fill resizes an image to the smallest possible size that fills the provided dimensions while leaving no blank space. This means that the resized image may exceed the provided dimensions.
Pre-compressed pristine images can cause numerous issues. Ideally, pristine images are high quality and not compressed.
If your pristine images are in GIF format (limited to 256 indexed colors), resizing can cause more colors to be added through interpolation. When this happens, indexed color can no longer be used, and larger derivative images may be the result.
When comparing the byte size of pristine and derivative images, consider the following:
*Byte savings will be different between real-time optimized images and offline optimized images. Real-time optimization is a quick and simple transformation into a single image format. Offline optimization is more complex, leveraging the full capabilities of Image & Video Manager , which frequently results in better byte savings.
*When measuring byte savings on web pages, it's important to know whether or not the reported bytes for a particular resource include the HTTP response headers. Some tools include HTTP headers in byte size, some don't. These headers can dramatically skew results, especially if Akamai debug headers are enabled. The best way to measure image byte savings is to measure the difference in the content length and not include response headers.
Updated 3 months ago