The Responsive Image Challenge – Part 1

ej

Images on the web used to be pretty simple. Upload your image to a server, throw the URL into an HTML <img> tag, and then it would appear on your page. No big deal.

However, a lot has changed in the last two years.

In 2007, Apple released the first-generation iPhone. The iPhone was the first smartphone that appealed to the average person. And, as we all know, it was a huge success and now all the major smartphone manufacturers are taking the same approach.

Overall, smartphones are great. You have instant access to the Internet, GPS navigation, calling, and texting all from a little device that you carry with you. For website maintainers, however, smartphones and the many devices they’ve spawned present some serious problems.

Problem #1 – Mobile connections are slow

While mobile speeds are a ton faster than they used to be, they’re still pretty slow compared to a traditional connection, especially outside of a big city.

So why is this a problem?

Well, compared to text and HTML code, images are really big. In fact, the text, html, CSS, and Javascript from www.bethel.edu is about 10% of the total page size. The other 90% is mostly images.

All that to say, text loads really fast, images load really slow. You can have an entire essay that’s smaller than a single image. On a desktop connection, not the biggest deal. However, this can make a huge difference on a slow mobile connection.

The simple solution: Make images as small as possible. Easy, right?

Not so fast.

Problem #2 – Retina

In 2010, Apple coined the term “Retina display.” In reality, this is just a screen with a ton more pixels than normal and an operating system that can still make everything look good. This is amazing for text and icons. Everything is smoother and overall better to view. So what is the downside? Well, images of course.

If anybody happens to be reading this on a Retina laptop, you might have noticed images look really bad on some websites. Why is this? Well, if you double the pixels of your display, but don’t double your image size, the images will have to expand to fill in the extra area. This causes blurry images all over your websites.

On a desktop, you can just serve an image twice as big. Not a huge deal. But what about mobile?

Retina screens are actually more popular on mobile than laptops because you actually hold those devices close enough to notice the difference. The catch-22 is that if we make our images look good, they are twice as big, and therefore take twice as long to load. If you compress them too much, the image quality will deteriorate. So we are dealing with the worst of both worlds—slower load speed with larger images. And even if connection speed wasn’t an issue, there is one more thing to consider…

Problem #3 – “Just make a bigger copy”

Pretty easy to say, but extremely hard to do.

If your source image is 300×300 but needs to be 600×600 for your Retina device, you can’t exactly just expand the 300×300 copy to be twice as big. It will look just as bad as if you served the 300×300 copy to begin with.

This relates to our first rule of images: “Always upload the largest copy possible.” Technically, we could serve this image all the time, and the let the phone or computer shrink it to the correct size. But these images are huge. At 3-5 megabytes a pieces, using this method would make our homepage close to 20 MB’s—a 2000% increase of our current page size.

So we need to resize it. But now the problem is that resizing and compressing images takes time. And time is very valuable when serving to a mobile connection. This creates a second rule:  ”Have your resized images ready to go before they’re needed.” Okay…so we need to have a different image size ready for every single width and height we’ll need to serve.

Great. And since we’re trying to speed things up, we’re going to need to make sure we only serve the exact size needed for the page. This ensures we’re loading as little data as possible. That is, if an image is only going to take up 100 pixels on the page, we don’t want to make someone load a 600-width version of the image. This is in line with our final rule, “don’t serve a bigger image than you need.”

Putting all those rules together shows how big of a problem this can be.

Before, we had one single image in an HTML tag. Now we have 10-20+ versions of the exact same image needed for a single webpage. After all, there are so many different phones, phablets, tablets, laptops, desktops, etc., that all need something different. That’s a lot of overhead.

We’ve spent a long time trying to create a solution that is fast, responsive, and extremely easy to use. And we think we’ve come up with something that, for our web authors, will be as easy as it was pre-2007 when we all we had was one image inside some HTML. Just put your image on the page, and leave the rest to us.

So how do we solve this? Check back next week for The Responsive Image Challenge – Part 2.