Skip to content

Instantly share code, notes, and snippets.

@derek

derek/gist:5835728

Last active November 22, 2016 21:11
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save derek/5835728 to your computer and use it in GitHub Desktop.
Save derek/5835728 to your computer and use it in GitHub Desktop.
Download ZIP
Velocity 2013 Notes
Raw
gistfile1.md

Velocity Conference 2013

Day 1 Keynotes

What, Where, and When is Risk in System Design

  • Johan Bergstrum (Associate Professor at Lund University, Sweden)
  • Video
  • This is a talk on safety science, risk
  • Is risk a product of unreliable components, or system complexity?
  • Linear systems
    • "If you want to understand why your system is, or is not working, you analytically go down and in to look at the individual components to see how they interact and follow their design rules."
    • The functioning of the whole can be reduced down to the functionality of its constituent components.
    • "Risk is a product of unreliable system components", often times caused by humans
    • More barriers can increase reliability
  • Relational systems
    • Fault lies in perspective
    • More barriers can increase unreliability
  • Risk and safety are both products of performance variability (t.co downtime used as example)
  • Managing Risk
    • Safety is an illusion, so keep the discussion of risk alive. In other words, systems are never safe, they're just less unreliable.
    • Invite minority opinion and doubt
    • Monitor gap work as prescribed and work as preformed
    • Debate the location of the boundaries and distance to them
    • Focus on how people make tradeoffs gauranteeing safety
  • Safety management is not about avoiding, it is about achieving
  • Risk is a game played between values and frames of reference
  • Slides @ jbsafety.se

Building the Next Billion Dollar Business in Web Performance

  • The problems in web performance are big problems.
  • To solve a big problem, you have to think big
    • Missions
      • Akamai - Fix performance
      • Amazon - Run your IT in the cloud
      • Google - Make the web faster
  • Some lessons from Keynote (the company)
    • Began performance monitoring in 1995
    • "The end user experience really matters"
    • If you are solving a big problem, be prepared to hear a lot of "No"s
    • Solving the big problems are about the journey about how you solve them
    • Keynote asked the browsers to change and implement detectable metrics, which they did
    • Today Keynote releases Real User Perspective
    • Build a Billion dollar business. Start. Now.

Making Mobile Fast

  • Alois Reitbauer (Compuware)
  • Video
  • Nothing notable

Meet the Obama Campaign's $250 Million Fundraising Platform

  • Kyle Rush (kylerush.net)
  • Video
  • Context
    • $500 million online in '08
    • Media reported an expected $1 billion
    • Working for POTUS
    • Competition was a guy who was rich (funny pictures of Romney)
  • When the campaign began, they inherited:
    • 5-7 second pageload time
    • No CDN
    • No caching
    • 46 HTTP requests / page
  • Built a 'Donate' API
  • When considering a CMS, they settled on Jekyll, Github, and Akamai to generate and serve static HTML pages.
  • Results
    • Super-fast iteration and site development.
    • 80% Faster time-to-paint. "I think Time to Paint is one of the most important metrics."
    • A/B testing with a 50/50 split resulted in a +14% conversion rate for the 'fast' version. Didn't specify difference between fast and slow versions
    • While the donate site was all static, the payment collection was of course dynamic. Being the only weak-point, they built an identical clone of their payment partner API with an AWS back-end.

Is the Web Getting Faster? (Arvind Jain, Google)

  • Video
  • Speed of networks
    • Peak connection speeds are up about 30% in the last 5 years
    • Google fiber's latency speed is redunkulous (4ms)
    • LTE is faster than most peoples' home connections (LTE average @ 13mbps, peak @ 35mbps)
  • Browser speed
    • In the last year, Chrome improved 24% on the desktop, 57% in mobile
  • Speed of the Web (pages)
    • Avg page size is 1.5MB (HTML 57k, images 900k, JS 200k, CSS 200k)
  • Getting faster?
    • Pages load time
      • Desktop is 5% faster
      • Mobile is 30% faster
  • Takeaways
    • Core infrastructire is getting faster at a repid page
    • But the web isn't faster, it is getting richer
    • Developers seem to have a time budget and will keep adding features to stay at that speed as the underlying system gets faster

Day 1 Lightning Demos

Akamai IO

Appurify

  • Manish Lachwani - @ManishLachwani
  • Video
  • Mobile Application Development is broken today
    • Lack of mobile specific debugging tools
    • Lack of performance optimization tools
    • Majority of optimization is manual - Developers do not use CI
  • "EC2 for mobile"
  • Private, dedicated, and shared device clouds
  • 6 levels of measurement
    • Client side (load times to gesture interaction)
    • Internal app mechanics
    • Server side
    • Device
    • Disk
    • Multi-app switching, response time
  • First runtime debugger for HTML5 apps. Also, have run-time debugging for native apps.
  • Super charge app development with the SDK. Available for free.
  • For beta access, manish@appurify.com

ARO

  • Doug Sillars AT&T @dougsillars
  • Video
  • Application Resource Optimizer
  • Free diagnostic tool
  • Open Source
  • Test any platform (via pcap or trace from native app)
  • Emulate any carrier network
  • Analysis of both native and web
  • Cool TCP analysis for mobile devices. Similar to YSlow.

Day 1 Sessions

Conquering the Uncanny Valley - Making Web Apps as Smooth as Native

  • Andrew Betts, Financial Times Labs, @triblondon
  • Slides
  • Web Applications on Mobile can succomd to the "uncanny valley"
  • If you are trying to emulate native and don't fully succeed, then you can end up worse off
  • Surprised by App Store reviews that congratulate the FT app on building a "native app"
  • For a web app to appear "native"
    • Smooth transitions need to be done in 16ms (or less) to achieve 60fps
    • 100ms is the threshold on UI interactions where things are considered "instant" by the human eye.
    • Must meet user expectations (subjective)
  • Use native DOM APIs for simple selection. It's much faster (up to 12x)
  • Flexbox is sloooooowwwwwwww
  • Disable hover effects on non-hoverable devices and during scrolls
  • Check out "expensive scrolls" demo (TODO: Find, it's on the web. appspot?)
  • Monitor FPS, which can be activated in chrome://flags
  • Use of border-radius on their toolbar ended up being very expensive when combined with other effects
  • Storing Data
    • "HTML5 can store data on device too, it's just... well, complicated"
    • Methods of storage:
      • WebSQL
      • IndexedDB
      • localStorage (and sessionStorage)
      • Cookies
      • HTML5 Application Cache
      • FileAPI
    • Use the appropriate one for the task (http://jsperf.com/indexeddb-vs-localstorage/13)
      • Use appcache sparingly
      • localStorage for speed
      • Database for capacity
    • HTML5 app cache sucks!
      • Always caches parent page
      • Always serves from cache, even when not connected
      • Cannot add or remove anything without repopulating entire cache
      • Treats headers differently
      • Firefox and Chrome do very different things
    • Storage optimization
      • Compress the text you store in local storage
      • Text encoding 'compression'
        • Don't worry, it is really fast
        • JS internallly uses UTF-16 for text encoding
        • Great idea for processing: fast string operation, full support for Unicode BMP
        • Terrible idea for storage of English text or Base-64 encoded images
        • FT uses compress & decompress methods to squeeze english strings into UTF-16. Very fast.
          • Disadvantage - If you inspect the database in devtools, none of it makes any sense
    • Caching
      • Layers
        • DOM
        • Memory (JS vars)
        • Browser Storage (webSQL)
        • Edge Cache (CDN)
        • Cache Servers (squid)
        • Application caching (memcachce)
        • Database
      • Closer the content is to the DOM, the better. But, storage in DOM has a high memory footprint
  • Network
    • Fewer network request you do, the better you'll be. They're painful, so make em count
    • Mobile radios are power managed, so expect variances.
      • For one test, AJAX requests at:
        • 1s intervals took 850ms r/t
        • 20s intervals took 2100ms r/t
        • This is due to the radio turning off when idle
    • Aggressively batch requests, callbacks per action and per group, process queues in the background.
    • HTTP 2.0 (SPDY)
      • Will help make this unneccesary (in theory)
      • W3C Beacon API for analytics
      • Still use cases for delayed requests
  • Hardware acceleration
    • First, turn on accel (translateZ(0))
    • Repositioning elements causes a reflow
    • Acellerated animation = paint only
    • Painting is expensive, so shift it to the GPU when possible
    • Chrome dev tools will show you FPS and painting times
    • The browser kicks on hardware accelleration only when it needs it
  • Open-sourced
  • When you can't make it any faster, make it seem faster. Essentially, fake it to make it.
    • Providing feedback makes it seem faster. Think about psycology
    • Overestimating the time remaining makes it seem to finish quicker
    • Progress feedback that starts sooner finishes sooner
    • Good analogy with the 'close evelator doors' button, it likely doesn't do anything, but people like it because it makes them feel part of the process, partial control
  • edgeconf.com
  • Q&A
    • Templating on server vs client. Facebook studies show that server-side rendered content has better engagement.
  • TODO: Get slides!

Optimizing JavaScript Runtime Performance for Touch

  • Stephen Woods (Flickr)
  • [Missed the first few minutes]
  • 30 FPS = 33.3ms per frame / 60fps = 16.6ms per frame
  • Intelligently cache. For example, cache values, not nodes (if you don't need the original node)
  • Prioritize interaction & visual aspects (the UI thread) of your application over anything the user doesn't see, such as XHR
  • CSS transitions do not block
  • Run slow code in a Worker (except on Android)
  • Takeaways
    • Cache data where possible
    • Update the UI on events, use transforms when possible
    • Multitask when you can, both with threads and yielding
  • Stephenwoods.net / touch-interfaces.com
  • Q&A
    • "Use the dumbest thing that works"
    • GPU and DOM share the same memory space, so by moving things into GPU memory you are limiting the space available for other areas.

The Curious Case of Dustjs & web-performance

  • Outline:
    • JavaScript templates at LinkedIn
    • LinkedIn applications using Dust.js
    • Measuring Web Performance at LInkedin
    • Deep dive: A mile long page
    • Lessons learny and Next steps
  • Dust.js is an attempt to create a normalization layer that turns JSON into HTML
  • The good Parts
    • High performance (w/ modern browsers)
    • pre compiled to JS at build-time
    • CDN cached with 365d expires
    • <4kb compressed
    • Logic-less, but extensible with helpers
    • The same Dust template can be compiled either on the server or the client
    • On the server, many options
      • Rhino
      • V8
      • Node.js
  • The delightful parts
    • JSON = Unification, easy to onboard new developers
    • Dust = Embracing open-source enhances the developer culture
    • JSON + Dust = Rapid iteration

  • 50% of LinkedIn traffic is now serving JSON + Dust

  • Time to Paint, and Time to First Pixel metrics are higher with Dust
  • Use dust intelligently, cause it can backfire
    • parsing & rendering is much slower in IE compared to other browsers
    • More Dust templates means more HTTP requests
    • Solutions
      • Prioritize above the fold
      • Defer rendering, fetch, and images
      • Server-side render for IE
  • Lessons learned
    • Performance is also User Perception and Engagement
    • How fast can they see anything on the page?
    • How early can they engage?
    • Is the user experience consistent
    • Simplify the design
  • Next
    • Invest more in open-source for improving performance
    • Enfore leaner JSON payload size
    • Preftect resources for certain use cases
    • Evolve with new web-standards
    • Move to faster CDNs across Ggeo
    • Invest in new ways to co-relate
  • Q&A

CSS and GPU Cheat Sheet

  • Colt McAnlis - Google (@duhroach)
  • Slides
  • #perfmatters
  • How does a web page get drawn?
    • Software rasterization
    • CSS Paints are not free
      • box-shadow (1px 1px) = .31ms
      • box-shadow (1px 2px 3px black) = .19ms
      • box-shadow (1px 2px 3px 4px) = .84ms
      • box-shadow + border-radius-stroke = 1.09ms = expensive!
  • Layer control
    • Load-time layer promotion
      • These all automatically get put on their own layer
        • Plugin
        • iFrame
        • Video**
        • Canvas**
        • WebGL**
          • ** Default to hardware accelerated
    • Assign-time layer promotion
      • TranslateZ
      • ScaleZ
      • RotateX
      • RotateY
      • RotateZ
      • Translate3D
      • [ and a few more ]
    • Animation start/stop layer promotion demotion
      • When animation begins, these are promoted to their own layer, then demoted at the end
        • transform: translate
        • transform: opacity
    • Stacking context & relative scrolling
      • position:fixed + z-index:0 // use for fixed headers
    • Input & scrollbars
      • overflow:scroll
      • Place overflow:scroll in their own layer by adding z-index:0
    • Tradeoffs and consequences
      • The GPU is not a silver bullet
      • Each layer has its own set of tiles
      • pre-painting
        • Chrome will ignore visible & invisible, and try to pre-paint as much as possible
        • display:none invalidates
        • display:none -> display: block // trigers paint
        • display:block -> translateZ(0) // load-time paint
  • Responsive design
    • resizing high pixel images to fit on a mobile screen can be a really bad idea.
    • Inspect 'image decode' and 'image resize' timers to see how the size of the image will effect rendering times
  • Tooling
    • composite layer to see tiles
    • Continuous Paint mode (enable in chrome dev tools)
  • Webpage design with the GPU in mind
    • GPU + Layers faster rendering
    • Too many layers = seriously bad time
    • Be aware of your CSS tags impact on CPU & GPU perf
    • Use tooling to show off how many layers you have

A Baseline for Web Performance with PhantomJS

  • @wesleyhales & @ryanbridges
  • Page load testing tools
    • Manual
      • Dev Tools
      • Firebug
      • Charles
      • HAR
    • Autmoated
      • WebDRiver
      • HTMLUnit
    • Services
      • harstorage.com
      • harviewer
      • webpagetest.org
      • pcapperf.appspot.com
  • HAR = the waterfall charts
  • F2E Perf Basics
    • Caching (headers, localStorage, appcache)
    • When to gzip (don't gzip stuff that's natively compressed)
    • When to pull from CDN, local, or break apart (single HTTP reqs aren't always a win)
  • Front-end Ops
  • CNN project
    • Recorded metrics before and after each build.
  • Developed github.com/wesleyhales/loadreport to measure metrics, uses Phantom.js
    • loadreport.js - Typical HAR metrics
    • speedreport.js - Similar to HAR report, viewed in a bubble-chart
    • filmstrip.js - Takes screenshots during the rendering time (smart!)
  • Slimer.js = Phantom.js, but with Gecko (Firefox)
  • Showed demo of the performance CI for wesleyhall.com

Day 2 Keynotes

Gamedays on the Obama Campaign

  • Video
  • Dylan Richard - @dylanr
  • No feature is cool enough to make your app not work.
  • Tech fails
  • Make the team resistent to failure. Practice. Practice. Practice.
    • Team set up staging environment to mimic election day, then started breaking stuff.
    • Devops tortured developers for 2 days
    • Learned?
      • Broken things they thought were fixed
      • Learned what failure really looks like
      • Learned new ways that things fail
      • Learned how to fix stuff. Built an instruction manual
  • Build resilient apps
    • plan for failure
    • make your plan clear
    • Of course, have resilient teams
      • learn from failure
      • build your instruction manual, use it

Web Performance Working Group (Arvind Jain, Google, W3C)

  • Video
  • 385 members, and 65 Groups
  • APIs
    • Navigation timing
    • High resolution timer
    • Page visibility (visibilitychange event)
    • requestAnimationFrame
    • What is next?
      • Resource priorities
      • Beacon
      • Disagnostics: Error logging

Eliminating Website Performance Theft (Joseph Loveless, @neustar)

  • Video
  • 2 billion people are online. PErformance is a differentiator and mandate
  • Eh, it's a marketing pitch for Neustar. "Slow performance steals from the bottom line" Ok.

Mobitest (Akamai)

  • Akamai serves 20% of the Web's traffic
  • The Akamai Internet Observatory
  • Mobitest App - Tests your website performance on yor mobile device

Popforms - Kate Matsudara

  • Video
  • Influence without authority
    • 3 things
      • Accountability
        • Being influential is about leading others and holding yourself to a higher standard
      • Everyone is your ally
        • Invest in relationships now for them to pay off in the future
        • "Be the person making the world a better place"
      • Reciprocity
        • Share value
  • Approach people asking yourself "How can I help them", instead of "How can they help me"
  • Influence is success

Ilya Grigorik - Google

  • Video
  • "The power to question is the basis of all human progress"
  • Curiousity is key to a good engineer
  • Each question unlocks more questions
  • HTTP archive data is all available and free.
  • bit.ly/ha-query

Pat Meenan - Google

  • Video
  • webpagetest.org
  • cloudshark.org has a tcp dump viewer

Patrick Lightbody - New Relic

The Application-Aware Infrastructure (Steve Riley, Riverbed)

  • Video
  • If your apps on their cloud, then function cloud(app)
  • What if instead, it was function app(infrastructure). What would that look like?
    • Abstractions everywhere
      • Middleware - check
      • Compute - check
      • Storage - check
      • We're currently missing 'transport'
  • SDN = Transport abstraction

Day 2 Sessions

How to Run a Post-Mortem (With Humans, Not Robots)

  • Dan Milestein, Hut 8 labs, @danmil
  • Slides
  • What went wrong, and how to prevent it in the future
  • Shame is tremendously powerful and will warp a person's thinking. Tread carefully.
  • As a person running a post-mortem, you have a few challenges
    • #1 - Get your team out of the moral mindset
      • Tip #1: Use humor to make people laugh
        • Share your personal failures
      • Tip #2: "Mock hindsight bias to its face"
        • "Let's plan for a future where we're all as stupid as we are today"
        • People don't get more stupid as time goes, so it's a given they'll be smarter. You need to instead make your systems resilient
      • Tip #3: Relish the absurdities of your system
    • Focus on TTR (Time to Recovery)
    • Focus on broadest fix, not just the root cause
  • Corrective actions, remidiations, and fixes
  • Gather data to justify investment in prevention & upgrades
  • "Automation" sometimes implies that humans cause your problems, which can be faulty thinking
    • Perspective of "Automation" vs "tooling"
    • If you have the mindset that Automation is the cure, you'll end up with something that is strong, silent, clumsy, and difficult to direct.
  • Biggest takeaway: You have partial failures all the time that are occuring invisibly. Invest in detection, learn from your systems, collect data.
  • Want to do better Post-Mortems? Do this:
    • Elect a Post-Mortem Boss
    • Look for a Goldilocks incident
    • Expect awkwardness
    • There must be fixes
    • Incrementally improve the process. When to do a PM? Follow ups? How many people in the room? Etc.
  • Slides available on Slideshare
  • Look into destructive testing & fire drills

Emerging JavaScript Tools to Track JavaScript Quality and Performance

  • Ariya Hidayat (Sencha)
  • http://speakerdeck.com/ariya
  • Slides
  • Compsable tools
  • TODO: Look into ajaxjs / plato (generated by jquery source?)
  • You can quantiy maintainability
  • Library-aware verifiction - Analyze your APIs and detect implimentation defects
  • With static analysis, you can detect (and fix) double-quotes
  • http://github.com/olov/defs/ - A tool that supports levical block scope
  • Measure run-time complexity (profiling executions)
  • Profile-guided Optimization - Optimizing to skip branches
  • Branch coverage with Istanbul, shout-out to Dav's "Istanbul will hurt your feelings"
  • Final words
    • Build composable tools
    • Automate any tedious parts of code review
    • Incorporate code quality metrics as dashboards

Benchmarking the New Front End

  • Emily Nakashima @eanakashima, Rachel Meyers @rachelmyers
  • Slides
  • Why monitor performance?
    • Better perf = more user engagement, page views, and revenue
    • The point of improving performance is to improve the experience of the end user
  • Render the important stuff first, then quietly render all auxilliary information
  • Suggested tools:
    • lognormal.com
    • webpagetest.org
  • Very product specific content for this talk. Takeaways are to intelligently track specific components of your page.

Enough with the JavaScript already

  • Nicholas Zakas (Box, @slicknet)
  • Slides
  • Focus of talk is on the over-reliance of JavaScript
  • What functionality exists where?
    • Server
      • Rendering HTML
      • Consturcting URLs
      • Calculating deps
      • Redirects
    • HTML
      • Document structure
      • nativve functionaity
      • accessibility
    • CSS
      • Layout
      • Colors
      • Visibility
      • Animation
    • But now we're cramming some of that functionality into JS, which is bad.
  • Ungzipped JS sizes
    • Facebook - 1.5k
    • Yahoo - 568k
    • Twitter - 993k
    • YouTube - 793k
  • Client-side rendering
    • MVW = Model-View-Whatever
    • We swung the pendulum too far in the client. Facebook & Twitter intially struggled with this, and are now moving everything back to the server.
  • Stop trying to recreate what the server and browser already do well.
  • Progressive enhancement still works. (Client-side Rendering killed the Progressive Enhancement discussion?)
  • On demand loading of JS? For example, when someone's mouse approaches a actionable button, load that JS.
  • JavaScript libraries are an economy of scale solution. Cost per JS component decreases as the number of components increases.
  • Example of over-reliance on JS.
    • Tabs - Library comparison
      • jQuery - 69k
      • YUI - 30k
      • NCZ - 2k
    • Stop duplicating DOM functionality in JavaScript
    • Outline the purpose of JS before you begin coding

Overall takeways

  • Browser metrics in CI are becoming popular, probably due to Navigation Timing APIs, especially measuring Time to Paint
  • Your software will make mistakes, but it's difficult to predict what & where, so make resilient systems that help you find problems faster, and limit the damage.
  • The point of improving performance is to improve the experience of the end user
  • Performance tuning is often times reverse engineering the browsers
  • When you think you are done with performance, you probably aren't.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment