Front End Developers View of Performance with Cristian Daniel Marquez Barrios

Five, four, three, two, one.

Drop dead.

Welcome to the Test Guild Performance Podcast where we get together to learn more about performance testing and site reliability with your host, Joe Calantonio.

Here it is.

Here it is.

Here it is.

Hey, it's Joe. And welcome to another episode of the Test Guild Performance Podcast. Today we'll be talking with Christian Daniel Maquez Barros all about what does Front End performance mean? Christian is a software engineer with 10 years of experience developing user interfaces with JavaScript. He's dealt with all kinds of front end technologies like Angular and React, and he's led Multiple projects doing JavaScript front end development as well. With today's modern development software frameworks, front end performance has become more important than ever for performance testers to be aware of. And Christian wrote a really Great post on Hackernew.com a few years ago on front end performance I thought would be fun to go over today to really help performance engineers understand the front end performance aspect of performance engineering. You don't want to miss this episode. Check it out.

Let's face it, performance testing is tough. Traditional load testing tools create scripts that are bogged down in data that's hard to read and require a lot of work. Even for simple playback. Load Ninja cuts out the dirty work by using AI to inspect and debug your code almost instantly. No coding necessary. No changing of hands or relays between teams either. Give it a shot. It's free and easy to try. Head on over to testguild.com smartbear and click on the link to learn more.

Hey Christian, welcome to the show.

Hey Joe, how are you doing?

Awesome, awesome. Great to have you on the show. I don't think I've had an episode yet on front end performance. Christian, before we get into though, is there anything I missed in your intro that you want to add about yourself?

Well right now I have to say that Anna Happy digital nomad too. So I've been traveling around the world and these days I mean I working for ARC Dep, just freelance platform and I've been working as a freelance developer like three years ago and I've been working from United States, Boston, Washington, also from Cancun in Mexico and here in Canada. So yeah that's what's new for me and I excited to be here in the show talking with you for signs like taking these kind of interviews.

So what I'm curious to know is before we even get into the big topic of performance for front end development, what is front end developer? I know full stack development, but why front End developer.

I see myself as an artist, I'm an engineer and I have some skills related with like organization of elements on the screen and how to draw using the browser as my canvas. So front end developer is like we have the engineer and the artist both in a single one. So you have to deal with data, but also you have to deal with the designs. So the front end developer is just the artist in the engineering.

Basically when you're creating a front end, you say you're like an artist. Do you ever think as you're creating performance or is that just an afterthought or is that something you do after you've designed the UI itself?

I mean that's the point of the article. Most of the time you are thinking that the performance is the faster thing. And especially in the engineering field where everyone needs to be quickly and you want to set up many servers and you want to do everything as quickly as possible. But in the design world you don't have to think a lot. Just imagine that you are in a bank and everything happened in a second. So you could be like, okay, why is this happening too fast? Maybe something went wrong and my transaction didn't finish or something, it's not working well and just the system respond a random response and everything is not well propagated. So that's the point all the time you have to think in performance, but you don't have to think and do things in the quickly way. And that's the point with this, you have to think in performance and you have to stop thinking about the faster but the smoother basically.

So how do you think about performance? I know like with the company I used to work for, they'd say thou shall be able to log in and under two seconds and it's after the application was already developed. Does anyone, you work with a bunch of different clients, does anyone ever give you those type SLA is like you have to be able to read a radiology x ray within 5 seconds or something like that.

Well that's, that's the ideal. You know we have the Lighthouse Lighthouse metrics that, that kind of metric that Google. Well the Google teams provide us using the Google Chrome tools. In the software development world you have like different step when you are creating like a singular interface and when you are discussing all the topics related how to generate interfaces and how to generate everything. One of the points that you have to discuss is the response time of each interface. And this is even more important if you are generating interfaces that includes some animations like a video Game or maybe drag and drop system where you need to basically play with the interface. So performance, it's always present and especially you want to make the user like happy with the product he's interacting. So the point of all of this is you need to create interfaces that responds as quick as possible, but you have to generate also interfaces that are smooth enough. So if you see this thing that I'm talking about at this point is like you have a user interface and you have the user actions and you have the timing of the server response. We as engineers are really good to respond in that part and how to set up the server and how to set up all the APIs and everything to respond as quick as possible. But we have a challenge because we are dealing with all machines, people using Internet Explorer 10, people using Legacy version of browser on all machines, and also these mobiles that they don't have a lot of RAM and you want to display an animation, let's say that when you sideload and you want to display the hello world or hello user or some smooth animation to open the menu from left to right and that kind of stuff. So you want to ensure that your code respond smooth enough to make the user feel he's working with a product that is working and not something that is broken. Basically, that's it. You need to think in performance like all the time that you're doing something. Even when you create a small function and you see that that function, it's call many times when you generate method, when you write some lines of code and you see that it could cause in the future some trouble, so you need to escape it or add some conditionals to prevent generate errors in the future, that kind of stuff. So the performance is everywhere.

So you mentioned a good point. It is client side performance. So do you have like a baseline that you develop against or do you actually have to test against different configurations?

Yeah, well, we have like different metrics. The first metric is once the server respond with the data, you need to display something. And that's the first method that we have to achieve the first interface that you display to the user waiting for the rest of the data. If you see this more technical and you analyze this, this needs to happen between one and two seconds after the user just enter the URL and hit enter. And after that, if you see, for example in YouTube, you will see that they download the full website. They just add like a boxes with a background that it's moving like a placeholder. So just to show the user here you will be Something, but you need to wait a little bit. We are preparing everything for you, but the user don't see that wide screen that in the past we used to have in many of the websites. So the idea is like you need to draw something in the website and let the user have some, give the user some feedback related with the website that is displaying right now. And you say, okay, we are working in the data and you will see something awesome soon.

As you're creating a front end, you're working as part of a team so you could have someone doing back end work that maybe created a slow database transaction per se, that you may be calling on the front end. How do you work with other developers to say, okay, I know this piece, this front end piece is performant, but there's another piece here that you need to optimize. Do you communicate that way?

Yeah, well that's why I like to do Scrum and Agile methodology. So what we do is we have a small team and we define like different stories where you can see how the software is connected with the whole solution. So you create just a portion of the software and you connect your code, let's call it your model. You connect your model with the whole application like a Lego block. So basically you need to interact with everyone. But I mean, unfortunately in this world you can talk with everyone. So what I like to do is I want to help other developers with the code that I create. So after I finish something, what I do is, okay, let's review everything and let's ensure that the code that I'm generating right now will help other developers with their work. It includes not only the performance, but the spelling of the words that I use.

The patterns that I use inside that function and that class that I generate and everything. It's like help me help all the developers, even myself in the future. Because I don't know, I'm working on this button today, but tomorrow I'd be working in a totally different view and that view will use the same button that I generate, I don't know. 3 months ago so if you see this, basically I'm helping the developer futures and the developers futures includes myself. So basically you have to think in, let's create something. Let's try to focus here. And especially me as a remote developer. I don't have any of my co workers here, all my partners are around the world so it's really hard to keep track about what are they working on. But we have the pull request system, we talk through the code basically and we try to help each other using good patterns and good technique, basically generating quite code with high quality.

So just curious to know the different projects you've worked on. Have you worked on when you check in code that you have some sort of pipeline within your CI CD that actually checks for certain performance criteria.

That's something that happened at some point during the Sprint. So basically we have the first solution, it's always the word. So you start working and you create a working solution and that's it. And after that you have to spend some time that we call in refactoring time and you use that time in order to improve your solution and try to have some metrics related with this. So there are two different scenarios. The first one is use tools that give you some metrics. So Basically we use JavaScript and we use the date function to store the timing and the dates when the function start execution and we log again when everything ends. So we have like two measures.

You do the basic math. You have the starting time, you have the ending time and you get a number. And with that number in mind you have two options. For example, when I work for Scotiabank like two years ago, what we used to do is store that kind of information in a database. And we have that information for many users because we have thousands of transactions per second because, well, it's a bank and we have that big table. And you could see how the interface respond with the user actions. For sure. That's the same metric that.

The backends guys use in the database just to lock everything related with each of the transaction. And right now with modern tools, basically that kind of system also has some functions in the JavaScript size to store information in the same database because well, there are different action that doesn't touch the database. Exactly. But if you see the interface, for example, you are in the step one and you move into the step two and after that you go back to the home. And that kind of metrics, you could measure everything and at the end the only variable that you need is time. When the user start doing this and when the user stop doing the action that you want to keep track. What we have right now you have a HTML file and in the past the browser just draw everything what you have in the HTML. But if you see the JavaScript part after the HTML load, we inject a new website in a single node of the HTML. So it took some time. So you want to have metrics about what is going on with your page and how much time it takes to display the website into the, well, the JavaScript website, if you want to see in that way right now there are different techniques like they pre render the HTML instead of loading everything in the client. So you can use the server to prepare the basic HTML and you display some information to the user. So that's a good technique because you don't need to wait until the JavaScript execution to see something to give some feedback to the user. You have many metrics and you need to be sure to store it if you want to have a well designed product. I used to have many slack groups and I see how people works on different companies. These friends, let's say they have another technique and they told me that what they do is okay, instead of improvement, the same application, they have a small application each time and if they see that this application failed, they move to a different total application in runtime. So they have like three or four different applications with different measures. And if something failed, okay, this failed, let's move to the other one instead of improving just a single application. So they have like, I don't know, five or six different layouts for the same information and one is responding better than the other. So they can switch like between layouts and between everything. What is true here is basically the user has the final decision about if everything is working. Because we could talk here about the good timing and good service response or that you think that this is smooth enough. But sometimes they told me too many, like transition or I don't like that you have too many animation here. Why I'm looking for my flight tickets and my hotels and I need to wait like a minute, it's too much time. But well, in the meantime you can display like different information. But yeah, so at the end everything related with performance and so far and the timing and everything we do at the end the user is the most important part because he will give the final review about what is going on with the application.

So you've mentioned a few of this already, but I just want to call them out. You have in the UX world there are three things that should be measured in this article you've already talked about satisfaction based on how the user is feeling about the performance task. But you also have effectiveness and efficiency. Could you just talk about them really quick? What each one means, if you see.

The timing about how everything works in a website and what kind of timings you have. So the first one is I want to do something with this product online. Let's say that you want to, I don't know, create a new event in your calendar, that's a problem. You create an application and you have many buttons. Let's say that the user has to click 10 times before start creating the new event in the calendar. That could be a problem because you have to do many things at the end.

Your goal is create a new event in the calendar. If you see that, it's really like.

That'S a metric that you don't have control on because it's like if you need to do 20 steps or something like that to accomplish a task because the server and everything require that that you are out of control. But if you see the user, he will say, okay, this is not efficient, I have to do many things. And you can measure everything by like counting the amount of clicks that took in order to generate this and asking the user, okay, do you think 10 clicks to generate a new event, it's okay or not? And after that he say, okay, this is cool because now I understand that you need to connect my information with the information of a bank with the information of another external tools that I'm using. And that's why I need to click around many times and it's good enough, but it could be better. And that's when you start, okay, the user fools this could be better. And we have a good engineer team they can take care about. Let's say instead of having five clicks to do this, let's do everything in one click and just display some message or let the user do another thing in the website while you do everything you need to do in behind the scenes using the backend system. And the satisfaction, well, you know, that's the most important part because if the final user is happy.

With the product that he's using, so he will think, okay, this is really cool. This is the order metric that we need to define. If you see you have your final goal, like okay, I want to generate a new event into the calendar. So that's my goal. If I have to spend, I don't know if the user spend 10 minutes on the same task. So that could be a problem for everyone because you are using like too many resources of the machine just to generate.

So if the user is not able to generate something quickly and they don't know, maybe they feel okay, this is good because I have to do this and he feels comfortable working with that. But if the user has to use many of the resources of the website and many of the resources in the backend, you can reduce that timing like providing less options in the interface or providing a more Clear UX experience so they can do everything quickly. It's a win to win for everyone, for us as a developer and for the.

Final user because they will do everything quickly and they have a good answer. These kind of metrics are kind of hard to explain because it's not like a math formula. We don't have a way to measure everything. But you have the information of the user. So for sure this is not a person who knows to use the computer very well. So he will type like really slow. For example, they don't know how to use the mouse. Or maybe this guy doesn't like to use the mouse and he's using BIM for example and he has a completely new machine and he's working really fast with the keyboard there to that kind of user that are not a normal user and you don't have a solution for them. So your website has like different listeners and they don't respond very well with that kind of user. So that also it's like a new metric at the end what you have is a bunch of information about the user and you have in the same way that you have a bunch of information about the server, if you meet the user information that you could store everything and you could get that information about the user using the browser. The information with the server, you store that with the backend system and you meet both. You can generate your own metrics and that's personal for each of the project because let's say that you want to generate a metric just to ensure that the bottom of the website is moving like it's bonding, it's moody or something like that. Because that's important because that you need to store, I know the coordinates of the button in the screen to preserve it and in the future display in the same position that that is something like that. That's just a crazy example that came to my mind right now. But it's like.

You have that elements and you have that metrics from the user and if you mix everything, you can generate like your own metrics. And at the end the idea is with this kind of metric create a better product for the user and not a better product for the machines. Because that's one of the mistake that I see in all like my co workers right now. Because they see, okay, I gonna pick this new technology, I gonna pick this new framework, I'm gonna pick like something, I don't know, new language because it's faster and it will take less resource of the machine and we're gonna have instead of Two servers, we can run everything in a single server, everything will be quickly. Or maybe let's use this new Amazon stuff in the cloud because it's faster and everything and at the end you will run the same application for the user and at the end the goal is the same. And I mean jQuery application people start saying okay, jQuery is too legacy, I don't like to use jQuery, it's too bad. But there are applications out there that use jquery and people love it.

Okay, you have to do many things. It's the same with PHP that they say, okay, let's stop using PHP because it's too old and they have too many problems with the garbage collection and well, too many technical reasons to stop using that. But well, we all read articles in WordPress, you know, there are many WordPress websites out there and you are still using it. You feel comfortable because they work in your phone, they respond quickly and you are happy with that. So there is no reason to spend a lot of money to change the tool to a quickly one to a better one at the end. Well, if the user is happy and you are generating enough money with that product, it made no sense to change just the technology stack because it's trend or because it's faster or something like that. Maybe if you have some problems related with the money because it's. You are spending too many resource and you are out of budget because the technology and the user is interaction. So maybe you can change something like that. But the final message is like, okay, we have to make the user happy and to do that you have to listen the user, you don't want. I mean the user doesn't care if you use a huge technology stack because they don't see it. You know, they only see what you have in the browser or in the computer of the on into your desktop application. If you see a video game and it's too slow and you only have like 30 frames per second, you could notice and you will say this game is bad. You won't say oh, this game was created with php. I mean that's not a real reason, that's not a real feedback from the user. But for sure it's important. But you have both metrics and they are on the table and you need to take decision with that kind of metrics.

How do you know when the user's happy though? Do they actually tell you or do you use things like I don't know how much of a front end developer gets involved with Google Analytics. Once it's in production. Because a lot of knows what happens once you're in production. All kinds of things happen you didn't expect. So are you actually looking at Google Analytics once it goes live and look at drop rates or bounce rates or things like that?

Yeah, yeah. I mean in startups it's hard to have that one. But I mean literally you have a TV in front of you with all the metrics in live action and you see if your application stop, if the timing is okay, if the server is responding okay. And I mean literally you have to take care about that one because you are creating new features. But if something is broken, you need to stop doing what you are doing because you need to fix it quickly and you need to listen the user. So you have like literally you have the TV with the metrics and also you have the feedback using this kind of tool that show many pop ups. Please give us a review. And the working in the UX part you go with the users. I mean you have something that they call UET research. And what you do is before generate the application and after you create the application you go with the final user. And there are like two different kind.

Of.

Research they do with paper. It's like because they're generating a new feature. So they go to the streak and they interview many people and they show that, okay, if you want to open a bank account and I show you this interface on the paper, it's okay, okay, that's the first one and the other one is with a computer and you, I know you buy the launch for them or maybe sometimes if you have a good budget, you can find like 10 random people and you interview them and you say come to our office and you have three different webcams and you have the machine and they start interacting with the application. Basically they say if you want to send an email, for example, what are you going to do? He starts interacting and you keep track about everything in the screen you see because you are recording the face and you have different cameras. You can match what the user is doing in the interface with the emotion. Or maybe he's frustrated or you have the microphone. I don't understand what is going on here. Why do you have this here? Again, it's just data. You can't have millions of user to do that. But if you have just a small budget you can have 10 per month. That kind of interaction with the computer, with cameras and with everything and that gives you like a good feedback about what is going on with your software. Also there is an application but instead of using cameras and everything, they create a video for random users in your website and they store all the user action technique that we use. You have the feature flag in the database and you have the user information. So you, you can say okay, let's only the first two or three connections to the website, let's enable the new feature or this is not working, so just turn off for all the developers. And I remember I worked for procore in the past and what they do is when they create a new feature they release like only for 10% of the user and if they don't have any complaint they do it to the 20% until they do to the 100%. In that way they ensure not only the QA process that you have internally with your co workers, but only also the feedback from the users. Because well, when you are working directly with the application, sometimes you don't know if this is good enough and you are too focused on the feature and you forgot to test the other branches. It's hard to test the whole application if you are focused in only your feature because well, you are not the user, you are the creator.

Okay Christian, before we go, is there one piece of actionable advice you can give someone to help them with their front end performance testing efforts and what's the best way to find or contact you?

My final advice for all of you is try to focus on the user and try to focus in your coworkers. So if you want to create the best product ever, what you need to do is listen to the final user and stop loving your code. Because sometimes if you get in love with this piece of code because I don't know the animation from top to bottom from the menu and this is really cool, I really like it, but the user doesn't like it or is taking too much time. So be ready to delete it. I mean don't be afraid to just delete everything and start from scratch again. Focus on the client and focus on your coworkers because well, you don't know who will interact with the code that you are generating today. Inactive on different communities in Colombia and also inactive in LinkedIn. So if you want to contact me, well let's do through Twitter or maybe through LinkedIn. That's the best way that I can answer. Well, in Hackertone you could write in the. Well in the comments of each of the articles I quickly respond most of them.

Thank you Christian for your performance testing awesomeness. For the seventh value we covered in this episode, head on over to test guild.com P23. And while you're there, make sure to click on the Try it Today link under the Exclusive Sponsor section to learn about Smart bears. Awesome software Load Ninja that helps you spin up browser based performance tests. Wicked. Fast and easy. Check them out. So that's it for this episode of the Test Guild Performance Test Site Reliability Podcast. I'm Joe and my mission is to help you succeed with creating end to end full stack automation awesomeness. As always, test everything and keep the good. Cheers.

Thanks for listening to the Test Guild Performance Podcast. Head on over to testguild.com for full show notes, amazing blog articles, and online testing conferences. Make sure to subscribe to join the Guild and continue your testing journey. This has been a Joe calantonio production.