Barry Pollard - Catching Up With Web Performance

Catching Up With Web Performance

Barry Pollard

00:00 / 43:07

Video

Transcript

Tanner: Everybody loves to podcast…
Tanner: Hello, everybody, and welcome to another episode of Catching Up With Web Performance, a podcast about stories of people in web performance. Today, my special guest is none other than Barry Pollard. Barry, how’s it going, man?
Barry: Good, good. How’s yourself?
Tanner: I’m hanging in there. Life is wild. Trying to edit audio, do all the things. But we’re hanging in there.
Barry: I’m interested to see the series and hear from other people. I know my own story, but there’s quite a few people I know signed up this, so looking forward to hearing them.
Tanner: Me too. Now, the gist of the show, I mean, it’s pretty simple. Every episode I ask people the same questions, like, how did you get into web performance? How’d you learn? What are things you find interesting or difficult? So I like to start with a memory, I think that’s a good way to get grounded. So I’m gonna ask you here, like, what’s your first web performance memory?
Barry: So I got into web performance kind of late. I got into the web very late, actually. The first half of my career I was in banking, actually, doing traditional software development in there. And I went to university in Scotland, in Edinburgh, and I was approached by banks in London. Went down there, did an internship for Goldman Sachs, and then went down, worked for some of the other big banks there, Citigroup, JP Morgan, and a few others.
Barry: And yeah, I was doing traditional bash scripts, a bit of C development, Java development, but I kind of didn’t really touch the web for a long time. But what I did touch was performance. So I worked in the equity derivatives space and they have a lot of overnight batch jobs that uses thousands of computes, servers that, you know, does all these various calculations to be ready for the next trading day.
Barry: And part of my role was to optimize that as much as possible because they were spending millions of dollars on servers there, and we had to use that as best we could. Some of them were very complicated instruments, it would take hours to calculate, some of them were very simple. And just throwing everything at the servers and expecting it to figure it out led to very suboptimal loading where either we wouldn’t ramp up and all the servers wouldn’t get used before or we’d…
Barry: You know, that would happen if you put a lot of simple jobs in there. By the time you’d loaded them on there, they were finished and then the next lot hadn’t finished loading, and so on so you never got the full utilization. And if you did the reverse and threw all the complicated jobs, you ended up, you know, an hour before trading opening with most of your jobs not done. And a big panic of whether it would get done, would actually get through the job there.
Barry: And so you had to balance that and optimize that to best utilize the resources that you got. And some of that was, like, it was making database queries to get a lot of the information it needed to do these jobs. And it was also farming out the jobs to these huge server farms. So that was my first sort of introduction into performance rather than web performance.
Barry: And from then on I was kind of hooked. It was a really interesting problem to try and figure out and tune and tweak and almost run real time experiments on millions of dollars worth of hardware. You know, we’d sit there, we’d talk and we’d say, like, “Let’s change the prioritization to do this and see what happens overnight.” And some of the riskier ones we’d do at the weekend where we had a bit more time to play with in case it went horribly wrong. But yeah, we were actually going in there, making changes, seeing what it was, and trying to save money because I mean, these banks have a lot of money but they don’t have unlimited money and we don’t have unlimited hardware. And even if we did, we couldn’t farm out the jobs and stuff like that.
Barry: So that was the first half of my career, and that was all spent in London. And then I met my wife, we started to have a family, so we moved back to Ireland and I had to look around for another job and there wasn’t a huge amount of investment banking jobs in the small part of Ireland I’m currently living in, in Cork.
Barry: So I had a bit of a career change at that point, and not too far because I went and worked for a health insurance company, so still finance. But I went in there as project manager, eventually running the software development team, and they had a website, and that became a bigger part of it. So I really started getting into the web there, and that was about ten years ago. And, as I say, I’d done basic HTML, what developer hadn’t at some point, but I never really understood the web as a whole.
Barry: So yeah, quite delayed, but once I got into that, again, it was this similar sort of thing, this idea of optimizing and tuning. And it wasn’t just the performance side. Initially, I started looking at the security side, we started beefing up our security there. I mean, as a health insurance provider we had a big onus on us to make sure we had a secure website.
Barry: And it was a lot of the same things you see in web performance. It was running a website through these tools, which would tell you how your TLS certificates are set up, or if you got these HTTP security headers and what you can do with those. And started learning about, you know, more complicated things like content security policy and those sorts of things.
Barry: And that kind of naturally led to other bits where, and other tools, you know, running your website through Lighthouse or some of these other tools which could spot problems. And a lot of them were, Lighthouse still is quite performance-focused, but they had other bits in there that kind of hooks in and then gets you into there.
Tanner: Yeah.
Barry: So that was my sort of earliest memory. I wasn’t really into web performance, but then it kind of started in that space and started being on that journey down to here.
Tanner: That’s so wild because, like, it sounds like you were in performance out the gate. Like it wasn’t web performance, but here we are, equity derivatives. Like, we need to make sure these operations are moving quickly and fast and efficiently.
Barry: Yeah, and it wasn’t a natural plan to go into that. It was kind of just my, the job that I ended up in. And I originally started in back office stuff and then moved to the front office and that was a key important part, and we were having big problems with that, so…
Tanner: Yeah, did you go to university and learn computer science there or?
Barry: Yeah, I did a software engineering degree, which, you know, doesn’t give you… It gives you broad strokes, and I think it is very useful, but it’s very different to the practical of actually doing stuff.
Tanner: Like what, like how?
Barry: I think it teaches you general principles. But take SQL, for example. I mean, I’m old, so web performance wasn’t a course when I was at university. But there you do a basic course in SQL, in sequel, and you know, you get to learn to write queries and you do that for a term or semester, whatever you call it. But until you’re doing it day in, day out for your job, you’re not really learning it, you’re not really seeing it, you’re not seeing, understanding, certainly the performance impacts. You get the rough concept of indexes and how they might help and so on, but it’s only by using it day in, day out that you actually see it. So I wouldn’t say people out of university, myself included, are ready to hit the ground running whenever they join a job. And graduates do need a lot of help and training whenever they go into a job.
Tanner: Yeah.
Barry: But what it does give you is a great grounding in a lot of concepts and a broad scope of the whole software development lifecycle and process and what it can do.
Tanner: Yeah. And then, I want to ask you more about education later, but making this switch from—you finish university, go into equity derivatives, software engineering, and then eventually you switch to web. Can you describe what were some of the differences, or were there differences, between general software performance, or what you were doing before, and then web performance that you were doing after?
Barry: I think there’s a few things. Like what I immediately liked about the web is you can put something on there and it’s globally available to everyone. You don’t have to package it up, compile it, create a package, put it in the, send it out in floppy disks or CDs or stick it in an app store, it’s just there. It’s available for everyone.
Barry: So that, and it’s so visual and easy to get something up there. You know, a few lines of HTML code and you’ve got a blog or even some interactive widgets. You know, menus and drop downs are very easy to add if you throw a framework at it and stuff like that. So I think the barrier to entry on the web is so small.
Barry: Now there’s a knowledge barrier, which I’m guessing we’re going to talk about here, which is much larger. But saying that, there’s a lot of resources out there that can do that. But if you compare it to, I don’t know, writing a Java program, just to try and get… Like there’s a reason that a lot of these things do “hello world,” which is command line, very boring things. To get GUIs and actual applications up and running is much more complicated. And some of these older—sorry, not older—some of these more traditional, non-web programmers—I don’t want to insult all the Java and C++ developers out there.
Tanner: No offense!
Barry: But, you know, the web is so instant. Literally, Notepad++, a few lines of HTML, open it in your browser, and it’s there. Stick it on a server and it’s there for everyone.
Tanner: Yeah.
Barry: And that was like before all this, you know, CI/CD and Jamstack and things which make it even easier for doing that.
Tanner: Yeah. Are there things then that, like, because there’s some of the differences or some of the things that excited you about the web: it’s instant, it’s publishing, the barrier to entry is so much lower. Are there things that you were able to, I don’t know. What do you think may have equipped you? Or what things did you take from your experience in software optimization and bring that to web optimization?
Barry: I think, again, I’m not very technical in a lot of things. I get massively invested and geeky about certain things and develop a passion for it like I have for web performance and read up about those. But I think what I was good at was at the broad strokes of seeing the whole thing, or knowing a little bit about this. My JavaScript is still terrible, by the way. My CSS isn’t that much better. But, you know, having a broad understanding of how it all fits together. And I guess that’s probably because I didn’t start as a web developer, and there you go and write some JavaScript code and you go up there. I kind of started as a more traditional developer, eked my way slowly into this, and so I had, I guess, some of the background of other things and backend processes and how those sorts of things work.
Barry: So I think what I found useful was having that bigger understanding of the whole thing, of how everything fits together. And also not just going, “It’s magic.” I remember a lot of my like non-IT users, they were like, “Okay, can you do a program to do this?” And they just conceptually couldn’t get the switch between what was easy to do and, you know, relatively easy versus completely impossible. So I don’t know, you’d just be doing a pivot table in Excel and they’d be like, “Wow, you’re some kind of computer genius! Whoa, can you figure out which of my customers have got no money in the bank?” And I was like, “No!” In what mind are those two things the same? But I don’t know. Again, maybe because of the educational background, having a software development degree, kind of gave me the broader picture there of doing that.
Barry: But then that also allows you to see a lot of low-hanging fruit in a lot of these things. So you can sit there and say, “Okay, the web page is served fast but then it’s taking a long while to go.” Then you know where you can concentrate on that. Or yeah, it’s taking a while to even present any of the data there. Is it your server that’s slow? Is it SQL queries that are creating the data to do that? If you’re, you know, a traditional server-side rendered application or something like that. I think that’s where it can be quite helpful to have that broad stroke and be able to delve into anything and figure out exactly where it needs to go and then farm it out to the experts.
Barry: So I ran a software development team in my last job. I say my JavaScript wasn’t great, but I would be able to identify a JavaScript problem and say, “Okay, and you, hardcore JavaScript developers, now go and figure it out, because this is the problem that we’re seeing is it’s been slow to do that.”
Tanner: Do you have an example of one of those? Like what was a time where that happened, where you said, “Hey, I’ve found a problem with this JavaScript, or something about this, we need to make better.” And then you explain that and gave it to an expert.
Barry: I guess like… We used a lot of client-side rendered stuff, so single page applications, which I think for an application is fine and there’s a small pause in loading it and then you get in the app and you’re sitting there moving around. So if you’re in a big long checkout workflow, and you’re going through steps and you’re giving payment details and your address, and then you’re buying, maybe that up front hit is worth it. Whereas for a more just home page, or an article page, less so in my mind. So we used these a lot because we had applications on our website and stuff like that. And in general they’re a bit slow to load but we knew that.
Barry: But I think what the biggest thing we found was with the whole Core Web Vitals initiative that came out a few years ago, was, yeah, we knew which pages were slow and fast to go. And in general our website was fairly fast and it would render pretty quickly. Some of the apps weren’t used as much as some of the static pages, so they can offset each other and it was, it was fine.
Barry: But where we really struggled was with Cumulative Layout Shift, or CLS. So we had these single page apps that were loading in piecemeal, content was shifting around, or quite often they were loading a skeleton page from about ten versions ago that had changed completely. It would flash on screen and then the app would kick in and move things around and do what the ultimate page was. And people weren’t concentrating that much on the actual loading, they were just sitting there going, “Yep, yeah it loads and it works,” and not seeing that. But the browser saw everything and was reporting these massive CLS shifts that were causing us there.
Barry: So that point, it’s like, okay, I don’t know SPAs, I don’t know what you guys are doing in there, but here’s the problem. Can we go ahead and fix that? Can we update our skeleton pages? Can we get it to load more progressively in sections? Can we set min-heights even? You know, a lot of them were fairly simple things that you can do just to, we know there’s going to be a bit of a widget in here, reserve that space and then go with that.
Barry: And some of that we could, you know, we could do short term. We could just add a few styles to our stylesheet to actually fix that without re-engineering the whole app. Or do that short term and then longer term say, “Okay, now do we need to do a bigger re-engineer? Do we need to do more server-side rendering? Do we need to get rid of this SPA technology completely?” And stuff like that. But that’s obviously going to take time. But there’s a lot that we could do in the meantime to just at least minimize the problem and get a nice little green flag from Google to say that all is good.
Tanner: Yeah. And speaking of Core Web Vitals then, so I’ve got a couple touch points in the story so far: university, graduated, software engineering, went into—would you call it banking? Equity derivatives?
Barry: Yeah, investment banking.
Tanner: Investment banking, yeah. So graduate from university, software engineering, go into investment banking, then get into insurance. And is this Laya Healthcare?
Barry: Yes, have you looked me up here?
Tanner: Yeah, I tried to do a little research before. Stalking, you know. But there’s, you know, there’s some, I want to hear more about this time because you switch over, you’re in the web, you have to learn, and then there’s Core Web Vitals. And you write a bunch of Core Web Vitals articles for Smashing Magazine. Like what, how, what was in between there, where you got introduced to the web, or rather, started working on the web, and then Core Web Vitals? Like, catch me up, what happens in that block of time?
Barry: Yeah, so there’s a big gap between that. As I say, I started getting into the web and that was only half my job. We still had the backend systems that we all looked at and the in-house systems that we look after as well. But I was quite attracted to the web side of it, and our website was only one small part of my role but one of the most interesting parts.
Barry: So we spent a lot of time optimizing that. And I’m obsessive by nature, so whatever I plug the website into, any of these tools like Lighthouse, and it gave me less than 100 score, I’d be like, “Oh, okay, right. What can we do to fix this?” So I’d read a lot there and find out more about what these things actually meant, because there is some understanding you need to know.
Barry: And you can’t be too obsessive, to see, that is, about these sorts of things. You’ve got to work out, is this really the best use of your time? You know, going from 90 to 99, is that really a game changer there? Is it worth it or is it mostly fast and are those tools artificially slow just to highlight problems and those sorts of things? So I spent a lot of time looking at those, understanding whether there was a real problem, which meant becoming more knowledgeable in the field. I read an awful lot. I’ve got a book face full of web performance books up there.
Tanner: What are some of the books you read?
Barry: Oh god… So Steve Souders I started with, back to the original man that kicked this whole thing off. Let’s have a look… Trying not to read out my own book. Web Performance In Action, a couple from Jeremy Wagner that I work with now. Using WebPageTest from Rick that I work with. Oh, it’s all people I work with, fantastic. Yeah, quite a few just there, and I’ve got more on my Kindle. Yeah, I’m just obsessively reading loads of information there.
Barry: Also, people were blogging a lot. I really like this about the, generally the web community, but web performance community in particular, people do blog a lot. And some of the more interesting sites aren’t from, you know, the big names.
Tanner: Like which ones?
Barry: Well, again, like individuals, individual bloggers, which is what I started doing. I think that’s more interesting. They seem more real and honest and do that. And also a lot of them, back in the early days, a lot of the big websites, you know, the Googles, the Smashing Magazines, and so on, weren’t necessarily doing so much on web performance. It was a bit of a niche topic back then, so you had to go to niche people.
Tanner: Yeah. Do you recall anybody who was talking? Or like who were some of those early bloggers that you followed?
Barry: Oh god, loads of people… Names are escaping me now. Yoav Weiss did a lot of stuff, watched a lot of talks about them. Pat Meenan’s talks are brilliant. Jake Archibald obviously does a lot of stuff in that area and does really entertaining talks and stuff like that. Andy blogged a lot and that. Tim Vereecke, yeah. There’s just loads of people in the community.
Barry: Tons of them.
Barry: They find weird and obscure things that, you know, aren’t in the manual as such, but kind of make sense once you can, again, put the whole piece together, which I find really interesting.
Tanner: Do you have any that come to mind, like any of those interesting, weird things?
Barry: So Matt Hobbs wrote a lot about WebPageTest and how to read the waterfalls, and he found all sorts of weird, obscure things with, I don’t know whether they were EV certs or CORS, his favorite subject.
Tanner: My god, Matt’s article, his WebPageTest like How to Read a Waterfall Chart is so comprehensive, it’s unreal.
Barry: Yeah, and he kept adding to that and all that. But again, it was the weird things of, “Hey, I noticed this,” it was “Why is this going?” and delving into that. And like the community’s incredibly open for that sort of thing. There’s people who engage a lot on Twitter. You know, you were able to speak to some of these people, these books on my shelf, on Twitter and they would respond back. And there’s a Slack web performance channel that’s really active. People are sitting there constantly helping and stuff like that.
Barry: So yeah, I kind of got into that and got really interested in reading that. And then responding to that, I guess it probably started on Stack Overflow, and I started answering a load of questions there. And asking very few questions, by the way. I think if you look up, I’ve asked about three questions in my Stack Overflow life and answered hundreds. I don’t know.
Tanner: That’s interesting. You learn more by answering than by asking?
Barry: Yeah, and I find mostly the problems that you got aren’t unique. And there’s a wealth of information out there if you just know how to search for it. And I think searching is a skill that, again, some people have and some people don’t. So if you dig hard enough, you can usually figure it out yourself. And, as I say, you’re not unique, there will be someone who’s experienced the same problem. Hopefully they’ve written up about it.
Barry: And then that’s the other thing, is whenever you find something that’s slightly different or took you a while to figure out, I love to blog about it, I love it when other people blog about their, and other people can learn from it.
Barry: So yeah, outside of my job, I started blogging at that point. And again, the barrier to entry is cheap and relatively simple. So my blog hasn’t been touched really since I put it up there, it looks awful. I don’t think people are coming there for design tips or anything like that. But it’s functional, it’s got a load of articles that people started reading. And again, sticking Google Analytics in there and seeing that people from China or Australia or whatever were benefiting from just some random stuff that you put on there was really engaging. I’m pathetic and needy and need this validation.
Tanner: We all do!
Barry: People email me and say, “Thanks very much, this is helpful, this is really useful.” Which I was like, “Oh, cool, this’s really good.”
Tanner: Yeah.
Barry: And then after that, yeah, like a publisher approached me and said, “You wrote a post on HTTP/2. We’re considering doing a book in the area, in that space. Would you be interested? And if so, would you like to submit a proposal?” So I did that thinking, “This’ll take a couple of months and this will be good.” Fast forward two years of my life later and I eventually got a book that sold very little.
Tanner: This book?
Barry: No, but that was really interesting—that book! Oh yes, sold at least one copy.
Tanner: There was a shipping delay, so I wasn’t able to get the physical copy yet, but I was very excited to have this. I’ve had the digital copy.
Barry: You could’ve got away with it, I didn’t even notice because you printed it out in color there.
Tanner: Yeah. So two years, my lord. You spent two, you started with blog posts, somebody asks you to write a book and you do it. Two years. That’s wild.
Barry: Yeah. I mean, that was, I find that really interesting. Like for start, HTTP/2, at the time, was relatively new. I mean, it was out there, people were using it but, and there wasn’t a lot of material available to it. So I started looking at it and I had to hobble together all the information from a lot of these people I mentioned previously. I think Pat had done a load of good talks on it, Jake and Yoav have also published good articles on it.
Barry: But yeah, you had to hobble it all together to try and figure it out. So whenever they said there, “Hey, are you interested?” I was like, “Yeah, this actually, this could make me a millionaire and I could have thousands of adoring fans all over the world.” It turns out, no, not so much for a little niche topic like that.
Barry: But no, I thought it would be good. I always liked writing. I don’t have a problem muttering on about things, as I’m sure you’ve noticed on this podcast. And I find it quite relaxing. I had a young family at the time. I wasn’t able to do any of the writing in the week. I had a day job and I had a young family, so that was a write-off. I read in the evenings and stuff like that, but didn’t really do any of it. And Saturdays I kind of took for the family. But my wife was very, very good to me and understanding and she took the kids off on Sunday. And Sunday I would spend, you know, eight to ten hours in front of the computer, either researching stuff or writing or, more often than not, deleting and starting again.
Barry: But it was kind of calming. It’s kind of nice to do that. And it was on my own time. I mean, that’s why, I’m sure you could bang out a book a lot quicker if you’re doing it full time. But I was doing it one day a week over the two years, so don’t feel too sorry for me. And I managed to get away from the screaming kids at that time.
Barry: But I really delved into that topic, really did that and spent a lot of time, learned a lot for myself. I think there’s this, I don’t know if there’s an old adage or something. “If you want to learn something, write the docs on it.” Because you’re going to have to figure it out and do that. And then I finished it, put the pen down and was very happy, hand it over to the publisher, and then the IETF announced HTTP/3 and I was like, “Oh for goodness sake. Timing is useless!”
Tanner: It just keeps moving.
Barry: So I managed to tweak it slightly during the editing process to put a few sprinkles of HTTP/3 in there, but yeah.
Tanner: This is wild, because I feel like you’ve covered, it sounds like, the whole learning spectrum, right? Like from going to university, going to a job, switching jobs, learning on the job, then learning through Lighthouse, getting obsessive about the metrics and scores that it gave you, trying to learn more about those, going to Stack Overflow, listening to talks, finding people, reading books, you know, then getting deeper in, not just reading books, but finding those people, finding the blogs, and eventually writing your own book.
Tanner: I don’t know how much further you can push the learning spectrum there. Like, that’s wild.
Barry: No, but I mean, that’s the thing, is there’s always something to learn. It’s such a wide scope, the web, and web performance even as part of that. No one’s ever going to be an expert in it. And it’s changing so much anyway. And I think I’m fascinated in two ends. One is, I say there’s a lot of low hanging fruit. Nothing annoys me more than a website that’s bad. And by bad I mean slow often, or just doesn’t load or breaks half the time or, you know, you click a button and it’s, you get a JavaScript error pop up instead of it submitting. You know, “Oh my god.” So a lot of those can be fixed quite easily, which is even more frustrating that they don’t fix these things.
Barry: So that’s one thing is like, oh, actually it’s quite easy to fix a lot of these things. And yeah, some of them are more complicated and you have to go down the rabbit hole and get weirdly obsessive like I do. But a lot there is, there’s fixing, but that’s one good side.
Barry: On the other end of the spectrum, there’s a lot of really fascinating, nitty gritty problem solving things to figure out where something should work, but it’s not working and why is this? And there’s this whole web, for want of a better word of interconnectiveness, of how things can, you know, subtly change something else, or knock something else on or knock something out of bounds or something like that. So again, that’s also fascinating to me, is there is no easy fix. You really have to delve in and figure that out. And it might not even be anything you’re doing wrong. It could be a browser bug, or the feature just isn’t working as it should, or it’s still in the way of standardization and it’s only partly there and that particular use case isn’t there yet and will come in the future, and there’s not much you can do about it.
Barry: So I think you can always find something of interest to go there. I don’t think at any point we’ll close the book on it and say, “Yep, web is done.”
Tanner: Yeah. And, you know, speaking of it being so large and just like, “Oh!” but not only web performance but the web. I’m curious, how do you think about web performance, maybe in general? Or if I had to push you to give me a definition, maybe like when you think of web performance, what stuff do you think of?
Barry: I honestly come back to my initial definition of a good website. And you can put it down to metrics of whether it’s, you know, the older load time metrics or the new fancier Core Web Vitals user experience metrics, or just gut feel of, “This is a bad website.” People know it whenever they see it, you know. You can go to, quite often your internal apps, your expenses apps or whatever, they’re usually great candidates for bad websites because you’ve got your captive market and they don’t have to do it. Whereas, you know, the more competition you get, usually not a terrible website might be able to to load faster, might be able to be slightly nicer in certain things, but it’s usually not a terrible experience.
Barry: But what if you load something and you’re staring at a white screen for ages? Or, like I’m just outside the city of Cork, and it’s quite a small city and it’s not long till you go out into the countryside, or you’re on a train and, you know, nothing loads and you have to refresh a few times and you’re still staring at the white screen or, even worse, an SPA spinner.
Barry: And those things annoy me and frustrate me and I’m just like, “Oh my god, how can you have such a bad website? How can you not have personal pride in what you’re producing? How are you happy with this?” And I know there’s constraints and people aren’t doing it, but certainly whenever I was in charge of a team that did that, I did my best to make sure it was a good website, it loaded reasonably quickly and was, you know, pleasurable to use rather than a pain to use, that you’re only using because you got no choice.
Barry: So yeah, web performance. I think what’s interesting is a shift from just load, which is still important and still being measured by this LCP. But I think the other parts of it, the shifting stuff around, I think CLS is my favorite core web vital. I love that. It’s like it brought a new dimension to web performance that a lot of people, myself massively included, had kind of ignored. We knew it was a problem, but we were like, “Eh, it’s not a big problem.” And then kind of it was thrown on the front our face of, “Well, now it is a problem. Now you have to fix it.” It was like, “Yeah, it is. And we should have fixed it a while ago.”
Barry: And like, websites are getting more pleasurable to use there. Like if you’re loading, I keep using BuzzFeed as an example, but they’re really annoying because they’ve actually fixed it. They used to be the worst sort of thing, whenever you went to those certain websites and ads would pop in, the article would spin down, and you couldn’t, you lost your place, and that would be really irritating. I know they did an awful lot of work to try and fix that, which, again, I think was driven by that initiative, which is really good.
Barry: So it’s not just about getting something on there, it’s actually making it usable once it’s on there. And then even after that, you know, buttons should be responsive and click, and moving around, scrolling shouldn’t be all jittery and yankee and so on. I think that, again, we’re kind of, we’re at a point of evolution in web performance where we’re moving from page load as a measure to full page lifecycle, which is quite interesting because it’s kind of the next step of, “Yep, we knew about that for a long time. Not everyone fixed it, but we knew it was a problem.” Now there’s all these other things that we kind of intuitively, or maybe at the back of our heads, knew it was a problem but never really surfaced before as, “That’s web performance.”
Tanner: Right. Yeah, I think CLS, in particular, really… Before CLS, I think we mostly talked about web performance as speed, time. It’s all about time, it’s all about speed., doing things fast. Whatever the thing is, whether it’s loading or responding, like, do that thing fast. And then out comes CLS, “Oh, by the way, there are things that are not about time.” There are things more about the experience, layout shifts, like there are other things that can cause a frustrating experience. And, you know, then we get notions of smoothness or battery life, I don’t know, energy efficiency. And I’ve seen a lot of other interesting talks about performance and I think, yeah, CLS feels like it single-handedly blew open this notion of, “Performance is not just speed.” It’s this whole, I don’t know, package of experience.
Barry: Yeah, I think there’s two things that the Core Web Vitals Initiative brought in. I mean, there was the whole SEO big stick, which give it the emphasis it had. But ignoring that, the two things it brought was, yeah, some of these different metrics from page load, and then the other big change was looking at field.
Barry: So it didn’t matter what Lighthouse was, it didn’t matter what that green 99 score was. It was your users are all on worse devices or worse networks than you are with your big fancy computer right next to the server room, and they’re a lot slower than you are. Or again, come back to full page lifecycle of your CLS is fine on loading but as soon as you go to another page or scroll down, there’s a lot more CLS there that was hidden that you didn’t see from these traditional tools that measure just page load, and they’re just as disrupting. And now boom, it’s in your face.
Barry: So I think whoever came up with that concept of measuring field rather than just basing it on Lighthouse scores was genius.
Tanner: Man. Yeah, field data, actually. That is such a good point. I’ve been trying to reflect on the past two years for me and like how Core Web vitals has reshaped my understanding of performance. And field data, like single-handedly… I literally did not know what a percentile was until Core Web Vitals.
Barry: You do now!
Tanner: Right! But you know, this is a whole nother side of things. And then maybe this is a segue, or place we can go to. Because Core Web Vitals came along and all the sudden I needed to know statistics, at least to some degree. Like I didn’t know that web performance was typically a log normal distribution, I had no idea what a long tail was. That concept never, I never heard of that. And then all the sudden, “Oh yeah, here, actually, there’s a distribution of users.” I didn’t think of people in distributions, I didn’t know that was a thing. I’m curious, did you have a similar experience? Or what’s been your experience with field data? Maybe I’ll start with that.
Barry: Well as I say, I think, again, the field data, in my mind, is two things. One is not everyone experiences it the same, and you have some people that are on worse phones, worse networks, or whatever. That’s definitely one big aspect of it, I think we kind of knew that. And, you know, some people with RUM solutions that told them that before, but in general, most people, the vast majority, didn’t really care about that and they just stuck it in Lighthouse and got the green 99 and were happy. So that’s one thing. And I think there is also, because they have a lot of noise in there, and I think this whole percentile thing that you alluded to there, the fact that Core Web Vitals ignores, only looks at the 75th percentile, so ignores the really extreme cases. I don’t think you really need to know that much more unless you really want to get in too deeply.
Barry: I mean, I think that’s the concept of they do try to simplify it. They do sit there and say, look, these three metrics, rather than the thousands of weird DOMContentLoaded and whatever the heck that means, and this, that, and the other, there’s three things that are relatively easy to explain conceptually, at least.
Barry: LCP, what’s your biggest content? When’s it getting on the page? How long does it take to get on the page? Okay. And you can go into the detail of when’s it measured, what does it include, redirects, does it this, does it that, and so on. What counts as an LCP element, what doesn’t, stuff like that. Forget it. At a high level, the biggest content, how long’s it take to paint the page? I can explain that to my father and he’ll get that.
Barry: Similarly, CLS, how irritating is it things moving around and when you click on the wrong button, or you’re reading an article and you lose your place and stuff like that. Massively complicated to think about how you measure that. But at a high level, quite easy to explain. And you can sit there and say you’re passing or failing or needs improvement on that. It’s, again, traffic light system, quite easy to understand.
Barry: And FID, nobody talks about FID, so we’ll kind of ignore that a minute.
Barry: But yeah, I think explaining that sort of thing and that necessitated, because field data is so noisy, it necessitated taking rid of that.
Barry: But the other side of of field data that I think is as important, if not more important, is the whole measure of the page lifecycle. So as I say, rather than just a page load and what appears above the fold, as you scroll down, as you interact, as you do other things, what else is happening on your page there and how does that affect you? I think, again, you can’t really measure that except with field data. So yeah, being able to see that and understand that, “Oh, I thought it was perfect because I loaded it in Lighthouse and I didn’t scroll down,” versus, “Oh, right, okay. There is this weird thing further down.” Or for this subset of users that are logged in and get a slightly different experience, or this other user who, I don’t know, is no longer a member and gets a different banner image saying, “We’re sorry to see you leave,” compared to the vast majority of users who are getting that. That’s the second aspect of field data that really got exposed.
Tanner: Yeah. Which, speaking of different users, I recall you wrote an article for Smashing Magazine. You actually did a case study on Smashing Magazine’s performance. Were there any interesting takeaways from that? Or can you tell me more about that experience?
Barry: That sounds like a leading question, like you know the answer, but yes.
Tanner: You bet it is.
Barry: So yeah, I started, back to my story, I started blogging a lot. I wrote this book and then I started writing a lot for Smashing Magazine. Actually Jeremy, who I now work with, reached out to me, so you have him to thank for my long posts in there because he was the first person to reach out to me.
Tanner: Thank you, Jeremy.
Tanner: Yeah, so they, because I’d written a couple of articles, Vitaly reached out to me and said, “Hey, we’re having problems, we’re not meeting this. We thought we had a fast website. What’s going on? Why are we failing to meet this?” I didn’t work for Smashing, I’d written a couple of articles for them and that was it, but this was quite an interesting thing.
Barry: And again, I just got my, I got nerd sniped. So I spent a long time looking at it, trying to figure out what was going on here. Because at the same time, I was trying to figure it out for my day job, but I was also figuring it out for my after hours geekery in blogging.
Barry: And I was like, Smashing Magazine is a fast website. You know, they have spent an awful lot of time optimizing. Vitaly runs a course on web performance, and he used to produce a big, huge checklist of all the web performance changes that happened that year. So the fact that he couldn’t get it right was interesting to me. And again, plugging it through the Lighthouse and stuff, it did show it as fast, but it was showing as a problem in their Core Web Vitals and in their CrUX data.
Barry: So I spent a lot of time trying to figure out what that was. And it was certain pages, and it looked to be a lot of older pages rather than newer pages, and we couldn’t figure it out for a long time. And then we started collecting their own RUM data. Because, like, Google makes a lot of it free through CrUX.
Barry: I think actually, slight adjacency there, that’s the third good thing about this field data, is they’ve basically given a reduced field data solution to everyone. I don’t think it’s a full RUM solution. But, and it’s all very high level and it can be frustrating that you can’t dig into that and so on. But they’ve basically said plug in any URL into PageSpeed Insights and you can see what any website, their field data looks like. Are they a fast website or not based on their users? Which again, I think just democratized field data. Before, RUM solutions were very niche and often quite expensive, and people wouldn’t think about them unless you had the budget signed off by your IT director to install this and spent a lot of time doing it. Whereas suddenly boom, you just had it there.
Barry: Now I don’t think it’s sufficient and I think you do need to, if you are wanting to invest in web performance, then you should invest in a RUM solution top. Because I often said, actually I just wrote an article in this, but the differences between CrUX and the other one is CrUX will often tell you you’ve got a problem, but it won’t tell you enough detail to say where or why or how, whereas a full RUM solution…
Barry: And look, it’s public by nature. There’s, you know, there’s some stuff that they can’t make available to everyone about other people’s sites, it’s not very fair. Whereas a RUM solution that only you can see and you can control doesn’t have any of those limitations, and can see that.
Barry: So yeah, so we installed—and there’s even free ones. Google published one, web-vitals.js, that you can plug in your website and it can feed stuff back to something like Google Analytics and you can go in there and slice and dice it as you see it.
Barry: And at that point, we saw after we’d done that, that a lot of the slow coming traffic was coming from traditionally slower countries. So India was a huge part of Chrome’s, or sorry, of Smashing Magazine’s visitors. Well, interestingly, it wasn’t a huge part of their total visitors of website whenever we looked at the analytics. But whenever you remember that CrUX is only measuring Chrome, and if you filtered it only in Chrome, suddenly you’re getting rid of all those iOS users in the richer Western part of the world. And suddenly that had a much bigger percentage population of that. And suddenly it made much more sense of what they were slower.
Barry: In the grand scheme of things, if you look at the total population, you can argue CrUX isn’t fair because of this. But look, it’s a limited view, and it was highlighting a problem there that they were having much slower experiences. And that suddenly then made sense and went, okay, right. Smashing Magazine is fast for Western people and faster internet connections and decent devices. And it’s not slow in those compared to everything else, it’s just they’re naturally slower networks, slower devices, older devices that often, you know, didn’t have as much memory or CPU and stuff like that.
Barry: At that point, we looked at some of the options there. We slipped on, we actually did a setting where we didn’t load web fonts. If they had Save Data set on, because a lot of them did have Save Data set on. And that brought it back enough, which is good because Save Data seems to be in a bit of a, it’s kind of moved into a different setting, its usage has massively dropped, which is disappointing.
Barry: But yeah, that was that was really interesting to spend ages drilling down into that. And, you know, that was the ten minute, or ten second, quick problem to solution. But it took months of figuring it out and trying other things and trying this and then going, “Oh, no, it’s not that,” and stuff like that. Again, I wasn’t working full time, I was just answering a couple of pings from over Twitter saying, “Hey, what do you think about this? Should we try that? Or what do you think about that?”
Barry: But whenever we nailed it, it was very satisfying to know why it was and understand why it was. And then not just go, “Eh, well, they’re just going to get a slower website. What can you do about it?” To actually sit there and take it to the next level and go, “Okay, what can we do about it?” Do they need web fonts? Is it a better experience for them not to have these web fonts that don’t make that much difference and actually have it faster? And also, you’re then at that point fixing the Barry Pollards who are on this train down in the outskirts of Cork who’ve got very limited reception. He won’t get the web fonts either. It wasn’t something specific for India users, it was for slow users that this happened. And therefore my experience got better in those extreme conditions and so on.
Barry: So whenever I published that there was a load of people saying, “Oh my goodness, I knew there was unfairness,” and, “How dare they,” and, “Should we block off certain countries if they’re not adding to your bottom line?” And stuff like that.
Barry: And I’m like, “You’re taking the wrong thing out of it!” I thought it was an interesting thing, and I also gave the solution, which by the way, is much easier than you blocking stuff off. And if these people are a large portion of your traffic, you’ve got to ask yourself, “Why?” Are you wasting money on SEO efforts pulling these people in if that’s not the people that you want? Or is it?
Barry: Smashing Magazine is different, it is a global magazine. But if you’re a retailer that doesn’t really sell to India, maybe you’re like, “Well, why should I do anything for these people? Because they’re not even selling.” I can understand that different story, but then I would argue, why are you getting so much traffic from there? Are you wasting your ad bucks pulling that traffic in instead of pulling in real traffic? You need to look at that and actually see that.
Tanner: Man, I feel like we could do a whole nother couple hours talking about like, “How do you know? How do you choose? What are these trade-offs?” Like, man, tons of great stuff. Unfortunately, we are coming close to time, so we’re gonna have to wrap up here. I’d love to know maybe in closing here, just like what are you doing now? And what are, where are your interests leading you now?
Barry: So I’m incredibly lucky in that I moved off my last job that I spent a lot of time talking about and I work for Google now, working on Core Web Vitals. So I’m getting paid to do my, what I was doing in my spare time, to do that full time.
Tanner: That’s fantastic.
Barry: And yeah, no, it’s a bit of a dream job for me, so I’m really happy. Been here a few months now, and I’m working in the DevRel team, so my job is literally to speak to developers, do this outreach, do a lot of the stuff that I was doing, blog as what I can, go to conferences. But as I say, I get paid to do this full time as opposed to a very small part of my last job, which I probably overextended and definitely did into my spare time. So my wife’s happy that I might get some of the evenings back to spend with her rather than geeking, because hopefully I’ll get enough of it during the day job.
Barry: But no, and I say, I get to work with a lot of these people that I’ve admired and read up for a long time. So it’s fascinating to chat with these people every day and see how they’re approaching things. And being on the inside, you know, there’s a lot of, “Oh, big evil Google doing this,” or, “A big corporation telling us what to do,” and stuff like that. But working here, and again, I’ve only been here a short time, it’s just people genuinely trying to do the right thing and trying their best to do it. And they haven’t got it all figured out yet either, but they’re doing their best to fix that. And there’s always bugs in software and there’s always things that we can do better, but it’s a never-ending journey that we’re just going to keep on trying to walk down.
Barry: So that’s what I’m doing now. And I say, it’s been a few months, so I’m sure I’m gonna find out next week that all the bad bits of the job that are horrible compared to what I’ve enjoyed doing up to now. But so far seems to be going great.
Tanner: Well, that’s fantastic. I’m excited to hear more from you, excited to follow along the blog posts, see the outreach of Barry Pollard. Thanks so much for coming on the show, Barry. Really appreciate your time.
Barry: No problem. Thanks very much for having me.

Recent Posts

Archives

Categories

Links

Video

Transcript

Leave a Reply Cancel reply