Performance Implications of Mobile Design

Performance Implications of Mobile Design

Guy Podjarny
@guypod
guy@akamai.com
http://blaze.io/blog/
Akamai Confidential

Good Morning!

Faster ForwardTM ©2012 Akamai

Agenda

• Performance Matters!
• Focus on top Mobile Design Paradigms
• A bit on Dedicates Sites (mdot)
• A lot on Responsive Web Design
• Review Performance each Paradigm
• Dig into the top performance problem
• Show what went wrong
• Discuss how you can fix it
• Share tools that can help
• And how to use them
• Summary

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



Some

Terminology


Dedicated Sites (mdot)

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


Responsive Web Design

One URL, Adapt to screen size
http://mediaqueri.es/mq/


Mobile First & Desktop First included in RWD

Mobile First
(Progressive Enhancement)

Desktop First
(Graceful Degradation)


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


Please don‟t hate me…

• I use real world examples
• Possibly written by you…
• Constructive feedback != bashing
• These are common mistakes
• We should learn from them
• I tried to spread the blame
• Plenty of sites to choose from…
• If you fix it, let me know!
• I‟ll spread the word


Performance Matters!

Akamai Confidential

Users Expect Fast Sites

Source:
Akamai


Users Abandon Slow Sites
Page Abandonment vs. Load Time

Source:
KISS Metrics


Fast Sites Help Bottom Lines
Shopzilla: 5 sec load time improvement

Source:
Shopzilla


Mobile Users Expect Equal Speeds

Source: Gomez

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

www.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


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?

• 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 are not cached by the browser
• Good test page (by @souders): http://bit.ly/redirect-cache-test



Akamai Confidential


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 10 Got Lucky
320x480 A Bit Smaller (BG
11% Image, Fonts,
vs …)
1600x1200

Much
Smaller
3%
Same Size
86%

1 Responsive
Images
A bit smaller = 50%-90% the size
Much smaller = <50% the size

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!


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
- May be used
by JavaScript
- Possibly delayed till
just before onload

desktop.css

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


Low Hanging Fruit: 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 – Helper Tool
• Responsive images apply to CSS too!
• Especially to background images
• And stop with the huge 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 resolution 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
px
• Duplicating download is not
• Use Inline JavaScript to decide the layout
• Then use external (cacheable) files to apply it
• 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+‟”/>‟);

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
•…


Measure!

• Mobitest
• Online service: http://akamai.com/mobitest/
• 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/

49 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
Akamai Confidential

Performance Implications of Mobile Design

More Related Content

What's hot (20)

Similar to Performance Implications of Mobile Design (20)

More from Guy Podjarny (17)

Recently uploaded (20)

Performance Implications of Mobile Design