Tweet
Tweet

Slide 1

Slide 1 text

Web Performance 101: What is web performance and why should I care? @tameverts #ChromeDevSummit ¯\_(ツ)_/¯

Slide 2

Slide 2 text

No content

Slide 3

Slide 3 text

@tameverts

Slide 4

Slide 4 text

No content

Slide 5

Slide 5 text

No content

Slide 6

Slide 6 text

speedcurve.com/benchmarks/

Slide 7

Slide 7 text

What is “web performance”? Why should I care about it? How do I measure it? How can I get other people in my company to care about it?

Slide 8

Slide 8 text

Slow websites suck.

Slide 9

Slide 9 text

the average web user believes they waste two days a year waiting for pages to load

Slide 10

Slide 10 text

“web stress” When apps or sites are slow, we have to concentrate up to 50% harder to stay on task. @tameverts

Slide 11

Slide 11 text

11 When do users start to interact with a page?

Slide 12

Slide 12 text

12 Source: Jakob Nielsen

Slide 13

Slide 13 text

13 Source: Jakob Nielsen

Slide 14

Slide 14 text

14

Slide 15

Slide 15 text

15 “We want you to be able to flick from one page to another as quickly as you can flick a page on a book. So, we’re really aiming very, very high here… at something like 100 milliseconds.” Urs Hölzle SVP Engineering, Google

Slide 16

Slide 16 text

fast slow @tameverts

Slide 17

Slide 17 text

Slow pages affect people’s perception of three things completely unrelated to time: 1. Content “boring” 2. Visual design “tacky” “confusing” 3. Ease of navigation “frustrating” “hard-to-navigate”

Slide 18

Slide 18 text

User experience and web performance are predictable indicators of business outcomes.

Slide 19

Slide 19 text

Rebuilding Pinterest pages for performance resulted in 40% decrease in wait time, 15% increase in SEO traffic, and 15% increase in signup conversion rate. Ancestry.com saw a 7% increase in conversions after improving render time by 68%, page weight by 46% and load time by 64%. Staples reduced median page load time by 1 second and 98th percentile load time by 6 seconds, resulting in a 10% conversion rate increase. @tameverts

Slide 20

Slide 20 text

No content

Slide 21

Slide 21 text

@tameverts

Slide 22

Slide 22 text

@tameverts

Slide 23

Slide 23 text

optimal load times for peak conversions @tameverts

Slide 24

Slide 24 text

even 100ms delays matter @tameverts

Slide 25

Slide 25 text

real user data + machine learning

Slide 26

Slide 26 text

collected 1M+ beacons of real user data across 93 attributes, including… • top-level – domain, timestamp, SSL • session – start time, length (in pages), total load time • user agent – browser, OS, mobile ISP • geo – country, city, organization, ISP, network speed • bandwidth • timers – base, custom, user-defined • custom metrics • HTTP headers

Slide 27

Slide 27 text

1sessions that convert have fewer images

Slide 28

Slide 28 text

@tameverts

Slide 29

Slide 29 text

2pages with more scripts are less likely to convert

Slide 30

Slide 30 text

160+ scripts… uh-oh @tameverts

Slide 31

Slide 31 text

speakerdeck.com/csswizardry/its-my-third-party-and-ill-cry-if-i-want-to

Slide 32

Slide 32 text

How fast is fast enough?

Slide 33

Slide 33 text

“The real thing we are after is to create a user experience that people love and they feel is fast… and so we might be front-end engineers, we might be dev, we might be ops, but what we really are is perception brokers.” Steve Souders

Slide 34

Slide 34 text

But measuring perception is hard. It’s even harder to scale.

Slide 35

Slide 35 text

No content

Slide 36

Slide 36 text

What tools do we use? Synthetic (lab) Consistent baseline Mimics network & browser conditions No installation Compare any sites Detailed analysis Waterfall charts Filmstrips and videos Limited URLs Real user monitoring (field) Requires JavaScript installation Large sample size (up to 100%) Real network & browser conditions Geographic spread Correlation with other metrics (bounce rate) No detailed analysis Only measure your own site

Slide 37

Slide 37 text

No content

Slide 38

Slide 38 text

No content

Slide 39

Slide 39 text

No content

Slide 40

Slide 40 text

No content

Slide 41

Slide 41 text

@tameverts

Slide 42

Slide 42 text

@tameverts

Slide 43

Slide 43 text

@tameverts

Slide 44

Slide 44 text

Free tools to explore Synthetic webpagetest.org developers.google.com/speed/ pagespeed/insights/ Real user monitoring github.com/bluesmoon/boomerang developers.google.com/web/tools/ chrome-user-experience-report

Slide 45

Slide 45 text

webpagetest.org

Slide 46

Slide 46 text

developers.google.com/speed/pagespeed/insights/

Slide 47

Slide 47 text

A brief history of performance metrics

Slide 48

Slide 48 text

No content

Slide 49

Slide 49 text

TTFB DNS TCP TTI FCP FMP FID OMG WTF

Slide 50

Slide 50 text

❑ Correlates to what users actually see in the browser ❑ Is easy to use and accessible right out of the box ❑ Recognizes that not all pixels and page elements are equal ❑ Allows us to customize what we measure on specific pages The best UX metric…

Slide 51

Slide 51 text

No content

Slide 52

Slide 52 text

Is it happening? Is it useful? Is it usable? Is it delightful? developers.google.com/web/fundamentals/ performance/user-centric-performance-metrics

Slide 53

Slide 53 text

Load Time The time from the start of the initial navigation until the beginning of the window load event

Slide 54

Slide 54 text

No content

Slide 55

Slide 55 text

No content

Slide 56

Slide 56 text

Start Render The time from the start of the initial navigation until the first non-white content is painted

Slide 57

Slide 57 text

No content

Slide 58

Slide 58 text

start render repeat visits

Slide 59

Slide 59 text

wow!

Slide 60

Slide 60 text

First Paint First Contentful Paint First Meaningful Paint

Slide 61

Slide 61 text

First Paint (FP) Pixels first start to render

Slide 62

Slide 62 text

First Contentful Paint (FCP) Text and graphics start to render… BUT often catches non-meaningful paints (e.g. headers, nav bars)

Slide 63

Slide 63 text

First Meaningful Paint (FMP) The paint after which the biggest ATF layout change has happened and web fonts have loaded

Slide 64

Slide 64 text

speedcurve.com/blog/an-analysis-of-chromiums-paint-timing-metrics/

Slide 65

Slide 65 text

Analysis of 40 top Alexa-ranked sites 95% of FP events occur before Start Render 85% of FCP events occur before Start Render 50% of FMP events occur before Start Render speedcurve.com/blog/an-analysis-of-chromiums-paint-timing-metrics/

Slide 66

Slide 66 text

Speed Index Average time at which visible parts of the page are in the viewport

Slide 67

Slide 67 text

No content

Slide 68

Slide 68 text

❑ Correlates to what users actually see in the browser ❑ Is easy to use and accessible right out of the box ❑ Recognizes that not all pixels and page elements are equal ❑ Allows us to customize what we measure on specific pages The best UX metric…

Slide 69

Slide 69 text

Custom metrics Measure performance with high-precision timestamps Available in both synthetic and RUM (yay!) https://www.w3.org/TR/user-timing/ https://speedcurve.com/blog/user-timing-and-custom-metrics/

Slide 70

Slide 70 text

how long does it take to display the main product image on my site?

Slide 71

Slide 71 text

Time to First Tweet The time from clicking the link to viewing the first tweet on each page’s timeline Pinner Wait Time (PWT) The time from initiating an action (e.g., tapping a pin) until the action is complete (pin close-up view is loaded) Time to Interact (TTI) @tameverts

Slide 72

Slide 72 text

No content

Slide 73

Slide 73 text

Lighthouse Scores based on audits run on synthetic tests. Checks your page against “rules” for Performance, PWA, Best Practices, and SEO. For each category, you get a score out of 100 and recommendations for what to fix. developers.google.com/web/tools/lighthouse

Slide 74

Slide 74 text

No content

Slide 75

Slide 75 text

No content

Slide 76

Slide 76 text

matuzo.at/blog/building-the-most-inaccessible-site-possible- with-a-perfect-lighthouse-score/

Slide 77

Slide 77 text

No content

Slide 78

Slide 78 text

Core Web Vitals

Slide 79

Slide 79 text

No content

Slide 80

Slide 80 text

developers.google.com/search/blog/2020/11/timing-for-page-experience

Slide 81

Slide 81 text

No content

Slide 82

Slide 82 text

“Core Web Vitals are the subset of Web Vitals that apply to all web pages, should be measured by all site owners, and will be surfaced across all Google tools. “Each of the Core Web Vitals represents a distinct facet of the user experience, is measurable in the field, and reflects the real-world experience of a critical user-centric outcome. “The metrics that make up Core Web Vitals will evolve over time. “The current set for 2020 focuses on three aspects of the user experience — loading, interactivity, and visual stability — and includes the following metrics… web.dev/vitals/

Slide 83

Slide 83 text

Largest Contentful Paint First Input Delay Cumulative Layout Shift loading interactivity visual stability

Slide 84

Slide 84 text

75th percentile of page loads across mobile and desktop

Slide 85

Slide 85 text

Amount of time it takes for the largest visual element to render. Available in Chrome and Chromium-based browsers. Measurable via synthetic and RUM.

Slide 86

Slide 86 text

No content

Slide 87

Slide 87 text

Amount of time it takes for page to respond to user input (e.g. click, tap, key). Only measurable via RUM.

Slide 88

Slide 88 text

FID can seem fast because user interactions take place later in the page’s rendering cycle... after CPU-hogging long tasks have completed. speedcurve.com/blog/first-input-delay-google-core-web-vitals/

Slide 89

Slide 89 text

No correlation when looking at all sessions speedcurve.com/blog/first-input-delay-google-core-web-vitals/

Slide 90

Slide 90 text

Stronger correlation at 75th percentile speedcurve.com/blog/first-input-delay-google-core-web-vitals/

Slide 91

Slide 91 text

Long Tasks have a high correlation across the board speedcurve.com/blog/first-input-delay-google-core-web-vitals/

Slide 92

Slide 92 text

Long Tasks Measures JavaScript functions that take 50ms or longer. Long or excessive JS tasks can delay rendering, as well as cause page “jank”. Measurable via synthetic and RUM.

Slide 93

Slide 93 text

Score that reflects how much page elements shift during rendering. Available in Chrome and Chromium-based browsers. Measurable via synthetic and RUM.

Slide 94

Slide 94 text

No content

Slide 95

Slide 95 text

Size of the shifting element matters speedcurve.com/blog/visualising-cls-layout-shifts/

Slide 96

Slide 96 text

Image carousels can generate false positives speedcurve.com/blog/visualising-cls-layout-shifts/

Slide 97

Slide 97 text

Web fonts & opacity changes can cause issues speedcurve.com/blog/visualising-cls-layout-shifts/

Slide 98

Slide 98 text

Bounce rate gets worse as CLS degrades Bounce rate improves as CLS degrades Bounce rate stays the same as CLS degrades @tameverts

Slide 99

Slide 99 text

No content

Slide 100

Slide 100 text

Look at your own data.

Slide 101

Slide 101 text

How do these metrics correlate with my business goals? How fast should they be? How do we stay on track?

Slide 102

Slide 102 text

No content

Slide 103

Slide 103 text

cnet.com/news/appliance-science-the-well-done-physics-chemistry-of-the-toaster/

Slide 104

Slide 104 text

No content

Slide 105

Slide 105 text

How to create a culture of performance

Slide 106

Slide 106 text

“The largest hurdle to creating and maintaining stellar site performance is the culture of your organization. Lara Hogan designingforperformance.com

Slide 107

Slide 107 text

“No matter the size or type of team, it can be a challenge to educate, incentivize, and empower those around you. “Performance more often comes down to a cultural challenge, rather than simply a technical one.” Lara Hogan designingforperformance.com

Slide 108

Slide 108 text

Educate Incentivize Empower

Slide 109

Slide 109 text

No content

Slide 110

Slide 110 text

No content

Slide 111

Slide 111 text

2009 Improved average load time from 6s à 1.2s 7-12% increase in conversion rate + 25% increase in PVs Average load time degraded to 5s User feedback: “I will not come back to this site again.” Re-focused on performance 0.4% increase in conversion rate 2010 2011 @tameverts

Slide 112

Slide 112 text

1. No front-end measurement 2. Constant feature development 3. Badly implemented third-parties 4. Waiting too long to tackle performance problems 5. Relying on performance sprints

Slide 113

Slide 113 text

1. You need a plan

Slide 114

Slide 114 text

Making it up as you go is not always a good idea. (Actual photo taken yesterday of my family’s gingerbread village.)

Slide 115

Slide 115 text

Tools ≠ Enough

Slide 116

Slide 116 text

2. Have a champion higher up

Slide 117

Slide 117 text

No content

Slide 118

Slide 118 text

3. Then build a cross-disciplinary team

Slide 119

Slide 119 text

No content

Slide 120

Slide 120 text

Everyone who touches a page should care about the performance of that page.

Slide 121

Slide 121 text

Embrace performance from the ground up. Embed engineers into other teams. Enlist performance ambassadors. Teach people how to use (or at least understand) the monitoring tools you use.

Slide 122

Slide 122 text

4. Set shared goals

Slide 123

Slide 123 text

It’s perilously easy to accidentally become a gatekeeper.

Slide 124

Slide 124 text

We first went to the engineering leaders, and then we went to our product leader. Our pitch was totally different... Reefath Rajali // PayPal chasingwaterfalls.io/episodes/episode-two-with-reefath-rajali/

Slide 125

Slide 125 text

“When we went to our product leaders, we spoke more about the business numbers and the business benefits. “When we spoke to our engineering leaders, it was more about our consumer delight.” Reefath Rajali // PayPal chasingwaterfalls.io/episodes/episode-two-with-reefath-rajali/

Slide 126

Slide 126 text

Find out what people care about

Slide 127

Slide 127 text

❑ bounce rate ❑ cart size ❑ conversions ❑ revenue ❑ time on site ❑ page views ❑ SEO ❑ user happiness ❑ user retention ❑ competitors

Slide 128

Slide 128 text

If they care about business metrics…

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

If they care about user engagement…

Slide 134

Slide 134 text

No content

Slide 135

Slide 135 text

No content

Slide 136

Slide 136 text

If they care about SEO…

Slide 137

Slide 137 text

No content

Slide 138

Slide 138 text

If they care about third parties…

Slide 139

Slide 139 text

No content

Slide 140

Slide 140 text

No content

Slide 141

Slide 141 text

Who they are What they care about What to show them Executives Competition Business impact Benchmarks (filmstrips and videos) Correlation charts (perf + KPIs) Marketing Third parties Traffic + engagement SEO Content Third-party performance Correlation charts (perf + bounce rate) Lighthouse SEO audits Image size Devs / engineers Well, lots of stuff, probably Consult with perf team

Slide 142

Slide 142 text

5. Make everyone accountable

Slide 143

Slide 143 text

Performance budgets FTW!

Slide 144

Slide 144 text

Thresholds YOU create for metrics that are meaningful for YOUR site addyosmani.com/blog/performance-budgets/ Milestone timings (e.g. start render) Quantity-based (e.g. image weight) Rules-based (e.g. Lighthouse scores)

Slide 145

Slide 145 text

No content

Slide 146

Slide 146 text

A good performance budget should show you… What your budget is When you go out of bounds How long you’re out of bounds When you’re back within budget

Slide 147

Slide 147 text

zillow.com/tech/bigger-faster-more-engaging-budget/

Slide 148

Slide 148 text

zillow.com/tech/bigger-faster-more-engaging-budget/

Slide 149

Slide 149 text

Super important! Look at your own data Monitor your competitors No sandbagging allowed Take a step-by-step approach if necessary Use synthetic and RUM (numbers may will vary)

Slide 150

Slide 150 text

Pro tips Create budgets for your popular and regularly changing pages Review violations early and always Compare before and after releases Update budgets accordingly zillow.com/engineering/bigger-faster-more-engaging-budget/

Slide 151

Slide 151 text

Who What Metric Ops Back-end issues TTFB Marketing Most important content Third parties SEO Largest Contentful Paint JS Long Tasks Lighthouse SEO score & audits Devs / engineers How well pages are built Performance issues Start Render, Web Vitals Lighthouse Performance audits

Slide 152

Slide 152 text

Give people ownership

Slide 153

Slide 153 text

“One of the original directives of the performance team was we weren’t going to set ourselves up to be performance cops.” Dan Chilton, Vox Media responsivewebdesign.com/podcast/vox-media-performance/

Slide 154

Slide 154 text

“We weren’t going to go around slapping people on the wrist, saying, ‘You built an article that broke the page size budget! You have to take that down or change that immediately!’ “Our goal setting out was to set up best practices, make recommendations, and be a resource within the company that people can turn to when they have to make performance-related decisions.” Dan Chilton, Vox Media responsivewebdesign.com/podcast/vox-media-performance/

Slide 155

Slide 155 text

6. Communicate

Slide 156

Slide 156 text

“We, as engineers, should learn how to show the impact on anything we do.” Malek Hakim // Priceline chasingwaterfalls.io/episodes/episode-one-with-malek-hakim/

Slide 157

Slide 157 text

No content

Slide 158

Slide 158 text

No content

Slide 159

Slide 159 text

No content

Slide 160

Slide 160 text

No content

Slide 161

Slide 161 text

No content

Slide 162

Slide 162 text

No content

Slide 163

Slide 163 text

How often is often enough? Wall monitors and dashboards 24/7 Alerts (to people who can make fixes) in realtime Reports no more than 1X week Meetups, hackathons, etc. monthly (if possible)

Slide 164

Slide 164 text

7. Don’t forget to celebrate!

Slide 165

Slide 165 text

No content

Slide 166

Slide 166 text

No content

Slide 167

Slide 167 text

No content

Slide 168

Slide 168 text

!!!

Slide 169

Slide 169 text

medium.com/the-telegraph-engineering

Slide 170

Slide 170 text

Score some easy wins

Slide 171

Slide 171 text

“The dull boring stuff” ~Andy Davies Scripts (especially third parties) Images Extraneous code Defer assets where possible

Slide 172

Slide 172 text

Shaved 15KB off logo Ran A/B test Increased bookings chasingwaterfalls.io/episodes/episode-one-with-malek-hakim/

Slide 173

Slide 173 text

In summary…

Slide 174

Slide 174 text

There’s no magic. Show up with a plan. Do the work. (Be patient.)

Slide 175

Slide 175 text

Thanks! @tameverts speedcurve.com/blog