Skip to content
Arc XP
Product Documentation

Image Resizer v2 FAQ

What happens if an image fails to transform using Resizer v2?

In Resizer v1, if an image fails to transform, the system displays no image. In the rare circumstance that an image fails to transform, Resizer v2 falls back to the original-sized image. Having an image appear for your readers is better than no image at all. However, if failover happens, this impacts your bandwidth.

Is there a bandwidth impact from migrating existing images from Resizer v1 to Resizer v2?

No, with v2 we’ve ensured that the output size is exactly the same as v1 (or smaller), thus not impacting your bandwidth consumption at all. No additional cost exists for cache-rebuilding with v2. Your output size is directly related to your quality settings and by default v2 is set to 75, while v1 was set to 85. If you are using a quality parameter in your transformation logic for v2, please be aware that increasing your quality in v2 will also impact your output size.

For images that have larger than or equal to 10,000 pixels for the height or width, will it work with Resizer v2? What is the impact to performance and billing?

Images with such large dimensions are transformed successfully using Resizer v2. Resizer v2 automatically downsizes images that meet this size criteria. Resizer v2 also has an extended timeout so that it should have an even lesser likelihood to failover to a full-size image. In this scenario, images may take longer to resize and render (like in Resizer v1), but will resize and render successfully (an enhancement in Resizer v2). This enhancement does not impact your bandwidth billing.

Google Web Vitals tool tells me my images are not optimized. How can I fix that?

Resizer v2 doesn’t behave any differently than v1 in this respect. Arc XP’s CDN will optimize image outputs from jpg to jp2/webp after the initial requests are made, and if enough time has passed where the object remains popular. If google web vitals is analyzing recently published stories or historical articles, our CDN may not have finished its optimization and will still return jpg file types. After some time though, these will be delivered in the most optimal format for a user’s device.

Yes, even if you re-publish the image (which generates an auth) for an image in a gallery, Content API does not receive the update until a gallery is re-published.

For auth token population, generally, our stance is that you should have your blocks set up so that the system can dynamically generate an auth token regardless of if its presence in ANS. Unfortunately, we can’t account for all images historically within differing content sources (gallery, story, and so on). Populating an auth token should not be a concern because it is a low latency API call.

If this is a concern, we can provide you a file of your images and a script to re-publish your images. But note that Content API rate-limits this action.

Is it a concern that the SEO string is open-ended in our Resizer v2 URL paths? How you are able to make it open-ended if it is not part of the signature?

We did not include the SEO filename in the auth signature so that you can change the path of the image without immediately invalidating previous SEO names for the same image. We can consider including a feature to protect SEO filenames (after v2 GA), but right now we do not think it is a concern.

Are we forced to use a fetch-based content source instead of resolve?

Yes, due to making async requests to signing service, you are forced to use the fetch content source. Therefore, if you use redirects within resolve content sources, you were doing so for free, but with Resizer v2, you must throw errors.

Why am I unable to use Resizer v2 in my secondary orgs and lower environments in the primary org (i.e. staging, dev)?

We are looking to add support for secondary orgs and lower environments in the primary org (i.e. staging, dev) before the deprecation date of April 2024. It is one of our top Resizer v2 priorities and we are targeting by end of Q1 2024. Please continue to migrate to Resizer v2 while we work on adding support for secondary orgs. A few additional notes on this topic:

  • The lack of support for secondary orgs does not impact OBF.

  • As Themes v2 blocks are fully integrated with image Resizer v2, customers with secondary orgs should plan to launch with Themes 2.0 after secondary orgs are supported by image Resizer v2.

Will Resizer v2 support author photos?

Yes, but you will need to resize it with v2 (currently should be using v1) in your front-end code.

Will Resizer v2 support choosing image quality?

Yes, see How to transform images.

Will Resizer v2 support focal point?

Yes, see How to transform images.

Why do we need to tokenize the image URL?

When you reference an image in Resizer v2, it needs to be the same path as it exists in the CloudFront URL and in S3. It’s possible for an image to not have an extension too, so it’s always best to just reference the CloudFront URL for the “asset ID” (arc ID + extension if present).

Will this impact my already setup Kinesis stream?

This may affect your Kinesis stream since we are introducing a new Auth field to the image ANS. Please check your Kinesis stream and update accordingly to account for the new Auth field.

Is using the same hash across all image resize requests a security risk?

Images are now only signed by the arc ID itself, so users can make any transformations they want without regenerating the token (see How to migrate from Resizer v1 to v2). There is the potential risk of malicious actors copying and pasting your image URLs and impersonate the image to use elsewhere on the internet. Additionally, there is also the potential risk of malicious actors modifying resize parameters on your images to incur bandwidth consumptions. Note that while Resizer v2 allows various transformations without needing a new token (for the purposes of more efficient development), this risk of malicious bandwidth consumption is not new for v2 and already exists with v1. If you are a victim of malicious attacks which impacts your bandwidth, reach out to your TAM to discuss billing options.

How do we avoid 404s from Resizer v1 URLs that may remain indexed by search engines after v1 is deprecated?

We highly recommend migrating all Resizer v1 URLs to v2 by following How to migrate from Resizer v1 to v2. We also understand that there can be a small number of v1 URLs that can be missed and some v1 URLs may remain indexed by search engines after v1 is deprecated. For these scenarios, we are going to implement a redirect that automatically transform v1 requests to v2 (keeping the v1 transformations the same as best we can*) with a 301 response. We will provide additional details as we get closer to deployment.

We may not be able to cover all different transformation variations from v1 to v2 in our redirect solution. The resulting v2 transformed image may look slightly different. We will provide additional details on the exact transformations we will support as soon as possible.

Does Resizer v2 support image file format transformations (i.e. jpg to png, etc)?

Resizer v2 does not support image file format transformation. Like Resizer v1, Resizer v2 does not support you choosing a specific output format since our Delivery service handles that automatically by choosing the optimal image file format. Although Resizer v1 did allow you to add it in the Resizer URL as part of the transformation request, like Resizer v2 our Delivery service defaults to handling it automatically.

Can I sign external (non-Arc) images dynamically on the client? Is signing service callable from the client?

No, and this was also discouraged in v1 since we strongly suggested that you do not expose the secret key publicly. Like v1 we only support the generation of security keys on the server-side, which allows you to transform external images (see How to migrate from Resizer v1 to v2). Resizer v2 allows you to transform your images using a single security key for all different transformations of a single image.

Will the “Path to Resizer” field in Edit Image UI be updated from v1 to Resizer v2?

No, any v1 image URLs that are provided by Photo Center in ANS will not be redirected and are excluded from deprecation. We will convert these to v2 at a later date.

What happened to the** resize_params **object?

The resized_params object was a ANS data object derived from an array of supported sizes in a site property object for identifying all the available image sizes for an entire site. You can see an example in one of our tests.

Naturally, listing all the possible image sizes, formats, and quality settings for an entire site becomes unmanageable. The getResizedImageParams function returned the resizer secret key, resizer URL, and the array of image widths, qualities, and types defined in the site properties. The resizerUrl is available in the site properties, the resizer key is no longer valid for resizer v2, and the supported image widths are no longer defined in the site properties. The only use case for the getResizedImageParams method is to retrieve the resizerURL, and because you can now find that property in site properties, we removed the getResizeImageParams function.

A list of image widths are now requested by the blocks themselves because they should have a better knowledge of what image sizes they need to render instead of trying to cover all possible images sizes in some site-wide list of all the supported image sizes. This means that Themes v2 can support a wider variety of sizes and can be more efficient in picking appropriately-sized images to request from Resizer v2.

We manage that URL creation in the image component where we concatenate the image resizer URL, the resize options passed by the blocks, and the width and height provided by the block or the ANS object passed to the image component. These sizes can be provided as an array of image widths (heights calculated based on aspect ratio) and those sizes are provided to the native <img> tag as a srcset so that the browser can make its logical decision on which image to load.