Dynamic Sample Content
In part 3b, we clone this article so we have some more sample content. It's the same!
Bandwidth is a commodity: we don't earn a profit off of overages. We pass that cost right on to the customer — but leave behind frustration when they don't know how to fix it.
Customers often come to us with bandwidth and speed problems; in many cases, they just need guidance and education on how to get the most out of the Images API.
In the first scenario, we were able to lower a customer's bandwidth by nearly 10x with some simple code changes.
Scenario One: Massive Bandwidth Overages
A customer in the fitness industry had many large image assets that are being delivered, unoptimized, to their end users. I ran a one-hour workshop to teach them how to get the most out of their images by compressing and sizing them for massive bandwidth reductions.
The source for their images was generally screenshots of videos, which they said were created on Adobe tools. This could mean Premiere Pro or AfterEffects—both tools have frame grab export that they’re not using it seems, because the images were scaled up incorrectly.
We looked at a few examples, which have a mix of video and text. In examples like this, some images were over 5mb in native size (with some as high as 60mb! Their upstream workflow was essentially unregulated). By adding some Images API attributes that were more appropriate to their use case (thumbnails in a list), we got the images down to 45k; this represents a 98% reduction in one case. This should substantially reduce their bandwidth overages as well as increase loading time and app responsiveness.
Understanding Chroma Channel Compression
JPG compression leans heavily on compressing some colors more than others—typically reds and oranges. The reasons for this have to do with how humans perceive images. In the examples they provided, the orange type will break down more than the photo content will, like the above example with ?fm=jpg&w=640&q=20.
Other Details
I also showed them ImageOptim which they can use to optimize PNG and JPG images losslessly before uploading to contentful, which would help in their particular case (of mixed photo and graphic content as a PNG).
We discussed using WebP briefly, but they’d need to be educated on that and evaluate their delivery platforms first for compatibility.
Another use case that came up briefly was motion previews—I explained that video clips are best for that, and not GIF files as they are quite inefficient.
Scenario Two: Finding the best settings
A frustrated customer reached out to our support team:
We tried different resolutions, different formats and different pixel density images but always after resizing, the image looks a little bit blurry.
We want to know what are the optimal source image requirements (like resolution, pixel density, format etc.) with which we will be able to achieve a better quality image after resizing (mostly shrinking) using the Contentful images API.
I wrote up some notes for our support team to pass on:
Image compression is both art and science. It’s a balancing of the two, as the customer discovered when trying to compress their image without making it blurry. Make sure the customer understands the basics, and builds from there. Here are a few helpful resources:
Be sure they can find the Images API docs.
Watch the Contentful DevRel Live Code video episode on the Images API, where we tune images live on 11ty.
Here’s a blog post on the various aspects of the Images API.
Here’s a longer podcast episode and transcript based off that article, where we get into some of the deeper questions around image compression.
They need to be sure they are actually presenting the image (assuming this is web) and 2x the density of the actual pixels (this is a rule of thumb, there’s 3x use cases etc.) So their image that’s delivered at say, 800px wide (w=800) needs to be presented in the markup at half that, so 400px wide. This is fundamental to “retina” or HiDPI image delivery. For web delivery, this is a combination of markup (HTML) and CSS. Imgix has a great tutorial on the subject; have them read this.
When I render their image at full size (800px) and shrink it to 400px, it looks pretty crisp:
Image sizing (display size) is a separate issue from compression.
When I convert this same image to JPG on the fly (?w=800&fm=jpg&q=30 ) it’s down to 28k, woo! Oh wait it looks horrible, waaat?
The reason is twofold:
Fine lines (type)
saturated color areas
JPG is old (but not as old as me!), which means it’s kind of dumb about what’s called chroma sampling. I touch on this in my podcast. Basically when the algorithm is looking to Marie Kondo your image, it grabs the color information first because usually our eyes don’t notice. Here, we do.
The same settings, but using WebP (a newer format, see the articles, fm=webp) are way smarter about color sampling.
?w=800&fm=webp&q=70 looks pretty amazing, and only 25k. Note that I had to jack up the Q to 70 because of the nature of the image: fine lines and saturated color.
There’s rarely one-size-fits-all on compression. You can tell them to never set q=100, that’s just violence to the end-users’ bandwidth. Customer should also learn about lazy loading strategies to offset larger images when needed.
Bottom line, the customer should:
Understand the tech & RTFM
Experiment with the settings to find the right balance of size and quality
Run your own performance workshop
Once you know how to evaluate a customer website, run performance tests, and understand what their performance goals and bandwidth budgets are, you can help customers lower their bandwidth bills, increase their satisfaction, and improve retention on Contentful — improving the odds for future expansion opportunities because we solved their problem.
