These practices are applicable while building apps that run natively on Android and iOS. These do not apply to opening websites in a web browser on either of the two platforms.
ImageKit uses the standard content negotiation approach to identify the image formats supported by a device or browser. This content negotiation technique depends on the
Acceptheader value in the request.
Mobile apps often do not send any
Acceptheader value. Without this header, ImageKit assumes that the device does not support WebP and continues to deliver images in JPG or PNG. These formats are larger in size than WebP and therefore consume excess bandwidth.
To deliver WebP images, if supported natively on the mobile OS, you should force the output format specifically to WebP using ImageKit's format transformation parameter
For example, the following URL has an
f-webptransformation to force the output to WebP format.
- 1.You can find WebP support for Android here
- 2.You can find WebP support for iOS (and other Apple OS) here
- 3.AVIF support for Android and iOS is still negligible. Use Google to find when it gets supported for apps.
Different image placeholders on your app will need images in different sizes. Mobile phones additionally have high-density or retina displays and therefore need to load an image larger in dimensions on such displays. You would have seen this with
xxhdpi, etc., on apps where you provide the same image in different dimensions.
For example, if you need a 300px wide image, you can use the following URLs with varying
dprtransform values on each display density.
1x - https://ik.imagekit.io/demo/default-image.jpg?tr=w-300,dpr-1 2x - https://ik.imagekit.io/demo/default-image.jpg?tr=w-300,dpr-2 3x - https://ik.imagekit.io/demo/default-image.jpg?tr=w-300,dpr-3
- 1.You might be able to get sufficiently high visual quality by capping the DPR value to 2 even on higher display densities. This means that using
dpr-2on a 3x device might still work. Do give it a try.
- 2.When loading high-resolution images on high-density displays, you might be able to compress them more and still retain the same visual quality. For example, you can compress the 2x image to quality 60 and still get the same output visual quality. You can do this with the quality transformation parameter
- 1.The original image on which the transformation is carried out should be large enough in terms of dimensions to allow for DPR transformations. For example, if the original image is 300px wide, then using a transform
w-300,dpr-2will give you a 600px wide image. But, it would be pixelated because ImageKit had to enlarge a smaller image to a larger dimension.
Mobile apps often have layouts with multiple or infinite scrolls. However, because of the limited mobile screen size, the user can only see a small portion of the layout at a time. Outside of that visible portion (the viewport) of the layout, any media you load is not visible to the user. Therefore, it might not be helpful to load that media at all.
You must use a technique called lazy loading, where you can defer loading any images or videos that are well outside the viewport to a later time. This helps you save bandwidth and improve the app user experience.
Once you have done all of the above, one more optimization you can implement on your apps is network-based media optimization, i.e., load a lighter image or video if the user is experiencing poor network speeds.
The concept is simple.
- 1.You determine the user's network speed
- 2.You load a lighter file by compressing it more (by lowering the quality transformation parameter)
Additionally, to improve the developer experience and security of your file URLs, do explore features such as named transformations, signed URLs, and advanced security.