Extreme Optimization for the Mobile Web
•
8 recomendaciones•922 vistas
That's Web? Extreme Optimization for the Mobile Web - HTML5 Dev Conf, San Francisco, Oct 2012
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (18)
Similar a Extreme Optimization for the Mobile Web
Similar a Extreme Optimization for the Mobile Web (20)
Último
Último (20)
Extreme Optimization for the Mobile Web
- 1. That's Web? Extreme Optimization for the Mobile Web Glan Thomas - Disney Interactive HTML5 Developer Conference 2012 San Francisco, CA
- 2. About me ... and why I am interested in this stuff
- 3. What is a Mobile Web App?
- 5. Webview
- 6. What’s it like going from the desktop to mobile web?
- 7. Why am interested in this © Universal Pictures
- 8. What are we trying to optimize?
- 9. Guest Experience http://www.flickr.com/photos/stuckincustoms/518435043/
- 10. The 5 Great Mobile Development Challenges
- 12. ➋ Variety of Display Densities
- 13. ➌ High Network Latency http://www.qsl.net/ylradio/archives/YLstor/images/radioroom.jpg
- 14. ➍ Matching Users’ Expectations © DreamWorks Pictures / 20th Century Fox
- 16. ➎ Dealing with your VP’s pessimism © 2010 Columbia TriStar
- 17. What if we don’t do anything? ✘ Long load times ✘ Partial content appearing ✘ Unresponsive UI ✘ Jittery animations
- 18. But It gets worse... • Unnecessary data usage • Decreased battery life http://www.flickr.com/photos/flydime/4670141424/
- 19. “Q, your app sucks. I used it for 30 minutes and it drained my battery so low that I missed my appointment with Dr Crusher!” © CBS Paramount Television / Paramount Pictures
- 20. ๏ MANY + LARGE HTTP REQUESTS = MORE DATA = MORE POWER USAGE = HIGH BATTERY DRAIN ๏ UNNECESSARY ANIMATIONS = HIGH USE OF CPU AND MEMORY = MORE POWER USAGE = HIGH BATTERY DRAIN
- 21. PRIME DIRECTIVE "Be green and respect the battery" © CBS Paramount Television / Paramount Pictures
- 22. WWW 2012 – Session: Mobile Web Performance April 16–20, 2012, Lyon, France Who Killed My Battery: Analyzing Mobile Browser Energy Consumption Narendran Thiagarajan† Gaurav Aggarwal† Angela Nicoara* naren@cs.stanford.edu agaurav@cs.stanford.edu angela.nicoara@telekom.com Dan Boneh† Jatinder Pal Singh‡ dabo@cs.stanford.edu jatinder@stanford.edu † Department of Computer Science, Stanford University, CA * Deutsche Telekom R&D Laboratories USA, Los Altos, CA ‡ Department of Electrical Engineering, Stanford University, CA ABSTRACT sites are poorly optimized for energy use and rendering them in the Despite the growing popularity of mobile web browsing, the energy browser takes more power than necessary. Partly this is due to a consumed by a phone browser while surfing the web is poorly un- weak understanding of the browser’s energy use. derstood. We present an infrastructure for measuring the precise In this paper we set out to analyze the energy consumption of energy used by a mobile browser to render web pages. We then the Android browser at popular web sites such as Facebook, Ama- measure the energy needed to render financial, e-commerce, email, zon, and many others. Our experimental setup includes a multi- blogging, news and social networking sites. Our tools are suffi- meter hooked up to the phone battery that measures the phone’s ciently precise to measure the energy needed to render individual energy consumption as the phone loads and renders web pages. We web elements, such as cascade style sheets (CSS), Javascript, im- patched the default Android browser to help us measure the precise ages, and plug-in objects. Our results show that for popular sites, energy used from the moment the browser begins navigating to the downloading and parsing cascade style sheets and Javascript con- desired web site until the page is fully rendered. The patch also lets sumes a significant fraction of the total energy needed to render the us measure the exact energy needed to render a page excluding the page. Using the data we collected we make concrete recommen- energy consumed by the radio. Our setup is described in detail in dations on how to design web pages so as to minimize the energy Section 2. In that section we also describe the energy model for the needed to render the page. As an example, by modifying scripts on phone’s radio which is similar to models presented in [18, 10]. the Wikipedia mobile site we reduced by 30% the energy needed to Using our experimental setup we measured the energy needed download and render Wikipedia pages with no change to the user to render popular web sites as well as the energy needed to render experience. We conclude by estimating the point at which offload- individual web elements such as images, Javascript, and Cascade ing browser computations to a remote proxy can save energy on the Style Sheets (CSS). We find that complex Javascript and CSS can be as expensive to render as images. Moreover, dynamic Javascript
- 23. Crunch Points Loading User Interaction Network Parsing Execution Rendering Animation Events
- 25. Tip Don’t take the network for granted
- 26. Network • High latency. • Bandwidth costs money (for all parties). • Might not be there. • It will definitely drain the battery. http://www.flickr.com/photos/robert-dolan/3864148280/
- 27. How do you solve a problem like the network? Do everything Steve Souders tells you to.
- 28. • Enable Gzip. • Reduce number of requests. • Reduce size of responses. • Expires Headers / Etags • Use a CDN. • Deliver device specific content. • Don’t use the network unless we absolutely positively need to.
- 29. Images • Optimization tools (ImageOptim, ImageAlpha). • Sprites to reduce requests. • Device specific images. • Base64 inline (pros & cons). • CSS and Unicode Glyphs to replace images. • CSS image masks for alpha.
- 30. Original PNG JPEG 3bit PNG Mask 33Kb 19Kb 4.7Kb --- 23.7Kb ~ 29% saving ---
- 31. Tip If you really must make the user wait, show something.
- 32. Ideal App Usage Cycle • Load App (HTML & CSS) • Render • Load Source (JS) • Parse • Execute • Parallel Operations • User Events • Deferred Loads (data and images)
- 33. Tip Use HTML5 and other goodies
- 34. HTML5 • LocalStorage • AppCache • Network / Connection API • Battery API • Web workers and shared web workers • Things we don’t need libraries for: • JSON, QuerySelector, ClassLists
- 35. JavaScript Libraries • Modular • Lightweight • Maintained • Understandable
- 36. Tip Don't animate anything that you can't reliably offload to the GPU
- 37. The GPU • translate3d, scale3d, rotate3d • Beware of the 1024px texture size limit • Interaction between the CPU and GPU • Don’t load too much on to it (~10Mb total storage)
- 38. Rendering and Updates • Avoid reflows • Carefully use opacity/transparency fades. • requestAnimationFrame
- 39. Tip Keep the DOM simple and use event listeners carefully
- 41. Build process • Build process • Testing and debugging http://floridakeysgirl.com/wp-content/uploads/2010/10/IMG_1147-e1288555102991.jpg
- 42. Debugging and Testing • Desktop Webkit • Simulator / Emulators • weinre - WEb INspector REmote • Charles proxy • Mobile Perf Bookmarklet (YSlow, DOM Monster) • PhantomJS, Selenium • Real devices, with real OSs
- 43. Recap • Prime Directive: Respect the battery. • #1 Don’t rely too much on the network. • #2 Show something while loading. • #3 Use HTML5 extensions. • #4 Use hardware acceleration. • #5 Keep the DOM simple. Use event listeners carefully and appropriately.
- 44. Thanks for all the fish @glan
Notas del editor
- \n
- I’m going to start by talking about how I got here and why I’m up here talking about Building awesome mobile web apps.\n\nTraditionally I’m a full-stack web dev\nOver the past few years a I’m chosen my side, said good bye to PHP and MySQL\n and focusing on frontend.\n\nToday I work for Disney Interactive, building HTML5 games, \nBefore this I worked for Tapulous of the successful ‘Tap Tap Revenge’ franchise. \n\n\n
- \n
- I used to work for these guys. I worked on building websites for a few large broadcasters including the BBC and BSkyB. I also did a fair bit consultancy and freelancing work too.\n
- Today work for Tapulous, makers of the successful ‘Tap Tap Revenge’ franchise. Tapulous is also part of Disney Mobile who make games such as ‘Where’s My Water’ and ‘Pirates of the Caribbean’.\nCorporate Inception\n\n
- \n
- Ok what do we mean by a mobile web app?\n\n1). Could be a standalone web app running in Mobile Safari, Chrome, Firefox, Opera Mobile or Windows Mobile 7 browser. Simply accessed via a URL\n\n2) The web app could be part of Native App and presented with a WebView container. The web app my represent all or just part of the main App.\n\nOur HTML, CSS, JavaScript and other assets may be packaged within the app or delivered via a network.\n\nThese include Ads, news, dynamic content.\n\nExamples include the iTunes store app, iAds.\n
- Ok what do we mean by a mobile web app?\n\n1). Could be a standalone web app running in Mobile Safari, Chrome, Firefox, Opera Mobile or Windows Mobile 7 browser. Simply accessed via a URL\n\n2) The web app could be part of Native App and presented with a WebView container. The web app my represent all or just part of the main App.\n\nOur HTML, CSS, JavaScript and other assets may be packaged within the app or delivered via a network.\n\nThese include Ads, news, dynamic content.\n\nExamples include the iTunes store app, iAds.\n
- Ok what do we mean by a mobile web app?\n\n1). Could be a standalone web app running in Mobile Safari, Chrome, Firefox, Opera Mobile or Windows Mobile 7 browser. Simply accessed via a URL\n\n2) The web app could be part of Native App and presented with a WebView container. The web app my represent all or just part of the main App.\n\nOur HTML, CSS, JavaScript and other assets may be packaged within the app or delivered via a network.\n\nThese include Ads, news, dynamic content.\n\nExamples include the iTunes store app, iAds.\n
- Ok what do we mean by a mobile web app?\n\n1). Could be a standalone web app running in Mobile Safari, Chrome, Firefox, Opera Mobile or Windows Mobile 7 browser. Simply accessed via a URL\n\n2) The web app could be part of Native App and presented with a WebView container. The web app my represent all or just part of the main App.\n\nOur HTML, CSS, JavaScript and other assets may be packaged within the app or delivered via a network.\n\nThese include Ads, news, dynamic content.\n\nExamples include the iTunes store app, iAds.\n
- Let me start by defining what I think a mobile web app is.\nCos those last screenshots didn’t look Web, cos they not.\n
- Google maps, Twitter, Facebook, LinkedIn\nSingle page load with lots user interaction\n
- Native App with webviews.\nNetwork loaded or prepacked\nTap Tap Revenge, Tap Tap Glee, LinkedIn\nApple use web views too for iTunes, iAd and many other apps.\nPhonegap - Great for cross device and app store discovery.\n\n
- A lot of this talk is about things problems which I encountered over the past 2 years\nand possible solutions we found. How HTML5 Helps\n
- I like to think of the Mobile web as the Wild West, everyone is rushing to stake a claim.\nLots of experimentation\nNew device APIs being built.\nFast paced change.\nCompeting technologies and platforms.\nIn some ways there is also an element of history repeating itself. 90s-2000s\nAlso a battle between Native and Web components.\n\n
- I said I was going to talk about this, but what...\n
- It’s kind of fitting, since Disney is all-about giving great guest experiences.\n\nThis is what all web app developers want to do. However on mobile we have a few challenges...\n\nI hope the same applies to this talk.\n\nGreat / fast apps make more money\n
- \n
- The first thing we have to deal with is a user’s exceptions. In the mobile world they are kind of spoilt by native apps and expect a web app to look and feel as responsive. This exception is quite different from the normal web, where users click links and spend time reading. On the mobile, the user is probably going to spend less time reading and more time navigating, so we need to react quicker.\n\nSo we need to over a level of refinement which are as close to a native view as possible, but still have the dynamism of a web view. If we transition from a Native view to a web view we want to avoid avoid a jarring experience. One thing which I’m not intending to talk about is how we can make out web view look like a native App, this is non-trial and in the case of Android there are so many different skins and user experiences that I’m not touching that with a 10 foot pole.\n\nAt the same time as matching a users expectations we need to deal with the mobile network, which ain’t the same a hardline.\n\nOther factors include the limited CPU and Memory resources which are available on a mobile device. Also not all devices are equal, so something which is performant on one device might not be the same on another. \n\nThis kind of leads us on to the next point. With the advent the high density displays such as the Retina display we now have device pixel ratios of 2x, 1.5x and 1x depending on the device.\n
- The first thing we have to deal with is a user’s exceptions. In the mobile world they are kind of spoilt by native apps and expect a web app to look and feel as responsive. This exception is quite different from the normal web, where users click links and spend time reading. On the mobile, the user is probably going to spend less time reading and more time navigating, so we need to react quicker.\n\nSo we need to over a level of refinement which are as close to a native view as possible, but still have the dynamism of a web view. If we transition from a Native view to a web view we want to avoid avoid a jarring experience. One thing which I’m not intending to talk about is how we can make out web view look like a native App, this is non-trial and in the case of Android there are so many different skins and user experiences that I’m not touching that with a 10 foot pole.\n\nAt the same time as matching a users expectations we need to deal with the mobile network, which ain’t the same a hardline.\n\nOther factors include the limited CPU and Memory resources which are available on a mobile device. Also not all devices are equal, so something which is performant on one device might not be the same on another. \n\nThis kind of leads us on to the next point. With the advent the high density displays such as the Retina display we now have device pixel ratios of 2x, 1.5x and 1x depending on the device.\n
- The first thing we have to deal with is a user’s exceptions. In the mobile world they are kind of spoilt by native apps and expect a web app to look and feel as responsive. This exception is quite different from the normal web, where users click links and spend time reading. On the mobile, the user is probably going to spend less time reading and more time navigating, so we need to react quicker.\n\nSo we need to over a level of refinement which are as close to a native view as possible, but still have the dynamism of a web view. If we transition from a Native view to a web view we want to avoid avoid a jarring experience. One thing which I’m not intending to talk about is how we can make out web view look like a native App, this is non-trial and in the case of Android there are so many different skins and user experiences that I’m not touching that with a 10 foot pole.\n\nAt the same time as matching a users expectations we need to deal with the mobile network, which ain’t the same a hardline.\n\nOther factors include the limited CPU and Memory resources which are available on a mobile device. Also not all devices are equal, so something which is performant on one device might not be the same on another. \n\nThis kind of leads us on to the next point. With the advent the high density displays such as the Retina display we now have device pixel ratios of 2x, 1.5x and 1x depending on the device.\n
- The first thing we have to deal with is a user’s exceptions. In the mobile world they are kind of spoilt by native apps and expect a web app to look and feel as responsive. This exception is quite different from the normal web, where users click links and spend time reading. On the mobile, the user is probably going to spend less time reading and more time navigating, so we need to react quicker.\n\nSo we need to over a level of refinement which are as close to a native view as possible, but still have the dynamism of a web view. If we transition from a Native view to a web view we want to avoid avoid a jarring experience. One thing which I’m not intending to talk about is how we can make out web view look like a native App, this is non-trial and in the case of Android there are so many different skins and user experiences that I’m not touching that with a 10 foot pole.\n\nAt the same time as matching a users expectations we need to deal with the mobile network, which ain’t the same a hardline.\n\nOther factors include the limited CPU and Memory resources which are available on a mobile device. Also not all devices are equal, so something which is performant on one device might not be the same on another. \n\nThis kind of leads us on to the next point. With the advent the high density displays such as the Retina display we now have device pixel ratios of 2x, 1.5x and 1x depending on the device.\n
- The first thing we have to deal with is a user’s exceptions. In the mobile world they are kind of spoilt by native apps and expect a web app to look and feel as responsive. This exception is quite different from the normal web, where users click links and spend time reading. On the mobile, the user is probably going to spend less time reading and more time navigating, so we need to react quicker.\n\nSo we need to over a level of refinement which are as close to a native view as possible, but still have the dynamism of a web view. If we transition from a Native view to a web view we want to avoid avoid a jarring experience. One thing which I’m not intending to talk about is how we can make out web view look like a native App, this is non-trial and in the case of Android there are so many different skins and user experiences that I’m not touching that with a 10 foot pole.\n\nAt the same time as matching a users expectations we need to deal with the mobile network, which ain’t the same a hardline.\n\nOther factors include the limited CPU and Memory resources which are available on a mobile device. Also not all devices are equal, so something which is performant on one device might not be the same on another. \n\nThis kind of leads us on to the next point. With the advent the high density displays such as the Retina display we now have device pixel ratios of 2x, 1.5x and 1x depending on the device.\n
- Mobile devices have processors which are less powerful than desktops.\nLess RAM\nA mobile phone’s spec is closer to a computer 5 years ago.\n
- Multiple densities 1x, 1.5x, 2x\n2x => 4 times the pixels which means more data.\nA pixel is not a pixel\n\n
- Mobile devices of course often reply on cellular networks.\nThey getting faster. They are still a lot slower than Ethernet or Broadband.\nAlso if we using public WiFI, generally these are also pretty slow too. \n
- Finally, Mobile users have become accustomed to Native interfaces, which are responsive \n
- Like blackboxes.\nIt’s hard to see how things are running on them.\nWether it is Debugging or Performance optimization.\n\n
- Someone said HTML5 didn’t work for them.\nNon technical challenge.\nget rid of preconceptions.\n
- All this ==> Crappy user experience\n\nThings that the user will notice right away.\n
- All this ==> Crappy user experience\n\nThings that the user will notice right away.\n
- All this ==> Crappy user experience\n\nThings that the user will notice right away.\n
- All this ==> Crappy user experience\n\nThings that the user will notice right away.\n
- All this ==> Crappy user experience\n\nThings that the user will notice right away.\n
- All this ==> Crappy user experience\n\nThings that the user will notice right away.\n
- Not only that... It gets worse... What might a user notice later...\nLets also think about some side effects\n\nData usage - we don't want to abuse a user's quota.\nBattery life - lets not run a user's device battery down unnecessary.\n\nHere are real world example...\n
- Not only that... It gets worse... What might a user notice later...\nLets also think about some side effects\n\nData usage - we don't want to abuse a user's quota.\nBattery life - lets not run a user's device battery down unnecessary.\n\nHere are real world example...\n
- Not only that... It gets worse... What might a user notice later...\nLets also think about some side effects\n\nData usage - we don't want to abuse a user's quota.\nBattery life - lets not run a user's device battery down unnecessary.\n\nHere are real world example...\n
- \n
- Lets look at what might be going on\n\nOh! there is a common theme.\nCause and Effect\n\nOccam's Razor\n\n\n
- Lets look at what might be going on\n\nOh! there is a common theme.\nCause and Effect\n\nOccam's Razor\n\n\n
- Lets look at what might be going on\n\nOh! there is a common theme.\nCause and Effect\n\nOccam's Razor\n\n\n
- Lets look at what might be going on\n\nOh! there is a common theme.\nCause and Effect\n\nOccam's Razor\n\n\n
- Lets look at what might be going on\n\nOh! there is a common theme.\nCause and Effect\n\nOccam's Razor\n\n\n
- Lets look at what might be going on\n\nOh! there is a common theme.\nCause and Effect\n\nOccam's Razor\n\n\n
- Lets look at what might be going on\n\nOh! there is a common theme.\nCause and Effect\n\nOccam's Razor\n\n\n
- Lets look at what might be going on\n\nOh! there is a common theme.\nCause and Effect\n\nOccam's Razor\n\n\n
- Lets look at what might be going on\n\nOh! there is a common theme.\nCause and Effect\n\nOccam's Razor\n\n\n
- Be nice to a device's battery - Save energy.\nSingle most important rule which we MUST obey when building a mobile web App.\nThis is why Flash is not on the iOS. \nThe one thing which has changed little for the modern smart phone over the past 3 years in how long the battery lasts on a single charge.\n\n\n
- Be nice to a device's battery - Save energy.\nSingle most important rule which we MUST obey when building a mobile web App.\nThis is why Flash is not on the iOS. \nThe one thing which has changed little for the modern smart phone over the past 3 years in how long the battery lasts on a single charge.\n\n\n
- It’s not just me talking about this.\n
- There a lots of optimization which we can make to our web app, some with have a greater impact on perceived performance than others. It’s useful to identify what techniques are going to most befit your users and work in implementing them first. There is no point on worrying about things way down here if you haven’t got the big stuff sorted.\n
- \n
- We can single out crunch points in our app.\nBasically there are 2 high level areas\nThen individual components which can be optimized.\n
- We can single out crunch points in our app.\nBasically there are 2 high level areas\nThen individual components which can be optimized.\n
- We can single out crunch points in our app.\nBasically there are 2 high level areas\nThen individual components which can be optimized.\n
- We can single out crunch points in our app.\nBasically there are 2 high level areas\nThen individual components which can be optimized.\n
- We can single out crunch points in our app.\nBasically there are 2 high level areas\nThen individual components which can be optimized.\n
- We can single out crunch points in our app.\nBasically there are 2 high level areas\nThen individual components which can be optimized.\n
- We can single out crunch points in our app.\nBasically there are 2 high level areas\nThen individual components which can be optimized.\n
- We can single out crunch points in our app.\nBasically there are 2 high level areas\nThen individual components which can be optimized.\n
- Of course if your app loads assets from the device then you can help minimize the load right off the bat. This is not always possible for example Browser based apps. There are also other reason why you may not want to do this, such as initial download size, keeping this content update etc.\n
- \n
- Why is it so bad?\n
- Bandwidth costs money (for all parties).\n\nThe network also impacts our Load phase, which is in most cases the slowest.\n\nUsers don’t always have good connection Think London Underground / Metro.\n\nJust spinning up the 3G attanna costs power.\n
- Bandwidth costs money (for all parties).\n\nThe network also impacts our Load phase, which is in most cases the slowest.\n\nUsers don’t always have good connection Think London Underground / Metro.\n\nJust spinning up the 3G attanna costs power.\n
- Bandwidth costs money (for all parties).\n\nThe network also impacts our Load phase, which is in most cases the slowest.\n\nUsers don’t always have good connection Think London Underground / Metro.\n\nJust spinning up the 3G attanna costs power.\n
- Bandwidth costs money (for all parties).\n\nThe network also impacts our Load phase, which is in most cases the slowest.\n\nUsers don’t always have good connection Think London Underground / Metro.\n\nJust spinning up the 3G attanna costs power.\n
- This is may be obvious. But in the mobile world simple network optimizations matter a LOT!\n\nThere are so many things we can do...\n
- This is may be obvious. But in the mobile world simple network optimizations matter a LOT!\n\nThere are so many things we can do...\n
- This is may be obvious. But in the mobile world simple network optimizations matter a LOT!\n\nThere are so many things we can do...\n
- This is may be obvious. But in the mobile world simple network optimizations matter a LOT!\n\nThere are so many things we can do...\n
- Enable Gzip - yep this one is so obvious, but it’s just a reminder.\nReduce number of requests...\n\nApplies to images, src, API data.\n\n\n\n
- Enable Gzip - yep this one is so obvious, but it’s just a reminder.\nReduce number of requests...\n\nApplies to images, src, API data.\n\n\n\n
- Enable Gzip - yep this one is so obvious, but it’s just a reminder.\nReduce number of requests...\n\nApplies to images, src, API data.\n\n\n\n
- Enable Gzip - yep this one is so obvious, but it’s just a reminder.\nReduce number of requests...\n\nApplies to images, src, API data.\n\n\n\n
- Enable Gzip - yep this one is so obvious, but it’s just a reminder.\nReduce number of requests...\n\nApplies to images, src, API data.\n\n\n\n
- Enable Gzip - yep this one is so obvious, but it’s just a reminder.\nReduce number of requests...\n\nApplies to images, src, API data.\n\n\n\n
- Enable Gzip - yep this one is so obvious, but it’s just a reminder.\nReduce number of requests...\n\nApplies to images, src, API data.\n\n\n\n
- Device specific: You can use @media ‘device-pixel-ratio’\nA problem this with is if you are also using cache manifests.\n\nUse CSS gradients, border-radius, ::before and ::after content to replace images.\n\nCSS marks demo\n
- Device specific: You can use @media ‘device-pixel-ratio’\nA problem this with is if you are also using cache manifests.\n\nUse CSS gradients, border-radius, ::before and ::after content to replace images.\n\nCSS marks demo\n
- Device specific: You can use @media ‘device-pixel-ratio’\nA problem this with is if you are also using cache manifests.\n\nUse CSS gradients, border-radius, ::before and ::after content to replace images.\n\nCSS marks demo\n
- Device specific: You can use @media ‘device-pixel-ratio’\nA problem this with is if you are also using cache manifests.\n\nUse CSS gradients, border-radius, ::before and ::after content to replace images.\n\nCSS marks demo\n
- Device specific: You can use @media ‘device-pixel-ratio’\nA problem this with is if you are also using cache manifests.\n\nUse CSS gradients, border-radius, ::before and ::after content to replace images.\n\nCSS marks demo\n
- Device specific: You can use @media ‘device-pixel-ratio’\nA problem this with is if you are also using cache manifests.\n\nUse CSS gradients, border-radius, ::before and ::after content to replace images.\n\nCSS marks demo\n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- Use a local version getItems.\n
- This sounds like a cop out, but sometimes it unavoidable.\nShow something sooner and indicate progress.\n\n\n
- Lets look at the usage cycle of a web app...\n\n\n
- Lets look at the usage cycle of a web app...\n\n\n
- Lets look at the usage cycle of a web app...\n\n\n
- Lets look at the usage cycle of a web app...\n\n\n
- Lets look at the usage cycle of a web app...\n\n\n
- Lets look at the usage cycle of a web app...\n\n\n
- Lets look at the usage cycle of a web app...\n\n\n
- Lets look at the usage cycle of a web app...\n\n\n
- What is Cool about Mobile is\nOne beast has been slain\nLess legacy - People don’t keep there phones for long, unlike desktop IE.\nBring on HTML5...\n
- Lets look at some of tools that HTML5 gives us to bring this all together.\n\n
- LocalStorage - KeyValue store, text content, 5Mb limit, well supported, lots of uses, Bing used it to store JavaScript and CSS content\nI use lot for caching JSON data.\n\nAppCache - can be useful, it’s very fiddly, but once you figure it out then it will help you a bit. The common consensus is that it needs more work.\n\nNetwork API - onLine / offLine checking and events\nConnection goes further - type off connection 3G, 4G, wifi - not well supported. \n\nBattery API - Samsung implemented, very early. \n\nWeb workers - Are good if you have a computational task which you don’t want to block UI thread.\n\n
- LocalStorage - KeyValue store, text content, 5Mb limit, well supported, lots of uses, Bing used it to store JavaScript and CSS content\nI use lot for caching JSON data.\n\nAppCache - can be useful, it’s very fiddly, but once you figure it out then it will help you a bit. The common consensus is that it needs more work.\n\nNetwork API - onLine / offLine checking and events\nConnection goes further - type off connection 3G, 4G, wifi - not well supported. \n\nBattery API - Samsung implemented, very early. \n\nWeb workers - Are good if you have a computational task which you don’t want to block UI thread.\n\n
- LocalStorage - KeyValue store, text content, 5Mb limit, well supported, lots of uses, Bing used it to store JavaScript and CSS content\nI use lot for caching JSON data.\n\nAppCache - can be useful, it’s very fiddly, but once you figure it out then it will help you a bit. The common consensus is that it needs more work.\n\nNetwork API - onLine / offLine checking and events\nConnection goes further - type off connection 3G, 4G, wifi - not well supported. \n\nBattery API - Samsung implemented, very early. \n\nWeb workers - Are good if you have a computational task which you don’t want to block UI thread.\n\n
- LocalStorage - KeyValue store, text content, 5Mb limit, well supported, lots of uses, Bing used it to store JavaScript and CSS content\nI use lot for caching JSON data.\n\nAppCache - can be useful, it’s very fiddly, but once you figure it out then it will help you a bit. The common consensus is that it needs more work.\n\nNetwork API - onLine / offLine checking and events\nConnection goes further - type off connection 3G, 4G, wifi - not well supported. \n\nBattery API - Samsung implemented, very early. \n\nWeb workers - Are good if you have a computational task which you don’t want to block UI thread.\n\n
- LocalStorage - KeyValue store, text content, 5Mb limit, well supported, lots of uses, Bing used it to store JavaScript and CSS content\nI use lot for caching JSON data.\n\nAppCache - can be useful, it’s very fiddly, but once you figure it out then it will help you a bit. The common consensus is that it needs more work.\n\nNetwork API - onLine / offLine checking and events\nConnection goes further - type off connection 3G, 4G, wifi - not well supported. \n\nBattery API - Samsung implemented, very early. \n\nWeb workers - Are good if you have a computational task which you don’t want to block UI thread.\n\n
- LocalStorage - KeyValue store, text content, 5Mb limit, well supported, lots of uses, Bing used it to store JavaScript and CSS content\nI use lot for caching JSON data.\n\nAppCache - can be useful, it’s very fiddly, but once you figure it out then it will help you a bit. The common consensus is that it needs more work.\n\nNetwork API - onLine / offLine checking and events\nConnection goes further - type off connection 3G, 4G, wifi - not well supported. \n\nBattery API - Samsung implemented, very early. \n\nWeb workers - Are good if you have a computational task which you don’t want to block UI thread.\n\n
- LocalStorage - KeyValue store, text content, 5Mb limit, well supported, lots of uses, Bing used it to store JavaScript and CSS content\nI use lot for caching JSON data.\n\nAppCache - can be useful, it’s very fiddly, but once you figure it out then it will help you a bit. The common consensus is that it needs more work.\n\nNetwork API - onLine / offLine checking and events\nConnection goes further - type off connection 3G, 4G, wifi - not well supported. \n\nBattery API - Samsung implemented, very early. \n\nWeb workers - Are good if you have a computational task which you don’t want to block UI thread.\n\n
- Compablity\n
- \n
- \n
- http://microjs.com/\n\nUse micro library, know what the library does.\n\nKnow the quality of the code.\nAvoid duplication of functionally.\n\nzepto, when.js, require.js, backbone.js...\n
- http://microjs.com/\n\nUse micro library, know what the library does.\n\nKnow the quality of the code.\nAvoid duplication of functionally.\n\nzepto, when.js, require.js, backbone.js...\n
- http://microjs.com/\n\nUse micro library, know what the library does.\n\nKnow the quality of the code.\nAvoid duplication of functionally.\n\nzepto, when.js, require.js, backbone.js...\n
- http://microjs.com/\n\nUse micro library, know what the library does.\n\nKnow the quality of the code.\nAvoid duplication of functionally.\n\nzepto, when.js, require.js, backbone.js...\n
- \n
- \n
- Whats happened is our big data payload request 16 is now coming from Localstorage and the other assets are coming for the AppCache.\n\nThere is still an issue with the parse time.\n\n
- So lets take a look at a couple of things which will affect a user’s experience interacting with our app after it has loaded.\n\nFirst up animation. I mentioned that we have limited hardware resources available, one thing we do have access it the device’s GPU (Graphics Processing Unit).\n\nIn the reality we shouldn’t be trying to do any kind of animation on a mobile device unless we can offload it to the GPU.\n
- We can make an element H/W accelerated by applying a CSS transform. This puts it on to the GPU as a surface or texture.\n\ndon’t put too much on it as this will cause textures to get flushed.\n\n
- We can make an element H/W accelerated by applying a CSS transform. This puts it on to the GPU as a surface or texture.\n\ndon’t put too much on it as this will cause textures to get flushed.\n\n
- We can make an element H/W accelerated by applying a CSS transform. This puts it on to the GPU as a surface or texture.\n\ndon’t put too much on it as this will cause textures to get flushed.\n\n
- We can make an element H/W accelerated by applying a CSS transform. This puts it on to the GPU as a surface or texture.\n\ndon’t put too much on it as this will cause textures to get flushed.\n\n
- Repaints can occur when ever a DOM style is updated.\nReflows (things like resizing of elements) can be more costly as they have to recalculate all the elements on the page.\n\nAvoid box shadows - Use border image or add element to a parent container and then don’t animate the contents so the can be saved as a texture.\n\nAvoid un-rendered content i.e. text-indent: -99999em - this makes the device render a large panel\n\nrequestAnimationFrame not tided to the UI thread, can be put to sleep / shutdown by the device. \n
- Repaints can occur when ever a DOM style is updated.\nReflows (things like resizing of elements) can be more costly as they have to recalculate all the elements on the page.\n\nAvoid box shadows - Use border image or add element to a parent container and then don’t animate the contents so the can be saved as a texture.\n\nAvoid un-rendered content i.e. text-indent: -99999em - this makes the device render a large panel\n\nrequestAnimationFrame not tided to the UI thread, can be put to sleep / shutdown by the device. \n
- Repaints can occur when ever a DOM style is updated.\nReflows (things like resizing of elements) can be more costly as they have to recalculate all the elements on the page.\n\nAvoid box shadows - Use border image or add element to a parent container and then don’t animate the contents so the can be saved as a texture.\n\nAvoid un-rendered content i.e. text-indent: -99999em - this makes the device render a large panel\n\nrequestAnimationFrame not tided to the UI thread, can be put to sleep / shutdown by the device. \n
- RE-USE DOM ELEMENTS.\n\nUse touch events - Don’t use mouse events, these incur a 300ms delay. Bill Fisher’s talk yesterday covered some really great ways to deal with touch events.\n\nAlso the when placing listeners. Its generally to add them to a single parent not rather than to individual elements. Libraries like Zepto or JQuery help you with this though Delegate and Live.\n\nTake advantage of the Event model, capture and bubble phase.\n\n
- Use touch events - Don’t use mouse events, these incur a 300ms delay.\n\nAlso the when placing listeners. Its generally to add them to a single parent not rather than to individual elements. Libraries like Zepto or JQuery help you with this though Delegate and Live.\n\nTake advantage of the Event model, capture and bubble phase.\n\nclosures\n
- \n
- You will need some kind of build process. I personally use ANT, cos I’m a sucker for XML, but you can use make, rake, jake... What’s important is that you need some kind of tool to transform your src code into something which you can deploy.\n\nWhat do we make our build do:\nResolve JS dependencies, concat, uglify, SASS\nBuild cache manifests.\nRun tests, JSLint, Jasmine + PhantomJS\nDeploy\n\nIssues you can find in minified code.\n\nBuild macros, pre processes.\n\ndebug and release builds.\n\n\n
- You will need some kind of build process. I personally use ANT, cos I’m a sucker for XML, but you can use make, rake, jake... What’s important is that you need some kind of tool to transform your src code into something which you can deploy.\n\nWhat do we make our build do:\nResolve JS dependencies, concat, uglify, SASS\nBuild cache manifests.\nRun tests, JSLint, Jasmine + PhantomJS\nDeploy\n\nIssues you can find in minified code.\n\nBuild macros, pre processes.\n\ndebug and release builds.\n\n\n
- Istat Menu\nTest in the real world\nAvoid the latest and greatest (aka 4S and 5)\n
- Istat Menu\nTest in the real world\nAvoid the latest and greatest (aka 4S and 5)\n
- Istat Menu\nTest in the real world\nAvoid the latest and greatest (aka 4S and 5)\n
- Istat Menu\nTest in the real world\nAvoid the latest and greatest (aka 4S and 5)\n
- Istat Menu\nTest in the real world\nAvoid the latest and greatest (aka 4S and 5)\n
- Istat Menu\nTest in the real world\nAvoid the latest and greatest (aka 4S and 5)\n
- Istat Menu\nTest in the real world\nAvoid the latest and greatest (aka 4S and 5)\n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- We are trying make 5* apps which people will tweet and blog about.\nOptimization is just a piece of the puzzle.\n
- \n
- \n