An Event Apart: Mobile First Responsive Design

by Luke Wroblewski May 11, 2014

At An Event Apart in San Diego CA 2014 Jason Grigsby walked through the importance of performance in multi-device designs and techniques for helping you achieve it . Here's my notes from his talk on Mobile First Responsive Design:

  • The Web has always been a balancing act of competing priorities: SEO, marketing, performance, and now device diversity. To manage diversity, many people are jumping into responsive web design solutions.
  • But can a one size fit all solution (like responsive web design) compete with a tailored solution (like separate mobile sites)? Do we need unique solutions for search engine optimization, context, advertising, and performance?
  • Studies show that people expect pages to load in two seconds or less. Slow Websites are the main reason people abandon e-commerce Websites. People expect things to load faster on mobile not longer.
  • If given the choice between optimizing for performance or optimizing for mobile design, performance should win out.
  • When early responsive designs came out, they were overly focused on layout design and not performance. Just looking at images, popular RWD implementations could save 80% of their file size on mobile.
  • An important part of the solution to RWD performance is mobile first responsive Web design. Yet looking at over a hundred responsive Web design, the majority were the same size on mobile as on the desktop. So most responsive sites are not being built mobile first. Instead a lot of responsive designs take desktop desktop sites and simply hide things using techniques like display: none.

Responsible Responsive Design

  • We've got a desktop design and we can't start over to make something responsive -it's a common refrain from companies. Starting with a mobile design process, though can reveal how the desktop experience can be improved. This is why mobile-first thinking is so powerful -even on existing desktop projects.
  • Responsive design for applications in inevitable.
  • 1: Build mobile first responsive designs.
  • Mobile first responsive designs is a technical approach to responsive designs. Start with a baseline mobile experience and enhance with a media query cascade that starts from small screens and adapts design as screens get bigger.
  • With this approach, older versions of IE will be served the simple mobile layout. To manage Internet Explorer, you can use IE conditional comments or include a polyfill that adds media query support to older versions of IE.
  • Mobile first design doesn’t mean starting from scratch. Its a useful process even if you have an existing desktop site. Start by asking what would the mobile version of this site or app look like? You’ll determine what priorities matter on key screens and flows. By the time you’re done, you’ll be likely to able to make the desktop version better based on what you learned designing for mobile.
  • 2: Keep CSS images in their place.
  • Images that are hidden using display:none are still downloaded by Web browsers.
  • To ensure images don’t get downloaded, scope them inside media queries. Set up media queries to isolate different images.
  • Setting display:none on a parent element does not download images. This doesn't get used that often because if there is part of the DOM you want to hide on different devices, you should ask if you need that part of the DOM at all.
  • Image overrides (baseline image gets replaced) in CSS media queries works most of the time. But not on Android 2 devices.
  • 3: Conditionally load Javascript based on capabilities
  • The Ajax Include pattern allows you to serve simple default elements to small screens and then enhance as screen size increases.
  • Hiding content with display:none does not prevent it from downloading.
  • Matchmedia() allows you to use Javascript to test whether a media query applies. Use this test to load the appropriate Javascript needed for a device.
  • Behavioral breakpoints: check to see if an element is present or not to apply Javascript. This allows your CSS to manage all your breakpoints & not duplicate breakpoints in Javascript and CSS.
  • 4: Deliver different sized images to different screen sizes.
  • This sounds easy but is really hard.
  • Our image tags only include one source attribute but there are two reasons we want to serve different sources: resolution switching and art direction.
  • Resolution switching: it doesn’t make sense to send the same resolution image to all screen sizes. We want different versions and sources so each device can load the most appropriate assets.
  • Art direction: resizing images only goes so far. We often want to crop images differently, adjust the placement of images and type, or display images at varying levels of detail.
  • Things are moving forward with a standards process for solving these responsive image use cases. The element seems to be the winner right now. Blink & Webkit are implementing it through a community effort. Mozilla has ddi they'll add and Microsoft has hinted they will as well. In the meantime, you can use the picturefill Javascript library to simulate the picture element or the hack of your choice.
  • SRCset and sizes present people with lots of options for delivering images.
  • 5: Handle high resolution images carefully. The difference between a Blackberry Curve image and a MacBook Pro Retina display is 1,433% percent bigger in file size. In memory that is 3,222% bigger. We need to be really careful with high resolution images.
  • If you use Javascript to swap out high resolution images, browsers are likely to download both the high resolution and standard resolution image.
  • Many e-commerce sites opt for performance and only serve up high resolution images on demand. This allows users to decide what images they want.
  • Compressive images is a technique that allows you to deliver high resolution photos without additional bandwidth but tread carefully as browser memory may be impacted negatively.
  • The image-set proposed spec allows the browser to make decisions about which image to serve based on screen capabilities and (hopefully soon) bandwidth considerations.

Image Solutions for the Web

  • What would an ideal image solution look like? Images are 60% of file size on Web pages so if we could solve them, we’d be doing good.
  • Use vector-based images or icon fonts wherever you can. The Filament group has a great resource on learning icon fonts. IcoMoon is a tool that can help you create custom icon fonts. Only use the characters you need in an icon font.
  • SVG may provide more bang for your buck over icon fonts.
  • Media queries can be used within SVG images. These media queries are dependent on the size of the image window not the screen. So an SVG image can be modified at several different sizes. This is very exciting.
  • Encourage people to upload the highest quality image possible.
  • Provide an automatic image resizing and compression service. Allow images to be resized to any size using URL parameters.
  • “Save for the Web” should be a thing of the past. Instead centralize the process in a service.
  • Provide a way to override resized images for art direction needs
  • Integrate image compression best practices
  • Bonus: detect support for WebP image format and use it. WebP files are 25%-34% smaller compared to JPEG file size.
  • Plan for the fact that whatever you implement will be depreciated. Make it easy to change as new solutions emerge for images on the Web.
  • Its unlikely a responsive design will ever be as fast as something specifically tailored for one device. Responsive design is about adapting to the unknown. If we do the extra work to make mobile first responsive designs fast, we can get the benefit of reaching many different devices with a performant solution.