Full Stack Web Performance

Get Started. It's Free
or sign up with your email address
Rocket clouds
Full Stack Web Performance by Mind Map: Full Stack Web Performance


1.1. frame rate / painting

1.1.1. 1000ms / 60 Hz = ~16ms pixels refresh on screen about 16ms

1.1.2. frames available from chrome dev tools record circle button in timeline? view maybe, or profiles

1.1.3. if a button is clicked in the middle of a frame, if you aren't done processing before frame painting is planned, it skips the frame this is called a dropped frame you do "request animation frame" to get the full 16ms timeframe in order to prevent dropped frame

1.1.4. things that are "on scroll" should do this

1.1.5. do all your reads before all your writes so it's not mixed and you don't waste frame time once the first write occurs

1.1.6. chrome dev tools - show painted rectangles

1.1.7. layer promotion transform: translateZ(0) hack <video> <canvas css opacity animations transforms new spec coming will-change: position will-change spec stop hacking, start being intentional

1.1.8. enable continuous page repainting shows how long to fully paint the screen while nothing special is running (but still needs to repaint) example/demo baseball cards were 14ms to just paint. due to rounded edges with box shadow

1.1.9. CSS Triggers styles -> which parts of painting is effected rounded edges and drop shadows are very computational intensive add shadows to images, not on the fly

2. Speaker

2.1. Nik Molnar

2.2. @Nikmd23

2.3. NYC

3. Why #perfmatters

3.1. people leave, even for half a second

3.2. User Needs

3.2.1. Functional -> Reliable -> Usable ->

4. Attack Plan

4.1. 1. Measurable Improvements

4.2. 2. Platform Stability

4.3. 3. Environment Neutrality

4.3.1. want environments to be equal

4.3.2. test dev prod, how they cache, cleanup cache, memory management make them equal

4.4. 4. Scenario Focused

4.4.1. Application's aren't slow

4.4.2. Scenarios are slow

4.5. 5. Preset Goals

4.5.1. maybe not 2x faster

4.5.2. we will spend two sprints, or x points on performance

4.6. 6. Descending Granularity

5. Network

5.1. chrome dev tools

5.1.1. Size / Content

5.1.2. Copy all as HAR "site is slow" in China send me har file online har viewer http://www.softwareishard.com/har/viewer/

5.1.3. Chrome audit tools gzip images

5.2. compression

5.2.1. server side - turn on gzip compression

5.3. image compression

5.3.1. tiny png . com

5.4. image sprite

5.4.1. simple in visual studio

5.5. procastinate

5.5.1. script async tag/attribute

5.5.2. img lazyload attribute ie11 only puts lower priority on an image to load it latter

5.6. anticipate

5.6.1. <link rel="dns-prefetch" load dns

5.6.2. <link rel="prefetch" downloads asset make sure it has caching headers, otherwise it WILL request it TWICE

5.6.3. <link rel="prerender" opens hidden tab in browser, downloads page, js, and css renders it, and swaps tabs

6. Server

6.1. Stay local

6.1.1. stay in process if possible DB call cache liberally web service call

6.2. Iterate Less

6.2.1. lowering hit count is usually easier

6.3. Cache liberally

6.3.1. don't do work if you don't have to

6.4. Stream

6.4.1. loading lots of data at once is slow

6.5. Miscellaneous

6.5.1. Use string builder

6.5.2. exceptions should be exceptional

6.5.3. build in release mode

6.5.4. and many more

7. Compute

7.1. chrome profiler

7.1.1. stack trace

7.1.2. flame view width of frame is how long it took to execute on a call stack

7.2. scope management

7.2.1. favor local vars

7.2.2. avoid with() statement adds another scoping layer which means it's another scope table scan for anything outside of it

7.2.3. careful w/ closures same as with()

7.3. looping

7.3.1. avoid for...in loops

8. Resources

8.1. Jank Free . Org

8.2. Books

8.2.1. High Performance Web Sites

8.2.2. Even Faster Web Sites

8.3. bit.ly/full-stack-web-perf