Diagnosing Your No-Code App Performance with Devtools

In recent office hours and things I've been seeing on the forum, people are asking about how to understand requests that are going between the client, maybe using a no-code platform like WeWeb or, or Wized, or even just sort of your ordinary applications. And things are going to a backend and how to understand what's going on with the frontend, with the backend, how to know where your errors are along the way, particularly as we increasingly use the decoupled no-code systems, right? So instead of having Bubble, which is going all the way across, using, you know, third-party services or using separated backends like say Xano or what have you, And the question is, how do you understand how these things flow across? Now, the truth is most of what we're making is web applications, and so you're sitting inside a browser, and browsers have tools that are a little bit hidden under the covers that we can use to understand better how the communication is going between the— between your browser, which is usually where your frontend has been distributed to, and your backend. I'm going to start with the StateChange site itself, which is run by Circle, which is a community platform. And I can, and if I want to understand what's going on with its relationship with its server, I would just, you know, right-click and choose Inspect. Or you can go to here and choose your, you know, your developer tools like you see here. And there's also a shortcut for it on both Mac and on PC. I think it's Control-Alt-I on PC and it's Option-Command-I I on, on a Mac. If I click on developer tools, I will get this other thing showing up over here. Now, it might be showing up if you click on the little three dots here in Chrome. Most other browsers work basically the same way. You might find it to be down here or you might find it to be over on the left. I have always found it most useful to look at dev tools over on the right because that way I have my primary over here on the left. And then I have the DevTools information over here on the right. And they sort of squeeze it down so it's about two-thirds, one-third usually between these two. And as I, you know, grab this edge and move it back and forth, I get sort of different displays. But the interesting stuff really isn't going to be in the display. Usually if you were to choose it using the inspect method, you're going to see something here called elements, which will show the dynamically built what's called domain object model of your page. And we can look into this in another video. What I really wanna bring your attention to here is that there are a few other elements. One is Console, super useful, talked about that in other, state change videos. And then there's this one called Network. Network is one I find to be most useful most days of the week because I can use this to find out how the page thinks and how it is talking to the server. And I can use this to diagnose what's going on. So for example, if you have a request and you're trying to understand why that request isn't getting good data or isn't working properly, you can look in here and go find your request and you can, you know, resize it a little bit or what have you. The other thing that happens is particularly if you've got a smaller screen or if you need something really large, if you click here, you can actually undock it and that causes it just to show, you know, kind of over on top. I'm just going to go re-dock it back to the side here. And you can go find all the different requests that it's been making. So for example, being able to take a look at new notifications, you know, the internal API for chats or what have you. And being able to also do things like understand, well, if I'm going to create a new post, you know, what else is it going to give me in terms of other types of requests that might be going on in here. Now, when I'm looking at these requests, there are a few different tabs that can go across the top here. So remember, I start here, I'm able to see when the request was made, and that's what we call a waterfall. So closer to the start of the page, that's going to be over here on the left. And then it's going to tell me usually when it was queued up and when it ran and how long it ran. So like a thick blue bar here would be indicating a relatively slow request. And the, and the, you know, and ones that are sort of further across are indicating things that happened further in the lifetime of the page. The fact that stuff happens like further right on the timeline here is perfectly normal. So that's not a thing to worry about, but it sure tells you when things were happening as we go along. Now we can click on one of those to find out which request we're talking about. And we have a few different headers over here that are really helpful. Make this a little bit bigger so I can understand it better. And those headers, so first we're gonna understand what the headers were for the request. And headers are kind of like what got written on the outside of an envelope, right? That might've gotten mailed to you. You can find out what the actual URL was that was sent, what kind of request it was. This is called a method. GET or POST, but there are also slightly less common ones like PUT and PATCH, and OPTIONS you'll see quite a bit. But mostly you're going to be looking at GETs and POSTs. You're going to be able to see what the headers were. Now, I, for reasons I don't understand, it shows you the headers that came back from the response before it shows you the headers that you sent. Now I find most of the time the headers you want to pay the most attention to are the ones that you sent out because that's how you're diagnosing the request. That's going to be what you're doing from, you know, WeWeb or whatever else. And you get to find out, okay, well, if it was supposed to be an authorized request, is there an authorization header? Uh, one thing you'll notice here is that they don't have authorization requests, but they do use cookies. And so you can see how the cookie is getting sent back and forth as one of the headers. And the cookie, of course, is a very long string. And so you sort of need to, you know, pay attention, read through it to find the cookie that you're really looking for. In the case of a lot of XANA requests, for example, usually using authorization requests. I'll show that in just a minute. The, um, you can see what the path was. You can see, uh, uh, what other in, whether it was set to accept, uh, JSON, whether it was set with the content type was set properly. These are all things to be paying attention to in terms of how the backend might be understanding what the frontend is doing. So once you've looked at these headers and looking at these for problems, and a lot of times, like, the way you look for problems is you take a request that's good and a request that's not good and you compare their headers. To see if there's something different. Like, oh wait, this one has authorization and this one doesn't. And that becomes a thing you can dial in on. So it's not like just looking first order. This is obviously wrong. It's going to be through comparison of what looks good. And then you have the response headers, which are what actually sent back to you. Most of the time, these aren't that interesting, um, except of course, when they're sending back that there was an error of some kind. The second tab that's of significance is what's called the payload. The payload is going to either break down the query string, and the query string is like the stuff after the question mark that you might have up here in the browser bar. Or it is the payload that is sitting inside your, the body, right? That's the equivalent of like what goes inside the envelope when you're mailing something. And that's what you're sending up to the server. And looking at this gives you a better understanding of whether you're sending what you meant to send to the server, because that helps you identify whether you're packaging things up right over on, say, the WeWeb or Wiz or whatever side, and versus is this being mismanaged by the Xano or what have you side. And then you have a question of like, what came back? And this comes in two forms. One is the response, which is sort of the actual text that got sent back from the server. And if the text is actually either in W-Form encoding or is in JSON, the preview is kind of nice to make it all a little more readable and collapsible or what have you, just to get a better understanding of how that works. Finally, the initiator you're probably not going to use that much because it's very hard to understand. But the timings you actually might use more to understand how long these things took. And the, usually the biggest source of slowdown is going to be the stalling and the content download, sorry, and the waiting for server response. The stalling is usually just how long I'm waiting to start making the request. And these, by the way, are both really, really short. This is 70 milliseconds and this is 107 milliseconds. So you put all these things together, you get 2 tenths of a second. It's just not driving the bus from a performance point point of view. But if you close this up, you can also pay attention when we're looking at the full list of things that might be taking longer. For example, things that are relatively large and things that are slow versus long. And so one thing that can be useful if you're looking at this from a performance point of view is actually click on where it says time and click twice to make sure that it points downwards to find out what your longest requests are. And that will help you understand where your performance bottlenecks might be. Of interest, the, the slowest things aren't necessarily the largest. For example, largest, I'll find that there are some that are like a photo or something, but those can be super, super fast because like a photo, even though it's large, can be served off of some really fast cache. Whereas it's going to be the things where I'm making like a request on the backend and that request might take more time. That usually is where the slowdowns will occur. And if we were to just take a look at this guy for a second, And by the way, the one to click on is going to be the name over here on the left. You can see here that's just waiting for the server response. And that waiting for server response means, and these things don't worry about too much, right? This DNS lookup, initial connection, SSL, that's, those are table stakes things that happen whenever you're just doing a secure connection, right? It's like asking, how long does it take to put the key in the lock and turn it? The big deal is how much time you're spending inside the house., and that's going to be where the waiting for server response comes in. That's usually the meat of it. And that waiting for the server response is usually where, if this is where you're seeing a slowdown, is going to be, let's, let's fix that on the, on the backend. Note that this timing is not always going to match up with what you see on the backend in terms of the actual runtime for a given request, which is where like issues of overhead or what have you come in. So let's look at that. Now we looked at this a little bit to see a few different types of requests that we're getting from our friends at, um, at Circle. Let's look at it from the point of view of something that I built that is actually working with Xano on the backend. This is a script tag, which is a low-code application, allows you to inject just a little bit of code into your, you know, into your no-code, low-code project. We're trying to make it easy, just create literally a little script tag that you can then put into your WeWeb or put into your Wized or whatever it is that's going to be interesting on the front end. And I have this, you know, slightly deprecated little piece of code here that we can use to understand how to, you know, get, you know, get data. And the way it works is you just modify your little bit of code, it saves as you go, and you can, you know, then create a little script tag which copies to your clipboard. And then if I wanted to, I could just, you know, paste it into here and it would just go into, you know, something I could put into once again, those other systems. And it also works directly with WeWeb. Okay, but the purpose here is not to be talking about script tag itself, but talk about how it talks with Xano on the backend, because this is a low-code system, which uses a bit of code on the frontend. So I can have the nice little editor, you know, like for Visual Studio Code, but then we're going to save it on the backend using Xano. And that's going to be how it's able to serve up the data that's necessary for it to be useful in people's projects. So here I've done this again, and once again, I've did the Option Command I from my keyboard. But what we're going to do here is we're just going to say right-click and do Inspect. That's what way I usually recommend people doing it when we're inside Office Hours. So you're going to have, once again, it shows you your elements, and we just go back over to Network. Keep in mind that if this is like more narrow, See, it doesn't actually show me network anymore. And that's when you gotta use these little two arrows thing. Cool. So network, great. Also remember that doesn't start recording things until you bring up this network tab. So we won't find out what it has to say. Let's press enter. And now it has saved something for me. That's the way it works, it saves as I go when I type. And as a result, I'm able to take a look inside here and be able to see that this thing has, you know, the timing, just like, because that's what we had in the previous page. Let's go back to the headers, right? So this is making a request to my Xano instance. It is going to embed. Once again, I look at the request headers. You see there's authorization token. And this authorization token is, of course, temporary. If you try to use this authorization token, it will not— it'll be dead by the time you're looking at it. And the, you know, and it just has the other information that sort of goes along with it. Notice there's an application type— sorry, content type. And that is ready to get back basically whatever data you wanna send. And so when I go to my payload, this is the POST payload. Remember, see how it says request payload here? That's because this is all on the inside of the envelope that we just talked about because it's a POST request and POST requests can have stuff inside the envelope. So the payload will contain, all right, here's the body and the body is actually all of this text here. And then just whatever other information is interesting about it. And then it sends back information and actually it doesn't send back much information at all because the idea behind the POST is it just sort of sends data and then doesn't send anything back. But if I were to say, you know, refresh this page, You can see here it does the same thing with a GET this time, and it sends back a whole bunch of data, including information about the project and whatever else. Now, this is significant because the project is, you know, because my GET is asking for information and my POST is sending information. So any of these requests can always send information either through the URL path or through the query string. That's probably a question mark. Or inside the, the body if it's a POST or one of those. And then it will, and then it can always send data back, which includes sending nothing back if you want to. You know, just sort of a, you know, just thumbs up signal of, hey, 200 response, this succeeded. Or it can send you back information like this that's going to then use to draw on the front end. By looking at this information of what you're sending out and what you're getting back, you can diagnose a lot about how your front end is working. You don't need to be doing, making a lot of code, don't need to make any of the stuff like you see over here on the left. It's just a matter of being able to right-click, take a look at these things, and even though they're called dev tools, they are your tools, and you can use them to diagnose how it is you're having conversation with the server. Now, one final thing, um, you've probably been noticing this sort of filter business over here at the top, and particularly when you have a whole lot of requests, what are you supposed to do with all that information? And the, and so like usually you'll have, you know, say all and you'll have all of your requests in here and that's totally fine. Usually the most interesting ones you're going to look at are going to be the ones that are called fetch/XHR and that allows you to filter down to just the ones that are, you know, most likely going to your backend as part of your business logic. But if you say them all, well then you can get like all these little JavaScript files and CSS files and see everything that downloaded, which can be really useful, particularly if you're looking at from, you know, understanding performance, for example, like are you getting clogged with lots and lots of files that are all supposed to be coming across here. You can also filter down to find out where, you know, if I want to say, you know, TypeDream, you'll notice nothing in here is called TypeDream, right? This, this thing up here is going to be like all the 213s, right? That's going to be by name. If you want to look for anything that contains the content of what you're looking for, you can do a, you know, you know, Ctrl+F in Windows or Cmd+F in, on the Mac and I could say, you know, TypeDream, you see, and starts to find those couple of requests that actually refer to TypeDream. And that allows me to sort of dial in on what those things are. Now, keeping in mind that all gets kind of fat as we're doing this, and this becomes another use case for potentially wanting to, you know, eject this so you have more of the window to work with and sort of go above and behind instead of left and right. Okay. Hopefully I've given you some tools to be able to start looking into it. And I would encourage you to do this with whatever your favorite website is and start to see underneath how these sites operate. The more you sort of watch the way they operate, the more an intuitive sense you're going to get for how these things work and be able to really bring these, you know, marvelous applications much more under your control because you're not just a no-coder, you're a developer too.