StefanPopa MobilePerf Wide2.2

Mobile Performance Strategies
Ștefan Popa, Performance Analyst

Copyright © 2017 Optymyze Pte. Ltd. All Rights Reserved. Confidential Information.
Summary
• Cost of performance loss
• Evolution of PC vs Mobile
• Performance bottlenecks
• Detailed look upon: Caching, RTT, RRC
• Performance runs – how to measure rendering
• Profiling
Performance testing
• Identify testing environment
• Configure environment, system monitoring
• Identify performance acceptance criteria (response time,
throughput, resource utilization, etc.)
• Plan & design tests
• Implement test design
• Analyze & retest
• Report
Cost of performance loss
• Amazon: every 100ms delay loss = 1% decrease in conversion
• Walmart: One second delay reduction is a 2% increase in traffic and 100ms decrease of page load is a 1% in sale
conversion
• Google: page load of 400ms is a performance bug
• Microsoft: Users may visit another page which is 250ms faster (Harry Shum)
• Forrester Research (2009) found that online shoppers expect 2 seconds load
Cost of mobile performance loss
Mobile < PC
11%
Mobile > PC 31%
12%
Mobile = PC
21%
Mobile >= PC 25%
Mobile <= PC
Desktop vs mobile battle
Conversion rates: Desktop vs Mobile
OS / browsers trends
Mobilegeddon / Mobilepocalyse
• Gary Illyes from Google said at the Search Marketing Summit 2016 in Sydney that Google will be
updating the page speed ranking factor to specifically look at the page speed of your mobile pages when it
comes to the mobile-friendly algorithm.
• Same is announced by Maile Ohye, Developer Programs Tech Lead @ Google

– check also her video ‘Site Performance for Webmaster’ @ Google Webmasters channel
• Test your site on: Google’s Mobile-Friendly Test page
• search.google.com/search-console/mobile-friendly
Create testbed based on analytics
– Use Site Statistics (Google Analytics – best option for target audience)
– General audience (Statcounter / W3schools/ etc.):
• Top 5 audience devices (for dec’16 USA: iPhone6, iPhone 6+, Samsung Galaxy S6,
Samsung Galaxy S6 Edge, Xiaomi Redmi 2)
• Top display sizes (including portrait or landscape)- User Agent String
Device name Resolution

iPhone 6/7/s 750x1334
iPhone 6+/7+ 1080/1920
iPad Pro 2732/2048
Galaxy S6/7/edge/+ 1140/2560
Galaxy S8 1440/2960
Most common performance bottlenecks
Element issue Cause Fix

CPU usage Code complexity Use alternative algorithm / better
coding / redundant code
Element (CPU/memory/net) throttle Bad thread/pool configuration Adapt configuration on system needs
Full memory usage Too many elements / unhandled OOM Call less methods / clean memory
Disk read/write speed Uncached data / big data load Cache stuff / You need all that data ?
Network throttle Bandwidth limitations cause wait You need all that data? Net limits ?
+Extra performance bottlenecks of
mobile
Issue Cause Fix
Display Size Page elements to render Less elements
Network speed (not trustworthy) Page Size Keep it simple
Number of elements that do HTTP Reuse connection
roundtrips (RTT) Use compression
MobileIP
Not using compression
RRC State Transitions 3G – 4mins of idle -> sleep Download resources in bulk
4G – 10mins idle -> sleep
Actual GUI performance Scripts, big images, image subscalling, Put load on app side
unused script parts, minimal DOM Less scripts
impact Small images customized for display
size
Cache ‘everything’
Render / Paint performance Vector images, rendered content You really need it?
Caching
• Study ‘Caching Doesn’t Improve MobileWeb Performance (Much)’. Vesuna, Scott & al, UC Berkeley, Google, ICSI, Univ of Washington.
Caching
• Study ‘Caching Doesn’t Improve MobileWeb Performance (Much)’. Vesuna, Scott & al, UC Berkeley, Google, ICSI, Univ of Washington.
Caching
• Study ‘Caching Doesn’t Improve MobileWeb Performance (Much)’. Vesuna, Scott & al, UC Berkeley, Google, ICSI, Univ. of Washington.
Round-Trip Time (RTT)
‘MopEye: Opportunistic Monitoring of Per-app Mobile Network Performance’.

Wu, Chang & Al. Singapore Management University, Hong Kong Polytechnic University
RRC States Transition
(Radio Resource Control)
How to test performance
Standard performance tests
– Single user / Manual (Fiddler / HTTrack / Charles, etc)
– Load Tests / Automatic - (JMeter, HP Loadrunner, etc)
Standard load test + single mobile device
1. Test on closed Wi-Fi ignoring the network transfer
1. Overcome infrastructure issues (RTT, RRC, etc)
2. Measure latency with Fiddler
3. Profile on Chrome with Chrome DevTools over USB
4. Profile on Safari with Safari DevTools also over USB
2. Validate on 3G / 4G LTE
Measure rendering using internal telemetry
Use tracking pixels to snapshot onLoad events
Develop a solution using PerformanceTimer / Navigation timer

API feature for modern browsers (Chrome, Safari) to exactly
measure load time (network transfer + render) for mobile
Profiling – be aware of the overhead
Conclusions
Testing:
• Fiddler + tracking pixel
• NavigationTimerAPI + logs
• Test on WiFi + charged & updated
Development:
• Optimize your JScripts / CSS
• Cache Critical Path elements
• Use less elements
Q & A & References
• https://hpbn.co
• https://developer.mozilla.org/en-US/docs/Web/API/Performance/now
• https://developer.mozilla.org/en/docs/Web/API/Navigation_timing_API
• http://www.telecomhall.com/what-are-modes-states-and-transitions-in-gsm-umts-and-lte.aspx
• https://hpbn.co/optimizing-for-mobile-networks/
• https://developers.google.com/web/fundamentals/performance/critical-rendering-path/
• http://homes.cs.washington.edu/~arvind/papers/pload-atc16.pdf
• https://arxiv.org/abs/1703.07551
• https://www.amazon.com/Web-Performance-Daybook-Techniques-Optimizing/dp/1449332919
• http://maintao.qiniudn.com/book/Web_Performance_Daybook_Volume_2_.pdf
• https://www.w3.org/2012/11/webperf-slides-greenstein.pdf
• https://arxiv.org/abs/1703.08228 Auto-tuning GCC for ARM Cortex-M3 devices

StefanPopa MobilePerf Wide2.2

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

StefanPopa MobilePerf Wide2.2

Uploaded by

Copyright:

Available Formats

Mobile Performance Strategies

Ștefan Popa, Performance Analyst

• Google: page load of 400ms is a performance bug

Mobile >= PC 25%

• Same is announced by Maile Ohye, Developer Programs Tech Lead @ Google

• Test your site on: Google’s Mobile-Friendly Test page

Device name Resolution

Element issue Cause Fix

‘MopEye: Opportunistic Monitoring of Per-app Mobile Network Performance’.

Standard performance tests

– Single user / Manual (Fiddler / HTTrack / Charles, etc)

– Load Tests / Automatic - (JMeter, HP Loadrunner, etc)

1. Test on closed Wi-Fi ignoring the network transfer

1. Overcome infrastructure issues (RTT, RRC, etc)

2. Measure latency with Fiddler

3. Profile on Chrome with Chrome DevTools over USB

4. Profile on Safari with Safari DevTools also over USB

Use tracking pixels to snapshot onLoad events

Develop a solution using PerformanceTimer / Navigation timer

You might also like