Externally Served Media Routes

I’m working with a large number of 100kb-200kb images that I am hosting externally on remote storage and linking in-app through the direct URL in my spreadsheet.

However, whenever I look at my data tables in Glide it looks like it is fetching the entire image. Can someone confirm if Glide is passing that route and having the user fetch that data from my CDN or if it is caching and serving that media from Glide’s servers?

Followup question if it is indeed caching my media, is there a better way to serve my content directly from my server instead?

Glide optimizes and caches all images. There’s no way to disable this at the moment.

Can you say why you want to optimize images yourself? We optimize them in many ways—a different format for Android versus iOS, scaling them when used in lists to make lists scroll faster, caching them on our own CDN. You can’t do all of this in the spreadsheet with your own URLs, for example.

And what do you mean that the data table fetches “the entire image”? The data editor and apps have different behavior.

@david
I use cloudinary as my repository because:

  1. I like to keep control of my own images which isn’t possible at the moment at glide. I cannot delete images myself.
  2. I can specify how I want the images transformed e.g. rotated (and Overplayed with images and text) and specify that from within glide/google sheets on-demand
  3. I can upload images from within glide via webview component and thereby control the size of the uploaded files and keep upload time down
  4. I can have the images in a gdpr compliant system
  5. I have one repository for images used in app and website
  6. I have a possibility to bulk upload images
  7. I can store at a cheaper price

Glide could fulfill most of these requirements by adding new functionality

There are also drawback by storing outside glide I know.

3 Likes

To echo what Krivo said, the ability to improve performance of my application.

As I have increased the amount of content in my applications the load times have increased dramatically. Even on single-image pages it is taking upwards of 3 seconds to render a 100kb JPG hero image.

Being able to add additional edge nodes to my CDN, introduce load balancing, optimize caching rules, etc by serving my media directly from a personal server.


As far as doing this from URLs in my spreadsheet there shouldn’t be a difference in linking to my external storage whether it is in an SQL database or a google sheet.

And finally the way I worded “are you caching and serving my images on my behalf instead of hitting my storage endpoints” may have been a bit confusing, I wasn’t sure who would be answering my question so I tried not to use technical terminology.

Our engineers do this automatically for all Glide apps, and much deeper than you can do it. For example, list item images get a thumbnailed .webp file to optimize loading and scrolling on Android.

Glide is not built for people who want to manage their own image CDN—Glide is a non-technical tool.

There’s no way your app should take three seconds to load a 100kb image. Please share your app with us so we can see if there’s a bug.

WebP further answers my initial question as I’m testing exclusively on iOS devices that currently struggle with that format in Safari - which has to be used to properly set the PWA to my homescreen in iOS 12 & 13.

You asked for additional details in your earlier replies so I provided them, but you don’t need to personally attack your users as to what extent you believe their technical skills are compared to your engineers.

We do not serve WebP on iOS — only on Android.

Sorry, when I said that Glide engineers can optimize images “much deeper than you can do it,” I only meant that we have deeper access to the technical workings of Glide that allow us to optimize your images based on device Operating System, screen density, etc. I did not mean this as a personal attack. We optimize the images per UI component, per device, which you cannot do in your spreadsheet, no matter how skilled you may be :wink: