Vinicius Dallacqua - Catching Up With Web Performance

Catching Up With Web Performance

Vinicius Dallacqua

00:00 / 46:40

Video

Transcript

Tanner: Hello, everybody, and welcome to another episode of Catching Up With Web Performance, a podcast about stories of people in web performance. Today my special guest is Vinicius Dallacqua. Vinicius, man, how’s it going?
Vinicius: Hello, and hello everybody. Yeah, it’s going good. It’s going great. It’s good to be here.
Tanner: I’m glad to have you. We talked a little bit already but the gist of the show is I wanna hear stories, man. I want to talk about, like, how you got into this, how you learned, things you find interesting, difficult, confusing. And then just see where the conversation goes from there. So what’s your first web performance memory? Like how did you get started in all of this?
Vinicius: Yeah, that’s a great question. So I am originally from Brazil. I’m a Brazilian living in Stockholm, working for Spotify now for about three years. And it all began… I’m from a part in Brazil that does not necessarily belong to the great big centers where most people come from. So I come from an area where resources, let’s say, were a bit more scarce.
Vinicius: So internet speeds were quite not there. So as I was in the university and building systems, like learning how to build systems, they mostly taught us backend stuff. So they did not really teach us a lot of frontend things. But I kind of, from very early on, had a passion for user experience in general. And that kind of ended up evolving towards performance, where I really wanted to make sure that whatever I built would be fast, or at least fast enough, on such internet speeds that I was facing back in the day. So that kind of stuck with me ever since.
Tanner: Were you building things already? Like, do you remember some of the early things that you were doing?
Vinicius: Yeah. I mean, I was building… So back in the days I worked for a government agency that was responsible for the elections, well, still is responsible for the elections. And within it, one of our… Of course, like, in Brazil, the elections are fully digital, so they have a digital process, and it’s everything’s electronic, which is awesome, because you have results within hours and all that good stuff, but it absolutely must not fail.
Vinicius: And the team I was with, we built systems both to actually execute that process but also that supports the process around it. So internal systems and externally-facing systems that get no access for three years and for like two days after every two years, or two to three years, it is absolutely battered. So it also matters. It mattered back then, performance, since then.
Vinicius: So yeah I was working there for like six years and before I started to move out of Brazil.
Tanner: Yeah. I mean, I’m just thinking of, you know, here we go, everything’s fine, and then the two years are up and it’s time for the election and it’s completely battered. Like, how do you prepare for that? What were some of the things? Can you remember, like, what was it like? What did it feel like in that moment?
Vinicius: Yeah, it’s definitely a very stressful time for everyone involved because the systems cannot fail. Like you do have contingency plans, as any good system would have, right? So you scale accordingly and you have contingency plans and whatnot. But, I mean, back in the days we just like stress tested and you have some audits run on it because it also must be secure and must be private. So all of that stuff, like your vote is private, it can’t be breached, that privacy can’t be breached. It’s a very rigorous process, actually, around it. So it taught me a lot back then.
Tanner: Yeah. And then from there, did you move to, you said to Stockholm? Like right after that? Or like what happened next?
Vinicius: Yes. So from there, I actually moved to Malta.
Tanner: Okay.
Vinicius: I lived three years in Malta, in the Mediterranean, and working for a Swedish company, a small Swedish company. But then every time I came to Sweden, I really was like, “Okay, I’m sold on this country. I want to stay in Sweden.” And after three years, I decided to move out of Malta and settle in Sweden. And I’ve been here for about six years now.
Tanner: Wow, wow. I mean, I’m curious, like, what inspired you to go from place to place? Was this, you know, the job leading you or life?
Vinicius: There was always a job, yeah. It was always a career progression in a way. I mean, of course, tied to the personal side where I really wanted to move to Sweden.
Tanner: Right.
Vinicius: But it was always a job choice. So I worked my way up to Klarna, which is a fintech, a Swedish fintech currently even expanding to the U.S. as well, but it’s big in Europe. And we have, I mean, there is one of the places where, again, I was flexing my performance brain. Where, for Klarna, they have, I mean it’s checkout, right? So, it’s of course more complicated than that, but the product that I was part of is the Klarna checkout experience where merchants would embed us, well them, into their websites to serve, works very close to how you would use PayPal or, you know, like Shopify experience, but it’s an embeddable solution.
Tanner: Yeah.
Vinicius: So of course that couldn’t also, like, it cannot fail as a purchase experience, right? And it has to be performant. But most important of all, there is always Black Friday. So it had a very similar feeling…
Tanner: The election of e-commerce.
Vinicius: Exactly. So it had a very similar feeling. It kind of was a bit of a throwback for me.
Tanner: Yeah.
Vinicius: Where, I mean, for big merchants you have big volumes but people don’t really shop that much around the year. There are always some ups and downs. But when it comes to Black Friday, it just, it’s the most important day of the year. You cannot fail for everything that’s sacred. So it was kind of the same, right? Like very important things, like stress testing, making sure that performance, it’s not hindered, and code freezes and all of that stuff.
Tanner: Now I’m curious, like, these two wild examples of “This just cannot fail.” Like I have huge Black Friday sales and I have elections to deal with. I don’t know anything about stress testing. What do you actually do when you stress test something?
Vinicius: So it’s really, it depends. There are different, of course, like most systems are multi-layered, right? So you have your backend and you have your frontend. So for the frontend to fail, it’s a lot harder. Because most of the time it’s just shipping assets. So as long as Amazon is up, or Google is up, you’re up. So your assets are already compiled, and already built, which is where I worked most of the time for both options.
Vinicius: Of course, back in my Brazilian software developer days, everything was a bit more coupled together. Just because it was 2012, it was another time, and other ways of building things. HTML and jQuery were still very cool, so everything was a bit more coupled.
Tanner: jQuery’s still cool!
Vinicius: jQuery’s still cool.
Tanner: Nope.
Vinicius: So everything was built a bit more coupled. And through that, of course, stress testing meant for us to make sure that it could handle the predicted… Like the load is massive, but quite predictable in that case. So you can, like, there’s not much uncertainty when it comes to scaling. But on the other hand, for Klarna, it is of course, a lot more unpredictable. You don’t know. You just know there’s gonna be loads of people trying to buy at the same time.
Vinicius: But when it comes to frontend, at least all you have to do is make sure that your frontend has good performance, right? Which, back then, we did not have all the good tools that we have currently, when I was there some three years ago.
Tanner: What’d you have?
Vinicius: Everything was still starting. We had, we did not have, like, web vitals and none of that. But like all the performance metrics, like TTI, Time To First Byte, and First Contentful Paint, all of that stuff was already starting. So we had something to point our fingers to. Like, “Okay, is our frontend performant enough? Is it good enough?”
Vinicius: Because that’s really all that we had to make sure. Like, on the backend, of course, there is same problems with scalability and stress testing and smoke testing, like if we hammered this with hundreds of thousands of requests a second would it be able to withstand that?
Tanner: Yeah. Which, again, me as a dummy, I’m picturing you clicking the website a bunch. Are you manually clicking a thousand times or 300,000 times? Or are you making a robot, or like how do you…?
Vinicius: No, you’re running scripts and robots, yeah, to do that stuff. So yeah, I mean on the backend is this, I have a lot less experience from that, but I participated in some testing sessions.
Tanner: So would you do something similar for the frontend too?
Vinicius: For the frontend, we would just make sure that, mostly it would be just like the auto-scaling works if we need more buckets to serve. But mostly it’s just making sure that the code is stable and performant when it comes to load times. And one of the things that really led me to dig even deeper into performance was when Lighthouse came about and we had, you know, the possibility of knowing beforehand if you would be able to ship good performant code.
Tanner: Could you know beforehand before Lighthouse? Or was it like a revelation that, “Wow, Lightouse, I can actually…”
Vinicius: Yeah, no, it was really great. Beforehand, you’d have to just have a profiling session, you know. Like you would have to like, “I think this page is not performing well,” and profile it and you know, go and look into the flame charts.
Tanner: Like in DevTools or something, open that up or…?
Vinicius: Yeah.
Tanner: Were you using Firebug back then or just DevTools?
Vinicius: I did use Firebug fairly, fairly, but I, my, one of my favorite tools was just to take a look at the flame charts and the network graphs and see how things stack together.
Tanner: Yeah.
Vinicius: But when Lighthouse came about, I was absolutely obsessed with automating Lighthouse performance profiling. And I did create, like, before the… Nowadays we have Lighthouse CI, which does exactly that, but back then we didn’t. And I kind of like, back then, before Lighthouse CI existed, I created sort of my own version of it—I’m sure many other people out there did the same for the same reasons—and ended up creating an automation around Lighthouse to, every time we have a code change coming up on GitHub, that would execute a script to run Lighthouse against the build for that PR and make sure that, comparing against what we had in master, we would not introduce any sort of performance degradation. And with that, at least on the lab scenario, make sure that we were, you know, predictable.
Tanner: Right. Do you remember the moment that you first heard of Lighthouse? Like, were you looking at Twitter? Or were you on a newsletter? And then the first time you tried it, maybe, do you remember?
Vinicius: I think I can recall. It was definitely Paul Irish on Google IO, I think, when he had a talk about Lighthouse. And back then it was a Chrome extension that you could download and install. So I immediately did that and it was like so, such a pivoting point really for tooling, when it comes to performance tooling. Yeah, and after that I actually started using it as much as I could because it made the life so much easier.
Tanner: Just click the button, let it run, all of a sudden I have like, nice… Was it still, you know, the green, yellow, orange, or is that right? Green, yellow, red?
Vinicius: Green, yellow, red. Yeah, and like the best part is just the actionable items that you have from it. Which helps people that, it helps people from all kinds of knowledge. Like you run an audit and it gives you actionable things to do, that you can do to fix. Of course, as you come to understand with most computer science problems you have, it’s always like a big, “It depends.” Kind of like, some things are always more gray area than others and you need a lot more experimentation around it. But they, for what it gives, is really great value.
Tanner: Yeah. So, sorry for one second, I feel like I missed, what was the job in Malta? There was back in Brazil, which, I’m gonna get the name of the agency. What was the name of it?
Vinicius: So in Portuguese it’s TRE, the initials.
Tanner: TRE. So we’re back in Brazil, TRE, then go to Malta. We didn’t quite talk about this one as much, but what was in Malta?
Vinicius: It was a frontend dev position on a small Swedish company there.
Tanner: And then after that going to, is it Klarna? Is that how you say it?
Vinicius: After that I went to another smaller, well, slightly bigger Swedish company in Sweden. And then from there, like, just after six months, I got hooked by Klarna.
Tanner: And then at Klarna, Black Friday, everything’s wild, exciting. And then while you’re there, Lighthouse comes out, changes the game. What happens after that? Because are you still at Klarna now, or you’re not?
Vinicius: No, now I’m at Spotify for, it’s been three years here at Spotify. And it was kind of funny because when I started doing those automations with Lighthouse at Klarna, I was really hooked into it. I was like, “Okay, this is kind of where I wanna, you know, become a specialist.” I want to do this, tooling for performance and performance processes and performance-oriented work.
Vinicius: And when I started interviewing for Spotify, I actually, like, on the managerial talks that we have during the process, I was always like, “I really want to work with performance. Like wherever you put me within Spotify, let me do performance. Like it’s my thing, it’s my jam. I really love doing it, talking about it, and writing about it. So if there is not a performance culture, I will create it.”
Tanner: Was there one? Did you make one? Where are we now?
Vinicius: And this is now the third part of my career, which kind of becomes, it turns into something on, “How do you create a performance culture around the company?” Because I started doing that at Klarna, where I created tooling around it and helped other teams to utilize such tooling to help them as well, build better performance awareness, and doing talks internally and creating articles.
Vinicius: And when it came to Spotify, there was like, there was people interested, but nothing really properly spawned out of it. So I kind of started over with the same project, actually. I ended up, but this time around with Lighthouse CI. So I started over like, “Okay, let’s automate Lighthouse tooling with our builds and understand our performance on lab and make sure we don’t ship regressions for performance.” That’s step zero. And from there I just, like, building internal knowledge and the culture and, like, we have to care about performance.
Tanner: Is it just you? Are you the Lone Ranger, like, creating this culture?
Vinicius: Well, I’m one of, there are more passionate, a lot of other passionate people around, that also likes about, like teams that really helped, enabled me working. We have a fantastic web infra team based in New York, where I had the pleasure to embed with and create the standard, like standardize the tool that I started creating, to become a plug-and-play solution for anyone within the web domain to have Lighthouse tooling.
Vinicius: And from there, now I’m working mostly with, also now solving the problems for real user monitoring. Which is the other side, right? Like you can’t only look at lab, you have to look at your users’ data to better understand your product.
Tanner: Yeah. So just to make sure I’ve got the Spotify story. You’re interviewing, talking to the managers, “Put me in coach! Put me in performance. Like I just need anything.” And they say, “Okay.” And there was or was not, like it sounds like you got there and you found a couple of people. You weren’t the only one. There were some other people there you found to rally around this idea.
Vinicius: Yeah, there was a few people that was already doing some things around, but nothing was taking much shape. And so what I did from beginning was to announce, really. Like, “Look, I really care about performance, guys.” And then every time there was something that I was doing to make sure it was, you know, there was knowledge around these.
Vinicius: So me and my manager was constantly talking, of course, and making sure that the other managers also understood that there was work being done. And then I actually created our first performance-oriented event within the company. I dubbed it “Perf Days.”
Tanner: Nice.
Vinicius: I’m actually planning a second one for this year. But on that day, I gathered all those like-minded people that wanted to talk about performance, and gather everyone together and just share the culture, share the knowledge, and others that would be curious about it.
Vinicius: And it was, it was really awesome. It was a great success. And now we’re going to have the second iteration soon. And it’s like, really trying to get everyone that is, that was doing something or was curious about performance, and to know that there is an effort going on to try to bring their ideas together.
Tanner: They’re not alone.
Vinicius: Exactly. So trying to be the voice of that. And that’s kind of how I’ve been, now on this part of, let’s say, my “performance career” so far, is trying to solve this problem. Like, how do you create a culture around performance? How do you come to a company and make that movement? You know, like how do you convince managers that is important?
Vinicius: And we can talk more about some of the understandings that I currently have. Like how do you convince managers, how do you bring people together and build the knowledge and build the tooling? And like, this is now where I’m currently focusing.
Tanner: I would love that. Because, you know, through this story we’ve got a lot of these technical ideas, like how are we stress testing, preparing for these big days where performance really matters because we can’t fail. And then it morphs. Somewhere along the way you get this, “Woah, I’m super passionate about this. I’m automating this tooling that equips and empowers people to measure performance for themselves and to create better things themselves.”
Tanner: And then that spins off even more to, “No, I want to create a culture around this. Like I don’t just want me and some people being, you know, ‘Okay, cool, we’ve got tools,’ but like also I want there to be a rallying cry. I want people to know they’re not alone. I want people to know that they have somewhere to look for answers or advice.”
Vinicius: Yeah, exactly. And like building the knowledge, building processes and like… Because things become a lot easier when, like, and you can definitely take a step back and think how it was back then, right? When we did not have a collective, let’s say collective agreement, which it’s not as far as standardization because it’s not part of W3C just yet, I think, but before we had this collective agreement and understanding of which metrics are important.
Vinicius: And now we have Core Web Vitals, a group of absolutely amazing people that gathers together and discuss metrics and try to come up with better metrics to help us, you know, deliver the best results to our users. Which is, you know, the most important thing to me since the very early days. But back then, we did not have such a thing. We were just like, “This site is fast. It feels fast.” You know? And then we started talking about perceived performance, and then things started taking shape.
Vinicius: But now we have an easy way of pointing out to things that matter, that we can measure, and we can understand. So it becomes part of creating a developer culture, becomes also building that knowledge internally. Also having easily accessible information about that and about like, “Okay, if I’m trying to solve my performance problems, what are the steps I can take?” You know, like to help people, bring people on the same level, and together to… It’s not a difficult task to do if you have information around it, and if you have a culture that helps people around it by building the tooling and helping enable, enabling those processes to become something, part of your development process instead of just a second thought.
Tanner: Yeah. We’ve got so many directions we could go here. Because, like, there’s one side of culture trying to, it almost sounds like negotiating with your managers, or like somehow convincing. There’s a weird side of convincing here, making a case. And then on the other side, there’s, I guess I’ll call it “equipping.” Like we’re talking to the other developers, the people implementing the changes. And then there’s the tooling still…
Tanner: In the background, Core Web Vitals comes out. “Woah!” And now we have the W3C has provided the Performance API and I can actually collect RUM data, right? Like there’s kind of these three different topics. I guess, which door should we open? And maybe I’ll phrase it this way: What things most interest you? Or which things do you find difficult or confusing about web performance?
Vinicius: So the things that most interest me is still greatly about user experience, but nowadays I guess it’s kind of morphing into both my end users and about the developers trying to solve performance issues.
Tanner: UX and DX.
Vinicius: Exactly, so the two sides of the same coin, and if you manage to make both happy it’s great. So to me it kind of shifts a bit into that nowadays on the importance.
Vinicius: And the negotiation aspects with managers, and all of that people, becomes a lot easier task when you have data in your hands. Like when you can show them, “Look, we are hurting our users. Look at the bounce rate versus our Core Web Vital metrics.” It’s like, try to build a connection and a correlation and then that kind of becomes a much easier talk to have. But you first have to have data. And for that you need to have the developer experience in check.
Tanner: Have you had that talk? Have you had to, like, collect data and put it, I don’t know, on a spreadsheet and say, “Here.” Like, maybe what’s one of those times that you had to have a conversation like that?
Vinicius: I had to have similar conversations. Hopefully, thankfully, people here at Spotify really cares, same as me, about the end user experience. And I have been blessed with project managers that cares about performance as much as I do. So my job has been made a lot easier. But when it comes to any kind of talks with, you know, managerial level people, you always need data. And for that, the whole DX and tooling becomes kind of a step zero for most people to start building stuff.
Tanner: So tell me a little about that data. I know you mentioned real user monitoring too. Do you start with some lab tests and just say, “Hey, look how fast our website is,” or do you jump straight to, “Let me get some RUM data,” and show them correlations?
Vinicius: Yeah, it depends. It depends on where you are. It’s definitely, I mean, twice now I have started with lab data. And the reasoning behind it is lab data, like, especially with ours, you can create pretty convincing data. As in, you can shape how the profiling is done and fine-tune it to a certain degree to where you can be fairly confident on those results that comes after it.
Vinicius: Of course, we never fully represent real users, but it can give you a very good indication of problem areas. So with the development side done, you at least can try and make sure that you’re not shipping regressions on performance and understanding your current state. But the natural second step, and where you are actually going to start being able to come with data, is when you have real users data.
Tanner: Yeah.
Vinicius: Then you will really be able to understand, “Okay.” So like Spotify is a global product, right? Like the user experience is not the same for everyone. And I work with the web player part of Spotify. So I work with the mobile web player most of the times nowadays, which is even on a narrower niche, where we are focused on the emerging markets, where performance really matters.
Tanner: I have so many questions now.
Vinicius: Yeah, for sure. And from there you start like, “Okay.” For users in Brazil, again, like on a Motorola Moto G on a 3G connection, patchy 3G connection, how is the user experience there? Because you compare across a broad section of data and you have to properly also slice it and make sense, right? Because you can’t just put everyone in the same pot if you have a global product.
Tanner: Interesting. Tell me more about that. Like, I hear slicing and I think pies and pizzas, like what are you, you’re slicing data? What do you do?
Vinicius: Yeah. So you’re making sure that you segment the data to make as much as an accurate representation as you can. Because when you have a global product, people will use it in different conditions and different devices in different network conditions. And when even battery percentages matter, where a cell phone can go into low power consumption, where they use slower cores, which affects your JavaScript compiling time and all of that stuff. You really, like, as much data as you can gather on those kind of things, like how the device battery is, if you have access to that kind of APIs, it really helps you understand.
Vinicius: So when it comes to slicing the data afterwards, you want to make sure that, for instance, you don’t compare users in the United States with a 5G connection are in the same pot as users in India or Brazil with a bad 3G connection. So you want to slice that data to have a proper…
Tanner: So look at just a group of people, like I’ll look at the data from the people in the US on their 5G connections, and I’ll look at that in one dashboard, and then I’ll look at emerging markets, like new users in India, on a different dashboard. Keep those separate.
Vinicius: Exactly.
Tanner: Gotcha.
Vinicius: Because those, like, when you talk about percentiles, if you put them together, those become the 99, 95, percentiles. So you’re talking, we’re talking about the tail end of your graph, like that long tail that forms after your graph has peaked, and then you’re talking about the people who are really struggling.
Tanner: Right.
Vinicius: That section of users who really are struggling, the P99s, P95s and so on. So they, if you are only taking medians, and I mean, we’re getting to technical on how looking at the dashboards…
Tanner: We’re getting to statistics!
Vinicius: We’re getting to statistics. Hey, you thought you’d never use that stuff when you were in college, didn’t ya?
Tanner: You were wrong.
Vinicius: Well, well. But yes, exactly. So if you only look at medians, averages, and P75s, yes, you’re going to fix for a lot of people, but then you’re not going to really understand the people who are really struggling with your current state.
Tanner: Yeah. So I’m interested in what are things you’ve been learning with the Spotify mobile web player? Like are there things that have surprised you that have come out of this?
Vinicius: Definitely. One is that how incredibly difficult it is to build a play button that works properly.
Tanner: Really? Tell me more.
Vinicius: Oh, you would be surprised. But it’s like the whole, gosh, like you can get very technical.
Tanner: The play button cannot fail.
Vinicius: Well, it can not. But yeah, like how different, even to this day, you still… When it comes to the desktop world, things are looking pretty good and standardized. We have most of the browsers now on Chromium, which is pretty much all the major browsers are now evergreen. So you know, like the struggles of the past definitely do not really affect people.
Vinicius: That’s not necessarily the same in mobile world, actually. Because most people don’t realize, but iOS users only use Safari even when they are on different browsers.
Tanner: What? I’ve got, look, I’ve got Firefox on my iPhone right now, Vinicius. Are you telling me this is a lie?
Vinicius: It’s a lie. So yeah, like the first time I heard that a few years ago, I was like, I was surprised.
Tanner: Which, to clarify, we’re saying that browsers, like all the browsers that you find on your iPhone, they may look like a different browser, and they have some things that are unique, but under the hood they’re all using WebKit. They’re all using Apple’s engine.
Vinicius: Exactly. They’re all using WebKit and they’re all using Apple’s engine. So you are very limited when it comes to iOS development for the web because it does not evolve as fast. It’s not an evergreen product, it’s still tied, like pretty much, a pretty old style of shipping browsers, right? It’s very attached to your current operating system.
Tanner: I’m gonna shout out Jen Simmons, though. I’ve seen the team on Twitter, they’ve been pushing a lot of updates to Safari. So shout out: Thank you! Thank you for doing some excellent work. Keep it up!
Vinicius: Yes, keep doing the good work. You are the heroes. But definitely, yes. Hopefully they will manage to win over the product manager and show, again, talk about the two sides of the coin, the user experience, but also the developer experience.
Tanner: Because there are still some APIs that we’re looking for to get.
Vinicius: Absolutely. And there is the whole thing on, I mean, ultimately also, like, you can get very, very political and very technical on how user choice matters as well when it comes to that. And, you know, progressing the web development, and the web in general, on a much less controlled and stricter way. And you can get very political and democratic and technical on that part.
Tanner: Right.
Vinicius: But yeah, so like when it comes to developing for the mobile web…
Tanner: Not everybody has it.
Vinicius: Exactly. For developing for the mobile web, it becomes kind of back into the old days in a way. Because even on the Android world, like iOS is pretty good at catching up with the newest versions, but Android not so much. And then you’re still kind of like, you have some older versions of Chromium running on older versions of Android. So it’s kind of still a lot of reminiscent of the back in the old days when it comes to that browser support area, and having to check things, and some APIs are not available and all of that stuff.
Vinicius: So it is a different way of building for the web as most modern people that only builds for desktop, or mostly for desktop, would think about.
Tanner: So tell me about this play button then. What is so hard about making a play button work on a mobile web player?
Vinicius: Well, for most developers who are not aware of the intricacies, it’s not because of the technical challenges. Of course, we have a great API for audio playback and all of that stuff. But when it comes to the legal aspect of the whole…
Tanner: Interesting.
Vinicius: Yeah, of course. Like you have, because Spotify has encrypted audio and it has different licenses that you have to be aware of.
Tanner: Wow, so if I go, I open the mobile web player on my Android phone, and I hit that play button, you’re telling me that it’s going out and talking to a lawyer. It’s checking all these different things to make sure that I’m allowed to play this song within milliseconds before it begins playing.
Vinicius: In a way, yes, that kind of is what happens.
Tanner: That’s wild, man.
Vinicius: Yeah, it’s quite mind opening. There is, there are different flowcharts on how the play button behaves in different states that would make an engineer kind of like second guess any other application in the world. Like, “Oh, then how does even Slack messages work nowadays? Because I thought it was just making a POST request.”
Tanner: Right, right. You thought working on a nuclear reactor was hard? Try the play button in Spotify.
Vinicius: Exactly.
Tanner: Yeah. I think that’s such a great one, though, because you brought up, like immediately, “Well, there are a lot of legal things that we have to figure out.” There’s so many other things that impact the performance of whatever you’re building. I mean, one of the first ones that comes up, and we talked about it, slicing data, is there are users all over the place. Everybody has a different experience, different devices, connections. My power goes out, I don’t have fast fiber anymore. But like, there’s also legal aspects. What are other things? And maybe there are some other surprises we could talk about, but are there other areas that you find, you know, “These are actually really important impacts and factors on performance”?
Vinicius: There are. I mean, there are always also, like, business requirements that you have to take care of and whatnot. But when it comes to impacting performance, it’s kind of an eternal tug of war on how much you ship that really matters versus how much you have to ship because of, you know, business logic or things that you want to upsell from that point and whatnot.
Vinicius: So it’s kind of an eternal tug of war on how… In theory, you always want to send the least amount of code down the pipe. But there is always the thing where you need to make sure to send to making more and more features, because you know how you want to make the users happy and keep shipping new things.
Vinicius: And that’s where performance work becomes really important. So to understanding, “Okay, what is the minimal, like the smallest subset of features and code that I can package it up and serve at that one point?” And then you, and then like, “Oh!” From that moment onwards you will lazy load, prefetch, and like all of those buzzwords, right? Like lazy load, prefetch, preconnect, and eager fetch some things, and bump up the fetch priority on certain things like LCP images.
Tanner: So you don’t just load the whole application right out the gate?
Vinicius: No, no. So to this day, I still remember back in Klarna, where I actually ended up creating an internal talk about it just because I was kind of stupefied on the results. But like, how code splitting is definitely not a exact science. It’s like, you can have too much code splitting, you can have too little, and you can have everything in between.
Vinicius: And then you also have to understand what parts of your application goes down the pipe, at what times, and you know. Because performance, again, your entire JavaScript is single threaded, so you want to make sure that you ship the smallest subset of things first, but also make sure that they fully parse and render and the application is fully functional and responding to input within a few seconds.
Vinicius: And from that moment onwards you want to make sure that you prefetch, or let’s say warm up, as much of your application beforehand as you can. And there are different strategies for all of that. And yeah, it’s…
Tanner: Can you walk me through that? Because you gave a talk on this, yeah?
Vinicius: Yes, yes. So, I mean, the whole process came to be because I was moving to another team where we were doing a greenfield project to create a shipping feature set that was going to be part of the checkout experience for some merchants that would choose to have Klarna as the shipping and tracking end of their products.
Vinicius: So for that, again, we were kind of like a vendor within a vendor because we were a module for the checkout, right? And again, we wanted to make sure that we ship the least amount of code because if the user never clicks the shipping button, it would never show. So we don’t want to include everything into the bundle and we won’t include all of that stuff. We want to include the smallest amount of code that will enable that button to function as fast as possible. And from there we can load the full experience.
Tanner: Yeah.
Vinicius: So I did the whole code splitting first, right? So I split out everything. So I chunked everything, and async import a lot of stuff, and created a whole like, “Ok, I will chunk things.” And it’s sort of like, “This is the index,” and then from the index I will chunk the routes and then whatnot.
Vinicius: And it turns out that I was, like, in the end, when that first version came out and ran from our pipelines and whatnot, we were worse than just shipping all the bundle.
Tanner: Really?
Vinicius: It’s just because of the sheer amount of pressure on the CPU, on to having to download and parse, and download and parse, and download and parse. Exactly. So even with HTTP/2…
Tanner: Yeah, did you find this out with, did you have like a RUM dashboard or something that alerted you all? Or was it your lab tests that caught it?
Vinicius: No, that was lab. Yeah, lab tests got it because we started seeing that our, like, the early painting and the First Paint, First Contentful Paint, and our TTI (which now is being deprecated as a metric but back then it was one of the points that we could point to) was getting worse, especially TTI was getting a lot worse.
Vinicius: And the thing is that, that’s why code splitting is not an exact science. Because, especially when you think about mobile users on a 3G connection, HTTPS handshake alone can take up to 300 milliseconds. So you’re talking about a lot of overhead. So if you ship a lot of chunks, you’re talking about a lot of overhead, building that HTTPS connection, of course, can be mitigated with HTTP/2 and whatnot, but still, right? You’re talking about downloading different chunks and parsing different chunks on a very memory- and CPU-limited device.
Tanner: It sounds almost like trying to focus on a task. Like instead of just doing everything all in one go, you kept interrupting me every five minutes and I couldn’t focus and I spent more energy trying to make it happen.
Vinicius: Yes, so the CPU takes a lot longer to actually be free and available. After doing that, I understood that I would have to create different priorities for different chunks. So I would have my app shell, which back then we were, like, that was the beginning of the whole app shell concept, so I would have the app shell with the absolutely smallest amount of code down on the pipe. And like, inline CSS and everything that I could do to just ship the most static version of that thing. I would just basically have, you know, like event handlers and…
Tanner: We’re gonna show that button and have it right there.
Vinicius: We want to show that button, the button will be functional within as few seconds as possible. And from that point, the main bundle would then have a subset of chunks with priorities, where we knew that if the user click on a button we would want to render a certain screen, a certain part of the flow. So that would naturally become our highest priority chunk to prefetch.
Vinicius: And from that point, any other chunk would be lazy fetched. So they would only have to be downloaded if that we would have to find ourselves into that part of the flow. So then that’s where you start thinking about your transitions and load screens and, like, how do you transition from one state to another. But yeah, that became a whole experiment on fine tuning and finding the balance on how much I send versus how much I have to, I can wait and send lazily down on the pipe.
Tanner: Interesting. And it sounds too, like when you’re lazily loading things, you’re doing kind of a dance here. “I’m going to wait and see if the user clicks the button. If they click the button, then I can start to load the next thing. I’m gonna hold until I see the next move.” Like is that, you’re starting to orchestrate some events that happen before you load the next thing?
Vinicius: Yeah, you start orchestrating the events to happen based on your user flows. So you, I mean, if you’re talking about a full-scale application, then you have, of course, different kinds of way of treating this kind of stuff, like per route and whatnot, right? And even within the route, you have the different sections of your application that can be loaded on different strategies.
Vinicius: But when it comes to that application that we were building back then, it became about our user flow, the user flow and the user journey. So whenever the button’s fully loaded and ready, then the next page would be eagerly fetched, prefetched, and then from that next page, the moment the next page hits, the next page would try to prefetch the next step. And like some parts of the next step that are, like… Because you always have business logic and conditions like, “Oh, if this happened that.” Then whatever is always the most common flow becomes like an eager fetch and the rest becomes a lazy fetch, like all that stuff to try to prioritize and mitigate all the overheads around trying to download things too eagerly.
Tanner: Yeah. Man, how do you learn how to do all this stuff? Like is this all trial and error that you’re just, “Let’s figure it out on the job”? Or do you have places you’re going, people, like how do you learn stuff?
Vinicius: Well, that is a great question. So I’m very lucky to have worked with very clever people around me that would help me question those things and come to realizations that I now have. And it’s a lot of experimentation, a lot of trial and error, a lot of going to conventions and talking to smarter people than you, and exchanging ideas and processes. And yeah, it’s like really not being afraid to fail, and not being afraid to look at the data and understand what’s happening also.
Vinicius: So like, “Why did I fail now? Why is it slower?” And really get to the bottom of it, of why is it slower. Really, why is it? And understand what different factors might incur. And yeah, from that it’s trying different things, see what sticks.
Tanner: Are there any particular resources that you’d recommend for people if they were trying to learn web performance now, or getting in for the first time?
Vinicius: Definitely. There is a lot of the Google developer videos out there, that they deal with the developer tooling. Even the older Google developer videos, like understanding the flame graph and understanding the profiler and all of that stuff, definitely helps to understand some of the things. Like videos about Lighthouse I saw from them, and a lot of talks that you can look around for of other people like Paul Irish and Paul Lewis and, you know, like all of those trailblazers that brought us where we currently are on tooling definitely helps as well.
Tanner: Nice. Alright, two places I think we could go next and then we can wrap it up. On the one hand, I feel like there’s a lot of parallels and overlaps between performance and other aspects, you know, even security and accessibility. And then on the other hand, hey, if you went back to 2012, what would you tell yourself from a decade ago? So there’s my two: comparing performance and other aspects, and what would you tell yourself ten years ago?
Vinicius: Right. So when it comes to comparing performance to the different aspects, I would say it boils down to user experience. They kind of are different facets of the same thing. So it’s like a dice, right? It has different sides, but the sum of the whole is user experience. So how reliable is your user experience? How, in all different fronts really, like is it going to reliably load fast to me? Is it going to reliably work without problems? Is it going to give me good user experience if I am a person with a screen reader? And all of that matters, and all of that is about the user experience.
Vinicius: So it really boils down to that. That’s why I’m like, it’s where it all started for me, back into all of those years back then, where I really was keen on understanding user experience as much as I could. And it kind of naturally evolved into performance, because it kind of is part of user experience as a whole.
Vinicius: And when it comes to the other question, I think if I would be able to meet my younger self, I would definitely tell him to just, you know, take your time understanding things, the basics first, as always. Because I actually had the opportunity and pleasure to mentor a bit myself. I mentored my brother. He was on a law career that shifted to development, and I helped, and I mentored him alongside of his whole university course and all. And it is the advice I gave him, and I would give my younger self the same, where the basics, the fundamentals matter a lot, and it’s where you build your whole knowledge on top of.
Tanner: Fantastic. Vinicius, I really appreciate you taking the time. It’s been a great time talking.
Vinicius: Yeah, it was awesome.
Tanner: I hope we get to do this again.
Vinicius: Absolutely. Yeah, hit me up.
Tanner: Yeah. Well, thanks so much for coming on the show, and until next time.
Vinicius: Yeah, take care.

Recent Posts

Archives

Categories

Links

Video

Transcript

Leave a Reply Cancel reply