Philip Walton - Catching Up With Web Performance

Catching Up With Web Performance

Philip Walton

00:00 / 47:19

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 Philip Walton. Phil, how’s it going, man?
Philip: Hey, it’s going well. How are you doing, Tanner?
Tanner: I’m hanging in, there’s a tornado watch, so hopefully our Internet connection doesn’t disappear.
Philip: Okay.
Tanner: But it’s good to see you!
Philip: Okay. Actually, where are you? Where do you live? I ask this question because I remember, I lived in Chicago for a while, and I remember tornado watches and that was, those are scary.
Tanner: Yeah, this…
Philip: I don’t have that anymore.
Tanner: I’m in Charlotte, North Carolina, and we usually don’t get them. We did a couple years back, which we’re about to get way off the rails here, but we had an incident where a tornado actually blew through our old neighborhood and tore up some of our old neighbors’ houses. Now my son has been traumatized about tornadoes ever since. So they’re out watching Octonauts to try and stay distracted, which is fun.
Philip: Yeah, I’m glad to say that I don’t have to think about that very much anymore. Because I remember as a kid, any time, you know, maybe it’s like the Wizard of Oz memories, you’re like, you see that and you’re scared about it.
Tanner: Yep.
Tanner: Anyway, that’s not what we’re here to talk about.
Tanner: So what’s your greatest fear, Phil? Tell me how it all began. Well, I have to ask you back, though. Where are you at? Are we both in the States here?
Philip: Yeah. So I’m in Los Angeles right now. I moved down here from San Francisco during the pandemic, and I’m enjoying not having to go into the office every day, so that’s been great.
Tanner: I bet.
Philip: Yeah.
Tanner: Well, hey, we’re just gonna keep rolling, we’re gonna keep talking about you, because the whole point of today: I want to know your story. I want to know all things Phil Walton. So let’s time travel here for a minute. If you can take me back, do you have a first web performance memory? I’m so curious how you got into this crazy world of web performance.
Philip: Yeah. So you told me that you were going to ask me this question, and I was thinking about it a bit, and I think my first web performance memory is actually different from how I got into web performance. But I think my personality has always been, you know, as long as I can remember, that if I can think of or see a way to do something more efficiently, I kind of really want to do that, no matter what it is. Like, I played a lot of, you know, strategy games when I was growing up, like chess and other games like that. And I was always really interested in trying to figure out the best way to do something or the, like the right strategy.
Philip: Probably my first web performance memory, I was, this was maybe 2006 or 2007, I was building a WordPress site for somebody.
Tanner: WordPress?
Philip: Yes, and I had just started doing web development professionally. And I remember that I had this design requirement where they, you know how WordPress sites often have a content area and then a sidebar with widgets in them and the widgets will have different information about the content, and so this was a widget that had all the posts, you know, like all the posts for a certain year, and then within that each month, and it had to have a post count next to the, you know, so whatever month it was and it would say how many posts were from that month.
Philip: Yep.
Philip: And I was on very poor shared hosting, and I remember that it was just taking a while, and I started kind of thinking about how, like if there’s anything that could be done to improve it. And I had been reading about like, you know, how you see what the actual, you can have some debug flags or something, you can see what the actual queries that WordPress is doing. And I noticed for this particular widget, I don’t remember exactly how many it was doing now, but it was doing tons of queries. I think it was either like fetching all of the posts and then looping through them and then manually doing, fetching counts for each of the month or something. Yeah, I can’t remember what it was but it was super inefficient in a way that seemed quite obvious to me, like, “Why don’t you just do one query? Like why do you need more than one query?” But it wasn’t an option, you know, like the way that these, you know…
Tanner: The Loop.
Philip: Yeah, really, it might have just been going through The Loop and then counting it manually or it was doing something else but, you know. So in WordPress you can write your own SQL query, so I knew a little bit of SQL, and so I thought I’ll make my own plugin that does this, and spent a bit of time just trying to figure out how to do this with one query. But it ended up not being super hard. And so I did that and it was noticeably faster. You know, this, again, it was on shared hosting, like I don’t know, HostGator, Bluehost, some kind of…
Tanner: One of the classics.
Philip: Where you pay, you know, $2 a month or something and you get the bare minimum. Yeah, and I just remember I was always interested in those kinds of things. Like whenever I would see something that had just seemed like, “There’s got to be a better way to do this,” I would, you know, deep dive into that. And I probably could have got my client project done way faster and the client would have never noticed if I hadn’t done that. But, you know, it was just more of a personal thing for me where I wanted to do it as right as possible. I wanted to figure out the best way to do it. And so that’s probably the first time I can ever think about, like, noticing the loading speed of a site and thinking about how, what I should do to make it faster.
Philip: But, you know, I didn’t end up doing much WordPress after that. And so it wasn’t like I went that direction into WordPress performance or other web performance right away. Like I, my career in web development was much more generalist web development, frontend development, you know, for a long time and then ended up joining Google. Although, that’s an interesting story.
Tanner: Oh really?
Tanner: Yeah. You know, actually that probably segues pretty well, so let’s go to that story. I had been doing a lot of just general web development. I had been doing a lot of frontend development. I worked for a startup that had, you know, almost exclusively computer science master’s and PhD engineers that knew nothing about web development. This company had this philosophy where, “We just need to hire the smartest people we can.” Which I think was just a bad idea because, you know, they don’t know anything about web development. I think people think that, “Oh, if you’re smart, you should be able to learn.” It didn’t really play out that way. You know, they just…
Tanner: Anyway, the company realized eventually that they needed to hire frontend developers as well. Because, you know, you have to understand how these things work in order to build a well-performing website. And one of the things that they definitely struggled with a lot was CSS. So, you know, they don’t teach CSS in computer science programs. And so people were writing whatever selector they needed to write to get the styles that they needed to get. And then you have, you know, dozens of engineers all contributing to the same main.css file, and their rules were conflicting with each other. It was a huge mess. I mean, all the stuff that people talk about today, you know, CSS-in-JS, encapsulation, scoping, all that stuff, we were definitely experiencing those problems at this company. And so I think they kind of realized that we need somebody that understands what to do.
Tanner: “Help us!”
Philip: And so one of the first things that I was doing was just kind of thinking through a lot of these problems. And this was in the same time period where, you know, people like Nicole Sullivan were talking about Object Oriented CSS, and Jonathan Snook talking about SMACSS and, you know, BEM was becoming popular. And so I started getting into a lot of these methodologies and thinking about that, and was introducing them to my company. One of the things that happened along the way there is I started to realize that I really enjoyed thinking about, you know, what is the right way to do something, what is the best practice, what is the best way to structure something, and really spending a lot of time thinking about that.
Philip: And I realized that when you work for a company, you often don’t have the luxury of doing that because you have a sprint, you have to get features shipped, and then you do that and then you move on to the next thing. And like, improving the architecture, improving the methodologies you’re using, that always seems like a problem that like, “Yeah, we’ll come back to that eventually.”
Tanner: Not.
Philip: And they never do. They never do. So after spending, you know, many years as a software engineer doing frontend software engineering, and just feeling like I wanted to do something more where I could spend time thinking about what the right way to do things was, I started thinking about roles in developer relations. Because a lot of developer relations is promoting best practices, talking about best practices, thinking about best practices. And so I had been applying to some other companies for frontend development general, like just in general, but then I also applied to Google for a developer relations role because it was interesting to me. And I ended up getting that role and getting an offer and realized after I got the offer, this shows a little bit of my naivete, but I didn’t realize that I had been placed on the Google Analytics team. I just assumed all of my experience, all of my background is in web development, so of course they’re going to put me on a team that is doing developer relations for something web-related. And no, they put me on the Google Analytics team. So I definitely had to like have a think about, “Is this even a position I want?” But I was kind of, you know, done with my previous company, and looking at this offer versus some of the other offers I’d received for frontend positions, it just felt like, you know, “Why not?” Like Google’s a great company, like, why not take this job and then see where it goes?
Philip: And so I joined that team. And I had heard, actually, from a number of people that it’s somewhat common at Google to switch teams later in your career. So my plan, even from day one, and I hope my old team isn’t listening to this, but my plan from day one…
Tanner: It’s nothing against you all! It’s nothing personal.
Philip: Yeah, exactly. My plan was to eventually transfer to like the Chrome developer relations team, or do something else with web at Google. And actually I was able to do that about three years later. It probably could have even happened sooner but with issues of headcount and, you know, you kind of have to wait until there’s some opening on the team. But in hindsight, it actually ended up being super valuable to me, because I had no experience with analytics, I had no experience with Google Analytics specifically, other than what most people have, which is I copied that snippet of JavaScript code and put it on my website, and I would look in to my analytics reports and see how many page views, you know, whatever site I was working on had. That’s pretty much it. I didn’t know any of the other features. I didn’t know anything about, you know… I mean, a big part of Google Analytics is the marketing side. I didn’t know anything about that. I didn’t really care that much about it, especially at the time. But as a result of being thrust onto this team and, you know, if I want to transfer to another team…
Tanner: I have to do well.
Philip: I have to be a high performer on my current team. You know, I can’t be a slacker and then transfer. So I knew that I would have to do that. And so I tried to do as well as I could, but in the process I ended up learning a ton about how analytics works. And I ended up being kind of on the frontend side, or they call it the “collection” side, so the side that talks about best practices for using the JavaScript client libraries, analytics.js, you know, now there’s a library called gtag.js, how to use those to collect analytics information. And I had built some client libraries myself that I released on GitHub to…
Tanner: Like Autotrack?
Philip: Yes, Autotrack is a good example of one. Just like, I think people assume that Google Analytics is doing a bunch of, I mean, so now it is to some degree, but back in those days, I think people always assumed, “Oh yeah, Google Analytics is tracking everything I do, and if I just knew how to use the product, I could get all the information. The only reason I can’t get the information is because I don’t know how to use the product.” That could not be farther from the truth. Google Analytics is tracking almost nothing.
Tanner: No!
Philip: It’s literally only tracking page views, unless you tell it to do something else, with a couple of other exceptions, depending upon maybe if you use certain plugins or something, or if you’re using Google Tag Manager, maybe you can customize it to do other things. But if you’re just copying the basic snippet, it’s literally just sending one HTTP request per page load.
Tanner: That’s it?
Philip: And if you have an SPA, it’s not doing any of that stuff either.
Tanner: No!
Philip: Yeah. And so if you want to know more information, like I know one of the things that I definitely wanted to learn about was things like, “What links are people clicking on?” So if you’re clicking a link to go to another page on your site, then you can infer that because you get the page view for the other page. But if I’m clicking a link to go to an external site, I have no idea if somebody is doing that or not. And so if I wanted to understand like what are the popular links on my pages, you have to instrument that yourself. And I feel like most people didn’t know that. And so Autotrack, it started from this idea of, like, you could probably just add some code that would automatically listen for click events on link tags and then look to see, or I should say anchor tags, and look to see if the href value is cross-origin and, if so, send an event that says that happened.
Philip: That starts getting into questions of, well, you know, you’re going from one page to another page, typically when you click on a link to go another page the browser starts unloading the current page, so your HTTP request is not going to make it, most likely. You have to, so there are newer APIs now, like sendBeacon(), which were designed for that purpose, but in the olden days you couldn’t always do that. And so there are different techniques that you could do, most of which are quite poor for performance. But I started learning about, you know, one of the most important issues with analytics is just understanding when you need to send the data to get it there reliably. Because if you want to know anything about what happened throughout the entire lifespan of the page, the best thing you can do is wait till the very end. But oftentimes waiting till the end of when the user’s on the page, that’s the worst time to send the data because it’s the time when it’s most likely that the data is not going to make it there successfully because the browser is already shutting down that page.
Philip: So there’s lots and lots of considerations for how you can do that. And, you know, just being forced to be on that team and really having to think through all of those things ended up being super useful for when I ended up finally transferring to the Chrome team. I wasn’t transferring to work on analytics-related things, but I transferred to the Chrome team, did a number of different things, like worked on some stuff with service worker, the Workbox library, was doing development for that for a while, you know, did a couple other things. But also because of my, I think, analytics background, I had, you know, one of the things I was asked to work on was there was a team working on performance metrics.
Tanner: Interesting.
Philip: So back in those times, right when things like First Paint and First Contentful Paint and Time To Interactive and these metrics were coming out, I was just on a team that was thinking about that kind of stuff. And then fast forward to, you know, 2020 when we announced Core Web Vitals. A couple of months before that, I’m writing the documentation, thinking about what are the best practices for measuring these metrics. So one of the things, I know that people probably know this, but one of the things that I think is the most interesting aspects of Core Web Vitals is that the metrics are measuring real user experiences.
Tanner: Yes.
Philip: Almost everything prior to Core Web Vitals… I mean, of course, there was RUM analytics providers. RUM stands for “Real User Monitoring”. There were many options, boomerang, mPulse, SpeedCurve, like all of these companies were already doing it. But there wasn’t, I think, any kind of really major initiative that expanded into the ecosystem mindshare beyond, you know, super geeky webperf-minded people.
Tanner: It was pretty niche.
Philip: It was, yeah. And so Core Web Vitals said, like, “This is the default.” The default is these metrics measure the real user experiences. And so in order to make that happen, there has to be Web APIs that enable that measurement in JavaScript. So if you’re running a script in JavaScript, you can write a function to get some information and then send that information to an analytics server somewhere so that then you can understand the real user experiences. Because it’s definitely different from, you know, other ways of doing the same thing, like lab measurements. And I would love to talk more about that in a second, but just in this particular example…
Tanner: Let’s go.
Philip: So I was kind of realizing that, yeah, if you want to measure this stuff in JavaScript, there’s a lot of stuff that you have to consider, a lot of stuff you have to consider, and it’s easy to do it wrong. And I was basing this from my analytics knowledge, you know, how if you want to measure Cumulative Layout Shift but you want to measure it throughout the entire lifespan of the page, then the right time to send that information is when the browser is unloading the page, but you know it’s not reliable to send data at that time. And so maybe you have to think about sending it when the visibility state changes to hidden, like the user backgrounds the tab. But of course that could, the user could background a tab but then come back to the page, and then now you have to maybe send more data. And so how do you determine that the additional data you sent is actually still from the same page, not a new page load?
Philip: Anyway, and so like a lot of these considerations, I knew would be important to bake in to some kind of library. Because it’s just very hard to, we can’t expect people just to know these kinds of things. I mean, how would you know unless you had spend a lot of time thinking about it? And so one of the things that I worked on was the web-vitals JavaScript library, which was essentially like, “Can I collect everything I know about analytics and try to package it into this single library so that people don’t have to think about that?” If you’re using a tool like Google Analytics…
Tanner: It’s almost like the Autotrack of Core Web Vitals.
Philip: Yes, very similar. I’m a one-trick pony over here.
Tanner: Hey, though. We need it!
Philip: Yeah. And it’s, you know, I mean, I said one-trick pony kind of jokingly, but it is definitely an area that I’ve noticed that people are very unaware of. And I’m not saying that in like a judgmental way. Why would you know that this was something that you had to, like, these considerations were important, unless you had spent a lot of time having to do this kind of work and thinking about it?
Tanner: I mean, if you go back to when you were working at, you know, was it an agency? What was the company you used to work at before?
Philip: So should I name names?
Tanner: AppFolio?
Philip: It was a company called AppFolio. Anyone who went on LinkedIn could easily find that information, so I guess there’s no reason to hide it. But yeah, it’s actually a really good company. They were a startup but, you know, I think they, there was nothing unique about them. I think most startups, and most tech companies in general, you know, you have this product cycle, you have to release new features and you have to work on them and you don’t always have a lot of time to go back and refactor and do things the right way, you know.
Tanner: Right, I mean that’s why I bring it up. Like so many of us, this is our day to day. When am I gonna think of this? So yeah, totally. Like, who else is, nobody’s being forced to think about this. Okay, let’s help out.
Philip: Yep. Yeah, so that talks a little bit about how I started getting involved in web performance from, like, kind of my first performance memory to how I ended up doing web performance at Google.
Tanner: Which actually, if we can, let me see if I can recap, make sure I get this all right.
Philip: Sure.
Tanner: So we go all the way back, we’ve got Phil’s first web performance experience, WordPress 2006, working on a widget in the sidebar, it’s supposed to show post counts. What the heck? This is really slow. Like, what’s going on here? Dig in. Oh my god, look at all these queries! Let’s consolidate this down to one. You’ve got this interesting obsession with just making things better, which it sounds like has been with your whole life. Which is, “Hey, this is kind of, could this be better? This isn’t great. Let me try and do it better.” You take that with you, you know, as you’re starting your professional career.
Tanner: We go to AppFolio, where you’re like the frontend guy. Like they don’t have a ton of frontend experience, it’s a lot of heavy computer science, more, “I can do backend but what is the Web?” You get in there, one thing leads to another, you end up saying, “I like this best practices thing. I like being able to share the things I’ve learned in my obsession to make things better. What if I try and apply to this DevRel role at Google?” You get it. Woah, no way! But hang on, I’m being thrown on the analytics team. Do I really want this? You do some soul searching and then decide, “No, this is, Google’s a great company and I can make this work. I’ve heard that people can switch to different teams, so let’s do it. I’m gonna go in, I’m gonna be on this analytics team, I’m gonna give it my best.” Which, in the process, that same thing, like, “Can I make this better?” We come out with tools like Autotrack. I say “we”, you come out with tools like Autotrack.
Tanner: And then again, one thing leads to another, we’re skipping through the story. You switch over to Chrome. You’ve got this analytics experience. Field data, you know, we haven’t really talked about this yet. If we want to do this, if we want this idea of Core Web Vitals, and we think that real user data is the most important thing, if that should be the source of truth, where do we get that from? And I feel like you’re, were you in the back corner, like raising your hand? “Excuse me, I would like to, this is how you should collect data.”
Philip: You know, I honestly, I don’t remember. I feel like it was probably just something people, maybe people knew. Like, “Oh yeah, you probably have some knowledge about this.”
Tanner: Go talk to Phil.
Philip: Yeah. I think actually one thing that would be interesting to talk about, because we have been talking about field data versus lab. You mentioned field data, in case anyone doesn’t know, “field data” is a term we use at Google a lot. I don’t think we were the first people to use this in regards to performance, but I don’t know. Anyway.
Tanner: Yeah.
Philip: RUM data, Real User Monitoring data, field data, same thing. Just in case anyone hears those terms and doesn’t know which one is which or what the distinction is. Yeah, they’re the same thing.
Tanner: I remember that was a little mental breakthrough for me as well. Throwing another word in the mix there: telemetry. That was when I realized, oh wait, like this isn’t just even a web or software thing, like this is actually just the notion of collecting data from where it actually happens.
Philip: Yeah, yeah.
Tanner: It spans across industries too.
Philip: Yeah, and it’s funny that we have all of these words that mean more or less the same thing. But I think one thing that I would love to… I mean, so my analytics experience was helpful to me because I then have the skills and knowledge to do this myself. Like I think a lot of people, even the people that understand that field data is important, they typically will use some analytics provider, RUM analytics provider, and they will install that on their site, and then they will look at the charts that this analytics company presents them. But I think there are very few people that are doing it end-to-end themselves and then looking at the actual data that comes in and, you know… What’s the word I’m looking for here? But basically doing their own reports, like running SQL queries to kind of analyze it, thinking about it in all these ways. Like if the tool they’re using doesn’t show them a particular report, they don’t have access to that information. But because I had that analytics backend experience, and because I knew how to really get at the raw data myself, it allowed me to then if I had a question about something, I could test it myself. And I think this was really, really important. And actually I’ll do a little bit of a sidebar here…
Philip: I think the number one skill that people in web development, not just web performance but people in web development, should develop… This is a, like, hot take here. When I was early on in my career I would, you know, I mentioned people like Nicole Sullivan and OOCSS, and Jonathan Snook and SMACSS, and you know it’s easy to look up to these people and think, “Oh, if I have a question about something, if I could just get their opinion then I would know the right thing to do.” You know? And I remember thinking that many times in my career. I would get stuck and I would be like, “I don’t actually know what the best practice is in this particular scenario, so what should I do?”
Tanner: Let me go ask the expert.
Philip: Let me reach out to the expert and then get some information. And now that I’ve kind of been a bit on the other side, like I actually have a lot of people that reach out to me and ask me similar questions, like, “What should I do in this situation?” And what I’ve realized along the way is that the absolute most useful thing you can do for your career is to figure out how to answer this question for yourself. It’s much easier said than done, but if you can figure out how to determine the answer for yourself, you basically have unlimited potential. You are not just bound by, “What is this expert, like, can I actually get them on Twitter? Can I get them to respond to me?” Most of the time it doesn’t work. But if you can figure out how to answer this question for yourself, yeah, you are way ahead of the curve.
Philip: I feel like we just need to like sit and marinate for a little bit.
Philip: Yeah… And field data is actually a really good way to do this with web performance. And so, like, let me give you an example of something that I’ve been talking about with some people recently. If you were trying to optimize your images and you were optimizing for a tool like WebPageTest or Lighthouse and you wanted to get your load time, let’s use LCP as an example, you wanted to get your LCP as fast as possible, and you had a site with some big images, you would naturally want to pick the lowest possible compression for that image where it still looked nice. You would want to pick the exact resolution for that exact file size. And you would do all of this and you would get everything exactly the way you wanted to get the lowest possible time on this lab tool.
Philip: But now imagine that this is a news site, or some some dynamic site, where that image changes from day to day and different people will request it with different sized screens, different devices, and you can’t always give them all exactly the perfect file size that they need. And so if you took the approach of, well maybe, I mean… I said you can’t, you actually can. If you were to dynamically resize the image every single time they requested it, you could give every single person the exact most efficient image to meet their needs. But it would almost certainly take longer, because you would have to then be doing that processing on the server, and to give it to them.
Philip: What is usually a much more effective way of doing things is to have a couple of common sizes, you optimize those images ahead of time, and you serve those images, whatever the closest one is, to the person requesting it. And another reason why that’s important is because when you consider things like CDNs and edge caching, if you have 100 users in a particular geographic area and the first person requests an image, maybe it’s not in the cache, but then when that image is served to them, now it’s in the cache for all those users in that area. Now when the other 99 request it they can get it almost instantaneously because it’s in their edge node right next to them. No processing of the image needs to be done. You know, even if we’re talking about like a JPEG using relatively old school compression, it’s still usually faster to serve that because it’s already there, it’s already in the edge.
Tanner: Right.
Philip: And that’s the kind of thing that a lab tool is never gonna tell you, because it’s always gonna say, “Oh yeah, you can shave a few bytes off of this thing.” But if you look at your field data, and you actually look at how long certain things take, you’ll start seeing a different story. Where, oh, maybe if we do this actually what, you know, it’s a bit counterintuitive, if you do this in a less optimal way, you know, quote unquote, “less optimal”, overall we end up with more, we end up with better performance for more of our users because we’ve done it this way.
Tanner: Yeah. I’m trying to think of a term for that, like “less maximized way”. That’s interesting.
Philip: Yeah, I don’t know if there is a term.
Tanner: We’ll find a word for that eventually. Dictionary people, find us a word.
Philip: Yeah, but it’s the kind of thing where somebody might say to you, you know, “What is the optimal image strategy for this particular site?” And again, you could try to find some expert or somebody you perceive as being an expert and ask them. Or you could just do a test, and you could see, and you could collect some data and you could implement a particular strategy. I mean, ideally you would be A/B testing, but even if you didn’t have the ability to do that, you could set up an experiment and run a test and then you could see, and you could answer this question for yourself, and then do some tweaks, and eventually you will determine what is the best strategy for your particular situation. And there’s nobody that could tell you that. Nobody could tell you what the best strategy for you is. So if you invest in learning how to understand how to answer this question for yourself then, again, I’m repeating myself here, but you’ll be miles ahead of the curve. That’s my hottest hot tip I have for today.
Tanner: Bring it. I love this, though, because I think those, some of these, I guess, maybe more philosophical elements, they do sometimes fall out of the conversation because we’re so focused on the technical terms, the tips, the tricks, the optimizing. Again, I want a dictionary person to find us a word for this idea. But you seem, again, you have this, it seems like you have this obsession with, “How can I do this better?” Which almost, it seems like the other side of the coin for, “Find out for yourself.” I’m gonna go try it. I’m not just gonna wait for the answer to come to me. I’m gonna go out and find the answer myself. How do you get that? Is that something you learn? Does it just happen? Is there a way you can cultivate it or share it with other people?
Philip: Do you mean how do you learn to answer the question for yourself? Or how do you learn to even think about it that way in the first place?
Tanner: Yeah, I guess, when you say your number one tip is, “Go find the answers for yourself, learn how to find the answer for yourself,” my immediate reaction is I want to go get everybody to do that. Do I just kind of tell them? Put out the podcast and everybody hears this and that’s it? Or is there something else that I’m missing?
Philip: That’s a good question. This is a question we have to think about all the time in developer relations. How can we get these ideas out to as many people as possible? And I don’t know the answer to that. I think that, you know, you just have to… I do think that people who are in the business of trying to help educate other people, whether it be web development or other things, it is important that we kind of, you know, it’s the whole teach a man to fish versus give him a fish kind of principle. It’s much better if you can help people understand how to fish than if you can give them fish. And I think a lot of people eventually get that. But I think it is important to just reinforce that as much as you can. Because, I mean, for me, the reason that I came to this conclusion is because I tried to get answers from experts and I was not successful. Like, you can’t always get people to reply to you when you ask them questions. And eventually I realized that I could just answer the question for myself, or I could, I should do what I needed to do to get to the point where I could answer the question for myself, or at least sufficiently enough where I was satisfied with the answer that I had.
Tanner: You know, I’ll throw one other thing in here, and we’ll keep talking about you, but something that I’ve actually, I feel like if I have a learning from all these interviews I’ve done on this podcast so far, one of them that’s been fascinating to me is the recurrence of tools. And I think that the story of, “Hey, you could teach a man to fish and he’ll…” Well, let’s reverse it. You know, the story of you could give a man a fish, he eats for a day, or you can teach a man to fish, he eats for the rest of his life. There’s an interesting in between there where you can also, like, give the man a fishing net, you give him a fishing pole, you can give him a charter boat to go dredge up fish. You know what I mean? Like, there’s an interesting in between with tools.
Tanner: And then I hear other people talking about platform. I think Rick Viscomi, we had the State of Web Performance from This Dot Labs a little while back, and he had a, threw a fascinating conversation, I think—Rick, where you at? We’re gonna get you on the show to talk about it. But he started to introduce the metaphor and the analogy of housing. Like, okay, there are people who are homeowners, apartment owners, landlords, etc. But anyways, all that to say I think it’s really interesting, the tiers of, we have education, platform, and tooling. There’s probably more there in this model but looking at the three of those and how they interact is really interesting.
Philip: Yeah, and tooling is interesting because in web performance I think people think of tooling as synthetic test runners or, you know, Lighthouse, WebPageTest…
Tanner: Lighthouse comes up over and over again, and WebPageTest too, yeah.
Philip: Yeah. And these are great, and I know that people who use Lighthouse love to look at the Lighthouse score. I personally think that the more interesting thing to look at in Lighthouse is the Opportunities and Diagnostics that it suggests. Because the score, I mean, one of the things people ask all the time is, “Why does my Lighthouse score change from run to run?” This is a feature, not a bug. Every time you make a network request, it’s gonna be a slightly different time. Every time a browser loads a page, it’s gonna be slightly different. There’s many, many factors that affect that. And so trying to think of, like, this single run as being the one true run is just completely backwards.
Tanner: There’s a thought.
Philip: Most of the time, when you run the same site through Lighthouse, it’s gonna give you the same Diagnostics and Opportunities every time, because in that case it’s looking not so much at like absolute timings of certain things, but it’s saying like, “Did this site do this thing?” Or like, “Was the sequencing of these events in this order?” Which is what, you know, we don’t want it to be in this suboptimal order. We want, we were looking for this optimal order, and if it’s in the suboptimal order, we’ll let you know. You know, “Do you have render blocking resources?”
Tanner: Almost like measurements versus practices.
Philip: Yeah, it looks for these best practices. And I think that that is really the strength that tools like WebPageTest and Lighthouse, like, you can look at, you know, you don’t just look at the top level number, you look at the waterfall, you start looking. I mean, in this case you might have to… Lighthouse is great because it will just tell you some of these things. WebPageTest, you might have to, I know there are some new pro features that I haven’t actually had a chance to use yet, but most of time you have to look at the waterfall yourself and you have to know enough to know, “Is this a good waterfall or is it a bad waterfall?” You know, I don’t know.
Tanner: Right.
Philip: And so I think tools are really helpful in that case because the tools can then kind of give you those answers. Like it can bake in some of these, like, “Well, let me check this waterfall and try to give you my best sense for whether this is good or bad or what could be improved.”
Tanner: Yeah.
Philip: Yeah. So tools are great for helping people that maybe don’t know enough get some really quick answers. But then I do think it is important for people to understand why the tool is saying something, even if you don’t necessarily know exactly how to measure it yourself, but just what’s the theory behind the recommendation. Because once you understand the theory behind the recommendation, then you’ll be more able to then figure out what the next answer to your next question is, because you understand the theory. I mean, it’s the same, I don’t know if you were like this but like in math class growing up, I encountered students who just wanted to memorize the formulas to get a good grade on the test. But I always wanted to understand why the formula worked.
Tanner: “But why?” Yeah.
Philip: And I felt like that’s always much more important. Because if you understand why the formula works, then when you see the next formula, you’ll be more likely to understand why that formula works as well. And I think it’s similar with development.
Tanner: Yeah, it feels like a lot of this is building up a habit of asking why. And maybe that’s another way to phrase that: Go find answers for yourself. Build up a habit of asking, “Why?” Why does the world work the way it does?
Philip: Yeah. Yep, I think so.
Tanner: Be curious! Classic. Oh, man. Okay, we’ve been talking a bit here about learning. I’m so interested in how you, I mean, you’ve already told us the secret is, “Ask why. Go find answers for yourself.” But maybe if you can come up with a couple other examples. You get onto the performance team. Are there any surprises that have come up along the way, as you’ve been fully in this performance space now for the past couple years? What things you learned, nuggets that you could share?
Philip: Hmm. That’s a good question. I mean, there’s a lot of things that have been surprising that I’ve learned, but I don’t know if they’re necessarily related to web performance. You know, one of the things that I’m actually quite happy about with Core Web Vitals in general… So we at Google, we understand that we’re asking sites to do a lot. The moment we decided to, like from the Chrome side, the moment we decided to partner with Search, and this wasn’t like necessarily my sole decision or anything, I don’t want to imply that, but we understood that we were asking people to do something. And if they didn’t do something, then depending upon your perspective, either there would be a penalty or they would be missing out on a possible reward.
Tanner: Yeah, either way, I don’t like it.
Philip: Yeah, this is asking a lot. And so from my perspective, from developer relations, it’s really important that we get this right. And I’m not trying to pretend that we get everything right. But one thing that has been encouraging to me is even the people that are skeptical of Google and have, you know, assumed that there’s some secret plan for why they’re doing this…
Tanner: Conspiracy.
Philip: Even those people I felt like have generally been, like I’ve heard people say, like, “I don’t like that it’s Google that’s making up all these metrics and they’re the ones that get to set the standards and define the metrics and they have the browser that implements the metrics.” And I get all of that, and I would probably be thinking some of those things too if I were on the other side of this.
Tanner: Yeah.
Philip: But even those people I’ve found have said, “This is how I feel, but I think that these are still pretty good metrics and so I’m happy. Like overall, I think I’m glad that this program exists rather than like it didn’t exist, and I think it’s done more kind of good than bad.” And I’ve been really encouraged to hear that because, you know, this is kind of how we’ve been thinking about it. Like we are pushing really hard to make sure that these are as fair as possible, and they’re as… You know, I think there was a history where Google would put out these very unrealistic requirements, or thresholds or expectations, like, “Your page must load within one second or you’re bad,” or whatever.
Tanner: Right.
Philip: I’m exaggerating for effect. But like, I think one of the things and, you know, lots of teams were involved in this, and I think the approach that we took here was, you know, let’s come with metrics that actually measure the experience. We’re not picking, we’re not trying to pick a particular framework or stack or say like, “You need to have your JavaScript less than a certain number of kilobytes.” We’re very intentionally not doing that. We’re saying we’re just going to try to measure the experience and we’re going to try to use data to back up what a good experience is. But then we also want to balance that against what is the world like right now? What are websites like? What is reasonable to expect somebody to be able to do? What would be, you know, we don’t want to tell people they have to do something and we know that only 2% of the Web could ever possibly do it. And so we tried to take that approach. And I think that has been largely the reason for the success of the program. Like we are asking people to do something, but we’re not asking them to do something that is above and beyond what they should be doing. And I think people generally believe that these things are good for users.
Philip: So you asked what learnings. I think one of the interesting learnings was, you know, we didn’t really know how people would react to this when we announced it. But I think this reinforced some of my initial beliefs that, yeah, you know, you have to meet people where they are. You have to be asking them to do things that are reasonable. You have to be thinking in their best interest. You know, not to say that these metrics are perfect, like there are many cases where, if I were hired as a consultant for some company, I would maybe say, I would maybe tweak to use a more site-specific metric. But if you are designing for the Web at large, then I think these metrics do a pretty good job.
Philip: So definitely, I would say that the learning was just the amount that which we needed to take into consideration, like what are people doing, what are their jobs, can they really realistically spend some of their development cycles thinking about what we’re asking them to think about? These were all super important considerations. And I would say, if anything, we slowed down substantially from our original plan. Because we saw that, one, people were generally happy with the program, but two, it was taking longer than we expected it to take for people to make progress. And we reacted to that by slowing down, which I think was the right call.
Tanner: Performance? Slowing down is a good thing?
Philip: Yes.
Tanner: The irony.
Philip: Yes.
Tanner: I love that, though.
Philip: Yeah. It’s more, it’s the, maybe it’s like “The Tortoise and the Hare”, kind of, the analogy. You go slower but you get there faster, or something like that. You get to your ultimate goal faster by being slower, more deliberate, more intentional, more thoughtful.
Tanner: Yeah. I mean, in a way it almost ties back to your image example, where you could micro-focus on every single thing, you could maximize and make this the most optimal… We could put our, we could put the hammer down! Every site has to be this or else! Or you could account for more of what’s going on, give more common, you know what, let’s take the world as it is, let’s meet people where they’re at.
Philip: Yeah. And I think that there are definitely, you know, performance people that would love my team or other teams at Google to be a bit more aggressive with this. You know, “Oh, these thresholds are too relaxed. That’s never gonna… The Web is gonna die if you don’t change them.” And, you know, everyone can have their opinion, but I think that we’ve been pretty happy with the approach of let’s pick thresholds that are reasonable. They’re, you know, they still might be tough, but they’re reasonable.
Tanner: It’s a dance.
Philip: Yeah. I remember actually having a conversation with some people about what is the ideal threshold for the Time To First Byte metric. So we didn’t, my team never officially put out a recommendation until recently about what we recommend for this, but I don’t know if you know, but the Chrome User Experience Report had a materialized table that had classified each metric, whether it was Good, Needs Improvement, or Poor. Actually at the time it was like Fast, Average, or Slow. It might even still have that because of just the historical reasons. But I think originally TTFB was 200 milliseconds and that was considered fast. And then it went to 500 milliseconds. And then it went to 800 milliseconds.
Tanner: Yeah.
Philip: And so we’ve been raising this threshold. And a lot of that was done because, you know, people, like, I started… This is a, I’m not gonna name any names, but I was having a conversation with a colleague, and we were debating about whether the threshold should be raised. And I took, and this colleague is in developer relations as well, I took the personal websites of like six or seven people on my team and presented the real world TTFB values for their websites, and they were all well over 500 milliseconds.
Tanner: Yep.
Philip: And, you know, kind of saying like, “Can we really expect people…?” And for the record, these were all 100% static blogs. No dynamic server processing, anything like that. These were all blogs. They were all using a CDN, either through GitHub Pages or Firebase Hosting or Netlify or whatever it happened to be, and they were all well above our recommended threshold. And, you know, this person was like, “Yeah, but we chose this threshold based on data we were looking at.” And I think one thing they had done is they had looked at Wikipedia, and they had started looking at like Wikipedia could easily, like most of the subdomains for the different countries could easily meet the threshold. So that was what it was based on. And I made the point that, “Okay, but one of the things to keep in mind is like when I use a CDN, if I don’t have a lot of traffic to my site, that resource that’s cached on the edge is quickly gonna get purged from their caches if other people aren’t accessing it frequently.”
Tanner: Right.
Philip: A site like Wikipedia has a huge advantage.
Tanner: It’s an interesting example to bring up.
Philip: Yeah, like they have a huge advantage because they get tons of traffic, and so they can leverage that edge caching to a much greater extent. And then about the same time, CrUX introduced the rank magnitude dimension. And if you look at TTFB and you compare the top 1,000 sites to the top 10,000 to the top 100 thousand, 1 million, and 10 million, TTFB goes slowly down. And I’m sure that it’s related to this, where the less traffic you have, the harder it is to optimize. Because you can’t benefit from that edge caching that CDNs get you.
Tanner: Right.
Philip: And this is just one example where, you know, you have to pick these thresholds based on what the entire Web can do, not just like a Wikipedia. Like you can’t, Wikipedia is a very special site that has performance engineers working, employed, like on staff, trying to improve performance constantly. So anyway, that was, I don’t know if that answers your question or I just answered a different question that you didn’t ask, but somehow I got on that tangent.
Tanner: It was a great conversation either way. Phil, there’s just so much, there’s so much to talk about.
Philip: Sure.
Tanner: Unfortunately, I do have to wrap us up here.
Philip: No problem.
Tanner: Yeah, it has been such a fantastic time getting to talk to you and getting to hear your story, and just all the things that you’re interested in and things that you’ve learned. Where can people follow you and keep up with what you’re doing?
Philip: So I’m slowly getting less active on social media as I get older, but you can follow me @PhilWalton on Twitter. We talked about, before I joined, about whether I go by “Phil” or “Philip”, and I will pick one based on the username that’s available to me. My personal website is PhilipWalton.Com. That’s probably the best place because I will, you know, no matter what I do, I’m sure I will keep that up. You know, even if I were to transition away from web development, I would probably still have a website where I put things that are interesting to me personally. Yeah, my team does a lot of stuff on Web.Dev, Developer.Chrome.Com, and so, you know, I lead the Web Performance DevRel team within Chrome. And so, yeah, I am posting less stuff myself but, you know, I’m secretly trying to insert my opinions and stuff into the stuff that my team publishes there. So yeah, pretty much anything on Web.Dev or Developer.Chrome.Com is partially falling on me, I guess. But yeah, personal stuff, my website, Twitter, I would say Instagram but I haven’t posted on Instagram in like two years.
Tanner: Hey, I’m sure you’ve got all the links on the website.
Philip: I haven’t, no. Actually, one of my plans is to eventually start putting personal photography on my own website.
Tanner: Please do.
Philip: Also, because most of my personal blog is mostly text-based, and I’m a big believer in trying to practice what you’re advocating for, and one of the things I advocate for a lot is how to build a site that has images and do it well, yet I don’t have a lot of personal experience with this. So it’s been, when I get some more free time, I plan on building a portfolio website for photography. Primarily just so that I can have a chance to play with what is the best way to create a photo-rich but high performing website. So stay tuned for that. We’ll see how that goes. Maybe like in ten years, I’ll finally get around to doing that.
Tanner: Hey, we’ll be here. We’ll be ready for it. Well, Phil, thanks again. Thanks so much. And until next time.
Philip: Yeah, thanks for having me. I look forward to the next one.
Tanner: See ya.
Philip: See ya.

Recent Posts

Archives

Categories

Links

Video

Transcript

Leave a Reply Cancel reply