- Whats the problem?
- Selectively serving images to mobile
- Responsive image strategies
- Responsive image options
- Background images
- High-resolution displays
- Other fixed-width assets
- Wrapping it up
This chapter is from the book
This chapter is from the book
This chapter is from the book
Selectively serving images to mobile
Let’s start by removing the images in the “More in Football” section from the core experience. It might be tempting to just use display:none and call it a day, but that doesn’t fix the problem, it only hides it.
An image set to display:none will still be requested and downloaded by the browser. So while the image won’t show up on the screen, the issue of the extra request and weight is still there. Instead, as usual, the correct approach is to start with mobile first and then progressively enhance the experience.
Begin by removing the images from the HTML entirely:
1.<ul class="slats">2.<li class="group">3.<a href="#">4.<h3>Kicker connects on record 13 field goals</h3>5.</a>6.</li>7.<li class="group">8.<a href="#">9.<h3>Your favorite team loses to that team no one likes</h3>10.</a>11.</li>12.<li class="group">13.<a href="#">14.<h3>The Scarecrows Win 42-0</h3>15.</a>16.</li>17.</ul>
Obviously, the images will not load with this HTML. On the small-screen display, that’s the way it’ll stay. For the larger sizes, a little JavaScript will bring the images back. Using the HTML5 data-* attributes as hooks, it’s easy to tell the JavaScript which images to load:
1.<ul class="slats">2.<lidata-src="images/ball.jpg"class="group">3.<a href="#">4.<h3>Kicker connects on record 13 field goals</h3>5.</a>6.</li>7.<lidata-src="images/goal_post.jpg"class="group">8.<a href="#">9.<h3>Your favorite team loses to that team no one likes</h3>10.</a>11.</li>12.<lidata-src="images/ball_field.jpg"class="group">13.<a href="#">14.<h3>The Scarecrows Win 42-0</h3>15.</a>16.</li>17.</ul>
JavaScript
The first thing to add is a quick utility function to help select elements. It’s not necessary, but it’s definitely useful to have around:
1.q : function(query) {2.if (document.querySelectorAll) {3.var res = document.querySelectorAll(query);4.} else {5.var d = document,6.a = d.styleSheets[0] || d.createStyleSheet();7.a.addRule(query,'f:b');8.for(var l=d.all,b=0,c=[],f=l.length;b<f;b++) {9.l[b].currentStyle.f && c.push(l[b]);10.a.removeRule(0);11.var res = c;12.}13.return res;14.}15.}
If you’re unfamiliar with native JavaScript, that might look a bit messy. That’s OK. All the function does is take a selector, and return the elements that match it. If you can grasp the code, that’s great. If not, as long as you understand what it accomplishes, that’s enough for our purposes.
Armed with that function, the part that actually loads the images is pretty straightforward:
1.//load in the images2.var lazy = Utils.q('[data-src]');3.for (var i = 0; i < lazy.length; i++) {4.var source = lazy[i].getAttribute('data-src');5.//create the image6.var img = new Image();7.img.src = source;8.//insert it inside of the link9.lazy[i].insertBefore(img, lazy[i].firstChild);10.};
Line 2 grabs any elements with a data-src attribute applied. Then, in line 3 the script loops through those elements. In lines 4–7, the script creates a new image for each element using the value of the data-src attribute. The script then inserts the new image (line 9) as the first element within the link.
With this JavaScript applied, the images aren’t requested right away. Instead, they’re loaded after the page has finished loading, which is what we want. Now, we just have to tell the script not to load for small screens.
Guy Podjarny
Performance Implications of Responsive Design
Guy Podjarny, or Guypo for short, is a web performance researcher and evangelist, constantly chasing the elusive instant web. He focuses heavily on mobile web performance, and regularly digs into the guts of mobile browsers. He is also the author of Mobitest, a free mobile measurement tool, and contributes to various open source tools. Guypo was previously the co-founder and CTO of Blaze.io, later acquired by Akamai, where he now works as a Chief Product Architect.
Responsive Web Design (RWD) tackles many problems, and it’s easy to get lost in questions around how maintainable, future-friendly, or cool your responsive website will be. In the midst of all of these, it’s important to not lose sight of how fast will it be. Performance is a critical component in your user’s experience, and many case studies demonstrate how it affects your users’ satisfaction and your bottom line.
Today, smartphone browsers are often redirected to dedicated mobile websites, known as mdot sites, which tend to be significantly lighter in content and visuals than their desktop counterparts. This translates to having fewer images, scripts and stylesheets to download, which helps make those websites faster. The equation is simple—downloading fewer bytes with fewer requests is faster than having more of both.
Responsive websites, however, don’t follow this pattern. I recently ran a performance test on 347 responsive websites (All the websites listed on http://mediaqueri.es/ in March, 2012). I loaded the homepage of each in a Google Chrome browser window resized to 4 different sizes, ranging from 320x480 to 1600x1200. Each page was loaded multiple times using www.webpagetest.org, a web performance measurement tool.
The results were depressing. Despite changing their look across window sizes, the weight and load time of the website hardly changed. 86% of the websites weighed roughly the same when loaded in the smallest window, compared to the largest one. In other words, despite the fact the websites look like an mdot site when loaded on a small screen, they are still downloading the full website content, and are thus painfully slow.
While every website is different, three causes for this over-downloading repeated across practically all websites.
- Download and Hide
- Download and Shrink
- Excess DOM
Download and Hide is by far the top reason for this bloat. Responsive websites usually return a single HTML to any client. Even on “Mobile First” websites, this HTML contains or references all that’s needed to provide the richest experience on the biggest display. On a smaller screen, sections that shouldn’t be shown are hidden using the display:none style rule.
Unfortunately, display:none doesn’t help performance one bit, and resources referenced in a hidden part of the page are downloaded just the same. Scripts within hidden sections still run. DOM elements are still created. As a result, even when hiding the majority of your page’s content, the browser will still evaluate the page in resources and download all the resources it can find.
Download and Shrink is a conceptually similar problem. RWD uses fluid images to better match the different screen sizes. While visually appealing, this means the desktop-grade image is downloaded every time, even when loaded on a much smaller screen. Users cannot appreciate the high quality image on the smaller screen, making the excess bytes a complete waste.
Excess DOM is the third episode of the same story. RWD websites return the same HTML to all clients. Browsers parse and process hidden areas of the DOM despite being hidden. As a result, loading a responsive website on a small screen results in a DOM that is far more complicated than what the user experience demands. A more complicated DOM leads to higher memory consumption, expensive reflows, and a generally slower website.
These problems are not simple to solve, since they’re the result of how RWD and browsers work today. However, there are a few practices that can help you keep your performance under control:
- Use Responsive Images
- Build Mobile First
- Measure
Responsive Images are already discussed in this book at length, and help address the “Download and Shrink” problem. Since images are the bulk of the bytes on each page, this is the easiest way to significantly reduce your page’s weight. Note that CSS images should be responsive as well, and can be replaced using media queries.
Build Mobile First means going a step beyond designing a Mobile First website, and actually coding a dedicated website for the lowest resolution you care about. Once implemented, this website should perform as well as other mdot sites, and be reasonably lightweight. From that point on, only enhance the page using JavaScript or CSS, to avoid over-downloading. Clients that have no JavaScript support will get your basic experience, which should be good enough for these edge cases. Note that enhancing with JavaScript and keeping performance high isn’t simple, and best practices for it are not fully established yet—which brings me to my next point.
Measure. Treat performance as a core part of your website’s quality, and don’t ship without understanding and accepting its performance. If you know your mobile website weighs over 1 MB, you’re likely to delay its launch until you do something about it. Measurement tools vary, but I would recommend Mobitest for testing on real devices (http://akamai.com/mobitest) and WebPageTest for testing on desktop browsers (www.webpagetest.org), resized them using the setviewportsize command.
In summary, Responsive Web Design is a powerful and forward thinking technique, but it also carries with it significant performance implications. Make sure you understand these challenges and design to avoid them, so that users won’t abandon your website before they got to experience your amazing visuals and content.
Introducing matchMedia
In Chapter 3, “Media Queries,” the script we built to toggle the display of the navigation on small screens checked to see if the list items in the navigation were floated. If they were, the collapse feature was created. This time, let’s use the handy matchMedia() method.
The matchMedia() method is a native JavaScript method that lets you pass in a CSS media query and receive information about whether or not the media query is a match.
To be specific, the function returns a MediaQueryList object. That object has two properties: matches and media. The matches property returns either true (if the media query matches) or false (if it doesn’t). The media property returns the media query you just passed in. For example, the media property for window.matchMedia("(min-width: 200px)") would return "(min-width: 200px)".
matchMedia() is supported natively by Chrome, Safari 5.1+, Firefox 9, Android 3+, and iOS5+. Paul Irish has created a handy polyfill for browsers that don’t support the method.
With the matchMedia polyfill in place, telling the browser to insert only the images above the first breakpoint simply requires wrapping the code inside a matchMedia check:
1.if (window.matchMedia("(min-width: 37.5em)").matches) {2.//load in the images3.var lazy = Utils.q('[data-src]');4.for (var i = 0; i < lazy.length; i++) {5.var source = lazy[i].getAttribute('data-src');6.//create the image7.var img = new Image();8.img.src = source;9.//insert it inside of the link10.lazy[i].insertBefore(img, lazy[i].firstChild);11.};12.}
Now when the page is loaded on a phone, or the screen is sized down, the images are no longer requested (Figure 4.3). This is a big win for performance on small screens. There are now three fewer HTTP requests, and the size of the page has been reduced by about 60KB (the size of those three images combined). Best of all, the headlines are still there and the links are completely functional. The experience doesn’t suffer at all.
)
Figure 4.3. On small screens, the images in the “More in Football” section won’t be requested, greatly improving the performance of the page.
With those images out of the way, we can focus on the lead-in image and the logo. We want those images, the logo in particular, to show up no matter the resolution. So, instead of conditionally loading them, we’ll load them every time, but sized appropriately. This is where things get hairy.