Karolina Szczur - Catching Up With Web Performance

Catching Up With Web Performance

Karolina Szczur

00:00 / 40:41

Video

Transcript

Tanner: Hello, everybody, and welcome to Catching Up With Web Performance, a podcast about stories of people in web performance. Today my very special guest is Karolina Szczur.
Karolina: Hi everyone.
Tanner: I’m going out on a limb here. Did I get it even halfway pronounced right?
Karolina: Yeah, you’re, you’re doing well.
Tanner: Good start. Karolina, how’s it going?
Karolina: Pretty good. I had two coffees so, you know, I’m ready to be talking about web performance.
Tanner: Oh my god, me too. Actually, what I’m really excited about is to hear all about you. Because you, I feel like you are one of the few people who really has a pulse on the performance world, because you run the Perf Newsletter, Perf.Email. Like, I dunno, do you feel that way? Do you feel like you are the wise sage that I picture you as in my mind?
Karolina: Like a wise wizard. I mean, I try to keep up with everything that’s happening, obviously. Performance Newsletter is one of the reasons, another reason is actually running a web performance monitoring platform. Do I know everything? Don’t think so, but I try to keep up with it and, you know, share that with the community.
Tanner: Well then, let’s dive in here, because I want to know how you even got into all of this, you know, this newsletter, this product, Calibre, amazing product. How did you get started? How did you become the wizard behind the curtains?
Karolina: The wizard… the Witch of Web Performance. That’s a good question. I’ve been thinking about this question since the original email from you. And I was like, “Was there a moment?” Was there like a distinct memory that I could think about when I’d have my “aha” moment about what performance? And I frankly could not think of like a single thing that switched me on to it.
Tanner: Not a one.
Karolina: Not a one, because I think it’s a bit bigger than just a single moment or, I don’t know, a job or anything like this. So I think, in terms of my background, I studied human–computer interaction back in Poland, where I’m originally from. And I’ve kind of even, before then, I was interested in creative, in photography, in the bridge between humans and computers, to be very kind of straightforward with it. We didn’t discuss web performance during my time there. We discussed accessibility. We had Ruby, Pascal, Lisp, psychology, sociology, like all sorts of things. It was like a very intense kind of random but amazing mix of knowledge that I received there. Which kind of steered me onto the—well I was interested in web design before, I was doing web design even before I joined—but it really gave me that kind of holistic understanding of Web as a platform and kind of emphasized that for me. So from there, and kind of understand that good design is a little bit more than just visuals, I started focusing, especially when working as a designer and frontend developer, on accessibility and web performance. And that’s way before the time when we had a lot of web performance resources. So long-winded answer…
Tanner: Around what time was that?
Karolina: Oh boy… 2012? 10? Like 12 years ago, 14 years ago.
Tanner: The end of the world, 2012, great year.
Karolina: Yeah, yeah. So it was a while ago. But I think for me, when I think about web performance as an interest, it’s just something that stems from that understanding of design and user experience and what the pillars of it are, and how do we get there on the Web. And web performance just made sense, in the same way that accessibility does, or good visual design or good content.
Tanner: So you were, you got a degree in human–computer interaction, this wild mix of computing but also psychology. Plus photography, so you have that creative side. And you’re doing, when you graduated and started your career, you were both design, like graphic design, and frontend development? Like mixing both the creative and the code there?
Karolina: Yeah, I always worked, I always gravitated towards design. I was a kind of “OG designer”. But I always, since the beginning, when I had access to the internet—sorry to my parents for the bills.
Tanner: It was worth it!
Karolina: Dial-up time. It was worth it. You know, inspecting the source, trying to build your own things, try to find out how it works. And I always believed that it was kind of crucial to not only success of designer but like good design, to understand how it actually interacts and how, for me to actually be able to build it, at least a prototype. Of course, that’s a little bit more complex now in kind of the JavaScript world, where frontend is very different than was 10–15 years ago.
Karolina: But yeah, I was always working at the intersection. And one of my first jobs, it was kind of like an agency that was doing design to HTML kind of stuff. And we had lots of checklists for, you know, is your code valid, is this, we had checklists for pretty much quality assurance. And there was a lot of stuff surrounding accessibility and quality and web performance, maybe without those names because it was a little bit kind of too early in those days.
Tanner: Do you remember some of the things you were checking? Like I assume, were you checking file size? You know, pre perf, uh, what do you call it, bundle size or perf budget.
Karolina: Yeah, size was important. Validity of HTML, which now some people laugh at.
Tanner: No!
Karolina: Well some do. That’s not my opinion, but you know. Yeah, so kind of that approach to maintaining standards and quality assurance. I also did work briefly in quality assurance, so again like all of this comes together.
Tanner: Really?
Karolina: Yeah, very briefly, but I did work as a QA tester.
Tanner: What was that like? I dunno, we don’t have to spend too much time but I’m curious, yeah, what was that like jumping in there?
Karolina: I mean, it did feel natural to me because I always worked with smaller teams, so I always did it by myself without even someone asking me or having like organizational support or kind of structures for me to do so. Like, it just makes sense. Yeah, I’m gonna test my work, of course. Like make sure that it’s up to scratch. But yeah, it was interesting because it was kind of full-time for a while dedicated to, you know, just making sure that all of those things are in place and collaborating with developers on getting them addressed in terms of any discrepancies or failures and improvements that could be made. So yeah, I would say a lot of experience across the entire like design to development to shipping spectrum, which is very helpful when you work at a small product company.
Tanner: I bet. So tell me more about this slow build. Because, you know, you’ve started, you have all these little, there are a lot of, it sounds like there are a lot of seeds being planted along the way. I have those creative elements, code, even quality, like the notion of quality assurance, you have a stint being a site tester. Where do you feel like, you know, I’m picturing a snowball, it’s starting to build, where does it start to, maybe this is jumping ahead too far, but where does it start to reach kind of critical mass for you?
Karolina: Oh boy. Is that a question about, like, how did I join Calibre?
Tanner: Well, if I’m not mistaken, I believe you’re labeled as the co-founder?
Karolina: Yes, yes.
Tanner: How did that happen?
Karolina: Ah, it’s a romance story.
Tanner: Yes! All good performance stories are love stories.
Karolina: Yes, love stories. I mean, to be completely transparent, I met Ben at CSSconf Europe, in Berlin, where I was doing the closing keynote, I think back in 2014, and we’ve seen each other since at different conferences. We were both in our conference phase at the time, speaking a lot and traveling. And then we both went to CSSconf Asia, and then I came to Melbourne for CSSconf Australia, and it kind of just happened. I was at the time working, I don’t even remember where I was working, I think maybe as a frontend engineer or a split of frontend and design. But as it happened, I randomly kind of visited Australia and then stayed, and seven years later I’m a citizen.
Tanner: Wow.
Karolina: Things happened like this.
Tanner: One thing led to another.
Karolina: Yes, I didn’t join Calibre initially. I think since 2017 Ben has been bootstrapping Calibre, just kind of working on it as a side project, and then decided to give it a go full-time. He saw the potential and wanted to see like, “Can I take it to a full-fledged business?” Of course, within the tangents of not taking venture capital. So a difficult journey, but he wanted to try. As a partner, obviously when somebody is running, I guess you could call it a startup, or a business on the side, you know that you’re always end up helping in one way or another. I think one of my first projects was running Perf.Email. I don’t remember which issue it was, 14 or 16, when I took over Perf.Email from Ben and I started running it. But that was way before my time when I joined the company. I actually joined full-time like nearly three years ago. So not that long ago in the company timeline, because the company has been around for like seven years.
Tanner: Wow, that’s crazy. So Ben has this great idea, “I’m gonna make this thing called Calibre.” And he starts it, dives right in, and you just kind of naturally end up helping. And one of the first things that you start helping with is the newsletter. That’s fascinating. What are some of the things that people are writing about? What are the stories that you’re collecting and sharing at that time?
Karolina: That’s a really good question. So maybe I will answer it from kind of like top level, where I see it now and where it was back then. I actually don’t recall, maybe we started as a monthly cadence, but even with that cadence, just once a month, it was quite difficult to gather high quality resources about web performance. We ended up to, you know, include kind of tangential topics. Like we always wanted to include accessibility a little bit, because to me it’s kind of like a sister subject, but we definitely didn’t find as much content as we hoped to. At some point, when the amount of content increased, we switched to every two weeks because we wanted to share more, but it really fluctuated.
Karolina: One thing that I definitely observed is that back in the day there was way less content about JavaScript optimization, which is just kind of getting back to the journey of frontend and where it is right now. So like we went from, you know, HTML and CSS to CSS in JS and everything being built in JavaScript. So that content is exploding right now, those resources. And it’s definitely way easier to find resources about web performance now than it was even two years ago. There’s way more resources in terms of talks, podcasts, articles. There’s way more interest. That doesn’t mean that all of it is high quality, there’s a lot of low quality content, but there’s definitely way more interest, including case studies as well. And I think one of the reasons why is the decision about Core Web Vitals. So making Core Web Vitals a ranking factor, like that has been a huge line in sand when a lot of people who weren’t interested in web performance suddenly were like, “Oh, we gotta pay attention to that now.”
Tanner: Right, that totally. So then, I mean, you were into performance before performance was cool. So what are, I guess, have there been any surprises? Or anything that you’ve noticed along the way, these trends, or things that have come up as you’ve been cataloging all these articles and seeing it become more popular?
Karolina: Surprises in content and surprises about ideas that people were sharing?
Tanner: Sure, or even your own, like as you’re trying to collect these.
Karolina: Oh boy, oh boy. Well, we could get into some really big subjects here.
Tanner: Let’s go.
Karolina: I mean, the web performance knowledge gap shows up a lot. There’s a lot of content that, and I’m not talking about like low quality copycat content, but genuine, someone who’s, or a company or an individual who seem to have some understanding of web performance, they aren’t just writing for SEO purposes or like links, not having the facts and not having the knowledge. And then those posts going viral and then people duplicating that content and that knowledge gap is widening in a way. Maybe “knowledge misconceptions” is a better term for that.
Tanner: Yeah, I was gonna ask because that sounds, and I don’t know if you’re able to bring any examples up, but is there a difference there between the gap and the misinformation?
Karolina: Yeah, but also sometimes it’s a Venn diagram. Like I think performance score and page speed are subjects that are definitely in that spectrum. It is fading a little bit now with Core Web Vitals but still quite present. So what you’re noticing is for a long time people thought that page speed score was what was contributing to the ranking, which was never true.
Tanner: Like that big Lighthouse score that said, “Oh, you got a 24” up at the top.
Karolina: Yes.
Tanner: Yep, I remember that.
Karolina: That’s still happening. That’s very much still happening. Less so, but that’s one of the things that is, you know, is being said over and over online still, and that is not helping people who don’t have the knowledge. So there’s like disinformation and knowledge gap at poles. Which isn’t helpful for people who are kind of panicking with Core Web Vitals and being like, “Okay, we have to get on it but I don’t fully understand the subject. But those people told me that this is what’s important.”
Tanner: Yeah.
Karolina: So a lot of work that I’m doing and we’re doing as a company is trying to help people in terms of educations through content or Perf Newsletter to our support channels. But there is also resistance. When something is so widely distributed as a fact, fighting that or saying that something, “Look, the performance score isn’t important.” Like that’s a hot take.
Tanner: Yeah, oh man. Yeah, are there other things that you’ve found difficulty going through? Feel free to take a tangent as well.
Karolina: Oh boy. Yes. Like difficulties with web performance specifically?
Tanner: Yeah.
Karolina: Yeah. So there are several kind of areas or buckets. There is lack of knowledge, which goes into kind of multiple sections, so like not understanding how the metrics are calculated. For example, a tangible example here would be the Largest Contentful Paint metric. People assume it’s an image but it could be text as well. So you see people saying like, “Oh, why is my LCP 7 seconds? The image loads at 2 seconds.” Well, because your LCP element is actually text and it loads way later because your web fonts aren’t optimized.
Karolina: There is difficulty understanding variability in web performance, which is a very hairy subject, and test reliability.
Tanner: Variability, what’s that?
Karolina: Yeah, try reading some resources about that. I mean, it is difficult to explain and it’s a difficult pill to swallow. You know, people expect that they can test web performance very fast and very reliably just like that and that the metrics will be fairly stable. But that is not true. There is an inherent variability in web performance, especially with Lighthouse. There is even a dedicated page to it that explains the types of variability and how severe it might be and what conditions it will show out. But again, that’s kind of very deep knowledge that many people don’t stumble upon.
Karolina: Similarly they don’t, like understanding that web performance differs on devices or differs per region. Why should you test in a distributed manner versus from a single location on iPhone 14 or whatever we’re up to? Or you know, your local MacBook just running Lighthouse. I got 70 there but, you know, on web.dev/measure I get 20. What’s happening?
Tanner: Metrics, variability, reliability. Are those kind of like the top three things you find yourself talking about over and over again?
Karolina: Yeah. Organizational buy-in as well. For example, an individual coming to us, or even as Calibre as a company or within the community, you have someone who is very passionate about web performance and accessibility and overall improving user experience, but they don’t get the time to spend on it, they cannot make that decision for themselves, their organization doesn’t care. How do you convince them? And then another step in that kind of Web Performance Maturity Model, hat tip Alex Russell, is actually setting up framework to have a team, to have people who are responsible for tracking that, who are responsible for the work that happens and ongoing efforts. So it’s not like we’ve done an audit once and now we’re kind of done with web performance.
Tanner: Right. It sounds like, I feel like you’re constantly just in this world explaining things. Are you normally, like, who are you talking to in all these conversations? Are these like developers having these problems, business people, analysts, like who? Yeah, I dunno.
Karolina: To be honest, all sorts of people. So on a tangent, I strongly believe that web performance should be something that is organizational, and anyone can be invested in it and anyone can care about it and make improvements, no matter their role. I don’t think this is something that we should gatekeep to developers. So that being said, in terms of who am I talking to about those kind of themes and issues, sure, they’re often developers, but they’re also quality assurance people, they’re data analysts, they’re SEOs, they’re product managers. They are CTOs, CEOs, product managers. So all sorts of roles across both product companies, agencies and e-commerce businesses, you name it. Like they’re, sure, you could say as a simplification, “It’s only developers who work on performance,” but it’s just not true. And I also don’t want it to be true.
Tanner: Yeah. I guess, is there a perfect world? Do you have, can you dream up a utopia here? Like what, in a perfect world of web performance, what would that look like or what would you see there being?
Karolina: Good question. Perfect world… First thing that comes to mind would be firstly, web performance starts with day one. It’s not something that, you know, is kind of tailored with the quality assurance approach at the very end. When you’re ready with your product, or your features ship, and then you look at web performance, accessibility, and any other checks that you might have, and like passes or it doesn’t pass, it’s kind of too late, we just run some checks and go further to release. Like it’s not, it shouldn’t be something that is last on the list. You’re not going to be successful with that. You have to start with that strategy. The same as you strategize like what features should we build, what products should we build, is this the right thing to be doing? You should be starting with accessibility, UX, and web performance in mind at the very beginning. So in an ideal world that starts at the very inception of a project. That’s one thing.
Karolina: Second thing is what we already discussed, which is organizational buy-in. So everyone knows what web performance is and at least kind of core characteristics, what it means, what is it influenced by and how we can make it better, and make sure that it’s continually kept at a certain baseline. Who owns those baselines? What are they? What are our goals? How do we go from there? So yeah, having the knowledge across the team and organization, having shared goals, someone who is responsible for those goals and reviewing them on a kind of quarterly basis, someone who’s like the steward of web performance. And that could be a team, that could be a person, probably a team, especially in bigger organizations.
Tanner: Yeah, I’m curious about that. Have you noticed any differences between big organizations and small teams?
Karolina: I mean, there are many differences, but what I find interesting is… So I like to talk about the kind of defensive, or reactive, approach to performance and proactive approach to performance. So to me, a proactive approach to performance is like we start day one with web performance when you kick off a project. You have a speed team, you know what the responsibilities are, you have systems in place to monitor, you have goals, you have performance budgets and all of those tools that we frequently talk about. And I just lost track of my thought…
Tanner: Differences between big companies and small companies. It sounds like you’re talking about a big company that day one, we’ve got a speed team, we’re ready to go.
Karolina: Yeah, we’re ready to go. We have that framework. We might even have multiple speed teams. But still, instead of preventing issues from happening, we see like, “Oh, a budget was blown for LCP by a lot. Let’s go and fix it eventually.” So that’s a kind of reactive approach to web performance. Ideally, in a proactive approach, you still have the organizational framework, you still have the knowledge and responsibility and alerting, but you test before you deploy to production. You make sure that, you know, you experiment, you make sure that regressions don’t happen. Obviously, they probably inevitably will happen, especially at scale. But by default, your approach is proactive versus waiting for an alert and then reacting to it when, you know, a cycle in our, I don’t know, development team allows us to. So the difference that you can see is when you think about big organizations that can have multiple of those speed teams, that their full-time jobs are web performance, which is like amazing amount of time and resources that you have, they still employ that reactive approach, not proactive. Like it’s just not, we’re not there as a community.
Tanner: Yeah, in a weird way it almost feels like how could a separate team be proactive instead of reactive? If you offload the responsibility of performance to an explicit team, it’s their job, they do it. I dunno, I’m trying to picture what a proactive performance team would look like.
Karolina: Yeah.
Tanner: Unless you’re embedded within every team. You know what I mean? That’s interesting.
Karolina: Yeah, I think…
Tanner: That’s interesting.
Karolina: I mean, obviously, like if you assign it, especially in like hundreds or thousands of people organization, to five people, that’s not gonna work. That’s just not gonna scale. So it would be… I think the question here is twofold. So one part is what you just mentioned, which is like this doesn’t scale if you have just a small team responsible for web performance. But another thing is that the tools aren’t quite there, which is something that we’re working on. So one of the things that we’ve built a while ago and we’re working on improving is a feature called Pull Request Reviews. And what it does is you connect it to your repositories and Calibre will test your staging, working environment and will give you performance metrics. Of course, having that one-to-one to your production is difficult, it is difficult to set it up that way, but still we regularly run performance experiments using that feature to see if we can improve something. So that would be an example of a tool that allows you to, you know, in connection that connects with performance budgets as well, to be a little bit more proactive versus “I just deployed this code and let’s wait for the charts.”
Tanner: Right.
Karolina: So I think one of the issues why we’re not being proactive is not only kind of the performance culture, but just also the tooling that isn’t quite there. For multiple reasons, like products not building, you know, companies not building those features. But also some of those difficulties in web performance, such as variability or importance of having the same settings to have, you know, regular kind of results that aren’t different due to setup, is a difficulty to build those kind of proactive systems.
Tanner: Yeah. I’m gonna counter tangent you. Have there been any features like that? Maybe what things about Calibre have you seen really resonate with people? Have there been things that you were like, “Oh, I didn’t think that was super useful and people just, wow, were really into it”? Or vice versa, something you thought would be great and it didn’t land quite as much as you thought.
Karolina: I think in terms of what I thought would be cool and what I think people think is cool, is Third Party tracking. So surfacing third party information in terms of tracking web performance. As we know, third parties are huge, there’s barely any website that doesn’t have any third-party tools or scripts. My personal doesn’t, so that’s something. But you know, there are some where you will see a hundred third parties that have like 10 megabytes of JavaScript, 90% of main thread activity. And nobody, or not a lot of tools are visualizing this information. So we thought that was critical to, as soon as this information became available for us to visualize, we visualize it to kind of bring forward how third parties are impacting user experience and web performance. And in that way you can use other tools such as, I don’t know, bundle analysis, or you can choose different alternative libraries. You know, there were a lot of people talking about the Moment library and how heavy it is and we should use other libraries because they’re not as intensive. So that’s one of examples. But yeah, that’s definitely a feature that has resonated with people and I really personally like it. And I’m actually currently developing its visualizations further, thinking how, you know, what is other information that we could show to people to help them make better web performance choices.
Karolina: One of the things that I’m really interested in is kind of environmental impact, which is something that’s very, very difficult still to calculate or have reliable resources on.
Tanner: Yeah, how do you even do that?
Karolina: There are some projects with reliable data, and I’m currently exploring if we can build them into the platform. So for example, you could see if the third parties that you’re using are green. Of course, again, this is a little bit like, I feel about it a little bit like about carbon offsets. So like, are you really offsetting or is this just a marketing ploy? So before we decide to build something like that in, we really have to make sure that the data is real and credible and that we can give signals to people that will be valuable. There are a few interesting projects in that space that I’m blanking on the names on, but I’ve looked at them and currently evaluating. So I think, you know, as we transfer more data, as there’s more compute, we should definitely be thinking about web performance from the environment standpoint as well. Just because we can transfer all of that, and we can have more servers and more machines, doesn’t mean that we should.
Tanner: Right. I think we should just mine Bitcoin on all of our websites, don’t you? Why not.
Karolina: I mean, why not. Doing it right now, gonna make a little pull request.
Tanner: No… Yeah, that’s really interesting. Going back to the Third Party feature being one of the things that, “Oh wow,” I didn’t, this was… It was something I couldn’t see before. I had no idea how much these third-party pixels impacted, or these third-party scripts impacted, my site. And now all the sudden you’ve shined a light in a dark corner that, “Woah, I can see this.” It makes me think of what you mentioned earlier about like… You said you don’t think web performance should be all about developers. Could you tell me more about that? Like, I’m imagining that you picture a world where anybody can do this. I dunno.
Karolina: I mean, I think saying like…
Tanner: Let me rephrase. Well, nah, I dunno, run with it. Let’s go.
Karolina: Go on. I mean, you can say, like, I definitely don’t think, like, okay… Can anyone work on web performance? I think the answer is yes.
Tanner: Tell me more.
Karolina: Should everyone work on web performance? Yes. Of course, there are different ways to work on it. You know, when we talk about web performance you, I feel like a lot of people by default think about, we think about developers who are setting up those very developer forward tools. You know, command line scripts, integrations, even tools like Calibre, like there’s a lot there. There’s a lot of data, there’s a lot of charting, you have to understand what’s what. It’s a big challenge and a hurdle to come into that world and understand what’s important, understand how you can contribute to it.
Karolina: So to answer that in a roundabout way, is a lot of web performance work done by developers? Yes, because you do have to dive into code, you do have to run optimizations. But that doesn’t mean that anyone else cannot be involved. For example, I wrote articles about web performance for designers, which is very close to my heart as a designer. You know, you can make choices about how many fonts you have in your product. You can make choices about the size of imagery. You can make choices about animation. Like there are a lot of design choices that you can make for web performance, for better or for worse.
Karolina: The same with PMs or quality assurance folks, like there are decisions and procedures that they can create to foster for web performance. So why should we, like, even if developers are the people who are executing on improving web performance, like they’re physically writing the code, improving the code, creating automatic tools like compressing images in pull requests, stuff like that. Sure. But someone has to strategically make this decision. Someone has to allocate a team or say, “In this sprint, we’re doing that.”
Karolina: And how is that possible if we only have developers who are usually, and especially in bigger teams, not decision makers advocating for it? Like we need organizational buy-in. That’s why to me, everyone should be and can be invested in web performance. I have seen so many people, who are not in development at all, excel at web performance at their organizations and, you know, personally having deep understanding, or even a more shallow understanding, but being on it in a way like, “These are our goals, this is what we’re going towards, and I know where we’re going.”
Tanner: Do you have any of those people or examples that maybe come to mind of somebody who wasn’t a developer, but man, they were good at what performance?
Karolina: Oh, yeah. I mean, obviously I’m not going to disclose names or companies, but like I know people who are SEOs who analyze the data, for example, that they pull from Calibre and like amazing spreadsheets and charting that they’ve created for their organization. And they get onto every single change that is happening. And, you know, they dig through like, “Why is this happening?” So it really does not have to be closed off to web development just because it’s the execution kind of vector of web performance.
Tanner: Yeah. It also makes me think of how first of all, it’s like, we need this. We need more than just us talking about performance. Having, for example, the SEOs. If I know that they’re the person who are checking in on this too, like there’s another voice. I need more voices pooling together in this to share knowledge, clear out disinformation, and advocating for it.
Tanner: The flip side, which I think is funny, even in my own personal story of performance, a lot of times like, I don’t know what to say. I don’t know how to talk about this. You know? And I find myself at a loss a lot of times trying to say… I feel like so often we just resort to, “You should care!” Right? Like the developer comes into the room and says, “You should care more,” and that’s it. And it sounds like, in a way, by trying to equip non-developers, you’re lending that missing voice or those missing words, that missing… I’m not even sure how to articulate this, but do you kind of get what I’m saying?
Karolina: Yeah, I totally get what you’re saying. I mean, one thing is like, you know, trying to convince people. So if somebody comes in like, “You should do this.” Why? Especially from a business perspective, like if someone comes to a manager, or I dunno, a CTO, and say like, “We should do this.” Like it’s inevitable that they will ask, “Why?” What are the outcomes? What are the risks? What are the benefits? Like, we need more facts. And actually, you know, having have written so much content in web performance space, finding facts and writing a very data-driven, legit content about web performance is weeks of research on just one post. And the majority of content that we have, or like, yeah, the majority, is not that. It’s like low level content. Which is fine because it still educates people, it brings important subjects, optimization, I dunno, imagery and whatnot. But to talk about web performance very confidently with data and research, there are very few people who can do this. And often that language is so complex, and so riddled with terminology and biases and assumptions, that it’s really hard to make other people who aren’t within that zone buy it.
Tanner: Yeah.
Karolina: So knowledge gap and also language, the way we talked about web performance. If we talk in deeply specialized terms—”technical”—that is not going to widen our audience. This is one of the content and voice and tone goals for me as someone who, you know, kind of stewards over web performance, the Perf Newsletter and also our content Calibre, is that we, as much as our content has to be, out of the lack of a better word, technical and for an audience that will be implementing it, I also want people who are newcomers, who might not be developers, to get an understanding based on this content. So it’s a very difficult kind of friction between deeply complex but, you know. Kind of like good design. Good design is invisible. It’s kind of the same vibe.
Tanner: Yeah. Do you have… I’ve made it a pet project to try and collect metaphors of how to talk about this. Do you find different, like, how do you find yourself talking about web performance? How do you talk about, or maybe, how do you non-technically talk about performance?
Karolina: There are a few kind of concrete ways that I do it, especially in writing. Acronyms is something that I usually avoid because it’s just assuming that somebody has that knowledge. And there are a lot of acronyms in web performance just in metrics alone. An approach of not assuming previous knowledge, as in somebody should know what performance score calculation is or, you know, how Interaction to Next Paint works. Usually in my writing, I try to like backtrack and say, “This metric captures this and this metric is important for this other metric,” which is a bit of a roundabout way to talk about something, but at least it makes sure that, you know… And also cross-linking feeds into that, crossing into other resources. But it makes sure that I’m not assuming that somebody already has this knowledge.
Tanner: Right.
Karolina: Avoiding jargon, explaining terms, avoiding acronyms. Analogies, like you said, are also a good thing, kind of real life analogies. Which is also a reason why all of our blog post illustrations are like real life hilarious situations. Like our Total Blocking Time article is just like this guy on a pier and like flamingo and he missed the boat and, you know, things like that. The article that is upcoming I think today is about unexpected benefits of web performance monitoring, and it’s a magician with a hat and out of the hat there comes another magician with a hat. So I do like analogies. And I do like being kind of plain spoken, especially in so-called technical writing, to make sure it’s more accessible.
Tanner: Yeah. You mentioned “why” earlier. I’m curious, like, why do we do this? Why do you do this? What inspires you to keep going, keep writing, keep sharing?
Karolina: Why do I work on web personas or why do I write specifically?
Tanner: Let’s go both.
Karolina: Oh, twofold answer. Alright. Why do we keep sharing. Both me and Ben come from kind of open source backgrounds. Ben worked on some high profile open source projects such as Bower back in the day. Major shoutout to back in the days.
Tanner: Rest in peace.
Karolina: We both spoke at conferences extensively. We both ran conferences extensively. So kind of that giving to the community vibe was always there for us in our kind of like professional careers. I have many opinions about how to run a company, which is why I’m running my own instead of working for somebody. And one of it is, you know, like there’s a lot of marketing out there, there’s a lot of content that’s definitely written for marketing. Which is fine, like, you kind of have to. I don’t have anything against it. But I do legitimately want to share free tools and knowledge with people so they can understand web performance and contribute to it at their organization, or personally, on their personal website, within their own projects, no matter their role.
Karolina: I’m one of those kind of idealistic “let’s bring back the old internet” people where, you know, in my dreams, I see a fast, accessible, ad free, tracking surveillance free, privacy forward, security forward internet that we all enjoy using, and we all can access in a way that isn’t prohibitive because of our settings, such as socioeconomic situation, our devices, how much money we can spend on a plan or can’t, and those factors. So this is kind of the pillar that I, the value that I think about when I think about web performance, building Calibre as a company, doing Performance Newsletter or any free tools that we have, giving back and creating a better internet. Of course, web performance is just a tiny fraction of it, but I think kind of in unison with accessibility, privacy, security, these are the values that I want to see. Or I just want to log off. So I might as well, you know, go and try to foster that through our company, through our resources, hopefully towards a bigger audience.
Tanner: Well, I’m excited to be along for the ride. I hope we see the performance community thrive and the Web grow even better and better and we see that one day.
Karolina: I hope so, too.
Tanner: Karolina, it has been such a great time talking. I wish we could talk for another 10 hours. Oh man. So how do people keep up with you? How do people follow Calibre and see what comes next out of your work?
Karolina: Sure. Well, you can sign up for Performance Newsletter at Perf.Email if you would like to get some web perf news every two weeks sent to your inbox.
Tanner: Yes, please.
Karolina: I’ve been told it’s pretty good, but what do I know? I run it so don’t ask me.
Tanner: It’s the best.
Karolina: Thank you. And if you’re into free tools, you could use our Core Web Vitals Checker, which checks any public URL for your Core Web Vitals data from Chrome User Experience Report so you don’t have to build anything for that by yourself, because why would you? You can use our Image Actions action, which will automatically compress images in your PRs, which is pretty magical and sweet. Or, if you’re using any live chat tools, you can use React Live Chat Loader, which will help you offload the web performance impact in the negative spectrum of those live chat tools. So some freebies.
Tanner: So much good stuff. Thanks again so much, Karolina, and until next time.
Karolina: Thank you.

Recent Posts

Archives

Categories

Links

Video

Transcript

Leave a Reply Cancel reply