filepicker.io - convert() and store vs FPUrl conversions

Question

I have an application where users upload an image and it has to be available in three different sizes (thumbnail, medium size, full size). The image does not need to be modified by my users.

It seems there are two options:

Option 1: Use image conversion urls whenever I want to display a thumbnail. Ex. https://www.filepicker.io/api/file/hFHUCB3iTxyMzseuWOgG/convert?w=200&h=250

Option 2: Use convert() with store to store the thumbnail in S3.

My question is can I use Option 1? How would this impact performance? Are the converted files cached on filepicker.io's end or does filepicker convert the image every time the user's browser hits the conversion url?

Gustav

Answer 1

The converted files are cached on our end, so using the conversion urls is entirely supported. If you know the sizes that you want ahead of time and don't think you'll need the variety, you can also use the .convert() call to "precache" the conversions, but it's more of a style preference than a huge performance difference

Martyr

Is it necessary to include cache=true in the convert REST call to ensure that caching happens? I can't prove that it isn't happening, but in my limited tests where I use REST to convert a dozen 1080p images to a thumbnail size and then reload the page, it isn't as much faster as I might have expected. How can I tell whether filepicker retrieved from cache vs. resized again? – Pantechnicon

Answer 2

Actually, there is a very important difference between using the Javascript .convert() method and using the /convert REST url.

Each time you call .convert() you use up one of the upload credits in your account, whereas using the /convert url method uses one of the conversion credits... and accounts have a lot more conversion credits than upload credits.

So, where possible, using the /convert url is significantly cheaper.

Extrinsic