RWD is not a Panacea

Estelle Weyl

http://estelle.github.io/rwdpanacea

OpenSignal.com breakpoints

"The principles of universality of access irrespective of hardware or software platform, network infrastructure, language, culture, geographical location, or physical or mental impairment are core values in Web design"

Tim Berners-Lee, Sept. 1998

Viewport

<meta name="viewport"
  content="width=device-width,
     user-scalable=yes">
@viewport { viewport-properties }

Specifies viewport size, zoom factor, and orientation.

Resource: A tale of 2 viewports
Tutorial: Media Queries slide deck

Responsive Design

Responsive Design

  1. fluid grids
  2. flexible images, and
  3. media queries

Network Resources

Wide / Desktop Narrow / Mobile
Requests 155 138
Assets 6.442 MB 5.272 MB
Load 21.14s 43.15s
DOMContentLoaded 3s 13.4s

Responsive Web Design

To see RWD in action, open a responsive site in a desktop browser and slowly make the browser thinner and wider. The layout magically adjusts itself to more comfortably fit the new width of the browser, even if you make the page as skinny as the resolution of a mobile phone. Google

Responsive Web Design

To see RWD in action, open a responsive site in a desktop browser and slowly make the browser thinner and wider. The layout magically adjusts itself to more comfortably fit the new width of the browser, even if you make the page as skinny as the resolution of a mobile phone. Google

Squishy!!!

@snugug

RWD !== Squishyness

Newsweek Network Resources

Wide / WiFi Narrow / WiFi
Requests 254 260
Assets 3.366 MB 3.000 MB
Load 12.0s 11.9s
DOMContentLoaded 2.32s 2.81s
WIRED

UA sniffing for different experiences:
Desktop: 86 requests/1.9 MB
Mobile:   89 requests/2.0 MB

Size matters

274%

According to the HTTP Archive, the average top 1,000 web page is 1,925 KB, compared to 702 KB in 2010.

HTTPArchive
Images: 1206 KB v. 416 KB
JS: 305 KB v. 113 KB

Open in separate window

Youtube Feathers:
Regular:  58 requests/1200 kB
Feathers: 14 requests/100 kB

TL;DR;

By keeping your client side code small and lightweight, you can literally open your product up to new markets.

Duh!

Speed is more than a feature. Speed is the most important feature. If your application is slow, people won’t use it...

There is real empirical evidence that substantiates the fact that speed is more than a feature. It’s a requirement.

Fred Wilson

Point being.....

  1. size of requests
  2. number of requests
  3. number of DNS lookups

YSLOW

  • Make fewer HTTP requests

    Decreasing the number of components on a page reduces the number of HTTP requests required to render the page, resulting in faster page loads. Some ways to reduce the number of components include: combine files, combine multiple scripts into one script, combine multiple CSS files into one style sheet, and use CSS Sprites and image maps.

  • Avoid empty src or href

    You may expect a browser to do nothing when it encounters an empty image src. However, it is not the case in most browsers. IE makes a request to the directory in which the page is located; Safari, Chrome, Firefox 3 and earlier make a request to the actual page itself. This behavior could possibly corrupt user data, waste server computing cycles generating a page that will never be viewed, and in the worst case, cripple your servers by sending a large amount of unexpected traffic.

  • Compress components with gzip

    Compression reduces response times by reducing the size of the HTTP response. Gzip is the most popular and effective compression method currently available and generally reduces the response size by about 70%. Approximately 90% of today's Internet traffic travels through browsers that claim to support gzip.

  • Put CSS at top

    Moving style sheets to the document HEAD element helps pages appear to load quicker since this allows pages to render progressively.

  • Put JavaScript at bottom

    JavaScript scripts block parallel downloads; that is, when a script is downloading, the browser will not start any other downloads. To help the page load faster, move scripts to the bottom of the page if they are deferrable.

  • Reduce DNS lookups

    The Domain Name System (DNS) maps hostnames to IP addresses, just like phonebooks map people's names to their phone numbers. When you type URL www.yahoo.com into the browser, the browser contacts a DNS resolver that returns the server's IP address. DNS has a cost; typically it takes 20 to 120 milliseconds for it to look up the IP address for a hostname. The browser cannot download anything from the host until the lookup completes.

  • Minify JavaScript and CSS

    Minification removes unnecessary characters from a file to reduce its size, thereby improving load times. When a file is minified, comments and unneeded white space characters (space, newline, and tab) are removed. This improves response time since the size of the download files is reduced.

  • Avoid URL redirects

    URL redirects are made using HTTP status codes 301 and 302. They tell the browser to go to another location. Inserting a redirect between the user and the final HTML document delays everything on the page since nothing on the page can be rendered and no components can be downloaded until the HTML document arrives.

  • Remove duplicate JavaScript and CSS

    Duplicate JavaScript and CSS files hurt performance by creating unnecessary HTTP requests (IE only) and wasted JavaScript execution (IE and Firefox). In IE, if an external script is included twice and is not cacheable, it generates two HTTP requests during page loading. Even if the script is cacheable, extra HTTP requests occur when the user reloads the page. In both IE and Firefox, duplicate JavaScript scripts cause wasted time evaluating the same scripts more than once. This redundant script execution happens regardless of whether the script is cacheable.

  • Reduce the number of DOM elements

    A complex page means more bytes to download, and it also means slower DOM access in JavaScript. Reduce the number of DOM elements on the page to improve performance.

  • Avoid HTTP 404 (Not Found) error

    Making an HTTP request and receiving a 404 (Not Found) error is expensive and degrades the user experience. Some sites have helpful 404 messages (for example, "Did you mean ...?"), which may assist the user, but server resources are still wasted.

  • Do not scale images in HTML

    Web page designers sometimes set image dimensions by using the width and height attributes of the HTML image element. Avoid doing this since it can result in images being larger than needed. For example, if your page requires image myimg.jpg which has dimensions 240x720 but displays it with dimensions 120x360 using the width and height attributes, then the browser will download an image that is larger than necessary.

  • Make favicon small and cacheable

    A favicon is an icon associated with a web page; this icon resides in the favicon.ico file in the server's root. Since the browser requests this file, it needs to be present; if it is missing, the browser returns a 404 error (see "Avoid HTTP 404 (Not Found) error" above). Since favicon.ico resides in the server's root, each time the browser requests this file, the cookies for the server's root are sent. Making the favicon small and reducing the cookie size for the server's root cookies improves performance for retrieving the favicon. Making favicon.ico cacheable avoids frequent requests for it.

  • Avoid CSS expressions

    CSS expressions (supported in IE beginning with Version 5) are a powerful, and dangerous, way to dynamically set CSS properties. These expressions are evaluated frequently: when the page is rendered and resized, when the page is scrolled, and even when the user moves the mouse over the page. These frequent evaluations degrade the user experience.

  • Avoid AlphaImageLoader filter

    The IE-proprietary AlphaImageLoader filter attempts to fix a problem with semi-transparent true color PNG files in IE versions less than Version 7. However, this filter blocks rendering and freezes the browser while the image is being downloaded. Additionally, it increases memory consumption. The problem is further multiplied because it is applied per element, not per image.

YSlow

Responsive Images

It's more than just making them squishy!

Improve performance

  1. Decrease file size: easily decrease bytes by 70+%:
    • Compress all images
    • GZip everything
  2. Don't download what you won't use
    • Lazy load
    • display: none; on parent of background image
  3. Only load the size you need
    • <picture>
    • Clowncar technique
    • <img srcset> (in Safari, Opera 21, Chrome 34)
    • (and picturefill)

Object + Media Queries + SVG + CCimg

background-size: auto;

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 300 329"
  preserveAspectRatio="xMidYMid meet">
 <title>Clown Car</title>
 <style>
  svg {
    background-size: 100%; background-repeat: no-repeat;
  }
 @media screen and (max-width: 300px) {
  svg {background-image: url(images/small.png);
  }
 }
 @media screen and (min-width: 301px) and (max-width: 600px) {
  svg {background-image: url(images/medium.png);
  }
 }
 @media screen and (min-width: 601px) and (max-width: 900px) {
  svg {background-image: url(images/big.png);
  }
 }
 @media screen and (min-width: 901px) {
  svg {background-image: url(images/huge.png);
  }
 }
 </style>
</svg>

Resource: Clown Car Technique

Right-size your images

Scaled: 1,850 milliseconds

Right-sized: 625 milliseconds

  • blue = CPU used to decode
  • green = FPS (more is better)
  • purple = rendering
PhysicsOfFast

background-size

autocovercontain
auto cover contain
44ms 182ms 203ms

Make fewer
HTTP requests &
DNS lookups

But, it was so fast for me ...

computer
MoviStar
Vodafone

Latency

Computer asks DNS server for IP address, then goes to IP to get website
  • Issue: Requests take longer to complete
  • Solution: Reducing requests improves performance

Yes, you want to...

  1. Make the site squishy
    • breakpoints based on design
  2. Reduce http requests / latency
  3. Reduce weight of page
  4. Avoid CSS performance gotchas
  5. Ensure legibility
  6. Serve the right size images
  7. Right input methods
  8. Effective content strategy
  9. Design mobile first

... but also consider ...

  1. bandwidth and latency
  2. memory
  3. battery
  4. responsiveness

CPU used to decode images

Scaled: 1,850 milliseconds

Right-sized: 625 milliseconds

  • blue = CPU used to decode
  • green = FPS (more is better)
  • purple = rendering
PhysicsOfFast

JavaScript

  • Render cost: JS (and CSS and images)
  • JS (download, parsing & executing)
  • Dynamic JS: ⬆ rendering cost (can't be cached).
  • AJAX: waking up the radio communications

JavaScript!

  • All scripts loaded and parsed (even if not used)
  • Reduce JS to only what is needed
  • Are libraries really necessary?
    • Include only functions used by page to reduce energy use.
    • Goal of most libraries is equalize across browsers
      (not necessry in mobile space)
    • Libraries simplify web development, but increase energy use.
    • You don't need a framework for that
  • Don't let 3rd party scripts be your SPOF

Battery Consumption

CPU Drains the battery. Avoid using it!

  • Avoid Reflows (and repaints)
  • Minimize JavaScript (size and activity)
  • Avoid loading resources you don't need
  • No JavaScript Animations
    • requestAnimationFrame (not setInterval or setTimeout)
    • CSS Animation
  • Manage memory
  • Avoid waking up the radio - prefetch

CSS Animation, not JavaScript

JavaScript Animation

CSS3 Animation

PhysicsOfFast

Memory

Device Memory
iPhone 3G128MBiphone
htc inspire
iPad
iPhone 3GS256 MB
iPhone 5/5S/61 GB
HTC Inspire768 MB
iPad 1256 MB
iPad 3/41 GB
iPod Touch (4)256 MB
Samsung Galaxy Note Edge3GB
Intex Cloud FX128 MB
MacBook Pro16 GB

Browser shares Memory

Running Services
Other73MB Avail: 255MB + 182MB in 21
Calendar8.4MB
Process:com.htc.bgp
ObexService31:52:14
Started by application: Touch to stop
AT&T Navigator8.4MB
Process: com.telnav.app.android.congular
ResoucePreLoaderRestarting
Started by application: Touch to stop
AT&T Spots2.4MB
Process: com.matchboxmobile.wasp
WispService31:52:14
Started by application: Touch to stop
Media4.1MB
Process: android.process.media
DownloadService31:52:14
Started by application: Touch to stop
PVWmdrmService2.2MB
Process: com.pv.wmdrmservice
PVWmdrmService31:52:14
Started by application: Touch to stop

Minimize the DOM

  • Minimize number of nodes
    • Uses up memory & time
    • Measures each node for each repaint
  • Cache DOM lookups
    • Store them!
  • Minimize DOM manipulations
    • Batch DOM queries & DOM manipulations separately

More nodes = more expensive!

Responsiveness

  1. User Interaction
    • Aim for a 100ms response time!
  2. Re-rendering time
    • 60FPS = 16.67ms per frame

Touch Events

  • Touch Event: 300ms delay
  • provide user feedback, fetch, update when ready
el.addEventListener('click', myFunction);
el.addEventListener('touchend', myFunction);*
<meta name="viewport"
 content="width=device-width;
          initial-scale=1; maximum-scale=1;">
* Scroll throws a touchend :( Luke W.

Performance Budget!

Good design is not about making something pretty. It is about making something usable and intuitive – the beauty of the product will be a result of these things.

-- Luke Jones