A picture is worth thousand words.
In order to display meaningful data, an image with data is a must. We use Filestack to store our images.
Background:
Here at Edcast, like other ecommerce platforms we would have observed, the basic level of viewing content was in tiles form. Let’s call it as “Card”. In order to display content effectively and beautifully, we used to attach content with an Image.
For contents which already have images, they get extracted and are displayed as such, but for the ones for whom the content failed to load the image or for who didn’t have any image, we show some stock images.
In order to understand what stock images are, I can just say they were pre-uploaded images on Filestack. When we upload an image on Filestack, it returns the meta_data of image. We have maintained a static array of meta_data of 100 images.
[{
"mimetype": "image/jpeg",
"size": 78252,
"source": "local_file_system",
"url": "https://cdn.filestackcontent.com/blah",
"handle": "blah",
"status": "Stored"
},{}{}]
The code written was pinging the original image link stored at our end, and then displaying it as such. At our end in order to give good user experience, a user was allowed to upload as heavy image as they can. We were not making any restrictions to our limits. High Resolution images made our website slow, was an overkill and increased the billing. Unoptimized images was now a big problem.
Core Problem :
- Restricting the image size without degrading quality and without user knowing
- Restricting the image size so that rendering can be made faster
Possible solution:
- Resizing Images on upload before it gets stored on Filestack
- Compressing Images
I got to know that the average webpage loading time is ~2MB and image size if are not controlled then it has the power to bloat your app. I went ahead with Resizing after understanding how exactly filestack is being used at our end. There are many articles talking about how to reduce the image load time.
Implementation:
Before Upload:
- Using Filestack’s File Picker Javascript API , restricting the dimensions of image using imageMax(imageMax: [number, number]) and imageMin(imageMin: [number, number])
This is to be used when user uploads an image. It ensured that even though user uploaded an heavy image, the final image getting stored is much restricted without compromising on resolution.
Before Rendering: (After image is stored on Filestack)
- Using Filestack’s Transformations API to resize the image on the fly.
https://process.filestackapi.com/resize=${options}/${pathname}
This was needed for images which comes from crawling and are not yet stored. This was also needed because we had different layouts and cropping the image is not an ideal solution. So passing the exact height or width(one of them) will make it adaptable to the layout.
After this another task was how to take care of existing large images whose upload is unrestricted via upload API of Filestack, but Transformations API limits it.
Backward compatibility of older images:
This was done via a rake task, steps followed were :
- Try Resizing using the API. If it couldn’t resize then find the reason
- If image size exceeded i.e if its a larger image
- Deleting the original image from filestack
- Upload the resized image
- Taking the links and updating the DB column.
This was indeed a lengthy procedure but in order to limit the data size, we did identify the large sized cards by another filestack’s API image-size. This made our data set extremely focussed.
There ought to be more efficient ways to optimize image rendering, but as of now this is also gave us desired results. It hugely reduced the time in loading of images on app and gave a significant improvement in app performance.
After Thoughts:
Glad that I got a chance to work on this stuff. It made me to look at the bird’s eye view so that I know how exactly Filestack is used on frontend and on backend. Also, one thing which got my attention is that RFTM is so real. I got to know the importance of checking documentation and how we under utilize the features of sometimes powerful systems.