Modern Performance Best Practices 2016

Slide 1

Slide 1 text

Modern Performance Best Prac0ces Dus$n Whi*le

Slide 2

Slide 2 text

Dus0n Whi6le dus0nwhi6le.com @dus0nwhi6le San Francisco, California, USA AppDynamics, Kwarter, SensioLabs, Yahoo!, …

Slide 3

Slide 3 text

Modern Performance Best Prac0ces Join this session for a prac$cal introduc$on to modern performance best prac$ces for web apps. We will dive into the latest tools and best prac$ces for launching an ideal end-user experience. Find out how you can leverage Chrome Developer Tools, Google PageSpeed, and WebPageTest to get started improving your applica$ons. author twitter handle

Slide 4

Slide 4 text

Modern Performance Best Prac0ces § Why web performance ma*ers § Common performance best prac$ces – Dive into PageSpeed Rules + look at SiteSpeed.io § A refactoring example – We will have an interac$ve refactoring session of an exis$ng app to reach an ideal pagespeed score § Discuss common tools that automate these techniques (ngx_pagespeed, yo*aa, cloudﬂare, etc) § Dive into WebPageTest to show how to test web performance from any browser § Recap best prac$ces and follow up with resources

Slide 5

Slide 5 text

This talk is heavily inspired from: Google PageSpeed Rules Google Web Fundamentals Ryan Tomayko’s “Things Caches Do” Addy Osmani’s “Automa$ng Workﬂow” Ilya Grigorik “High Performance Browser Networking”

Slide 6

Slide 6 text

Please be interac$ve! Ask ques$ons. Engage!

Slide 7

Slide 7 text

No content

Slide 8

Slide 8 text

No content

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Why performance ma*ers

Slide 11

Slide 11 text

Performance directly impacts the bo*om line

Slide 12

Slide 12 text

No content

Slide 13

Slide 13 text

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 -ASer 3 seconds, 40% will abandon your site. -10 seconds is about the limit for keeping the user's a*en$on §Modern applica0ons spend more 0me in the browser than on the server-side

Slide 14

Slide 14 text

Performance Ma*ers • Treat performance as a feature • Implement performance best prac$ces on server-side and client-side • Use the 14kb rule and op$mize cri$cal path for instant loading • Implement a responsive design + responsive image strategy • Implemen$ng a touch-ﬁrst strategy • Using task runners to build and deploy code for produc$on

Slide 15

Slide 15 text

Scaling server-side applica$ons • Caching - Cache as much on the client-side and server side as possible (javascript, css, images, fonts, content). • Leverage a CDN + browser caching • Use a reverse proxy cache on the server side • Queuing - Do not delay the user experience for tasks that can be executed in the background • Async - Op$mize work to execute concurrently / asynchronously

Slide 16

Slide 16 text

Leverage HTTP Caching • For sta$c components: implement "never expire" policy by sejng far future expires header • For dynamic components: use an appropriate Cache-Control header to help the browser with condi$onal requests

Slide 17

Slide 17 text

No content

Slide 18

Slide 18 text

Expires or Invalida0on

Slide 19

Slide 19 text

Expira0on

Slide 20

Slide 20 text

No content

Slide 21

Slide 21 text

No content

Slide 22

Slide 22 text

Valida0on

Slide 23

Slide 23 text

No content

Slide 24

Slide 24 text

No content

Slide 25

Slide 25 text

Expira0on and Invalida0on

Slide 26

Slide 26 text

No content

Slide 27

Slide 27 text

No content

Slide 28

Slide 28 text

No content

Slide 29

Slide 29 text

No content

Slide 30

Slide 30 text

Caching Best Practices § Use consistent URLs: if you serve the same content on different URLs, then that content will be fetched and stored multiple times. Tip: note that URLs are case sensitive! § Ensure the server provides a validation token (ETag): validation tokens eliminate the need to transfer the same bytes when a resource has not changed on the server. § Identify which resources can be cached by intermediaries: those with responses that are identical for all users are great candidates to be cached by a CDN and other intermediaries. § Determine the optimal cache lifetime for each resource: different resources may have different freshness requirements. Audit and determine the appropriate max-age for each one. § Determine the best cache hierarchy for your site: the combination of resource URLs with content fingerprints, and short or no-cache lifetimes for HTML documents allows you to control how quickly updates are picked up by the client. § Minimize churn: some resources are updated more frequently than others. If there is a particular part of resource (e.g. JavaScript function, or set of CSS styles) that are often updated, consider delivering that code as a separate file. Doing so allows the remainder of the content (e.g. library code that does not change very often), to be fetched from cache and minimizes the amount of downloaded content whenever an update is fetched.

Slide 31

Slide 31 text

Queueing • Any process that is slow and not important for the h6p response should be queued • Sending emails/sms/push no0ﬁca0ons + pos0ng to social accounts • Upda0ng proﬁles and discovering friends from social accounts • Analy0cs + Instrumenta0on • …

Slide 32

Slide 32 text

No content

Slide 33

Slide 33 text

No content

Slide 34

Slide 34 text

In modern web applica$ons more latency comes from the client-side than the server-side.

Slide 35

Slide 35 text

Common Performance Best Prac$ces • Reduce # of HTTP Requests • Avoid redirects • Concatena$ng resources stylesheets + javascript • Combining images using CSS image sprites • Leverage HTTP caching to eliminate requests

Slide 36

Slide 36 text

Common Performance Best Prac$ces • Reduce size of HTTP requests • Op$mize stylesheets + javascripts + images + fonts • Leverage gzip compression • Reduce cookie size + use cookie less domains for sta$c assets

Slide 37

Slide 37 text

Common Performance Best Prac$ces • Op$mize content • Move stylesheet to head • Move javascript to body close (and eliminate blocking javascript) • Preload components when idle

Slide 38

Slide 38 text

Common Performance Best Prac$ces • Reduce DNS lookups • Reduce network latency with Content Delivery Networks

Slide 39

Slide 39 text

Google Chrome Developer Tools

Slide 40

Slide 40 text

No content

Slide 41

Slide 41 text

No content

Slide 42

Slide 42 text

No content

Slide 43

Slide 43 text

No content

Slide 44

Slide 44 text

No content

Slide 45

Slide 45 text

No content

Slide 46

Slide 46 text

No content

Slide 47

Slide 47 text

No content

Slide 48

Slide 48 text

No content

Slide 49

Slide 49 text

Google Performance Tips • Avoid landing page redirects • Avoid plugins • Conﬁgure the viewport • Enable compression • Improve server response $me • Inline CSS • Leverage browser caching

Slide 50

Slide 50 text

Google Performance Tips • Minify resources • Op$mize images • Op$mize CSS delivery • Priori$ze visible content • Remove render-blocking JavaScript • Size content to viewport • Size tap targets appropriately • Use asynchronous scripts • Use legible font sizes

Slide 51

Slide 51 text

No content

Slide 52

Slide 52 text

No content

Slide 53

Slide 53 text

No content

Slide 54

Slide 54 text

No content

Slide 55

Slide 55 text

npm install psi

Slide 56

Slide 56 text

psi dus$nwhi*le.com

Slide 57

Slide 57 text

No content

Slide 58

Slide 58 text

No content

Slide 59

Slide 59 text

No content

Slide 60

Slide 60 text

Google on Browser Performance • Eliminate render-blocking JavaScript and CSS • To deliver the fastest $me to first render, you want to minimize and (where possible) eliminate the number of cri$cal resources on the page, minimize the number of downloaded cri$cal bytes, and op$mize the cri$cal path length. • Op$mize JavaScript Use • JavaScript resources are parser blocking by default unless marked as async or added via a special JavaScript snippet. Parser blocking JavaScript forces the browser to wait for the CSSOM and pauses construc$on of the DOM, which in turn can significantly delay the $me to first render. • Prefer async JavaScript resources • Async resources unblock the document parser and allow the browser to avoid blocking on CSSOM prior to execu$ng the script. Olen, if the script can be made async, it also means it is not essen$al for the first render - consider loading async scripts aler the ini$al render. • Avoid synchronous server calls • Use the navigator.sendBeacon() method to limit data sent by XMLH*pRequests in unload handlers. Because many browsers require such requests to be synchronous, they can slow page transi$ons, some$mes no$ceably. The following code shows how to use navigator.sendBeacon() to send data to the server in the pagehide handler instead of in the unload handler. • Defer parsing JavaScript • Any non-essen$al scripts that are not cri$cal to construc$ng the visible content for the ini$al render should be deferred to minimize the amount of work the browser has to perform to render the page.

Slide 61

Slide 61 text

Google on Browser Performance • Avoid long running JavaScript • Long running JavaScript blocks the browser from construc$ng the DOM, CSS OM, and rendering the page. As a result, any ini$aliza$on logic and func$onality that is non-essen$al for the first render should be deferred un$l later. If a long ini$aliza$on sequence needs to be run, consider splijng it into several stages to allow the browser to process other events in between. • Op$mize CSS Use • CSS is required to construct the render tree and JavaScript will olen block on CSS during ini$al construc$on of the page. You should ensure that any non- essen$al CSS is marked as non-cri$cal (e.g. print and other media queries), and that the amount of cri$cal CSS and the $me to deliver it is as small as possible. • Put CSS in the document head • All CSS resources should be specified as early as possible within the HTML document such that the browser can discover the tags and dispatch the request for the CSS as soon as possible. • Avoid CSS imports • CSS import (@import) direc$ve enables one stylesheet to import rules from another stylesheet file. However, these direc$ves should be avoided because they introduce addi$onal roundtrips into the cri$cal path: the imported CSS resources are discovered only aler the CSS stylesheet with the @import rule itself has been received and parsed. • Inline render-blocking CSS • For best performance, you may want to consider inlining the cri$cal CSS directly into the HTML document. This eliminates addi$onal roundtrips in the cri$cal path and if done correctly can be used to deliver a “one roundtrip” cri$cal path length where only the HTML is a blocking resource.

Slide 62

Slide 62 text

Browser Performance Best Prac$ces • Compressing your JavaScript with Closure Compiler • CSS: Using every declara$on just once • Op$mizing JavaScript code • Prefetching resources • Minimizing browser reﬂow

Slide 63

Slide 63 text

No content

Slide 64

Slide 64 text

No content

Slide 65

Slide 65 text

Op$mizing Content Eﬃciency • Elimina$ng unnecessary downloads • Op$mizing encoding and transfer size of text-based assets • Prefetch resources based on user ac$ons • Image op$miza$on • Web font op$miza$on • HTTP caching

Slide 66

Slide 66 text

CSS Performance • Avoid universal rules • Don’t qualify ID rules with tag names or classes • Use the most speciﬁc category possible • Avoid the descendant selector • Ques$on all usages of the child selector • Rely on inheritance • Avoid vendor-speciﬁc features unless necessary • Remove unused css (uncss)

Slide 67

Slide 67 text

Eﬃciency of CSS selectors • id (#myid) • class (.myclass) • tag (div, h1, p) • adjacent sibling (h1 + p) • child (ul > li) • descendent (li a) • universal (*) • a*ribute (a[rel="external"]) • pseudo-class and pseudo element (a:hover, li:ﬁrst)

Slide 68

Slide 68 text

Steve Souders examined the performance impact of CSS selectors and determined that the delta between the best case and the worst case was 50ms. Don’t waste too much $me on it.

Slide 69

Slide 69 text

Image Op$miza$on • Prefer vector formats: vector images are resolu$on and scale independent, which makes them a perfect fit for the mul$- device and high-resolu$on world. • Minify and compress SVG assets: XML markup produced by most drawing applica$ons olen contains unnecessary metadata which can be removed; ensure that your servers are configured to apply GZIP compression for SVG assets. • Pick best raster image format: determine your func$onal requirements and select the one that suits each par$cular asset. • Experiment with op$mal quality sejngs for raster formats: don’t be afraid to dial down the “quality” sejngs, the results are olen very good and byte savings are significant. • Remove unnecessary image metadata: many raster images contain unnecessary metadata about the asset: geo informa$on, camera informa$on, and so on. Use appropriate tools to strip this data. • Serve scaled images: resize images on the server and ensure that the “display” size is as close as possible to the “natural” size of the image. Pay close to a*en$on to large images in par$cular, as they account for largest overhead when resized! • Automate, automate, automate: invest into automated tools and infrastructure that will ensure that all of your image assets are always op$mized.

Slide 70

Slide 70 text

No content

Slide 71

Slide 71 text

No content

Slide 72

Slide 72 text

Web Font Performance • There are four primary levers that determine the performance impact of web fonts on the page: • The total number of fonts and font-weights used on the page. • The total byte size of fonts used on the page. • The transfer latency of the font resource. • The $me when the font downloads are ini$ated.

Slide 73

Slide 73 text

Web Font Op$miza$on • Audit and monitor your font use: do not use too many fonts on your pages, and for each font, minimize the number of used variants. This will assist in delivering a more consistent and a faster experience for your users. • Subset your font resources: many fonts can be subset, or split into mul$ple unicode-ranges to deliver just the glyphs required by a par$cular page - this reduces the filesize and improves download speed of the resource. However, when defining the subsets be careful to op$mize for font re-use - e.g. you don’t want to download a different but overlapping set of characters on each page. A good prac$ce is to subset based on script - e.g. La$n, Cyrillic, and so on. • Deliver op$mized font formats to each browser: each font should be provided in WOFF2, WOFF, EOT, and TTF formats. Make sure to apply GZIP compression to EOT and TTF formats, as they are not compressed by default. • Specify revalida$on and op$mal caching policies: fonts are sta$c resources that are infrequently updated. Make sure that your servers provide a long-lived max-age $mestamp, and a revalida$on token, to allow for efficient font re-use between different pages. • Use Font Loading API to op$mize the Cri$cal Rendering Path: default lazyloading behavior may result in delayed text rendering. Font Loading API allows us to override this behavior for par$cular fonts, and to specify custom rendering and $meout strategies for different content on the page. For older browsers that do not support the API, you can use the webfontloader JavaScript library or use the CSS inlining strategy.

Slide 74

Slide 74 text

No content

Slide 75

Slide 75 text

Caching Op$miza$on • Use consistent URLs: if you serve the same content on different URLs, then that content will be fetched and stored mul$ple $mes. Tip: note that URLs are case sensi$ve! • Ensure the server provides a valida$on token (ETag): valida$on tokens eliminate the need to transfer the same bytes when a resource has not changed on the server. • Iden$fy which resources can be cached by intermediaries: those with responses that are iden$cal for all users are great candidates to be cached by a CDN and other intermediaries. • Determine the op$mal cache life$me for each resource: different resources may have different freshness requirements. Audit and determine the appropriate max-age for each one. • Determine the best cache hierarchy for your site: the combina$on of resource URLs with content fingerprints, and short or no-cache life$mes for HTML documents allows you to control how quickly updates are picked up by the client. • Minimize churn: some resources are updated more frequently than others. If there is a par$cular part of resource (e.g. JavaScript func$on, or set of CSS styles) that are olen updated, consider delivering that code as a separate file. Doing so allows the remainder of the content (e.g. library code that does not change very olen), to be fetched from cache and minimizes the amount of downloaded content whenever an update is fetched.

Slide 76

Slide 76 text

Op$mize Cri$cal Rendering Path • Analyze and characterize your cri$cal path: number of resources, bytes, length. • Minimize number of cri$cal resources: eliminate them, defer their download, mark them as async, etc. • Op$mize the order in which the remaining cri$cal resources are loaded: you want to download all cri$cal assets as early as possible to shorten the cri$cal path length. • Op$mize the number of cri$cal bytes to reduce the download $me (number of roundtrips).

Slide 77

Slide 77 text

No content

Slide 78

Slide 78 text

No content

Slide 79

Slide 79 text

No content

Slide 80

Slide 80 text

No content

Slide 81

Slide 81 text

No content

Slide 82

Slide 82 text

npm install sitespeed.io

Slide 83

Slide 83 text

sitespeed.io -u dus$nwhi*le.com

Slide 84

Slide 84 text

No content

Slide 85

Slide 85 text

No content

Slide 86

Slide 86 text

No content

Slide 87

Slide 87 text

No content

Slide 88

Slide 88 text

No content

Slide 89

Slide 89 text

No content

Slide 90

Slide 90 text

No content

Slide 91

Slide 91 text

No content

Slide 92

Slide 92 text

No content

Slide 93

Slide 93 text

No content

Slide 94

Slide 94 text

No content

Slide 95

Slide 95 text

Automate your frontend workﬂows

Slide 96

Slide 96 text

No content

Slide 97

Slide 97 text

No content

Slide 98

Slide 98 text

No content

Slide 99

Slide 99 text

npm install -g grunt-cli

Slide 100

Slide 100 text

No content

Slide 101

Slide 101 text

No content

Slide 102

Slide 102 text

npm install -g gulp

Slide 103

Slide 103 text

No content

Slide 104

Slide 104 text

Grunt and Gulp make it easy to incorporate best prac0ces and automate the tedious parts of web development.

Slide 105

Slide 105 text

No content

Slide 106

Slide 106 text

No content

Slide 107

Slide 107 text

npm install -g bower

Slide 108

Slide 108 text

No content

Slide 109

Slide 109 text

npm install -g yo

Slide 110

Slide 110 text

No content

Slide 111

Slide 111 text

Use Bower (for dependencies), Grunt/Gulp (for automa$on), and Yeoman (for bootstrapping)

Slide 112

Slide 112 text

npm install -g yo bower gulp

Slide 113

Slide 113 text

No content

Slide 114

Slide 114 text

npm install -g generator-gulp-webapp

Slide 115

Slide 115 text

mkdir webapp

Slide 116

Slide 116 text

yo gulp-webapp

Slide 117

Slide 117 text

No content

Slide 118

Slide 118 text

npm install

Slide 119

Slide 119 text

bower install

Slide 120

Slide 120 text

gulp

Slide 121

Slide 121 text

gulp serve

Slide 122

Slide 122 text

gulp test

Slide 123

Slide 123 text

gulp serve:dist

Slide 124

Slide 124 text

No content

Slide 125

Slide 125 text

A live refactoring for performance

Slide 126

Slide 126 text

No content

Slide 127

Slide 127 text

No content

Slide 128

Slide 128 text

ngrok h*p 3000

Slide 129

Slide 129 text

No content

Slide 130

Slide 130 text

No content

Slide 131

Slide 131 text

No content

Slide 132

Slide 132 text

No content

Slide 133

Slide 133 text

No content

Slide 134

Slide 134 text

No content

Slide 135

Slide 135 text

No content

Slide 136

Slide 136 text

No content

Slide 137

Slide 137 text

No content

Slide 138

Slide 138 text

No content

Slide 139

Slide 139 text

No content

Slide 140

Slide 140 text

No content

Slide 141

Slide 141 text

TodoMVC has been called many things including the 'Speed-da$ng' and 'Rose*a Stone' of MV* frameworks.

Slide 142

Slide 142 text

git clone h*ps://github.com/tastejs/todomvc

Slide 143

Slide 143 text

npm install

Slide 144

Slide 144 text

bower install

Slide 145

Slide 145 text

gulp

Slide 146

Slide 146 text

gulp serve

Slide 147

Slide 147 text

No content

Slide 148

Slide 148 text

Google Web Starter Kit

Slide 149

Slide 149 text

No content

Slide 150

Slide 150 text

No content

Slide 151

Slide 151 text

No content

Slide 152

Slide 152 text

No content

Slide 153

Slide 153 text

git clone h*ps://github.com/google/web-starter-kit.git

Slide 154

Slide 154 text

npm install

Slide 155

Slide 155 text

bower install

Slide 156

Slide 156 text

gulp

Slide 157

Slide 157 text

gulp serve

Slide 158

Slide 158 text

No content

Slide 159

Slide 159 text

No content

Slide 160

Slide 160 text

Automated Performance Improvements

Slide 161

Slide 161 text

No content

Slide 162

Slide 162 text

No content

Slide 163

Slide 163 text

No content

Slide 164

Slide 164 text

No content

Slide 165

Slide 165 text

No content

Slide 166

Slide 166 text

No content

Slide 167

Slide 167 text

Monitor performance on the server-side and client-side

Slide 168

Slide 168 text

No content

Slide 169

Slide 169 text

Monitor your end user latency with Episodes.js or Google Analy$cs SiteSpeed

Slide 170

Slide 170 text

No content

Slide 171

Slide 171 text

No content

Slide 172

Slide 172 text

No content

Slide 173

Slide 173 text

No content

Slide 174

Slide 174 text

Monitor the end user experience with applica$on performance management tools (that use naviga$on + resource $ming apis)

Slide 175

Slide 175 text

No content

Slide 176

Slide 176 text

No content

Slide 177

Slide 177 text

No content

Slide 178

Slide 178 text

No content

Slide 179

Slide 179 text

No content

Slide 180

Slide 180 text

No content

Slide 181

Slide 181 text

Understanding the impact of HTTP2 • Todays best prac0ces are tomorrows an0-pa6erns • 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 (domains), unconcat (css/javascript), and unsprite your assets (images) • You should switch from inlining to server push • Read Ilya Grigorik awesome book on browser performance - h*p://hpbn.co/h*p2

Slide 182

Slide 182 text

Recap / Take aways § Treat performance as a feature § Implement caching and queuing to improve server-side latency § Start with a solid founda0on by leveraging yeoman or google web starter kit § Leverage nginx/apache boilerplate server conﬁgs for sane web server secngs § Follow best prac0ces to op0mize delivery of javascript, css, images, and fonts § Op0mize for cri0cal rendering path § Google Chrome Developer Tools is your friend for proﬁling § Automate build and deployment best prac0ces with Gulp/Grunt § Use PageSpeed Insights, SiteSpeed.io, WebPageTest.org as part of development lifecycle § If you can’t improve the code then leverage mod_pagespeed, Yo6a, or CloudFlare § Monitor the real user experience with applica0on performance management tools

Slide 183

Slide 183 text

Resources

Slide 184

Slide 184 text

https://developers.google.com/web/fundamentals

Slide 185

Slide 185 text

https://developers.google.com/web/tools/starter-kit/

Slide 186

Slide 186 text

http://yeoman.io/blog/performance-optimization.html

Slide 187

Slide 187 text

https://speakerdeck.com/addyosmani/automating-front-end-workﬂow

Slide 188

Slide 188 text

h6p://hpbn.co/h6p2

Slide 189

Slide 189 text

No content

Slide 190

Slide 190 text

No content

Slide 191

Slide 191 text

Recommended Velocity Sessions § Building High Performance Progressive Web Apps - Aditya Punjabi § High Performance Browser Networking - Ilya Grigorik § Scaling Front-End Performance - Patrick Meehan § Experiences of HTTP/2 in the real world - Michael Gooding § Outages, ownership, and cralsmanship: A devops story - Adam Cath

Slide 192

Slide 192 text

Most of this content comes directly from: Google Web Fundamentals Google PageSpeed Rules Ryan Tomayko’s “Things Caches Do” Addy Osmani’s “Automa$ng Workﬂow” Ilya Grigorik “High Performance Browser Networking”