Currently, "@eZ\Publish\SPI\Variation\VariationHandler" variation handler injected into Thumbnail service

https://github.com/ezsystems/ezplatform-kernel/blob/master/eZ/Publish/Core/settings/thumbnails.yml#L10
and
https://github.com/ezsystems/ezplatform-kernel/blob/master/eZ/Bundle/EzPublishCoreBundle/Resources/config/thumbnails.yml#L9

I have no idea why it's declared twice, but it's a separate topic.

@eZ\Publish\SPI\Variation\VariationHandler is aliased to @ezpublish.image_alias.imagine.variation.imagine_alias_generator
in https://github.com/ezsystems/ezplatform-kernel/blob/master/eZ/Bundle/EzPublishCoreBundle/Resources/config/image.yml#L282

There is a "decorator" with implemented cache (unused):
https://github.com/ezsystems/ezplatform-kernel/blob/master/eZ/Bundle/EzPublishCoreBundle/Resources/config/image.yml#L63

As a result, the performance degrades a lot.

For example, we have API endpoint to return 100 content names, which we expected to work fast.
Content info loading triggers thumbnail loading, which is loading 100 images from S3, to calculate thumbnail width and height.
We don't need this information, but it's loading on each request, so it takes ~20 seconds instead of being completed in less 1s.

Anyway, I think this solution needs a second look.
Ideally, should work in this way:

• height and width stored in file "metadata" instead of a separate caching mechanism. In the same place as mime-type, size, path, etc.
• Make `getThumbnail` method lazy load information, as it's mostly required in admin UI and unused on front websites.

It will require some core devs team decisions, so I didn't work on PR for this. As I'm not 100% sure it will not be rejected, and it can take a few days to complete.