The Journey of a Pixel in a React Application

Hey everyone, and thank you for joining my talk, The Journey Over Pixel in React Application. Before I talk about the topic, I want to present myself. I'm Shem Magnezi, I'm the co-founder and CTO of Wilco. Before Wilco, I've been in a couple of startups, but then later in a bigger corp, like WeWork and Meta. Today, we're going to talk a little bit about web development and a website, and how they painted on the screen.

Web development has become very easy these days. You open your favorite coding agent, whether it's Base44, or Lovable, or even Cursor, and with a single prompt or a single topic, you get a full-blown application. That's magic, right? However, it's essential to understand what happens behind the scenes. When it's become too easy, we may not truly comprehend what transpires. It's crucial to delve into how things work to identify and rectify issues like bugs and optimization problems.

Improving user experience, optimizing performance, and managing website resources efficiently are vital aspects of web development. Understanding technologies like React, HTML5, and WebSocket can help enhance a website's success. Delving into the engine that powers web applications is crucial to know what happens from the moment a user accesses a site until they can interact with it effectively. It's not just about the magic of web development; it's about understanding the processes that make it all possible.

And it's sometimes scary and even might be not that good. And for this, I want to talk about today, about what happened actually behind the scene, when you're building a website, and you deliver it, and people are using it. Okay? So, once you understand what happened behind the scene, you will be able to then later dive deeper to those topics, and maybe fix some bugs that happened along the way. Maybe there are some areas in your application that are not optimized well. And you need to fix those. In order to fix those, you need to understand specifically how things work. Maybe you want to improve your accessibility and SEO. So, you need to understand how those web applications painted on the screen, and what is an HTML, and CSS, et cetera.

You want sometimes to give better user experience for what you got from scratch, what you got for free, and then you get into specific pages, and maybe try to improve those. Maybe you need to... you heard a little bit about something called React, or HTML5, or even WebSocket, and things like this, and you want to improve your website. And maybe your website is very successful, and then the website is getting a little heavier, a little slower, or just costs tons of money to deliver all those images, and HTMLs, and files, and you need to improve those. And generally speaking, you want to understand what happened behind the scene. You want to understand what goes on behind it. It's not just a magic.

So, that's why I want to jump into the engine that runs your web application, and what happens once you enter a specific website, until actually you can use it and interact with this. Okay? So, I want to start with actually giving an example of our website, the website of Wilco, because I don't want to shame other people, and just want to show that even for someone that knows what actually happens behind the scene, and for our team that are very seniors, even for us, delivering a perfect website is very, very hard. First, it's hard, and you need to deliver a lot of resources, and time, and money, invest a lot of things there in order to give a perfect website, and sometimes it doesn't work. There is always pros and cons, and you sometimes forgive yourself for something that you skip.

So, this is a version of our website, as you can see, apple.co.gg, that I opened with a network tab, and more importantly, I enabled in Chrome a debugging option where the network is very, very, very, very slow, and caching is disabled, and this is conceptually how people with very, very slow internet get into the website on the first try. This is obviously not reflect all our users, most of our users using desktop, and they have internet connection, and wireless, or read wire, and they get it very, very fast, and if you get to the website, you see that in a couple of milliseconds, you get into the website, but once I open it, and in this version, you see how long it takes, how many things going on there, how long it takes until actually the website is interactive and users can use it. I accelerated the time, but it took something like few minutes. This is something that's unacceptable in any application, but I want to show you that even in our application, that we invested a lot, and we know exactly what happened there, even there, it's very, very hard to deliver a perfect website, okay?

So it took two minutes, even more, and accelerated, and now we're going to jump into the flow, and see what's actually going on behind the scenes, because a lot of things going on. A lot of things, but for us, it's all taken for granted, and it's accurate. So the first thing that happened is that I click app.willco.gg, okay? In the address bar, and behind the scene, no one, like the internet, doesn't know what is app.willco.gg. The internet works on IPs, right? So someone needs to translate this app.gg into a specific IP where our website sits on. At the end of the day, an IP is a server that just gives you files. So someone needs to translate it, and this something or someone, it's called DNS, okay? So this process for moving from app.willco.gg or any other text or address to IP is called DNS resolution. Actually, there is not a lot of things that we can do here, and at the end of the day, this is the user machine, but something that we can help with is whether if we have all kind of other resources in the HTML, because at the end of the day, you don't just deliver one HTML. Your HTML loaded a lot of other resources, for example, fonts or things like this.

You want to understand what happened behind the scene. You want to understand what goes on behind it. It's not just magic. So, that's why I want to jump into the engine that runs your web application, and what happens once you enter a specific website, until actually you can use it and interact with this. Okay? So, I want to start with actually giving an example of our website, the website of Wilco, because I don't want to shame other people, and just want to show that even for someone that knows what actually happens behind the scene, and for our team that are very seniors, even for us, delivering a perfect website is very, very hard. First, it's hard, and you need to deliver a lot of resources, and time, and money, invest a lot of things there in order to give a perfect website, and sometimes it doesn't work. There is always pros and cons, and you sometimes forgive yourself for something that you skip.

So this should be very, very fast, like a request here. Here it goes, like continue from there. Whether it's by saving and skipping all kinds of logic, whether it's to implementation, maybe it's using CDNs, those are servers that are very, very efficient in deliver content. We can leverage those, so we can see a simple Node.js app and you see that we have all kinds of middleware that we are doing while we get a request. And then for the root request, we just, okay, this is the static assets, deliver those, and you can see that the current request is giving for this IP, just give us the plain HTML. And usually it should be an HTML, right? The HTML that the browser can handle and see what's going on from there, because there is a waterfall right now, right after this, to get all the other resources. Okay? So we got an HTML back to the browser, and the browser start parsing it and understand how to handle this. Okay? So first is initial the HTML document in here. We need to understand that HTML is a spec that can be very, very confusing or very complex, and we need to keep it very simple. Okay? Because this is the first thing that the browser is doing and it doesn't allow to do other things until it parsed. Okay? So the HTML should be very simple, without a lot of head scripts or things that will block the browser from starting to load all the other resources. And also, if there are critical resources and nice to have items in the HTML, try to differentiate those and the critical content will be right on the start, and the nice to have or thing that you need to load without breaking the flow and interacting the user can be asynchronously after those blocks. Okay? So once we loading and parsing, we need to optimize those. And if the HTML is very, very complex, the HTML parsing will take time that is not necessary. But if we are giving a very simple one, this will be very, very fast, and we can start loading other resources. Okay? So once we have the HTML and once it parsed and once we have the header, we need to fetch a lot of other items because in modern web, it's not just an HTML. And it doesn't matter if we are talking about server side rendering, client side rendering. Obviously with client side rendering, there are a lot more JavaScript, but also with server side rendering. We're going to load CSS files, images, JavaScript, SVGs, all kinds of resources because we want to give a very rich experience to the user. Users are used to a nice looking and interactive website, and we have to do it with other resources like CSS, JavaScript, fonts, other third party libraries, scripts that we need to load. Those are usually append in the header. All the resources that we need, but some are loaded in the body in other versions. So first of all, this is by default. I don't see it anymore, but HTTP 2 used sequence loading. So you load the first CSS, then the second CSS, third CSS. I don't see it too often, but sometimes there are some errors. And again, you need to understand what's the difference and what happened behind the scenes. But with HTTP 2, those resources happen in parallel, so we load a couple of CSS together, JavaScript file, and it saves tons of time. Those files, those JavaScript CSS, can be very heavy. In the end of the day, those are syntax that you write with all the classes and all the functions and all the code that you write.

It can be very big and heavy, but the browser don't really care about your naming convention or readable function names or comments or things like this. So you really have to compress those using all kinds of tools that we have out there. All those resources should be shrinked and compressed in order for those to deliver as fast as possible, and won't take too much time to deliver in the network and then with saving.

When you load those resources, prioritize those. I bet that the CSS for the theme is more important than the image that you put down there in the footer or JavaScript that in order to give you an interaction on the header is more important than the analytics JavaScript that you load. So think about those and prioritize those, and the must-haves should be on the header or blocking scripts and the nice-to-haves can be after in async way.

Here you can see open a network for any website and see how many resources it loads outside of your HTML. It's become some kind of standard, it's completely fine, and HTML and web browser can handle it. Just be able to make things right. Once we have the JavaScript, we need to execute those, because this is a JavaScript, we need to run it. The browser takes it and starts to run everything there. Again, we saw already that we need to zip it, but not only zip it, we also need to remove unnecessary code, because you write a lot of code and you load tons of libraries, but many of them are not relevant.

If, for example, you have a JavaScript file for the admin mechanism and those are regular users, why do users need your JavaScript logic? You can remove those, you can remove unused code for polyfills or things like this. All those things, obviously, you don't need to handle those alone by hand. There are tools that are doing it for you, whether it's shrinking or removing files, and you need to use those.

Here is an example of chunking all kinds of JavaScript files. Instead of a huge JavaScript file, some of them are not used, you chunk it, same for the CSS, and only take the parts that the user needs. We have the HTML, we have the resources, we have the JavaScript, and it starts running, and now we get into the React lifecycle. Again, it's very similar for front-end and back-end, and it's very similar to other frameworks like Vue, but at the end of the day, all those frameworks have some kind of lifecycle inside to draw eventually your website.

So here, again, don't do things that reinvent the wheel, just stick to the best practices, whether Memorize or Effects and things like this, and just use the best practices. If you are getting into a very, very complex or slow pages, it's usually around state management and optimize those. Once we have all the React lifecycle, React will try to merge those virtual tone into the actual DOM. This is something internally that happened in React. Again, stick to the best practices, but like keys and things like this, but generally speaking, I saw many... Most of the time when React became heavy is because there are very, very, very complex components that are hundreds layers deep.