Download as PDF, PPTX
Uploaded byGuy Podjarny
Unravelling Mobile Web Performance
The document discusses mobile web performance, emphasizing the need for fast loading times as users have high expectations and tend to abandon slow sites. It covers various challenges related to mobile networks, hardware, and software, suggesting optimization techniques such as reducing requests, using local storage, and eliminating single points of failure. Additionally, it provides insights into performance implications and best practices for achieving efficient mobile web experiences.
More Related Content
Similar to Unravelling Mobile Web Performance
![Vibe Coding vs. Spec-Driven Development [Free Meetup]](https://cdn.slidesharecdn.com/ss_thumbnails/vibecodingvsspecdrivendevelopment-251209105622-43f455e7-thumbnail.jpg?width=640&height=640&fit=bounds)
Unravelling Mobile Web Performance
- 1. Mobile Web Performance Guy Podjarny, CTO guypo@blaze.io Twi?er: @guypod
- 2. Agenda • Why Mobile Web Performance? • The Different Aspects of Mobile – Performance implicaHons – OpHmizaHon Techniques • Summary • Q&A 2
- 3. Who Am I #1: CTO of Blaze.io • Automated Frontend OpHmizaHons from Shared insights from Blaze performance OpHmizaHon Service world’s fastest sites >1M pages analyzed research team – Dynamically applies opHmizaHon best pracHces • Cloud-‐based service – No soVware or hardware – Integrates with CDN services • Quick deployment – 1 hour or less. – No code changes required Faster, more efficient site
- 4. Who Am I #2: Blaze Mobitest • Mobile Web Performance Measurement – Free Online Service: h?p://blaze.io/mobile/ 4
- 5. Who Am I #3: Mobile Perf Researcher h?p://blaze.io/blog/ 5
- 6. Terminology Resource Doc Complete, Waterfall Chart (Request/Response) (a.k.a. onload, Start Render Load Time) 6
- 7. Why Mobile Web Performance Ma?ers
- 8. Users Expect Fast Sites Source: Akamai 8
- 9. Users Abandon Slow Sites Page Abandonment vs. Load Time Source: KISS Metrics 9
- 10. Fast Sites Help Bo?om Lines Shopzilla: 5 sec load time improvement Source: Shopzilla 10
- 11. Mobile Browsing is Gelng Big Sources: HubSpot, Twi?er, Reuters 11
- 12. Mobile Users Expect Equal Speeds Source: Gomez 12
- 13. And will abandon slow sites Source: Gomez 13
- 14. Front-‐End vs. Back-‐End Performance • Back-‐End Performance – Time to generate page – 10% of page load Hme • Front-‐End Performance – Network Time – Browser Time – 90% of page load Hme Source: New Relic 14
- 15. What Is Mobile? • Mobile is not just one thing… • Mobile Network • Mobile Hardware • Mobile SoVware 15
- 16.
- 17. Mobile Networks are SLLLOOOWWW… Latency (Ms) 400 350 300 250 200 150 100 50 0 Broadband Mobile Download (Mbps) Upload (Mbps) 10 2.5 8 2 6 1.5 4 1 2 0.5 0 0 Broadband Mobile Broadband Mobile Source: PCWorld, FCC, Novarum 17
- 18. SoluHons: Reduce Requests & Bytes • Why Reduce Requests? – High Latency + Slow Upload = Big Req Overhead – # Requests has highest correlaHon to load Hme • Why Reduce Bytes? – Simple math – less to download, be?er load Hme Correla7on To Page Load Time 0.35 0.3 0.25 0.2 # Requests 0.15 # Bytes 0.1 # Domains 0.05 0 Nexus S XOOM iPad iPad2 iPhone IE8 18
- 19. OpHmizaHon: On-‐Demand Images Mobile Walmart Apparel Page Mobile Walmart Apparel Page Original Images-‐On-‐Demand 19
- 20. OpHmizaHon: On-‐Demand Images • Reduced Requests: 28 Requests (33%) • Reduced Bytes: 108 KB (33%) • Reduced Fully Load Time: 5.9s (63%) 20
- 21. OpHmizaHon: On-‐Demand Images • Site: h?p://m.nbcsports.com/ • Reduced Requests: 15 Requests (35%) • Reduced Bytes: 50 KB (31%) 21
- 22. Mobile Networks are unreliable • High Packet Loss – High noise environment – Any request may be delayed • Non-‐Sustainable Speeds – Long-‐lasHng interrupHons – Moving client • SoluHon: Eliminate Single-‐Points-‐of-‐Failure 22
- 23. SoluHon: Eliminate SPOFs • Common SPOFs – Scripts – CSS – IFrames – Fonts • SoluHon #1: Async JS/CSS • SoluHon #2: Avoid/Delay IFrames • SoluHon #3: Avoid Fonts 23
- 24. Async JS – Eliminate Script SPOF Original Async JS 24
- 25. Latency vs. Start Render: Async JS in AcHon Start Render Time per Latency (Milliseconds, 10 Top Mobile News Sites) 6,000 5,000 4,000 3,000 2,000 1,000 0 30ms 100ms 200ms 300ms Original Site With Async JavaScript 25
- 26. Non-‐Persistent Comm. Channel • Mobile Nets have limited capacity – Limited by spectrum & ba?ery • ConnecHons are made ad-‐hoc – Then dropped by device & tower • Impact: 1.5-‐2 second delay – Likely for every single page… • SoluHon: Maintain a heartbeat – Send a dummy request every 2-‐3 seconds – Will maintain a live cell tower connecHon – Make sure you stop it aVer a while... 26
- 27. Non-‐Persistent Comm. Channel • Mobile Nets have limited capacity – Limited by spectrum & ba?ery • ConnecHons are made ad-‐hoc – Then dropped by device & tower • Impact: 1.5-‐2 second delay – Likely for every single page… • SoluHon: Maintain a heartbeat – Send a dummy request every 2-‐3 seconds – Will maintain a live cell tower connecHon – Make sure you stop it aVer a while... 27
- 28.
- 29. Mobile SoVware Is Cool! • Designed for the web – Browsing a key acHon from day 1 • Designed for Performance – Try to adapt to hardware, ba?ery and network limitaHons • Supports modern standards – Namely HTML5 & CSS 3.0 • Includes smart browsers – Modern JS Engines, look ahead downloads, DNS prefetching… • All in all: A friend, not a foe 29
- 30. Mobile Cache Sizes Too Small • Mobile Persistent Cache around 0-‐25 MB – Memory cache a bit bigger, but short lasHng – Compares to 75-‐250 MB on Desktop • Cache cycled through several Hmes a day – Average page size ~400 KB mobile, ~800KB desktop – Average desktop user browses 88 pages/day Cache Capacity in MB Cache Capacity in Pages 30 70 25 60 50 20 40 15 30 10 20 5 10 0 -‐ iPhone 4 Nexus S Blackberry iPad 2 XOOM iPhone 4 Nexus S Blackberry iPad 2 XOOM More Info: h?p://www.blaze.io/mobile/understanding-‐mobile-‐cache-‐sizes/ 30
- 31. Small Cache SoluHon: localStorage • Use HTML5 localStorage for caching – Available on all major mobile plaworms – Doesn’t expire, survives power cycle – Size limit is usually ~5MB • Most useful for caching JavaScript & CSS files – Using for images will quickly consume the 5MB • Scriptable Access enables other opHmizaHons – h?p://www.blaze.io/technical/browser-‐cache-‐2-‐0-‐scriptable-‐cache/ • In addiHon, use far-‐future expiry dates – Impacts Android’s cache evicHon policy 31
- 32. Mobile SoVware: Pipelining • HTTP Pipelining is around since HTTP 1.1 – Idea: sending mulHple requests on connecHon before receiving response – Most useful in high latency environment • Big in Mobile – ~65% of mobile clients – Also included in iOS 5 – Hardly used on Desktop 32
- 33. Pipelining: What Should You Know? With Pipelining • Risks – Head-‐of-‐Line Blocking Slow Resource delays • Slow resource delaying fast ones Fast Resources – Resources requested out of order • Depends on heurisHcs ConnecHon 1 Without Pipelining – Support detected per server/conn – Requires explicit Keep-‐Alive header • Conflicts with Domain Sharding h?p://www.blaze.io/mobile/h?p-‐pipelining-‐big-‐in-‐mobile/ ConnecHon 1 ConnecHon 2 33
- 34. Pipelining Network Capture (Galaxy S) • Samsung Galaxy S – Max Conn: 12 – Conn Per Host: 12 – Max Piped Reqs: 6 – Pipelining Support Scope: Per Conn – Conn/Pipe Request DistribuHon: Fill First • Full Details: hMp://www.blaze.io/technical/hMp-‐ pipelining-‐request-‐distribu7on-‐algorithms/ 34
- 35. Pipelining: What to do? • Make sure your servers support HTTP pipelining. – Most reasonably new servers do • Use separate domains for slow & fast resources – Helps avoid a slow response delaying a fast one • Use “ConnecHon: Keep-‐Alive” – Good pracHce anyway, but criHcal for pipelining – Include an explicit keep-‐alive header for Android • Use Domain Sharding carefully (or not at all) – Serving resources from one domain helps pipelining – Android is limited to 4 connecHons total anyway… 35
- 36. Mobile SoVware: FragmentaHon • Too Many Browsers… – Top: Android, iOS – Other: Opera, Blackberry, IE Mobile, WebOS, Firefox • Too li?le visibility.. – Especially on iOS and Blackberry – True for vendor-‐specific changes to Android • Too frequent changes… • Too few supporHng tools… 36
- 37. Android FragmentaHon -‐ ConnecHons Samsung Galaxy S Samsung Nexus S Motorola XOOM -‐ Max Conn: 12 -‐ Max Conn: 4 -‐ Max Conn: 35 -‐ Max Conn Per Host: 12 -‐ Max Conn Per Host: 4 -‐ Max Conn Per Host: 6 -‐ Max Piped Requests: 6 -‐ Max Piped Requests: 3 -‐ No Pipelining Support 37
- 38. Android Tablets Not IdenHfied • www.cnet.com Nexus S XOOM iPad 2 38
- 39. Frequent OS & Device Updates 39
- 40. Mobile Browser Usage – North America 40
- 41. FragmentaHon: SoluHons • Focus on top devices – Android & iOS first • Blackberry & Opera second – Test on key Android devices & tablets • Bolster Server-‐Side DetecHon with Client-‐Side – If screen is wide, redirect to desktop version • Measure! – Hosted: h?p://blaze.io/mobile/ – Your Devices: h?p://pcapperf.appspot.com/ • Stay on top of news 41
- 42.
- 43. Mobile Hardware: Weaker CPU • Weaker CPU = Slower JavaScript – SHll 10x slower than desktop • Script Parsing is Slow – About 1-‐10ms/KB Sunspider Time by Device/Version iPhone 4 (4.2) 10,303 • Not just JavaScript iPhone 4 (4.3) 4,285 – Flash, CSS, iPhone 4 (5.0) 3,574 Dynamic Graphics… iPhone 4S (5.0) 2,227 Macbook Pro 230 -‐ 2,000 4,000 6,000 8,000 10,000 12,000 43
- 44. Hardware Impact on Page Load Time • Alexa US Top 100: Average Load Times – Measured at night over same WiFi + Cable iPhone iPhone iOS 4 4S Simulator Page Load Time 4000 CPU 1-‐Core 2-‐Core 2-‐Core 3500 ~800Mhz ~800Mhz 2.7Ghz 3000 2500 CPU Cache 32 KB 32 KB 4 MB 2000 1500 1000 RAM 512 MB 512MB 8 GB 500 0 Median 3.4s 2.9s 1.5s iPhone 4 iPhone 4S iOS Simulator Page Load 44
- 45. Mobile Hardware: Form Factor • Mobile Devices are Small… – Comes with the territory • Two Main Sizes – Smartphone (2.6’’ to 5.5’’) – Tablet (7’’ to 10’’) • Design Challenge -‐ Performance Opportunity! – Can reduce data to match screen size • At least for Smartphones… – Can anHcipate exact resoluHon 45
- 46. Responsive Images: Resize To Screen 128px, 240px, 6.8 KB 2.9 KB 320px, 10.6 KB 480px, 21.3 KB Site: lonelyplanet.com Device: iPhone 4 Before: 867 KB AZer: Full Res, 50.1 KB 570 KB 46
- 47. Mobile Hardware: Touchscreen • Touchscreen common in Mobile • Touch can mean many things – Devices lag to decide Zoom? Click? Scroll? • Impact: Delayed Clicks – Take 300+ ms to decide it’s a click • SoluHon: Replace click with touch – May sHll have usability implicaHons 47
- 48.
- 49. What Is Mobile? • Mobile is not just one thing… • Mobile Network • Mobile SoVware • Mobile Hardware 49
- 50. Mobile Web Performance Aspects CHALLENGES SOLUTIONS • Mobile Network • Mobile Network – Slow – Reduce Requests, Bytes – Unreliable – Async All, Avoid SPOFs – Ad-‐hoc connecHons – Maintain a Heartbeat • Mobile Hardware • Mobile Hardware – Weak CPU – Async/Avoid Scripts – Small Screens – Progressive Images – Touchscreen – Touch instead of Click • Mobile SoVware • Mobile SoVware – Small Cache – localStorage – HTTP Pipelining – Separate Slow Resources – FragmentaHon – Focus, Measure 50
- 51. QuesHons? Mobile Web Performance Guy Podjarny, CTO guypo@blaze.io
- 52. Sources • h?p://transiHon.fcc.gov/Daily_Releases/Daily_Business/2011/db0802/DOC-‐308828A1.pdf • h?p://www.pcworld.com/arHcle/189592/atandt_roars_back_in_pcworlds_second_3g_wireless_performance_test.html • h?p://blog.kissmetrics.com/loading-‐Hme/ • h?p://www.slideshare.net/kleinerperkins/kpcb-‐top-‐10-‐mobile-‐trends-‐feb-‐2011 • h?p://www.google.com/events/io/2011/sessions/use-‐page-‐speed-‐to-‐opHmize-‐your-‐web-‐site-‐for-‐mobile.html • h?p://blog.newrelic.com/wp-‐content/uploads/infog_061611.png • h?p://statcounter.com/ • h?p://danzarrella.com/new-‐data-‐on-‐mobile-‐facebook-‐posHng.html# • h?p://www.comscoredatamine.com/2011/02/top-‐mobile-‐acHviHes-‐in-‐us/ • h?p://blog.twi?er.com/2010/09/evolving-‐ecosystem.html • h?p://www.ecousHcs.com/pcmag/arHcles/2392095 • h?p://mobile.h?parchive.org/ • h?p://www.h?parchive.org/ • h?p://blog.newrelic.com/wp-‐content/uploads/infog_061611.png • h?p://www.gomez.com/wp-‐content/downloads/19986_WhatMobileUsersWant_Wp.pdf • h?p://www.akamai.com/dl/whitepapers/ecommerce_website_perf_wp.pdf • h?p://www.novarum.com/novarum_blog/2009/02/real-‐measurements-‐of-‐municipal-‐wireless-‐technologies-‐wifi-‐wimax-‐ and-‐cellular.html • h?p://www.neHndex.com/ • h?p://features.journalism.org/2011/10/25/tablet-‐revoluHon/ • h?p://www.markeHngtechblog.com/ecommerce/infographic-‐how-‐is-‐mobile-‐impacHng-‐retail-‐commerce/ 52
- 53. Techniques to Reduce Requests • Merge Files – Consolidate JS/CSS Files – Inline small JS/CSS into HTML – Inline small images into CSS – Avoid CSS @imports • Avoid Unnecessary Requests – Load Images On-‐Demand – Avoid redirects where possible • Cache More – Cache as much as possible – Version files for long-‐term cacheability 53
- 54. Techniques to Reduce Bytes • Compress – Use GZIP compression for Text Resources – Use Lossless Image Compression • Remove Surplus Data – Minify JavaScript, CSS & HTML – Remove unused content (CSS, JS) – Reduce quality to display size • Shrink Uploads – Serve StaHc Files from Cookieless Domains 54
- 55. Form Factor: OpportuniHes • Responsive Images: Resize To Display Size – No point in sending large image to small screen – Useful Tool: SenchaSrc (resize on the fly) – Refinement: Lazy load bigger image on zoom • Use @media to use minimal CSS – Example: <link rel="stylesheet" type="text/css” media="screen and (max-‐device-‐width: 480px)” href=”smartphone.css" /> – Can include resized CSS images • Be careful with Progressive Design – Watch for excessive JavaScript or blocking render 55
- 56. Weaker CPU: SoluHons for JS • Use Less JavaScript… – Don’t send Desktop JS to Mobile if not used – Pre-‐Execute as much as you can • Run Dynamic code on server, return staHc content – Avoid heavy JavaScript Libraries • Defer Scripts – Run scripts that aren’t criHcal only aVer onload – Defer EvaluaHon of Inline JavaScript • Download code as comment, evaluate on-‐demand • Async Scripts – As explained earlier 56
- 57. Weaker CPU: SoluHons for Non-‐JS • CSS – Avoid CSS Expressions – Avoid inefficient CSS Rules • Example: html div p a {color: red} • Minimize reflows – Specify image dimensions – Avoid dynamic content not at bo?om – Avoid dynamic reordering of resources • Avoid Flash 57