Winning the Performance Race

Hey, everybody. Thanks for joining. My name is Gil. I'm a software engineer at Wix, and today I want to tell you about how we improve the performance of millions of Wix websites.

For those of you who don't know, Wix is a platform for creating websites and web applications, and since Wix websites can be very complex with a lot of different features and components, performance has always been one of our biggest challenges. In the last few years, we heavily invested in performance. We implemented actually many solutions for optimizing websites, but today I want to focus on one big project that created massive improvement in performance.

You can see the impact of performance here. This is a graph based on Core Web Vitals metrics. I'm sure that many of you already know what it is, for those of you who don't. Core Web Vitals is a metric that Google developed to measure the user experience of websites on the internet, and we can use Core Web Vitals to measure our web applications, the applications that render Wix websites. You can see Wix on the orange graph, it's compared to other web platforms or competitors, and you can see how much we improved, from having very low Core Web Vitals results just a few years ago, to having one of the best Core Web Vitals results, relatively in a short period of time, and of course those results reflect user experience in our websites. So although many things happen during this time, the project that I'm about to present to you was one of the biggest influencers for this improvement.

Okay. So in the beginning, my name is Gil. I'm a software engineer at Wix, and in Wix I'm a part of the viewer team. In the viewer team we develop the application that renders Wix websites. So whenever a user goes to a Wix website, our application runs and renders the website.

So in the last two years I'm leading the performance team where we try to find and also, of course, solve performance issues in Wix websites. Going back to this graph, today I want to talk about the journey that we went through. Before I dive into the project and the solutions of how we actually improve the performance of Wix websites, I want to begin by explaining the problems that caused us to have such low results and, of course, user experience, and then also, of course, explain the solution that fixed those problems.

It is important for me to tell you that none of those problems and solutions that I'm going to talk about are specific to Wix. None of them are actually Wix-specific. Maybe, in the beginning, I will start with an example from our application, but very fast I will also talk about why I think those problems and also those solutions can be found and implemented in any web application. I will talk about it more later. So, like I said earlier, there are many things that we did and also that anyone can do to improve the performance of web applications in general, but today I want to focus on the most important and impactful thing we did. We implemented many, many, many different solutions, but the thing that I'm going to talk about is actually the biggest project. It was the biggest project that we implemented. It's also, I think, the hardest problem that we solved, because it's not some lines of code that you can add to your application. By solving this problem, it actually requires more of a change of the architecture of the application. We had to rewrite many parts of our application in order to solve this problem. It's not something that is just changing a few lines of code and just everything resolved. It required a big change, and usually, most applications require a bigger change. Today, I want to tell you how we dramatically decreased the amount of JavaScript that we sent to Wix websites. This is what I'm going to focus on today.

For those of you who are less familiar with this problem, you can see how much JavaScript an application is downloading and executing in the browser by going to the network tab in the browser dev tools, and on the bottom side, you can see you have the transfer size of the JavaScript. On the JavaScript tab, you can see the transfer size and the resource size. Both are important, the difference between them are the compression of the JavaScript, whatever is downloaded is compressed, and the browser is uncompressed and executed, so usually a few times the resource size that the browser is executing is in most cases bigger than the transfer size, about 3, 4, 5, it really depends on the code.

So, first of all I want to talk about why JavaScript size is actually a problem, what caused us to have such a big amount of JavaScript that actually caused us to have a lot of performance issues, so I want to touch on exactly what in our code was actually the problem. And I'm going to give example of one feature in one component to demonstrate this problem, but then of course I'll explain why this problem happened in all over our code. And also of course how it's a very common issue in many applications. So, I'm going to start with a simple example, it's the example of one feature that we have in a button component, and it's the feature that allows our users when they add buttons, like I said Wix is a platform for creating websites, or you can add components and you can add features to those components, so in this example it's the link feature of the button component, you can define where you want the page to go, which page, or whatever you want to happen when the user clicks the button, actually the user of the website. So, like you see in this panel, you can choose what to do when the button is clicked, in case of link, of course, you want to link to somewhere, you can link to page, you can link to external web address, you can link to an email, a phone number, open a lightbox, you can do many things, in case of a page link, you can choose which page to navigate to and also how to open it, so many options, you can choose to configure this link object.

And let's think about how someone would implement this feature. Of course, you would have to save the data from the panel, right? I mean, the developer probably took all the data from the panel, saved it into a database. Let's take a look at the saved data again.

Simple example of the data that was saved based on the panel. So we have the pattern data. Of course it has an ID and a type but also inside the data property you can see the link object. The link object includes the type of the link that the user chose. In this case it was a link, a page link. Means you want to navigate to a different page. And also the page ID of this link, of the page the user chose. So for example, in this example, just another page in our application, in our website. So this is the saved data from this panel.

And then of course, the saved data needs to be passed to the button component to create the link itself. So when the user click it, we will do the navigation. So again, I want to show you how a simple react component would look like implementing this exact logic. So a very simple react component taking the props. Of course the props includes the data that we just saw. You can see the link object. You can see the function calculate link in this code. We will dive into it just in a second. But you can see, it returns an href, and then we take the href and put it in the anchor tag. So whenever the user click the button, it will do the navigation. You can see there's another case in case the user did not add a link because you don't have to add a link. Not all buttons have links. We just render different HTML and just use and button, and maybe in more complicated cases we will add an onClick function. This is very important to differentiate between those tags. For SEO it's very important if you have a href to put an anchor tag, and if you have a regular button, not add it. It's very important for SEO reasons. This is a simple React component that implements the feature that we just presented. This is just an overall architecture of our solution from the panel.

We save the data on our servers, and then when the user goes to the website we send it to the client side, and of course we just saw the JavaScript of the React component that are sent to the client side to create the HTML that we then, of course, display the website with.

So it's a very simple feature, but let's talk a little bit about some issues that we see with this code. The biggest issue is actually in the calculate link function. Now let's dive into this function, the calculate link function.

So this is how the calculate link function looks like. Get some parameters, but then you can see all those cases that, remember, we saw from the panel. We signed the panel, those cases, and now we can see all those cases in our code. So if it's a link page, I need to calculate the link to the page. It could be an external link. I'll probably have this in the data as well. Could be any other cases. If I want to open a popup, I'll probably need more information here. So you can see this function has many, many options from the panel. So let's go over the issues that we see here.

You can probably start imagining the issues that we have here. We give our users many options to configure the components, right? Of course, components can do a lot of things, especially buttons and especially link options. So we give them many options and then we write code to implement those options. But since the user can choose only one option, we write a lot of code that actually is not used in many cases, because since the user can only use one option, most of the other cases are not used, so this is a lot of unused JavaScript code that we download to the client. And of course also, we saw it also inside the calculate link function, but also we can see it in the button component. Because also this code can, there's only one component that, only one HTML that we can send. So but we also need to implement in the button component, two options in this case, and probably more options, so more unused code. So this is the first problem. Many options cause components to download a lot of unused code. But there's actually another problem. And it's actually harder to see in this example because it's a very small example. You can see it here. Resolving the code that took the saved data and actually created the HTML. And let's look at the code, sorry. I'm talking about actually this code. The code actually gets the data from our structure, from our saved data, and create HTML.

In our case, it's basically this calculate link function. Now in our case, simple example, it's just one line of code. But in more complex cases, it's actually more code that we actually have to run. We have to execute this code. So it even takes more time.

In this example, it just takes the page's object and map the ID to get the URL of the page. So you're probably thinking, why do I need to calculate this data instead of saving it? I guess an even simple solution would be to just save the data like you want to view it instead of calculating all these transformations in the client side. So let's say I can save the data with the age ref instead of saving whatever the user chose here. But then if I'll do it, if I'll save the age ref, for example, this URL that I have here, I will actually move the problem to the editor side where I configure the button, because then I need to try to figure out what happens, how do I transform a URL to this panel? Basically it's gonna be very hard to understand which type of navigation the user chose based on this URL. So I don't want to save it to calculate it when the user creates this panel, but then if I want to calculate it in the client side, I need to ship all this JavaScript.

So what do we do? Before I jump into the solution, I want to talk a little bit about is it a week specific issue. And I don't think so. I think this problem of saving data and then sending it to the client side and calculating the HTML from the saved data is also very heavy in a lot of applications. Usually we don't really think when we save data, how we're going to present it. For example, like product page, we don't really think, okay, how I'm going to display this product page. I usually think about what this product has, but how I display it, in a lot of cases it's completely different, then I need to download JavaScript and download the data, trying to calculate how I want to create HTML. Also, having a lot of options for components is also not with specific issues. We develop a lot of, I say front-end developers, in React usually, we create complex components with many options that requires a lot of JavaScript, and sometimes, we only use some of them in our code. So, again, a lot of JavaScript that is actually unused. So, I think that any web application can have this problem, and I'm sure that a lot of applications with performance issues have this problem.

So, let's talk about the solution. So, how do we solve not downloading a lot of unused code? We actually rewrite our components into small feature-specific components. So, instead of having this big button component that could have also a link button but also regular button in different cases, web address buttons and many different buttons, you know, just trying to implement whatever the user wanted, we actually cut those components into small feature-specific components. So, instead of having this big button component, we rewrote it into small feature-specific components. This is the first step, but you can see the href already passed from the props here, so how did we calculate the href? It actually passed, the href is actually now passed from the server. So the second step of the solution is calculating the view data, which in our case is the href, we calculated it in a server, but not in the same server as the save data came from. We actually created a frontend server, which is something between the backend server and our client application. So all this function has moved entirely into the backend, into our frontend server, because it has nothing to do with the browser. All the data that is using this function is basically take save data and calculate view data. So, and of course in this case we have the XML-based URL and of course we can send it to this frontend server.

So let's look at the architecture. If before, before the solution, the save data was sent to the client along with the JavaScript, now we have something in the middle we call frontend servers, basically is just a Node.js server that is kind of like in the middle of the backend server and a client application. And most of the JavaScript is now passed into the frontend server. You don't have to download it, it's just saved there. And we calculate all the view data inside this server, and then we send only view data. And then when we say view data, now mapping it to HTML, calculating the HTML from the view data is very easy. You need very small JavaScript also to download and also to execute. The client application becomes much, much also smaller, but also of course faster. And you can also now, if you calculate the view data in the frontend server, you can add cache in CDN, and then you also not run this JavaScript code in many of the cases. Everything is from the CDN cache. You run it once, you calculate it once, but then you save it in the CDN. So next time it's even faster. So now getting this data is now fast. So it's a small, it sounds like a small change, but it was actually a big change taking saved data, taking the calculate delete function, moving it to the server side that creates only view data. And you can see only the view data moves to the small dump react components that we wrote that just create the HTML. So one small example of one feature in one component, but actually we have a lot of components and a lot of features. And we had this problem in almost every component and every feature. So we had to do a huge refactor to implement to implement the solution in all our application. That's what caused us to have this massive, massive improvement. We did it in all our applications, in all our features, completely redesigned our application, and we moved so much code to the server, cached it, and now a client application is very, very small, gets only view data, transform it to HTML. And that's about it in the client side. So can you do it in any application? Of course, I think it makes sense to do it. I think it makes sense to do it in a lot of applications. You just need to understand what is your data that you are sending to the client side. And then you need to understand which code you can actually move to the server side to calculate the saved data into view data. Then you send, then your components will only get view data, which is very similar to the HTML, so that you will not need any calculations to map this data to HTML.

So to summarize, this is, like I said in the beginning, we did a lot of things to improve performance, and of course it wasn't the only thing, but I think this project was the main reason why we improved so much in the last few years. We gradually moved more and more components and features to this architecture, and by that improved code revivals, and of course in user experience. So the takeaways from today is I think the best way to improve loading time is to decrease the amount of JavaScript download to the client side. You can do it by moving the logic from the client side to the server side, like we talked about. You can write feature-specific components, so you're only downloading the components that you actually need, and not big components with a lot of options, and of course caching the server responses, now that includes the Vue data and the CDN, will actually create your application in a way that it's very, very fast. Thank you very much.