Performance Implications of Mobile Design (Perf Audience Edition)

Performance Implications of Mobile Design

Guy Podjarny
@guypod
guy@akamai.com
http://guypo.com/ Akamai Confidential

Agenda

• Quick Intro to top Mobile Design Paradigms
• Review each Paradigm
• Explain Key Implementation Points
• Dig into top performance problem
• Show what went wrong
• Discuss how you can fix it
• Share tools that can help
• And how to use them
• Summary

Faster ForwardTM ©2012 Akamai

Who Am I #1: Ex-CTO of Blaze.io (now Akamai)


Who Am I #2: Blaze Mobitest

• Mobile Web Performance Measurement
• Free Online Service: http://akamai.com/mobitest/
• Now Open-Source!
• For more details: http://bit.ly/open-source-mobitest


Who Am I #3: Mobile Performance Researcher

http://guypo.com/


Waterfall Charts
Resource Doc Complete,
Waterfall (Request/Response) (a.k.a. onload,
Chart Start Render Load Time)


Quick Intro to Mobile Design

Akamai Confidential

Dedicated Sites (mdot)

URL/Website Per Device Profile
m.walmart.com www.walmart.com


Why Dedicated Websites?

• Historical Reasons
• More established and better understood
• Hard to change existing desktop websites
• Different owners inside/outside the company

• Better Reasons
• Less sensitive to specific browsers
• Helps align to native apps
• Easier to get perfect site for that context (Maybe)


Responsive Web Design

One URL, Adapt to screen size
www.bostonglobe.com


Mobile First & Desktop First: RWD Variations

Mobile First
(Progressive Enhancement)

Desktop First
(Graceful Degradation)


Why Responsive Websites?

• Broader Device Support
• Support the endless screen size permutations
• No Need for User-Agent Mapping

• Easier to maintain
• Maintain one website instead of multiples

• Future Friendly
• Anticipates future devices
• Better suited for handling new types of devices
• http://futurefriend.ly/


Responsive Shades of Grey

• Responsiveness is a property of a website
• A dedicated mobile website can be responsive
• A website can respond “only a little bit”

• Display Size is not the only variable
• Can respond to hardware properties (e.g. camera)
• Can respond to data availability (e.g. location)

• Server-side code can help too (a.k.a. RESS)
• Though responsiveness is primarily client-side


Dedicated Sites (mdot)

Akamai Confidential

Mdot

Dedicated Sites don‟t
create new performance
problems
Still have old problems,
but that‟s not related to mobile design


Small Mobile Site, Small Waterfall Chart

m.cnn.com , iPhone 4, iOS 5.0

Big Desktop/Tablet Site, Big Waterfall Chart

www.cnn.com
iPad 2
iOS 5


Dedicated Sites Top Performance Problem

Redirects

m.
www.


Redirects are expensive!
www.espn.com
2 redirects, 1.3 seconds lost


User-Agent Detection FAIL

Nexus S XOOM iPad 2


Solution: Client-Side Detection


Late Redirect using scripts are even slower

www.disney.com
2 redirects + JS Redirect, 3 seconds lost


Could get nasty

www.garmin.com
3 redirects + JS Redirect, 3.6 seconds lost


Redirects – What To Do?

• Replace redirects with client-specific HTML
• Your CDN/load-balancer can help!
• Minimize Redirects
• Merge redirect chains
• Use HTTP Redirects, not JS redirects
• Keep the client-side detection as backup
• Detect most devices server-side
• Cache HTTP Redirects on the CDN
• Makes the extra round trip shorter
• Use HTTP 301 Redirect, with a future Expiry
• 302/303/307 redirects not cached by iOS and others



Akamai Confidential

RWD Implementation 101

• Fluid Design
• Turn absolute sizes into relative sizes
• Breakpoints
• Ethan Marcotte (@beep) / Stephen Hay @stephenhay:
“Expand window until it looks like shit. Time to insert a breakpoint!”
• CSS Media Queries
• Change CSS more significantly at breakpoints
• Examples: Hide Columns, Collapse Menus, Remove bg imgs
• Using min/max width controls default view
• Determines what non-conforming browsers will display


Live

Demo


Media Queries Example Mobile-First:
Uses min-width

3 “versions”: 2 Breakpoints:
Basic, Mobile, Desktop 320px, 640px

RWD Implementation 201

• Extend support with scripted DOM manipulations
• Not all browsers support media queries (e.g. IE 6-8)
• Due to JS Support concerns, used mainly for enhancement
• Often required for responding to features

• Beware: Widths are not accurate or consistent
• Leave some buffer…

• Use EMs instead of PXs for absolute sizes
• Better handling for zoom or font size differences



Top Performance
Problem:
Over-Downloading


Test – Compare Sites on Different Resolutions

• Data:
• 347 Sites from http://mediaqueri.es/
• Testing Methodology:
• Use http://webpagetest.org/
• Use Chrome browser
• Resize window before each measurement
•Resolutions: 320x480, 480x960, 1024x768, 1600x1200
• Saw similar results with iPhone vs. iPad tests
• Collect Results
• Excel & Pivot Tables
(Automated version of Jason Grigsby‟s test last year)
©

Responsive Sites Load Times & Size, by Resolution

Load Time* by Resolution (ms)
4,000
3,500
3,000
2,500
2,000
1,500
1,000
500
0
Page Size by Resolution (KB)
1,200
1,000
800
600
400
200
0

* Over Cable Speed
(5 Mbps down, 1 Mbps up, 28ms RTT)


Small Screen = Less Visible Content != Less Bytes

320x48 1600x120
0 0


Some depressing stats…
Page size
Smallest Screen (320x480)
3%
11% vs.
Biggest Screen (1600x1200)

Roughly Same Size

A Bit Smaller (50-90%)
86%
Much Smaller (<50%)


Big Site, Big Waterfall
1600x120
0


Small Site, Big Waterfall

320x480


Download and Hide

Rich Side-bar,
holds ads and more

Display set to none


Hidden content is still downloaded

Display set to none,
resources are still
downloaded!

Hidden
background
Images are not!


Download and Shrink

Smaller Screen,
Same Size Image


Media queries don‟t prevent CSS downloads

Separate CSS
per media

basic.css
mobile.css 320x480
“Right” CSS loaded

“Wrong” CSS loaded
- Possibly deferred to
just before onload
- WebKit Bug 39455
- Conditions may change
(e.g. rotate device)
- Scripts may use it
Faster ForwardTM
desktop.css ©2012 Akamai

Excess DOM

1402 elements 1398 elements
3485 nodes 3491 nodes

Simplicity
not
reflected
in DOM

1600x1200 320x480

RWD Woes

• Download and Hide
• Download and Shrink
• Extra CSS Download
• Excess DOM


What Can We Do About It?!

Akamai Confidential

Images accounts for most mobile pages size

Stats from http://mobile.httparchive.com/


Responsive Images

128px,
240px, 6.8 KB 2.9 KB
320px, 10.6 KB

480px, 21.3 KB

Site:
lonelyplanet.com

Device:
iPhone 4

Before: Full Res, 50.1 KB
867 KB

After:
570 KB

Responding Up (or badly?)

ipad_hero.jpg
113 KB
Served to Desktop

ipad_hero_2x.jpg
360 KB
Served to New iPad


Standardizing Responsive Images

@srcset

VS.
<picture>

https://github.com/scottjehl/picturefill

Responsive Images

• Responsive Images =
Serve lower res images to smaller screens
• Optionally load full res image in the background

• Lots of great resources on how to do it
• Cloud Four blog - Education
• Sencha.io Src – Free Server-Side Image Resizing
• https://github.com/scottjehl/picturefill - Client-Side Selector

• Responsive images apply to CSS too!
• Especially to background images

Load Images via CSS

Full Details:
http://timkadlec.com/2012/04/media-query-asset-downloading-results/


Or load images via JavaScript

• Same loader can:
• Apply responsive images
• Load only visible images, including only above-the-fold images
• Interferes with speculative look-ahead parsing


Beyond Images - Build Mobile First

• Don‟t just design Mobile First – Code a Mobile-only site
• Build only for the lowest resolution you care about
• Adapt to similar screen sizes: No layout shifts, no big res jumps
• Performance should compare to mdot sites
• Once implemented – Enhance via JavaScript
• Grow DOM only on screens that need it.
• Desktop clients with no JS support are a minority
• Your mobile site should be good enough for those
• Don‟t sacrifice the performance of 99% for the remaining 1%


Enhancing via JavaScript – Tips & Tricks
1600px
• Split your files by layout/resolution
480
• Duplicating content on the server is ok 320 px
• Duplicating download is not px

• Use Inline JavaScript to decide the layout
• Then use external (cacheable) files to apply it
• document.write() all CSS files (and other links) in one inline script!
• Put scripts that change design at the top
• JavaScript blocks rendering
• Will avoid FOUC – Flash Of Unstyled Content
• Put all other scripts at the bottom
var css = „small.css‟;
if (window.innerWidth > 640) css = „large.css‟;
else if (window.innerWidth >= 320) css = „medium.css‟;
document.write(„<link type=“stylesheet” rel=“stylesheet” href=“‟+css+‟”/>‟);
Faster Forward
TM
©2012 Akamai

Don‟t forget the “regular” concerns

• Reduce HTTP requests
• Consolidate Files
• Inline tiny files
• Reduce bytes
• Minify CSS/JS
• Use Lossless Compression for Images
• Load visible content first
• Defer everything else
• Or Load it on demand
• Avoid CSS Imports
•…

Now you can be Responsive AND Fast!


Measure!

• Mobitest
• Online service: http://mobitest.akamai.com/
• Install local open-source version (details)
• Google‟s Pcapperf
• Convert network capture to waterfall charts
• http://pcapperf.appspot.com/
• Stoyan Stefanov‟s “icy”
• HTTP insight into iOS HTTP requests
• https://github.com/stoyan/icy
• @firt‟s iWebInspector
• Remote debugger for iOS simulator
• http://www.iwebinspector.com/

56 Faster ForwardTM ©2012 Akamai

Testing different screen dimensions

• Run webpagetest script with resizing
• Use Chrome as agent (not supported on other browsers)
• Sample script (tab delimited):
setviewportsize 320 480
navigate http://bdconf.org/

• Many other scripting
options:https://sites.google.com/a/webpagetest.org/docs/using-
webpagetest/scripting

• Figure out the viewport dimensions you want to simulate
• http://www.websitedimensions.com/


Summary

Akamai Confidential

Summary

• Choosing your mobile design is HARD
• There are many factors to consider
• Design Decision have Performance Implications
• Mdot Primary Concern: Redirects
• RWD Primary Concern: Over-Downloading
• Either design paradigm can be made fast
• Performance should be built in – not bolted on
• Measure!
• Make perf testing a part the core functionality test


Questions?
Performance Implications of Mobile Design

Guy Podjarny
@guypod
guy@akamai.com
http://guypo.com/ Akamai Confidential

Performance Implications of Mobile Design (Perf Audience Edition)

Recommended

Recommended

More Related Content

What's hot

What's hot (18)

Viewers also liked

Viewers also liked (20)

Similar to Performance Implications of Mobile Design (Perf Audience Edition)

Similar to Performance Implications of Mobile Design (Perf Audience Edition) (20)

More from Guy Podjarny

More from Guy Podjarny (18)

Recently uploaded

Recently uploaded (20)

Performance Implications of Mobile Design (Perf Audience Edition)