Winning the Performance Race

Rate this content
Bookmark

Over the past two years, we’ve dramatically improved Wix Website performance, beating all of our competitors in Core Web Vitals. This project was a company-wide effort to finally solve the number one user complaint in the company – live site performance. 


In this talk, I will take a deep dive into the design changes that were implemented to achieve this significant improvement, and explain why and how those solutions could be applied in any web application to achieve similar results.

Gil Eckstein
Gil Eckstein
21 min
23 Oct, 2023

Comments

Sign in or register to post your comment.

Video Summary and Transcription

Today's Talk focuses on improving the performance of Wix websites through an architecture change that reduced JavaScript size and improved Core Web Vitals metrics. The implementation of a feature with saved data required rewriting components and calculating view data on a separate frontend server. This approach led to a smaller and faster client application and allowed for caching in the CDN. The key takeaways include reducing JavaScript download, using feature-specific components, and caching server responses.

Available in Español

1. Improving Performance of Wix Websites

Short description:

Today I want to tell you about how we improve the performance of millions of Wix websites. We heavily invested in performance and implemented one big project that created massive improvement. Core Web Vitals is a metric that Google developed to measure the user experience of websites, and we can use it to measure our web applications. The project I'm about to present was one of the biggest influencers for this improvement.

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.

2. Improving Performance of Wix Websites (Part 2)

Short description:

Today I want to talk about the journey that we went through to improve the performance of Wix websites. We implemented a big project that required a change in the architecture of the application. By dramatically decreasing the amount of JavaScript sent to Wix websites, we were able to address performance issues. I will explain why JavaScript size is a problem and give an example of how it affected our code. This is a common issue in many applications.

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.

3. Implementing Feature with Saved Data

Short description:

Let's take a look at how someone would implement this feature. We save the data from the panel into a database and pass it to a button component. The component renders different HTML based on whether a link is added or not. This differentiation is important for SEO purposes. This is a simple React component that implements the feature we just presented.

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.

4. Analyzing Code Issues and Unused JavaScript

Short description:

We save the data on our servers and send it to the client side to create the HTML for the website. The calculate link function has many options from the panel, resulting in a lot of unused code. This is the first problem: many options cause components to download unused code. The second problem is resolving the code that takes the saved data and creates the HTML.

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.

5. Calculating HTML from Saved Data

Short description:

In our case, the calculate link function is used to map the ID to the URL of the page. Saving the data as-is would create challenges in understanding the user's chosen navigation type. To avoid shipping unnecessary JavaScript, we need a solution to the problem of calculating HTML from saved data. This issue is not specific to our case but is common in many applications. To address it, we rewrite components into small feature-specific ones and calculate view data on a separate frontend server. This eliminates the need to download unused code and improves performance.

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.

6. Improving Performance through Server-side Logic

Short description:

The architecture change involved moving the saved data and calculate delete function to the server side, resulting in improved performance. By calculating view data on the frontend server and sending only the necessary data, the client application became smaller and faster. This change also allowed for caching in the CDN, further enhancing performance. This approach can be applied to many applications by understanding the data sent to the client side and moving appropriate code to the server side. The key takeaways are reducing JavaScript download, using feature-specific components, and caching server responses.

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

A Guide to React Rendering Behavior
React Advanced Conference 2022React Advanced Conference 2022
25 min
A Guide to React Rendering Behavior
Top Content
React is a library for "rendering" UI from components, but many users find themselves confused about how React rendering actually works. What do terms like "rendering", "reconciliation", "Fibers", and "committing" actually mean? When do renders happen? How does Context affect rendering, and how do libraries like Redux cause updates? In this talk, we'll clear up the confusion and provide a solid foundation for understanding when, why, and how React renders. We'll look at: - What "rendering" actually is - How React queues renders and the standard rendering behavior - How keys and component types are used in rendering - Techniques for optimizing render performance - How context usage affects rendering behavior| - How external libraries tie into React rendering
Speeding Up Your React App With Less JavaScript
React Summit 2023React Summit 2023
32 min
Speeding Up Your React App With Less JavaScript
Top Content
Too much JavaScript is getting you down? New frameworks promising no JavaScript look interesting, but you have an existing React application to maintain. What if Qwik React is your answer for faster applications startup and better user experience? Qwik React allows you to easily turn your React application into a collection of islands, which can be SSRed and delayed hydrated, and in some instances, hydration skipped altogether. And all of this in an incremental way without a rewrite.
React Concurrency, Explained
React Summit 2023React Summit 2023
23 min
React Concurrency, Explained
Top Content
React 18! Concurrent features! You might’ve already tried the new APIs like useTransition, or you might’ve just heard of them. But do you know how React 18 achieves the performance wins it brings with itself? In this talk, let’s peek under the hood of React 18’s performance features: - How React 18 lowers the time your page stays frozen (aka TBT) - What exactly happens in the main thread when you run useTransition() - What’s the catch with the improvements (there’s no free cake!), and why Vue.js and Preact straight refused to ship anything similar
The Future of Performance Tooling
JSNation 2022JSNation 2022
21 min
The Future of Performance Tooling
Top Content
Our understanding of performance & user-experience has heavily evolved over the years. Web Developer Tooling needs to similarly evolve to make sure it is user-centric, actionable and contextual where modern experiences are concerned. In this talk, Addy will walk you through Chrome and others have been thinking about this problem and what updates they've been making to performance tools to lower the friction for building great experiences on the web.
Optimizing HTML5 Games: 10 Years of Learnings
JS GameDev Summit 2022JS GameDev Summit 2022
33 min
Optimizing HTML5 Games: 10 Years of Learnings
Top Content
The open source PlayCanvas game engine is built specifically for the browser, incorporating 10 years of learnings about optimization. In this talk, you will discover the secret sauce that enables PlayCanvas to generate games with lightning fast load times and rock solid frame rates.
When Optimizations Backfire
JSNation 2023JSNation 2023
26 min
When Optimizations Backfire
Top Content
Ever loaded a font from the Google Fonts CDN? Or added the loading=lazy attribute onto an image? These optimizations are recommended all over the web – but, sometimes, they make your app not faster but slower.
In this talk, Ivan will show when some common performance optimizations backfire – and what we need to do to avoid that.

Workshops on related topic

React Performance Debugging Masterclass
React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Top Content
Featured WorkshopFree
Ivan Akulov
Ivan Akulov
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
Building WebApps That Light Up the Internet with QwikCity
JSNation 2023JSNation 2023
170 min
Building WebApps That Light Up the Internet with QwikCity
Featured WorkshopFree
Miško Hevery
Miško Hevery
Building instant-on web applications at scale have been elusive. Real-world sites need tracking, analytics, and complex user interfaces and interactions. We always start with the best intentions but end up with a less-than-ideal site.
QwikCity is a new meta-framework that allows you to build large-scale applications with constant startup-up performance. We will look at how to build a QwikCity application and what makes it unique. The workshop will show you how to set up a QwikCitp project. How routing works with layout. The demo application will fetch data and present it to the user in an editable form. And finally, how one can use authentication. All of the basic parts for any large-scale applications.
Along the way, we will also look at what makes Qwik unique, and how resumability enables constant startup performance no matter the application complexity.
Next.js 13: Data Fetching Strategies
React Day Berlin 2022React Day Berlin 2022
53 min
Next.js 13: Data Fetching Strategies
Top Content
WorkshopFree
Alice De Mauro
Alice De Mauro
- Introduction- Prerequisites for the workshop- Fetching strategies: fundamentals- Fetching strategies – hands-on: fetch API, cache (static VS dynamic), revalidate, suspense (parallel data fetching)- Test your build and serve it on Vercel- Future: Server components VS Client components- Workshop easter egg (unrelated to the topic, calling out accessibility)- Wrapping up
React Performance Debugging
React Advanced Conference 2023React Advanced Conference 2023
148 min
React Performance Debugging
Workshop
Ivan Akulov
Ivan Akulov
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
Maximize App Performance by Optimizing Web Fonts
Vue.js London 2023Vue.js London 2023
49 min
Maximize App Performance by Optimizing Web Fonts
WorkshopFree
Lazar Nikolov
Lazar Nikolov
You've just landed on a web page and you try to click a certain element, but just before you do, an ad loads on top of it and you end up clicking that thing instead.
That…that’s a layout shift. Everyone, developers and users alike, know that layout shifts are bad. And the later they happen, the more disruptive they are to users. In this workshop we're going to look into how web fonts cause layout shifts and explore a few strategies of loading web fonts without causing big layout shifts.
Table of Contents:What’s CLS and how it’s calculated?How fonts can cause CLS?Font loading strategies for minimizing CLSRecap and conclusion
High-performance Next.js
React Summit 2022React Summit 2022
50 min
High-performance Next.js
Workshop
Michele Riva
Michele Riva
Next.js is a compelling framework that makes many tasks effortless by providing many out-of-the-box solutions. But as soon as our app needs to scale, it is essential to maintain high performance without compromising maintenance and server costs. In this workshop, we will see how to analyze Next.js performances, resources usage, how to scale it, and how to make the right decisions while writing the application architecture.