Dus-n Whi8le • dus-nwhi8le.com • @dus-nwhi8le • San Francisco, California, USA • Technologist, Traveler, Pilot, Skier, Diver, Sailor, Golfer
Why does performance ma8er?
MicrosoI found that Bing searches that were 2 seconds slower resulted in a 4.3% drop in revenue per user
When Mozilla shaved 2.2 seconds oﬀ the landing page, Firefox downloads increased 15.4%
Making Barack Obama’s website 60% faster increased dona-on conversions by 14%
Performance directly impacts the bo8om line
How fast is fast enough? § Performance is key to a great user experience - Under 100ms is perceived as reac$ng instantaneously - A 100ms to 300ms delay is percep$ble - 1 second is about the limit for the user's ﬂow of thought to stay uninterrupted - Users expect a site to load in 2 seconds - AIer 3 seconds, 40% will abandon your site. - 10 seconds is about the limit for keeping the user's a*en$on § Modern applica-ons spend more -me in the browser than on the server-side
Application complexity is exploding Agile SOA Login Mobile Cloud Flight Status Search Flight Purchase Web NOSQL Big data
Benchmarking acmedemoapp.com (be patient) Finished 659 requests Server Software: Apache-Coyote/1.1 Server Hostname: acmedemoapp.com Server Port: 80 Document Path: / Document Length: 5217 bytes Concurrency Level: 10 Time taken for tests: 10.015 seconds Complete requests: 659 Failed requests: 0 Keep-Alive requests: 659 Total transferred: 3600776 bytes HTML transferred: 3438003 bytes Requests per second: 65.80 [#/sec] (mean) Time per request: 151.970 [ms] (mean) Time per request: 15.197 [ms] (mean, across all
Connecting to the hive. Attempting to call up 2 bees. Waiting for bees to load their machine guns... . . . . Bee i-3828400c is ready for the attack. Bee i-3928400d is ready for the attack. The swarm has assembled 2 bees.
Read 2 bees from the roster. Bee i-3828400c: running @ 220.127.116.11 Bee i-3928400d: running @ 18.104.22.168
Read 2 bees from the roster. Connecting to the hive. Assembling bees. Each of 2 bees will fire 500 rounds, 25 at a time. Stinging URL so it will be cached for the attack. Organizing the swarm. … Offensive complete. Complete requests: 1000 Requests per second: 306.540000 [#/sec] (mean) Time per request: 163.112000 [ms] (mean) 50% response time: 151.000000 [ms] (mean) 90% response time: 192.000000 [ms] (mean) Mission Assessment: Target crushed bee offensive. The swarm is awaiting new orders.
Read 2 bees from the roster. Connecting to the hive. Assembling bees. Each of 2 bees will fire 50000 rounds, 500 at a time. Stinging URL so it will be cached for the attack. Organizing the swarm. … Offensive complete. Complete requests: 100000 Requests per second: 502.420000 [#/sec] (mean) Time per request: 360.114000 [ms] (mean) 50% response time: 451.000000 [ms] (mean) 90% response time: 402.000000 [ms] (mean) Mission Assessment: Target crushed bee offensive. The swarm is awaiting new orders.
Read 2 bees from the roster. Connecting to the hive. Assembling bees. Each of 2 bees will fire 50000 rounds, 500 at a time. Stinging URL so it will be cached for the attack. Organizing the swarm. Bee 0 is joining the swarm. Bee 1 is joining the swarm. Bee 0 is firing his machine gun. Bang bang! Bee 0 lost sight of the target (connection timed out). Bee 1 lost sight of the target (connection timed out). Offensive complete. Target timed out without fully responding to 2 bees. No bees completed the mission. Apparently your bees are peace-loving hippies. The swarm is awaiting new orders.
Read 2 bees from the roster. Connecting to the hive. Calling off the swarm. Stood down 2 bees.
Automate client-side performance tes-ng with Grunt/Gulp
Use Bower (for dependencies), Grunt/Gulp (for automa-on), and Yeoman (for bootstrapping)
How many people understand exactly how fast their site runs in produc-on?
Track performance in development and produc-on
Instrument everything = code, databases, caches, queues, third party services, and infrastructure.
Chef / Sensu
Statsd + Graphite + Grafana
Track performance of end users
Load tes-ng services from the cloud
Test for failures • NetFlix Simian Army + Chaos Monkey • What happens if you lose a caching layer? • What happens if dependencies slow down?
Performance Ma*ers • Treat performance as a feature • Using the 14kb Rule for instant loading • Markup management • Elimina$ng excess AJAX calls • Working with and around applica$on cache • Developing a responsive design + image strategy • Implemen$ng a good touch-ﬁrst strategy • Code management for good produc$on and development experiences • Using task runners to build and deploy produc$on code
Best Prac$ces • Treat performance as a feature • Capacity plan and load test the server-side • Op-mize and performance test the client-side • Understand your star-ng point • Instrument everything • Monitor performance in development and produc-on • Measure the diﬀerence of every change • Automate performance tes-ng in your build and deployment process • Understand how failures impact performance
The protocols are evolving • The limita$ons of HTTP/1.X forced us to develop various applica$on workarounds (sharding, concatena$on, spri$ng, inlining, etc.) to op$mize performance. However, in the process we’ve also introduced numerous regressions: poor caching, unnecessary downloads, delayed execu$on, and more. • HTTP/2 eliminates the need for these hacks and allows us to both simplify our applica$ons and deliver improved performance. • You should unshard, unconcat, and unsprite your assets • You should switch from inlining to server push • Read Ilya Grigorik awesome book on browser performance - h*p://hpbn.co/ h*p2
Integrate automated performance tes-ng into con-nuous integra-on for server-side and client-side
Understand the performance implica-ons of every deployment and package upgrade
Monitor end user experience from end to end in produc-on