Created
July 5, 2012 21:13
-
-
Save m0nkey/3056456 to your computer and use it in GitHub Desktop.
Velocity 2012 notes
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Velocity Conference 2012 | |
| DAY 1, Monday | |
| Mobile Web Application Performance | |
| Estelle Weyl (standardista.com) | |
| - http://estelle.github.com/mobileperf | |
| - Pro-tip: use pointer-events:none; to debug z-index issues (click through to lower layers). | |
| - "Spinners are boring! Use a ball or something. :P" | |
| - Q&A, Souders: DragonFly, profiler Android, can phones be on carrier network to measure reflows, etc? DragonFly is the solution. | |
| - localStorage: Why not use HTML5 Application Cache? App Cache has a really bad rep right now, Bing as example. Really big image daily. When you reload you reuse everything from the cache until you have 100% of the app cache is ready. | |
| Taming the Mobile Beast | |
| Patrick Meenan (Google) | |
| Matt Welsh (Google) | |
| Announcing https://developers.google.com/speed/pagespeed/insights?velocity=1 | |
| - mobi.test implementation on webpagetest; view iOS and Android | |
| - Pat Meenan blog post re: mobile testing - github project | |
| - HARViewer | |
| - Mobile Waterfalls | |
| - brown.edu waterfall, 75 seconds on 3G | |
| - 124 KB background image that is obscured behind content | |
| - Make a connection to the mobile carrier | |
| - Ookla/Speedtest.net: overview of typical mobile network performance | |
| - Cell network connectivity idle time can occur in the middle of user context (2 second to re-establish the callback). | |
| - Mobile network test: Build a webpage that loads a small 1KB image repeatedly at increasing intervals. Watch how long it takes to load. | |
| - Souders: Blog entry on making a mobile connection (great info on radio link latency): http://goo.gl/F5sKV | |
| - More TCP connections (from the mobile browser) are not always better. Each connection pays the cost of the TCP handshake (200ms on typical 3G links). Parallel can adversely compete for the channel. Domain sharding can actually be a bad thing (less important) on mobile due to the DNS roundtrips. | |
| - HTTP Pipelining - multiple GET requests in parallel. | |
| - Most carriers do transparent web proxying. T-Mobile example showed that nearly 1MB file changed over 3G, carrier gzipped the file. | |
| - SunSpider stats references, slower embedded processors will (obviously) show slower benchmarks. | |
| - Not all mobile caches are created equal. Perhaps 1/2 or 1/4 cache size available on mobile compared to desktop. | |
| - Web view components in native apps are NOT the same as the browser itself. Performance will differ; for example no caching available in web views. | |
| - CPU profiling of JS functions using Chrome Dev Tools (demo showed tethered Chrome on Android) | |
| - iOS6 also has mobile debugging: bit.ly/L1zXTX | |
| - JS Bookmarklets for mobile debugging (refer to Standardista slides re: Souders bookmarklet overlays) | |
| - JDrop - JSON bookmarklet post-consumption | |
| - DOMMonster - How complex is your DOM? | |
| - Docsource | |
| - cssess | |
| - Snoopy | |
| - SpriteMe | |
| - webkit resource timing bug id=61138 | |
| - PageSpeed Insights | |
| - PCAP Web Performance Analyzer (tcpdump/packet capture) pcapperf.appspot.com | |
| - icy (mobile browser with sniffing) Apple developer license only (not in the app store) | |
| - iWebInspector | |
| - winre | |
| - User Agent Switcher Extensions (viewport scaling doesn't work, no touch events, etc.) | |
| - WebPageTest (spoof user agents) | |
| - Key take away: Measuring mobile web behavior is hard! | |
| - Navigation timing on Windows Mobile and Android 4+, not in iOS 6 spec yet (will it be?). | |
| - Google Analytics provides free RUM. Know what you are measuring and why you are measuring it that way. | |
| - SSL connections make 3 extra roundtrips; be really careful about what your app really needs. What about Speedy? Circumvents carrier proxies, but also prevents the carrier from employing optimizations. You should manage your own optimizations anyway. | |
| - Chrome for Android background prefetching? | |
| - Watch out for bytes stream and turning on the radio regarding performance of web sockets. They create TCP connections. Really high latency connection on mobile. | |
| - Track the actual metrics of carriers from where your users are coming from. Seems obvious; look at the actual user data. | |
| Dev vs. Prod: Optimizing Your Site Without Making Your Build Process Suck | |
| Ian White (Neustar) | |
| - The process problem: Perceived problem with optimization, misconception that profitability is impacted by the same time spent on optimization rather than strictly on building the thing faster. | |
| - If your site loads faster people will stay longer. Value propopsition; get a user in the first 20 seconds and they will stay for 2 minutes. | |
| - mod_pagespeed | |
| - serving static resources: nginx, have a reverse proxy for optimization | |
| - flask referenced for ease of using in minification | |
| - versioning static urls, md5 hashes are meaningless to humans but build numbers have semantic significance | |
| - versioning semantically in url helps well with offline caching | |
| - image optimization, smush.it (yahoo), pngcrush, image optimization pipeline (serge) | |
| - @2x Apple's recommended retina optimization | |
| - css sprites: glue by jorgebastida on github | |
| - checkout and go: default config to dev settings, make it as easy as possible for new devs to get up and running, override for each environment as needed, offload as much as possible from the build process ("do it live!"), if you decide to pre-generate create tasks in the application -- refer to app manifest and localCache | |
| The 90-Minute Mobile Optimization Life Cycle | |
| Hooman Beheshti (Strangeloop Networks) | |
| - Chrome Remote Debugging on ICS, iwebinspector.com, weinre (web inspector remote), aardwolf (remote debugging of javascript), Steve Souders mobile perf bookmarklet, pcapperf.appspot.com, RUM, webpagetest.org | |
| - Problems: Too many connections,,Too many bytes (time to first byte, pipelining helps here), No CDN, Too many round trips, Poor caching, 3rd party calls (marketing tags, analytics, etc) -- big problem | |
| - Stepwise acceleration/optimization | |
| Low hanging fruit | |
| - add HTTP keep-alive connections | |
| - add HTTP compression | |
| - Expect: fewer connections, fewer bytes | |
| CDN | |
| - improve time to first byte | |
| Mobile FEO | |
| - consolidate resources (css, js, images) | |
| - image compression | |
| - minification | |
| - optimal use of localStorage | |
| More mobile FEO | |
| - deferral of round trips to after onload | |
| Mobile caching | |
| - where to put the objects? | |
| - the size of the cache? | |
| - smaller than desktop | |
| - think about total cache size limit | |
| - user behavior may affect what's served from cache | |
| - things are getting better but not at the pace we want | |
| - stevesouders.com/cache.php | |
| - localStorage | |
| - ~2.5mb key/value store per domain | |
| - programmable | |
| - Deferral of images (not just 3rd party) not in the viewport | |
| - One or more scrolls of deferral? | |
| - HTML Caching | |
| - be more granular, smarter | |
| - Convert click events to touch events, smart usage of localStorage, redirection suppression, 3G vs. WiFi navigation selection options (Android only?) | |
| - HTTP Pipelining | |
| - Packet drops in cell networks suck for pipelining | |
| - TCP Windows | |
| - init_cwind | |
| - Google recommends 10 | |
| - minimum send/receive handshake from server/client; receive window packets limit returned data on client | |
| - good idea to have larger cwinds | |
| - CDN planet cwind optimization artle | |
| - Radios connection idle time disconnects from the tower to save battery life | |
| - 1-2 seconds to restore connection | |
| - souders blog article on this topic | |
| - webperformancetoday.com | |
| - strangeloopnetworks.com | |
| - bit.ly/velocitycdntest | |
| DAY 2, Tuesday | |
| Lightning Demos: | |
| Patrick Meenan (Google) | |
| Bryan McQuade (Google) | |
| Dallas Marlow (Tumblr) | |
| Steve Souders (Google) | |
| - wpofoundation.org and webpagetest.org mobile testing | |
| - Load remote download data into dev tools in Chrome | |
| - Speed index is a great proxy for the user experience as we move toward lazy loading, etc. | |
| - Critical path explorer on pagespeed insights. | |
| - httparchive.org | |
| - ctlab.org Dr Richard Cook | |
| - Web timings highlights from @vikchaudhary re: APIs built into major browsers in last 12 months. | |
| Performance Implications of Responsive Web Design | |
| Jason Grigsby (Cloud Four) | |
| @grigs | |
| - http://velocityconf.com/velocity2012/public/schedule/detail/24868 | |
| - Reorder media queries so that they go from small screen to large screen | |
| - Some devices do not support media queries, use conditional comments when needed (IE). | |
| - use mediaMatch() polyfill | |
| - Conditional CSS (Jeremy Keith) - event driven functionality to drive behaviors of the page based on break points | |
| - A List Apart: responsive images - define different sized images using the same img src? more difficult than it seems. | |
| - Picturefill JS lib (preferred) or Sencha.io src solution | |
| - Handle high density images carefully - don't download massive images if you can avoid it, don't download multiple times (Apple)! Use CSS images whenever possible via media queries based on the module or use-case. image-set proposal in CSS. | |
| - foresight.js - network speed is not a constant so be careful not to depend on these features | |
| - Filament Group Southstreet | |
| Performance Lessons Learned from the PhoneGap Team | |
| Brian LeRoux (Adobe Systems) | |
| - Do as Souders does. | |
| - Be future friendly. Retina display as an example. | |
| - Time to market ... small teams kick ass (2 devs and 1 IxD) | |
| - Testing! | |
| - Don't hide your roadmap or issue tracker. | |
| - JSON proxy to the data! If you can cache that on the client even better. | |
| - Ship daily. Devs don't get burned out on the work, they get burned out on rapidly changing requirements and not being able to ship things. | |
| - Security is not possible on the phones, cannot encrypt/decrypt on the phone. Auth methods have to be made to backend Be responsible about what data you access and use on the user's phone. | |
| - Launch dates and marketing -- don't have to be in sync with release cycle, don't let marketing control the release cycle. | |
| - Metrics watch what you users are doing. Reduce WTF/min for developers. Hang out with and support your team. | |
| - Develop in the web browser. Test on real devices not on an emulator. | |
| - UX concerns: emulating the native controls can be difficult, just follow what is best for your app; great UX is goal directed; UX is itterative - don't just hand over static designs devs | |
| - "the web is a self healing system" james pearce, facebook | |
| - Proprietary lock-in is a performance antipattern. | |
| - HTML: DOM reflows are a killer of performance; avoid deeply nested structures. Twitter Bootstrap could hurt in terms of heavy nested divs. | |
| - grunt.js | |
| - CSS: always put in the head to avoid FOUC; deeply nested selectors are a performance problem; don't use opacity on things that don't need it. Hardware acceleration is not everywhere, do not rely on transforms, etc that they would depend on hardware accel that isn't there. | |
| - Images: responsive images @scottjehl | |
| - eCSSential or css-slap-chop -- clean up Bootstrap CSS that's not used | |
| - HTML5 async or defer | |
| - script loader? controljs.org | |
| - Google lazy eval technique hack? | |
| - github.com/bebraw/jswiki/wiki/Touch | |
| - JS Frameworks to hate on: jquerymobile, sencha, twitter bootstrap | |
| - Maybe to love? xuijs and zepto | |
| - MVC: backbone + underscore, emberjs | |
| - lukew - focus on the user not the convenience for the developer | |
| - localStorage to eval later for JS and CSS, clever means of offline reload and increasing performance (see other localStorage references, this comes with risk). | |
| - sencha probably has the most advanced tooling; but not the ultimate answer | |
| - Get an Android 2.3 phone, probably more users in the wild than iOS 5.1. | |
| - Chrome Canary build | |
| - When to use Cordova/PhoneGap? Only when you want to deploy an app otherwise use native, don't be silly. | |
| Using Node.js to improve the performance of Mobile apps and Mobile web | |
| Tom Hughes-Croucher (Jetpacks for Dinosaurs) | |
| - Effect of latency on servers ... most people shield their front ends (nginx, varnish, etc) highly tuned for HTTP performance. Test tcp connection via helo in JS ... many servers take a looong time to kill that connection that asked for nothing. | |
| - Event-driven frontends, placeholders and shared work resources - example of user no longer acking back back packets because they walked into a building and their radio signal is dead. | |
| - Front-end MVC approach really sucks for the 1st page load. | |
| - Bandwidth, latency, device capability | |
| - Interesting: shoving innerhtml into the template appears to render much faster on mobile | |
| - Node.js affords the options to pick either HTML rendering or JSON rendering depending on the need. HTML will be more efficient in many ways, however JSON will be "cheaper" in terms of bandwidth for the server and the client. | |
| Rendering Slow? Too Much CSS3? Ask RSlow | |
| Marcel Duran (Twitter Inc.) | |
| David Calhoun (CBS Interactive) | |
| - Reflows, slow perceived performance | |
| - -prefix-free, LESS, SASS | |
| - Scroller bookmarklet (Andy Edinborough) for debugging CSS3 performance | |
| - Opera Dragonfly and Chrome Canary referenced | |
| - iWebInspector | |
| - Weinre | |
| - Chrome Developer Tools allows export of timeline as JSON, rendering and painting (Chrome Canary) | |
| - Cuzillion | |
| - Hardware acceleration of image compositing a performance boost is seen for CSS background over img tag. | |
| - utf8ify.com | |
| - Use @font-face iconography, more performant than background image | |
| - 24ways spinner CSS3 transitions? | |
| Time To First Tweet | |
| Dan Webb (Twitter Inc) | |
| Rob Sayre (Twitter) | |
| - Twitter performance improvements blog article: http://engineering.twitter.com/2012/05/improving-performance-on-twittercom.html | |
| - Performance is highly contextual; neither server-side or client-side is correct | |
| - Use navigtaion timing API using real user data; Twitter only captures a small percentage but it's an acceptable amount for guaging overall usability/expectations: connect, process, response, render. | |
| - "Hydrating" tweets; only showing the stuff on the page that's cachable (ie. common pages primed) at first then showing more as needed | |
| - Front-end templating: Mustache.js -> Hogan.js -> Pre-compiled (JS concatenated strings) vs. Server-side templating: Mustache.rb -> Eckersley -> Mustache.java (jvm) | |
| - Loading JS: module system, CommonJS via AMD; decouple loading from eval; build tool spiders dependencies and make bundles; lazy loading, parallel loading, different bundles | |
| - Layer On pushState support; avoid full page refreshes for newer browsers | |
| - onClick if history API supported then intercept link and munge with XHR; if request comes from XHR just send partial via JSON, otherwise send the whole HTML page. | |
| DAY 3, Wednesday | |
| Lightning Demos: | |
| Marcel Duran (Twitter Inc.) | |
| @marcelduran | |
| - YSlow, 5 years old (happy birthday!) | |
| - npm install yslow -g | |
| - parse .har files from WPT | |
| @sajal (CDN contrib to YSlow) | |
| - YSlow for PhantomJS - junit integration for continuous integration automation (jenkins, travis ci, etc)! | |
| - yslow.nodester.com - run remote .har files | |
| - showslow.com beacon results from nodester | |
| Nat Duca (Google) | |
| - CSS animations, tracing in Chrome | |
| - chrome://tracing | |
| - screen updates at 60hz, 16ms or so | |
| - sleep timer at 180ms to fake slowness | |
| - renderermain is js renderer thread | |
| - use tracing and interact with the page to capture | |
| - jankfree.com | |
| Lindsey Simon (Twist) | |
| - Browserscope - engine for performing tests and medians | |
| - urloritdidnthappen.appspot.com/render/93001 | |
| Changing Culture & Being a force for Awesome... | |
| Jesse Robbins (Opscode) | |
| @jesserobbins | |
| - Created GameDay, part of larger discipline of resilience engineering | |
| - Hacks: | |
| - Start small, not a threat to the establishment within your organization | |
| - Create champions, get executive sponsors, starting with your boss | |
| - Give everyone else the credit | |
| - give "special status" and make sure they brag about it | |
| - Metrics: | |
| - Find a kpi that supports change | |
| - Track and use it ruthlessly, show value and convert laggards | |
| - _tell your story with data_ | |
| - Celebrating successes, tell a powerful story | |
| - Always be positive about people and how they overcame a problem | |
| - Never about people who created the problem | |
| - Leave room for people to come to your side (don't fight stupid) | |
| - Compelling events: | |
| - Just wait it will come | |
| - Can be created by things like compliance, scaling, cloud migrations | |
| - Not "I told you so" - but "what do we do now" | |
| - Permission: | |
| - Don't ask for permission, ask for forgiveness | |
| - FEMA/anarchists example of Katrina -- often people aren't saying no, they just don't know how to say yes. | |
| - Document your authority in your shared wiki; permission that you need you make. | |
| - Start small, build trust & safety | |
| - Create Champions | |
| - Use metrics to build confidence | |
| - Celebrate successes | |
| - Expoit Compelling Events | |
| Wisdom of the Crowd: Gathering Insights from Real User Monitoring | |
| Patrick Lightbody (Neustar Web Performance) | |
| @plightbo | |
| - Redefine real user monitoriing as: real user measurement "RUM_easurement_" | |
| - pingdom, synthetic HTTP monitoring | |
| - selenium + jenkins + "cloud" | |
| - window.onerror DO NOT return true; hat tip to dropbox for capturing JS errors | |
| Browsers | |
| Luz Caballero (Opera Software) | |
| @gerbille | |
| Opera mobile | |
| - Focus on limited network speed and expensive data fees - markets trend to countries falling under this classification | |
| - Opera mini is a thin client/proxy to a server, binary optimized format not HTTP -- OBML | |
| - Data compression to/from the browser is handled effeciently; uses progressive loading | |
| - Tradeoffs: Presto; mini is limited to scrolling only on the body element; XHR and set timeout and set interval limits; fewer server roundtrips - reflows and repaints cause calls back to server; lazy loading is tricky in mini, the lazy loaded scripts don't always get to run. hwa panning zooming and scrolling in android only currently. operamini object. "Opera Mini" phrase for user agent sniffing. review headers. media queries are supported in mini. testing in mini using online simulator. SPDY in opera turbo and mini in the future. | |
| Tony Gentilcore (Google) | |
| Chrome | |
| - Smooth graphics and memory footprint improvements ... remote debugging via USB | |
| - jankiness interrupting paint(); webkit is single threaded | |
| - add a second thread | |
| - DOM tree (nodes) -> RenderObject tree -> RenderLayer tree | |
| - Threaded compositor keeps its own copy of the layer tree, transforms performed on the GPU, rock solid position:fixed during scroll | |
| - Is JavaScript not garbage collected naturally? All unreferenced memory is collected, references will pile up over time. Use the memory timeline sawtooth graph; watch for the normal clearing of the memory. Use heap profiler to snapshot and sort by largest shallow size. | |
| Taras Glek (Mozilla Corporation) | |
| taras@mozilla.com | |
| - https://blog.mozilla.com/tglek | |
| - Don't use DOM localStorage | |
| - Scheduling sucks: settimeout, xmlhttprequest loops, every other API with async callbacks | |
| - Don't use settimeouts for animations; use CSS animations | |
| - requestAnimationFrame API for JS animations if you must use JS | |
| - Avoid touching the DOM regularly | |
| - Don't update invisible elements until they come into view | |
| - page-visibility API (HTML5): hook timeouts to this API for hide/visible state of tab | |
| - DOM localStorage sucks, 5mb limit. IO is not faster than network. | |
| JavaScript Timers, Power Consumption, and Performance | |
| Nicholas Zakas (WellFurnished) | |
| Scaling Pinterest | |
| Yashwanth Nelapati (Pinterest) | |
| Marty Weiner (Pinterest) | |
| 5 Essential Tools for UI Performance | |
| Nicole Sullivan | |
| @stubbornella | |
| - WPT disable different types of media by extension | |
| - DOM node inserts are slow | |
| - CSS selector profiling | |
| - The rendering engine. Webkit component, WebCore. | |
| - Refer to Gentilcore talk, HTML construct to DOM tree before render tree construction. | |
| - Style sharing, new in Webkit been in Gecko for a while. | |
| - Rule hashes, right most selector is evaled first. | |
| - Ancestor filter, liklihood that a selector will match or not. False positives are possible but false negatives are not. Larger sheets will have more false positives. | |
| - Fast path, improvements to descendents and child selectors. | |
| - Sibling selection can be really expensive, recent improvements to the engine. Be careful of ~ and +. DOM appends slowed down by this. Probably best to avoid completely; scope to classname exactly where you need it. | |
| - IE10, reducing the number of rules evaluated per page. Routinely evaluating sites on the web. Avoid descendent and sibling selectors. | |
| - Chrome, selector audit tool. Interestingly user agent styles appear to be among the slowest typically showing in the audit tool. A lot of variation between runs. | |
| - DOM depth checkers, TILT 3d webgl Firefox to view layers of the page. TILT does export: how can that webgl be mapped/reused? | |
| - Unused selectors, dust-me-selectors can utilize sitemap.xml; will show :hover and similar styles as unused because no user action has occurred. | |
| - Chrome selector audit, single page only ... also an option. Math is hard. | |
| - Understanding painting (visualizing), -show-paint-rects. Command line flag for Chrome (also in Chrome 20+ dev toos settings?). Visualize what the paint looks like. | |
| JavaScript Performance MythBusters™ (via JSPerf) | |
| Lindsey Simon (Twist) @elsigh | |
| Nicholas Zakas (WellFurnished) @slicknet | |
| Chris Joel (Cloudflare) @robodynamo | |
| Kyle Simpson (Getify Solutions) @getify | |
| - browserscope.org, jsperf.com | |
| - String concatenation versus array and joining with a space: say no to string concatenation, performs terribly. | |
| - Literal compilers for JIT fully optimized in browsers. | |
| - localStorage versus cookies; contentious issue and inconclusive. writes slow to localStorge on first load, reads and writes after seem acceptable. | |
| - "eval is evil"; busted, eval jQuery rather than network is faster | |
| - hash.pushState and #! history problems in URLs etc.: busted, but prefer feature detection | |
| - queryselectorall versus getelementbytagname; latter is faster because former does massive eval of nodelist | |
| - converting nodelist to an array and then itterating over that array is expensive; the actual conversion IS expensive, however if you need to reitterate over that repeatedly it can be efficient | |
| - script concatenation or using <script defer> is performant more for loading JS than deferred methodology in scripts | |
| - functionsource.com | |
| - Akamai IO | |
| aloisreitbauer - ux management compuware | |
| tooling and monitoring moving into browser apis, away from js tools/widgets on the page |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment