Dianoga 3.0 is released

I’m happy to announce the release of Dianoga 3.0. This release brings significant improvements compared to previous releases, and is recommended for existing users.

What’s Dianoga?

Dianoga is a tool that optimizes images uploaded to the Sitecore media library to save bandwidth and improve page loading times as a result.

s also the monster that lives in the Star Wars trash compactor. What?

Dianoga ensures that your site is always serving fully optimised media library images even if you are using Sitecore’s dynamic resizing features (for example with Adaptive Images). Even if you have already optimized every image uploaded into the media library, after Sitecore performs image processing the result is not optimized (an unfortunate limitation of other image optimization libraries for Sitecore is that they only apply to the original image).

Dianoga is also great for situations where content editors may not be image editing experts and upload images that contain gobs of EXIF data and other nonessential metadata - these are removed automatically before being shown to visitors. All of the optimizations done are lossless (no quantizing, etc) so you lose no image quality.

What’s new in 3.0?

SVG support

With the rise of SVG as a common format for media library media, it became apparent Dianoga needed to support optimizing SVG. Dianoga 3 includes SVG optimization!

SVG media is automatically:

  • Optimized for size (the SVG is processed using SVGO)
  • Gzipped before going in the media cache, and served using the cached gzipped version (reduces size over the wire)
  • Apropos configuration to enable SVG support in media library on Sitecore < 8.1 is enabled by default (thanks to Kamruz Jaman and Anders Laub for the blogs e.g. this and this)

Optimization strategies

Dianoga 1.x used a synchronous optimization technique that resulted in a slower initial image load time, but always served optimized images. Dianoga 2.x instead relied on an asynchronous technique where the first media served would be unoptimized and subsequent hits were optimized, but the response time was never impacted.

It became apparent that both of these strategies have their place, for example you need to be synchronous when uploading to a CDN, and so Dianoga 3 supports optimization strategies that let you choose when to optimize. If you don’t like any of the strategies or want to optimize only when sending media to a CDN programmatically, you can also invoke the optimization pipeline directly to optimize precisely when you need to (the MediaOptimizer class is what you’re after here).

Pipeline-based optimization

Dianoga is now powered by Sitecore pipelines, providing simple and flexible extension options. The root <dianogaOptimize> pipeline runs for all optimizations, and spins off into <dianogaOptimizeJpeg> and other similar sub-pipelines for individual file types.

Optimizer chaining

With Dianoga 2, you could not simply apply more than one optimizer to a file format. For example, you might wish to quantize a PNG (which is lossy), and then also optimize its encoding after quantization to further reduce file size. This is very simple with Dianoga 3 - now each optimizer is just a step in a pipeline. Add or remove optimizers as you wish.

Media path exclusion

Got a folder of huge photos you don’t want optimized because they should be kept pristine for downloads? Have another reason you want to not optimize specific parts of the media library? Great - Dianoga 3 now supports that.

Because optimization is pipeline based, this just takes the form of a processor that aborts optimization when the input is to be ignored. See Dianoga.ExcludePaths.config.example which ships with the NuGet package for how to use this.

Framework version requirements

Dianoga 3 requires .NET 4.5.2 or later to be the target framework of the project it is referenced in. This provides compatibility with Sitecore 8.2. Dianoga 3 requires Sitecore 7.x or later.

Bugs and fixes

  • Asynchronous optimization has been significantly simplified and reliability improved compared to Dianoga 2. File in use issues should be completely eliminated.
  • Unit tests have been added to the codebase (I blame Dan Solovay)
  • Optimization tools are moved to App_Data so that IIS will never consider serving their files (as opposed to /Dianoga Tools in 2.x and earlier)
  • Optimization tools have been updated:
    • libjpeg is now mozjpeg, which results in better optimization for the web specifically
    • SVGO has been added to optimize SVGs
    • PNG optimization remains unchanged using PNGOptimizer, other than now being chainable with the PNGQuant lossy quantizer.

Installing

Dianoga is available from NuGet. You must be using packages.config (NuGet 2.x style) package management for Dianoga, because it installs content items to the project. If you wish to use project.json (NuGet 3.x style), you must manually install the tools and configuration files because of limitations in NuGet 3.x.

Upgrading

Easy. Make sure your host project is targeting .NET 4.5.2 (or later - I use it with 4.6.x), and then upgrade your NuGet package.

Have fun!

Transparent media optimization with Dianoga 2

I’ve pushed a significant update to Dianoga, my framework to transparently optimize the size of media library images, including rescaled sizes.

My original post on Dianoga 1.0 explains why you’d want to use it in detail, but as an overview how does saving 5-40% overall on image bandwidth sound? All you have to do is install a NuGet package that adds one dll and one config file to your solution. That’s it. You can also find documentation on GitHub.

What’s new in 2.0

Dianoga 2 is faster and more extensible. The key change is that media is now optimized asynchronously, resulting in a near-zero impact on site performance even for the first hit. Dianoga 1.0 ran its optimization in the getMediaStream pipeline, which meant it had to complete the optimization while the browser was waiting for the image. For a large header banner, this could be a couple seconds on slower hardware (for the first hit only). Dianoga 2 replaces the MediaCache and performs asynchronous optimization after the image has been cached. This does mean that the first hit receives unoptimized images, but subsequent requests after the cache has been optimized get the smaller version.

Extensibility has also been improved in Dianoga 2. Previously, there were a lot of hard-coded things such as the path to the optimization tools and the optimizers themselves. Now you can add and remove optimizers in the config (including adding your own, if you wanted say a PNG quantizer), and move the tools around if desired.

There was a bug in Dianoga 1.0 that resulted in the tools DLL becoming locked, which could cause problems with deployment tools. This has been fixed in 2.0 by dynamically loading and unloading at need. Thanks to Markus Ullmark for the issue report.

Upgrade

Upgrading from Dianoga 1.0 to 2.0 is fairly simple; upgrade the NuGet package. You can choose to overwrite your Dianoga.config file (recommended), or merge it with the latest in GitHub if you don’t want to.

Have fun!

Automatic Sitecore image optimization with Dianoga

Have you ever run Google PageSpeed or WebPagetest against a Sitecore site and been disappointed with the unoptimized images coming from your Sitecore media library? When I did, I was seeing claims that I could reduce the size of many of my images by 10-30%, simply by removing unnecessary image data and optimizing the image encoding. The tools to accomplish image optimization, such as jpegtran or PNGOptimizer, operate in a lossless fashion - in other words, your images lose zero fidelity but become smaller. On a big website, any reduction in data transfer is a big cost savings on bandwidth as well as a UX improvement due to improved load times.

With this in mind I set out to make a tool to automatically optimize the output of the Sitecore media library, and Dianoga was born. Dianoga sits in the trash compactor getMediaStream pipeline, which Sitecore uses to transform media items before it writes them to its disk cache. When an image gets processed, we complete the processing by transparently optimizing it before it goes in the cache. No changes are ever made to the actual media item in the database, and you never have to explicitly request optimization.

There are some other image optimization modules out there for Sitecore, so how is this one different? First, this one is automatic (no clicking a button in the content editor, or forgetting to). Second, this one optimizes as the media is served to the client, which means that if you’re using Sitecore’s image resizing functionality (which is perfect for modern responsive techniques like srcset and Adaptive Images without tons of work) each size of the image is individually optimized - which is important because the act of resizing the image deoptimizes it.

Sound like fun? Free bandwidth savings for no work other than a really difficult installation process? Just kidding - installation is as simple as a zero-configuration NuGet package that doesn’t even touch your Sitecore databases. You might want to delete App_Data/MediaCache after install so that media is recached with optimizations, but that’s all there is to it.

Find Dianoga on NuGet (Sitecore 7+), or you can get the source from GitHub (source works for Sitecore 6.x). There is also a readme on GitHub with additional details about logging, troubleshooting, and such.