The Responsive Web (2015)

Part 3. Expanding the design with code

Chapter 9. Testing and optimization for responsive websites

This chapter covers

· Responsive testing

· Why optimization is crucial to building responsive experiences

· Using web inspectors to improve site performance

· Tips on improving performance

So far we’ve used HTML and CSS to build a responsive website that adapts to changing viewports. We’ve discussed how to add images and media to a responsive site and how to prevent failure in older browsers. All of this has added a lot of extra work for both designers and developers. For developers, the endeavor can be greater because achieving responsiveness in sites involves adding extra content and functionality to pages, and this introduces one of the biggest challenges of responsive web development: how to add the functionality of responsiveness without bloating the site’s load time. If you add a few CSS techniques to your workflow and create pages that scale down, you’ve succeeded in making your websites visually scale, but potentially at the cost of performance.

One of the biggest cons people cite against responsive design is that responsive sites perform slowly, and it’s true. Generally, creating responsive websites means adding responsiveness like a feature, and sometimes this means loading extra images or hiding elements. But there are some small steps you can take to ensure that your site performs optimally.

If a chair is pleasing to the eye but gives people back pain, what good is the chair? In the same way, if a responsive site is beautiful and scales nicely but comes at the expense of load time, what good is the site? The advances in hardware emulation and testing tools for both desktop and mobile devices mean it’s now easier than ever to make an incredibly fast website. In previous chapters you built sites using a resized browser window. This works fine when you’re only concerned with the basic scaling and architecture of a site, but there’s no substitute for working directly on a device. By testing on a device, you can see exactly what the user will end up with in terms of application responsiveness, bandwidth speed and latency, and human interaction in the touch experience.

In the previous chapter, we discussed using Modernizr in progressive enhancement. In order to enact progressive enhancements, though, you have to test in order to find areas to enhance. Testing in native environments is the best way to anticipate the experience your users will have.

9.1. What is responsive testing?

Responsive web design requires a workflow that involves testing during the build process. In building a site and progressively enhancing it into the final product, you need to ensure that the site is responsive not just in size and layout, but also in its capabilities and features.

In responsive web design, it’s important to remember that there’s more to being responsive than anticipating browser width. The only way to get a sense of how a site works in various devices is to experience it first-hand. Most developers can’t justify the expense of building their own browser labs, but there are a number of environment simulators that are available for use.

I find it’s best to draft a testing plan based on a single set of devices that serve as a starting point, and to add progressive enhancements through various devices, operating systems, and environments.

9.1.1. Simulated testing environments

Simulated environments are the easiest way to test your website on various operating systems, and there are a number of software simulators available. These are simple emulators built to test operating systems outside of their native environments.

There are a few programs for Macs that simulate Windows and Android environments, as well as iOS. Unfortunately, because of Apple’s software philosophy, OS X is unavailable for emulation in environments outside of Apple hardware, whereas Windows and Android environments are easily emulated within a Mac environment. This is one of the reasons why OS X is my preferred development environment.

One application that can assist in running simulated environments on Macs is Parallels (www.parallels.com/); it requires a license that costs around $80 USD. Parallels allows you to build simulated environments based on operating system and hardware standards that you set.

Using Parallels for Mac

When you first start up Parallels, you’re greeted with an installation wizard that walks you through the process of setting up a new virtual machine. You’re given a series of options, as shown in figure 9.1. You can install a new copy of Windows, migrate an existing copy of Windows, download Chrome OS, Ubuntu, or Android, or build a virtual machine from an OS X recovery disc.

Figure 9.1. On launch, Parallels gives you options for configuring your virtual environment.

Once it’s installed, Parallels will run with your desired operating system in its own window. This window will function like an OS inside of your OS (see figure 9.2). You can share assets and test against your local host as well as anything online.

Figure 9.2. Running Windows 8 on a Mac. With this setup, I have access to a simulated environment for most web users. IE10 has the developer tools to allow you to test previous versions of IE, so the bulk of cross-browser bugs can be identified.

The settings for each virtual machine are configurable and give you a chance to simulate variations in your testing environment (see figure 9.3). This allows you to intentionally cripple your website to see how it looks on older computers, so you can make sure you’ve accommodated those users. While this might seem over the top, it’s incredibly helpful.

Figure 9.3. The Parallels settings for my Windows 8 virtual machine, located under Virtual Machine > Configure. Here I can reduce the amount of memory devoted to the virtual machine. In the Hardware section there’s also an option to limit video memory, which is helpful in debugging animations.

The pros of Parallels

There are a lot of benefits to using Parallels. It’s efficient and consistent, and because it’s a commercial program, it has a lot of support and premium features. It lets you set up almost any configuration and combination that you might want. The simulated environments it offers give you insight into various browsers and can help identify potential problem areas before they get too serious.

The cons of Parallels

In spite of all that Parallels can do, there are a few obvious drawbacks. First is the price tag. Apart from its own cost, using Parallels to run Windows still requires a copy of Windows, which when purchased alone is around $90 USD for the pro pack. Parallels also can be resource intensive, but no more so than a lot of other virtual machines.

There’s a free alternative to Parallels released by Oracle called VirtualBox (https://www.virtualbox.org/), which gives you the same ability to install virtual machines, but it’s slightly more cumbersome and I’ve had a lot of issues with it. It also lacks support for Chrome OS and Android. That being said, it works in a pinch.

Installing iOS Virtual Environments

Aside from Parallels, you can simulate iOS environments in OS X using the iOS Simulator included in Xcode. Xcode is an IDE, compiler, and SDK kit for iOS development, but it also includes a set of simulators that are handy for web testing. Xcode can be downloaded for free from the App Store and installed with a click of the Install button (see figure 9.4).

Figure 9.4. The Xcode welcome screen

To access the iPhone simulator, start up Xcode, and select Xcode > Open Developer Tools > iOS Simulator. This will give you a functioning local version of iOS that you can use to test your sites in Mobile Safari (see figure 9.5).

Figure 9.5. The iOS Simulator screen. This application is incredibly useful for testing responsive websites in a simulated iOS environment.

The simulator is very useful, but it’s important to note that while this will give you a good sense of the layout and overall look and feel of your site, you’ll still be lacking the native feel of touch interactions.

The iOS simulator allows you to test using a variety of iOS devices and iOS versions. You can test on any iOS version that you can install locally, and Apple provides emulators for iPhones and iPads dating back to the first models. Because Apple controls the hardware in those devices, it’s easy for Apple to accurately emulate their performance.

9.2. Browser tools for testing

When you begin developing responsive sites, building a device lab will make for an incredible testing lab, if you can afford it. Specific devices are hard to recommend because they’re constantly changing, but it’s a good idea to have a device for each major OS. Ideally, a device lab should include the following:

· A high-end Android

· A low-end Android

· An older iPhone or iPod touch

· An up-to-date iPhone or iPod touch

· A Windows phone

· An iPad

· An Android tablet

It’s a good idea to spread out the screen sizes as much as possible.

Generally a spread of four or five phones and two or three tablets, each with a different OS, is a good selection. Don’t worry about buying the latest device models, since they’re strictly for testing, and having older devices forces you to work within tighter parameters. A site built to work well on an older phone with a slow connection will perform even better on a newer, faster phone.

In a pinch, there are also a number of emulators available for testing (discussed previously in section 9.1.1). These can show you how the software will render the page, and they’re great for testing for software errors, but nothing compares to the actual experience of interacting with a website on a particular device. You can easily debug most issues for mobile and tablet devices on a simulator, but the ability to interact with a site on a physical device offers unique insight.

An easy way to get this insight is by taking a field trip to the nearest electronics store and viewing a staging environment there. This approach means you’ll need a publically available testing environment, and you might have to fend off a salesperson or two, but you might learn a little about how your site operates under various conditions.

9.3. Using web inspectors

A web inspector is a browser tool that allows you to view the page source and the live DOM hierarchy, debug scripts, profile CPU and memory usage, view network traffic, and more. In mobile, tablet, and desktop browsers, there are a variety of inspectors available to you. Earlier we used the Chrome inspector to investigate a page’s markup and CSS. As I’ve gotten more adept at writing code, I’ve found the web inspector to be one of the most important tools in my toolkit.

Internet Explorer has had a developer toolkit available since IE6. Safari has its own web inspector in both OS X and iPad. Likewise, Firefox has had a Firebug plugin available for a few years and has recently included its own developer toolset. These toolsets are much like the Chrome developer tools, but for the purposes of this book, I’m going to stick with the Chrome tools.

Aside from displaying the markup and providing a JavaScript console, the inspector lets you view how a site loads, what it loads, and how quickly it loads. In Chrome, Google even offers a plugin called PageSpeed that can test your page and help you find problem areas in your site, such as browser caching, JavaScript execution, and asset minification.

Yahoo has a similar web page performance analyzer called YSlow (https://developer.yahoo.com/yslow/), which grades your page based on a set of default rules proposed by YSlow, or by using a custom ruleset, like Google PageSpeed. YSlow is provided as a browser plugin for Firefox, Chrome, Opera, and Safari, and it can also be executed from the command line using Node.js.

9.3.1. Mastering web inspectors

The key to mastering web inspectors is knowing what each of the tabs at the top does and how to use it. In this section we’ll cover some of the most useful features of the web inspector for Google Chrome, called Chrome DevTools:

· Elements— This gives you a full view of the rendered DOM and the ability to inspect each object’s associated CSS as well as its DOM properties and associated event listeners. This is incredible for tweaking designs and getting feedback on potential CSS bugs. It’s the default Chrome DevTools panel and the one I use most often.

· Resources— This panel shows the resources being used by a page, including JavaScript, CSS, and HTML, as well as the storage methods used by the browser, such as local storage and cookies.

· Network— In this panel you can view what’s loaded, how it’s applied, and its overall effect in page rendering. It will show a timeline of how the page loads. You can even break down to the millisecond how various assets affect the page load.

· Sources— This panel is used for debugging JavaScript and CSS and can help you track down the root issues in JavaScript applications.

· Timeline— In this panel you can record a page load and dive deep into how the page is loading and how the load time is affected.

· Console— This panel is useful for viewing and testing JavaScript objects, and it’s also great for logging messages when debugging.

Two of these panels, Resources and Network, are especially helpful in creating a responsive website. They’ll help you optimize your site and reduce the user’s overall bandwidth burden.

Elements

In the Elements panel you have access to the full DOM. Here you can see everything as you wrote it after it’s been affected by JavaScript and even while JavaScript runs on the page. Once you select an element to inspect, you have a full view of its CSS properties, including all selectors affecting the object and their computed styles, as well as DOM properties and event listeners. We discussed the inspector in chapters 5 and 8, so there’s no need to go into depth here.

Resources

In the Resources panel, you can view the elements being queried by the server on page load. These are seen under Frames, and can be used to identify what CSS and JavaScript is being loaded, as well as images and other assets. If you are loading something you don’t need, or there are places where you can be more efficient, this will quickly become apparent.

When you click on an asset, you can view what the source is and see its size in terms of data type, size, and dimensions, as shown in figure 9.6. This gives you a sense of every element’s weight in the load process.

Figure 9.6. Inspecting an image in the Resources panel

Network

The Network panel is of particular interest when you’re trying to optimize a site’s efficiency for responsive websites. This tool will help you get a visual sense of every request and its effects on your site’s load time, because it shows the request a page makes and the time it takes to execute that request (see figure 9.7).

Figure 9.7. The Network panel

A client (or web browser) makes a request for every asset used on the page, and then a server sends a response. After this handshake between the client and the server, the page can begin to load. This means every image file, CSS file, and JavaScript file requires a request to a server (if the file wasn’t previously loaded and cached by the browser). These requests take time, called the round-trip time (RTT).

Client-server handshake

The client-server handshake actually breaks down into three round trips from the client to the server: the first to find the file (called DNS name resolution), the second to establish a TCP connection, and the third to begin transferring the file.

Accessing developer tools on iOS

In iOS 6, Apple began including the ability to access Safari’s developer tools within the desktop version of Safari from an iPhone or iPad. This gives you the ability to inspect elements on your iPhone.

To do this, attach your iPhone or iPad to a Mac with the USB cord and then open Safari. Once there, you can access the developer tools on Safari by clicking Develop > Devices from the toolbar and selecting your device. The window you’ll see is similar to the Chrome developer tools. Infigure 9.8, the Safari developer tools are running from an attached iPhone.

Figure 9.8. Safari developer tools running from an attached iPhone

Sources

In the Sources panel you can inspect specific source files used in the project, giving you the ability to investigate individual files (see figure 9.9). This is mostly useful in debugging JavaScript, but it can also be helpful in inspecting your CSS files.

Figure 9.9. The Sources panel in Chrome developer tools

The Sources tool also lets you modify the resources in memory live—you can change your CSS and JavaScript files and immediately see the changes. Be aware that those changes are made in memory, so they’ll be lost when the page is reloaded.

Timeline

The Timeline panel gives you the opportunity to see the loading of a page on a microscopic level. This gives you a visual representation of all the requests made on page load, the time taken to return those requests, and the assets’ total load time (see figure 9.10).

Figure 9.10. The Timeline panel displays real-time load-processing information.

When you’re trying to reduce total load time, it’s important to look first at the number of requests being made and see if there are any ways to reduce them. You can also investigate whether any files are taking an extraordinary amount of time to load.

It’s also important to remember the load order of a page. Pages start with the initial DOM load and then load CSS; at that point, the page is displayed and JavaScript is executed. In the timeline, you can watch how your page loads all of these assets.

The timeline will show loading, scripting, rendering, and painting of the page in real time once you click the Record button. The recording can be stopped to analyze the results, and you can zoom in on different parts of the process to get in-depth feedback.

Console

In the Console panel you get to interact with the site’s JavaScript. We’ve used the Console in previous chapters to log screen size and get easy access to the pixel width of the page on load. Aside from getting diagnostic information, you can use the Console as a live shell prompt for JavaScript. You can interact with page elements and JavaScript objects.

The Console is hugely helpful in interacting with JavaScript APIs because it can return and log values, giving you the opportunity to see a visual readout of results being returned. The ability to use a shell prompt also affords you the opportunity to run functions and see their effects live on the page. The Console is hugely helpful in debugging JavaScript.

9.4. Tips on reducing request times

Despite increasing bandwidth, HTTP requests still create a latency problem in a majority of sites because they’re highly dependent on both the user and the server. This is particularly an issue in mobile development because mobile users in the United States are often on cellular connections, which tend to be slower than Wi-Fi and feature bandwidth caps. The server requests need to be reduced, and assets being transferred need to be minified to improve performance.

9.4.1. Reducing HTTP requests

Reducing HTTP requests is of major importance across all sites, but it’s not just load time that’s a concern. Most users are impatient when first experiencing a new site, and if the site doesn’t load in a matter of seconds, the user will leave. The initial HTTP requests can add to the time before the site begins rendering, increasing the number of people who leave before the site has loaded. Reducing these initial requests can give you a dramatic advantage over your competition. There’s also more and more information coming out about the effect of load time on search-engine optimization.

Every DNS lookup a browser does comes at a cost to the total load time, so the fewer servers that are involved, the fewer lookups are necessary. There’s a strategy to using a second or third domain in order to run parallel downloads, which we’ll talk about in section 9.4.3.

Another big way to improve performance is to ensure that there are no bad requests on your page. These are wasteful and can bog the site down as an asset searches for a nonexistent asset. This problem is much more common than most people think. Sometimes it’s the result of trying to pull in an old JavaScript file that no longer exists in the head tag; other times it’s a bad path to a rarely used image in a CSS file. It’s important to ensure that on every page load, the page can find all the required assets. This means making sure you write correct paths to assets, and that you maintain those paths in the live environment.

Once you’ve minimized the page’s requests, it’s time to start tending to your site’s assets. Minifying JavaScript and CSS is one excellent way to do that, and it’s well-covered territory. The YUI Compressor from the Yahoo Developer team is a great resource for JavaScript and CSS compression (http://yui.github.io/yuicompressor/). Image compression is another big one; I use ImageOptim (https://imageoptim.com/).

Developer insight: compressing CSS and JS

Compressing CSS and JavaScript files can save a lot of extra bytes, but sometimes it can cause legacy issues for future developers who might not know what compression technique is being implemented. When compressing files, make sure you document how you compressed the assets so anyone else working on the project knows how to make changes on the original JavaScript and CSS files and compress them again for production. It’s also a good practice to keep production-ready compressed files separate from uncompressed development files to reduce confusion.

9.4.2. Reducing image requests with Base64 encoding

Images are another major focus when improving site performance. There are applications to help you compress images and reduce their overall burden on the site. One way to optimize images is to use Base64 encoding. This means breaking down an image into its data form and inserting it into your CSS that way. Base64 encoding will increase total image size by about 33%, but it can reduce a file request in exchange.

I find this method to be extremely effective for textures on a site; you can easily save yourself some HTTP requests by including the texture as a Base64 image. The amount of data will be slightly larger, but you’ll spare yourself a request by including the image in the CSS. Base64-encoding images in your CSS is more about saving the request for the image than it is about saving file size.

You can convert an image into Base64 by using any number of tools online, like the one from the Web Coder Tools site (http://webcodertools.com/imagetobase64converter/). A quick search will identify several sites that offer such services. Once you have the string that represents the image, you can easily insert it into your CSS with the following code:

body {

background-image: url(data:image/png;base64,

[ long string of Base64 data here ]

);

}

This may seem completely foreign and complicated, but it works exactly like a normal background image. Use this technique sparingly and only for small images of just a few KB.

9.4.3. Speed optimization check list

One of the companies that’s an absolute trailblazer in the optimization and page-speed category is Yahoo. An alternative to Page Speed by Google is Yahoo’s YSlow, which we touched on earlier. Yahoo has even publicized a list of 35 best-practice categories, available online athttps://developer.yahoo.com/performance/rules.html.

In keeping with this excellent checklist, here are some of the rules presented in Yahoo’s best practices and some ways to optimize against each rule:

· Minimize HTTP requests. As discussed earlier, minimizing requests can boost site performance exponentially. Combining all JavaScript files into a single script or all CSS into a single stylesheet is a great way to improve response times. Using CSS sprites (as mentioned in chapter 6) is another way to optimize image loading.

· Use a content delivery network. A content delivery network, or CDN, is a series of web servers with the dedicated purpose of serving static files across multiple locations. Each user is served the assets based on network location, reducing the number of network hops in order to receive an asset. There are multiple services providing low-cost CDNs, such as Akamai and Amazon. A CDN is best used for static content, but it’s one of the best ways to improve site performance.

· Put stylesheets at the top. Putting stylesheets in the head tag of a page ensures that a page loads progressively, meaning that content at the top of the page loads before content at the bottom of the page. This gives the user visual feedback about the page-load progress and serves as an indicator of overall page load. While it won’t do anything magical to reduce page size, it will give the page the appearance of a fast load, creating a more satisfying user experience.

· Put scripts at the bottom. JavaScript blocks parallel loading of page assets. This means the order of script tags as they appear on the DOM is the order in which they are downloaded and then executed. In order to ensure that a page renders visually as quickly as possible, it’s best to put script tags at the bottom of the page. This allows the page to load its visual elements first, and then to execute any functional JavaScript.

· Split components across multiple domains. This works in conjunction with establishing a CDN, but by putting assets on different domains, you can maximize parallel downloads. You should avoid using more than two or three domains, but hosting static content on parallel CDN domains will ensure rapid delivery and parallel loading of those assets.

· Keep components under 25 KB. Keeping site components under 25 KB is important to making site assets cacheable in iPhones. The iPhone has a 25 KB cache limit and won’t store files larger than 25 KB uncompressed.

· Avoid empty image srcattributes. Images with empty src attributes—for example, <img src="">—cause major page-rendering issues. In short, the browser spends a lot of time looking for an asset that isn’t there, and this blocks the rendering of other page assets.

The full list of page-speed best practices can be found in the performance section of Yahoo’s developer portal (https://developer.yahoo.com/performance/rules.html).

9.5. Summary

In this chapter, we discussed the importance of site optimization in responsive web design. You learned how to use web inspectors to view the document structure and discover valuable information about how your page loads and what assets are being used. In this chapter we learned the tools of the trade needed to optimize your responsive websites.

By optimizing for performance, you can regulate any additional assets you might develop in building a responsive website, like feature-detection libraries, additional images, and viewport-specific code. Performance is absolutely crucial to responsive design because sites need to run on such a wide array of devices with variations in their capabilities.

We also covered a few less common tips on how to optimize page loads and reduce server requests. By optimizing your pages, you can reduce page load time even after adding the additional code needed to create a responsive website, and you’ll ensure that your pages work well within the constraints of mobile.

9.6. Discussion points

· How can you consider performance optimizations when beginning the development process?

· How can design contribute to a site’s performance?

· What are some ways you can easily examine site performance?