Skip to main content

Imagekit

Intro​

Features​

Bulk Upload​

Question - Imagekit vs AWS S3 for uploading images​

For optimizing the upload process of a huge size of images with a lot of images, what is the way to go, where uploads are distributed throughout the world?

  1. We should upload to S3 using S3 presigned URLs and serve those images via imagekit, by connecting to S3 bucket using external storage?
  2. Upload to imagekit directly using it's react library and authenticationEndpoint and don't use S3?

Currently we are sending images to backend, and backend uploads to imagekit, which is not a good scalable method, so we will migrate to one of the above methods.

Answer​

both approaches mentioned can be possible using ImageKit.

Storing your assets in ImageKit DAM can have significant advantages, as mentioned below:

ImageKit’s Media Library is a highly available Digital Asset Management Solution. The storage system that forms the basis of the Media Library/DAM is co-located with our core processing servers. DAM storage is currently spread across 6 locations - USA West (California). USA East (North Virginia), Europe (Frankfurt), Asia (Mumbai), South East Asia (Singapore), and Australia (Sydney).

All the assets are stored in the region that you select while creating your account with ImageKit.

ImageKit’s Digital Asset Management Solution is not only a highly available Storage solution, but it comes with a lot of other significant benefits over traditional Cloud Storage.

Simple User Interface that can be used both by your tech and nontech teams with a wide range of APIs for integrations with other products.

There are multiple ways to organize your assets by creating AI tags, manual tags, and custom Metadata.

Easier search options for retrieval of your assets.

Granular User Role Management and Sharing of assets within or outside your Organization.

Delivery and real-time transformation of your Stored assets through a CDN

Read more on the different features provided by ImageKit DAM here.

Also, as the assets are stored in the same region as the Image Processing region while delivering assets directly from the DAM, you would see performance benefits as compared to using an AWS s3 as both the Storage and the Processing region will be in the same region and infrastructure used by ImageKit.

Optimizations​

Caching​

Age on "Embedded URL" is 178571 seconds, i.e. approx 50 hours. Age on the "Individual URL is 12951 sectors i.e. approx 3.5 hours. ​ If I try to skip the cache on the embedded URL by adding a versioning parameter v1, it does give the updated dimensions. ​ Purging the cache for this URL or adding a versioning parameter should help you fix this.

ImageKit follows a recommended setting of a 365-day cache time, by default. If you'd like this cache time to be customised, there are two ways to resolve this for you -

1. Versioning of your image URLs​

Since caches are based on the image URL, adding a simple parameter like the last updated timestamp to the URL is the most effective way of automatically clearing cache, when it is actually needed.

For eg, If there are two images 1.jpg and 2.jpg both of them get updated at timestamp 156237123. There URLs would look like - 1.jpg?t=156237123 and 2.jpg?t=156237123

Now, if image 2.jpg is updated, you can use the last updated timestamp from your database to change the value of the parameter 1.jpg?t=156237123 (this URL continues to remain cached as long as possible) 2.jpg?t=158268232 (this URL is now automatically purged from cache)It requires a small change to your code, but this would work the best regardless of what service you use. ​

2. Using a custom cache-control time with ImageKit​

This option allows caching based on the cache control headers being passed from your origin attached to ImageKit.io. For example, if your origin https://storage.googleapis.com/ sends a cache-control header to cache a file for 1 hour (which it does on your website), ImageKit.io applies the cache-control header across all its internal caches, generated transformations, and CDN.This ensures that the cache control set by you is obeyed at all times.

Please note: We will have to enable this option for you at our end. And this can only be enabled on a paid plan.

I would personally recommend that if cache clear can be resolved with option 1, then please prefer that. It maximises the benefit of caching on the CDN while purging it for only images that actually get updated, instead of a periodic cache clear for all images. ​ In case there is a specific URL that you would like to purge cache for, as an exception, you can always do so from the dashboard here: https://imagekit.io/dashboard/purge-cache. More details on how to use this method of cache purge here: https://docs.imagekit.io/features/cache-purging

The cache purging methodology would essentially remain the same even if images are stored on ImageKit's media library.

However, it does simplify the process for you. If you make any edits to the image, you can save it as a new version or as a new file on the media library.

If a new version of an image is created on ImageKit's media library, we update the time stamp on the newer version's URL.

If you save the image as a new file, we added a random string to the image's name, thus also updating the URL.

If you replace the old URL with the new URL on the front end, it would have an effect of skipping the cached response of the older version.

For example: If this is the older image: https://ik.imagekit.io/uf5ueu4sr6/sakura%20tree%20in%20bloom.jpg?updatedAt=1704462165134 I make edits and create this newer version: https://ik.imagekit.io/uf5ueu4sr6/sakura%20tree%20in%20bloom.jpg?updatedAt=1704462541504 If you update the time stamp on your URL to the one on newer version, you skip the cached response, without having to purge the cache.

Purge cache - ImageKit.io Docs

Settings​

  • Use best format for Image Delivery - Turned on
  • Optimize image quality before delivery - 50%
  • Restrict image size based on user's device
    • Desktop - 2000x2000
    • Mobile - 1000x1000
    • Width of 1440px for laptops, 960px for tablets, 480px and High-density images for bigger phones, and 320px for smaller phones.
  • Parameters - Dynamic image resizing

Libraries / SDKs​

Signed URLs​

A signed URL is a secure URL that can be generated only by you using your account's private key. There are certain use cases where you will need to use signed URLs:

  • You have turned on the "Restrict unsigned URLs" setting from the dashboard.
  • You watermark all your images using ImageKit.io parameters to protect original assets. You do not want anyone to access the original image by removing the watermark specific transformation from the image URL.​
  • You want certain image URLs in your application to be accessible only for a specific time period in the future.
  • You are trying to access a private image.
A signed URL would be similar to

https://ik.imagekit.io/your_imagekit_id/path-to-image.jpg?ik-s=`generatedURLsignature`&ik-t=`UTCtimestamp`

5 ways to secure your website images with ImageKit

Signed URLs - ImageKit.io Docs

Private images - ImageKit.io Docs

Others​