James D Bloom, profile picture
Uploaded byJames D Bloom
PDF, PPTX3,960 views

Mobile Web Best Practices

The document discusses best practices for mobile web development, emphasizing challenges such as diverse devices, network limitations, and user expectations. It suggests solutions like mobile-first design, adaptive techniques, and performance enhancements to improve user experience and site speed. Key strategies include reducing requests, optimizing resource load, and employing progressive enhancement to ensure compatibility across devices.

Technology◦
Related topics:
Mobile Web Solutions•

Embed presentation

Download as PDF, PPTX
MOBILE WEB BEST PRACTICES http://about.me/jamesdbloom http://blog.jamesdbloom.com JamesDBloom
PERCENTAGE OF MOBILE WEB 50% 45% 40% 35% 30% 25% 20% 15% 10% 5% 0% http://www.tecmark.co.uk/wp-content/uploads/2011/08/Mobile-and-UK-Web-Traffic-August-2011.pdf
WHAT I’M TALKING ABOUT ¡  The Problem §  What’s different and hard about mobile ¡  The Solution §  Adaptive Techniques §  Mobile First §  Avoid JavaScript §  Device Detection §  Adaptive Design §  Progressive Enhancement §  High Performance §  Network §  Less Request §  Less Bytes §  Bandwidth Efficiency §  Less Latency §  Sof tware §  Faster Page Rendering §  Faster Interaction §  User §  Faster Interaction §  Improve Perception ¡  Tools §  Debugging §  Performance §  Emulators
WHAT’S MOBILE – THE PROBLEM ¡  Network §  Different types of network: §  GSM, GPRS, WCDMA, UMTS, EDGE, HSPA, UMTS, LTE, WiMAX §  High latencies §  300ms to 1000ms §  High packet loss §  From 0.1% to >20% §  Each time triggers TCP Slow Start again §  Radio Resource Control (RRC) §  Adds 1.5s to 2s to initiate connection §  Total Connection Time §  RRC + DNS + TCP 3-way handshake + TCP slow start + HTTP Request §  SSL adds even more §  Bandwidth §  3G §  Download: ~1Mbps Upload: ~0.5 Mbps §  Broadband §  Download: ~9Mbps Upload: ~2Mbps
WHAT’S MOBILE – THE PROBLEM ¡  Device §  Rapidly changing, widely diverse hardware §  “2500 different devices on Facebook per month” - Tobie Langel 7000 SunSpider JS Benchmark (in ms) for some of the devices released in the last year 6000 5000 4000 3000 2000 1000 0 http://www.anandtech.com/show/5584/htcs-new-strategy-the-htc-one
WHAT’S MOBILE – THE PROBLEM ¡  Device §  Slow CPU §  10x slower then desktop §  JavaScript that runs for 100ms on desktop will take ~1s on mobile §  Low memory §  Mobile RAM in MB §  Desktop RAM in GB §  Small screen §  Navigation §  Touch §  Gestures: Tap, Double Tap, Drag, Flick, Pinch, Spread, Press, Press & Tap, Press & Drag, Rotate, … §  More direct interaction §  But different on each device §  Focus §  Pointer Google Tech Talk - November 10, 2011 - Guy Podjarny
WHAT’S MOBILE – THE PROBLEM ¡  Software §  Rapidly changing, widely diverse browsers and operating systems No Browser Creator No Browser Creator 1 Android Browser Google 21 Obigo Browser Obigo AB 2 Apollo Team Apollo 22 Opera Mini Opera Software 3 BlackBerry Browser Research in Motion 23 Opera Mobile Opera Software 4 Blazer Palm 24 Palm HP 5 Bada Samsung 25 Pixo Sun Microsystems 6 Chrome for Android Google 26 PlayStation Portable Sony 7 Classilla Cameron Kaiser 27 Polaris Browser Infraware 8 Deepfish Microsoft 28 Safari Apple 9 Dolphin Browser MoboTap 29 Symbian / S60 Nokia 30 Skweezer 10 Firefox for mobile Mozilla Foundation 31 Skyfire Skyfire Labs 11 ibisBrowser ibis 32 Skyfire Mobile Browser Skyfire 12 Internet Explorer Mobile Microsoft 33 Steel 13 Iris Browser Torch Mobile 34 Teashark 14 JOCA InteracT!V 35 Tristit 15 Kindle Basic Web Amazon.com 36 UC Browser UC Mobile 16 MIB Motorola 17 Minimo Mozilla Foundation 37 uZard Web Logicplant 18 Myriad / Openwave Myriad Group 38 Vision Mobile Browser Novarra 19 NetFront ACCESS 39 WebOS Browser Palm 20 Nokia Series 40 Browser Nokia 40 WinWAP Winwap Technologies
WHAT’S MOBILE – THE PROBLEM ¡  Sof tware §  Changing rapidly §  Different navigation method §  Proxied vs Direct §  Proxied – Opera Mini, Kindle Fire §  Direct – all others §  HTTP vs SPDY §  SPDY – Kindle Fire, Chrome for Android §  HTTP – all others §  Process models §  Multi Process – Chrome for Android §  Single Process - all others §  Small Cache §  2-4MB §  Connections §  Max Total §  Max per host §  Pipelined §  Multiple requests over a single socket without waiting for a response §  Problems with proxies and head-of-line blocking
WHAT’S MOBILE – THE PROBLEM ¡  Users §  Distracted §  i.e. walking down the street §  Shorter interactions §  i.e. waiting for a bus §  Touch §  Fat fingers §  Gestures (are they all intuitive?) §  Targeted tasks §  i.e. what are the local restaurants? §  Expectations §  Web that “pretends” to be app is likely to disappoint §  85% - “customers expect to be able to shop on their phones and want the experience to be as good or better than on a computer” http://www.nytimes.com/2011/04/18/technology/18mobile.html?_r=3
MOBILE FIRST ¡  Mobile first §  Start simple and build up §  Test for presence (and function) of all APIs §  If it exists it may not work correctly §  Everything should fallback §  local storage → local variable → no storage §  push & pop state → hash bang fall → page refresh §  auto refresh → manual refresh button §  Avoid native events → use synthetic events §  minimizes difference between browsers ¡  Forget pixel perfect §  Fluid grids §  Adaptive design
AVOID JAVASCRIPT ¡  Avoid JS → Middle Tier §  Why are we re-implementing the browser? §  Maximize stability across devices, even unknown devices §  Ensure site works without JS §  You control execution environment §  More reliable §  Easier to test §  Limit device dependent code §  Easier to automate tests §  Simplify browser interaction helps Selenium §  More code covered by Java unit tests §  Easier to optimize §  Scale out / up §  Easier to diagnose issues §  Well understood §  Better tools
ADAPT – DEVICE DETECTION ¡  Breakpoints §  Major breakpoint on server §  Chose fixed high level breakpoints §  Mobile §  Tablet §  Desktop §  TV §  Avoid serving desktop site on mobile width §  Too heavy §  Too slow to download §  Too slow to render §  Not optimized correctly §  Adapt §  Content §  Layout §  Features §  Page weight §  Caching §  Vary: User-Agent!
ADAPT – DEVICE DETECTION ¡  Breakpoints §  How to select major breakpoint §  Headers §  User-Agent §  Accept §  x-wap-profile / Profile §  UAProfile with device capabilities and preferences (W3C Ubiquitous Web Applications Working Group – closed July 2010) §  OperaMini §  Device Libraries §  WURFL §  Open Source §  Slightly limited information §  Based on UAProfile §  DeviceAtlas §  Started by Ericsson, Google, GSM Association, Microsoft, Nokia, Samsung, T-Mobile, Telecom, Telecom Italia, Visa and Vodafone §  51Degrees §  Build into ASP.NET and MVC.NET §  DetectRight §  Custom DB §  Augment existing device library §  Log capabilities (i.e. cookie / analytics / JS) §  Tools §  Spring Mobile §  WURFL §  Apache Mobile Filter §  WURFL §  51Degrees §  DetectRight
ADAPT – ADAPTIVE DESIGN ¡  Breakpoints §  Minor breakpoint on client §  @media §  Screen size, resolution & pixel density §  Fluid grids, dif ferent columns, adapt image size (see earlier slide) §  navigator.connection.type! §  ETHERNET, WIFI, CELL_2G, CELL_3G, …! §  Send to server §  Cookie §  JS §  Landscape vs portrait §  Consider width of screen not width of viewport §  Test for presence (and function) of all APIs §  If it exists it may not work correctly §  Everything should fallback §  local storage → local variable → no storage §  push & pop state → hash bang fall → page refresh §  auto refresh → manual refresh button §  Indicate it’s a mobile website
ADAPT – PROGRESSIVE ENHANCEMENT ¡  Progressive Enhancement §  Test for presence (and function) of all APIs §  If it exists it may not work correctly HTML5 §  Everything should fallback §  local storage → local variable → no storage §  push & pop state → hash bang fall → page AJAX / HIJAX refresh §  auto refresh → manual refresh button §  HTML5 CSS Extensions §  Not fully supported §  mobilehtml5.org Basic JavaScript §  www.modernizr.com §  caniuse.com §  www.browserscope.org Advanced CSS §  www.quirksmode.org §  PolyFills Simple CSS §  Add weight §  Better to except not supported and degrade HTML
HIGH PERFORMANCE – WHY? ¡  47% expect page load < 2s ¡  40% abandon sites with page load > 3s ¡  +1s → -7% conversion rate ¡  if $100,000 per day, +1s → $2.5 million lost sales ever y year ¡  Bing §  +1s → -4% revenue ¡  Google §  0.4s to 0.9s → -25% searches (-$2.5 billion revenue) ¡  Firefox §  -2.2s download page → +15% downloads (+1.7 million extra / year) ¡  Shopzilla §  -5s → +7-12% revenue, -50% hardware cost ¡  Wallmart & Amazon §  every -100ms → +1% revenue http://blog.kissmetrics.com/loading-time/ http://blog.mozilla.com/metrics/category/website-optimization/ http://radar.oreilly.com/2009/07/velocity-making-your-site-fast.html http://www.webperformancetoday.com/2012/02/28/4-awesome-slides-showing-how-page-speed-correlates-to-business-metrics-at-walmart-com/
HIGH PERFORMANCE – LESS REQUESTS ¡  Less Requests 0.5 Highest Correlation to Load Time 0.45 0.4 0.35 Total Requests Image Requests Total Xfer Size Image Xfer Size Domains 0.5 Highest Correlation to Render Time 0.45 0.4 0.35 0.3 Total Requests Image Requests Total Xfer Size Image Xfer Size Domains http://mobile.httparchive.org/
HIGH PERFORMANCE – LESS REQUESTS ¡  Less Requests §  Bundling §  Maximum single request each for JS & CSS §  Single bundle more efficient use of bandwidth §  Blocks page while bundle downloaded §  Blocks page while bundle parsed §  Consider GMail approach to defer parsing (discussed later) §  Image Sprites §  Single PNG image §  Data URI §  Supported by: iPhone, Android, Opera §  Not supported by: IE, Nokia Series 40 §  spriteme.org, css-sprit.es §  CSS3 for effects & ornaments (not images) §  Gradients, rounder corners, drop shadow, text shadow §  Avoid @font-face §  Size is between 10KB up to 4-5MB for Asian character sets §  Flash of un-styled text (FOUT) due to download & install §  6% of mobile pages use @font-face §  Aim at <= 1 requests §  We can do better than this….
HIGH PERFORMANCE – LESS REQUESTS ¡  Less Requests §  Inline scripts, css and images on first load §  Inline all resources, and send cookie §  Extract script, style and images into localStorage, update cookie §  Subsequent load check cookie §  If initial value §  no JavaScript or localStorage - return page with resources as external links (to utilize caching) §  If updated §  Output script to load resources from localStorage (at top of page) §  Bing §  1st request 54.9 KB §  2nd request 5.5 KB
HIGH PERFORMANCE – LESS REQUESTS ¡  Less Requests §  Application Cache §  <html manifest=“/manifest” >! §  Pros: §  Extremely fast §  Second page load 0 HTTP requests (for static content) §  Authoritative control of locally cached resources §  Cons: §  If file changes must update manifest file §  Makes page load asynchronous → second page load only §  Adaptive images → user cookie set on first load to determine image quality §  Double refresh issue → use updateready event on window.applicationCache and prompt user §  Atomic §  Impossible to version §  Buggy JS API §  Hard to invalidate §  Tip: §  Loads in order so CSS → PNG → JS §  Use NETWORK: * to make manifest “open”
HIGH PERFORMANCE – LESS REQUESTS ¡  Less Requests §  Application Cache
HIGH PERFORMANCE – LESS BY TES ¡  Less Bytes 500 Average Bytes per Page by Content Type (in KB) 400 300 200 100 0 Images Scripts Stylesheets HTML Other Total 16 14 Average Individual Response Size (in KB) 12 10 8 6 4 2 0 JPEG PNG GIF HTML JS CSS http://mobile.httparchive.org/
HIGH PERFORMANCE – LESS BY TES ¡  Less Bytes §  Simple semantic HTML Mobile Image Requests §  No divitis, classitis, iditis §  However: §  classes can improve css selector performance §  Ids can improve testability PNG §  Minify 24% §  HTML, CSS, JS JPEG §  Optimize Images 47% §  Use PNG instead of JPEG and GIF GIF §  GIFs for small images (i.e. <10x10 pixels) 29% §  JPEG for photographic-style images §  Maximize lossless compression §  JPEG: jpegtran, jpegoptim Other §  PNG: OptiPNG, PNGOUT 0% §  WebPageTest http://mobile.httparchive.org/
HIGH PERFORMANCE – LESS BY TES ¡  Less Bytes §  Adaptive Images §  Don’t scale images on the client §  Wastes bandwidth §  Requires device CPU §  Use @media, window.matchMedia(…), window.devicePixelRatio, etc §  -webkit-min-device-pixel-ratio (1 -> low res, 1.5 or 2 -> high res) §  For manifest file use capabilities cookie §  Server Scaling §  Multiple fixed breakpoints §  Allows for different designs (i.e. larger text on small images) §  Scale on demand in between major breakpoints §  Use CDN to “save” scaled images
HIGH PERFORMANCE – LESS BY TES ¡  Less Bytes §  Less JS §  Remove duplication §  Cost of parsing JavaScript about 1ms per 100KB §  Steve Souders – “every byte of JavaScript is 10x more expensive then everything else” §  Mini frameworks only §  Avoid → jQuery, Sencha, YUI, Dojo, etc §  It takes between 1 .5s and 8s to parse and download jQuer y over 3G §  jQuer yMobile wraps jQuer yUI with wraps jQuer y Core §  Use → XUI, Zepto, microJS, baseJS http://www.slideshare.net/mobile/Gomez_Inc/optimizing-web-and-mobile-site-performance-using-page-speed
HIGH PERFORMANCE – LESS BY TES ¡  Less Bytes §  Compression §  More consistent data will compress better §  CSS key-value pairs in same order §  HTML attribute in same order §  Use lowercase (or consistent) casing wherever possible §  Use consistent quoting for HTML attributes (always single or always double) §  Minify JS, CSS and HTML §  Avoid gzip for image or other binary files §  These files are already compressed
HIGH PERFORMANCE – LESS BY TES ¡  Less Bytes §  Less Cookies §  Remove / reduce cookies §  Cookie Free Domain §  Server-Side Cookies (ID only) §  Store data on server side and only send unique ID §  HIJAX §  Smaller page request §  Could also use Hashbang §  Twitter accepts both https://twitter.com/#!/foo and https://twitter.com/foo §  Only works with JavaScript enabled §  Its an ugly hack and looks like one §  History API §  history.pushState() & ‘popstate’ event §  Don’t forget forward and backwards isn’t a page reload, it’s a page display §  Endless Scrolling Pattern §  Only download subset §  Less bytes §  Much more complexity §  Only worth while for very large data sets §  Recycle elements that are scrolled off screen
HIGH PERFORMANCE – BANDWIDTH ¡  Bandwidth Efficiency §  Fit request into single packet (if possible) §  Packet size ~1500 bytes §  Parallelize downloads §  Avoid blocking HTML parsing §  JS at the bottom §  Avoid delaying resource download §  Avoid @import §  document.write(…) §  Max requests per domain §  Domain sharding §  Adds DNS lookup → >6 request per domain
HIGH PERFORMANCE – BANDWIDTH ¡  Bandwidth Efficiency §  Defer JS requests §  Progressive enhance so delay in JS is never a problem §  defer & async §  download and parse not delayed §  tells browser there is no document.write(…)! §  async §  executes after download §  execution order not guaranteed §  defer §  executes after parsing http://peter.sh/experiments/asynchronous-and-deferred-javascript-execution-explained/
HIGH PERFORMANCE – BANDWIDTH ¡  Bandwidth Efficiency §  Defer JS requests §  Downloading JS asynchronously §  XHR Eval §  XHR Injection §  Script in iframe §  Script DOM element §  document.write(…) §  Load scripts after onload to guarantee loaded asynchronous download
HIGH PERFORMANCE – BANDWIDTH ¡  Bandwidth Efficiency §  Eager loading §  Download in background and store in localStorage §  Mobile Web: <a class="eager" … />! §  Chromium: <link rel=“prerender” … />! §  Avoid bad requests (i.e. 404) §  7% mobile pages have (4xx) errors §  Avoid redirects §  73% mobile pages have (3xx) redirects §  If you can’t avoid cache §  Language redirect for Accept-Language (see details on caching later) §  Expires <= Date (to disable HTTP/1 .0 caches that don’t support Var y) §  Cache-Control: max-age >= 1 year §  Var y: Accept-Language http://mobile.httparchive.org/
HIGH PERFORMANCE – BANDWIDTH ¡  Bandwidth Efficiency §  Dynamic Update http://mobilehtml5.org/
HIGH PERFORMANCE – BANDWIDTH ¡  Bandwidth Efficiency §  Dynamic Update §  AJAX Polling §  Long Polling §  Server Side Events §  Web Sockets §  JSON vs HTML fragments §  Trade-off §  Less bytes on network §  Identical fixed network costs §  Much more complex JavaScript code that must work across multiple devices §  HTML fragment approach → simple identical JavaScript universally across the site §  JSON → custom JavaScript for ever y item of updatable content
HIGH PERFORMANCE – LESS LATENCY ¡  L e s s L a t e n c y §  Less server time §  Execute backend calls in parallel §  Avoid synchronization §  Threads §  DB (i.e. locking) §  NoSQL §  Eventual Consistency §  Use Futures to only block when absolutely required §  ETag → short circuit backend tasks §  Flush header while waiting for backend calls §  Allows CSS to be downloaded on client in parallel with backend calls §  HTTP/1.1 §  Trailer header allows addition of Content-Length, Last-Modifier and ETag with Transfer-Encoding: chunked §  Servlet 3.0 does NOT support this!! §  Under load scaling §  Avoid “too many” threads per request §  Threads should not be blocked waiting (i.e. IO / locks) §  No conversation state §  Must be managed across servers §  Session replication §  Sticky sessions §  Some state exists but not held on web server §  Decouple and isolates problem §  Separation of concerns §  Better encapsulation §  Improves opportunity for graceful degradation §  Web Tier Persistence §  Transient User Data (i.e. shopping basket, web UI preferences)
HIGH PERFORMANCE – LESS LATENCY ¡  Less Latency §  Minimize DNS lookups §  Mobile Web analytics request §  230ms DNS lookup §  76ms TCP + HTTP connection §  58ms server time §  Flush Early §  Check flush isn’t buffered §  Apache, Network (i.e. Netscaler), gzip §  Only works on HTTP/1.1 connections §  Uses Transfer-Encoding: chunked! §  Caching §  Make pages cacheable §  Avoid cookie or header driven content §  Except User- Agent, Accept-Language, Accept-Encoding §  Use path variable instead of query parameters §  Most proxy caches do not cache resources with quer y parameters §  i.e. only latest version of Squid fixes this §  Use fingerprinting to dynamically control caching
HIGH PERFORMANCE – LESS LATENCY ¡  L e s s L a t e n c y §  Caching §  Expires (HTTP/1.0) §  Date when resource is stale §  Cache-Control (HTTP/1.1) §  Overrides Expires header §  max-age - how long resource is fresh (in seconds) §  public, private – where item is cacheable §  no-store – never cache §  no-cache – always revalidate §  must-revalidate – revalidate if stale §  s-maxage, proxy-revalidate – proxy servers settings §  Vary (HTTP/1.1) §  Allows cached items to be varied by header §  If using disable HTTP/1.0 caches by Expires <= Date §  Tips §  Maximize freshness → 1 year §  Android clears cache based on length of freshness → >10 years §  Last-Modified §  Last time resource modified §  If-Modified-Since – conditional GET §  If-Unmodified-Since – conditional PUT, DELETE §  ETag §  Ensure consistency across multiple web servers §  Unique identifier for specific resource version §  If-None-Match – conditional GET §  If-Match – conditional PUT, DELETE §  Favor semantic “week validator” over byte level “strong validator” §  Week Validator enables short-circuiting the server HTML generation §  Trailer: ETag supports Transfer-Encoding: chunked (not supported by Servlet 3.0) §  304 Not Modified §  Last-Modified §  ETag
HIGH PERFORMANCE – LESS LATENCY ¡  Less Latency §  Caching §  Not used enough 45% Cache-Control: max-age (days) 40% 35% 30% 25% 20% 15% 10% 5% 0% None t <= 0 0 < t <= 1 1 < t <= 30 30 < t <= 365 365 < t http://mobile.httparchive.org/
HIGH PERFORMANCE – LESS LATENCY ¡  Less Latency §  Caching §  Browser §  Limited size §  Average mobile page size 550KB → < 7 pages to full reload OS (Device) Component Total Last-Modified ETag Survives Power Cycle Android 2.1 (Nexus One) 2MB 2MB Yes Yes Yes Android 2.2 (Glaxay S) 4MB 4MB Yes Yes Yes Android 2.3 (Nexus S) 4MB 4MB Yes Yes Yes Safari, iOS 3.1.3 (1st-gen iPhone) 0b 0b No No No Safari, iOS 3.2 (iPad) 26KB 282KB Yes Yes No Safari, iOS 4.0 (iPhone 3GS) 51KB 1MB Yes Yes No Safari, iOS 4.0 (iPhone 4) 102KB 2MB Yes Yes No webOS 1.4.1 (Palm Pre Plus) 1MB ? No No Yes http://www.yuiblog.com/blog/2010/06/28/mobile-browser-cache-limits/ http://www.blaze.io/mobile/understanding-mobile-cache-sizes/ http://mobile.httparchive.org/trends.php#bytesTotal&reqTotal
HIGH PERFORMANCE – LESS LATENCY ¡  Less Latency §  Caching §  Reverse Proxy (i.e. ISP) §  Vary: Accept-Encoding §  many proxy caches do not detect Content-Encoding correctly §  Cookies §  Generally public caches won’t cache pages with cookies §  If they do cookies will be shared §  Edge / Gateway (i.e. CDN) §  Edge Side Include (ESI) §  Dynamic content assembly in cache §  Add icons: §  favicon.ico §  apple-touch-icon.png §  apple-touch-icon-precomposed.png
HIGH PERFORMANCE – LESS LATENCY ¡  Less Latency §  Offline Storage §  Single origin policy §  No freshness or cache eviction §  No versioning §  No request → very fast and works offline §  Manifest file §  see earlier slides §  Web Storage §  Local Storage (or Session Storage) §  key/value storage of strings §  Simple but no query language §  No locks or transactions §  No indexes or complex data structures §  Slow, synchronous → blocking §  Up to 5MB §  Very fast §  Synchronous §  Only accessible from JavaScript §  Indexed DB §  Flat-file DB §  Hierarchical key/value persistence §  Basic indexing §  Fully asynchronous §  Supports indexed filtering and lookup §  DB level transactions & locking §  Up to 5MB, then prompt user for more §  Only accessible from JavaScript §  Web SQL Database §  SQLite in browser §  select, insert, update, delete, joins, inner selects, etc §  Up to 5MB, then prompt user for more §  Standard dropped by W3C §  Slow §  Only accessible from JavaScript §  File API
HIGH PERFORMANCE – LESS LATENCY ¡  Less Latency §  Radio Resource Control §  HEAD request every 2-3 seconds to keep cell connection live §  Drains battery and adds congestion so don’t poll forever §  Page Beacons (Analytics) §  Make asynchronous §  Inject 1x1.gif §  Separate domain §  Avoid site cookies infecting request §  Avoid analytics cookies infecting site §  304 response §  Maximize benefit §  Page flow §  Device capabilities §  @media / JS cookie §  User- A gent §  Connection Type §  navigator.connection.type! §  ETHERNET, WIFI, CELL_2G, CELL_3G, …! §  Carrier §  Massive’s Operator Identification Platform
HIGH PERFORMANCE – PAGE RENDER ¡  Faster Page Render §  Simple semantic DOM §  For every element (i.e. in Chrome) §  Node in DOM Tree §  RenderObject in RenderTree §  Efficient CSS selectors §  Avoid universal rules §  Don’t qualify id rules with tag names or classes §  Don’t qualify class rules with tag names §  Make rules as specific as possible §  Avoid descendant selectors (especially Tag or Universal) §  Apply rules at the highest level and allow inheritance §  Remove redundant qualifies §  ID selector with class or tag §  Class selector with tag
HIGH PERFORMANCE – PAGE RENDER ¡  Faster Page Render §  CSS in head §  External or inline style blocks in body can cause reflow or FOUC §  Allows page to render progressively §  External stylesheets block rendering until downloaded and parsed §  Use hardware accelerated CSS animations §  Gets GPUs directly involved with compositing §  Avoids slow video to system memory copies §  Less redraws of complete screen §  only compositing layer redraw and recomposition §  Use CSS instead of JS animation §  Specify image dimensions §  Avoids reflow after image downloaded §  Specify character set §  Avoids browser auto detecting (and making / correcting mistakes) §  Timers §  Lots of >1s timers §  Very few (i.e. one) <500ms timers http://googlecode.blogspot.com/2009/07/gmail-for-mobile-html5-series-using.html
HIGH PERFORMANCE – INTERACTION ¡  Faster Interaction §  Defer JS parsing §  100ms per 1KB §  Make browser ignore code §  Comments §  None script element §  When needed use eval(…)! §  Avoid blocking single UI Thread §  Long-running JS = Unresponsive UI §  Asynchronous §  Use events §  Synthetic (via setTimeout in framework) §  Native §  Script Yeilding §  setTimeout(function() {…}, 50)! §  Different browsers have different timer resolutions / issues §  Short timeouts can significantly shorten battery life §  setImmediate(function() {…})! §  Add to back of UI Thread Queue (i.e. no timer) §  Not supported yet (only in IE 10) §  WebWorkers §  Asynchronous, doesn’t block UI Thread §  Data is serialized into and out of worker §  No access to DOM §  Separate execution environment
HIGH PERFORMANCE – INTERACTION ¡  Faster Interaction §  Touch delay §  Click event delayed between 300 and 500ms §  ontouchstart → ontouchend (with ontouchdrag within error margin) §  Event Handlers §  Event handlers on outer container §  Use event bubble §  Avoid lots of smaller event handlers
HIGH PERFORMANCE – INTERACTION ¡  Faster Interaction §  Touch §  Work directly with content §  Avoid button indirection §  Although gesture support currently limited §  Limited touch events §  touchstart, touchmove, touchend §  Fat fingers §  Fitt’s Law §  difficulty ∝ distance, size §  Large buttons §  Inactive margin §  Right first time
HIGH PERFORMANCE – PERCEPTION ¡  Improve Perception §  Flush early §  Visual feedback to user §  Button click changes color §  Image Interlacing §  Visible image after only 1/64 downloaded §  Adds ~15% §  Remove address bar §  While JavaScript is executing in background §  After onload §  window.scrollTo(0, 1);! §  If page height < window height then increase page height first to allow scroll
TOOLS – DEBUGGING ¡  Debugging §  Chrome Internals §  chrome://net-internals §  chrome://appcache-internals/ §  chrome://profiler/ §  For full list see chrome://chrome-urls/ §  Works on Chrome for Android §  Firebug §  Desktop only §  BlackBerry Browser §  Remote debugging §  Smar tphone 7.0+ §  PlayBook §  Web Inspector §  http://trac.webkit.org/wiki/WebInspector §  Wienre §  http://phonegap.github.com/weinre/ §  DragonFly (for Opera Mobile) §  WebKit Remote Debugging §  http://www.webkit.org/blog/1620/webkit-remote-debugging/ §  Adobe Shadow §  Synchronize desktop browser with multiple mobile browsers §  http://labs.adobe.com/technologies/shadow/
TOOLS – PERFORMANCE ¡  Performance / Analysis §  Chrome Inspector §  JS & CSS Profiler §  PageSpeed §  Chrome Inspector §  Firebug §  YSlow §  Chrome Inspector §  Firebug §  Mobile Perf Bookmarklets §  YSlow and other tools §  http://stevesouders.com/mobileperf/mobileperfbkm.php §  PCAP Web Performance Analyzer §  http://pcapperf.appspot.com/ §  Analyse packets → Waterfall & WebPageTest §  Shark for Root §  Android packet sniffer §  Works with 3G §  Analyse results (PCAP file) with pcapperf §  Speed Tracer §  Chrome Inspector Plugin §  Analyses all page interaction (CSS & JS) §  3PMobile §  On device browser §  Network Waterfall §  Browser Event (i.e. image loading time, CSS processing time) §  dynaTrace §  JS performance analyser §  http://ajax.dynatrace.com/ §  Loadtimer §  Tests time for full load of multiple URLs §  http://www.stevesouders.com/blog/2011/12/01/loadtimer-a-mobile-test-harness/ §  WebPageTest §  Waterfall of network traffic §  Timing of page load event adds noise
TOOLS – EMULATORS ¡  Emulators §  www.mobilexweb.com/emulators ¡  Remote Labs §  DeviceAnywhere (bought by WebPageTest) §  deviceanywhere.com §  PerfectoMobile §  perfectomobile.com §  WebPageTest §  Samsung §  Free hosting of Samsung devices §  http://developer.samsung.com/remoteTestLab.do §  Nokia §  Free hosting of Nokia devices ¡  Experimental §  Cuzillion §  Build up different types of page §  internal / external CSS §  internal / external JS §  images §  Good for testing and learning about new devices / browsers §  http://stevesouders.com/cuzillion/

More Related Content

PDF
High Performance Mobile Web
byJames D Bloom
 
PDF
High Performance Mobile Web
byJames D Bloom
 
PPTX
Quantifying The Mobile Difference
byGuy Podjarny
 
PPTX
Performance Implications of Mobile Design
byGuy Podjarny
 
PPTX
Imagesandvideo tallinn
byDoug Sillars
 
PDF
Jon Arne Sæterås - Give Responsive Design a mobile performance boost
byDevConFu
 
PDF
Faster web pages
byDavid Rodenas
 
PPTX
Imagesandvideo stockholm fastandbeautiful
byDoug Sillars
 
High Performance Mobile Web
byJames D Bloom
 
High Performance Mobile Web
byJames D Bloom
 
Quantifying The Mobile Difference
byGuy Podjarny
 
Performance Implications of Mobile Design
byGuy Podjarny
 
Imagesandvideo tallinn
byDoug Sillars
 
Jon Arne Sæterås - Give Responsive Design a mobile performance boost
byDevConFu
 
Faster web pages
byDavid Rodenas
 
Imagesandvideo stockholm fastandbeautiful
byDoug Sillars
 

What's hot

PDF
Happy Browser, Happy User! NY Web Performance Meetup 9/20/19
byKatie Sylor-Miller
 
PPTX
Imagesandvideo stockholm webmeetup
byDoug Sillars
 
PPT
Shopzilla - Performance By Design
byTim Morrow
 
PPTX
Image-ine That: Image Optimization for Conversion Maximization
byYottaa
 
PPSX
10+апреля+лучшие+практики+и+инновации+вадим+береговский+akamai
byelenae00
 
PDF
Raiders of the Fast Start: Frontend Performance Archaeology - Performance.now...
byKatie Sylor-Miller
 
PDF
7 Habits of Exceptional Performance
byNicole Sullivan
 
PDF
Extreme Web Performance for Mobile Devices - Velocity NY
byMaximiliano Firtman
 
PDF
Inside Picnik: How We Built Picnik (and What We Learned Along the Way)
byjjhuff
 
PPTX
Performance Implications of Mobile Design (Perf Audience Edition)
byGuy Podjarny
 
PPTX
Step by Step Mobile Optimization
byGuy Podjarny
 
PDF
Recipes for the Perfect PI v2.0
bySascha Wenninger
 
PPT
After YSlow "A"
byNicole Sullivan
 
PPTX
Velocity NY 2013 - From Slow to Fast: Improving Performance on Intuit Website...
byJay Hung
 
KEY
Developing High Performance Web Apps - CodeMash 2011
byTimothy Fisher
 
PDF
Web Performance & You - HighEdWeb Arkansas Version
byDave Olsen
 
PPTX
Mot cph when its just too slow
byDoug Sillars
 
PPTX
A Beard, An App, A Blender
byedm00se
 
POTX
Its timetostopstalling sw_mobile_bristol
byDoug Sillars
 
PDF
IBM Connect 2016 - AD1548 - Building Responsive XPages Applications
bybeglee
 
Happy Browser, Happy User! NY Web Performance Meetup 9/20/19
byKatie Sylor-Miller
 
Imagesandvideo stockholm webmeetup
byDoug Sillars
 
Shopzilla - Performance By Design
byTim Morrow
 
Image-ine That: Image Optimization for Conversion Maximization
byYottaa
 
10+апреля+лучшие+практики+и+инновации+вадим+береговский+akamai
byelenae00
 
Raiders of the Fast Start: Frontend Performance Archaeology - Performance.now...
byKatie Sylor-Miller
 
7 Habits of Exceptional Performance
byNicole Sullivan
 
Extreme Web Performance for Mobile Devices - Velocity NY
byMaximiliano Firtman
 
Inside Picnik: How We Built Picnik (and What We Learned Along the Way)
byjjhuff
 
Performance Implications of Mobile Design (Perf Audience Edition)
byGuy Podjarny
 
Step by Step Mobile Optimization
byGuy Podjarny
 
Recipes for the Perfect PI v2.0
bySascha Wenninger
 
After YSlow "A"
byNicole Sullivan
 
Velocity NY 2013 - From Slow to Fast: Improving Performance on Intuit Website...
byJay Hung
 
Developing High Performance Web Apps - CodeMash 2011
byTimothy Fisher
 
Web Performance & You - HighEdWeb Arkansas Version
byDave Olsen
 
Mot cph when its just too slow
byDoug Sillars
 
A Beard, An App, A Blender
byedm00se
 
Its timetostopstalling sw_mobile_bristol
byDoug Sillars
 
IBM Connect 2016 - AD1548 - Building Responsive XPages Applications
bybeglee
 

Similar to Mobile Web Best Practices

PDF
Drupalcamp New York 2009
byTom Deryckere
 
PDF
Mobile Web & HTML5 Performance Optimization
byMaximiliano Firtman
 
PDF
Siruna session at Drupalcon Paris 2009
byTom Deryckere
 
PPT
Mobile browser testing v1.0
byRavindran Antonysamy
 
PDF
Web Browser Demystified
byRohit Joshi
 
PDF
Building Mobile Websites with Joomla
byTom Deryckere
 
PDF
Best practices for delivering quality web experiences
byBen Mantooth
 
PPTX
Mobile Mantras
byhannerlib
 
PPTX
Mobile Mantras: XD Best Practices for Mobile Development
byRob Fitzgibbon
 
PDF
Mobile Web High Performance
byMaximiliano Firtman
 
PDF
Mobile CMS - CMSExpo 2010
byTom Deryckere
 
PDF
Developing for Mobile Web
byBarbara Bermes
 
KEY
Jonathan snook - fake-it
byStarTech Conference
 
KEY
Tuenti Mobile Development
byTuenti
 
PDF
The Web is the platform, @lxjs
byharicot
 
PDF
The mobile browser world
byPeter-Paul Koch
 
KEY
Mobile Internet
byMichaël Uyttersprot
 
PPTX
mobile browsers.pptx
byMohitjoshi305593
 
PPT
Designing for Mobile Devices
byOxonDigital
 
PDF
Cross Platform Mobile Developmemnt
bySoutom Dhara
 
Drupalcamp New York 2009
byTom Deryckere
 
Mobile Web & HTML5 Performance Optimization
byMaximiliano Firtman
 
Siruna session at Drupalcon Paris 2009
byTom Deryckere
 
Mobile browser testing v1.0
byRavindran Antonysamy
 
Web Browser Demystified
byRohit Joshi
 
Building Mobile Websites with Joomla
byTom Deryckere
 
Best practices for delivering quality web experiences
byBen Mantooth
 
Mobile Mantras
byhannerlib
 
Mobile Mantras: XD Best Practices for Mobile Development
byRob Fitzgibbon
 
Mobile Web High Performance
byMaximiliano Firtman
 
Mobile CMS - CMSExpo 2010
byTom Deryckere
 
Developing for Mobile Web
byBarbara Bermes
 
Jonathan snook - fake-it
byStarTech Conference
 
Tuenti Mobile Development
byTuenti
 
The Web is the platform, @lxjs
byharicot
 
The mobile browser world
byPeter-Paul Koch
 
Mobile Internet
byMichaël Uyttersprot
 
mobile browsers.pptx
byMohitjoshi305593
 
Designing for Mobile Devices
byOxonDigital
 
Cross Platform Mobile Developmemnt
bySoutom Dhara
 

Recently uploaded

PDF
Top 7 Manufacturing Software for Small Businesses Boosting Growth in 2025
byEnvertis Software Solutions
 
PDF
Security Technologys: Access Control, Firewall, VPN
byShielaLasala
 
PDF
Accelerating Responsible AI Adoption in Public Sector and Private Organizations.
byYasir Naveed Riaz
 
PDF
The Ultimate Guide to Problem Management Dashboards for IT Teams.pdf
byomnex systems
 
PPTX
Ethics in AI - Artificial Intelligence Fundamentals.pptx
byemenyiblessing
 
DOCX
Introduction to the World of Computers (Hardware & Software)
byALIABBAS ABASOV
 
PDF
Knowing and Doing: Knowledge graphs, AI, and work
bymarainglezakis1
 
PDF
Agentic Automation for Testers – A Hands-On Deep Dive
byUiPathCommunity
 
PDF
Unser Jahresrückblick – MarvelClient in 2025
bypanagenda
 
PDF
Empowering Productivity with Clever Prompts and Intelligent Agents
byUni Systems S.M.S.A.
 
PDF
TrustArc Webinar - Looking Ahead: The 2026 Privacy Landscape
byTrustArc
 
PDF
Unlocking the Power of Salesforce Architecture: Frameworks for Effective Solu...
byvarsha30tiwari
 
PPTX
The Landscape of Computer Software Development Companies
byYash Singh
 
PDF
Making Sense of Raster: From Bit Depth to Better Workflows
bySafe Software
 
PDF
Igniting the Future: Copilot trends, agentic transformation and product roadm...
byUni Systems S.M.S.A.
 
PDF
Greetings All Students Update 3 by Mia Corp
by©LDMMIA, ©Reiki Yoga
 
PDF
TPPmark2025 Kenta Inoue's answer 12/04/2025
byKenta Inoue
 
PDF
Digit Expo 2025 - EICC Edinburgh 27th November
byRay Bugg
 
PDF
TrustArc Webinar - Assessing AI Risk with Confidence
byTrustArc
 
PDF
Vibe Coding vs. Spec-Driven Development [Free Meetup]
byHaim Michael
 
Top 7 Manufacturing Software for Small Businesses Boosting Growth in 2025
byEnvertis Software Solutions
 
Security Technologys: Access Control, Firewall, VPN
byShielaLasala
 
Accelerating Responsible AI Adoption in Public Sector and Private Organizations.
byYasir Naveed Riaz
 
The Ultimate Guide to Problem Management Dashboards for IT Teams.pdf
byomnex systems
 
Ethics in AI - Artificial Intelligence Fundamentals.pptx
byemenyiblessing
 
Introduction to the World of Computers (Hardware & Software)
byALIABBAS ABASOV
 
Knowing and Doing: Knowledge graphs, AI, and work
bymarainglezakis1
 
Agentic Automation for Testers – A Hands-On Deep Dive
byUiPathCommunity
 
Unser Jahresrückblick – MarvelClient in 2025
bypanagenda
 
Empowering Productivity with Clever Prompts and Intelligent Agents
byUni Systems S.M.S.A.
 
TrustArc Webinar - Looking Ahead: The 2026 Privacy Landscape
byTrustArc
 
Unlocking the Power of Salesforce Architecture: Frameworks for Effective Solu...
byvarsha30tiwari
 
The Landscape of Computer Software Development Companies
byYash Singh
 
Making Sense of Raster: From Bit Depth to Better Workflows
bySafe Software
 
Igniting the Future: Copilot trends, agentic transformation and product roadm...
byUni Systems S.M.S.A.
 
Greetings All Students Update 3 by Mia Corp
by©LDMMIA, ©Reiki Yoga
 
TPPmark2025 Kenta Inoue's answer 12/04/2025
byKenta Inoue
 
Digit Expo 2025 - EICC Edinburgh 27th November
byRay Bugg
 
TrustArc Webinar - Assessing AI Risk with Confidence
byTrustArc
 
Vibe Coding vs. Spec-Driven Development [Free Meetup]
byHaim Michael
 

Mobile Web Best Practices

  • 1.
    MOBILE WEB BEST PRACTICES http://about.me/jamesdbloom http://blog.jamesdbloom.com JamesDBloom
  • 2.
    PERCENTAGE OF MOBILEWEB 50% 45% 40% 35% 30% 25% 20% 15% 10% 5% 0% http://www.tecmark.co.uk/wp-content/uploads/2011/08/Mobile-and-UK-Web-Traffic-August-2011.pdf
  • 3.
    WHAT I’M TALKINGABOUT ¡  The Problem §  What’s different and hard about mobile ¡  The Solution §  Adaptive Techniques §  Mobile First §  Avoid JavaScript §  Device Detection §  Adaptive Design §  Progressive Enhancement §  High Performance §  Network §  Less Request §  Less Bytes §  Bandwidth Efficiency §  Less Latency §  Sof tware §  Faster Page Rendering §  Faster Interaction §  User §  Faster Interaction §  Improve Perception ¡  Tools §  Debugging §  Performance §  Emulators
  • 4.
    WHAT’S MOBILE –THE PROBLEM ¡  Network §  Different types of network: §  GSM, GPRS, WCDMA, UMTS, EDGE, HSPA, UMTS, LTE, WiMAX §  High latencies §  300ms to 1000ms §  High packet loss §  From 0.1% to >20% §  Each time triggers TCP Slow Start again §  Radio Resource Control (RRC) §  Adds 1.5s to 2s to initiate connection §  Total Connection Time §  RRC + DNS + TCP 3-way handshake + TCP slow start + HTTP Request §  SSL adds even more §  Bandwidth §  3G §  Download: ~1Mbps Upload: ~0.5 Mbps §  Broadband §  Download: ~9Mbps Upload: ~2Mbps
  • 5.
    WHAT’S MOBILE –THE PROBLEM ¡  Device §  Rapidly changing, widely diverse hardware §  “2500 different devices on Facebook per month” - Tobie Langel 7000 SunSpider JS Benchmark (in ms) for some of the devices released in the last year 6000 5000 4000 3000 2000 1000 0 http://www.anandtech.com/show/5584/htcs-new-strategy-the-htc-one
  • 6.
    WHAT’S MOBILE –THE PROBLEM ¡  Device §  Slow CPU §  10x slower then desktop §  JavaScript that runs for 100ms on desktop will take ~1s on mobile §  Low memory §  Mobile RAM in MB §  Desktop RAM in GB §  Small screen §  Navigation §  Touch §  Gestures: Tap, Double Tap, Drag, Flick, Pinch, Spread, Press, Press & Tap, Press & Drag, Rotate, … §  More direct interaction §  But different on each device §  Focus §  Pointer Google Tech Talk - November 10, 2011 - Guy Podjarny
  • 7.
    WHAT’S MOBILE –THE PROBLEM ¡  Software §  Rapidly changing, widely diverse browsers and operating systems No Browser Creator No Browser Creator 1 Android Browser Google 21 Obigo Browser Obigo AB 2 Apollo Team Apollo 22 Opera Mini Opera Software 3 BlackBerry Browser Research in Motion 23 Opera Mobile Opera Software 4 Blazer Palm 24 Palm HP 5 Bada Samsung 25 Pixo Sun Microsystems 6 Chrome for Android Google 26 PlayStation Portable Sony 7 Classilla Cameron Kaiser 27 Polaris Browser Infraware 8 Deepfish Microsoft 28 Safari Apple 9 Dolphin Browser MoboTap 29 Symbian / S60 Nokia 30 Skweezer 10 Firefox for mobile Mozilla Foundation 31 Skyfire Skyfire Labs 11 ibisBrowser ibis 32 Skyfire Mobile Browser Skyfire 12 Internet Explorer Mobile Microsoft 33 Steel 13 Iris Browser Torch Mobile 34 Teashark 14 JOCA InteracT!V 35 Tristit 15 Kindle Basic Web Amazon.com 36 UC Browser UC Mobile 16 MIB Motorola 17 Minimo Mozilla Foundation 37 uZard Web Logicplant 18 Myriad / Openwave Myriad Group 38 Vision Mobile Browser Novarra 19 NetFront ACCESS 39 WebOS Browser Palm 20 Nokia Series 40 Browser Nokia 40 WinWAP Winwap Technologies
  • 8.
    WHAT’S MOBILE –THE PROBLEM ¡  Sof tware §  Changing rapidly §  Different navigation method §  Proxied vs Direct §  Proxied – Opera Mini, Kindle Fire §  Direct – all others §  HTTP vs SPDY §  SPDY – Kindle Fire, Chrome for Android §  HTTP – all others §  Process models §  Multi Process – Chrome for Android §  Single Process - all others §  Small Cache §  2-4MB §  Connections §  Max Total §  Max per host §  Pipelined §  Multiple requests over a single socket without waiting for a response §  Problems with proxies and head-of-line blocking
  • 9.
    WHAT’S MOBILE –THE PROBLEM ¡  Users §  Distracted §  i.e. walking down the street §  Shorter interactions §  i.e. waiting for a bus §  Touch §  Fat fingers §  Gestures (are they all intuitive?) §  Targeted tasks §  i.e. what are the local restaurants? §  Expectations §  Web that “pretends” to be app is likely to disappoint §  85% - “customers expect to be able to shop on their phones and want the experience to be as good or better than on a computer” http://www.nytimes.com/2011/04/18/technology/18mobile.html?_r=3
  • 10.
    MOBILE FIRST ¡  Mobilefirst §  Start simple and build up §  Test for presence (and function) of all APIs §  If it exists it may not work correctly §  Everything should fallback §  local storage → local variable → no storage §  push & pop state → hash bang fall → page refresh §  auto refresh → manual refresh button §  Avoid native events → use synthetic events §  minimizes difference between browsers ¡  Forget pixel perfect §  Fluid grids §  Adaptive design
  • 11.
    AVOID JAVASCRIPT ¡  AvoidJS → Middle Tier §  Why are we re-implementing the browser? §  Maximize stability across devices, even unknown devices §  Ensure site works without JS §  You control execution environment §  More reliable §  Easier to test §  Limit device dependent code §  Easier to automate tests §  Simplify browser interaction helps Selenium §  More code covered by Java unit tests §  Easier to optimize §  Scale out / up §  Easier to diagnose issues §  Well understood §  Better tools
  • 12.
    ADAPT – DEVICEDETECTION ¡  Breakpoints §  Major breakpoint on server §  Chose fixed high level breakpoints §  Mobile §  Tablet §  Desktop §  TV §  Avoid serving desktop site on mobile width §  Too heavy §  Too slow to download §  Too slow to render §  Not optimized correctly §  Adapt §  Content §  Layout §  Features §  Page weight §  Caching §  Vary: User-Agent!
  • 13.
    ADAPT – DEVICEDETECTION ¡  Breakpoints §  How to select major breakpoint §  Headers §  User-Agent §  Accept §  x-wap-profile / Profile §  UAProfile with device capabilities and preferences (W3C Ubiquitous Web Applications Working Group – closed July 2010) §  OperaMini §  Device Libraries §  WURFL §  Open Source §  Slightly limited information §  Based on UAProfile §  DeviceAtlas §  Started by Ericsson, Google, GSM Association, Microsoft, Nokia, Samsung, T-Mobile, Telecom, Telecom Italia, Visa and Vodafone §  51Degrees §  Build into ASP.NET and MVC.NET §  DetectRight §  Custom DB §  Augment existing device library §  Log capabilities (i.e. cookie / analytics / JS) §  Tools §  Spring Mobile §  WURFL §  Apache Mobile Filter §  WURFL §  51Degrees §  DetectRight
  • 14.
    ADAPT – ADAPTIVEDESIGN ¡  Breakpoints §  Minor breakpoint on client §  @media §  Screen size, resolution & pixel density §  Fluid grids, dif ferent columns, adapt image size (see earlier slide) §  navigator.connection.type! §  ETHERNET, WIFI, CELL_2G, CELL_3G, …! §  Send to server §  Cookie §  JS §  Landscape vs portrait §  Consider width of screen not width of viewport §  Test for presence (and function) of all APIs §  If it exists it may not work correctly §  Everything should fallback §  local storage → local variable → no storage §  push & pop state → hash bang fall → page refresh §  auto refresh → manual refresh button §  Indicate it’s a mobile website
  • 15.
    ADAPT – PROGRESSIVEENHANCEMENT ¡  Progressive Enhancement §  Test for presence (and function) of all APIs §  If it exists it may not work correctly HTML5 §  Everything should fallback §  local storage → local variable → no storage §  push & pop state → hash bang fall → page AJAX / HIJAX refresh §  auto refresh → manual refresh button §  HTML5 CSS Extensions §  Not fully supported §  mobilehtml5.org Basic JavaScript §  www.modernizr.com §  caniuse.com §  www.browserscope.org Advanced CSS §  www.quirksmode.org §  PolyFills Simple CSS §  Add weight §  Better to except not supported and degrade HTML
  • 16.
    HIGH PERFORMANCE –WHY? ¡  47% expect page load < 2s ¡  40% abandon sites with page load > 3s ¡  +1s → -7% conversion rate ¡  if $100,000 per day, +1s → $2.5 million lost sales ever y year ¡  Bing §  +1s → -4% revenue ¡  Google §  0.4s to 0.9s → -25% searches (-$2.5 billion revenue) ¡  Firefox §  -2.2s download page → +15% downloads (+1.7 million extra / year) ¡  Shopzilla §  -5s → +7-12% revenue, -50% hardware cost ¡  Wallmart & Amazon §  every -100ms → +1% revenue http://blog.kissmetrics.com/loading-time/ http://blog.mozilla.com/metrics/category/website-optimization/ http://radar.oreilly.com/2009/07/velocity-making-your-site-fast.html http://www.webperformancetoday.com/2012/02/28/4-awesome-slides-showing-how-page-speed-correlates-to-business-metrics-at-walmart-com/
  • 17.
    HIGH PERFORMANCE –LESS REQUESTS ¡  Less Requests 0.5 Highest Correlation to Load Time 0.45 0.4 0.35 Total Requests Image Requests Total Xfer Size Image Xfer Size Domains 0.5 Highest Correlation to Render Time 0.45 0.4 0.35 0.3 Total Requests Image Requests Total Xfer Size Image Xfer Size Domains http://mobile.httparchive.org/
  • 18.
    HIGH PERFORMANCE –LESS REQUESTS ¡  Less Requests §  Bundling §  Maximum single request each for JS & CSS §  Single bundle more efficient use of bandwidth §  Blocks page while bundle downloaded §  Blocks page while bundle parsed §  Consider GMail approach to defer parsing (discussed later) §  Image Sprites §  Single PNG image §  Data URI §  Supported by: iPhone, Android, Opera §  Not supported by: IE, Nokia Series 40 §  spriteme.org, css-sprit.es §  CSS3 for effects & ornaments (not images) §  Gradients, rounder corners, drop shadow, text shadow §  Avoid @font-face §  Size is between 10KB up to 4-5MB for Asian character sets §  Flash of un-styled text (FOUT) due to download & install §  6% of mobile pages use @font-face §  Aim at <= 1 requests §  We can do better than this….
  • 19.
    HIGH PERFORMANCE –LESS REQUESTS ¡  Less Requests §  Inline scripts, css and images on first load §  Inline all resources, and send cookie §  Extract script, style and images into localStorage, update cookie §  Subsequent load check cookie §  If initial value §  no JavaScript or localStorage - return page with resources as external links (to utilize caching) §  If updated §  Output script to load resources from localStorage (at top of page) §  Bing §  1st request 54.9 KB §  2nd request 5.5 KB
  • 20.
    HIGH PERFORMANCE –LESS REQUESTS ¡  Less Requests §  Application Cache §  <html manifest=“/manifest” >! §  Pros: §  Extremely fast §  Second page load 0 HTTP requests (for static content) §  Authoritative control of locally cached resources §  Cons: §  If file changes must update manifest file §  Makes page load asynchronous → second page load only §  Adaptive images → user cookie set on first load to determine image quality §  Double refresh issue → use updateready event on window.applicationCache and prompt user §  Atomic §  Impossible to version §  Buggy JS API §  Hard to invalidate §  Tip: §  Loads in order so CSS → PNG → JS §  Use NETWORK: * to make manifest “open”
  • 21.
    HIGH PERFORMANCE –LESS REQUESTS ¡  Less Requests §  Application Cache
  • 22.
    HIGH PERFORMANCE –LESS BY TES ¡  Less Bytes 500 Average Bytes per Page by Content Type (in KB) 400 300 200 100 0 Images Scripts Stylesheets HTML Other Total 16 14 Average Individual Response Size (in KB) 12 10 8 6 4 2 0 JPEG PNG GIF HTML JS CSS http://mobile.httparchive.org/
  • 23.
    HIGH PERFORMANCE –LESS BY TES ¡  Less Bytes §  Simple semantic HTML Mobile Image Requests §  No divitis, classitis, iditis §  However: §  classes can improve css selector performance §  Ids can improve testability PNG §  Minify 24% §  HTML, CSS, JS JPEG §  Optimize Images 47% §  Use PNG instead of JPEG and GIF GIF §  GIFs for small images (i.e. <10x10 pixels) 29% §  JPEG for photographic-style images §  Maximize lossless compression §  JPEG: jpegtran, jpegoptim Other §  PNG: OptiPNG, PNGOUT 0% §  WebPageTest http://mobile.httparchive.org/
  • 24.
    HIGH PERFORMANCE –LESS BY TES ¡  Less Bytes §  Adaptive Images §  Don’t scale images on the client §  Wastes bandwidth §  Requires device CPU §  Use @media, window.matchMedia(…), window.devicePixelRatio, etc §  -webkit-min-device-pixel-ratio (1 -> low res, 1.5 or 2 -> high res) §  For manifest file use capabilities cookie §  Server Scaling §  Multiple fixed breakpoints §  Allows for different designs (i.e. larger text on small images) §  Scale on demand in between major breakpoints §  Use CDN to “save” scaled images
  • 25.
    HIGH PERFORMANCE –LESS BY TES ¡  Less Bytes §  Less JS §  Remove duplication §  Cost of parsing JavaScript about 1ms per 100KB §  Steve Souders – “every byte of JavaScript is 10x more expensive then everything else” §  Mini frameworks only §  Avoid → jQuery, Sencha, YUI, Dojo, etc §  It takes between 1 .5s and 8s to parse and download jQuer y over 3G §  jQuer yMobile wraps jQuer yUI with wraps jQuer y Core §  Use → XUI, Zepto, microJS, baseJS http://www.slideshare.net/mobile/Gomez_Inc/optimizing-web-and-mobile-site-performance-using-page-speed
  • 26.
    HIGH PERFORMANCE –LESS BY TES ¡  Less Bytes §  Compression §  More consistent data will compress better §  CSS key-value pairs in same order §  HTML attribute in same order §  Use lowercase (or consistent) casing wherever possible §  Use consistent quoting for HTML attributes (always single or always double) §  Minify JS, CSS and HTML §  Avoid gzip for image or other binary files §  These files are already compressed
  • 27.
    HIGH PERFORMANCE –LESS BY TES ¡  Less Bytes §  Less Cookies §  Remove / reduce cookies §  Cookie Free Domain §  Server-Side Cookies (ID only) §  Store data on server side and only send unique ID §  HIJAX §  Smaller page request §  Could also use Hashbang §  Twitter accepts both https://twitter.com/#!/foo and https://twitter.com/foo §  Only works with JavaScript enabled §  Its an ugly hack and looks like one §  History API §  history.pushState() & ‘popstate’ event §  Don’t forget forward and backwards isn’t a page reload, it’s a page display §  Endless Scrolling Pattern §  Only download subset §  Less bytes §  Much more complexity §  Only worth while for very large data sets §  Recycle elements that are scrolled off screen
  • 28.
    HIGH PERFORMANCE –BANDWIDTH ¡  Bandwidth Efficiency §  Fit request into single packet (if possible) §  Packet size ~1500 bytes §  Parallelize downloads §  Avoid blocking HTML parsing §  JS at the bottom §  Avoid delaying resource download §  Avoid @import §  document.write(…) §  Max requests per domain §  Domain sharding §  Adds DNS lookup → >6 request per domain
  • 29.
    HIGH PERFORMANCE –BANDWIDTH ¡  Bandwidth Efficiency §  Defer JS requests §  Progressive enhance so delay in JS is never a problem §  defer & async §  download and parse not delayed §  tells browser there is no document.write(…)! §  async §  executes after download §  execution order not guaranteed §  defer §  executes after parsing http://peter.sh/experiments/asynchronous-and-deferred-javascript-execution-explained/
  • 30.
    HIGH PERFORMANCE –BANDWIDTH ¡  Bandwidth Efficiency §  Defer JS requests §  Downloading JS asynchronously §  XHR Eval §  XHR Injection §  Script in iframe §  Script DOM element §  document.write(…) §  Load scripts after onload to guarantee loaded asynchronous download
  • 31.
    HIGH PERFORMANCE –BANDWIDTH ¡  Bandwidth Efficiency §  Eager loading §  Download in background and store in localStorage §  Mobile Web: <a class="eager" … />! §  Chromium: <link rel=“prerender” … />! §  Avoid bad requests (i.e. 404) §  7% mobile pages have (4xx) errors §  Avoid redirects §  73% mobile pages have (3xx) redirects §  If you can’t avoid cache §  Language redirect for Accept-Language (see details on caching later) §  Expires <= Date (to disable HTTP/1 .0 caches that don’t support Var y) §  Cache-Control: max-age >= 1 year §  Var y: Accept-Language http://mobile.httparchive.org/
  • 32.
    HIGH PERFORMANCE –BANDWIDTH ¡  Bandwidth Efficiency §  Dynamic Update http://mobilehtml5.org/
  • 33.
    HIGH PERFORMANCE –BANDWIDTH ¡  Bandwidth Efficiency §  Dynamic Update §  AJAX Polling §  Long Polling §  Server Side Events §  Web Sockets §  JSON vs HTML fragments §  Trade-off §  Less bytes on network §  Identical fixed network costs §  Much more complex JavaScript code that must work across multiple devices §  HTML fragment approach → simple identical JavaScript universally across the site §  JSON → custom JavaScript for ever y item of updatable content
  • 34.
    HIGH PERFORMANCE –LESS LATENCY ¡  L e s s L a t e n c y §  Less server time §  Execute backend calls in parallel §  Avoid synchronization §  Threads §  DB (i.e. locking) §  NoSQL §  Eventual Consistency §  Use Futures to only block when absolutely required §  ETag → short circuit backend tasks §  Flush header while waiting for backend calls §  Allows CSS to be downloaded on client in parallel with backend calls §  HTTP/1.1 §  Trailer header allows addition of Content-Length, Last-Modifier and ETag with Transfer-Encoding: chunked §  Servlet 3.0 does NOT support this!! §  Under load scaling §  Avoid “too many” threads per request §  Threads should not be blocked waiting (i.e. IO / locks) §  No conversation state §  Must be managed across servers §  Session replication §  Sticky sessions §  Some state exists but not held on web server §  Decouple and isolates problem §  Separation of concerns §  Better encapsulation §  Improves opportunity for graceful degradation §  Web Tier Persistence §  Transient User Data (i.e. shopping basket, web UI preferences)
  • 35.
    HIGH PERFORMANCE –LESS LATENCY ¡  Less Latency §  Minimize DNS lookups §  Mobile Web analytics request §  230ms DNS lookup §  76ms TCP + HTTP connection §  58ms server time §  Flush Early §  Check flush isn’t buffered §  Apache, Network (i.e. Netscaler), gzip §  Only works on HTTP/1.1 connections §  Uses Transfer-Encoding: chunked! §  Caching §  Make pages cacheable §  Avoid cookie or header driven content §  Except User- Agent, Accept-Language, Accept-Encoding §  Use path variable instead of query parameters §  Most proxy caches do not cache resources with quer y parameters §  i.e. only latest version of Squid fixes this §  Use fingerprinting to dynamically control caching
  • 36.
    HIGH PERFORMANCE –LESS LATENCY ¡  L e s s L a t e n c y §  Caching §  Expires (HTTP/1.0) §  Date when resource is stale §  Cache-Control (HTTP/1.1) §  Overrides Expires header §  max-age - how long resource is fresh (in seconds) §  public, private – where item is cacheable §  no-store – never cache §  no-cache – always revalidate §  must-revalidate – revalidate if stale §  s-maxage, proxy-revalidate – proxy servers settings §  Vary (HTTP/1.1) §  Allows cached items to be varied by header §  If using disable HTTP/1.0 caches by Expires <= Date §  Tips §  Maximize freshness → 1 year §  Android clears cache based on length of freshness → >10 years §  Last-Modified §  Last time resource modified §  If-Modified-Since – conditional GET §  If-Unmodified-Since – conditional PUT, DELETE §  ETag §  Ensure consistency across multiple web servers §  Unique identifier for specific resource version §  If-None-Match – conditional GET §  If-Match – conditional PUT, DELETE §  Favor semantic “week validator” over byte level “strong validator” §  Week Validator enables short-circuiting the server HTML generation §  Trailer: ETag supports Transfer-Encoding: chunked (not supported by Servlet 3.0) §  304 Not Modified §  Last-Modified §  ETag
  • 37.
    HIGH PERFORMANCE –LESS LATENCY ¡  Less Latency §  Caching §  Not used enough 45% Cache-Control: max-age (days) 40% 35% 30% 25% 20% 15% 10% 5% 0% None t <= 0 0 < t <= 1 1 < t <= 30 30 < t <= 365 365 < t http://mobile.httparchive.org/
  • 38.
    HIGH PERFORMANCE –LESS LATENCY ¡  Less Latency §  Caching §  Browser §  Limited size §  Average mobile page size 550KB → < 7 pages to full reload OS (Device) Component Total Last-Modified ETag Survives Power Cycle Android 2.1 (Nexus One) 2MB 2MB Yes Yes Yes Android 2.2 (Glaxay S) 4MB 4MB Yes Yes Yes Android 2.3 (Nexus S) 4MB 4MB Yes Yes Yes Safari, iOS 3.1.3 (1st-gen iPhone) 0b 0b No No No Safari, iOS 3.2 (iPad) 26KB 282KB Yes Yes No Safari, iOS 4.0 (iPhone 3GS) 51KB 1MB Yes Yes No Safari, iOS 4.0 (iPhone 4) 102KB 2MB Yes Yes No webOS 1.4.1 (Palm Pre Plus) 1MB ? No No Yes http://www.yuiblog.com/blog/2010/06/28/mobile-browser-cache-limits/ http://www.blaze.io/mobile/understanding-mobile-cache-sizes/ http://mobile.httparchive.org/trends.php#bytesTotal&reqTotal
  • 39.
    HIGH PERFORMANCE –LESS LATENCY ¡  Less Latency §  Caching §  Reverse Proxy (i.e. ISP) §  Vary: Accept-Encoding §  many proxy caches do not detect Content-Encoding correctly §  Cookies §  Generally public caches won’t cache pages with cookies §  If they do cookies will be shared §  Edge / Gateway (i.e. CDN) §  Edge Side Include (ESI) §  Dynamic content assembly in cache §  Add icons: §  favicon.ico §  apple-touch-icon.png §  apple-touch-icon-precomposed.png
  • 40.
    HIGH PERFORMANCE –LESS LATENCY ¡  Less Latency §  Offline Storage §  Single origin policy §  No freshness or cache eviction §  No versioning §  No request → very fast and works offline §  Manifest file §  see earlier slides §  Web Storage §  Local Storage (or Session Storage) §  key/value storage of strings §  Simple but no query language §  No locks or transactions §  No indexes or complex data structures §  Slow, synchronous → blocking §  Up to 5MB §  Very fast §  Synchronous §  Only accessible from JavaScript §  Indexed DB §  Flat-file DB §  Hierarchical key/value persistence §  Basic indexing §  Fully asynchronous §  Supports indexed filtering and lookup §  DB level transactions & locking §  Up to 5MB, then prompt user for more §  Only accessible from JavaScript §  Web SQL Database §  SQLite in browser §  select, insert, update, delete, joins, inner selects, etc §  Up to 5MB, then prompt user for more §  Standard dropped by W3C §  Slow §  Only accessible from JavaScript §  File API
  • 41.
    HIGH PERFORMANCE –LESS LATENCY ¡  Less Latency §  Radio Resource Control §  HEAD request every 2-3 seconds to keep cell connection live §  Drains battery and adds congestion so don’t poll forever §  Page Beacons (Analytics) §  Make asynchronous §  Inject 1x1.gif §  Separate domain §  Avoid site cookies infecting request §  Avoid analytics cookies infecting site §  304 response §  Maximize benefit §  Page flow §  Device capabilities §  @media / JS cookie §  User- A gent §  Connection Type §  navigator.connection.type! §  ETHERNET, WIFI, CELL_2G, CELL_3G, …! §  Carrier §  Massive’s Operator Identification Platform
  • 42.
    HIGH PERFORMANCE –PAGE RENDER ¡  Faster Page Render §  Simple semantic DOM §  For every element (i.e. in Chrome) §  Node in DOM Tree §  RenderObject in RenderTree §  Efficient CSS selectors §  Avoid universal rules §  Don’t qualify id rules with tag names or classes §  Don’t qualify class rules with tag names §  Make rules as specific as possible §  Avoid descendant selectors (especially Tag or Universal) §  Apply rules at the highest level and allow inheritance §  Remove redundant qualifies §  ID selector with class or tag §  Class selector with tag
  • 43.
    HIGH PERFORMANCE –PAGE RENDER ¡  Faster Page Render §  CSS in head §  External or inline style blocks in body can cause reflow or FOUC §  Allows page to render progressively §  External stylesheets block rendering until downloaded and parsed §  Use hardware accelerated CSS animations §  Gets GPUs directly involved with compositing §  Avoids slow video to system memory copies §  Less redraws of complete screen §  only compositing layer redraw and recomposition §  Use CSS instead of JS animation §  Specify image dimensions §  Avoids reflow after image downloaded §  Specify character set §  Avoids browser auto detecting (and making / correcting mistakes) §  Timers §  Lots of >1s timers §  Very few (i.e. one) <500ms timers http://googlecode.blogspot.com/2009/07/gmail-for-mobile-html5-series-using.html
  • 44.
    HIGH PERFORMANCE –INTERACTION ¡  Faster Interaction §  Defer JS parsing §  100ms per 1KB §  Make browser ignore code §  Comments §  None script element §  When needed use eval(…)! §  Avoid blocking single UI Thread §  Long-running JS = Unresponsive UI §  Asynchronous §  Use events §  Synthetic (via setTimeout in framework) §  Native §  Script Yeilding §  setTimeout(function() {…}, 50)! §  Different browsers have different timer resolutions / issues §  Short timeouts can significantly shorten battery life §  setImmediate(function() {…})! §  Add to back of UI Thread Queue (i.e. no timer) §  Not supported yet (only in IE 10) §  WebWorkers §  Asynchronous, doesn’t block UI Thread §  Data is serialized into and out of worker §  No access to DOM §  Separate execution environment
  • 45.
    HIGH PERFORMANCE –INTERACTION ¡  Faster Interaction §  Touch delay §  Click event delayed between 300 and 500ms §  ontouchstart → ontouchend (with ontouchdrag within error margin) §  Event Handlers §  Event handlers on outer container §  Use event bubble §  Avoid lots of smaller event handlers
  • 46.
    HIGH PERFORMANCE –INTERACTION ¡  Faster Interaction §  Touch §  Work directly with content §  Avoid button indirection §  Although gesture support currently limited §  Limited touch events §  touchstart, touchmove, touchend §  Fat fingers §  Fitt’s Law §  difficulty ∝ distance, size §  Large buttons §  Inactive margin §  Right first time
  • 47.
    HIGH PERFORMANCE –PERCEPTION ¡  Improve Perception §  Flush early §  Visual feedback to user §  Button click changes color §  Image Interlacing §  Visible image after only 1/64 downloaded §  Adds ~15% §  Remove address bar §  While JavaScript is executing in background §  After onload §  window.scrollTo(0, 1);! §  If page height < window height then increase page height first to allow scroll
  • 48.
    TOOLS – DEBUGGING ¡ Debugging §  Chrome Internals §  chrome://net-internals §  chrome://appcache-internals/ §  chrome://profiler/ §  For full list see chrome://chrome-urls/ §  Works on Chrome for Android §  Firebug §  Desktop only §  BlackBerry Browser §  Remote debugging §  Smar tphone 7.0+ §  PlayBook §  Web Inspector §  http://trac.webkit.org/wiki/WebInspector §  Wienre §  http://phonegap.github.com/weinre/ §  DragonFly (for Opera Mobile) §  WebKit Remote Debugging §  http://www.webkit.org/blog/1620/webkit-remote-debugging/ §  Adobe Shadow §  Synchronize desktop browser with multiple mobile browsers §  http://labs.adobe.com/technologies/shadow/
  • 49.
    TOOLS – PERFORMANCE ¡  Performance / Analysis §  Chrome Inspector §  JS & CSS Profiler §  PageSpeed §  Chrome Inspector §  Firebug §  YSlow §  Chrome Inspector §  Firebug §  Mobile Perf Bookmarklets §  YSlow and other tools §  http://stevesouders.com/mobileperf/mobileperfbkm.php §  PCAP Web Performance Analyzer §  http://pcapperf.appspot.com/ §  Analyse packets → Waterfall & WebPageTest §  Shark for Root §  Android packet sniffer §  Works with 3G §  Analyse results (PCAP file) with pcapperf §  Speed Tracer §  Chrome Inspector Plugin §  Analyses all page interaction (CSS & JS) §  3PMobile §  On device browser §  Network Waterfall §  Browser Event (i.e. image loading time, CSS processing time) §  dynaTrace §  JS performance analyser §  http://ajax.dynatrace.com/ §  Loadtimer §  Tests time for full load of multiple URLs §  http://www.stevesouders.com/blog/2011/12/01/loadtimer-a-mobile-test-harness/ §  WebPageTest §  Waterfall of network traffic §  Timing of page load event adds noise
  • 50.
    TOOLS – EMULATORS ¡ Emulators §  www.mobilexweb.com/emulators ¡  Remote Labs §  DeviceAnywhere (bought by WebPageTest) §  deviceanywhere.com §  PerfectoMobile §  perfectomobile.com §  WebPageTest §  Samsung §  Free hosting of Samsung devices §  http://developer.samsung.com/remoteTestLab.do §  Nokia §  Free hosting of Nokia devices ¡  Experimental §  Cuzillion §  Build up different types of page §  internal / external CSS §  internal / external JS §  images §  Good for testing and learning about new devices / browsers §  http://stevesouders.com/cuzillion/