(audience applauding) - Why, thank you.
I don't even know what to say.
Thank you, thank you, sir.
I'm sorry, I just have to take a picture of the crowd and sent my parents 'cause they won't believe me. (audience laughing) They would be like, what do you do over there? I'm like, literally, I talk, for real.
They're like, yeah, whatever.
Thank you, thank you, Tim, thank you, Tammy, and thank you perfnow for having me.
But let's really get going.
For those of you who follow me online, all 10 of you, this may look familiar.
So, good morning DOM.
I like to read the DOM every day, when I wake up. (audience laughing) (coughing) Pardon me.
But seeing that I am in Amsterdam, I have to say, how's it go? Goedemorgen DOM.
Is that right? Sorta right? Okay, cool, I tried.
But no, let's get going.
So, essentially, we are here at a performance conference, I believe we're going to talk about performance. And I actually remember the very first day I had that moment of, sort of, clarity, where I was like, man, this actually really interesting, this performance thing.
And I'll tell you exactly what happened.
I was at this agency firm I worked at and I remember we had just gotten, I think, some of the new iPhones, and it was the first time we had like the, sort of, the plus version. And, you know, we were talking about retina images and I was like retina images, what are those, I don't get it, and I was startin' to read about it and I'm like okay whatever.
I think I get it.
And so I kept digging in some more and you know how it works, like, you know, 1X, 2X, 3X, whatever, and actually kind of threw up a little bit of code and threw it on one of the phones and I just remember looking at it and having this one moment of clarity where I was like, holy smokes, retina images, I think I get it. And I was thinking to myself like man, all that data, wow. And I was really having this, kind of like, just sort of surreal moment where I was like this is gonna be a problem, well, at least a challenge. And that's when really I start to really get into performance.
I start to go to meetups and I start to do things like watching velocity conference online because they used to have a.
The first part of the conference was the keynotes, and you could watch it live, stream it, I had two big screens, I used to stream it on the corner of my screen on the right.
Who remembers velocity conference? Yeah, a few of you.
And you know, remember the the sort of keynotes, you could watch.
So, I used to watch those all the time.
Then I started to go back and watch some of the videos. And that also led me to buying some of their books. So, O'Reilly Media, O'Reilly Books, and I start to dig in because, again, for some of you who may remember, the majority of performance literature, printed anyways, seemingly mostly came from O'Reilly, O'Reilly Media. So, shout out to O'Reilly for, you know, for putting those out 'cause that was really interesting. So, as I kept going through the catalog, and I finally came on to this one book, which was called, High Performance Web Sites. And from what I could tell, it's one of the earliest books to really get out there and I was reading some material about it, and it's the book that came out by Steve Souders. And is the one that was more or less referenced quite often as like, the sort of like, the bit of a ground zero in terms of like web performance conversations. So, as I kind of flipped through it, I read it and I understand, pardon me, I understood that it was gonna be a bit of a user experience conversation.
Because if you ever go back to read the book, and show of hands, if you flip through the book or you read the book at all, which is all good. And for some of you who haven't, you can still kind of go back and some of the conversations around that book are very much legitimate today, even 10 years later. So, a lot of the conversations were about, sort of, like performance, obviously, but certainly, user experience and that's something that he kept bringing up in the conversation, in his book. And as you kind of can, as I kept going through that, that tome, I realized that, man, I guess we are sort of becoming merchants of user experience.
And that's something that kind of sat with me the whole time.
And in fact, beyond that, we're actually becoming dealers of UX.
And as I kept thinking about it, you know, as we became dealers, we also, obviously, have as web professionals, we became people who delivered UX.
So we are in charge of the delivery of the user experience. And that's, again, something that's gonna be a theme throughout this conversation that we're gonna have today.
So, with that being said, I'd like to welcome everyone to my talk, which I'm entitling, which I'm calling, a Decade, essentially, of Disciplined Delivery. It's gonna be a retrospective of these 14 rules that Steve Souders talked about in that first book. I think you understand what's going on here. (audience laughing) That being said, hello, my name is Henri, absolutely, I'm French, which is why it's spelled with a I.
That is my Twitter handle, that's my Instagram, but it is not my real last name.
I get asked this all the time and I repeat the same answer all the time.
It is a non-plume term, sort of, conference speaker name, et cetera, et cetera.
It just had a cool little ring to it, ultimately. I'm from the greatest city on the planet called Toronto. And that is, yeah, shout outs in the building. (audience laughing) And that's in Canada. As you can see three O's, three A's, I think I could probably minify that in all likelihood. (audience laughing) And we are perfnow, so if you do have any commentary about this talk, definitely use this hashtag, hit me, tag me on it, and I'd love to speak to you afterwards. So that being said, let's get going.
We're going to talk about this tome, that again, was a bit of a ground zero for the performance conversation.
Yes, it was written by Steve Souders, someone who I quite often, personally called the pontiff of performance.
I also call him the sovereign of speed, from time to time, you'll see that on Twitter. But the funny part is that, Mr. Souders used to talk about performance being only a backend issue. He was like, yeah, you know, performance it's like we just like some backend deals, you know, databases and whatnot.
And I actually went back and I was looking at this book, again actually, from O'Reilly, and it was about performance, and this book was also actually talking about how performance is about the backend.
And it was actually kind of interesting because some of the checks, some of the lists, that they had you go through were things like, is your modem on? And I'm like, what? Did this really get printed? Is the browser hanging? You know, these are things that you're asked to check at the time.
Are you using a slow browser.
And I thought that was super interesting.
And again, this is about 2002 or so.
So, you know, bizarre as that was, we get back to the idea that, yes, Mr. Souders believed that most of the performance issues were kind of coming from the backend.
And then, one day, he started to do some testing, and he realized that 5% of the time spent waiting, was coming from backend, and he thought, like, that's actually kind of bizarre. And he went back and did some more testing, and again, it came back 95% of wait time was being spent in the front-end.
And again, as he kept going through and doing some more testing and more testing, and he finally came up with this thing he called the golden rule, which was the following, and this is something that I used to this day when I talk about performance.
80 to 90% of the performance is spent in the front end. And this is something that basically set performance on a course to where we are today.
A lot of the work that we do is pretty much dealing with the complexities of the front-end.
Now, Mr. Souders went on to do lots.
Obviously, some wind in his sails, and he came out with this tool called YSlow.
Does anyone remember YSlow? Oh, fantastic.
Okay.
That's what I'm talking about.
You know, YSlow gave scores, you know, YSlow was ahead of its time.
Before Lighthouse.
Before web page test.
Where's. (chuckles) (audience laughing) Hold on, hold on, hold on.
I mean shout outs.
Oh, there he is. (chuckles) But no, this was very significant.
It looks a little something like this for those who hadn't seen it.
But Mr. Souders went on and in doing some more research and, you know, putting down pen to pad, he essentially came out with what some regard as again, the sort of first tome, a bit of a Bible in front-end performance.
High Performance Web sites Essential Knowledge for Front-End Engineers.
14 steps to faster loading websites, or 14 rules. And I'm going to actually call them rules, so apologies, if they're not rules but this is something just, you know, a misnomer, if anything.
But we're gonna go through the 14 rules from this moment in time which is about 2006, 2007. And we're essentially gonna go back and look to see how they would fare today.
And you know, it might be a little comical at times, but just ride with me.
So, rule number one, make fewer HTTP requests. Now, that seems like a bit of a no brainer. I actually want to, sort of, quote a friend of mine, who's a speaker as well, great dude, Phil Hawksworth, who has this one line which I love and it goes something like this.
The most secure server is the one that doesn't exist. I like that.
And I'm going to follow it up with one that I like to use all the time which is, the quickest request is the one that's never made. Now, making, you know, lesser amounts of HTTP requests, there's a bunch of reasons why you might want to do it. You know, in the end, the request is a bit of a complicated process.
There's a lot that goes into a request from a, sort of like, a standpoint with say, marketing, design, you know, they want to see something on the page, you don't for whatever reason.
But the bottom line is a request is relatively expensive. Mr. Souders talked about, you know, using image sprites, which most of you likely know what that's all about as well. Obviously, reducing the amount of requests for a greater amount of images but that came with its own challenges because now you had a bigger image to deal with.
Inlining images also came in as a solution here. But that also comes with its own little challenges where you'll have html file that's gonna be a little bit bigger, and then he also talked about combining scripts, which we might look at a little side-eyed, kind of, these days.
You know, 2019, like, I don't know about that. But that was the number one rule.
Now, if we look at what it was like, and I'm going back to 2011 here, and because that's as far as I could go in terms of content to 2019, this is the total amount of requests that are taking place.
Now, 2019 you can see that at the median, we're looking at, I believe, 69 requests and obviously a lot less in 2011.
But since 2011 we're up 305%.
Wow, right? So, that's something that's definitely legitimate to this day, keeping the request low.
Now, at the bottom here, I have a little address here which is, stands for, well HPBN, stands for high performance, is it, browser networking? Yeah is that it? - [Man] Yeah.
- Now, if you're not, if you want to be a bit more, you know, a bit more versed or at least very well versed in browser networking and the requests, this is a book that you might want to pick up, and that was the website. And if you don't pick the book up here, I believe Mr. Grigorik is in the building here with us today.
Somewhere around here, so you'll be able to. Oh, there he is.
Fine Canadian, right there.
(audience laughing) Rule number two, use a CDN.
Okay, that seems like again, a bit of a no brainer. Now, what's a CDN gonna do for you? It'll do what it did back then, it'll do today, helps you with issues like latency, caching static resources at the edge world wide.
Obviously, that'll help, say, if you're in Melbourne, and I don't know, you want to hit my website, which doesn't exist by the way, in Toronto, and maybe I'll have something set up in Sydney, who knows? That'll help.
And CDNs today, more important ever because with all the media that we're shuffling back and forth, these are things that, again, today, are even more crucial to the web's health.
So, that was absolutely correct.
Now here's a great stat.
Out of 468 million requests from the HTTP Archive, 48% were not served from a CDN.
This is some fantastic research by a gentleman by the name of Paul Calvano, you might want to follow him, that's his Twitter handle.
I believe, Paul Calvano is with us here today as well, I don't know somewhere.
You'll see him.
He's a quiet guy.
Shout out to Paul.
But there's room to, there's room to grow here. So yes, CDNs are absolutely important.
The third rule is add expires headers.
Now, this has to do more, overall, with caching but you definitely want to, and you know and also, I mean, stale resources whatnot.
I mean, it's a little bit more complicated, I don't want to get into too many details, but at the end the day you want to make sure that you're able to cache that content, also check on the freshness of some of these resources. Because at the end the day, you do not want to. Well, actually I want to get into this part right here, which is caching is ca-ching.
(audience laughing) Because you're also going to be able to save. You don't want to sit there and shuttle back and forth the same resources because your expire headers are off. That'll save you money, we'll talk about that in a hot second, that'll save your users money as well.
Here's some more data right here and I believe this is from the, the almanac that just came out more recently. Anyone familiar with that? Awesome.
You'll be able to speak to a few of the authors here today. So, you'll see that a very low percentage of websites have a good caching score.
What does that mean? It means we have some room to grow.
And the byte savings, let's talk about that. We can be saving a lot more data by getting our caching right.
So that was actually very important.
Gzipping components, that was number four.
Now, here's a great quote from Colt McAnlis, the foundation of the whole internet is compression. And that's absolutely correct.
Nothing happens on the internet without compression. So, it's gonna be essential to transfer resources, it's always gonna be welcome whenever available, and massive savings when it's well tuned.
This is an older stat, Netflix saw a 43% decrease in their bandwidth bill after turning on Gzip. Just a flick of the switch.
By the way that statistic you can find that on WPOStats.com, the authors are here with us, actually they're on stage with us earlier today. Tim and Tammy.
Now again, let's look at some Lighthouse compression scores. Only 60% are at 100.
And we're talking about, (tongue snaps) again a flick of the switch to get the rest up, mostly.
So, these are things that we definitely want to do. Ah, put style sheets at the top.
Now this is where get into some weird magical voodoo, kind of, business.
But at the end the day, again, once again, once upon a time in 2006, 2007, back then, we believed that order didn't really matter too much, and back then as well, IE was the leading browser at the time so you had these weird situations that, you know, IE had very particular needs.
You ran into issues like non-progressive loading, some flash of unstyled content, but then eventually we ran into things like critical CSS, async loading, and these things came into play.
So, again, these are sort of like antiquated rules that weren't completely false but definitely certainly had issues and they developed with time.
Now, this is where it gets really gangster. (audience laughing) Putting scripts at the bottom.
I just had to put the eyes there.
(audience laughing) 'Cause that got a little funny.
I mean, we're gonna hear about this, probably, I don't know if it's today or tomorrow but I believe there's a talk called JavaScript Bytes by Tim. JavaScript is very complicated.
It's got very particular needs, the execution has become one of the biggest challenges online.
So, again, 2006, 2007, there was experimentation taking place, discoveries were made thereafter.
So, when you hear things like putting scripts at the bottom, you might chuckle for a second, but at the time, these things were just, kind of like, well, whatever, this is how it's gonna work. You know, we're on desktop computers.
We found out eventually that synchronous scripts block the DOM construction.
Then there were these weird semi-hacks, some of them blocked the CSS OM.
And then thereafter, at the time, they weren't really around because, you know, we only had IE and some other browsers were just starting to scratch the surface, but async and defer came about. But at the end of the day, scripts, they were then, and they still are to this day, a little complicated.
So having scripts at the bottom, eh, not something that we'd necessarily adhere to.
Now, let's look at total JavaScript payload right now. And this is on mobile, again.
And I'll get into that, I'll get into why little later. 2011 to 2019.
You can see right now that at the median, we have about 380 kilobytes but that's a 622% increase since 2011.
And this is where JavaScript is going and basically, it's like.
How does that quote go? Jesus, grab the wheel! Ah! (audience laughing) Things are going a little crazy.
But we have to learn how to manage it and we're gonna talk about that a little later. Rule seven was avoid CSS expressions.
I won't even get into that because that came and went real quick.
But at the end the day, it looked like this. You know, it's funny how we complain about CSS-in-JS, but this was actually JS-in-CSS.
It was a very bizarre Internet Explorer hack and it got deprecated mad quick.
Make JS and CSS external.
Again, these are the pretty much standard to this day but, you know, you're talking about rule two and three, which is CDNs and caching, you know, related. I mean, it's proven to be fast, still, but we're looking at the opportunity to make sure that we're able to cache these resources, because if you go in line, you start to lose out, and some of these opportunities like caching, and then, and everything that comes with being in line. Rule number nine was reduce DNS lookups.
Now, this is actually super interesting because we talk about having less requests, awesome, but if you're gonna have less requests, you're gonna also have less DNS hookups.
Lookups, hookups, my bad.
(audience laughing) Woo. (chuckles) It was a long night, it was a long night, I forgot her name. (audience laughing) And sorry about that. They're expensive, they don't come for free. Now the cost of a DNS lookup is the result of many variables.
The resolver, the current load, the bandwidth, pardon me about that, proximity to the host.
But again, in modern times, things have changed a little and, you know, I mean, we have things like DNS-prefetch that are around today that are able to help out with moments like these.
But again, this rule definitely still stands in 2019. Now, I was looking at one of my top sites, not my favorite, but I was looking at ESPN.com and you can see the expense of a DNS lookup right there. So, these are things that you want to minimize as much as possible.
Speaking of minimizing, number 10 was minification. Now, this is again, very simple, we know what that's all about.
I like to call it the chroma sub sampling but for text files 'cause it kind of really is.
11, avoid redirects.
Loosely related to rule nine.
But redirects are kind of expensive as well, especially on mobile.
I mean, because you have a number of steps to go through and then eventually you get this notification for a redirect, and you have to sort of like repeat these steps all over again.
And think about this on mobile where you're gonna have some latency.
So yes, these are moments that you definitely do want to avoid.
And again, I mentioned the fact that on mobile you are going to have that latency to deal with, and we're gonna talk about that in a hot second. Now, I'm gonna race through the last few years, things like remove duplicate scripts, configure ETags, and again, sort of related to a bit of the caching conversation that we had made, make Ajax cacheable.
Sorry, I'm losing my mind right here.
Those were the 14 rules, and for the most part, again, back then, when things were a bit more simpler the resources weren't as plentiful as they are today, yeah, they kind of made some sense.
But I want to talk about this addendum that came through. Because a couple years later, this happened. Literally, two years later.
Which was, you know, we'll say, not necessarily part two because that's not what Mr. Souders calls it, this was literally a second book, but he did release another book called, Even Faster Web Sites.
Now, in this book we had more details.
He talks about the addition of more rules and some of these rules were represented in YSlow as well, when you did some of the audits.
In this book, he finally talked about image management, because none of that conversation took place in the first tome.
And that has become a massive problem today. He started to talk about things like splitting payloads, playloads, oh my god.
Sorry, I was watching basketball at the time, probably, you know, (chuckles) doing my deck and be like, oh my God, look at that dunk.
(audience laughing) Splitting playloads.
Come on keynote, I need that red squiggly.
And of course, avoiding blocking scripts.
That's gonna be, you know, forever, it seems. But, I mean, a lot of that came about just as, and I'm sure you thought about it, just as 2007 came. Because we're talking about the book comes out 2006, it was written in 2005, six, comes out in 2007, which was the first part, releases the next book in 2009. And you're thinking like man 2007, 2007, what was going on in 2007? Now, I'm trying to think of what I was doing in 2007. What was I doing? I had an amazing date at the time.
2007 I was actually working for a company just over the border here, a German company, 2007. Oh yeah, in 2007, this happened too.
Now, this was, what I'm gonna call, certainly, the first inflection point.
Why am I calling it that? Because this was the first moment that you can actually say that, looking back, it was the beginning of a changing of comportment. Users started to gravitate towards these mobile phones, these smartphones, and it was that one moment in time that eventually we can go back and look to. Because in 2016 we had our second significant inflection point. And 2016 is when, and depending on the documentation that you read, whether you know, it might be plus or minus a few months, but in November 2016, essentially, some claim, some feel, is when the mobile device finally eclipsed the desktop in terms of access to the web, world wide.
So, you finally had this moment time where more people were accessing the web on mobile than desktop, and I want everyone to remember this, 'cause it's never ever going back.
Like it's, at no point is someone gonna say, I'm sick of my phone, I'm going back to this desktop, I'm going to Starbucks with my desktop.
(audience laughing) Which I've seen actually, by the way.
So this is more recent data.
This was, I believe, October in 2019, mobile is at 52.48, desktop 44.5.
Now, this is world wide.
So it's probably gonna fluctuate from country to country, but I want you to remember this, if you start to remove, like your work day, where you're gonna be on your desktop quite often, it becomes dramatically different.
And it's overwhelmingly a mobile situation. Why do we have to, why do we need to keep an eye on mobile? Well, because of the fragility of the mobile device. Loading on mobiles is very challenging, and I like this quote right here, which is, "resource loading is a delicate dance "that can be delightful, "but also destructive due to device damper and limitations." It's a fantastic quote.
Because it's actually mine.
(audience laughing) Yeah, you might want to shoot that and tweet it, I don't know.
But no, honestly, it's actually very complicated. Resource loading on mobile is going to be a challenge for the foreseeable future, for a number of reasons. I mean, the performance process is now in part proof, and also a part perception, because we need to keep that user experience and, sort of like, you know, feel that something's happening.
We're essentially being asked to say, abracadabra and quod erat demonstratum in the same breath. We are performers of magic and somehow, pulling out real measurements at the same time. And this is happening all due to the mobile device. So, how do we, how are we gonna deal with this? How are we gonna deal with the fact that we have companies like Google, who have teams, called NBU? Which stands for Next Billion Users.
How are we going to deal with the fact that there's some people, today, who are getting online, exclusively, through the mobile device? This is like, how they're discovering the web. How are we going to deal with the fact that, you know, we talk about, potentially, you know, oh, high powered devices, I'm on an iPhone X, iPhone 11, I don't know what iPhone is out right now, I know I upgraded recently to an iPhone 7.
I really did, it's right here.
That's why this picture is gonna be grainy online, by the way. (audience laughing)
But these are facts, I actually tweeted out a stat, just a couple of days ago, that Uber noticed that 40% of their rides were being booked on Android phones that are 2015 and older.
And we're in 2019 today.
We are working with this array of devices that are out there being used every day, that has a massive range of power, of specs, of memory, and this is something that you and I have to deal with constantly.
Now thankfully, we have the performance now conference, which is what we all came down for.
And I'm super excited because we're essentially gonna hear from some of the brightest minds out right now. Who have a lot to share, who have collected tons of data, tons of writing, you know, and again, the modern resource loading is not what it used to be. You're talking about predictive prefetching. Who would have been talking about that five years ago? Divya is gonna talk about that tomorrow, I believe. I mean, we're talking about requests and how tough request is and some people felt like, oh man, you know what, don't worry about the H1 stuff because we got H2 coming.
Well, H2 didn't have, you know, everything straightened out. That's why people like Pat Meenan are here to straight us out with the truth.
Ain't that right, Pat? (audience laughing) Okay, you supposed to say, yeah! (audience laughing) I mean, we're gonna hear about, like, third party performance, you know, Simon Hearne is in the building, wherever he's at.
- [Simon] Yeah! - Okay, there we go.
(audience laughing) And I didn't even pay him.
That being said, I think we're gonna spend two fantastic days, we're gonna hear and learn a lot, and I hope you stick around 'cause I know I will. And I want to thank everyone for having me here. (audience applauding) - 10 minutes.
- Hello, hello.
- All right, walk over to these comfortable looking seats. - And I was actually gonna avoid this but-- - No, it's great.
Or we could just stand with or would that be awkward? So, I wanted to start with, first, we had like a really hard hitting question come in, so I'm just gonna lobby that, right away.
Is the good morning DOM message that you tweet, automated? - It's actually not, you know, I wanted to but I think the automation would be too boring. You know, I kind of have to get out there and just say, hey, you know, what's going on, who's doing what, you know? And maybe this, you know, the greeting is going to reflect something that I just saw or read. So, I don't know, man, it can't be all automated, you know, where's the love? A little personalization, all right, I respect that. - No doubt, no doubt.
- Okay.
All right, so you're going through all these rules and-- - Yup. - You're showing stats
around, you know, things like caching-- - Yup. - Things like compression.
You mentioned, you know, render blocking, JavaScript. These are the things that still, profiling sites-- - Yup. - I see all the time.
- Yup. - And they're impacting
performance negatively.
In the more mundane, low hanging things, that have been around for a long time, how do we get people, kind of, excited about this or to focus on this? 'Cause I feel like there might be a tendency for us to, like, hone in on whatever the latest greatest micro optimization is because that's really attractive and interesting, whereas like compression, eh, yeah.
- You know, it's funny you should say that, I was talking about this more recently.
So, for anyone who's, sort of like, stuck around and been around performance for a little while, I'm not saying that I have been, but I mean, I've, sort of like, had my pulse on what was going on.
There a couple things that I think brought out some change. And the key is, I've always said this, the key is curiosity. Are you curious enough to keep Dev Tools open 24/7? Not everyone is.
I know I am, I actually remember buying, you know, those ultra wide monitors, like 21:9's? I was so excited to get that because it meant that I could have Dev Tools open like fully and a page fully open at the same time, you know, so I didn't have to squint and stuff like that. But, it's the curiosity that's going to get you going. Now, that's part A of the answer.
I think Part B, and I think something that has been surprising to see on my end, is, I mean, and I'm gonna shout them out.
I think what Google did with Lighthouse was very interesting, because you now have a number of people who are actually out there, sort of like, kind of bragging about their Lighthouse scores. And that only happens when they're actually running an audit.
And I think the idea that they're running an audit and probably getting the results from the audit, hopefully reading the results, and making the tweaks at that point, I think it's been a bit of a game changer, and hopefully more people will sort of get into, like you said, like the weeds or whatnot-- - Sure. - And and say, hey,
you know, I'm not sure what that is but I'm gonna look into it some more because I need those five extra points. - Sure. - You know, so,
I think that's been good in terms of getting a bit of, like, an attitude change towards, you know, not looking at just like the very simple optimizations.
- Yeah, and I think that, sort of, not about Lighthouse, like, that's part of it, right, like the tools-- - Yup. - That build the awareness and the incentivization around it. - Absolutely.
- You know, that incentive is a big thing.
So, you know, do you think that, like, just Google's recent announcement, right, about the performance potentially being, like, calling out slow performing sites-- - Yeah. - And their mobile updates.
Are those another example of, like, major inflection points in terms of building this awareness? - I mean, it will be, certainly, and I'm, I'm really interested in what's gonna happen there because, again, some of you may remember, I'm pretty sure you do, I know, I had a conversation some years back about that with Tammy as well, where they had started to experiment with that slowly, and I'm not sure exactly why it got pulled, it could be a number of reasons. But, you know, the one thing that I'm sure a lot of, again, sort of like, long standing, you know, performance inclined persons will remember is, we're all trying not to be like that performance cop. - Yeah. - And you don't
want to have, you know.
So, I'll tell you something quick, someone once told me at a conference, they really enjoyed this talk I gave, I'm like, aw, thank you very much, et cetera, et cetera. And they told me they generally don't like performance talks and I was like, (gasps) (audience laughing) You know, like, clutching my pearls.
And I'd legitimately asked why and they said, well, you know I always feel like they're talking down to me. And I never forgot that moment.
And so I try to make sure that the conversation is always like, hey, you know, that's not bad, you know, here's what we'd like to talk about.
And it's always, kind of like, a spin that's gonna be positive, as much as possible. So, I'd like to see how that goes and whether people are kind of like, oh, what the hell? - Sure. - You know?
- No, that's a good point.
And I think that's something Laura Hogan has talked about quite a bit in the past, right? - Yeah. - That performance cop,
janitor thing. - Yeah, yeah.
Exactly, exactly. - All right.
Well thank you very much.
- Merci, sir.
- Thank you to Henri, again.
(audience applauding) So.
