Links
- Noam on Twitter
- Noam on Medium
- Noam on Smashing Magazine
- Noam’s performance case studies for Wikipedia
- Tweet: “Performance is not an aspect of software, software is performance.”
- Video: What if “browser issues” were our issue?
Video
Transcript
- Tanner:
Alright! Hello, everybody, and welcome to our first episode of Catching Up With Web Performance, a podcast about stories of people in web performance. Today I have my very special guest, Noam Rosenthal. Noam, how’s it going, man?
- Noam:
Going great, going great. Waiting to be a father of my firstborn and otherwise doing web performance stuff.
- Tanner:
That’s nuts, man. I mean, congratulations first.
- Noam:
Thanks.
- Tanner:
That’s going to be awesome to be a father.
- Noam:
Yeah.
- Tanner:
So here, this first episode, we’re just trying to hear people’s stories. With you, I want to know how you got into this world of web performance and maybe even some of your thoughts on what web performance is. And then we’ll just see where the conversation takes us.
- Tanner:
So maybe we’ll start there. Can you take me back to like, what’s like your first web performance memory?
- Noam:
Yeah. Actually, I started my career as a web developer. That was 1998 and we were doing… Back then it was before CSS and before Ajax, and we were doing tricks like having iframes, having invisible iframes that load HTML that injects code into the parent so that the page doesn’t have to reload. Basically doing an SPA with invisible iframes. This was very common back then.
- Noam:
It was very common but you couldn’t Google it because there was also no Google yet. So it was common in a way that everybody invented it by themselves. But everybody sort of invented the same things and that was one of them.
- Tanner:
Yeah.
- Noam:
That was maybe the first story. But where I got into actually looking under the hood was the days when I was working for Nokia. It was around 2008, 2009, and there was… At that time there was this big web versus native multi flame war across the industry, of like should everybody use native apps. Like the whole App Store thing started.
- Noam:
I have to tell you, I really, really dislike app stores and everything to do with them as a user.
- Tanner:
Yeah.
- Noam:
I disliked it from the start, that I have to download things onto my phone so that I can get some content.
- Tanner:
Right.
- Noam:
It’s like a big step backwards. So you can imagine which team I was in for the web versus native. On the other hand, my very smart colleagues from the native side were always saying, “Wait, but web is slow.”
- Tanner:
Interesting.
- Noam:
It was like a truth, like an axiom.
- Tanner:
Yeah.
- Noam:
You know how in Game of Thrones they said, “It is known.” And there’s like, “The web is slow, it is known.” That’s what I kept hearing.
- Tanner:
Right. And then you said back like, well, how do you respond to that?
- Noam:
I said, “Okay, maybe, but I want to know why.”
- Tanner:
Yeah.
- Noam:
I was already in the C++ world back then and the main thing that was considered slow in the web was animations. Animated UI after the first iPhone became like this, how do we do this in a way that’s 60 frames per second? It’s really difficult, etc. And I saw that CSS animations just started and seemed like a great way to express animations.
- Noam:
I really liked it. I always liked CSS and cascading and how it’s separate from the content. And indeed, at the time for the Qt port of WebKit, which was what Nokia was using, CSS animations were extremely slow. So it was like, okay I’ll going into WebKit code and understand why and try to fix it. And my first patch to WebKit in 2009 was to fix this.
- Noam:
It was a huge, huge first patch.
- Tanner:
Was to fix the animations in WebKit?
- Noam:
The animations in… Apparently Apple had something special. Today it’s very known, accelerated compositing, the whole implementation of how 3D animations work, etc. So for Apple they worked with core animations, with the internal macOS, iOS animation framework. And what I had to do is connect it with Qt or with Nokia or whatever’s animation framework instead. So it was like, oh, there’s just a missing link here to make this fast.
- Tanner:
And that was it. There’s just this missing link right here, and you found it.
- Noam:
That, plus many hours of work of actually making it fast. But that was my first step into actual web performance and going under the hood.
- Tanner:
Yeah. And you said this is right around, is this 2014, you said?
- Noam:
2009.
- Tanner:
2009.
- Noam:
Yeah.
- Tanner:
So it was 2008, 2009, app versus mobile, or web versus apps, native versus web. And you hear people say, “But the web is slow.” Animations are one of the slowest things on the web. And your first thought is like, “Let me just go in the browser and fix the code.”
- Noam:
Yeah.
- Tanner:
Ha! That’s wild, because for me, like somebody who’s—I’ve never worked in the browser before. I’m curious, it sounds like there was from like when you started in 1998 to that time a decade later, 2008, 2009, were you doing any browser work in there? I guess, how are you able to get into the browser and just do that code when you may have been writing CSS otherwise?
- Noam:
Well, I was a web developer late nineties, beginning of 2000. Then with a brief, brief gig as a professional bass player in the middle. I studied C++ and did a lot of C++ UI work in mobile. I went into mobile in a startup in Israel.
- Tanner:
And mobile like you were actually working on native apps?
- Noam:
I’m talking about 2004… I don’t think native apps is what you think it is in 2004. There was Symbian apps.
- Tanner:
Ah, I’m super young and new to the game, so catch me up on history. Learn me something.
- Noam:
So 2004, what was around was Nokia. And the only way to, there was other things too of course, but the only way to write mobile apps was Symbian apps for Nokia or Windows phone apps. I think it was called Windows ME at the time. It was called so many things, the Microsoft thing. But back then I was working more in embedded UI, like trying to build a mobile phone from scratch kind of software. That software ended up in satellite phones in the end. But I got pretty proficient with C++ anyway, C++ UI, and with graphics. I was working for… Qt was and still is a C++ framework. It was popular for many years and still is. Back then I was working with Qt customers trying to make them be able to use the framework and be fast on all kinds of devices. I was working very closely with Netflix, for example, trying to get fast UIs on TVs and stuff. So from there, jumping into WebKit was the next step.
- Tanner:
Yeah. Such an interesting pattern, going kind of there and back again. Web, going and working on TVs for Netflix, coming back, and then here we are doing these Nokia phone upgrades and saying, “Let’s make CSS animations faster.”
- Noam:
Yep.
- Tanner:
“I’ll go in and patch WebKit.”
- Noam:
Right.
- Tanner:
So where’d you go from there? You know, here we are, you’ve cut your teeth on performance here by just going straight to the source, improving animation speed and performance in the browser.
- Tanner:
What comes next?
- Noam:
Next time I ended up managing a whole big team of consultants. You can say I worked here on some internal HTML5-related projects at Nokia that I’m still not sure I’m allowed to speak about.
- Tanner:
That’s okay.
- Noam:
Yep, even though it was a long time ago. But trying very hard to do things inside Nokia after the whole thing with Microsoft, and then Nokia becoming smaller in terms of phones, and then none of that really panned out. Though, my work did come out in a Nokia phone called the N9.
- Noam:
It was 2011 or 2012. So I worked really hard to make that browser run CSS animations smoothly. I enjoyed that a lot. After that, I went into a totally different field. Well, not that different. But I went to Samsung Digital Health. I managed a sizable team to create like a research watch that can measure all kinds of vital signs.
- Noam:
I think I like jumping between platforms and products a little bit. It’s kind of a different view of the world to try to make a product than to build a platform for other products. Seeing one teaches you a lot about the other.
- Tanner:
Yeah, like what kind of things do you learn between those two?
- Noam:
Well, the one thing that platform providers do a lot where I think you only understand when you’re a product, when you work on a product, is many times the exact feature you need is either deprecated or in the next version. Like the motion of the platform. When developing a platform, you’re used to being in this motion of things evolving and evolving and evolving. And when you’re a product, sometimes you need to stop the clock for a minute and say, “Okay, at this point in time is everything the platform providing me actually doing what I need?”
- Tanner:
Yeah. So it sounds like on one you can just kind of go with whatever is already happening, but on the other one, you need to stop and say, “Hang on, what do we actually need to do here?”
- Noam:
Yes. I say that… Well, in a product you usually work in kind of a silo. You build on top of things, on top of things, on top of things until you get to the user. And then in big companies, they kind of like say that silos are bad. “We want people to coordinate with each other.” I don’t know if you ever encounter that.
- Tanner:
Kind of. Yeah. And I’ve mostly worked at small agencies. The past four years, I’m at a larger company, but it still feels like working at a small agency because we have so many groups. But they do encourage crossing over and trying to—you know, it feels kind of like a small workplace environment still, where you try to crossover a lot with different departments. So I haven’t quite hit the siloed point yet.
- Noam:
Right. So I think that’s a little bit of the risk with product. Also, you might become really specialized in one or two technologies and bad practices can fester and become like… On the other hand, when you work on platforms, you can have the pancake problem.
- Tanner:
The pancake problem?
- Noam:
Yeah, where everything is layered on top of each other. But if you try to build something that’s real, it’s just like syrup that goes all over the place and it’s not sturdy.
- Tanner:
Yeah.
- Noam:
So I think to build good platforms you have to understand products really well and understand users. I think when you build platforms, sometimes you’re a little removed from the users and you get to the users via people building products on top of your platforms. It’s like second degree.
- Tanner:
Right.
- Noam:
I think one thing that’s helped me a lot is when I started working on platform that I worked more as a sales engineer in the business department.
- Tanner:
Yeah.
- Noam:
I recommend every engineer to have a few years in their career as a sales engineer.
- Tanner:
Yeah. What do you learn as a sales engineer? I haven’t had the opportunity yet.
- Noam:
Or if you don’t do it as your job title, join the sales people or join customer calls.
- Tanner:
Like go in, get on the call and hear exactly what’s going on and be a part of it.
- Noam:
Where the rubber meets the road of your product. Like take the car you build to an actual spin, be a taxi driver with it.
- Tanner:
Right. Actually get out and feel how it’s being used and what’s going on.
- Noam:
Yeah, have customers yell at you. It teaches you a lot about the importance and the urgency, how things you build as a platform can make or destroy small businesses.
- Tanner:
Yeah, for real.
- Noam:
You can’t always see it when you are, kind of shelled in the platform.
- Tanner:
Yeah, we’ve got some really interesting directions we could go with this. I mean, this idea of product and platform. You said on the platform side, it’s a lot easier to become detached.
- Noam:
Yep.
- Tanner:
You don’t really get to hear from your users. On the product side, you’re like there. I mean, you can still be in a siloed department, potentially, working on product. But if you can get the chance to be, you know, go on the sales team, let customers yell at you so you can feel the pain or feel exactly how your product is being used and get better feedback on how to make it better.
- Noam:
Right.
- Tanner:
I’m curious then, if you take that idea or concept, I’m wondering how does maybe the web or web performance tie in with this? Where we’ve got the platform, we’ve got all these people making products, and then we have this group of people saying, “Performance matters! Make performance!” How does… How do you see this world?
- Tanner:
When you think about web performance, do you see kind of the platform and the product? Or do you have a different perspective, a different mental model for how you see that world?
- Noam:
Well, I definitely think that working on the product side of things helps me with this. Even though now I’m purely on the platform side of things working for the Chrome team. But I would say both with performance and with other things, like accessibility and security even, the key is the user. And when we say performance matters, or accessibility matters, we actually mean the user matters. It’s different ways to look at the user matters.
- Noam:
When I look at the things we develop on my team, which is the Core Web Vitals, and the other metrics, which… I’m more in the side of resource timing at the moment.
- Tanner:
Yeah.
- Noam:
The metrics we produce are supposed to be about user experience,
- Tanner:
Right.
- Noam:
We’re trying to make things that are qualitative and are good or bad user experience into something that can be quantified and measured.
- Tanner:
Yeah.
- Noam:
I don’t know if this answers your questions, but I think the main thing with products and platforms here is to not lose sight that the metrics are a tool for user experience.
- Noam:
They’re not the goal. They are an objective. They’re a good way to focus yourself on an objective that helps you with the goal but the goal is user experience. And user experience is something that changes from application to application. For example, Core Web Vitals are less meaningful when you have a very heavy, big application that has a session of hours, let’s say the Wix editor.
- Tanner:
Right, or like Photoshop on the web.
- Noam:
Yeah. It’s like, okay, so it has a loading spinner for a few seconds or whatever. It’s a question of user experience. You want to look at the correct metrics for your user experience. I don’t know if this helps answer your question.
- Tanner:
Yeah, actually it gives me some really good jumping off points here. Because speaking of platforms and products and getting closer to your users like, here you’re working on resource timing. Who are your users there? Or like when you think of getting on a sales call, like letting your customers yell at you, how do you do that where you’re at right now with resource timing?
- Noam:
Well, first of all, my previous job at Wix really helped me because I spent three years at Wix where we were trying to make Wix sites faster. And the Wix site is something that goes very quickly to end users. And I could always see how frustrating it is when a Wix site doesn’t load quickly, etc.
- Tanner:
Yeah. And would you actually try out the Wix site yourself?
- Noam:
Of course.
- Tanner:
Or would you watch like a dashboard somewhere?
- Noam:
Both. I learned a lot from that. But I think the problem I had with working on product is that you have to fix the same problem over and over again. Like you have the depth with one use case, but you don’t have the scale.
- Tanner:
Right.
- Noam:
I thought that right now in my career—and perhaps it will change again later on, probably—I’d rather have the scale and the breadth and affect the platform at the cost of being a little more remote from the customers.
- Tanner:
Yeah.
- Noam:
I think one of our biggest vessels towards customers is what’s called the RUM providers.
- Tanner:
Yeah. Real User Monitoring?
- Noam:
Real User Monitoring. And there are several providers of that, like Akamai, Cloudflare, CDNs, etc., that measure a lot of things in the field. They basically use the metrics that we provide to makes those measurements and understand user stories.
- Tanner:
Yeah. So you’re working on the platform that actually provides the metrics that the tools are able to get back and then tell product people how their product is working.
- Noam:
Yeah, but one of my greatest joys in this is debugging actual slow user stories. Like analysis of actual user stories. Like this is what happens on this website to this user and understanding why, understanding what could be done differently, what the platform could have provided that wasn’t provided, etc.
- Tanner:
Do you have a recent example or time that you did that, that you could kind of walk through? Like when I found this user story, here’s what I looked at and what I was able to learn from it.
- Noam:
Yeah, actually this is from before joining Google because I just joined six weeks ago.
- Tanner:
Happy anniversary.
- Noam:
Thanks. So I was working on a very heavy application of trace analysis on the web. They were analyzing gigabytes worth of JSON in a client-side application.
- Tanner:
Wild.
- Noam:
Yeah, it’s doable today.
- Tanner:
It boggles my mind that you can do gigabytes on the client.
- Noam:
Yeah. And they said it’s super slow, we think it’s just a limitation of the browser. The first request was actually to do a custom build of the browsers that fixes the limitation. And I said, okay, why don’t I look at the code, at the app first.
- Tanner:
Amazing.
- Noam:
Yeah. And what I found is that it’s an app that tries to load the whole JSON into memory and then analyzes it.
- Tanner:
Wow. Gigabytes in memory and then tries to process it.
- Noam:
Yeah. I had to do two things there. One is make it use the Streams API for everything. I love the Streams API.
- Tanner:
Yeah.
- Noam:
Check it out, listeners. Basically it was a JSON inside a ZIP, so I used a ZIP stream and a JSON stream that fed each other and then what comes out of the JSON stream is analyzed and then fed into the internal data model. So there’s no big, giant like let’s read everything into memory—there’s never except for the end model. The other thing was they were using something called breathing, taking breath, to avoid long tasks.
- Tanner:
Okay.
- Noam:
Which is a good practice. Say you have a lot of analysis to do and you say, okay, I’ll do a little bit, wait for user events, do a little bit, wait for user events. Or let user events…
- Tanner:
Kind of chunk it out over time instead of trying to just plow through it all at once?
- Noam:
Yeah.
- Tanner:
Breathing.
- Noam:
Breathing, yeah. Or yielding? Task yielding?
- Tanner:
Yeah, I think I’m more familiar with the yielding term, but I like breathing. It has a much more tangible feel to it. “Come up for air, take a breath!”
- Noam:
Exactly. And so their function for doing that was using requestAnimationFrame. But tip for listeners: do not use requestAnimationFrame for anything that’s not an animation frame.
- Tanner:
Interesting! What do you use instead?
- Noam:
requestIdleCallback.
- Tanner:
There it is.
- Noam:
requestIdleCallback is something that will happen almost instantaneously if you’re actually not doing anything. While animation frame would happen in the next animation frame. So if you’re actually cutting it to pieces that are a millisecond or 5 milliseconds, you might have several of them in the same animation frame, even though requestIdleCallback perhaps sounds slower than requestAnimationFrame.
- Tanner:
That’s so interesting that it sounds slower, but it’s actually faster because you’re doing everything as quickly as possible. If we’re idle, just keep doing it. Don’t wait for the next animation frame.
- Noam:
It’s faster when you’re idle and slower if you’re doing an animation.
- Tanner:
Words, man. Words are hard.
- Noam:
Yeah, same with setTimeout. setTimeout also sounds like, setTimeout with zero, also sounds like something that would be slower than requestAnimationFrame.
- Tanner:
But it’s actually faster?
- Noam:
It’s not faster or slower. It’s just not synchronized with your animations.
- Tanner:
Ah. This is where I have to start learning a bit more about the browser rendering model or the process of how it actually handles animation frames versus JavaScript execution.
- Noam:
Right. The basics of that… I had the privilege to incorporate the spec for requestIdleCallback into HTML recently as the spec writer. So knowing that to a depth helped me with the client.
- Tanner:
Right.
- Noam:
So basically whenever the browser can render something new on the screen or whatever, then you get another request animation callback. And then it runs all the request idle callbacks until you have new animation frames, basically.
- Tanner:
Gotcha. As an animation frame comes in, I’ve got my whole queue of idle callbacks, handle as many as I can until the next animation frame and then keep going.
- Noam:
Yeah.
- Tanner:
I want to ask you so much more about the spec here too. Should I go and, I don’t know, do people leisurely read specs to learn more? Or how can I learn more about these types of things, like requestAnimationFrame, idle callbacks, setTimeout.
- Noam:
First of all, yes. It takes a while, especially with the HTML spec. The HTML standard is huge, but it’s very cross-reference. It’s a lot of links to links to links to links. It takes a while to understand the lingo a little bit, but I highly recommend it as the way to understand how things work.
- Tanner:
Do you have any tips? I recall you mentioning something about learning the formal language of specs.
- Noam:
Yeah.
- Tanner:
Are there any sort of tips you have about like here’s how to read or interpret the formal language of a spec.
- Noam:
It’s more like kind of by doing it. Start with a question you have, like how does requestAnimationFrame work versus requestIdleCallback for example. Search for requestAnimationFrame in HTML spec. See where cross references get you.
- Tanner:
HTML spec requestAnimationFrame, go.
- Noam:
Yeah. Or MDN always has links to the standard.
- Tanner:
Yeah.
- Noam:
So yeah, it’s a little formal and algorithmic but it’s English in the end.
- Tanner:
Right. And as long as you know enough English to get by, you can make your way through that spec.
- Noam:
I’d say it’s not more difficult English than programing languages, writing function names, especially if you’re reading. If you’re writing, it takes a while to understand where to look for things. Also, you kind of have to compile it in your head.
- Tanner:
Right.
- Noam:
You might write something that’s a bug and you wouldn’t even know.
- Tanner:
Yeah. So let me recap real quick on the user analysis story. So we go back, you’re working on a large kind of trace route application that runs on the web, takes in gigabytes of data, you find out it’s slow. I’m curious whether you jumped in and tried it out yourself or like how you poked around. But somewhere from there you said, I see we’ve got two big problems here.
- Tanner:
One, we’re ingesting all this information right out the gate. Maybe I could switch that to streams instead. And then two, we had not only ingesting all the information at once, switching out the streams, but also during these really long tasks where we’re trying to process that information, the browser wasn’t coming up for air, so take that long task and break it up by breathing or yielding.
- Tanner:
And those are kind of the two things you did in that application.
- Noam:
Yeah. I’d say I started from something very crude, which is running the app with developer tools and pausing it a lot.
- Tanner:
So as the spinner’s going just hit pause or stop. Like I’ve got my dev tools open with the performance tab, record, stop, see what’s going on.
- Noam:
Yeah. I’ve used that extremely crude technique for years and it never failed me.
- Tanner:
Yeah.
- Noam:
It would always, if you pause it for enough times, it would always end up leading you to interesting places in the code.
- Tanner:
Yeah.
- Noam:
For example, it led me to lodash cloneDeep.
- Tanner:
Tell me more.
- Noam:
Yeah, that’s another thing. This was a one liner that just saved them so many seconds. I did pause and pause and pause, always saw the time in the middle of lodash cloneDeep. And I looked for the caller of lodash cloneDeep and I saw that it’s actually a flat object and I changed it to just doing like curly braces with three dots, like a shallow clone. It needed to also clone the prototype, so I cloned the prototype.
- Tanner:
Right. So just switching from cloneDeep to like a shallow clone saved…
- Noam:
Seconds.
- Tanner:
Crazy amounts of time.
- Noam:
Yeah. It saved like in the 30%.
- Tanner:
That’s fantastic.
- Noam:
Yeah. I’ll say the first rule of web performance: do less slow things.
- Tanner:
Wisdom.
- Noam:
Usually it’s the first thing I do when I optimize something. There’s usually a few things that are super slow that are, when you just fix them, they’re usually silly. Usually if you just pause your app or use the timeline view in Chrome DevTools, or the heap view, which is where I found the whole huge JSON is actually in memory as a string.
- Tanner:
Yeah.
- Noam:
You just do those things and you find these huge outliers that are usually the first thing you have to fix for performance. And then you get to the smaller bits and then more interesting things come.
- Tanner:
Speaking of interesting, are there any other things, maybe in general that you find interesting or difficult or confusing about web performance?
- Noam:
Well, I think web performance is extremely difficult. And it gets us to some conversation we had a few weeks or month ago about performance being the resource. I see the question of “Why is performance difficult in software?” the same as “Why is money and time difficult in business?”
- Tanner:
Yeah, why is it?
- Noam:
Because it’s a measurement of everything.
- Noam:
When you talk about software, you talk about computers. Sure, you have other aspects like users, etc., or whatever the content is. But in the end, the software itself, the material of software is computers. Performance measures time and it measures money. It measures energy over time, like how many CPUs you use. Performance is not just about time measurements.
- Noam:
It’s also about like how many cloud instances do you have up and running. That’s also performance in a way. Like your AWS bill.
- Tanner:
Right. I’m trying to find a way to articulate this because it gives me a visceral feeling that I can’t quite describe. Performance isn’t like a thing that I can take and tweak, right? Like it it just is. It’s the software. It’s like asking yourself, why is it hard to get fit or to lose weight?
- Noam:
It’s exactly like that.
- Tanner:
To keep flossing, right? Why is it hard to save money?
- Noam:
Yeah. Why is it hard to separate the mind from the body?
- Tanner:
They’re just interlinked.
- Noam:
It’s interlinked. Like whatever your content is is interlinked with performance. It’s not separate. It’s not a separate thing, it’s not a feature. I think when I said it’s not an aspect, it is actually an aspect if I look at the world, but it’s not a feature.
- Tanner:
Interesting. What’s the difference between an aspect and a feature?
- Noam:
An aspect is like a way to look at things. Like you can look at software from the aspect of user experience or from the aspect of performance or from the aspect of legality or security. Those are aspects, but they are not a feature. Neither of those things are a feature. Also accessibility is not a feature. They’re different perspectives to look at your software, but your whole software is related to those things.
- Noam:
It’s not like something you can put on the side. It’s like… yeah.
- Tanner:
It’s so interesting because it flies in the face of, I hear so often, “Performance is a feature.” You know, you’ve heard people say that too. “Performance is a feature, you should treat it as a feature.” And here we’re getting a bit more philosophical about it, saying, “Well, no.” When you think of it as a feature, and I’m curious what are maybe the side effects of thinking of it as a feature as opposed to, you know, performance is almost like a frame of mind. It’s a perspective, similar to accessibility and security, where it’s a way for me to look at this thing.
- Tanner:
I wonder, if I’m looking at just properties of an object and I say, like this book, what are its features? What are the features of this book? It has these words or it has this color. What is its performance? You can’t really consider performance in the same way. It’s immediately relative. I have to start asking, well, performance for who? What is it performing, etc.
- Noam:
Yeah, I think that’s because a book is not software. I think it’s more of an aspect of software, it’s not necessarily an aspect of everything. But I guess from a book perspective, you have the length of the book, you have the weight of the book, you have how long it reads, how many chapters it has. It does have some features that are performance-like, but it is very philosophical.
- Noam:
But I think, look at software more as a living thing. A business needs to manage time and money as a body, as a person, we have to manage our health and our fitness, etc. Diet.
- Noam:
I think the most important thing about why we should not treat it as a feature is because many times in software organizations management treats it as a feature. The same with security and accessibility and other things that are kind of aspects that are in the commons. They are not something that’s specific to your product usually. Many times, and I don’t want to, how do you say it, I’m grossly generalizing.
- Tanner:
Right, right. I don’t want to blanket statement this, I don’t want to…
- Noam:
I’d say that blanket statements are always 100% wrong.
- Tanner:
Yep, yep.
- Noam:
But I would say that many times I encountered managers that are really focused on the actual marketable features, like the product-specific features, etc. The whole thing about security, accessibility, and performance… SEO is maybe also somewhat in that category, though managers today are a little more focused on that.
- Tanner:
Yeah.
- Noam:
It’s like, okay, we have to cover our backs there, but it’s not meaningful for me as a manager to excel there. It’s like, let’s tick a box here.
- Tanner:
And companies that don’t set aside these aspects and treat them as features, those companies are more successful than the ones who say, “I’m going to dedicate a sprint to improving my performance.”
- Noam:
Yeah, they kind of sideline it. Also performance needs to be in your how you develop your code, how you think of your code, what team you’re building. It’s not like let’s build it and then worry about performance.
- Tanner:
Yeah.
- Noam:
It’s like part of the health of what you’re building.
- Tanner:
Yeah. I’ll eat all this food and then I’ll worry about how healthy it is or how to improve my health.
- Noam:
Something like that.
- Tanner:
Or I’ll spend all this money and then worry about how to save money.
- Noam:
Yeah.
- Tanner:
Yeah. There’s a lot more that we should do there. I’m still waiting for the Noam Rosenthal blog post about performance as the resource of software. Which, speaking of, we’re coming close to time. So maybe do you have any closing thoughts? Like, how, what are ways that people can learn or improve?
- Tanner:
What are your parting words of wisdom? For how to improve performance or better learn performance.
- Noam:
I would say what my mom taught me when I was a kid, which is, “Don’t believe what they tell you in school.”
- Tanner:
Yep.
- Noam:
Always check for yourself.
- Tanner:
Go straight to the browser.
- Noam:
Use dev tools, measure for yourself. Use RUM, measure for yourself. When you hear best practices, “Don’t do this, do that. Don’t do this, do that.” Or you hear, “This tool will make your site faster.” “It’s important to get Core Web Vitals up.” Always ask, “Why?” Understand why. Don’t believe it. Understand why is that true for your users, or maybe it’s not true for your users, and how it applies to what you’re building. That’s my final words, I guess.
- Tanner:
Wisdom. Well, thanks so much, Noam. Really appreciate you coming on, taking the time.
- Noam:
Thanks for having me.
- Tanner:
Yeah, until next time.
- Noam:
Pleasure. Till next time. Good luck with the podcast.