Performance as UX with Justin Howlett
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

Performance as UX with Justin Howlett

  • 617 views
Uploaded on

Presented at SCREENS 2013 in Toronto. ...

Presented at SCREENS 2013 in Toronto.
Details at fitc.ca/screens

In this talk, Digiflare lead iOS developer Justin Howlett will discuss the impact of performance on User Experience. Justin will discuss easy to implement platform agnostic techniques, technologies and libraries to improve your user experience through performance. Although most techniques and technologies are platform agnostic many of the case studies and examples will be presented in native Objective-C for iOS.

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
617
On Slideshare
614
From Embeds
3
Number of Embeds
1

Actions

Shares
Downloads
10
Comments
0
Likes
3

Embeds 3

https://twitter.com 3

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Performance as UX Justin Howlett @justinhowlett @Digiflare
  • 2. Who am I?
  • 3. Tradition view Save bandwidth costs Save server costs Simply be able to run on a platform My app/website is good enough - - - -
  • 4. Put the user first Performance improvements should be to improve the user experience Think of it as a 100ms experience improvement not a performance bump. You can design and develop for speed in order to improve UX - - -
  • 5. Will a user really notice a 200ms delay?
  • 6. “Users really respond to speed” !!!!!!!!- Marissa Mayer CEO Yahoo!
  • 7. Quantifying the User Experience Why$Performance$matters$to$User$Experience
  • 8. A 500ms delay on google.com results in a 20% reduction in traffic.
  • 9. A 100ms delay on amazon.com results in a 1% reduction in sales.
  • 10. Limit for users feeling that they are directly manipulating objects in the UI. For example, this is the limit from thetime the user selects a column in a table until that columnshould highlight or otherwise give feedback that it'sselected. Ideally, this would also be the response time forsorting the column - if so, users would feel that they are sorting the table. 0.1 second
  • 11. Limit for users feeling that they are freely navigating thecommand space without having to unduly wait for thecomputer. A delay of 0.2-1.0 seconds does mean thatusers notice the delay and thus feel the computer is"working" on the command, as opposed to having the command be a direct effect of the users' actions 1 second
  • 12. Limit for users keeping their attention on the task. Anything slower than 10 seconds needs a percent-doneindicator as well as a clearly signposted way for the user to interrupt the operation. 10 seconds
  • 13. Smooth animations and scrolling are often cited as major reasons iOS users stay iOS users.
  • 14. Topics Covered
  • 15. Topics Covered Myths about performance Easy to implement techniques Emerging standards that improve performance The perception of performance - - - -
  • 16. Topics Avoided Big-O notation Too much Objective-C / iOS - -
  • 17. A brief note You don’t have to implement any of these, just beware of what is out there. There are technical descriptions but feel free just to focus on the diagrams, they tell the most important story. - -
  • 18. “Don’t Trust Anyone. Don’t believe blindly what you are told. Perform experiments, test your own data and code with your own users and devices. What ‘seems obvious’ is not always true.” !!!!!!!!- David Lee
  • 19. Run tests on your own stack and on your own data. Then run them again just to make sure.
  • 20. Myths about performance
  • 21. XML is much slower than JSON on the web.
  • 22. “Overall using native JavaScript the use of XML and JSON is essentially identical performance for total user experience (transfer plus parse plus query)” !!!!!!!!- David Lee
  • 23. but, but, JSON...
  • 24. “This study must have been done 5 years ago on a typewriter running IE6”
  • 25. 33 different documents The most commonly used browsers and operating systems Includes mobile devices August 6-9 2013 - - - - XML is NOT much slower than JSON on the web.
  • 26. UITableViewCells are rendered quicker in Core Graphics.
  • 27. What the heck is a “UITableViewCell” ?
  • 28. What the heck is a “Core Graphics” ? Draw flat using the CPU Lines, fills, shapes etc.. - -
  • 29. Draw it flat with the CPU, GPU does less work and bam! extra fps. Now let’s celebrate!
  • 30. http://floriankugler.com/blog/2013/5/24/layer<trees<vs<flat<drawing<graphics<performance<across<ios<device< Where is your “fast cell technique” now?
  • 31. This appears on stackoverflow more than you can possibly imagine.
  • 32. Easy to use tools to improve web performance.
  • 33. Google Page Speed Insights
  • 34. Yahoo! YSlow
  • 35. 23 testable rules that affect performance Minimize'HTTP'Requests Use'a'Content'Delivery'Network Avoid'empty'src'or'href Add'an'Expires'or'a'CacheDControl'Header Gzip'Components Put'StyleSheets'at'the'Top Put'Scripts'at'the'Bottom Avoid'CSS'Expressions Make'JavaScript'and'CSS'External Reduce'DNS'Lookups Minify'JavaScript'and'CSS Avoid'Redirects Remove'Duplicate'Scripts Configure'ETags Make'AJAX'Cacheable Use'GET'for'AJAX'Requests Reduce'the'Number'of'DOM'Elements No'404s Reduce'Cookie'Size Use'CookieDFree'Domains'for'Components Avoid'Filters Do'Not'Scale'Images'in'HTML Make'favicon.ico'Small'and'Cacheable
  • 36. Your users may not be consciously aware but performance drives positive user experiences.
  • 37. Emerging standards and libraries That%you%can%use%right%now%if%you’re%brave
  • 38. Server side push Communication driven by both the server as well as the client.
  • 39. Server side push Not just for real-time applications 1 request and 4 responses is faster than 4 requests and 4 responses - -
  • 40. Server side push Traditionally this was sockets over some terrible port that was probably blocked anyway. Or done with long polling. (YUCK) - - Old$and$busted
  • 41. Server side push Multiple emerging standards Websockets Push notifications Not a standard HTTP 2.0 SPDY+Push - - - - - - The$new$hotness
  • 42. Server side push
  • 43. HTTP 2.0 (SPDY) Google initiative SPDY Hint Rather than automatically pushing resources to the client, the server uses the X-Subresources header to suggest to the client that it should ask for specific resources, in cases where the server knows in advance of the client that those resources will be needed SPDY Push SPDY%experiments%with%an%option%for%servers%to%push%data%to%clients%via%the%X:Associated:Content%header.%This%header informs%the%client%that%the%server%is%pushing%a%resource%to%the%client%before%the%client%has%asked%for%it.%% - - - - -
  • 44. HTTP 2.0 (SPDY) HTTP SPDY SPDY+Hint Average ms 3111 1695 1608 Speedup 45.51% 48.30%
  • 45. HTTP 2.0 (SPDY)
  • 46. HTTP 2.0 (SPDY) Available for Apache as mod-spdy Available for Nginx as a patch
  • 47. Websockets Easy Implementation, especially in NodeJS. Support on all current browsers except the Android browser. - -
  • 48. Websockets
  • 49. Messagepack “It's like JSON.but fast and small.”
  • 50. Messagepack Binary serialization format Always smaller than XML and JSON - -
  • 51. Messagepack JSON 8.0KB Messagepack 5.3KB
  • 52. Messagepack *Languages,*Encode*and*Decode*sets*may*be*based*on*entirely*different*sample*data*and*hardware. Language Messagepack Encode Messagepack Decode JSON Encode JSON Decode Python 2.75s 0.72s 3.33s 6.83s Ruby 0.06s 0.10s 0.42s 0.23s NodeJS 5.0s 3.5ms 1.0ms 1.0s Java 759ms 1386ms 1201ms 1216ms
  • 53. Messagepack Not right for everyone Client-side gains might easily outweigh server-side loses Test with your own data using your own stack - - -
  • 54. Image compression Your%PNGs%are%bad%and%you%should%feel%bad.
  • 55. Before we get started JPEGs are for photography GIFs are for animated cats PNGs are for everything else
  • 56. Before we get started If you save your 2 color logo as a jpeg you should be banned from the internet. Think of the electricity we could save if everyone simply saved their images in the correct format.
  • 57. Before we get started </rant>
  • 58. Your PNGs are bloated You’re likely using PNGs that are 4x larger in disk size than they need to be.
  • 59. Your PNGs are bloated It’s difficult for users to shop on your site when your images take forever to load.
  • 60. Your PNGs are bloated Savings can be lossy or lossless 24bit vs 8bit PNG Color palette reduction (256 to 2 colors) Lossy color reduction causes banding - - - -
  • 61. Your PNGs are bloated 139KB (24bit) 41KB (8bit 256 colors) 21KB (8bit 64 colors)
  • 62. Your PNGs are bloated What is banding and how to mitigate it.
  • 63. Lossless image compression PNGOUT Zopfli Pngcrush AdvPNG OptiPNG - - - - -
  • 64. Image compression ImageOptim OSX (contains all previously mentioned libraries) JpegMini (OSX + Windows) ImageAlpha OSX - - -
  • 65. Image Size Reduction Huge impact on shipping application size, download wait time. Huge impact on asset downloading times Downloading and installing a 1GB app is an awful. And yes you’re still responsible for that part of your user experience. - - - http://imageoptim.com/tweetbot.html
  • 66. But wait, there’s more. Image size reductions have a direct impact on the performance of iOS applications. (And probably all others)
  • 67. Image Performance gains “Xcode-optimized images were significantly slower to display. Decoding speed appears to be correlated to image file size more than anything else (most likely savings on byteswapping are negligible compared to additional disk I/O and extra data to decompress.)” http://imageoptim.com/tweetbot.html
  • 68. webP What is webP and why does it render everything I just said obsolete?
  • 69. webP One format to rule them all.
  • 70. webP Open source, developed mainly by Google. 25-34% smaller than JPEGs 26% smaller than PNGs Supports alpha channel Animation support (though ironically the chrome team won’t support it) - - - - -
  • 71. webP Many mobile Operating systems and GPUs are heavily optimized for PNGs WebP should not replace PNG assets that ship with an application. For low internet speeds, small sized images and desktops it may be a great option, easy to fallback. ! ! !
  • 72. webP Performance JPEGwebPJPEG JPEG webP webP 0481216200 0 4 4 8 8 12 12 16 16 20 20 Image Size (KB) Image Size (KB)
  • 73. webP Performance JPEGwebPJPEG JPEG webP webP 00.020.040.060.080 0 0.02 0.02 0.04 0.04 0.06 0.06 0.08 0.08 iOS Render Time iOS Render Time
  • 74. webP support Chrome 9+ Opera 12+ Android browser 4.0+ Opera Mobile 11.1+ Chrome for Android 29+ - - - - -
  • 75. Techniques to improve performance Without'having'a'PHD'in'Computer'Science
  • 76. Behavioral APIs Sits between DB or API or Feeds and the client. Abstract heavy parsing and multiple requests to a server Reduce data sent to the client I don’t care what “page” of data this came from. - - - -
  • 77. Behavioral APIs Prepare data in a way that’s best for that particular device messagepack, json, jsonP, XML, PNG, webP. Prepare data in a way that’s best for the application This views has these 4 elements, this endpoint provides all four models at the same time. - - - -
  • 78. Unnecessary iteration A case study.
  • 79. Unnecessary iteration The worst way
  • 80. Unnecessary iteration int bytesPerPixel = 4; //r,g,b,a for(int x = 0; x < imageWidth; x++) { for(int y = 0; y < imageHeight; y++) { int pixelStartIndex = (x + (y * imageWidth)) * bytesPerPixel; int r = pixels[pixelStartIndex ]; int g = pixels[pixelStartIndex +1]; int b = pixels[pixelStartIndex + 2]; //calculate the luminosity of the pixels } }
  • 81. Unnecessary iteration Do you really need the pixel location in the image?
  • 82. Unnecessary iteration The better way
  • 83. Unnecessary iteration int bytesPerPixel = 4; //r,g,b,a for(NSInteger i=0; i<length; i+= bytesPerPixel){ int r = pixels[i]; int g = pixels[i+1]; int b = pixels[i+2]; }
  • 84. Unnecessary iteration If my image has 100 pixels. 1 loop2 loops1 loop 1 loop 2 loops 2 loops 02000400060008000100000 0 2000 2000 4000 4000 6000 6000 8000 8000 10000 10000
  • 85. Don’t try and do everything yourself Apple has implemented sorting algorithms far better and far faster than I could ever dream to.
  • 86. Threading for performance Some%people,%when%confronted%with%a%problem,%think,%"I%know,%I'll%use threads,"%and%then%two%they%hav%erpoblesms.
  • 87. Threads, queues, workers
  • 88. Embarrassingly parallel Little&or&no&effort&is&required&to&separate&the&problem&into&a&number&of&parallel&tasks.
  • 89. Threading Case Let’s&break&up&our&image&into&smaller&chunks&and&iterate&those&chunks&using&separate&threads
  • 90. Threading for Performance 1 Thread2 Threads3 Threads4 Threads100 Threads1 Thread 1 Thread 2 Threads 2 Threads 3 Threads 3 Threads 4 Threads 4 Threads 100 Threads 100 Threads 012340 0 1 1 2 2 3 3 4 4 iPhone 5 iOS7 (lower is better) iPhone 5 iOS7 (lower is better)
  • 91. Threading for Performance +5%$performance$when$recompiled$as$a$646bit$binary$
  • 92. Threading for Performance 1 Thread2 Threads3 Threads4 Threads100 Threads1 Thread 1 Thread 2 Threads 2 Threads 3 Threads 3 Threads 4 Threads 4 Threads 100 Threads 100 Threads 012340 0 1 1 2 2 3 3 4 4 OSX 10.8 rMBP (lower is better) OSX 10.8 rMBP (lower is better)
  • 93. Threading for Performance More threads aren’t better Threads can be expensive to spawn Thread spawn cost can outweigh performance gains Data set size, hardware and threading API performance are the largest contributing factors Threads are difficult to debug - - - - -
  • 94. CDNs Divide&and&conquer
  • 95. If you’re using Amazon S3 or a static server and your user base isn’t hyper local... you’re doing it wrong.
  • 96. http://www.quora.com/What0are0typical0latencies0for0static0content0in0S30vs0Cloudfront S3CloudFrontS3 S3 CloudFront CloudFront 040801201602000 0 40 40 80 80 120 120 160 160 200 200 Latency from EU (ms) Latency from EU (ms) CDNs
  • 97. Reuse and recycle
  • 98. UITableViewCells UICollectionViewCells Reuse DOM Elements - - - Reuse and recycle
  • 99. Reuse DOM Elements “The solution is to recycle DOM nodes once they’re no longer visible. In this way, a list that seems to have infinite content could contain only say 10 elements – just enough to fill the screen. Once you scroll down the list, DOM nodes that scrolled off the top are detached, updated with new data and placed at the bottom of the list. Simple. Ingenius. Beautiful.” Sencha Fastbook
  • 100. Reuse DOM Elements Sencha Fastbook
  • 101. Preload and prerender
  • 102. Prioritize prefetching intelligently Detect where scrolling will end up and load that content Load popular content Load content that a user is otherwise likely to want to see If you’re block the UI or the use of the application you’re doing it wrong Ship with a full cache, first load shouldn’t be slower than any - - - - - - Preload and prerender
  • 103. But, be careful... “In most cases, pre-fetching won't be nearly as beneficial as you might expect. On a mobile device, power and bandwidth are limited resources, which calls into question the value of loading things that a user may not actually ever see. You're most likely doing a disservice by trying to be clever about this.” !!!!!!!!- Mattt Thompson
  • 104. The Perception Of Performance When%it’s%okay%to%lie
  • 105. How do I implement that? Don’t start from zero Microinteractions and animations can buy you time while you load Button Downstates Asynchronous UI. Assume success, handle failure gracefully. Prioritize performance for human beings • • • • •
  • 106. Don’t start from zero Predictive analysis Load popular content first Oculus rift prerendering based on human neck acceleration curve • • •
  • 107. Microinteraction and Animations Buy yourself time by surprising and delighting Simple animations and interactions can not only give your project a premium feel but can actually buy you time Jetsetter • • •
  • 108. Jetsetter
  • 109. Prioritize Responding to touch and ensuring smooth scrolling and animation have more impact than image load times. You can have the fastest network request on the planet but if you don’t respond to the user input immediately you’ll be branded slow.
  • 110. Asynchronous UI Assume success and fail gracefully Reflect the user request immediately or almost immediately If you need to send more information later then do so Instagram • • • • https://speakerdeck.com/mikeyk/secrets-to-lightning-fast-mobile-design
  • 111. Asynchronous UI https://speakerdeck.com/mikeyk/secrets-to-lightning-fast-mobile-design
  • 112. Questions
  • 113. We’re hiring!