For the first few years of my career I’d joke that I “type for a living.” That was selling myself short, though, I know—making websites is a complicated gig. It’s more accurate, I think, to say that I’m wrong for a living. I’ve been wrong about damn near everything about this job so far. I’m probably—no, definitely—wrong about plenty of things, as we speak.
I’m spectacular at job interviews, before anyone asks.
I should be more specific here: I’ve spent a good part of my career being wrong about matters of browsing context, but I don’t think I’m the only one. It hasn’t been all that long since the days of fixed-width websites, and the era of “looks best in Internet Explorer.” Back then, I was up to my neck in each of those industry-wide wrongnesses, sure that we were doing the right thing promoting the better browser and keeping apace with all the the hottest new CRT monitor sizes. It sure felt like I was right, at those times. It seemed like there were plenty of reasons to think so.
I’ve been wrong about context more recently than either of those—before web standards changed the way we think about browser support, and before responsive web design changed the way we think about our layouts. For a time—and with just as little realization of how wrong I was—I’d chosen a single familiar, comfortable context for the sites I’d build. I was building websites for my context: the browsing conditions that I was used to. I was doing my work on a fast computer and a high-speed internet connection—that’s what the web was, to me. I have the privilege of assuming high bandwidth and stable networks—I can assume that sending out a request will always result in something being sent back. But we can’t make assumptions about bandwidth that way, any more than we can make development decisions based on a cursory look around our offices, saying, “Everyone here has a pretty big display,” or, “Everyone here is using Firefox.”
I’m not the only one who made this mistake, either: not long ago, a full 72 percent of responsive websites were sending the same amount of data to mobile and desktop users, while only about six percent of responsive sites were taking significant steps in tailoring assets to mobile devices. Unfortunately, that last statistic doesn’t really track with reality: seventy one percent of mobile users expect websites to load almost as fast, or faster, than everywhere else.
The people building the web have it the easiest on the web, and perhaps as a result: the average web page is now more than 1.8 megabytes, with images alone accounting for a full megabyte of that.
That’s more than a case of us creating an minor inconvenience for ourselves. Building enormous websites means us shifting the burden of our mistakes onto every single user that visits our site. It’s us saying that we’re willing to build something that isn’t for some users, because that’s most comfortable for us—no different from “best viewed in Internet Explorer 5.5” or “best viewed at 600×800,” but much more costly.
That’s not what I want the web to be. That’s not what I want this job to be. The meaning I take from this gig doesn’t come from getting a div to show up in the right place—it comes from knowing that working just a little harder can mean that entire populations just setting foot on the web for the first time will be able to tap into the collected knowledge of the whole of mankind. That’s the philosophy that started the crusade for “responsive images.” Building massive, resource-heavy sites means excluding millions of users worldwide that have only ever known the web by way of feature phones or slightly better. These are users paying for every kilobyte they consume, already keeping tabs on which sites they need to avoid day-to-day because of the cost of visiting them, and not some nebulous hand-wavy “bandwidth cost” either—actual economic cost.
If every single one of you were convinced that this is a big deal, it still wouldn’t be enough—there are too few of us, and the steps to solve these problems in our daily work aren’t as clear-cut as they need to be. This is something I’ve wanted solved at the browser level for a long time now. I want a feature we could make a part of our everyday workflow—something we all just do as a matter of course, baked right into HTML5.
That solution is here, thanks to the efforts of developers like Eric Portis. In our latest issue, Eric’s “Responsive Images in Practice” forgoes the rocky history and web standards minutia involved in the search for a native “responsive images” solution and cuts right to what matters most: putting those solutions to use so we can build a better web for our users. Those users will never see any difference; they won’t care what combination of responsive image techniques we used or which use cases we needed to address. They’ll see images, same as they would before. What those users will notice is that the web feels faster.
Responsive web design is still pretty new, in the grand scheme of things. We’re all still getting the hang of it, myself included. There are plenty more things for us to be wrong about, I’m sure, but I’m excited to find them with you all. Because every time we discover we’ve been wrong about some matter of context on the web, we find a way to fix it together. And the web gets a little stronger, a little faster, and a little more inclusive as a result.
I’m going to join you, Mat, in admitting my wrongness in the area of responsive images. I had already skimmed Eric’s recent post that you mention. Now I better go back and read it more carefully. Thanks for a well-written article pointing out a huge blind spot in my practice — if not my thinking.
While I am fully on board with responsive images, I am starting to wonder if we’re looking to see the huge decrease in web page size that we had assumed would come. Recently I added support for responsive images to our slideshow script that was generating images for the desktop at 1200px in width. We generated many versions of the images at lower resolutions (potentially an overkill amount). I then checked it on my Galaxy S5 and saw that it loaded the original file! Doing the math it had made sense — 360px screen with a device pixel ratio of 3 would look for an image that was 1080px wide. This is larger than our 1024 image so it downloaded the next size up, which was the original at 1200 wide.
As new devices come out and device pixel ratios increase the potential savings we were hoping for with smaller images may go away. In fact, we may see web page size INCREASE as authors attempt to accommodate even more devices.
Frustratingly, this may require authors and CMS to go the route so that they can use art directives to generate versions of images in webp (or whatever the name of the JPG extension that Microsoft supports whose name eludes me is called) to reduce page load further. I support the art directive option, but I wish that it was really used JUST for a different type of image all together, which an image in a new file extension really isn’t IMHO.
Both links in the fifth paragraph are broken. Cheers.
@Pi E Rs, thanks for the heads up—and sorry about that! They’re fixed now.
I really enjoyed your response to this powrsurg. It got me thinking more in depth then the original article about how those new sizes would be used. At first I was a bit disheartened by the results you described, but it’s actually quite wonderful. Let me explain a bit of why:
When we provide the browser with the option of sizes and let it decide, we get a better experience for the end user. I can already imagine mobile browsers having a built in control, or perhaps just a preference, that prefers full resolution images while on WIFI, using a minimal size approach otherwise. A browser would also know the speed of a connection better than we could estimate, so there could be conditional switching of the asset downloaded for poor connections as well. That’s just two easy targets, I have to think the device and browser creators will find others as well.
Great article! So, you’ve made a lot of points here but I can’t tell if you’re advocating for smaller web sites across the board or separate content for Web and mobile. I understand the end point is that responsive images mean you don’t have to choose, but you still kind of do.
So if your call is for smaller web sites: agreed! Web sites have long been bloated for the exact reasons you mention: “Hey it looks great in Chrome on my top-of-the-line late model Mac, who cares about IE7?”
If your call is for separate content: no way. Most users browsing Web sites from mobile are doing so in their spare time (like, waiting a latte or for the Uber driver to find them) and you should not punish them unnecessarily for viewing your site(s) from a mobile device.
Everything that’s available from the Web should be available from mobile, even if that means we as Web developers have to work a little bit harder to make that happen. Perhaps we agree 100%.
Some very good points here and will apply yo animation and interactive content too – something we (and companies like us) must consider for optimizing the output from our software.
But it works both ways. I’ve recently visited two big brand media sites recently where the images were so big and unresponsive it was uncomfortable to view on a desktop. IMO there is a real danger we’ll turn websites into large print picture books and punish desktop visitors who have to scroll and click a lot to find any real content or have massive images and video.
I have to wonder if ultimately the solution will be different sub-sites for different devices.
@powrsurg Galaxy S5 is a newer device running a newer OS. It is not the cheap android device that most data limited pay you go plans supply. Moreover, Android support WebP, and the picture element supports targeting image type support. You can also target high density displays with the picture element also, which would allow you to create a large version with much higher compression/lower quality and get smaller files with better image viewing quality for smaller devices.
Responsive images is solving a problem, and browser makers and phone makers are aware of the issue. They will adapt to standards, but it will take time.
@Lance Gliser, I hear what you’re saying, but connection type is likely not to be the optimal solution. Wi-Fi can be strong or weak (in fact, I have NEVER experienced a Wi-Fi connection that beat a 4G LTE connection, but others may have different experiences). A 4G connection may be spotty depending on location. Heck, even periodic polling could be problematic for users browsing the web while on a train. I think it’ll take longer for vendors to find a solution to when they should download larger/smaller quality than it took them to come up with a solution to responsive images.
@J A Streich, I am aware that the S5 is a more powerful device, and I understand the benefits of the picture elements and responsive images in general. My only qualm is that websites may not see the reduction in file size transferred that they were expecting. They will see in certain situations, but it won’t be across the board. It took me a while to realize that my setup was doing the right thing during testing as I thought I broke something when I got the first image back. With 4K and 5K devices coming out we might see our page size increase as we try to accommodate those devices.
Good explain ! But you also can read my post about meaning of image in webpages
Good expamles but, to apply for the private design websites is harder to entering which design websites vip developments like us, look from http://www.medyator.net
Responsiveness is a whole new era in web design, I agree with you. It has already changed a few major design elements, like pictures, text, layout, etc and also it has changed the way we perceive websites and the web in general. Responsive websites are the only future of the web, not mobile and desktop versions separately. And it’s time for big changes: big brand websites are getting redesigned along with small biz sites, emails are now almost useless if not responsive. Finally website building tools don’t have a choice – they need to be responsive to meet their customers’ expectations. That is why MotoCMS is now getting responsive, and many more other web design and development companies are doing the same.
Great post, I definitely agree with the sentiment.