Introducing TwicPics vs. Cloudinary

Let’s be crystal clear: there’s a strong correlation between your website’s performance and success metrics, like user experience and SEO. Users abandon websites and shopping carts that take too long to load. And, the loading performance of a web page is now a direct ranking signal used by search engines, notably Google.

So, clearly, image optimization should be included as a key concern when developing and maintaining your web apps. However, this creates a number of challenges. Who should take responsibility for image optimization (back-end, front-end, designers, marketing, etc.)? How much manpower or resources should you divert from other areas? And, when do you reach the point where manually implementing image optimization becomes more trouble than it's worth?

Even worse, solving the challenges related to image optimization and delivery is not a one-time fix. You need to continuously refine your strategy as web and consumer standards evolve.

So, how can you make sure to adequately address image optimization in your web projects without distracting your development team from where they’re needed most? One of the most effective solutions is to outsource this task to an image optimization SaaS, like TwicPics and Cloudinary.

That immediately raises the next question: which image optimization SaaS is best for your online presence? The answer to this question is especially important when your website is the key enabler of your business and your main point of contact with the outside world.

Below, we’ll break down the differences between TwicPics and Cloudinary - two highly capable image optimization solutions. From the ease of use to features to the practical differences in implementation and how they fit into your overall software design lifecycle.

What is TwicPics: A Quick Introduction

TwicPics is a Responsive Image Service Solution (SaaS), providing real-time, context-sensitive, and on-demand image generation.

The concept behind how TwicPics works is fairly straightforward. TwicPics acts as an image proxy that pulls your images from a web location, generates device-adapted versions of those images on the fly, and then, caches, and delivers them to your website visitors.

TwicPics is very much developer-focused. One of its core beliefs is that website images are not a matter for back-end developers or DevOps. Thanks to its tools, image delivery can be purely a front-end concern.

Yes, it can be used by non-technically skilled website admins purely for its automated image processing capabilities, which are impressive.

To date, TwicPics estimates to deliver over 8.2 billion images and 108 TB of data per month. Despite being a newer competitor on the image optimization scene, TwicPics already has an impressive list of clients. This includes L’Oreal, The Market, Burger King, and Camaïeu.

What is Cloudinary: A Quick Introduction

Cloudinary was founded in 2012 and is easily one of the most widely used and well-known cloud-based DAM (digital asset management) platforms in the world. They claim to be used by over 1 million developers and 800 popular brands, including household names, such as Sony, Trivago, Tesla, and NBC.

Cloudinary has evolved from a DAM with some auxiliary features to an all-in-one digital media management platform that spans programmable media, media optimization, and DAM capabilities with wide-ranging third-party integrations.

Cloudinary is a jack of all trades, aiming to insert itself into each stage of your software design and asset management lifecycle: from media asset upload to optimization and delivery.

So, image optimization is literally just one piece of the Cloudinary puzzle. Unlike TwicPics, which is very much front-end and designer-oriented, aspects of the Cloudinary platform can be utilized by all teams across the SDLC.

As a result, Cloudinary is not just a single, monolithic product. With the launch of its Media Optimizer, it effectively split into two solutions with some overlapping capabilities: a full-fledged DAM and image optimization CDN.

Setting up & Ease of Use

First up, let’s look at the process of how you would onboard TwicPics and Cloudinary into your project. We’ll also assess the general ease-of-use and what the experience actually using each service will look like.

TwicPics

Signing up for TwicPics and integrating it with your web project is incredibly quick and simple. If your only requirement is to serve perfectly optimized images with accelerated delivery, you can get going in minutes.

To, illustrate, we’ll go through a quick demo of setting up TwicPics for your web app:

1. First, go to TwicPics and sign up for an account. TwicPics offers a free tier with 3GB of CDN bandwidth a month. This should be enough for most personal projects, especially as TwicPics only calculates CDN bandwidth (the CDN usage after content has been optimized). So, you can start playing around with it immediately with no commitment:

2. The first time you sign up, TwicPics will take you through a guided tower of the platform, which includes setting up a new image source. TwicPics will also immediately assign a default domain to you in the format of <sub>.twic.pics:`

3. You can connect a new image origin by clicking “Add new path.” Then, provide the publicly available source URL of the location where your images are stored. Optionally, you can specify a Path location which will modify the URL string from which your images are accessible:

So, for example, let’s say that we have an Amazon S3 bucket as an image dump. Typically, S3 bucket URLs have the following format:

https://testamazonbucket.s3.us-west-1.amazonaws.com/

Let’s say in this bucket we have a file named main-header.jpg. Assuming that the permissions are set to public, we can fetch this image using the following URL:

https://testamazonbucket.s3.us-west-1.amazonaws.com/main-header.jpg

Now, if you use this S3 bucket URL as your Source URL in TwicPics, you can fetch that same image using your TwicPics-provided domain like this:

https://9lnc3i79.twics.pics/main-header.jpg

With a free account, you can’t create multiple domains. However, what you can do is specify multiple Paths under a single domain. So, for example, you can connect one Amazon S3 bucket by creating a path, called s3, which will be accessible from 9lnc3i79.twics.pics/s3 and another Google Cloud Storage bucket, called gsc, which is accessible from 9lnc3i79.twics.pics/gsc.

Now, there are only three simple steps left to integrate TwicPics with your web project and start serving pixel-perfect optimized images:

1. Add the TwicPics front-end script to your project: TwicPics uses a lightweight, front-end JS script to analyze your CSS template and the device DPR. It also enables the default lazy-loading as well as pixel-perfect resizing. Just copy and paste the following script to your web page file and replace the <sub> with your TwicPics domain:

<script async defer src="https://<sub>.twic.pics/?v1"></script>

2. Modify your <img> tag src attribute: for all images that you want TwicPics to optimize, simply replace the default src attribute with data-twic-src. So, your <img> tags should look like this:

<img data-twic-src="image:<path_to_image>" />

3. Update your image URLs with your TwicPics domain: The last step is to make sure that you serve the correct image. If you use the data-twic-src attribute, TwicPics will automatically serve images from the domain you specify in the above script. So, all you need to do is provide the path (if you specified one) + the image filename. For example:

<img data-twic-src="image:main-header.jpg" />

Background images are referenced in a similar way:

<div data-twic-background="url(image:<path-to-image>)"></div>

As are video posters:

<video data-twic-poster="image:<path_to_image>"></video>

The TwicPics Native and TwicPics Components have the dual purpose of also allowing you to configure certain default behaviors, such as lazy loading, renaming the “twic” class, setting the max DPR, etc.

Essentially, that’s all you need to know to start serving perfectly optimized images via TwicPics. TwicPics is designed to be a hands-off image optimization service. So, it will appropriately optimize images regardless of the user context or your CSS styling.

In the documentation, you can find step-by-step guides for setting up TwicPics with Akeneo, WordPress, or other web project types.

Cloudinary

As a DAM and image CDN rolled into one, Cloudinary works a bit differently.

If you’re looking for image delivery and optimization solution, there are two different ways to use Cloudinary. The original way is to subscribe to Cloudinary’s “Programmable Media” packages. This is a full-fledged DAM solution that combines managed storage as well as optimized image delivery via a CDN.

So, instead of having to use an external storage solution, you can just upload your images to Cloudinary. You will then be provided with a Cloud Name that you use to reference your assets in your website project.

So, in your <img> tags, you’ll update the src attribute to look like this:

https://res.cloudinary.com/<cloud_name>/image/upload/myimage.jpg

Where <cloud_name> is an alphanumerical string provided by Cloudinary.

Last year, Cloudinary also launched Media Optimizer. Media Optimizer is more of a traditional image CDN, taking the form of a headless DAM. So, like TwicPics, you’ll need to connect an external image dump from which Media Optimizer will pull images to deliver. This includes external storage systems, such as Amazon AWS and Google Cloud but you can also use Cloudinary’s built-in storage.

You’ll be assigned a delivery domain that will be used like this in your image URLs:

https://<delivery_domain>.mo.cloudinary.net/

Like TwicPics, you can also create different path [prefixes, called “profiles” by Cloudinary, under your delivery domain. So, when you want to serve images via the Media Optimizer, your image URLs will end up looking something like this:

https://<delivery_domain>.mo.cloudinary.net/profile_1/myimage.jpg

If you want to use Cloudinary as your media source, you would just change the path prefix to /image/upload like you would when using the DAM.

Either way, by default, Cloudinary’s automatic behavior is to use formatting and quality compression to optimize images.

Implementing Responsive Images

Regardless of whether you use responsive syntax or not, TwicPics will automatically resize images according to the screen size and DPR of the device loading the image.

However, one of the key advantages of using TwicPics is how it intelligently interacts with your CSS to deliver smartly cropped and responsive images in all contexts. Importantly, it does this with almost no human intervention.

For example, a common practice today is to specify an aspect ratio for a particular image that must be maintained across all devices and display sizes.

If you style an image to have an aspect ratio of 16:9 across all devices, TwicPics will preserve that aspect ratio by automatically resizing an image to different 16:9 resolutions, such as 1024×576, 1600×900, 1920×1080, or 3840×2160, depending on the user device resolution and DPR. If you specify an aspect ratio of 4:3, for example, TwicPics would serve the image in resolutions such as 640×480, 1024×768, 1440×1080, and 2048×1536.

You can even define different aspect ratios based on specific breakpoints by using media queries. TwicPics will analyze your CSS and apply on-the-fly resizing and cropping accordingly. This greatly reduces the complexity and struggle of art direction for various devices and displays.

You can see this in practice in the documentation:

• You can rely on our Quick Start Guide to help you integrate TwicPics Native in HTML5.
• If you are using JS Framework(s) like React.js, Vue.js, Next.js, Nuxt.js, Angular… Make sure to check the TwicPics Components.

The same goes for using different aspect ratios for the same image at different media breakpoints.

TwicPics is designed to effectively free developers from the frustrating and tedious process of implementing responsive syntax. However, TwicPics does work well with natively-implemented responsive syntax. This is important because there are use cases where you still want to use native responsive syntax for art direction. It’s also best practice for above-the-fold critical images.

So, this is all you need to enjoy most of the benefits of responsive syntax:

<img data-twic-src="image:main-header.jpg" />

On the other hand, Cloudinary is not capable of automatically assessing the user context and CSS template to dynamically resize images responsively out-of-the-box.

Cloudinary does still solve a major problem: having to manually resize and manage multiple versions of a single image. Using conventional responsive syntax, you need a resized physical copy of an image for each srset breakpoint. However, using Cloudinary, you still need to implement the responsive logic but can direct Cloudinary to generate the resized variant for you dynamically.

So, a responsive syntax implementation using Cloudinary would still look like this:

<img
  sizes="(min-width: 30em) 28em, 100vw"
  srcset="
    https://res.cloudinary.com/eeeps/image/upload/f_auto,q_70,w_256/on_the_phone.jpg   256w,
    https://res.cloudinary.com/eeeps/image/upload/f_auto,q_70,w_512/on_the_phone.jpg   512w,
    https://res.cloudinary.com/eeeps/image/upload/f_auto,q_70,w_768/on_the_phone.jpg   768w,
    https://res.cloudinary.com/eeeps/image/upload/f_auto,q_70,w_1024/on_the_phone.jpg 1024w,
    https://res.cloudinary.com/eeeps/image/upload/f_auto,q_70,w_1280/on_the_phone.jpg 1280w
  "
  src="https://res.cloudinary.com/eeeps/image/upload/f_auto,q_70,w_512/on_the_phone.jpg"
  alt
/>

In lieu of Cloudinary’s recent “automate everything” update, there are a number of ways to automate the responsive images:

• Dynamic image transformation using responsive syntax with <srcset> or <picture> elements (shown above).
• Automated responsive images via the front-end JavaScript frameworks (e.g., the React SDK) according to the image width.
• Automated responsive images via the cloudinary-core JS library according to the image width and device DPR.
• Automated responsive images using client hints according to the image width and device DPR.

However, regardless of which route you take, Cloudinary will require more setup and manual decision-making than TwicPics’ hands-off approach. You’ll also need the foreknowledge to understand how the different approaches will affect your project and to weight them against each other. With TwicPics, you don’t have those types of concerns.

Note that TwicPics recommends using similar syntax only for above-the-fold images. This is to maintain web best practices that would apply to using any image CDN.

Using the API

TwicPics can be used as an entirely hands-off image optimization solution. However, one of its best features is its powerful and intuitive URL-based API. Using simple commands, front-end developers or designers can take charge of image manipulation and transformation.

TwicPics’ API is extensive. So, it covers pretty much everything from art direction to image optimization to changing the behavior of TwicPics under specific circumstances. A manual image manipulation string looks like this:

https://<sub>.spontwic.pics/<path_to_image>?twic=v1/<manipulation>

All you have to do is replace <manipulation> with a query string of parameters that specify your commands.

So, for example, you can resize the width of an image to 500px simply by concatenating the parameter resize=500 to the URL string:

https://<sub>.twic.pics/<path_to_image>?twic=v1/resize=500

When resizing only one dimension of an image, TwicPics maintains the aspect ratio by default.

Parameters can be chained and ordered to create a set of transformations and there are no limits on the number of manipulations that can be chained in a single query string. This is useful, for example, when cropping an image while maintaining focus on a specific feature. For example:

https://<sub>.twic.pics/<path_to_image>?twic=v1/focus=50x50/cover=100x100

As you may know, cover is a CSS property that specifies that the image should be resized to completely fill the entire area, in this case, a 100x100 pixel container. Focus, on the other hand, specifies the focal point. Using this combination, TwicPics will scale the largest image dimension to 100px so the container is filled while maintaining the aspect ratio as well as center the remaining image on a point 50:50.

One very handy feature of TwicPics’ API is that it offers built-in error reporting. TwicPics will issue an HTTP error with a status code for straightforward testing and debugging.

The API even provides transformations you can apply to image placeholders. You should check out the documentation for a deep dive into all possible transformations.

Cloudinary uses a similar URL-based transformation API. Like TwicPics, you build a query string using parameters that specify the transformations/manipulations you would like to apply.

https://res.cloudinary.com/demo/image/upload/<transformations>

So, you can execute the same set of transformations in the above TwicPics example like this:

https://res.cloudinary.com/demo/image/upload/c_crop,g_auto,h_100,w_100

The only difference is that we let Cloudinary automatically choose the focal point using g_auto. This is the default behavior using TwicPics, so there’s no need to specify it in the transformation string.

Arguable, Cloudinary’s image transformation and media optimizer API is even more extensive than that of TwicPics. You can create pretty advanced chained transformations by separating individual sets of transformations using a “/”.

For example:

https://res.cloudinary.com/demo/image/upload/c_crop,h_100,w_150,x_380,y_250/c_fill,h_100,w_130/a_20/c_scale,w_0.8/flower.jpg`

First of all, the image will be cropped to 150x100px with a custom center offset. Then, a fill crop to 130x100 will be applied. Next, the image will be rotated by 20° before finally being scaled down to 80% of its original size.

Conveniently, you can also create named transformations in the dashboard. So, you could create a parameter called first_crop that contains all of the entire initial set of transformations.

Following that logic, you can create named transformations for all the other sets and combine them like this to create the same effect:

https://res.cloudinary.com/demo/image/upload/first_crop/second_crop/a_20/custom_scale/flower.jpg

Image transformations and manipulations will work exactly the same when using Media Optimizer. It’s just your URL structure that will look different.

All-in-all, there are more similarities than differences between the two when it comes to manual image transformation and manipulation. However, one thing I do appreciate is that TwicPics is written in a more designer-friendly language with parameter names such as resize, crop, flip, etc.

On the other hand, Cloudinary’s naming conventions are more obscure with parameters like w_20, c_fill` etc. which doesn’t mean much at first sight.

More development-oriented users can also use the Media Optimizer API to carry out many management tasks in a programmable way using a command-line interface. This method will probably only be convenient from a DevOps or back-end development perspective.

Here is a breakdown of the most important similarities and differences between the two APIs:

As you can see, there is considerable overlap between the two.

However, Keep in mind that some of Cloudinary’s more advanced features require using the back-end APIs or the language-specific SDKs to execute.

Although Cloudinary’s API is also generally more extensive, a side-effect is that it’s also harder to learn and become comfortable using. Especially as you’ll sometimes need to transition between full-stack, back-end, and front-end development.

On the other hand, TwicPics offers a more streamlined API designed using a more front-end-friendly syntax. Another major advantage of using TwicPics is the lightweight, copy-paste script that does most of the work for you. It takes care of optimization and dynamically follows your existing art direction. All you have to worry about are unique edge-cases for both optimization and art direction.

Documentation

Documentation is a vital resource, particularly when just getting started with using new technology. Clear and concise documentation that guides you through the initial steps and explains how to use the service will play a huge role in how quick and easy it is to onboard.

TwicPics’ documentation is exactly that. It’s a single, coherent resource broken down into logical chapters and subsections. The getting started guide will get you up and running with a basic TwicPics implementation in minutes. From there on, it’s a straightforward process to look for specific information on topics, like using best practices, understanding the TwicPics starter script, using transformations, etc.

Cloudinary is just the opposite. As befits such a wide-ranging platform, the documentation is broken up into multiple independent hierarchies or areas, such as image and video transformation, digital asset management, media optimizer, etc. By themselves, most of these categories are larger than the entire TwicPics documentation.

While it’s great to have such an exhaustive resource to turn to, it does come with its problems.

After sitting with the Cloudinary documentation for hours, I was still discovering new features and capabilities. Occasionally, these new additions completely contradict information you had read earlier, forcing you to rethink how you will implement Cloudinary.

What’s more, it makes it really challenging to simply scan for or read up on a single topic. You will inevitably end up going down a rabbit hole of information with no end in sight.

For example, if you land on the image manipulation and transformation section first, you’d think there’s no way to serve responsive images via Cloudinary. However, a deep dive into the media optimizer section will eventually bring you to Cloudinary’s JS applet which does have this capability.

For most, it will take roughly an hour to get through the entire TwicPics documentation. And, once you’ve done that, you’ll already feel like you’ve got a solid handle on how TwicPics work. It helps that TwicPics is focused solely on the optimization and accelerated delivery of images. And, that the service is designed to be intuitive and effortless for front-end developers/designers to incorporate into their projects.

In contrast, this won’t be nearly enough time to get to grips with even a single aspect of the Cloudinary platform. Not even mentioning figuring out how all the different pieces function together.

Plugins, Compatibility, and Integrations

Inline with its entire philosophy, TwicPics was developed to be as technology-agnostic as possible. By using the URL-based setup as described above, you can already take advantage of the majority of TwicPics’ image optimization powers.

However, there is an official TwicPics components package that front-end developers can integrate with their projects to take advantage of all TwicPics capabilities. Supported frameworks include Angular, React, Vue, Gatsby, Next.js, Nuxt.js (v2), and Svelte (v3).

This is a game-changer for front-end developers that use modern JS frameworks. It’s effortless to install and the out-of-the-box collection of web components lets you take full advantage of TwicPics optimization capabilities with almost no extra configuration.

In most cases, it’s as easy as installing the TwicPics components npm package, copy-pasting some code, making some configuration changes, and updating your img components to TwicPics img components:

<TwicImg src="https://assets.twicpics.com/examples/twicpics-optimized-image.jpg" />

TwicImg components will automatically benefit from using LQIPs and Lazy Loading which will do wonders for your CLS and other speed-related metrics.

Cloudinary has been around for some time, so it’s not surprising that there are a huge number of third-party integrations for it.

There are Cloudinary-built integrations for Zapier, Magento, and WordPress in the form of native plugins/apps. Cloudinary partners, like Contentful, Vue, Amazon Web Services, and the Google Cloud Platform have also built their own Cloudinary integrations.

Cloudinary has also developed a number of SDKs for popular front and back-end frameworks, like Ruby on Rails, Python, Node.js, React, Angular, Vue, Swift/Objective C, and Android. Officially endorsed community libraries can also be found for Gatsby, Laravel, Netlify, and others.

Cloudinary’s SDKs work similarly to the TwicPics web component package. However, there is slightly more variation in implementation between various frameworks.

TwicPics vs. Cloudinary: Features

Ok, now let’s look at what each service actually has to offer in terms of their most important image optimization and delivery capabilities:

DAM Capabilities

This is undoubtedly where the biggest difference between the two services lies. Cloudinary is, first and foremost, a DAM (digital asset management) solution - a convenient, secure, and feature-rich platform to store and manage all your projects’ digital assets.

Its image CDN-only service, Media Optimizer, is a relatively new addition to the platform.

As a result, Cloudinary has many different areas of focus of which image optimization and delivery is just one.

On the other hand, TwicPics is focused solely on image optimization and delivery. And, all future development will go into improving TwicPics’ image optimization capabilities.

TwicPics' choice to not offer DAM capabilities is entirely purposeful. For one, it means that their service is entirely storage agnostic and is close to being front-end agnostic as well. As long as your image dumps are reachable via a public URL, images can be served and transformed in exactly the same way with a minimal difference in implementation.

This is in line with the TwicPics ideology - that images should only be a concern for front-end development and design. As the front-end developer, designer, or art director, you’re also completely isolated from having to deal with managing multiple image variants.

All you need to keep track of is your original, high-quality master images.

Automated Image Optimization

Whenever you edit an image uploaded to Cloudinary for the first time, Cloudinary automatically applies certain optimizations. This includes:

• Stripping unnecessary metadata.
• Quality compression.
• Format conversion.

That’s literally the only automated optimization that Cloudinary makes that doesn’t require any manual configuration. Although there are multiple responsive image implementations, I don’t really consider them “out-of-the-box.”

In contrast, TwicPics makes all of the following optimizations by default:

• Strips unnecessary metadata.
• Image resizing and cropping, including high-DPR/Retina devices.
• Lazy loading.
• Adaptive quality compression.
• Format conversion.

It doesn’t take a genius to figure out that, without any human interaction, using TwicPics will result in better byte-savings under almost all circumstances.

To get the same effect using Cloudinary, you’d have to manually implement native responsive syntax and lazy loading as well as enable automatic formatting, DRP adjustment, and smart cropping for each image you serve.

Handily, both allow you to create default manipulations from within the dashboard. This is particularly useful when combined with the ability to create separate paths or “profiles” to apply specific manipulations to specific subsets of images.

Real-time Image Processing and Optimization

Another rather unique TwicPics feature is that the script is always listening for changes in your document object model (DOM). This includes picking up when:

• New elements are inserted in your document with TwicPics attributes, such as data-twic-src, data-twic-poster, data-twic-background or data-twic-view.
• A TwicPics attribute is modified.
• Image sizes are changed dynamically at run-time.

What this enables TwicPics to do is respond dynamically to changes regarding how images are presented in real-time. Whenever the image presentation is altered, the script will re-assess the context and fetch a more appropriately optimized image variant.

What’s perhaps even cooler is that TwicPics automatically tags elements with specific CSS classes at different stages of their loading lifecycle. So, you can use these tags to apply specific CSS effects, such as while an image is loading or after it has completed loading. This feature is also useful for testing during development with flags like twic-error that indicate there was an error loading a particular element.

Most other image optimization solutions, including Cloudinary, do not have this ability. Images are only assessed and modified when they are on initial load. Cloudinary is not capable of detecting DOM or CSS styling changes, reassessing the context, and adapting how it optimizes a particular image.

Lazy Loading

Lazy loading is a web best practice. It helps bring down LCP and initial page loading times by deferring loading off-screan images until the user scrolls to their location. For large images that may take longer to load, using a fast-loading LQIP (Low-quality image placeholder) is considered another best practice.

TwicPics features built-in native lazyloading. Simply by adding the one-line script, all your TwicPics images will be lazy-loaded by default. While this isn’t exactly a groundbreaking or novel feature, TwicPics’ lazy loading is more intelligent than most of the alternatives out there.

TwicPics doesn’t just take the visible area in the viewport into account before deciding when to fetch and render an image. It also takes into account the user's actions, scripts' DOM manipulations, and style changes.

This makes it possible for TwicPics to defer image loading to exactly the right moment, without resulting in interrupted user experiences. Combined with its dynamic placeholders, it’s really one of the smoothest implementations of lazy loading you’re likely to come across.

Implementing lazy loading through Cloudinary is not as simple as it doesn’t provide a way to quickly implement lazy loading for your website images simply by adding a one-line script to your project files.

The only way to get lazy loading is by installing some of its front-end or back-end SDKs on your projects in order to use its advanced component libraries. Even then, you need to make modify your image components by adding additional syntax. With TwicPics, on the other hand, this behavior is automatic.

Cloudinary’s lazy loading implementation is also more basic than that of TwicPics. It will only apply to when the image is initially loaded and doesn’t take anything other into account than when the image shows up in the viewport.

For HTML-based websites, you’ll need to create the placeholder separately in the Cloudinary dashboard and then implement the logic for using the placeholder in your website code. However, you can have Cloudinary automatically serve an image placeholder in case the image is not available.

Smart Cropping

TwicPics will always try and identify the most important visual elements in all your images and keep them in the frame whenever the image is cropped, regardless of changes in the aspect ratio or size.

No matter how complex the rule is, TwicPics will intelligently resize and crop images so that the most important information is still visible. You can see this in action here.

One of the things that makes TwicPics unique is that it doesn’t only analyze and understand the end-user context, but your CSS template as well. This means that you can go about your business, implementing art direction in CSS as you usually would.

Cloudinary also provides intelligent cropping. Smart cropping is not enabled by default but you can use it for any image simply by using the g_auto parameter when serving an image. Like TwicPics, Cloudinary will attempt to crop the image while keeping the most important visual information in frame.

CDN and Caching

Of course, the CDN infrastructure is important to ensure that the distance between you and the majority of your visitors is as short as possible, regardless of their geographic location.

TwicPics’ global CDN consists of 3 processing clusters with over 225 total PoPs (points of presence) across 89 cities and 47 countries. The PoPs are spread as far as the southern tip of Africa, South & North America, Europe, South & East Asia, as well as the far reaches of Oceania. Image data is transmitted via HTTP/3 over Quic for maximum speed and efficiency.

What’s more, TwicPics claims 99.99% server uptime and reliability.

On the other hand, Cloudinary doesn’t operate its own in-house CDN. Instead, they leverage a multi-CDN setup from downstream providers Akamai, Fastly, and Amazon CloudFront. This is an excellent feature for providing users with maximum coverage and availability.

Another good quest is, “Won’t generating new image variants on a remote server delay the delivery process?”

Well, not in any meaningful way. TwicPics estimates that it takes no more than 5 ms to process an image. Even if you have multiple images loading at the exact same time within the viewport, the difference will be barely perceptible.

Also, both Cloudinary and TwicPics will immediately cache a newly-generated image variant for a particular end-user context. This is so it can be fetched more efficiently without processing the master image in the exact same way.

So, any delay that does occur as a result of generating a new image variant will only be felt the very first time that particular image variant is created. Cached variants are also duplicated and distributed across servers on the CDN to deliver requests from as close to the user as possible.

TwicPics also uses browser caching so that the same user can fetch a once-rendered image locally without downloading it multiple times.

Using the Cloudinary Media Optimizer API, you can exercise some control over your cache from the command line. For example, you can warm up your cache by sending the delivery URLs of the relevant images to the warm-up cache endpoint. You can also invalidate cached media or derivatives this way instead of using the UI.

Dynamic Placeholders

For example, one of the fixes for the CLS core web vital is to use image placeholders that reserve space on the viewport before the actual image renders. However, empty white spaces provide the visitor with no information, are unattractive, and don’t make a great first impression.

Once again, TwicPics has the interests of those responsible for image art direction well covered.

This feature can be enabled for a particular image, simply by using the output=preview parameter in the URL. TwicPics will generate a LQIP (low-quality image placeholder) that will initially load in place of the full-size image.

In terms of art direction, you can choose to use a standard blurred-out LQIPor one based on the meancolor or maincolor of the original image.

As another option, you can also use TwicPics’ default placeholders. To do that, just replace the img src attribute’s value with placeholder:auto, like this:

<img data-twic-src="placeholder:auto" width="300" height="300" />

In DPR 2, that will automatically generate a placeholder like this:

TwicPics’ dynamic placeholders are entirely responsive and CSS-aware, just like normal images. You can use the TwicPics API to modify placeholders by changing the color, transparency, size, etc.

Placeholders are served as mesh SVG files instead of bitmaps, further reducing their payloads.

With Cloudinary, you can implement dynamic placeholders using its Advanced Image Components included in its various SDKs. It offers similar LQIP art direction to TwicPics, with a small number of additional LQIP options built-in.

However, for other types of web projects, you’ll still need to manually implement the logic for progressive image loading.

Plans and Packages - Feature Breakdown

TwicPics and Cloudinary use two very different pricing strategies. On the one hand, TwicPics is only really considered with the amount of CDN bandwidth that you use. On the other, Cloudinary uses a credit system that splits your total credit allocation between the amount of storage and bandwidth you use as well as the total number of image transformations per month.

Both count CDN bandwidth as the “net viewing bandwidth.” This means it only counts the data transfer size of the already optimized image that’s being delivered. So, if a master image has a size of 1 MB and is optimized by 75% down to 250 kB, both CDNs will only count 250 kB toward your total bandwidth usage each time that image is requested.

When it comes to image delivery and optimization, TwicPics has one clear advantage. Because TwicPics doesn’t track transformations and doesn’t factor in storage, every kilobyte of your bandwidth allocations is purely for delivering media-related data.

For example, let’s compare TwicPics Pro with Cloudinary Plus. TwicPics costs roughly 17% more than Cloudinary Plus.

However, let’s try and break down what a hypothetical case of using Cloudinary would look like. Let’s say that you use at least 50 GB of your storage allowance for various media assets, including images and video. You now have 175 credits left to divide between transformations (max 175K) and bandwidth (max 175 GB).

In a real-world scenario, you should expect at least 5 variants of an image to be generated for different user contexts. However, Cloudinary factors a number of actions into the total transformation count, including manual image edits. So, 5 is really a best-case scenario.

However, Cloudinary also counts derivatives toward your storage usage. So, let’s say you have 5 derivatives of each image and that they are roughly the same size as the original, you would have to multiply your potential storage usage by 5.

Sure, these figures are highly hypothetical. However, this illustrates the uncertainty of the type of shared-credit system like the one Cloudinary uses. Not to mention the difficulty in accurately calculating your needs and how they will affect your Cloudinary plan.

To its credit, Cloudinary imposes soft limits which means it won’t cut you off immediately if you exceed your allocation. However, you’ll need to either reduce your usage or upgrade your plan if your usage persists.

On the other hand, TwicPics is flexible because it charges you on a pay-as-you-use basis when you exceed your plan limits. TwicPics also only counts in 100 MB increments. So, if you use 3.05 GB/month on a Free 3 GB plan, TwicPics discards the extra 50 MB and you'll still considered within limits.

Let’s say you reach 10 GB in a month on the free plan. In that case, you’ll be charged an overage fee at a rate of $0.5 per GB. So, your total bill will be only $3.5 for that month.

TwicPics vs Cloudinary: Pricing Scenarios

Now, let’s look at some scenarios of how real-life traffic patterns could affect your TwicPics or Cloudinary subscription.

The table below contains data from four different types of website with the typical monthly visitation patterns and image contents of each. In the columns to the right, we show the most affordable plan that the website would qualify for using TwicPics or Cloudinary. The examples suppose an average optimized image size of 25KB:

How did we get to these conclusions? Glad you asked.

Let’s take the first scenario of a small institutional website (no ecommerce) as an example.

First, you can expect TwicPics to reduce image payloads by up to 30% more than Cloudinary. So, the total bandwidth consumption using Cloudinary would be ~4 GB.

On a Free Cloudinary plan, that would leave you with 25-4 = 21 monthly credits remaining.

If we take the original image size as 75% larger, each image would be 100 KB. That means a library of 100 images would weigh = 5MB. If we assume 5 variants per image, that equals roughly 25MB. At 0.0025 credits, the storage consumption barely touches your monthly credit budget. And, you still have roughly 21 credits left.

So far, so good for Cloudinary.

However, according to this data, 80,000 transformations are performed every month. And, that’s just the automated transformations. That’s more than 3x your entire Cloudinary monthly credit budget and almost 4x more than what’s left of the budget after deducting CDN usage.

If you’re using Cloudinary, you’ll soon need to upgrade to the Plus plan with 225 credits to continue using the service at this scale.

Now, these numbers are not definitive. The difference in how TwicPics and Cloudinary handle image transformations means it’s almost impossible to make a direct comparison. Not to mention the fact that even different websites of the same type can have dramatically different traffic patterns and media usage.

However, the fact remains that if TwicPics generates 500,000 transformations a month for a particular website and Cloudinary only generates 200,000, that shows a lack of flexibility or dynamic responsiveness on the behalf of Cloudinary.

We can apply this same logic at higher scales. Once again, illustrates the potential pitfalls of using a shared-credit-based system like Cloudinary.

Is TwicPics Always Cheaper than Cloudinary?

What this data shows is that, in most cases, TwicPics will work out to be the more economical option between the two. That’s especially true if you’re mainly looking for a service that will extract the maximum optimization potential from your media assets.

Of course, you need to compare the cost of TwicPics and Cloudinary through the lens of your own unique requirements. There’s something to be said about the DAM capabilities and visual editing tools that Cloudinary has to offer. However, the monetary value of these tools is much harder to quantify and will differ from situation to situation.

Cloud storage today is extraordinarily cheap. If we take Amazon S3 as an example, 225 GB would only cost you $5/month while 600 GB would only cost you $13.80/month. Supposing our scenarios above, paying for both TwicPics and S3 storage would still work out significantly more cost-effective than Cloudinary.

Even if we add Adobe Photoshop ($20.99/month) as your live image editing solution, you would still be paying less than you would for Cloudinary.

Still, there’s no accounting for the convenience of having all these tools rolled into a single one-stop platform. And, Cloudinary also provides a powerful framework for back-end developers to streamline media asset uploading and management.

Who is TwicPics Best For?

TwicPics is a full-stack image optimization and delivery solution. Here is a summary of what TwicPics has to offer.

• Storage agnostic asset handling.
• Intelligent quality compression and image formatting.
• Hands-off image optimization with responsive resizing.
• Lighting-fast processing, and delivery via an in-house global CDN.
• An intuitive API using front-end development and design-friendly language.
• Automated implementation for dynamic LQIPs and lazy loading.

What’s more, its powerful JavaScript API seamlessly integrates with any front-end development workflow through intuitive commands. Finally, TwicPics is technology/storage agnostic and respects web standards. So, it will seamlessly slot into nearly any web project.

TwicPics doesn’t solve all your media asset-related concerns. However, it was never meant to. Compared to many other popular services, TwicPics will still leave plenty of room in your budget for other proprietary software or services to handle asset storage, management, and editing.

The main idea of the TwicPics philosophy is that the optimization, delivery, and presentation of media assets should be a front-end design concern only. Back-end developers can continue with their work without having to take image presentation into consideration.

Who is Cloudinary Best For?

Cloudinary, on the other hand, is a full-stack media asset management solution with a role to play at every stage of the SDLC:

• Media upload, storage, and management.
• Intelligent quality compression and image formatting.
• Extensive APIs for back-end and front-end developers.
• A multi-CDN network using downstream providers.
• Visual manual image and video editing tools.

As a full-stack DAM, delivery, and optimization solution, you also know with Cloudinary that all your media-asset-related technology will be covered under a single subscription. However, Cloudinary’s credit-based pricing tends to not scale as affordably, particularly if your website experiences a high demand for image transformations.

Unlike TwicPics, Cloudinary is a multi-faceted behemoth aimed at solving problems across all aspects of the media asset management process. Because using its more advanced features requires greater technical expertise and manual intervention, Cloudinary is unlikely to be used purely by designers, especially if image optimization is a significant concern.

Conclusion/Verdict

Furthermore, Cloudinary is not primarily aimed at making life easier for front-end devs. While it does feature an API that can be used to transform or optimize image assets in-code, it’s not as streamlined as TwicPics’ JavaScript API.

You can argue that if your main concerns are:

• The optimization and responsiveness of your media assets
• Simplifying and speeding up the development process

Then TwicPics is your best bet. TwicPics hands-off and intuitive approach greatly simplifies the entire web development process, from server-side architectures to frontend integrations. Not to mention benefitting from the out-of-the-box optimization performance of the smart and unobtrusive JavaScript library.

On the other hand, as a DAM, Cloudinary is a behemoth that aims to solve many more problems related to media asset management. It also provides tools to developers across the full stack of website development technologies and processes.

However, that additional sophistication does come at the cost of speedy and effortless onboarding. Not to mention a more complex and, generally, expensive pricing structure.