Medhat Dawoud - Catching Up With Web Performance

Catching Up With Web Performance

Medhat Dawoud

00:00 / 52:37

Video

Transcript

Tanner: Hello, everybody, and welcome to Catching Up With Web Performance, a podcast about stories of people in web performance. Today, my special guest is Medhat Dawoud. Medhat, how’s it going, man?
Medhat: Yeah, going well. How’s it going with you, Tanner?
Tanner: Oh, you know. My background’s too dark, want to get a light some day. But here we are!
Medhat: Yeah, same for me as well. As I told you earlier, it’s still a new man cave, so it’s still empty as well. So don’t feel ashamed about that.
Tanner: Oh, man. We could talk for hours about YouTube advice, because I know you have tons of content, tons of stuff that you’ve been doing. I’d love to hear more about how you even got into that. So each episode here on Catching Up, I ask people about their stories. Like, I just want to hear your story. How’d you get into web? How’d you get into web performance? And then see what we can learn from your experience. So maybe if you can think back, like, what’s your first web performance memory? How did you get started?
Medhat: Yeah, well, that’s a tough question, to be honest, because I started more than ten years ago in the web industry. And back in the day, there were not frontend and backend work. It was something called “web developer,” what they call nowadays “full stack developer.” I’m kind of against this term, but yeah, that’s another story.
Medhat: Now, like, seven or eight years ago, I shifted myself completely to be a frontend engineer. It was still tough back in the days to make the switch because everyone was focused on, you know, there is an engineer doing everything. And most of the engineers who are doing backend, they suck at making any frontend thing. I know it. I’m talking from experience, I worked with too many of them. At some point I worked as a consultant. I was working cross-cutting different projects as a frontend engineer, not to do the whole project, but only to fix the problems that backend engineers made to the user experience in the frontend.
Medhat: So this question, I’m saying it’s tough because I can’t really remember the first attraction with web performance. But I can remember that I care from the beginning about the user experience, and I consider web performance is one of the user experience. Our main goal in enhancing performance is to make the web accessible, or more accessible. Right? So yeah, that’s something that, as far as I remember, there’s not a particular story, but it was just coming by different projects. And every time I hit something and I find that the user is complaining about something, so I start learning it, making some documentation about this, and it comes yada, yada, yada like this.
Tanner: Man, I feel like you… There are so many details that you just quick cover that we could dive into. Because like, I mean, a story of ten years, right? Like, you’ve got, and even talking about performance and user experience. Maybe we could tweak the question a little to, “When was the first time you remember thinking about user experience?” Do you have a particular user experience memory?
Medhat: Yeah, it’s not I think about the first one, but I can talk about one of them. We used to have some project that creates too many requests in the page load. And what hits me when I find that there’s a lot of requests that are repetitive and sometimes it’s double requests as well. The solution back in the days was very tough to solve this double calls thing. I wrote even an article recently about that.
Medhat: But we find out there’s something that was not fully supported yet called AbortController. And that was a magical solution for that thing, is to only keep the latest one that you made and cancel any repetitive calls. So even if you are making, like, a search box or something, and you are making a typeahead, imagine you can just make a debounce or something, a debounce effect. But what happens is that you are making the debounce effect in a fixed amount of time. So you give it even 1 second, let’s say, and this request takes like 4 seconds, and during this one second it’s over and you’re making the request and the user starts typing again. So imagine there is more and more things happening in the background, but using something like AbortController triggered this web performance thing in mind. And I used it in different projects as well. It was for me a very, very important deal.
Medhat: But if we think back in the days, a little bit back as well, like ten years ago, or maybe eight years ago, it was mostly about jQuery. And the more you want some more functionality, I would say, the more you are searching for some jQuery library to fix it. We are not usually making the fix ourselves. And maybe nowadays NPM packages is the new jQuery libraries. But that’s something that I wrongly used to do, is to search usually for a new library to do something for validating this, for changing this font, for making or checking if the user is authenticated or not.
Tanner: You wouldn’t think first, “I can fix this. I know how to do this”? You would search for “library that does thing I want, thing I need”?
Medhat: As a junior, I did that a lot, yes.
Tanner: Wow, yeah.
Medhat: Yeah, and by time I had a project. It was, I was working as a consultant as well, and I had a project that was suffering from performance too much. It was about 200 pages, the project itself. So you need to be in a good performance space, because it was about making a live camera monitoring for security, something.
Tanner: Oh, really?
Medhat: Yes, this needs a really good performance. Not only about the camera itself, because this streaming can be done using, you know, Socket.IO or something. But the site itself should load fast because if there is a hazard or a problem happening, you need to access it as fast as possible.
Medhat: Then I had this thing that we use too many libraries, jQuery libraries, that we can really get rid of them. You know? And if you remember, like eight, nine years ago, we don’t use these bundlers that we have nowadays. We don’t have Webpacks, we don’t have Rollup, we don’t have this stuff. We used to have something more a task runner, if you remember.
Tanner: Yeah, like using Grunt or Gulp or something to concatenate all your scripts.
Medhat: Yes, Grunt! I forget its name, it’s Grunt. Yes, we used to use Grunt.
Tanner: The warthog with the horns sticking out?
Medhat: Yeah, exactly. And even the libraries were not from NPM, if you remember, it was from something called Bower.
Tanner: Bower, yep.
Medhat: Yeah.
Tanner: Rest in peace, Bower.
Medhat: Yeah. So from there, I start eliminating libraries, sanitizing them. And this was, as far as I remember, one of the first things that triggers me that this matters, performance matters. It’s not to add the more you want something, the more you add libraries or something that someone else wrote. It might be very bad performance, but you just add to your project.
Tanner: Man, I’m piecing together here the story blocks of Medhat. You’ve got ten years ago, you get started. Somehow, out of the blue, you’re a web developer. We don’t have frontend and backend at the time, we’re just web developers. You come in, you start working. You’re in the full stack, so you’re doing backend and frontend, but somewhere along the way, maybe three years in, you decide, “I want to be frontend. I really like the frontend.” Something changes your mind there, something makes you fall in love.
Tanner: Then you’re working on these projects, you’re doing a lot more with frontend work, a lot of jQuery, a lot of jQuery libraries. The way that you work, you don’t just fix things yourself, you actually are searching for tools that other people have put together to solve your problems. You’re like an, I don’t know, a collector or an aggregator of solutions. You know, “I don’t really solve it myself, I go find somebody and then I piece all the bits together.” So you’re a librarian of solutions.
Tanner: And then something else happens. I feel like there’s a gap after that, where eventually, “Web performance!” You’re writing blogs, you’re doing YouTube videos, you’re a Google expert, and now we’re here. Does that kind of sum up or are there gaps in there that we could fill in a bit?
Medhat: Yeah, I can just get you through, you know, quickly, briefly about the rest of the story. From there I moved from a company to a company. Like after this incident, as far as I remember, like six other companies I worked for, and different sizes of the companies. And in each company you are responsible of something that, by a way, you are hitting a user experience. And user experience, including this web performance thing.
Tanner: Every time you built something, there was a user experience involved that you had to care about.
Medhat: That’s absolutely true, because you’re a frontend engineer. You’re hitting everything the user can see and interact with, is your responsibility. So user experience is, yeah, a big part of your life as a frontend engineer.
Tanner: Can you tell me about that actually? The moment when you said, “Frontend, I’m going to focus…” What was that? Do you have a, can you recall when you decided frontend was the thing?
Medhat: It’s very hard to say that, because it happens that I get a lot of compliments about what I’m doing as a web developer before shifting to frontend in this, what we call now frontend engineering, which is user interface, thing.
Medhat: So we used to create a project, me and my colleagues, backend-wise, no offense, that was using PHP. And I was working with them in different features, and we just threw it there for the user and let’s see. Somehow I was just caring too much to make what we do in the backend is something that needs to be well-represented.
Medhat: So after all the work, I stay as a late person doing this cleaning up, making this very good user experience, trying to enhance performance. Just postpone this, defer this script, and do this and do that. And every time I do that, after demoing this project, I get a lot of compliments for that work. They always say that without this part of work, our, you know, maybe harder work (they thought that) would be nothing, wouldn’t be really…
Tanner: What was this project that you did?
Medhat: Oh yeah. The first project was something for, it was in college, it’s more than ten years ago. It was a project for software engineering. It was, you know, a forum thing, a normal thing with normal CRUD operations and this kind of stuff. And we need to get like forty degrees if we finish it. We, I get the compliments even from the professor, that if it’s not well-represented, you would be just like the other students, what they did.
Tanner: So this is a school project?
Medhat: It was a school project, yes.
Tanner: You’re in school, you decide you need a forum, so you start working in PHP. So this is before the ten years!
Medhat: It was before, yeah. I’m trying to get, you know, as old as I could from the stories but this happens again.
Tanner: It’s fascinating.
Medhat: Yeah, it happens again after…
Tanner: From the beginning you’re like, you’re the one burning the midnight oil.
Medhat: Something in my genes, I can’t just control it. I care about this thing. Some people can say it’s a control freak, but no, it’s… I do care about this. I’m always defending the user experience. And even in my recent project, to be honest, just a quick, brief thing…
Medhat: We had a project that we are replacing a big application that was using Access and Excel sheets. It’s a very legacy one. But a specific process, for a user to do it, it takes like 15 minutes to finish this upgrade thing. What we did is, as an MVP, it takes about 20 seconds. I was…
Tanner: Oh my god! Sorry, you went from 15 minutes to 20 seconds?
Medhat: Yeah, yeah, but this makes sense because…
Tanner: What?! Paint the picture for me, because I hear Excel and Access and spreadsheets. Why did it take 15 minutes before? What did you do to make it 20 seconds?
Medhat: No, no, no. It’s not really, it was not a development effort before. It was a lot of manual work, okay? But to process this data and manually do everything was taking 15 minutes. It’s not only about the development time, you know? This process, we just sit with the user, learn the user experience, what they want to do, the user flow, and from there we learn it. I started the MVP from scratch and we try to minimize the time as much as possible. You can imagine that for the entire company, this process of planning that we minimize to make it in a few minutes was taking about 16,000 hours a year. Okay, that’s a lot. That’s a lot. Now it takes way less. But yeah, here’s the twist is coming still.
Medhat: I make it 20 seconds, and the users were very impressed. This process takes like six months to build this MVP. But what happens for us is after a while this amount of data, huge amount of data, has been doubled or tripled, so it becomes like 30 seconds or 40 seconds. Imagine that the user in the end, we talk to them. I was challenging that. I was talking to my team and saying, “This is not acceptable. This is nonsense to open the page and wait for this amount of time after you select all the filters.” And we asked the user and imagine how the user behaves to do this. What’s their reaction?
Medhat: They accept it! They just said, “We used to have 15 minutes. Why not wait one minute for that?” So what is the moral behind that is that performance as well is something, you know, relative. If the user get used to very slow application and you build something that is slightly faster than what they used to, they will be happy. So yeah, from there I just… Let’s get back to the story. Sorry, I’m getting you back and forth.
Tanner: You’re good!
Medhat: But yeah, back in the story. When I worked on this project and the users were really impressed about the amount of work, of course it’s a team effort, but this amount of effort we put in the user interface in the end just framed all the work of the whole team in the background. From a team to a team until I worked, as I mentioned before, as a consultant in a company, instead of working in one project, I was used exactly for this thing: to be just boosting the UI, you know, for different projects in the same time.
Medhat: So I was like, you know, a polisher for each project. I’m getting in, reviewing it, giving some advice, and from there it becomes like part of my personality. You know, “You have to care about performance, you have to…” But don’t care too much! Because the user might not just appreciate what you are doing.
Tanner: That’s interesting. I feel like there’s two very interesting things here. On the one hand, we’ve got working on something that’s yours, you cared deeply about, and you’re going to stay late to make sure it’s perfect, and switching from that to just giving advice, giving your opinion. I’d love to know more about that, as well as how do you balance, and what do you do in those moments where you want something to be so much better but it doesn’t make a difference to the people you’re doing that for?
Medhat: You need to learn your users, first of all. And as you know, in performance, we have two types of testing. The first one is lab testing and another one is field testing. So about the lab testing, it’s about the tools that you’re using, that you are making some assumptions. So, first of all, you’re studying the market, you know your users, how many of them are using phones, how many of them are using desktop, how many of them are using tablet?
Medhat: So if the majority of your users and your application is being used on desktop, don’t push yourself too much to make it performant on mobile. That’s something that takes time, consumes time, effort, and a lot of engineers. You know, smart engineers need to work on that to make it smart and fast. So if you learn your market, first of all, use the right tools to measure that and make your assumptions correctly.
Medhat: This is the lab testing. Gather all the information, enhance it to make just a baseline. If you have this baseline of performance, now you are good enough. You are not so good, you are just good enough to the level that people might say, “Right, this is not that bad.” This is using the lab testing. But the most important thing is field testing. Field testing is using something that is measuring a real opt-in user, and this is really, really very useful, very accurate. And you can build decisions based on them.
Medhat: The different metrics as well matters. You need to think about which metric you need to think about the most. So if it’s for you, for example, the Core Web Vitals nowadays is really, really important. You need to care about the interaction with the user, the FID and Largest Contentful Paint and Total Blocking Time. These kind of stuff are not something that if you did you are making a great effort or great progress. Now you’re doing the minimal thing you can do to make your website performant.
Medhat: So back to your question about how you make a decision for enhancing performance. First of all, the user. The user decides. As I told you, I made a recent project and the user accepted one minute waiting because of their past user experience. So learn from your user not to make a lot of effort for nothing.
Medhat: I hear from some people that they are making, you know, a sign up page and they are making it very performant. Man, come on. If someone is coming to this page and they are going to sign up for your project, they are not really caring about that it’s blazing fast when we click the button, “Boom!” and you have confetti coming from the top. No! They just care about, “Just get me in!” And from there, they are going to use this application from inside. Care about your application. Don’t care about these kind of pages that if they came here they’re already interested. Right?
Tanner: The signup form is completely different from your security camera monitoring application.
Medhat: Yeah?
Tanner: Is it? I guess? Or like, how, when you think of those two examples, how would you compare your sign up form to a security app? Or your live camera monitoring application, if you go back to that example. How would you compare those two?
Medhat: Again, for me, the user is in the center, always. Okay? How often the user is visiting this page and how often they will use the other page? How critical this page for the user and how critical the other one? For me, the application itself, if the minimum viable product for the application is the landing page, which has a calculation or something, for me this is the most important one that I will put the effort to make it very performant as much as I’ve got. But if the sign up page is something that will be used only once per user, and after that they will never, ever visit that again, I don’t care that much about being very performant. Of course, I need it to be, as I said about the lab testing, to be the minimal level of performance. But not to be very, very performant. I’m not going to put any effort in that, to be honest.
Tanner: Right. I guess what I was trying to get at with the security example, when you were talking before about the live camera monitoring, it felt like there was something about that that felt more urgent. Like the user who is just using a sign up form, “Just let me in, I want to get in.” I’m not too worried about how quickly the page loads. But the security monitoring, like, that needs to work. “I have to see, I need to know when things change.” And those feel very different.
Medhat: Yeah. As I remember, as well, for this example, one page in this project was to have like a big canvas on top of the video. So the security man can just draw something on the video to show something as a presentation or something. This was the very critical page, and it had a lot of calculations, a lot of work. And, you know, this 3D thing, or this kind of canvas or drawing, this is very, very heavy and expensive on the browser side. This, as I remember, it was really time-consuming to enhance the performance there, and it was critical as well. So this depends, again. The user said that this is very critical to be very fast, then we put most of the effort there. It’s not only about the frontend and backend, and even the algorithm.
Medhat: You can imagine that this streaming was happening using a library in C++ and we were streaming that through web sockets in a NodeJS server and then streaming it to the frontend. It was a long story. And we were using AngularJS back in the day. If you remember, AngularJS has a lot of performance holes.
Tanner: Yeah, I’m remembering… So the security app, the live camera monitoring, that was a while ago?
Medhat: It was 2013? Nine years ago.
Tanner: Gotcha. So that was kind of at, that was towards the beginning. That’s at the cusp, where you’re just… Oh man, what a project to get started with!
Medhat: Yeah, it was a good one. I learned a lot there, to be honest.
Tanner: How did that change you? Like are there things that you took away from that project?
Medhat: Geometry. I hate that I skipped geometry at school because I learned a lot.
Tanner: Right.
Medhat: I skipped a lot of things, but I learned it there. Yeah, I remember my manager was laughing every time I’m telling him, “I regret skipping this school lesson because now I am re-studying it.” And it was fun, to be honest, but it was hard as well because I should have learned that very well. You know, drawing that and making so smooth arrows, this requires a lot of calculations and a lot of operations that I learned at school, but I didn’t care that much at school to learn that. I didn’t care, like, “Oh, no, I’m not going to use that in life.” But it happens that I used it, you know? And I use it for performance as well.
Tanner: Yeah. What are, are there other things like that, that you thought you didn’t need to know, or all the sudden became really important in your career, that you’ve been surprised about?
Medhat: Oof… Look, I studied computer science for four years in Egypt, and in my studying I learned pretty much all the topics that any software engineer wants. But, you know, as a student, I was not caring that much about most of them because I didn’t know how important they are, including, of course, algorithm, data structure. I was good at them but not that good as a student. I was not caring that much.
Medhat: Ten years ago—or no, not ten years ago, I was graduated 2011, so it’s now 11 years ago—when I was graduated, I was not really caring that much because it was not a requirement to work there. Maybe it was a requirement to work in a paying company or something, but it was not one of my ambitions. So I just didn’t care. But later, you know, five years later, after being graduated, I find out that I need to relearn this stuff again.
Medhat: So if any of the people who are listening to us is still a student and studying this stuff, believe me or not, this is very important. Sooner or later you need to focus very much on data structure, algorithms, architectures and logic and operating systems, you know, concepts of programing languages, and how to build a programing language, compilers. Everything I’m saying now, I studied and I was not caring about, but I re-studied it again after graduation with five years or so. Because you will hit them in somehow a specific project. And geometry, don’t skip this one.
Tanner: Don’t skip. Yeah, I already showed this off in a different one, but mine, I never took statistics and now I’m learning.
Medhat: Statistics, of course! Never, never. This one is very, very, very important. That’s a dealbreaker for a developer not to know statistics, of course. I’m not so great in it as well, but yeah, I can search for the things I want.
Tanner: Yeah, it’s funny because statistics, I didn’t need or care to know about statistics until I got interested in performance. And it was because I needed to be able to answer the question, “How do you know? Is it better? How much better?” And the only way to explain that was through…
Medhat: Numbers.
Tanner: … statistics, was through… Like, literally until Core Web Vitals happened, I had no idea what a percentile was. Right? I don’t know if it was the same for you when Core Web Vitals came out. Did, were there things that you learned, or surprised you, or took you from that?
Medhat: To be honest, I cared about different metrics before the Core Web Vitals. I was caring about the First Contentful Paint, it was before Core Web Vitals. The total time, the blocking time, I was caring about this. Total Blocking Time, by the way, was the thing that we used to use to measure what now is FID, or First Input Delay.
Medhat: So a lot of different stuff that you used to do, I lived a little bit inside this Network tab. It was not that great like it is right now. That’s why I learned a lot from a book called High Performance Web Networking, or High Performance Browser Networking. I guess, yeah, you have it?
Tanner: This one?
Medhat: Yes! Very good. Yeah, this one. I think everyone who cares about performance has to learn from this book.
Tanner: How did you find out about that book? Like when did you pick that up? When did you reach for that book?
Medhat: That’s a good question. That’s very recent, to be honest.
Tanner: Oh, really?
Medhat: I learned a lot online in the beginning. I was not a good reader. Like two years ago or something, I start reading well again. But before that I was not really a good reader. That is another advice, if someone is listening and would like to to hear about that.
Medhat: The best resource for learning ever is books. Videos, podcasts like the one that you’re listening to right now, is opening topics. You know, thinking about it, hearing about stories, and get some keywords to search about later on, but it’s not really learning learning. Learning is from books, period. That’s what I believe in.
Medhat: So when I find out that I need this academic learning, like couple of years ago, I start depending on some books. This is one of the books. Some other books I learned were ebooks. And I read this, you know, famous Design Patterns by Addy Osmani. They made another version with, what was her name? It’s called Patterns.Dev. It’s a new version of the patterns. They’re making great effort there explaining everything, and a lot of performance topics is there in this book. So I highly recommend it to everyone.
Tanner: Lydia Hallie.
Medhat: Lydia, yeah. Lydia Hallie.
Tanner: Addy Osmani and Lydia Hallie, Patterns.Dev.
Medhat: Yes, Patterns.Dev. It’s really highly recommended. Before that, Addy used to make something called JavaScript Design Patterns and I read it as well, that was very useful. And catching the patterns and seeing, “No, this doesn’t work here, this is not so performant here.” So you need to change to something else or something. You know?
Medhat: Not only Addy, a lot of other people I was following as well. That was my source of being in touch with performance before that. Including, you know, Jake Archibald and Surma and all the Chrome Team. They are really great, and sharing very nice tweets as well about performance.
Medhat: And the frameworks in the frontend are really enhanced now, comparing to in the beginning when I started with jQuery and Backbone. I’m not sure if you used Backbone?
Tanner: I didn’t. I actually, I think, so there was Backbone at the time, Knockout was my first.
Medhat: Knockout, yeah, it comes in same time or right after it.
Tanner: Yeah, they were parallel.
Medhat: Yeah, and after that it’s AngularJS was very giant. And the worst thing that AngularJS did is being super easy to learn.
Tanner: The worst thing that Angular did was being super easy to learn? Tell me more!
Medhat: Yes, because being super easy to learn makes it super nice for any backend engineer to start tracking in the frontend. And when you come from a background different than the frontend and get into it, either you are a UX engineer, so you care too much about accessibility and how, you know, the color difference and the perfect pixel and this kind of stuff, or you are coming from a backend background. And from backend background, you come with the paradigm with you. You might not feel it, but you just come with the same paradigm. You used to do that in Java and you need to apply this in AngularJS, the one that you’re writing alongside with Java. This caused a lot of problems. As I remember, when I was participating in different projects cross-cutting, I felt a lot of bad practices that backend engineers are doing it and they believe this is good. It’s good!
Tanner: You have some examples?
Medhat: Yeah, that’s hard to remember specific example. But yeah, for example, for AngularJS, as if as far as I remember, there were not something as a shared state management. People used to create a service, and they threw the data to the service, and go there to ask the service to bring it back. Okay? They are not applying Publish-Subscribe or something. These patterns were there, but they used to do that in different languages like Java, for example. You know, share the data through a service, or in C# the same thing. So this is one of the patterns that bothered me, but I don’t really blame them for that because there were not any…
Tanner: They were doing what they know.
Medhat: … mature solution back in the days. Redux was very early stage as a solution for that thing, it was one of the beginning after Flux. And when Redux came, that’s why it takes too much popularity, that people were striving for something that solved this problem, that was resolved badly in different ways. So this is one of the things.
Medhat: And even, the first language I learned in my life was Python. And when you write something in style in Python which is in a different language, normal in Java, for example, and you write it this way in Python, they call it this code is not “pythonic.” It’s not really looks like Python. So from the same idea in frontend, in different languages, in different frameworks, I would say you need to learn from the user guide how to use this framework, how to do this thing there. Don’t reinvent the wheel. So that’s why I really, I don’t hate AngularJS, but I hated the effect that it leaves there.
Tanner: Having such a low barrier to entry makes it easy for people to make mistakes, because they just come in and they do what they can, make mistakes along the way, and there’s nothing, it sounds like there’s nothing to tell you, “This isn’t right. Slow down. Change this.”
Medhat: Yes. That’s why, early after that, I moved from AngularJS to React in a project, and Angular 2 when it was RC4, and it was a good thing. From a client of ours, as a consultant, they asked us, “We need to use Angular.” And we said, “Still in RC?” They said, “Well, it is the future. Let’s do that.” And I get my hands dirty into that.
Medhat: If you remember back in the days as well when Angular was releasing the first time, it was released in two different documentations: in JavaScript and TypeScript. TypeScript was optional, it was not mandatory like now. So Angular came with a lot of enhancements, including the zones thing, you know, about updating the different zones. But what was really fascinating back in the days was React, and still of course. I’m now, I’m currently fully based in React.
Tanner: What has React done differently from Angular that excites you?
Medhat: Simplicity! You know, I don’t want someone to guide me to do that this way. I want someone to give me the freedom, and I find the best way, or you can recommend some. In Angular, you can’t. Basically, there’s a way to do that in “Angular way,” and if you didn’t do it the Angular way, you will just walk a thousand miles to make it in a different way. It’s not easy to customize. It’s very hard.
Medhat: I worked, by the way, I worked with Angular for three years full-time. So I’m not sure, I hope it is better right now. I didn’t touch it for a while now. But I’m fully React. React is giving you a lot of flexibility. It’s unopinionated in a lot of things. Angular is fully opinionated in a lot of things. Would you like to share state? There is a solution baked inside it. Would you like to make fetching? Okay, there’s a solution baked inside it. Would you like to make some typings? Okay, some typings are coming out of the box. And there is a way to write the component as well. There is not much flexibility, I would say.
Tanner: I’m curious, do you feel like, does React make things too easy for people? Does it make it too easy to make mistakes in React?
Medhat: Hm… Yep. Look, it’s easy to just absorb it, learn it in the beginning, in my opinion. And comparing to Angular, it’s all relative, of course. If you’re coming from outside the field completely, you might find any of them in the beginning there is some learning curve. But if you ask me about the comparison between Angular and React, no, React is way easier to get into nowadays.
Tanner: And I guess kind of what I’m getting at is sort of, I’m thinking of feedback here, that it feels like when there’s a low barrier entry it’s easy to make mistakes. But somehow, and I feel like you’ve done this in your career, somehow you had something else telling you there was a better way. Either it was your own passion for UX that said, “I’m going to stay here and make this perfect.” Or there was somebody else that came alongside you, maybe, or you heard a tweet or a blog post. What are some things that give you that feedback, I guess? Or does, and React doesn’t have to be the only example, but how do you find ways to get better? How do you know when you need to get better?
Medhat: Yeah, that’s a very good question. Just to get some validation about your code or your project, you need to have some experts to look into it. If you don’t have an expert to look into it, you need to make yourself the expert who overlook it as if you are not creating that yourself. So from where to get this experience? To be like a mentor to yourself is to learn from different good places, including the company cases that you will find in Web.Dev, for example. This is a blog for Google developers.
Tanner: Web.Dev’s case studies? Yeah.
Medhat: Yeah. There’s a lot of case studies there for different companies, you can learn from them. You need to follow some newsletters. You need to follow some blog posts for big companies who make success about web performance. What’s so good about these companies’ blogs as well is that you are getting an idea about the problem that they faced in the past and how they resolve it. From there, you’re learning that either you are doing it in the right way or you can just be critical about yourself and say, “No, they resolve it differently. Let’s give this a shot.” Of course, if you can. But don’t consider yourself like, you know, the project you are building is not the next Facebook. So just think in the scale of your project as well.
Medhat: So you teach yourself by seeing others’ mistakes and learn from them. Or make the mistake yourself and start measuring and learn from there that this is not performant enough, this is bad, this is anti-pattern. Learn from different patterns like, you know, the Patterns.Dev book or something. It’s very perfect start for yourself. Follow the people who are writing a lot of learnings about that on Twitter as well.
Medhat: Yeah, I can just mention that, just follow a hashtag called #PerfMatters, for example. You will find a lot of people sharing a lot of things. One of the things that I highly recommend, I learn a lot from there, is a newsletter from Calibre. It’s called Perf.Email. This is awesome. The best performance source for the modern solutions ever. You’ll find the most brilliant people’s articles are featured there, including myself, so I have a shameless plug. I had an article in version 99 before the 100, yes, I had one article shared there.
Tanner: Congratulations.
Medhat: Thank you, thank you.
Tanner: If I can recap real quick, because you’ve got, you’ve shared a lot of points like, “Hey, here’s kind of Medhat’s Model for Learning.” If I’m getting this right, it sounds like you like to expose yourself to problems, whether that’s through other case studies or even just taking on new jobs or interesting projects, like somehow or another, expose yourself to problems that you need to answer. Like I have a question, I need an answer, and then you go looking for an answer, and you have a lot of different places that you can get these answers from, like reading. You found books to be super, super helpful.
Tanner: But even within that, when exposing yourself to problems, you mentioned keywords. Like going on Twitter, looking at newsletters, listening to podcasts, finding people to follow. There are all of these gateways to problems and new things, new interesting things. So getting keywords from people you’re following, reading books as deep-dives on this material, and then following kind of that pattern of, like, expose yourself to a problem, find a deep-dive resource about it, and then keep going on.
Medhat: Yeah. Perfect summary.
Tanner: People, newsletters, Twitter. Yeah, it’s all over.
Medhat: Yeah, but the most academic thing is Web.Dev, as I said before. Very academic, very organized, nice articles from the Chrome Dev team and our fellow GDEs as well. We are allowed to post on this Google blog.
Tanner: Yeah. GDE, Google Developer Expert, right?
Medhat: Yeah, yeah. Google Developer Experts. You can follow as well a lot of experts in performance. And you might hear from more of them in this show, I guess, with you Tanner, right?
Tanner: We’ve got a handful, yeah. I got, Barry Pollard just came on. Next, actually, I’m going to be lucky enough to have Annie Sullivan. Gonna chat with her, hear about how, the story of how she got into coming up with metrics and her position at Google, Core Web Vitals.
Medhat: Perfect, perfect.
Tanner: But yeah, there’s so many places to go. Let’s do that. I’d love to talk more about the things that interest you, or maybe even things that confuse you now. Like you mentioned lab versus field data, like let’s dive into that. What are some things that interest you about lab data and field data?
Medhat: Yeah, I talked in April of this year, I was on stage for my very first time in React Live in Amsterdam. And my topic was “Cheap Performance Wins,” and that’s basically about cheap ways to enhance your performance. And I talked specifically in one part about how you measure performance, first of all, because if you can’t measure it, you can’t enhance it.
Medhat: So measuring, as I mentioned before, is two types. It’s either lab data or field data. The lab data you can do in many different ways. The most basic one is something very obvious in your DevTools.
Tanner: You just open DevTools and like it’s right there? You can do lab data? Or…
Medhat: The most basic one is using something like Lighthouse or something.
Tanner: Open DevTools, go to the Lighthouse tab, and…
Medhat: Click it and do it. And yeah, I don’t mind if you just make this and get the screenshot and go brag about it on Twitter. That, “Hey, I get the 99% and very green.” That’s really cool and makes a lot of satisfaction about that. But it’s very important as well to show the before and after one, because it might be, you know, 95 and you make it 99. This is, by the way, harder than making it from 50 to 90, for example.
Tanner: Getting from 95 to 99 is harder than going from 50 to 95?
Medhat: Absolutely, absolutely.
: Whaaat? Why?
Medhat: Yeah, I can tell you, I can tell you. Because if your application is performing like 50 for now, this means that there’s a lot of obvious fixes that you can do right now. Because if it’s that bad, you will start from the basics.
Tanner: There must be an easy win.
Medhat: The easy wins comes first! Because yeah, even in my talk, I was talking about that. I get an application and start from, I think it was 60 something, and I finished at 90 something. That was very easy in 30 minutes, quick fixes and you’re just doing that. So if you are going to enhance, for example, the Largest Contentful Paint, that’s very obvious in the beginning to think about. The images, optimize them, use nice extensions, like WebP or AVIF even, or something like that. Make lazy loading, optimize the size of your CSS, defer them if you want, and make some priority hints as well is coming now and very stable in different browsers. So this stuff that I said is very easy to apply, and this will gain like 10%. Boom! You have 10% without doing much. It just…
Tanner: Here, just check this bullet list. Here’s some low-hanging fruit. Just jump in, take care of these.
Medhat: And what is so cool about using something like Lighthouse, is there is an audit option inside it. So if you run Lighthouse and you get 50, or 30 even, you have a list of checkboxes down there. You need to do that, take care of this, and this request is taking too long. This is the baseline, as I said before. This is baseline of being not bad. This doesn’t mean that you are very performant.
Medhat: By doing all the audits that comes out of the box with Lighthouse, this gives you the minimum amount of performance, but from there you might be 90, which is good enough. That’s why I’m saying from 90 to 99, this is the hardest part, because now you’re squeezing it. You’re thinking about the other parts.
Medhat: For example, I will take React as an example. If you are building a React application and… For example, in the last version, React 18 as we talk right now, there is, they enforced now the strict mode. And strict mode means that they build a new thing that makes the useEffect run just twice in order to cache this component. So if you go back and forth in your application, it just feels like an instant. Their intention is very good, but actually anyone who upgraded their application to React 18, immediately they will find a lot of double requests, if they have inside the useEffect any fetching. They will have a lot of re-renders happening without any reason.
Medhat: The only way to prevent that is to clean up each useEffect. In the return function, inside useEffect, you need to clean up everything you are doing there. So you need to negate it. If you, for example, hiding in the useEffect, you’re opening a new modal. Okay? If you didn’t clean it up, this will run twice. So you need in the cleaning up to remove it. Show it, remove it, and React will show it again for you. The user would not see anything. But this is how the strict mode is happening.
Tanner: How, I just upgraded, how do I know that this is happening? Does Lighthouse tell me that I’m double rendering now?
Medhat: No, in this case you need some more things. You need the React DevTools, for example. You install it and you will find it in the DevTools. And if you open it, you will find a tab called “Profiler.” And in Profiler you will have a cog. If you click on it, there is something called “Highlight updates on component re-render,” and this will show you every time you have a component, it will re-render, it will have like an orange border around it. So you know that this component is being re-rendered more than one time.
Medhat: And not only that, you will find inside the Profiler as well, something called “Record why each component re-render while profiling.” This is very useful and helped a lot in my talk. For example, I showed a live demo about that. It shows you for each component how many times it re-render. If you click on it, it shows you which hook has caused that, which context made this re-render, and at which time. And you can reverse and do that and so forth.
Medhat: That’s why I’m saying this part is a bit tricky and not cheap, to be honest. This is expensive time-wise, and needs a lot of experience in networking and in React and in using these kind of tools. That’s an answer for your question about why the 90 to 99 is more hard. It’s harder because of that. The first 40% is easy because it’s known, very common.
Tanner: I like that you mentioned “squeezing,” because I feel like squeezing the juice out of something, that I have a piece of fruit and I squeeze the juice to make lemonade, I don’t know, orange juice. It’s easy if I have half of the orange left to squeeze, I’ve got plenty of juice. But if I’ve already squeezed out 95% of the orange, that last 5% is, I have to squeeze really hard to get it.
Medhat: Really hard. Yes, yes. And it takes time, of course. To detect even these problems, you need to learn the tools, as I said. And learning the tool is not everything. Learning the tool and extracting the data from this flame shape, for example, for this profiler, is a bit tricky. You know, it needs you to consume some time, and re-render, and stop it there, and do some stops here, and go back and forth in another components tab inside your DevTools, included in your React DevTools as well. Very helpful to see each component, how many times it re-renders, and all the context inside, and all the props inside it, to see what is set when. So you know, if there is a double re-renders or something.
Medhat: This is the trickiest thing, for example, now in React. And I find it something that you need to pay attention to. Maybe for the new people in React, if they are starting today and they’re using React 18+ with strict mode, they will get used to this good practice of cleaning up. You can disable, of course, the strict mode, but I think it’s very nice they enforce it because they needed everyone to clean up the effects after they finished.
Tanner: We were unintentionally making things worse.
Medhat: Yes, yes. React, I ask this question, by the way. React is not slow, but the way we’re using it makes it slow.
Tanner: That’s interesting. And if we learn the tools, learning tools can help us protect ourselves, or protect our users from poor experiences.
Medhat: Yeah, pretty much yes. The right tools as well. What I’m talking about right now are all lab testing. You are assuming that this is bad and you’re behaving towards that to enhance it, stop re-render, do that, do this. But this data might be misleading, unfortunately. Because it depends on my machine is different than your machine, is different than your browser, than my browser, than the time, than how many memory you have, that what are you are running in the same time. And this might be misleading.
Medhat: So just, this might be shocking for some people who are bragging with this, you know, Lighthouse thing on Twitter. I might run the same application that you run in my Lighthouse and might be different results.
Tanner: So you’re telling me if I run Lighthouse on my super Mac Pro and get a 99, but then I go with my little cheap Lenovo laptop, I won’t get a 99?
Medhat: No. Most probably not. Most probably not.
Tanner: Medhat, no!
Medhat: Try it yourself.
Tanner: How can I trust my results?
Medhat: Yes, that’s, that gives us the other part of your question about the field testing. Field testing is very accurate. This is real data coming from the user, coming from their machine, and what they are seeing. So for example, for the lab testing you cannot measure the FID, the First Input Delay, because this requires the user to behave and see the user, when they click, how much time it takes. In the Lighthouse, we can measure the FID by the Total Blocking Time, because Total Blocking Time indicates a little bit that, “Alright, this is the blocking time, the user might be affected by this blocking time.” But the field testing, you can measure the FID.
Medhat: If you’re using, for example, the Chrome UX Report, you know that? It’s a very open source and free, everyone can use it. You plug it into your application, you’ll find each user, what they used, which computer, which OS, what is the memory usage, and of course the Core Web Vitals are measured correctly.
Medhat: And in the Core Web Vitals, you don’t have to make 100% of your pages following it. You need only like 75%. That’s why I’m talking about, you know, the sign up page. Don’t care about it that much, it wouldn’t affect your scoring. But 75% of your mostly visited pages needs to follow the Core Web Vitals.
Tanner: So get that baseline as much as possible, but find the pages where people are really, like, that people really care about, they visit a lot, focus your attention on those first?
Medhat: I would say the indexed pages, the pages that the search engines can see, are the pages that you need to care about that much. But for example, I’m hosting my blog on Vercel, and Vercel comes out of the box with some analytics. And this analytics, of course, it’s paid if you’re using it more often, but this analytics is field testing. It gives you Core Web Vitals for real. Real users who visited my application. And it gives you the amount of pages that covers this. So up to 75% is covered, it says, “Yeah, you’re good.” And it tells you it’s desktop or…
Medhat: All the tools, by the way, not only Vercel, but any tool you’re using for field testing, you will find most of this information. Calibre, of course, is using, Akamai mPulse is doing that in a great way. There’s a lot of tools, just pick one and depend on the field testing results, because it’s way more accurate comparing to the lab testing. But the lab testing is a good starting point.
Tanner: What should I do if my lab test tells me one thing but my field data tells me something else? Like for example, if my lab test says I got a 99 but my field test tells me I have a slow LCP or I’m failing Core Web Vitals. What do I do now?
Medhat: The question is how often is that in your field data? Is it 1 user out of 100? Or 1 user out of 3? Or 10 users out of 100? Might be 50% of your users. The more percentage this is happening, this means that your application is bad in the field, is bad for the user. But if it’s happening, like once, imagine some people might… I do have some laptop that would there, like for 10 years I make it like a home server. I might access your website from it and it’s really bad performance, and I know it’s bad performance. So this will be recorded in your field testing.
Medhat: If it’s only one instance, don’t care about it that much, I would say. But if it’s often happening, I would say, “No, you need to care about this. You need to think about it.” And of course, the field data will tell you which browser was used, which OS, and from there you can just grab this information and go to a lab testing and simulate the same thing that the user see. If you successfully simulate that, and successfully made better results, next time the same user visit your website will have the same result that you have. That’s why I’m saying the lab testing might depend on your machine, but the field testing is very accurate. Use it.
Tanner: And then take that information back to my lab test and say, “Wait a minute, I need to be testing with whatever my real users are using.”
Medhat: Exactly, exactly.
Tanner: Fantastic. What are you doing now, Medhat? Like how can people follow you and keep track and learn more from what you’re learning?
Medhat: Well, currently I’m not creating too much content. I’m focusing, to be honest, on the local communities. I have two talks on September, both of them in meetups here in Amsterdam. One of them will be about the “Cheap Performance Wins Version 2,” or “Volume 2,” I would say, because I made a lot of enhancements on this one, and whenever it will be shared, I most probably will tweet about it. The other one will talk about enhancing the performance of fetching. I wrote an article as a starter, might be the gist of this new talk, I would say, and it will be very interesting as well. And I’m planning to write some more articles still, luckily they are not published yet.
Medhat: These are the content I’m creating in the upcoming periods. And some conferences I submitted to them, not sure when will be done, might be October and December. And I’m mostly accessible and reachable on Twitter. My Twitter handle is my name, @Med7atDawoud, but the “h” is “7.” This is how you can reach out to me. And I’m rarely writing on Medium, sometimes I write on Dev.To. But, of course, if you would like to see my writings, it’s mostly on my blog, MedhatDawoud.Net. My just first name, last name, and “.net”.
Tanner: Well that’s fantastic, man. Hey, I’m excited to see more, excited to keep following you.
Medhat: Thank you.
Tanner: Hopefully we get to do this again sometime, I loved chatting.
Medhat: Yeah, for sure, for sure. I enjoyed talking to you too much, Tanner, and thank you very much for inviting me for this interesting topics. And yeah, hopefully we can repeat it again.
Tanner: Sweet! Ba-da-ba, outro music… Just kidding, we don’t have music.

Recent Posts

Recent Comments

Archives

Categories

Links

Video

Transcript

Leave a Reply Cancel reply