Cloudinary Blog

ImageCon 2018 Speaker Ryan Cooke, Pinterest on Delivering a Better Mobile Experience

Pinterest on Delivering a Better Mobile Experience: ImageCon 2018

For our first in a series of Q&A posts with our ImageCon 2018 speakers, we spoke with Ryan Cooke, a Software Engineer and Android Developer at Pinterest, a site that serves up billions of images everyday. In the following post he discusses why improving mobile images was important for improving the user experience and offers advice on building a mobile-first site.

Check back later this week for our next speaker post and follow all things ImageCon on Twitter at #ImageCon2018.

What were the issues that drove Pinterest to test different ways of delivering "better" mobile images?

As we expanded to international markets Android was becoming our most popular app, so we really started going above and beyond to improve its quality. One thing that stood out was when iOS users tried the Android app they immediately noticed the images looked worse, and they were right. Seeing as we serve billions of images everyday this seemed like an opportunity for improvement. We were able to be really laser-focused on how images could be better. Our first couple of changes really showed an improved user experience, so we were able to justify that image quality matters, and eventually we were able to take what we learned from Android back to other platforms.

What advice would you provide developers building a mobile-first site?

My personal take is to build as little from scratch as you can. Use the tried and tested patterns, third party libraries, etc. This will let you get moving fast and will likely give you an infrastructure that won't completely need to be rewritten. New hires may even be able to work with familiar tools. In regards to image loading specifically, I'd recommend using one of the existing third party client side tools (on Android: Picasso, Glide, Fresco; on iOS: PinRemoteImage) to handle the heavy lifting. If your app is really image heavy and you expect to be doing a lot of work on making the images the best they can be it may be worth adding a wrapper around the library so you can replace it with your own or another one as the need arises.

Are the lessons learned from your experience applicable to other sites and if so what would those be?

My biggest takeaway is that good image prefetching and caching makes a big impact on how the user sees your app. On a lot of apps it is very easy for a developer to already have the images ready for the user before the user would see them. Think of something like a movie ticket app, where they show the poster for the movie. There are like 20 images total the app will display at any time and it would be easy to have those loaded before I scroll to it, but they don't. The result is even on a high quality network I see the placeholder and then the content loading over the placeholder. The content changing will often draw my eye because it is motion, but it's probably not what the developer wants the user to be looking at. Overall it gives a subconscious feeling of a slow site and something not quite done. Our users at Pinterest still sometimes see placeholder images, but through clever prefetching they see them less and less.

Recent Blog Posts

Hipcamp Optimizes Images and Improves Page Load Times With Cloudinary

When creating a website that allows campers to discover great destinations, Hipcamp put a strong emphasis on featuring high-quality images that showcased the list of beautiful locations, regardless of whether users accessed the site on a desktop, tablet, or phone. Since 2015, Hipcamp has relied on Cloudinary’s image management solution to automate cropping and image optimization, enabling instant public delivery of photos, automatic tagging based on content recognition, and faster loading of webpages. In addition, Hipcamp was able to maintain the high standards it holds for the look and feel of its website.

Read more
New Image File Format: FUIF: Why Do We Need a New Image Format

In my last post, I introduced FUIF, a new, free, and universal image format I’ve created. In this post and other follow-up pieces, I will explain the why, what, and how of FUIF.

Even though JPEG is still the most widely-used image file format on the web, it has limitations, especially the subset of the format that has been implemented in browsers and that has, therefore, become the de facto standard. Because JPEG has a relatively verbose header, it cannot be used (at least not as is) for low-quality image placeholders (LQIP), for which you need a budget of a few hundred bytes. JPEG cannot encode alpha channels (transparency); it is restricted to 8 bits per channel; and its entropy coding is no longer state of the art. Also, JPEG is not fully “responsive by design.” There is no easy way to find a file’s truncation offsets and it is limited to a 1:8 downscale (the DC coefficients). If you want to use the same file for an 8K UHD display (7,680 pixels wide) and for a smart watch (320 pixels wide), 1:8 is not enough. And finally, JPEG does not work well with nonphotographic images and cannot do fully lossless compression.

Read more
 New Image File Format: FUIF:Lossy, Lossless, and Free

I've been working to create a new image format, which I'm calling FUIF, or Free Universal Image Format. That’s a rather pretentious name, I know. But I couldn’t call it the Free Lossy Image Format (FLIF) because that acronym is not available any more (see below) and FUIF can do lossless, too, so it wouldn’t be accurate either.

Read more