Jack Franklin - Catching Up With Web Performance

Catching Up With Web Performance

Jack Franklin

00:00 / 38:06

Video

Transcript

Tanner: Hello, everybody, and welcome to Catching Up With Web Performance, a podcast about stories of people in web performance. Today my special guest is Jack Franklin. Jack, how’s it going?
Jack: Hey, I’m good, thank you. How are you doing?
Tanner: I’m good. You know, trying to take notes, get ready for the day, and then hear more about people’s stories. And what, actually, I’m glad you’re here because I want to hear more about you. Like, who is Jack Franklin? Can you remember, maybe if you go back, what’s your first web performance memory?
Jack: I think it was at a Chrome Developer Summit. Pff… we’re talking eight years ago-ish? Ish. Don’t quote me on that. And at the time I was a Chrome Developer Expert or Google Developer Expert, they call it, I think. So I didn’t work for Google then, but I was kind of part of this community of people. And yeah, I got to go to the Chrome Dev Summit in Mountain View. To be honest, at the time, it was my first ever trip to that area of the States and it was a handy excuse to go see San Francisco.
Jack: And yeah, I was at this Chrome Dev Summit and one of the talks was by a lovely man called Paul Lewis, who I think if we’re talking web performance a lot of people have come across Paul and some of the work he did, he used to work on Lighthouse, a bunch of web performance stuff. Yeah, don’t tell him I said it but cool guy, a lot of respect for him. And yeah, he did this really interesting talk about it and it just kind of got me thinking. I think it was something that, at the time I was working on a startup building sort of a web app, but I think in kind of classic startup situation, it was always hard to prioritize the performance aspect of it, I think… I can’t remember what, you know, it wasn’t React, it was before React, but whatever technology it was we were using on the frontend, performance was very much like an afterthought. And a small team, limited runway, needed to just move quickly and ship features and get users. So trying to, I remember taking some of the stuff from Paul’s talk and trying to apply it was was tricky. But from then I just, I think at that point I followed Paul on Twitter and found out more of the, like, Chrome and Google at the time were doing various blog posts about performance things, obviously lots of people outside of Google as well. And just kind of became a bit more interested.
Jack: From then, really, I did bits of it. So when I sort of changed jobs a couple of times, I tried to bring and think about performance a bit more. But I was very much a novice, in terms of, I’d load up the Performance panel and I’d do a trace and I’d like pretend I knew what I was doing, but I was still sort of stumbling a bit through the tools. So I did that for a while and then, yeah, then wound up working with Paul at Google.
Tanner: Wha??
Jack: Nearly three years ago I joined, which was obviously a kind of cool full circle type affair. I ran into him at a conference…
Tanner: Did you, I have to know, did you tell him? Did you, like, go up to Paul and say, like, “Paul, you got me started!”
Jack: I did, yeah, yeah. We chatted a few times. We chatted at a conference. But yeah, so that was, you know, really exciting for me to be asked to join the Chrome DevTools team. And at that point, that wasn’t to work on performance tooling, just to be on DevTools. Then maybe a year in, there was an opportunity to sort of start focusing on the performance tooling, and I kind of jumped at that along with Paul.
Jack: So yeah, for the last couple of years I’ve worked on performance tooling at Google on the Chrome DevTools team. So obviously, for us we focus primarily on the Performance panel that’s within DevTools, along with collaborating with the Lighthouse folks and all the other stuff that’s in the sort of web vitals performance tooling situation. So that’s now what I kind of spend my life doing, which has been amazing. I said earlier I felt like a novice at the tools way back when. To be honest, I still feel quite a lot like a novice. There is so much to learn and I’m fortunate to work with a lot of people who are so smart and deep into this stuff and happy to share their wisdom and experience. So it’s been exciting. It’s been a learning curve for sure, kind of being given a bug on the Performance panel and having to find the bug, but also like figure out what it’s even representing. Like how do I reproduce this? Get more familiar with all that side of things. So it’s been fun.
Tanner: What is one of those bugs? Like, did you have a bug, did you have a first bug? Like what was that time that you got on the team and they said, “Here! Here, Jack, take it, go.”
Jack: I’m struggling to think of a specific example. Often we’ll have situations where a certain combination of things on a given website will cause maybe a slight bug in terms of the metrics we present, or the numbers will maybe miss rendering. Cause you know, the timeline is like effectively a series of rectangles representing events and the time spans of those. We often have bugs where—I say often, not that often—but we often have bugs, particularly on edge cases, where we’ll misrepresent some data. But I think that’s the main challenge, building performance tooling, is there are however many websites there are, effectively infinite websites in the world, and that this sort of cross combination of all the technologies and all the things that is going on in those websites is infinity times infinity. And so we’re trying to make a tool that any website can be loaded, can be profiled, and then you can dig into that. And you just get a ton of edge cases. Like, I had this script that was render blocking and I had this script that I dynamically loaded, then I had this CSS sheet, and the combination of these things causes this bug.
Jack: So a lot of the time with performance, the challenge is reproducing it. And we do… A lot of people are very good. I think one of the benefit of building a tool for developers is if people find a bug in the Performance panel, they intuitively understand that if I provide the website I was profiling and a trace of that website that will help us find the bug, which is true. But even so, the trace files that represent how the website loaded are megabytes of JSON. And so you’ve got to try and dig into that and figure out what’s going—it’s a challenge. And it can be frustrating at times. But it’s also nice when we can ship improvements to tools that hopefully mean people can ship improvements to their users, is kind of what motivates me in that regard.
Tanner: I just, I’m trying to imagine here, I picture that you now live in a world of edge cases. Like, “Alright, what are we doing today? Well, I guess I’ma go figure out this crazy bug, go dig through some JSON, try and figure out like…” I also feel like you’re probably a treasure trove of surprises, like just weird performance cases that, “Woah, that did that?” Do you have any things that, you know, in your journey here, what has surprised you over your career and over the time that you’ve learned performance?
Jack: Yeah, we definitely had some surprises. We had one the other week where, you see some very bad performing websites. And to be clear, I don’t always think that’s the developers on the team purposely not caring or making it bad. But there was one, I won’t name any individual website, but there was one where, we picked it completely randomly, we were just looking to get a few to sort of profile for various reasons, and we discovered that the Largest Contentful Paint, which is quite an important metric, with JavaScript turned on was 13 seconds. If we disabled all the JavaScript, it was half a second. And that was really interesting because I think what we have is when you have a website with a bad Largest Contentful Paint, LCP, seven, eight times out of ten, it’s going to be one of a couple of things, and the fix is at least theoretically straightforward. In this particular website, the Largest Contentful Paint was a big image, it was like a big background image of a picture of the product. And typically when that is really slow, what that website is doing is it’s not loading that image until like 12 seconds in and then it loads the image and it dumps it in. So typically the work there is, “Okay, why is that image being loaded so late? How do we make that image pull, be loaded sooner?” What was amazing in this case was the image was loaded immediately and then there was so much JavaScript going on, and so much stuff that the browser was having to do, that it didn’t get a chance to paint the image onto the screen.
Jack: So we find it’s almost like all the time where the assumptions we have about, “Okay, the main causes of LCP are X, Y and Z.” And suddenly it’s like, “Oh no, they’re not. There’s this whole other one we haven’t even thought of.” So you get, you kind of just get used to it. It’s one of those where I think if you’re a developer who likes having a very rigid set of rules that you sort of build your product on top of, performance can sometimes throw those upside down because you just get all these weird edge cases that are hard. So that, I think I now do not get surprised when we see interesting bug reports or interesting performance-related issues on websites. It’s been a fun, fun ride seeing a bunch of those.
Tanner: Man, I have so many places I want to go. Like I want to know what you find interesting, but I also want to know how you learned. I’d love to go back as well to your startup days and kind of walk up through of like, “I was a novice, now I’m still a novice but I know more, I’m a little more… I’m still a novice but I’m an experienced one. I can get around, I can find…” So yeah, maybe let’s do that. Can you take me back to like, how did you learn all this stuff? Like how did you get through all this?
Jack: Yeah, a fairly sort of classic stereotypical journey in. Got into building websites when I was 13, 14, built a website for my football, or soccer as you would call it, Tanner, a soccer team.
Tanner: I watch Ted Lasso.
Jack: Yeah, there you go, alright, perfect. And yeah, built this dreadful website for them and just discovered I really liked coding HTML and CSS. Then I think got into jQuery, then PHP, decided to do computer science at university. Yeah, so did the university degree and then got a job at a startup. And it was quite a small startup at the time. And looking back that was, for me personally, a really good move, like joining a startup earlier on rather than, say, applying to a Google or a company more like that size, because the engineering team was pretty small and I really got exposed to a whole range of stuff. I actually started as a backend developer there. I was writing Ruby, doing Ruby on Rails applications and Postgres databases and that side of things, which I loved, I had a great time, I really enjoyed it. But then suddenly, I think like maybe the frontend person on the team left suddenly or had an extended period of absence, and because I dabbled in frontend and learned sort of building websites for football teams, I kind of volunteered to get stuck in. If I remember rightly, I think it was Angular 1, like the way back old Angular was what I learned.
Tanner: Classic.
Jack: And just yeah, just discovered that I really liked the frontend. I think I realized that I liked doing the backend but it was nice to do the, what I would call the more tangible part, which is you’re actually kind of bringing that application to life with the user interface and what you show and how you build the UI and all that, all the frontend concerns. Just ended up enjoying that a bit more. So just kind of moved at that company into being frontend. The product for that company, it was really an API, it was like a payments API, but we needed to build a dashboard for people to view all their payments and manage them. Classic stuff, classic CRUD dashboard. So that was really how I got started and the first time I was, I would say I was building proper frontend applications almost, rather than HTML and CSS static sites.
Tanner: And would this have been around the, how close is this to 2014? When Saint Paul called you to the good work of performance.
Jack: So this would have probably been… It would have been 2014, 2015 that this was happening, yeah. So maybe actually, maybe I was a year or two off. Maybe Paul was more 20… I went to the Chrome Dev Summit maybe closer to 2016, perhaps, ish.
Tanner: Interesting. We’ll fact check after the episode.
Jack: Yeah, exactly.
Tanner: I have to ask, though. I usually try to make a habit of finding people’s books.
Jack: Oh no…
Tanner: I can’t say I, well, wanted to have yours here. But tell me, you mentioned, how did this thing happen?
Jack: Is that mine? Have you got one?
Tanner: Beginning jQuery.
Jack: Oh, I’ve never seen one…
Tanner: I wanted to get the paperback but I didn’t get it in time.
Jack: Don’t buy it.
Tanner: It’s too late. It’s too late, it’s already done.
Jack: I feel bad for you. You’ve just probably added like 10p to my next statement in terms of royalties, so that’s nice. Yeah. So, well, you said you looked through my blog. I’m sure if you went back far enough to 2012-ish it must be…
Tanner: Where it all began.
Jack: You’ll see a bunch of jQuery-type posts. Yeah, that was really where it all began. And I was just blogging, really, it is kind of cliche, but I was just blogging like stuff I found that I’d learned about. There’s blog posts there that now looking back they look so straightforward, but at the time it was brand new information to me, like I didn’t know. It was the fact that you could use jQuery to dynamically toggle a class on an element or animate something, you know, 300 pixels was super exciting to me.
Tanner: Right, it’s huge.
Jack: It’s like, you know, just playing around, messing around, it was mega. And I think that was the power of jQuery. Particularly, you think back to how JavaScript was at the time, jQuery really unlocked a whole load of stuff that was just way easier. And so I just blogged about jQuery a bunch and then got an email from Apress, who are the publisher, and they said, “We’re looking for someone to write a book, sort of intro to jQuery.” And at the time I felt like my last 18 months I had basically done an intro to jQuery just myself, just from Googling and reading other blog posts. I can’t remember if I watched many YouTube videos at the time. This is a bit pre kind of the era of lots of people doing video courses. But I just, I’d messed around with jQuery a bunch, and actually jQuery’s documentation was excellent, and I just thought, “Yeah, why not. I’ll write a book.” To me that was really exciting, to get the opportunity to write a book.
Jack: So yeah, I mean it is very outdated now, so I am sorry that you bought it. And the thing I remember is it was deliberately targeted, you know, beginners. So it wasn’t ever going to be a huge book. But I remember when it arrived, I’d been working on it for a year, so I had a full-time job at the time and then in the evenings I would spend most nights probably at least a couple of hours on the book. It was a pretty rough year for sort of the amount of energy I sort of spent on everything tech-wise. But then one day this box of books arrived in the office, it was like the first time I’d ever seen it, and I remember opening it. And if your copy arrives you’ll see it is disappointingly thin. Like it should be thick, I wanted it to be thicker. Like it doesn’t feel like a proper book, and that was what really annoyed me, and I was like, “I should have added that extra chapter.” You know?
Tanner: What is this, a pamphlet?
Jack: Exactly. Yeah, like is this a school project I just did? And so that was a bit disappointing. But it was a good experience. I think I learned a lot about writing, which was very valuable, looking back.
Tanner: Yeah, how’s that?
Jack: I would do a much better job now, obviously. But then I have eight, nine more years, more experience, so that shouldn’t be surprising.
Tanner: Yeah, I just think I haven’t heard of many people who… Because this, if I’ve got my timeline right, you’re coming like fresh out of university, “I’m writing a book! I already wrote a book.”
Jack: It was during university.
Tanner: And now I’m blogging… Yeah, so like you come out, you’ve already written a book, you start your career, and we’re off to the races. Like, I don’t know, I think that’s crazy. I think that’s fascinating. So from there, like, where do you go from there? Because we’ve got this, you’re at the startup, you’re building web apps. I wonder if you’re using Backbone.
Jack: Yeah, we weren’t there. I remember using Backbone a lot on a couple of side projects. I think I did some blog posts about it maybe? You probably know better than me if you’ve looked through the archives.
Tanner: Oh no, I had to skim.
Jack: You had to skim, yeah fair, that was sensible. I think I did do some Backbone at times. And then, yeah, actually from there I ended up… That was really, I think around that time, first job, I really kind of discovered Twitter and was using that a bit more and kind of following other developers and stuff. And then I actually decided to leave that job to get a different job at another startup where I would be developer evangelist.
Tanner: Yeah.
Jack: So I sort of temporarily left full-on software engineering behind for a year and I did DevRel, or developer relations, evangelism, whatever you want to call it. And so for a year I just basically went to a load of conferences, spoke at a bunch, just listened to a bunch, did all the classic wearing the company t-shirt, handing out t-shirts at stands and writing blog posts about this API that the company built. And I had a great time. I met a lot of people. I think that maybe was like the first time I met maybe Paul, a bunch of other people who I now kind of speak to quite a lot. And that was really good for me. Selfishly, if you look back at it career-wise, that was, I mean, the best decision I could have made for myself because just once a month at the absolute least I was on a stage somewhere doing a talk about something. And my talks probably weren’t great, certainly some of them looking back definitely weren’t, and sometimes the content was less interesting than at other times, but it was just meeting people, like so many people. And then blogging as well.
Jack: And I think at that point I really enjoyed that side of it, and I liked, I’ve always liked teaching people and trying to help. I actually, before I kind of got into coding, into computer science, I wanted to be a teacher.
Tanner: Really?
Jack: Like a secondary school teacher or high school teacher. I always wanted to teach maths. That was always what I wanted to do.
Tanner: I’m gonna tell my son. He’s like, “Math sucks.”
Jack: No!
Tanner: Well, go talk to Jack.
Jack: Yeah, exactly.
Tanner: Math is great.
Jack: Yeah, I loved it. And I still, like, someday would love to teach some maths to someone. But anyway, so I think when I did computer science and went into programming I wanted to do the teaching side of it and conferences and blog posts gave me that avenue to do that, which was fantastic.
Jack: But during that time, as developer relations, I really missed being a software engineer and getting to… I wrote code as developer relations, but it was sort of small side projects, kind of example apps to demonstrate this API for the company I worked for. And I missed, like, the nitty gritty of software and dealing with legacy code or all that stuff, refactoring and building features.
Tanner: You missed dealing with legacy code?
Jack: I did, yeah. I like it.
Tanner: Tell me more.
Jack: I then moved back into software startups and have been doing engineering ever since, but it was a really fun year. I think I traveled around most of Europe, got to America once. So yeah, it was good for me, but I was very happy to move then back into software.
Tanner: Yeah. So tell me more about this journey because you’re, man, you packed in those first several years.
Jack: Yeah. Yeah, I did.
Tanner: And now we’re getting back into coding, getting right in. You used a couple of interesting words when you were talking about performance. Like I wrote down “stumbling” here because you start using the Performance panel. So far working on applications, performance has been kind of an afterthought, but, “Oh, I saw this talk and now I got these great ideas, I want to try it.” You’re getting into the Performance panel and it’s just, “What?” Is it overwhelming? Like you’d stumbled. Can you recall some of those times that you were first using it or trying to figure things out? What were some of the things that you… How did you make things more performant? And how has that changed over time?
Jack: Yeah, I think the performance tools can be very overwhelming. When you load them up they show you a lot of information, right? I mean, loading a website is complicated and they have to show that. I think at the start it was very basic stuff. I was using the performance tools to see how many kilobytes of JavaScript we were shipping. And then I was… DevTools has this, what’s it called, the Coverage tab or panel, I can’t remember quite, the one where it’s like X percent of your JavaScript was actually used or not. So I think really at the very beginning I was doing the very fundamentals. Okay, we have a script that’s loaded in the head, let’s move that to just below the—oh, sorry—just above the closing body tag so it doesn’t block any rendering. We’re shipping, I don’t know, 200 kilobytes of JavaScript all in one bundle, let’s try and split that up. And I was splitting it up at the time as well. If I remember right, it was like moving it into separate script tags and dumping things into global, like window.app=”blah”, because there was no lazy importing or anything like that.
Tanner: Right.
Jack: Or there was, what was it? Did you ever use RequireJS?
Tanner: Yes!
Jack: Yeah, like AMD loading and that, I think that could lazily load stuff. It was a little, I never really understood how it worked.
Tanner: Yeah, chunking all that stuff got really weird and then it had to like…
Jack: Yeah. Yeah, we all kind of had that.
Tanner: Recreating the define function and stuff.
Jack: Yes! Yeah, you could like copy that kind of script from their website which made, if you were publishing a package, it made it work for AMD and for Node, I can’t remember. Oh yeah, UMD, Universal Module Definition. That’s it! UMD. That’s what I’m after, yeah. I don’t miss any of that. There’s a GitHub repo with all the different ones. Yeah, yeah. And I never really understood any of them. So yeah, I was doing at the time what we could do in terms of splitting up code and that kind of thing.
Tanner: File size, chunking, and stuff.
Jack: I think I was always working at startups… Yeah, yeah. And I was always working at startups where they had built an app using, I think it was Angular then I think it was, I joined a company where they’d built an old app in Angular but it was very old, they wanted to rebuild it in React. So I kind of joined to do that. But sometimes with apps like that, it is hard or harder after the fact to start applying these performance things because you’ve just built this big app, performance hasn’t been a concern. So I tried to sort of go in and teach people that at the very least we can lazy load this JavaScript which responds to the, I don’t know, the Settings page, which we don’t need to load until the user clicks on Settings, that kind of stuff. So it really was the fundamentals, but that was sort of the entry way into it for me.
Tanner: Yeah. Let’s fast forward a bit. I’d love to hear more about now, like you were using the tools, now you’re making the tools. Have there been any paradigm shifts? Or, you know, I guess now’s a good time to get back to the interesting stuff. Like what about working on the tools, what about performance really interests you?
Jack: I think the main thing is I feel really privileged to be able to work on a tool that, if we do it right, helps a lot of people in their day-to-day life. And that is, that was sort of the appeal about joining the DevTools team. And I think for me having used DevTools I can remember, obviously it wasn’t Chrome DevTools, it was, I think Firebug was the first like developer tool thing I met, but the extension for Firefox. And then I think, you know, Firefox, Mozilla had their DevTools, Chrome and WebKit and all that, all the DevTools. And so every day, from the first day I ever learned any HTML, like the day one of dropping a paragraph tag into a page, through to the job prior to DevTools, I had used DevTools pretty much every single day to help me. So the opportunity to then be on the team that can help people help themselves and their users was kind of an absolute no brainer to me. It’s still the thing now that gets me most excited.
Jack: It does get a little bit, you have to watch your head. Because if I’m working on DevTools I use another DevTools to debug the DevTools that I’m working on, because DevTools is a web app just like anything else. And so you end up with two DevTools windows, yeah, and one of them is inspecting the other one, which I am working on and making changes to. That’s all great and it’s a bit confusing, but then if you break your DevTools because you’re making a change to DevTools you then can’t inspect the broken DevTools because inspecting them will load up the broken DevTools again.
Tanner: No! Command Z! Undo!
Jack: Yeah, it can be a little bit of an experience to try and figure that out. A tip most people on the team use is they’ll have the DevTools they’re working on they’ll set to light mode, and the DevTools inspecting that they’ll set to dark mode, or vice versa so you can distinguish them. But yeah, it does get a bit trippy for sure. But that’s kind of the shift is I’ve spent all my career thinking about users and in terms of like… people using websites, for want of a better phrase.
Tanner: Non-technical people.
Jack: Non-technical people, yeah. Whereas now it’s developers building those websites. So it’s like a level removed, or not necessarily removed but a different level, a different sort of type of user.
Tanner: It almost, maybe this is a weird metaphor, but is it kind of like shifting from, I don’t know, being an interior designer who was working on making, “I want this room to be beautiful. I want it to be comfortable for people who are going to be walking in and out and sitting and using it.” And you’ve switched to being more of like, “No, I’m actually going to work for the construction teams who are actually going to be building the house.” Or like I’m going to be supplying the people working on the house, the architects and so on.
Jack: Yeah.
Tanner: I don’t know if that matters.
Jack: Yeah, I think roughly. You know, I understand what you mean. I think so. And that, to me, is really exciting to be able to do and have that impact.
Tanner: Yeah.
Jack: Yeah, it turns thinking about performance into a whole different level, because we’re not thinking about how can we improve this one website’s performance, we’re thinking about how can we provide the tools to improve the Web’s performance. And so that is a, obviously a challenge, but also a very exciting one. Because if we can get it right and we educate people and we provide tools that can make it easier, then we improve the Web for loads and loads and loads of people and that’s the exciting part.
Tanner: Right. I’d love to dive in more into the Performance tab itself. And I think maybe this is a way to ask it, almost kind of going back to that first bug. Like you join the DevTools team, you get on, you’re working on, you raise your hand and you say, “Yes, I want to work on the Performance tab.” And then you start working on it. What are some of the things that you did? Are there any highlights over that time of working on the Performance tool?
Jack: Yeah, I think the first thing I did was just try and immerse myself in understanding the format of traces, because that was unlike anything I’d ever done before. And there were interesting challenges. I mean, these… So when you hit record in the Performance panel where, you know, the browser is logging all these events, we get them as a big JSON file. On a big website that can be 10, 20 megabytes, easy, of JSON text. Like they’re not small.
Tanner: Yeah, which paint the picture for me too. Like I’ve never heard of a trace before. Wait, what? What is a trace?
Jack: Yeah. So it’s basically a massive, it’s a big JSON file, which is effectively an array of objects. And each object represents some event that occurred during the lifecycle of that loading. So the very first event will…
Tanner: Like a request was made or an image loaded or…
Jack: Yeah, all that stuff. The first one will be something like, I can’t remember the exact names, they have quite odd names at times, but the first one will be broadly like “Navigation Started”. And then in that they can have metadata associated with them, so Navigation Started, URL JackFranklin.Co.Uk, whatever. And then you’ll get things like “Image Painted Requests Fired”, but the request is split up, like Request Created, Request Sent, Request Received, Request End maybe. And so if you’re looking to pull out a network request, you need to find all those events. And they will often have IDs, so you can have multiple events with the same ID and they represent really one thing. So you have to go through the JSON file and sort of find those and pair them up accordingly. Then there’ll be events for things like “Largest Contentful Paint Candidates”, because as the browser paints, it pulls out different candidates and then eventually it decides which one is the winner, or the most suitable candidate.
Tanner: Right, because it doesn’t know.
Jack: It doesn’t know.
Tanner: I have to work for all websites. I don’t know what the biggest thing is going to be.
Jack: Yeah. So every time it paints something it’s like, “Oh, this could be it.” And so if you look in the trace, it will tell you all the things that it thought might be it. And then finally at the end it goes, “Oh no, that was it.” Broadly, it’s always the last one, right? It has to be the last one, because that makes most sense most of the time, but it’s not always the last one. And so you have to be careful in how you parse it.
Jack: And then we’ll also have all the JavaScript that was going on. So all the work that happened on the main thread or if there are any other threads going on. So iframes, for example, they will be in there, but on a different thread they’ll have different thread and process IDs. So you also, if we’re just looking at the main thread and like first-party code, so no, if we ignore like iframes and ads, then you’ve got to make sure you’re only getting events from the right processes and the right threads that represent that.
Jack: So it can get pretty challenging. And the challenge, particularly if you’re working on, let’s say, a 20–30 megabyte trace, sometimes text editors don’t love to render 30 megabytes of JSON. And so it’s not like you can just load it up and look for what you’re looking for, because often you’re looking for this combination of events that you need to massage together to represent this one concept, like a network request. So yeah, they’re pretty challenging.
Tanner: So what do you do? Like do you, are you loading up, I don’t know, are you loading up VS Code with 20 megabytes, VS Code crashes, and then you’re out of luck? Like what do you do?
Jack: Well I use Vim, firstly. So that… Normally I load Vim with none of my configuration loaded and it can just about handle it with a little bit of lag. So that works fine. And then what I’ll normally do is, is load it up in the Performance panel and console.log() or use the Debugger to step through and look at the data. There’s also another tool, which I’m going to have to check if it’s public or not, I’m 99% sure it is public. Yeah, it is public. There’s another tool called Perfetto, which is a very low-level Chrome performance tool, which no one as a regular web engineer, for want of a better phrase, would ever use. But if you’re a low-level browser engineer, Perfetto is a more useful tool for you, it gives you everything. But often so we can dump traces into there and kind of look at what that parses out as well.
Jack: But there is no shortcut here. The best way I found was, “Okay, I want to understand LCP,” because I keep going about LCP, “I want to understand LCP better.” What I’ll do is I’ll make a dummy website locally that just has three images that paint, and one of them is 10 megabytes in size, and then from there I will go through that trace. Because if you keep the website very small with not much going on, then the trace files start to be a little bit more understandable, and you can actually kind of walk your way through them and see what’s going on. And if you then look at the same trace on a much larger website, it’s the same set of events, it’s just in the large website there happens to be more of them because there’s more going on. So what you have to do is you have to reduce these test cases, or these dummy websites that we build, down to just what you want. And at that point it’s much more approachable. And on a big website it’s just that, the same, all over again.
Tanner: Right. It puts a whole new spin on filing a bug report, by the way. Or at least perspective for me to be like, “This is why a minimum test case is so important.” Because I don’t want to have to deal with a 300 megabyte trace.
Jack: Yeah, that could be a challenge. You get people saying like, “Something on my website is breaking the performance tool, it errors,” and they attach a trace file and they do everything they can do. And now it’s like, “Okay, what part of this website is actually causing it?” Because it’s not going to be all of it. It’s going to be some really, really niche thing, and that can be challenging. And sometimes, to be honest, we can’t figure it out. Or the amount of time it’s going to take to figure out for this one single bug report, which is the only instance we’ve ever had of this particular crash, sometimes unfortunately we can’t, we can’t prioritize all of them. But we, you know, obviously we try to as much as possible, but it’s not always feasible.
Tanner: Well I imagine there’s so many bugs going around, like, “I’m really sorry, but there’s literally thousands of these that we have to deal with.”
Jack: Yeah, yeah, pretty much. But yeah, that was my life for months, was trace files and just trying to understand them, along with understanding how the browser actually works and how it renders and how it deals with processes and threads and iframes and all that stuff. That was where I’m very fortunate to work at a place where there are a lot of people who know about browser engines. And so there’s people I’m able to talk to, to help me understand that situation.
Tanner: When you were learning more about how the browser works, were there any, I guess, eurekas or, “Oh wait, that’s how it works?” Did you have any moments like that?
Jack: I don’t think so…
Tanner: More subtle.
Jack: …too much. I think that…
Tanner: More things just like, “Okay cool, that makes sense.”
Jack: More subtle, yeah, yeah. Or understanding where it will share processes versus not, and create a new process, which is largely down to the domain. And if it’s on like, if it’s on the same domain it will kind of stick around, if it’s a new one, if it’s an iframe like Ads.Com, that’s a new thing because it’s a new URL.
Tanner: So I’m a dummy, I have no idea what a shared process is. Is there, there are processes that are shared and some that are not shared? What’s, what are these?
Jack: Yeah, just the browser has got a bunch of processes that it creates as it renders your website. And so if I’m thinking about pulling out data from those processes into the Performance panel, we need to make sure we get data from the right processes that we care about. And so typically what we want to do, not always but some of the times, is ignore anything that comes from a third party or an iframe. So we’ll look for, like, the… You know, JavaScript is single threaded and the browser only has one thread. So we need to make sure we get the right thread that represents where the developer’s code is running, not where Ads.Com is running their code. So I think it’s stuff that if you are trying to debug the performance of your website, you don’t need to know, but if you’re trying to parse a file representing the loading of a website… And I would not, you know, if someone asks, “Oh Jack, can you spend 20 minutes telling me how browsers work?” No, I’m not the person to do that. But I have like just enough understanding to dig my way through a trace file, and understand when I need to ask for clarifications. But yeah, it’s, pff… yeah, there’s some complicated stuff by people with far bigger brains than me.
Tanner: I can only imagine. Well, man, we could just talk for hours about all this. Unfortunately, we are coming close to time. I would love to talk more about the Performance tab itself, but maybe, do you have any kind of parting words of wisdom? Or things that you’ve learned over the years that you would share with somebody starting out now, getting into web or web performance?
Jack: I think the main thing would be to get really good at understanding errors. I’ve done quite a lot of teaching of beginners, or intermediate kind of junior developers, and thinking back about the ones… Or the developers I’ve worked with who are sort of people I’m like, “Wow, you are, like, really good. If I can end up anywhere close to how you work, I’m doing well for myself.” It is their ability to see and understand an error. Because errors happen. Right, we all make endless typos or logical errors, that’s part of being a developer, and sometimes they suck and they’re incredibly frustrating. But what sets people out, I think, is the ability to see the error, and just read it through properly, and just take a minute to think about it, and not just go like, “Oh, I give up, it’s not working,” which is easily done. But that’s the thing in my head that separates developers. And if I can sneak in a second, I think…
Tanner: Absolutely.
Jack: Communication is the other thing. Whether that is clear comments in code, where the code needs that sort of level of clarity. Whether it’s clear pull request descriptions so I don’t have to ping to ask for more context. Clear documentation, clear tests, all that. The communication just saves so much time, if you can be clear and concise and get the level of communication right. So I think those are my two things that I think I would focus on.
Tanner: This is a shot in the dark, but do you have any particular resources or people who you’ve learned those two skills from, error debugging and clear communication, that you might recommend?
Jack: Oh, off the top of my head, no.
Tanner: We’re gonna get an answer back. We’re gonna bring him on for a second episode to tell us all about error debugging.
Jack: Yeah, there’s definitely blog posts that I have read on both these topics. There was a really good blog post, I’m gonna, I will find it and have to tweet it or send it to you, or maybe you can put it in show notes or similar because there are.
Tanner: Absolutely.
Jack: But yeah, there was one blog post that just linked to a bunch of pull requests on GitHub and explained why these are really good, and that was one I remember stuck with me. And I will attempt to hunt it down.
Tanner: That would be fantastic.
Jack: I’m sorry to the author, because off the top of my head I can’t remember who it was.
Tanner: But whoever you are, you’re the best. You’re the MVP.
Jack: Yeah, thanks.
Tanner: The hero we needed.
Jack: Yeah, exactly.
Tanner: Well that’s fantastic. Jack, thank you so, so much for taking the time to hang out today.
Jack: Not a problem. Thank you.
Tanner: I would love to do it again sometime.
Jack: Yeah.
Tanner: Until then, have a great one.
Jack: You too. Thanks very much.

Recent Posts

Archives

Categories

Links

Video

Transcript

Leave a Reply Cancel reply