In his talk at Smashing Conf in Freiburg Germany 2013 Andy Hume talked about what he learned working on a large scale responsive design at The Guardian. Here's my notes from his talk Real Life Responsive Design:
- Print circulation is dropping while mobile visitors are skyrocketing. This presented a big opportunity for the Guardian.
- The initial goal was to build a new mobile Web site to replace the existing one. But is there really a clear definition of what mobile is today? The long term goal was to replace the existing desktop site and provide a more future friendly approach to all other device.
- The Guardian has a central content store where writers and editors use in house tools to write content into the store. There is also a Read API which is used to create native applications and Web experiences. Applications get built on top of the API -so they can be created quickly.
- Mobile first, Performance, Resilience were key to the success of the Guardian project.
Mobile First
- The Guardian started from m.guardian.com so they can have a clean slate for responsive design. This also allowed the team to avoid compromising the main Guardian site. The team was deploying code multiple times a day and was very experimental.
- One of the primary disadvantages of a separate mobile site is the redirect. It can double the amount of time it takes to deliver content to a user's device. Removing the redirect was the single biggest improvement to performance.
- To avoid SEO complexity, the Guardian hid the mobile site from Google.
- Mobile first design requires you to simplify and prioritize your content. This forces stakeholders to agree on what matters most as screen space is limited.
- Confining the redesign to mobile prevented a lot of people in the organization from getting involved. This allowed the team to move faster (under the radar).
- Mobile first development is all about starting small. Build your core HTML content first, the style the core elements first.
- Cutting the mustard is BBC News' approach to splitting browser support into tow groups: good enough and not. Each browser bucket gets the set of assets it needs.
- For the Guardian, the core version does not get ads, custom fonts, or additional (decorative) images. If the images are there for design, they are treated as an enhancement.
- Internet Explorer 8 does cut the mustard but it does not support media queries. The Guardian just serves the mobile layout to IE8.
- Cutting the mustard into two simply browsers is nice and simple.
Performance
- Performance has to come up for responsive design.
- The Guardian's performance tracking tools measure data from real users in real time. They show time to first byte and time to render the DOM. These help the team track down issues.
- Time to page render is the most important metric for performance.
- There are three stages of priority: content, enhancements, and leftovers (things the user doesn't care about -3rd party tools).
- HTML and CSS are the content -all that's required to load the page. The enhancements are all Javascript: additional content, touch gestures, etc. DOM content ready is when enhancements are loaded. On Page Load is when the letovers are loaded.
- At 1.3 seconds on mobile, the user basically has a complete page. By 2.3 seconds every is complete (including the leftovers).
- Web fonts are a critical part of design. The Guardian treats custom fonts as an enhancement. If you don't support WOFF, cut the mustard, or support Local Storage you don't get Web fonts.
- At pre-render, if there fonts are stored locally, they are used. If not, the font loading process is stopped until after the render. At the point, the fonts are downloaded (on GZIP, Base64 encoded) and cached in Local Storage. Then the fonts are loaded. This should only happen once per user.
- The http cache typically doesn't store things for a long time. This is why the Guardian uses Local Storage but hopefully this is just a short term solution.
Resilience
- Resilience is an often misunderstood part of Web development.
- Companies measure server uptime to 5 9's but this doesn't tell you anything about people's real world experience with your site. Instead measure the experience for real users.
- Server response is not the only factor. Networks go down, disappear, get congested, and more. It's unreliable yet resilient.
- Progressive enhancement is often considered for technology support. But it is just as important for when things go wrong.
- Progressive enhancement is about building in resilience. This is just as important as server uptime.
- HTML with inline CSS in the head of a document cuts down the number of http requests to one. This makes this faster but also more resilient.
- There is a trade-off here as several lines of CSS might be loaded on multiple pages but the tradeoff when you have only a few page views per session is probably worth it.
- Progressive enhancement is a theme across all of these: mobile first, performance, and resilience.