Hello Gliders,
I’ve been trying for hours to implement TinyPng into my Glide tables via Json but couldn’t figure out. Could someone please help?
I’m trying to compress images without the use of make.com if that’s possible.
Do you mean via a fetch URL column?
They do provide a way to do it, but I’m not entirely sure if the result is cached, i.e if the code fires every time there’s a user accessing the app then you’re doomed usage-wise.
I would still resort to Make to do something like this. If you don’t have that many users then it would still be ok.
1 Like
Thanks a lot Thinh for your reply and for helping me to avoid the potential catastrophic usage.
I’ve implemented Cloudinary method which I’ve gathered from the community here and paste the link into a column in my glide tables:
https://res.cloudinary.com/glide/image/fetch/q_auto,c_fill,h_500,w_500/X
(Where X is the link to the uploaded image from glide tables.)
Question:
-
Since I have the original copy on my glide table and don’t need a copy of the compressed image, are there any limitations in using the glide cloudname? e.g. … com/glide/image …
-
What is the recommended Cloudinary resizing mode to use for images viewed on a phone? I’ve been trying to play around but find that the images load time are about the same, but just leaving it as q_auto seems to be about one second faster
So what’s the ultimate reason you want to do this? Is it because you want to reduce the image size in your storage (your Cloudinary method doesn’t help), or you want to scale your image size to a certain dimension?
This is just a hacky method, you are actually using Glide’s account to transform your image. Normally, that “glide” part should be your Cloudinary user name.
I don’t know if resizing with Cloudinary does help with loading time, but wouldn’t Cloudinary would still have to process your image first before pushing the final image to the user?
If users are loading your app for the first time, they will have to load all the images and I imagine that increases your loading time. Once the images are cached, it should load quicker (2nd time onwards).
What you were suggesting with TinyPng would help though if you can pull it off, since it directly changes the source image to a TinyPNG resized version, and doesn’t rely on a third-party service like Cloudinary to process that first.
1 Like
The ultimate reason is speed - reducing the loading time for users because my app is image-heavy and it is currently taking a long time to load.
This is just a hacky method, you are actually using Glide’s account to transform your image. Normally, that “glide” part should be your Cloudinary user name.
I have tried various ways to change the Glide cloud name to mine but it doesn’t seem to work. I’m not sure if it’s because I’m on a free plan, but I have reached out to Cloudinary and I’m currently awaiting response from them. Any help on this would be appreciated.
I don’t know if resizing with Cloudinary does help with loading time, but wouldn’t Cloudinary would still have to process your image first before pushing the final image to the user?
This certainly helps. It reduces the loading time by a few seconds. The time to process one image through Cloudinary (end result 400kb) is still faster in my observation than loading the original image from the original Googleapis link which has a file size of 2MB.
If users are loading your app for the first time, they will have to load all the images and I imagine that increases your loading time. Once the images are cached, it should load quicker (2nd time onwards).
Got it. While this is true, the first-time experience however is not great and it turns people off from visiting the website a second time. Hence, I’m trying my best to see how I could bring down the loading time to a minimal.
What you were suggesting with TinyPng would help though if you can pull it off, since it directly changes the source image to a TinyPNG resized version, and doesn’t rely on a third-party service like Cloudinary to process that first.
I’m having a hard time trying to set up Make and linking it to a 3rd party provider, e.g. TinyPng or CloudConvert. In particular, I find the portion on Http request, POST, Authorization, Json and how to replace the original image URL in Glide tables very confusing as a non-coder. 
I have spent many days trying but still couldn’t get it to work unfortunately. I haven’t come across any videos or tutorials on how to set it up - specifically, sending the URL from glide to a 3rd party via Make or Zapier, optimize it, feed it back to glide tables and replace the cell with the new URL. If there is, please do let me know! 
Question: If I upload a photo of 5mb and glide tables generates a URL, and I then subsequently replace it with another link with a file size of 50kb, does my usage states 5mb or 50kb?
My sense it’s the latter but would be helpful to confirm my understanding.
What doesn’t work in your case? Does the image not load at all?
As long as you replace the original link with the new link, then the 5MB file will be deleted from your storage after no more than 30 days.
Regarding Make flow, it should be like this:
-
Create a new scenario in Make, add a “Custom webhook” module as the 1st module. Generate a webhook and copy the URL.
-
Assuming you are having a form to submit the new row with the image, in the on-submit action of that form, create a “Trigger Webhook” action. Send over the rowID and the image URL.
-
In Make, add a HTTP module to call the TinyPNG API. Use the image link from Glide as the input. Make sure you follow the HTTP call format from TinyPNG. Parse the response.
-
Add a final HTTP module to write the image back to Glide, using the resulting URL from TinyPNG and the rowID you passed from Glide in the 1st step.
Please try this first and let me know where you get stuck.
1 Like
This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.