container_registry view performance gets slower with more tags

Summary

We have multi-job CI set up in such way that first build stage job creates an image tagged with current commit hash. We use the image in multiple jobs following the build stage. This means each pipeline will produce one image leading to many image tags. Currently there are 599 images in one of our projects and the registry images page takes around 2 minutes to render. Images can be removed from the page but it takes a really long time.

Steps to reproduce

Have a lots of images in your project. Our setup is on-premises Gitlab 8.16.5-ee that is using a docker registry (S3 Storage with Cloudfront) on another machine.

What is the current bug behavior?

Render time of registry page time gets very long with many images. I can see in the registry logs that Gitlab is doing a huge number of API requests, basically getting metadata for each tag on each project registry page load.

What is the expected correct behavior?

I would expect Gitlab to have some sort of caching so it doesn't need to ask the registry about every image tag metadata every time.

Also some kind of easy way to cleanup not-needed images after all CI jobs finish would help, but there doesn't seem to be any way to delete images from the CI runner? I can see a feature request for removal API which would help.