How we Pictured TwicPics

Back in 2010, Ethan Marcotte talked for the first time about what he aptly branded the “Responsive Web Design strategy”. As images quickly became the main issue in said designs, Ethan introduced the notion of “fluid images” as a potential solution a mere year later.

The idea behind “fluid images” is to let CSS engines resize hi-res images themselves. While visually satisfying, this approach has two major drawbacks:

• dismal performance: it’s an hi-res image being downloaded, taking that much bandwidth and slowing down the webpage accordingly.

• no art direction: you have to deal with the aspect-ratio and ROI of the high-res image as-is, no matter the orientation of the device.

In 2013, Responsive Images Community Group issued a note listing Responsive Images specifications being worked on. Of particular interest were the srcset attribute and the picture element. Five years later, those two add-ons have been integrated into the HTML standards and are now supported by all recent browsers.

Use-case: Pictures Gallery

Let’s start with the ubiquitous picture gallery : think product listing, virtual tour, contact roster, you name it.

Also let’s assume we wish to deliver a state of the art experience : what are our constraints?

• Images should be delivered at the exact size they’re displayed : no more hi-res master image. Save the bandwidth, shorten the loading time.

• Images should be delivered at the correct aspect ratio for each layout (Art direction). For instance 4:3 for desktops, square on tablets and 16:9 on smartphones.

• Pixel density (DPR) should be handled (retina, amoled, etc).

• Images should use the best format possible. For instance, use WebP instead of JPEG when supported by the browser (73% globally).

• Have a placeholder strategy with lazy-loading to save bandwidth early and improve the initial page load time (and thus user experience).

Let’s bring our specifications to life using a flexbox grid with responsive images:

With the new HTML standards, integrating responsive images is perfectly feasible. Yet using them dramatically increases the number of images to generate and manage beforehand. It also increases code complexity by an order of magnitude.

Back in the good old non-responsive days, an image was represented by a single line of HTML and a single url. Sadly, when it comes to a *responsive *image, we multiply the lines of code and image variants.

In this simple example, we had to produce 70 lines of code and 36 variants per image. Which means that your ecommerce site with 4 breakpoints and 1000 products would require 36,000 images and 5MB of HTML!

Don’t think I blame the RICG members for a second. They have done a great job bringing fundamental and much needed features to the platform. Sadly, the hassle of handling responsive images is not limited to the HTML platform, it goes far deeper than the sole front-end layer.

As we see an exponential growth in the number of image variants required for a responsive site, a very large management overhead ensues (back-end scripts, naming conventions, variants generation, storage, etc) not to mention dedicated delivery strategies that have to be implemented (HTTP2, CDN, caching policy, etc).

In such a coupled environment, a small change in the front-end design can cascade into large scale variants re-generation, multiple cache invalidations and more.

Faced with this type of complexity, developers tend to settle for what they deem an acceptable compromise between quality and performance.

Experts agree that images are still the number one cause of bloat on the web and countless studies have shown that page views, customer satisfaction and conversions are constrained by web performance.

A compromise will not cut it.

Xavier, Julian and I kept banging our heads against the walls with this very issue. We scouted for services that would alleviate the pain but none of them addressed the problem the way we wanted.

To us, such a service had:

• to handle the server-side part automagically (ideal compression, optimal caching policy, fast processing, fast delivery),

• to integrate transparently into our front-end workflow and respect web standards,

• to not mess with our storage strategy.

These three primary requirements in mind, we started working on our very own service two years ago. Today, it’s live and its name is TwicPics.

TwicPics offers Responsive Images as a Service. It provides on-demand responsive image generation combined with a smart and unobtrusive JavaScript library, all based around a no-nonsense, testable, URL-based API.

In other words, it solves all image problems and puts an end to the compromise:

Let’s go back to our gallery use-case and take a look at the same result with TwicPics:

• 1 image (the master)

• 1 line of code per image

• Pixel perfect on every devices

• No complex plumbing

• Best practices by default (lazy loading, caching policy, fast delivery, ideal compression, etc.)

As you can see, with TwicPics, developers always use the biggest, most detailed version of the image and everything is handled automatically. The end-user never sees the original image. Instead, an optimized, perfectly sized, device-adapted image is delivered from a server close to him. From top to bottom, TwicPics helps you deliver lighter, faster images at the highest visual quality.

Join us! You’ll get 3GB totally free to witness how easily responsive images can be handled.