Efficiency of services like Cloudinary, Imgix

Question

I want to build a website with a lot of images and hence image manipulations like amazon, ebay, flipkart,etc. I have been suggested to use services like Cloudinary, Imgix, etc to resize my images since it would be better to store one version of each image although I'd need several versions with different sizes. I'd like to know how efficient these services are. Are there any issues? I'd like my website to be very fast and responsive. I have heard concerns like "Take into account that you're at least doubling the transfer latency involved, which will frequently dominate the time required to complete an image operation.

Normal: end_user->your_user->end_user

Through these services: end_user->your_user->you->your_user->end_user"

Answer 1

To answer your question as a user of these services and keeping in mind the way your question is asking about any issues in these services please see following points.

1. These services are optimized in terms of caching images. When you upload an image they create different sizes and transformation at that time. Some of these would cache it to nearest server at the same time so you get to see it quickly next time you ask for it.
2. You can specify what default sizes you want to cache. For example on your server you will upload 3 version of image 200x200 for mobile thumbnail, 300x300 for tablet thumbnail and 400x400 for desktop. You will save time by uploading images to these servers and they can resize into all three within milliseconds and distribute them to multiple cache servers.
3. Issues you might get are if you are changing images frequently then these services will require cache busting or changing URLs etc to get latest version. You will have to wait for cache to expire etc. However according to my use the benefit you get from loading an image in milliseconds on various devices is far more than the effort to bust cache and most of these services provide handy methods to do that.
4. These services reduce space on your server and most of the time cost of hosting images with them is a lot cheaper than storing images along with served code. If you are uploading high res or large size images the difference is significant. For example storing 500GB of images on web hosting machine or storage blob with caching is 4 times the cost of one of these services. Backup and version control is another benefit that comes with these services.
5. If you implement a nice image upload/view/tag/remove strategy you can save a lot of time and money over time by using any of these services. I recommend looking for a service that fits your usecase. For example you might want to use css/js cache as well or you might want to use images for private use or you want video uploads or you want object recognition in your project. Loads of choice just need time to research which is best.

The concern you mentioned about double latency are wrong because they are assuming that all calls will hit your server. These image services supply you a url that can hit directly their server or even better a local cache version of image. They take care of a lot of things that you might not have considered yet.

Answer 2

I am using imgix over 1 year. I think hosting images by a professional image server is much better than hosting it by your servers.

High performance

1- As Paul Straw said: Imgix has a proper caching strategy. It doesn't add the latency to load image. It even deduct the latency as its not fetching the master image every time the page loads. It fetches the image from cache.

2- Both Cloudinary and imgix use wide and fast CDN. So the user who needs to download an image, can get the file from the CDN edge which is closer to his location. Therefore latency will be dropped and it downloads faster.

3- Serving the correct image dimensions for a given device (or as close as possible) is the best way to make sure that images aren’t adversely affecting your page load times. Even small differences between the actual and desired sizes of an image can increase the file size dramatically.The most basic feature of image hosting services is the ability to resize images on the fly to fit any device as needed.

In addition of high performance of these services, I have seen some other benefits too which I mention some of them here:

Responsive images

Nowadays many website owners, Sales and Marketing executives and ... care about many marketing aspects. They choose pictures carefully in order to convert a user to buyer or to reach a certain goal in their website. Resizing an image for different screen maybe is enough for responsive design but its not enough for increasing the conversion rate of your website. Sometimes you need to crop the image to resize it. With image hosting services you can choose exactly where to crop, which part of the image is essential for marketing purposes to be remained and which part can be cropped. you can have all of these controls on the fly with these services without using Photoshop and prepare several pictures offline.

Retina Support

Most of images may be seen good in normal screens but when you see them in high density screens like Apple Retina or some Android devices are not good at all. The device pixel ratio is used to easily convert between device independent pixels and device pixels. This makes it possible to display images at the correct pixel density on a variety of devices such as Apple Retina displays and Android devices. In imgix you can choose to load pictures with higher DPR if the screen can support high density images. you can do it with srcset tags. Read more here

Image manipulation on the fly

Everything you wanna do on a picture can be done on the fly. You don't need to use Photoshop for small image manipulations. That's reduce design speed significantly.

Better SEO ranking

Image size is a big contributor to page load speed , which in turn is a key metric in determining search result rankings for your pages. Reducing image size can go a long way toward improving your rankings, especially if you can get the full page load below the threshold where many users start to drop away out of impatience.

Answer 3

[Disclosure, I am the CTO of the company that offers ImageEngine]

Mention of our own ImageEngine is in order here. ImageEngine is in the exact same space as the other solutions mentioned by the OP with a few extra advantages: its CDN was built from the ground up with mobile optimization in mind. In addition to Desktop browsers, ImageEngine's Edge Servers can accurately detect features like screen size, resolution and supported image codecs, and optimize images accordingly. This happens thanks to WURFL, the same Device Detection solution adopted by Facebook and Google, and accounts for additional optimization (up to 80% bandwidth savings) and reduced CDN bills. We call this concept "Smart Bytes".

Another big difference is the ease of integration. ImageEngine does not require organizations to upload images anywhere. This is great for companies with legacy images to handle. While ImageEngine allows directives (through URL parameters) to specify how a given image should be optimized, it also supports "auto-mode",i.e. ImageEngine will retrieve images from the origin website (no need to host images on someone else's server) and automatically optimize the picture to the best format as determined by the Device Detection component and client-hints. For example, devices and browsers that support .webp will get .webp. Customers just activate ImageEngine in front of their existing site and the magic happens with no need of extra tweaking. Current customers (particularly e-Commerce) love this feature.

Answer 4

There is definitely an advantage to only loading images the size that you need them. The biggest bonus is going to be load times. We all know that users don't like to wait for pages to load. So if you have multiple copies or compress all of your images based on screen size, you will offer a better user experience. Google also bases search display on load times, which image size plays into. I also suggest using a service that offers CDN for images so that you can take advantage of caching.

Answer 5

at work we use a combination of

• the generic pipeline image optimization eg grunt plugins
• getting clients design teams to use apps for image optimization
• we also use Cloudinary on a lot of our sites.

The solution usually varies based on customers costs and budgets but we are finding that Cloudinary is actually working out cheaper especially for customers who don't want us or their internal teams to spend time on image optmization and just want to focus on features.

By offloading the images and videos to cloudinary - its freeing up time for us to just focus on improving the site, AB testing and other revenue generating activities. Transfer latency which doesn't appear to be a big problem due to cacheing and CDNs would be a small price to pay for literally hours/ days of time freed up to focus on building products and developing the business.
You should work out what your time is worth- and how much more money you can make if you freed it up to do other things. What other things would you try?

Answer 6

(Disclaimer: I handle developer relations at imgix, and will be answering this post as it applies to our stack)

You're absolutely correct that for a completely uncached image, there are more "hops" involved to serve an image. For the first user to view an image, this can result in a slightly increased latency. After that, however, the image is cached by both our rendering cluster and global CDN, which makes subsequent requests for any image based off of the original much faster. Either way, the byte savings from serving correctly-sized images to the browser will almost always outweigh any additional latency from initial requests for an image.

Here's a simple diagram that shows the flow when an image has not yet been cached:

                      ┌─────────────────┐  4. Origin responds
                      │   Your Origin   │  with full-size
                      │ (S3/web folder) │  `dogs.png` image.
                      └─────────────────┘
                        ▲             │
                        │             │
                        │             │
                        │             ▼
      3. Image is not ┌─────────────────┐  5. imgix caches the
cached at imgix, send │      imgix      │  full-size image, then
request to origin for │                 │  resizes it to 300px
           `dogs.png` └─────────────────┘  wide and caches that
                        ▲             │    derivative.
                        │             │
                        │             ▼
      2. Image is not ┌─────────────────┐  6. The imgix CDN
       cached at CDN, │ imgix CDN (edge │  caches the 300px wide
     forward to imgix │nodes worldwide) │  variant and serves it
   rendering cluster. └─────────────────┘  to the browser.
                        ▲             │
                        │             │
                        │             │
                        │             ▼
  1. Browser requests ┌─────────────────┐  7. The browser
     `dogs.png?w=300` │ User's Browser  │  receives and renders
                      │                 │  300px wide `dogs.png`.
                      └─────────────────┘

Once the image has been cached (after a single user requests it), the loop becomes much tighter:

 2. The imgix CDN has ┌─────────────────┐
 this variant cached, │ imgix CDN (edge │
 and serves it to the │nodes worldwide) │
             browser. └─────────────────┘
                        ▲             │
                        │             │
                        │             │
                        │             ▼
  1. Browser requests ┌─────────────────┐  3. The browser
     `dogs.png?w=300` │ User's Browser  │  receives and renders
                      │                 │  300px wide `dogs.png`.
                      └─────────────────┘

After an original image is cached at our rendering cluster, generating derivatives is also much faster (in this case, a 600px wide version), since they don't require an additional trip to your origin server:

3. Full-size image is ┌─────────────────┐  4. imgix resizes the
    already cached at │      imgix      │  cached full-size image
     imgix, no origin │                 │  to 600px wide and
      request needed. └─────────────────┘  caches that
                        ▲             │    derivative.
                        │             │
                        │             ▼
      2. Image is not ┌─────────────────┐  5. The imgix CDN
       cached at CDN, │ imgix CDN (edge │  caches the 600px wide
     forward to imgix │nodes worldwide) │  variant and serves it
   rendering cluster. └─────────────────┘  to the browser.
                        ▲             │
                        │             │
                        │             │
                        │             ▼
  1. Browser requests ┌─────────────────┐  6. The browser
     `dogs.png?w=600` │ User's Browser  │  receives and renders
                      │                 │  600px wide `dogs.png`.
                      └─────────────────┘