ImageEngine Deserves a Second Look

This is a sponsored post. This the first time we’ve done this, and we only agreed once we found a topic that we would write even if it wasn’t sponsored. ImageEngine had no editorial control.

tl;dr; ImageEngine may be the easiest way to implement responsive images and is worth considering when you’re looking for a solution that will get you 80% of the way to optimization with minimal effort. They have a new, free developer tier you should try out.

A few weeks ago, I had an engaging conversation with ImageEngine about a new, free developer tier they’re working on. They were curious about the hesitance from developers like myself to utilize their service, and I am ashamed to admit, even in situations where it would be a fit, ImageEngine hadn’t crossed my mind.

Last summer, I advised two clients grappling with web performance issues where images were the main culprits. Despite presenting various image optimization services that would work on their BigCommerce and WordPress sites, neither client moved forward due to the labor-intensive task of updating image sources in their templates.

In retrospect, ImageEngine would have made a lot of sense for these clients as a quick and easy way to get some big improvements in their image performance. For the BigCommerce customer, it still would have likely meant updating templates, but only with a prefix instead of full responsive images markup. For the WordPress customer, they could have installed a plugin, added their ImageEngine unique domain, and they would have been off and running.

But why wasn’t ImageEngine part of my initial recommendations? A few factors contributed to this oversight:

• Market Presence: Competitors with more aggressive marketing and more features were more top-of-mind.
• Device Detection Stigma: ScientiaMobile created ImageEngine. ScientiaMobile’s bread and butter is device detection based on their core technology called WURFL. More on this later.
• The Quest for Perfection: I’ve spent too much time on responsive images and can’t help but see the flaws in various approaches. I often seek the flawless solution, overlooking practical and effective alternatives. It’s a pattern.

On that last point, I was concerned about what happened if device detection got something wrong?

Of course, striving for perfection can sometimes hinder progress. In the case of my clients, the quest for the perfect image solution led to months of unnecessary slow site performance. An 80% solution now is better than a perfect solution delayed indefinitely, and you can always do further optimization later.

ImageEngine excels in providing an immediate performance boost because of a few key differences in its approach:

At first, I didn’t get the benefit of this subtle difference between ImageEngine and other image optimization services. They all optimize images. Why does it matter if ImageEngine does it by default whereas others have to add something to the URL?

Let’s compare Cloudinary’s URL syntax to ImageEngine. If I wanted Cloudinary to retrieve an image from our server and optimize it, my URL would look like this:

https://res.cloudinary.com/cloudfour/image/fetch/f_auto,q_auto/https://cloudfour.com/wp-content/uploads/2024/01/3d-part2-r1.pngCode language: plaintext (plaintext)

There are several flags in that URL that tell Cloudinary what to do. The fetch portion tells Cloudinary to retrieve the image from the URL in the second half; f_auto tells Cloudinary to convert to the best image format that the user’s browser supports automatically, and q_auto automatically optimizes quality.

By contrast, the ImageEngine URL to do the same thing would be:

https://3r3r223r.cdn.imgeng.in/wp-content/uploads/2024/01/3d-part2-r1.pngCode language: plaintext (plaintext)

No flags are necessary. All you have to do is prefix your image path with the domain ImageEngine gives you, and the image is optimized.

I understand why other services don’t optimize by default. Sometimes people want to serve the original image. You may anger some customers if you pick the wrong level of optimization. Besides, adding parameters in the URL is not a big deal, and they can be tremendously powerful.

But it is also true that having images optimized by default makes the implementation just a little bit easier. And every little bit of reduced friction helps.

If I had a magic wand, every image on the web would use responsive images syntax and use the best possible image format. But that’s not the reality. There are many websites that still only offer a single desktop-sized image that contains far too many pixels, and thus far too many megabytes, for a mobile device.

This is where ScientiaMobile’s background in device detection shines. ImageEngine not only recognizes nearly all devices, they also know the screen size of those devices. They can resize images for small screens based on that knowledge.

Is that resizing going to work as well as someone using responsive images syntax? Probably not. Could it make a mistake occasionally? Yes, but it will be rare.

So again, it isn’t the perfect solution, but it does make a big difference, and it does so with the minimal amount of effort.

And if you add one meta tag to support client hints like this:

<meta http-equiv="delegate-ch"
      content="sec-ch-width https://3r3r223r.cdn.imgeng.in; 
               sec-ch-viewport-width 3r3r223r.cdn.imgeng.in; 
               sec-ch-dpr 3r3r223r.cdn.imgeng.in; 
               ect 3r3r223r.cdn.imgeng.in;">Code language: HTML, XML (xml)

ImageEngine will use client hints in the browsers that support them. With client hints, any of the worries about device detection inaccuracy go away.

ImageEngine assumes you’re going to leave your images whereever they currently live. Nearly every image optimization service offers some version of a proxy as an option that can be turned on. But because this is all that ImageEngine does, it simplifies the setup and configuration of a new service.

Before I agreed to write anything about ImageEngine, I asked to try it. I installed it on a development server for our site. This site runs WordPress so I installed the ImageEngine plugin, and was presented with a form that only asked me for one thing: the ImageEngine domain for my account.

I figured once I set it up and turned ImageEngine on, there would be more to do. But there wasn’t. The settings screen stayed the same. I opened the advanced settings to peek at them and see if there was anything else to do. There wasn’t.

I didn’t change any of these settings. I cleared our server’s cache, and just like that, ImageEngine was serving up all of our images optimized from its CDN.

In fact, the ImageEngine plugin is so simple and flexible that ImageEngine refers to it as the “Image CDN” plugin. It isn’t ImageEngine specific. You can use it for any other service that you need to prefix image URLs.

Not every integration will be as easy as the WordPress plugin. Some content management systems will require updating templates. For developers, there is support for a variety of different languages. You’ll have to assess your own situation to see what the integration path will look like. But there’s a decent chance that you’ll find it possible to get that first pass of optimization out the door with less effort.

You don’t have to stop with ImageEngine’s default optimization. ImageEngine supports resizing images and modifying the optimization settings via URL parameters like other services do. Using these features allows a developer with more time to implement full responsive images syntax and get further optimization gains.

This comforts the responsive images advocate in me. I can see scenarios where getting a quick performance win with the default ImageEngine configuration could help some site owners. And then later when the developers have the time, they could go into their templates and add the markup necessary to support responsive images fully.

Don’t get me wrong. I’m not saying ImageEngine is the best at everything. They don’t have some of the advanced features that other systems do like AI capabilities or asset managers. There are inevitably going to be use cases for which ImageEngine isn’t the best fit.

But I think the idea that one image service is perfect for all scenarios is a fallacy. And I think the image optimization providers themselves know this. They know there are types of projects and customers that they are a better fit for than for others.

All I am saying is that ImageEngine is worth consideration. Don’t make the mistake I did and leave it off your list of options.

In the early days of mobile, I was a defender of device detection. I thought it was another tool in the toolbox, and if used well, there was no reason to avoid it even if we all have painful memories of websites stupidly using user agents strings to block non-preferred browsers.

Over time, my perspective changed. I still didn’t have any problem with device detection, but I came to believe that a solution’s default outputs mattered. It wasn’t that device detection was inherently bad. The problem was that it was too easy for smaller teams of developers to implement device detection poorly.

This is not too dissimilar to my perspective on React. Can you make React fast? Maybe, with enough time, money and expertise. Is that what most developers do? No. Going against the grain of a tool is difficult which is why I advocate for frameworks that are more performant by default.

Ironically, the reason why I avoided ImageEngine—my fear of device detection complexity—is the opposite of the reality. ImageEngine is simple by default. Much of that simplicity has to do with design choices and smart defaults. But at least some part of it comes from leveraging device detection to make smart guesses.

So I need to issue a mea culpa for ignoring ImageEngine, and in particular, for not suggesting it to our last clients last summer. I don’t know if ImageEngine will be right for your project. What I can say without hesitation is that you should check out it—especially in situations where you need a quick win on image optimization.