How to Optimize Your Site for Core Web Vitals | Wix

Hey, everybody, welcome. Welcome to this WIX performance webinar. I'm your host, Brett Harrelson, and let me tell you, we have a jam packed session in store for y'.

All.

This is going to be a fantastic lineup. Today. We're talking about how to optimize for Core Web Vitals. This is amazing. So let me, let me introduce our guest real quick and then we're going to jump into it. So first, Dickla is joining us from Google. She is amazing and she is also, she is also a web ecosystem consultant and she focuses on supporting Google's top partners. She helps them achieve exemplary user experiences, speed business growth through leveraging cutting edge web technologies, and of course, the latest Chrome web capabilities. Dickle, I'm so glad you're here. Thank you for joining us. And joining us from WIX is Dan. Most of you in the partner community know Dan. He's lurking and answers a lot of your real technical questions. And he's been focusing on optimizing sites on wix specifically for speed. And most of you know Dan. Dan's the man. And I'm so glad to have both of you here. This is exciting. So here's what we're going to talk about. We're going to start with dicla and she's going to walk us through navigating through Core Web Vitals and then we're going to switch tracks and Dan's going to specifically talk about what he's been doing to prioritize performance at wix. And he wants to talk about also addressing performance myths and also performance best practices. So let's kick this off. Dikla, let's talk a little bit, if you will. Tell us about Core Web vitals. And welcome.

Thanks, Brett. Hi, everyone. It's great to be here. Thank you, Brett, for that introduction. I'm Dicla, I'm a web ecosystem consultant at Google and I'll talk to you a bit about Core Web vitals. So before we delve in, let's talk about what's at the core of Core Web vitals. Excuse the pun. And that is, of course, user experience. And user experience is not something that is easy to always measure. And we've recognized three pillars of user experience that are quite distinct from one another, starting with loading. When is something happening? Is it happening? Am I seeing on the page what I want to see? After that we have interactivity. Is the page responsive and is it responding in a timely manner? So as quickly as possible? Of course. And then visual stability. Is it delightful to view the page Are things jumping around or not? And so forth. As I mentioned, this is not an easy challenge and therefore we've created Core Web Vitals. We've defined Core Web vitals and these three metrics at that. And the first one is LCP Largest Contentful Paint. Then we have fid, first Input delay. And then we have CLS Cumulative Layout shift. You can see the different thresholds here. And to ensure you're hitting this target for most of your users, a good threshold to measure is the 75th percentile of page load. Now, one scenario which you might have already encountered Core Web vitals with is through this announcement by Google Search announcing that a new signal that combines Core Web Vitals with our existing signals for page experience will be launching. And in fact it has already started. So the gradual launch has started in mid June and it will continue till the end of August. Now let's talk about each metric. So first we have lcp. This measures the render time of the largest content element, whether it's an image or text. And if we look for instance, at the top right corner here, the example, the evaluation continues until the user interacts with the page. So usually that will be for the first view, the first initial view of the page. In the beginning you can see we recognize just a bit of text because that's what's in the page. But eventually, when the page fully loads, what is recognized as the largest contentful paint is the image there, and rightfully so. And the time it takes for that image to load will be reported as the largest contentful page paint. Next we have FID first input delay. This measures the time from when a page, from when a user first interacts with the page until the time when the browser is actually able to respond to that interaction. So we've all been in situations where we've clicked on something on a page, nothing really happens. It takes some time. That is obviously not the best user experience. And we look here at when the page, the browser is free to respond to the first user interaction. And that will be represented by fid. And then lastly, CLS Cumulative Layout shift. This is the sum of the strongest cluster of shifts. And this is in order to measure different shifts that are happening in the page, which is obviously not a very delightful user experience. So we've all encountered situations where we go to a website and then some button or image or ad appears and it shifts the content of the page and those shifts clustered together, capped at five seconds, is what will be counted towards cls. If you want to learn more, I encourage you to Visit the different Web.dev links shared here. You can of course just visit Web.dev and see all the resources we have there and you'll get more information regarding each metric. Now, there are different tools that measure core web vitals, some of which you might already be familiar with, some maybe not. We have Lighthouse, we have crux, we have PageSpeed Insights, which actually is a combination of Lighthouse and Crux in a way. We have the Google Search Console, Chrome Dev tools, the Web Vitals Chrome extension. So there's quite a few of them and each one of them offers a distinct value in order to optimize your user experience. One thing which is worth noting is that some of them display lab data, some of them display field data, and some of them display both. Lab data is is data that is measured on a specific environment while loading your page, and it is what a user is likely to experience in that environment. This is great for debugging and this is great for, let's say you have a certain UI change you want to make and you want to understand what is the impact that change has on performance. You can look at the lab data before and after and get immediate feedback on the impact of that change. On the other side you have field data. Field data, also known as real user metrics, comes from what your users are actually experiencing in the field. This is being collected from actual users visiting your website. This can be collected by you, and this can be collected. For instance, Google collects and publicly shares this data from crux, the Chrome User Experience Report. This is data that is anonymously collected from opted in users and it shows what experience they are having on your website. This is the bottom line. This is what you should be looking at when you assess the experience of your website. If you have any questions, and I'm sure you already do, and you probably will have more questions as you learn more about Core Web vitals. As I mentioned before, there's all the Web.dev links and resources already shared and of course there's also the Core Web Vitals FAQ and it is a great place to visit and understand more. The first question here is unsurprisingly, where does the core Web Vitals data that search considers comes from? And this comes from Crux, which I've already mentioned. So real user data you can use the Search Console Page Experience Report to understand more. As I said, each tool is a bit different. The User Experience Report, for instance, allows you to look at groups of URLs that are grouped together according to the type of page. So that's very useful. And lastly, I want to mention WIX and the great investments and progress they've made in regards to performance at large and core web vitals specifically. Whether it's by evolving the infrastructure as can be read in this beautiful case study published recently, or or by making performance data more accessible to users by creating the site Speed Panel for the partners. Dan will speak about this in a bit later. And as a result of this investment, we're seeing really great improvements in core web vitals. You can see this throughout the last year the number of origins having good core web vitals has significantly improved for WIX websites. You can check this out at the new Corbett Vitals Technology Report and let's hope this continues to rise. I'm sure it will. Dan will tell you more about that. And that's it for me. Thank you very much. And Brad, back to you.

Thank you. Thank you so much for that. Diclo before we switch and I'm really excited to hear specifically from Dan about wix's what WIX has really done here. I did want to ask you a couple quick questions if I can rapid fire just a couple at you here just for clarification. How is it determined if a page passes or fails the web vitals assessment?

Yes, so this is calculated at the 75th percentile over 28 days as mentioned from the crux data. So. So according to that, if a page hits all three core web vitals, then it passes the web vitals assessment.

Thank you for that. And I know there's a lot of other questions and I'll try to come back at the end and save those, but I have two more burning questions specifically for me now you were showing us and we were talking a little bit about site speed tools and measuring tools such as I think a couple of those. There was Lighthouse, PageSpeed Insights. I've seen this a few times from some of our partners conversations and they discussed about the difference, the varying results between some of these tools. Can you tell us a little bit about why that may be?

Yeah, that is a great question. So each tool is different, right? And there are various things that can influence the results you're seeing. So the first thing of course is the lab data versus the field data which we've mentioned. Right. So that is easily the most the biggest thing that will create change just because lab data is run in a very specific environment, whereas field data is for all your users. But even if you're looking just at lab data, for instance, then you will have different results. Sometimes that can occur if the environment is different. Right. So if you're running Lighthouse on PageSpeed Insights or you're running Lighthouse on Chrome dev tools, that will give you very different results because those are different environments. And if you're running it on your own laptop, then you're going to see what the page is currently displaying rather than the the lighthouse run on PageSpeed Insights, which is like an anonymous user opening the page for the first time. Whereas for field data, while it may all come from crux, it can differ. If you're looking at the whole origin data, which is what you'll see on the Chrome user experience report, it will be the whole origin data and it will be per month. And if we're looking at PageSpeed Insight, it can be both the origin and the specific page data, and that will be the last 28 days as opposed to a month. And then we have the search console report, which again shows a bit clusters together different page types. So each of these tools gives something else and has different insights and therefore the results may change.

Thank you. That makes a lot of sense and I'm sure that just cleared up a lot of questions out there. So thank you. I'm going to rapid fire one more Dickla and then we're going to jump to Dan and learn specifically about what WIX is doing to optimize here. But since the core web vitals has launched, we've seen changes and updates to the metrics. So my question is, will that continue being the case?

Yes. So core web vitals have are meant to be dynamic. So as I mentioned, measuring user experience is a challenge and we are always aspiring to improve and be better at that. And sometimes that means we will have to make changes to the metrics. Those changes in the past have been communicated and we will continue to communicate them in advance so that users can properly prepare for those changes and hopefully we'll just get better and better.

Thank you so much, Dikla, and it's an honor to have you here. And I know we'll probably have some more questions towards the end, but before we do that, let's segue here into Dan. Dan, you've been a busy guy and tell us a little bit about what you've been doing to prioritize performance at wix.

Thank you Brett. And thank you Dicla. That was a lot of great information and hi everybody. Well, yes, as we've seen in the class presentation, having good performance is very important for the success of a website. It's important in order to get good engagement for the website to get low bounce rate. And as we've now learned, it's also important for SEO. And as a result, at wix, we're investing significant effort and resources into improving the performance of of all websites hosted on our platform. In fact, improving performance is a top priority across the entire company and involves every part of our organization. And as a result of that, many of you are experiencing noticeable performance improvements in your websites without needing to make any changes on your end. That said, it's important to emphasize that differentworks websites do do experience different levels of improvement. I'd like to say that improving performance is a journey, not a destination. And there's always more work that can be done. And it's the reality that some aspects of our offering are further along than others. But we're working very hard to push all these aspects along. So one great example of the effort that we've put in is that we've essentially re architected and effectively rewrote much of what we call the viewer component of our platform. The viewer is that thing, that aspect of our platform, which takes the data from our servers and uses it to render the websites, the HTML and the CSS that you view when you visit the WIX website. What we've done is that we've moved a lot of the computation from code that used to run in the browser onto our fast servers. And that had two great impacts. First of all, it reduced the amount of JavaScript that we need to download down to the browsers. It's reduced it by up to 80%. The second thing is that it offloaded a lot of the computational effort, which is especially important for visitors who are using lower end mobile devices, which as we know, are becoming the de facto way in which most people access the web. Another thing that we've invested a lot of effort and resources into is our infrastructure. We've created and structured more data centers around the globe. We now have numerous data centers all around the world. So whenever you need to hit one of our servers, you will hit a server that's closer to where you are and involving fewer hops, which means a faster response. And as a site benefit, it also means better uptime for wix because we just have more data centers that we can share across. We are also much smarter about our use of CDNs. First and foremost, all static assets that are used in WIX websites are delivered through CDNs. CDNs, for those who don't know, that stands for Content Delivery Networks. This is a network of servers around the world that essentially cache requests and then respond really quickly because they're usually really close by to your actual visitors wherever they are in the world. So all the static assets, as I mentioned, are now delivered from CDNs. So that includes the media, images, videos, it includes the scripts, the css, et cetera. And now also most of our HTML is also served by CDNs. And finally, last but not least, we've really enhanced our processes to promote performance. And what I mean by that is that it's not enough to make all of these improvements just in order to ensure that performance gets better. You also need to continuously watch out that performance does not degrade, that it doesn't regress. And the way that, that we've gone about that is that we've put in processes in place so that every time we make a change to our code, it actually checks this change. There's an automated process that does a performance test on this change and compares it to the current result. And if we see a degradation, well, that stops the process and that change cannot be rolled out. In addition to that as the same as Google monitors sessions and collects the data into their crux database. We also monitor all WIX sessions also, obviously anonymously. We do it, by the way, from all web browsers, not just from Chrome. This data is also updated to our own servers, which allows us to monitor performance all the time. So that if somehow some degradation made it out, something like slip through the cracks, we recognize it really quickly and are usually able to resolve it before anybody, any one of you actually even notices it. So these are all things that we've done in WIX to ensure that we can provide the best performance that we can.

Just point out one thing real quick, you're getting a lot of praise here. WIX is getting a lot of praise and I know over the past few weeks or so, specifically from partners, they're noticing incredible speed enhancements. You've got some fans here that are, that are attending and a lot of people are saying, Lauren, her desktop scores are near perfect. A lot of people are really appreciating this because it has really changed the game for them as far as speed. So I just want to make sure that the sentiment is said to you. Huge thanks to wix, you're killing it and you have some fans.

Thank you very much. We greatly appreciate it. So first of all, do keep the responses coming in, both the good and the bad. If you are still running into performance issues, like I said, you know your own, your personal mileage may vary. It you know, depends on our components because as I said, you know, we're making a lot of advancements, but we can't advance everything at exactly the same rate. And also the choices that you make have impact on the performance of your site. And we'll discuss this further along. Before we do, Declan already showed a graph similar to this. It's essentially from the same source. It's from the HTTP archive which is based on utilizes crux data. So this is from a Google tool or a Google sponsored tool actually. And it shows the performance data that Google actually collects again from Chrome sessions for WIX sites and for sessions of other CMSs. As you can see, the light blue line, that's us. And you can see that over the past year we've improved by five fold in terms of the ratio of sessions that are good or green for all core web vitals. That means that five times as many session WIX sessions or WIX Pages actually Wix URLs now get good core web web vitals, all three of them, CLS, LCP and FID for the 75th percentile, which ensures, according to what Google has said, the highest possible ranking boost. But even more importantly, from my perspective, a better experience for the people who visit these sites. Now, before we actually go into what you can do in order to improve the performance of your websites and get the most from benefit from all the enhancements that we are making, I do want to address a couple of myths and misconceptions that I encounter when I discuss WIX performance with various partners, customers, designers, etc. So the first myth is that, well, that you can't improve the performance of a WIX website. That really, you know, only WIX can do it and you're stuck with what you have. And the reality is that the decisions that you make while designing and putting content on your website have a significant impact on the performance of the site. As you all know, WIX is a very flexible platform. You have almost unlimited freedom in what you can do in terms of the structure and content of your website. And the decisions that you make definitely have a significant impact on the performance of a website. The next myth that I want to address, and one that I unfortunately see a lot I recently saw it again, is that you guys need to optimize the images before you upload them onto wix. For example, one thing that I recently saw somebody write is that you should resize the images, the width and the height to be as small as possible and match exactly the site that you intend to use. On your webpage. And that's totally incorrect. In fact, it's essentially the opposite. We automatically optimize images and we do a really good job of it. We work really hard to ensure that we deliver the minimal amount of information, but provide the best possible experience to your visitors. If I go again to that example of resizing the image, you should in fact upload the largest image in terms of width and height that you can get. And we will automatically on our servers, resize it and clip it exactly to the needed size of that particular session. And consequently, we download only the bits, the pixels that are actually needed for that particular session. You get the optimal usage of data while providing the best image quality. Another example of the thing that we do is that we automatically transform the image format into WebP, which is a new, relatively new image format originally from Google now, effectively supported by almost all browsers. So we verify that the browser actually supports it, and if it does, then we deliver the image using that format instead, which reduces image download size by approximately 20%. There is a difference that you can make by choosing between JPEG and PNGs, but we'll get to that later on in my presentation. Another myth that I see is that animations are bad for performance, and that if your performance is bad, you should remove all the animations from your website. Again, that's not correct. If you've got, for example, Parallax animations going on, they have no bad impact on your performance. The one thing that you should watch out for is for excessive use of reveal animations. By that, I mean if the stuff in the initial view is automatically animated when the person visits your website. Because the problem with that is, let's say your header flies in from the right then until the movement of that header ends. Then effectively you could say that the page hasn't finished loading because the visitor can't actually read the content of that header text until the animation finishes. So do take into account that if you've got a lot of reveal animations going on automatically as the page loads, you're effectively increasing your load time. Finally, the last myth that I want to touch on is that large videos are bad for performance. That's really not the case. Videos use streaming, which means that they are delivered really efficiently over the network, and they start playing as soon as a little bit of them arrives. You know, like the same as you. The same thing that you experience when you watch videos on YouTube, you don't need to download the entire video in order to watch it. So it's really efficient in that regard, and in most cases, it won't have an adverse impact on your performance. And now we can finally move to the heart of my presentation, which are the things that you can do to get the most out of your WIX website in terms of performance and core web vitals. So I'm going to start with almost the simplest thing, like the basic component of any website, not any WIX website, any website, really, and that is text. You know, it's the text to a great extent that makes the website, because the text is what tells your visitor, you know, who you are, what your website is.