Learn all about Core Web Vitals in this 1 hour webinar featuring Dan Shappir, Performance Tech Lead at Wix.com, and Dikla Cohen, Web Ecosystem Consultant at Google. Find out how Wix prepared for the new Google page experience and gain expert advice on optimizing your site’s performance to ensure excellent user experience.
Transcript: Understanding Wix high performance and CWV scores
Speakers
Dikla Cohen, Web Ecosystem Consultant, Google
Brett Haralson, Brett Haralson, Community Manager, Wix
Dan Shappir, Performance Tech Lead, Wix
00:02
Brett: Hey everybody. Welcome. Welcome to this Wix performance webinar. I'm your host, Brett Harralson. 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 introduce our guests real quick. And then we're going to jump into it. So first Dikla is joining us from Google. She is amazing. And she is also a web ecosystem consultant and she focuses on supporting Google's top partners. She helps them achieve exemplary user experiences, speed and business growth through leveraging cutting edge web technologies, and of course, the latest Chrome web capabilities. Dikla, 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. 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 Dikla. And she's gonna walk us through navigating through Core Web Vitals, and then we're gonna switch tracks. And Dan's gonna 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.
01:38
Dikla: Thanks, Brett. Hi, everyone. And it's great to be here. Thank you, Brett for that introduction. I’m Dikla, I'm a web eco system 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, and one scenario, which you might have already encountered [with] Core Web Vitals is through this announcement by Google search, announcing that a new signal that combines corporate 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 [for] 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 [on] 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 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 [on] 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 TLS. If you want to learn more, I encourage you to visit the different web dot dev links shared here, you can, of course, just visit web dot 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 (Chrome User Experience report), 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.
06:32
Dikla: 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 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. It 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, you probably will have more questions as you learn more about Core Web Vitals. As I mentioned before, there's all the web dot 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 corporate vitals data that search considers come from? And this comes from CrUX, which I've already mentioned, so [for] 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 [with] Core Web Vitals specifically. Whether it's by evolving the infrastructure as can be read in this beautiful case study published recently, or by making performance data more accessible to users by creating the Site Speed panel for the Partners. Dan will speak about this 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 Core Web 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 Brett, back to you.
10:20
Brett: Thank you. Thank you so much for that Dikla. Before we switch, and I'm really excited to hear specifically from Dan about 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?
10:43
Dikla: Yes, so this is calculated at the 75th percentile over 28 days, as mentioned from the CrUX data. So according to that, if a page hits all three Core Web Vitals, then it passes the Web Vitals assessment.
11:04
Brett: 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 the difference in the varying results between some of these tools. Can you tell us a little bit about why that may be?
11:38
Dikla: 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 biggest thing that will create change, just because lab data is running 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 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.
13:32
Brett: 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 Dikla. 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?
13:54
Dikla: Yes. So Core Web Vitals 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, will just get better and better.
14:33
Brett: 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.
14:54
Dan: Thank you, Brett. And thank you Dikla. That was a lot of great information. And hi everybody. Well, yes, as we've seen in Dikla’s 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 a 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 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 different Wix websites 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. That had two great impacts.
First of all, it reduced the amount of JavaScript that we need to download down to the browsers, it reduced it by up to 80%. And 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 visit to hit one of our servers, you will have a server that's closer to where you are, involving fewer hops, which means a faster response. And as a side 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 cash 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, etc. 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 [to ensure] performance does not degrade, that it doesn't regress. And the way 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.
19:25
Dan: 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, the same as Google monitors sessions and collects the data into their CrUX database. We also monitor all sessions, all Wix sessions also obviously anonymously. We do it by the way from all web browsers, not just from Chrome and this data is also updated to our own servers, which allows us to monitor performance all the time. So that if somehow some degradation, like made it out, something, like, slipped 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.
20:30
Brett: And Dan, I just want to 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 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.
21:06
Dan: Thank you very much, Brett, we greatly appreciate it. So first of all, do keep the responses coming in, both the good and the bad. If you're 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 [an] impact on the performance of your site. And we'll discuss this further along. Before we do Dikla already showed a graph similar to this, it's essentially from the same source. It's from the HTTP Archive, which is based on, it utilizes CrUX data. So this is from a Google tool or Google sponsor tool, actually.
And it shows the performance data that Google actually collects, again, from Chrome sessions, for Wix sites and for info sessions of other CMSs. And 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 sessions, Wix sessions on Wix pages, actually, Wix URLs now get good Core 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 benefit from all the enhancements that we're 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 size 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 worked really hard to ensure that we deliver the minimal amount of information but provide the best possible experience to your visitors. So 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. So you get the optimal usage of data while providing the best image quality. Another example of the things 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.
25:53
Dan: So we verify that the browser actually supports it. And if it does, then we deliver the image using that format instead, which reduces the image download size by approximately 20%. There is a difference that you can make by, you know, choosing between JPEGs 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 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. And 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 that 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.
And finally, the last method I want to touch on is that large videos are bad for performance. That's really not the case of videos that 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 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 Wix, 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 about, what they can do on your website. And there are a couple of things that you can do with text to ensure good performance.
First and foremost, just make sure that you have some meaningful content, text on the initial viewport, or sometimes referred to as above the fold. That's the initial area of the page that is visible before your visitor scrolls. So I've seen pages that have just an image or maybe even a gallery, and until the visitor scrolls down, there's nothing for them to read. That's from my perspective, that's bad experience.
First of all, text usually loads faster than images. But beyond that, I want to know who you are before I decide whether I even want to scroll within your website or not.
Also, we usually recommend limiting the number of fonts and font weights that you put [on] the site. First of all, I have to say that from my own perspective, excessive use of fonts can make a site look unprofessional and unappealing. But beyond that, in some cases, text will not actually be visible until its font downloads, the font that it uses, finishes downloading. So if you're using a lot of fonts, it will take longer for all the fonts to download, and therefore it will take longer for the text to appear.
One thing that's really Wix specific, you've got this feature where you can upload your own custom font. And we've seen situations where people accidentally upload the same font multiple times, and then use the various fonts that they uploaded, even though it's the same font, multiple times, and that results in the same font, being downloaded multiple times to your visitor’s browser, which isn't great for performance. Now, we are working on having a systemic solution to this, to automatically prevent this from happening. But until we finish implementing it, please be aware of it and try to avoid uploading the same font multiple times for the same website.
30:50
Dan: And another important thing, you know, seems kind of unrelated necessarily to performance—is to ensure good contrast with your text. But let me give you a quick example. Suppose you have white text on top of a dark image on top of a white page background. Well, what happens is that even if the text loads before the image, the visitor won't see the text until the image loads, because it will just be white text on top of [a] white background. Now we work really hard to load images as quickly as possible. But still, like I said before, text usually loads faster. So you know, try to think how you can ensure good contrast in all conditions.
And last but not least, avoid text in images. And what I mean by that is not text that's overlaid on top of images, that's perfectly fine. I mean text, that's actually a part of the image itself. That is embedded in the image. It's bad for performance, because until the image loads, there's no text. But it's also really bad for SEO and accessibility. Because search bots and also screen readers just don't see this text. So yeah, it's not good and you should definitely strive to avoid it.
Media is the other like, big thing with modern web sites, and by media, I mean, images, videos, and whatnot. So one thing to look out for with images especially, is to check and watch out for extra large downloads. You know, if an image file is tens of kilobytes, or hundreds of kilobytes, there's one thing, but if it's a couple of megabytes, that's another. Now, I'm not talking about the size of the image that you upload onto Wix. I'm talking about the size of the image that actually gets downloaded. There are various tools that you can use to check that like the Chrome Dev Tools that's built into the browser, the Network tab, or the Web Page Test tool, there are other tools as well, if you've got really large downloads, that can be detrimental to performance.
I mentioned before that we optimize images for you. That being said, and without going into too many technical details, because I just don't have the time for it. You should just take it as a given that you should prefer JPEGs over PNGs, where applicable. That will result in (usually) smaller downloads for the same size and almost the same quality of images. Usually it's indistinguishable. There are certain situations where PNGs are required. For example, if you need transparency, because for example, you're using parallax or something like that, in such cases, you just have to go with a PNGs. But when you can, definitely do [choose] JPEGs. As I said, the image size, the download size of the image will be smaller, and your users or visitors usually won't be able to tell the difference.
[The] thing is and this is interesting that SVG or shapes, as they are referred to in our Editors are actually better than both. So for example, if you can get your logo as an SVG, for example, if you're using the Wix Logo [Maker], then definitely do [choose] an SVG and SVG is smaller, it's sharp from the get go. It remains sharp when the visitor lets zooms in or zooms out. It's always sharp. And like I said, it's usually much smaller than any other image format.
Generally, avoid GIFs. I mean, there are, you know, certain cases. For example, if you've got this really tiny animated thing, like an arrow pointing down, but again, watch out for the extra large download, you'd be surprised. But if it's, if you're looking to create some sort of animated effect, just avoid GIFs. Use a looping video instead, just put in a video, configure it to run in a loop and just use that instead. I've seen websites that download a 12 megabyte GIF, and it's just bad for performance. So, you know, in most cases, you should definitely strive to avoid them.
35:20
Dan: Another Wix specific thing, when you set an image as a strip background, you can actually also specify the background color behind the strip, if you make—behind the image, if you make the image partially transparent, that color shows through. But even if you don't make that image transparent, it turns out that this color has value. You can set it by clicking on that tiny fold on the left corner, top corner. And the reason is that that color will show up briefly, while that image loads, potentially, especially over slower connections. So if you specify a color that matches the primary color, the background color of the image, that will result in a better visitor experience, because I have seen situations of like this jarring transition where the primary color of the image is green but somebody set the strip background color to pink, and it creates this really jarring transition. And it also can have a detrimental impact on performance measurement tools.
I want to talk about mobile, because the majority of our visitors based on all the data that we collect, something like 70% of the people, even over 70% of the people who visit Wix websites, use mobile devices. So it's really important to have good performance on mobile. So if you're using the regular Editor, the Wix Editor, don't forget to go into the mobile Editor and to verify that your pages look good on mobile. We worked really hard on the automatic creation of the mobile view. But you know, it's still, it's your website, and you know, best. So do go into the mobile Editor, make sure that everything is properly organized there, and that your site looks good on mobile devices. One of the cool things about the mobile Editor these days is that you can both add and hide content specifically for the mobile. So you can hide some stuff that you only want to show on the desktop that's potentially less important because you know, what can we do? Mobile has less screen real estate, so you need to be more targeted. And you can add stuff. So for example, you can hide the less important content and magnify the more important content and make it easier to view on those smaller screens.
You can also maybe reduce the number of items in galleries or feeds or repeaters. I've seen mobile pages that are 30 screens long. I mean, who expects a visitor to scroll down through 30 screens of the mobile device, you know, it probably means that the page is probably too long.
And there are no free lunches, the more stuff that you put on the page. You know, we try to do things like lazy loading, we're working on making it even smarter. But again, no free lunches. Anything that you put on a page has a certain cost. That accidentally made it into the wrong slide. We'll fix it later. But—so those are the things that I wanted to say about mobile.
In addition, there are several general suggestions that I'd like to make. Dikla actually showed a screenshot of our new Site Speed panel in the Wix dashboard for your site. We were really happy that this panel was also shown in the recent Google I/O Keynote. And it's a really useful tool. It has two parts. On the top part you see data from the field that we collect from actual Wix site sessions, live sessions, and we compare you based on that data to other sites within your domain. And the bottom part actually shows data that we retrieve from Google PageSpeed Insights. So it's essentially the same lab data that you would see if you ran Google PageSpeed Insights on that same website.
39:56
Dan: If you're using Velo on your pages, especially If you put in like, a site level script, which effectively impacts all pages, then you may, there's a good chance that you will need to enable manual caching for your pages. That means going into the Page Settings, going into the Advanced Settings, and then enabling Manual Caching and specifying the longest possible duration that's appropriate for you. What that does is that it ensures that the HTML of the page gets cached into a CDN for quick delivery.
If you're not using Velo, then in the vast majority of cases, we will do this automatically for you. But if you are using Velo, then you know, we can't really know what you're doing in your Velo code on the server. So we can't know that we can safely cache your content and for how long. So that's the reason why you may need to enable manual caching. By the way, when content is cached into a CDN, you don't have to worry about outdated content being delivered. Because the instant you, let's say, for example, publish a new version of your site, we automatically push that update to the CDN to replace the previous version.
Be careful of excessive use of marketing integrations. And by that I mean stuff like Facebook Pixels or the Google Tag Manager. I mean, you know, obviously, they're required, you know, they serve a purpose, you're running marketing campaigns, for example, but make sure to only add those marketing integrations that you actually use. And once you're done with them, please remember to remove them. It's very easy to forget them there to just leave them there, because the page will keep on working but they do have a bad impact on your site performance. Surprisingly so sometimes, I've seen Wix pages where a marketing integrations account for half the loading time of the page. It's that significant.
In general, if you're using videos, I would recommend to use the Wix Video Player rather than external video players, because with external video players, we actually need to download those external video players. And for example, the YouTube video player is something like half a megabyte of a download of JavaScript. So just you know, not the video, just the player, it's pretty heavy. So in general, when you can [choose] using the Wix Video Player over the one of the external video players.
I already mentioned this before, there are no free lunches, the more stuff you put on a page, the heavier the page becomes, the longer it takes to load. So if you've got really long pages, please consider splitting them into several shorter pages. For example, maybe you can move an FAQ off of the main page. Or maybe you can move, you know the blog, just have a link to your blog, but actually put the blog on some other page instead of the homepage. Again, it's up to you. It's your content. If it needs to be there, then it definitely should be there. But again, be aware that there's a cost to everything that you put on your page.
Lightboxes and animated galleries can be detrimental. The reality is that the way in which Core Web Vitals are measured, and the page experience ranking in general can ding you for using lightboxes, for example. Because think about it, your content appears and then a few seconds later, a lightbox appears so effectively from the perspective of Core Web Vitals, your page really hasn't finished loading until that lightbox is displayed which creates an extra delay. Also, lightboxes often get in the way of the main content on the page, which is not great. So yeah, if you're running like a special promotion, you know, it makes sense to use a lightbox. But definitely don't put your primary content like “the who you are” in a lightbox. Put it within your page itself. And don't use lightboxes and automatically animated galleries unless they bring actual benefit to your web page or website.
44:49
Dan: And my final tip is it's so easy within Wix to duplicate either a page or even the entire website. So you can duplicate your site, and then run it through a performance testing tool, comparing the score of your current site to the replicated site. you can use our Version Releases and A/B test. Currently, you know, the A/B test, you won't be able to get separate performance data for the A/B test. But you can, let's say, create a duplicate of your page, use one version for a while and see how it impacts your site speed. And then use another version and see how it impacts your site speed. Or, again, use one of those lab tools for immediate results, you know, go which way you want.
Before I conclude my part, and everybody, you can see that I really like to talk and get into the details. I just want to mention that you can follow me on Twitter, I'm fairly active there. I tweet about Wix related stuff about performance related information. I also try to occasionally write stuff on Facebook, so feel free to reach out to me there. But Twitter is where I'm most active. And I tried to follow back. So yeah, you know, hit me up there. And with that, Brett, I conclude my part.
46:20
Brett: So, Dan, I just want to say thanks so much. We have a lot of questions, and I'm gonna rapid fire three to you. But I do want to say thanks so much. And what's so amazing about this, Dan is I love that you're able to come here and show this and talk about some of these numbers and show the performance efforts that's been done at Wix to really, really move the needle. And everybody's seeing this. And I you know, it's funny, because you know, you and I spend time together, and we talk behind the scenes, and we get excited about what's coming. But to actually see it, right? And get to have these numbers and show the graphs.
46:55
Dan: First of all, it will be excellent if you can link to this presentation. But I do want to mention that most of the stuff that's here, and you know, hopefully all of the stuff that's here is available in more detail in Knowledge Base articles, many of which are linked to from the new Site Speed panel. So you can, you know, all our users can just go into the Site Speed panel, they will find links to various Knowledge Base articles about performance, and they expand on a lot of the information that I've provided here. And we're working hard to ensure that they contain all the information.
47:33
Brett: Amazing. Thank you very much. Thank you very much, Dan. So let me throw a few questions out here. Here's one that we wrote down, “The new Site Speed dashboard is displaying that my site's performance is good. But I'm seeing a low score in the initial view in the Google PSI. Why is that?”
47:57
Dan: So as I mentioned, the Site Speed dashboard actually has two parts. The top part, which you see initially when you load it, and then the bottom part that you actually need to scroll down to. So if you're looking at the bottom part, then that should actually show you the same scores for desktop and for mobile, that you're getting from PSI. Because effectively the values that we put there, we just send your site over, your page over to PSI, the homepage of your site over to PSI, run PSI on it, and then just put the data there.
Now, as Dikla mentioned, you know, there can be fluctuations in your scores, because of you know, the web and the internet, you're not operating in a vacuum. So you may want to run both PSI, multiple times, and maybe also do a refresh within the Site Speed panel, just to see how the scores jump around a little bit. But overall, that bottom number should actually be the same.
Now the top number, or the top values that you see, as I mentioned, those are actually collected from the field. So those are actually the performance numbers that we get from sessions of real people who are visiting your website. And those may or may not match the numbers that you get from PSI because as Dikla mentioned, PSI just runs, loads the site while measuring it in this one particular environment. That environment may be similar, or maybe very different from what your visitors actually have. Now, if it's different, then your users might get, you know, either better or worse experience than what you may see in PSI. Now, what actually determines at the end of the day, again, as Dikla explained, what actually determines [it] at the end of the day, is the actual experience of your visitors. That [is] what counts for the success of your website in terms of the Google ranking. And more importantly, in terms of whether or not your visitors engage with the site and don't bounce, because when I visit your site, I don't really care what your PSI score is, I care what my experience is. Now you can use your PSI as an indicator, your PSI score, you can look at what you're currently getting, make some changes, and see whether it's improving or degrading. And based on that you can kind of draw an inference of what may happen when you deploy it in the field. But that's more or less the value of those lab tests.
50:46
Brett: As always, Dan, a very thorough and precise answer.
Dan: And that's a nice way to say that I'm—
Brett: Very well-versed. No, no, no, very well-versed. This is an amazing, amazing panel, we have here. Dikla, I want to toss one to you. Earlier, while you were presenting, there was a little side conversation that a lot of the attendees were having regarding some of the extensions for Core Web Vitals. My question to you is, and I think actually Ryan asked this, “Is there a recommended one?”
51:25
Dikla: Well, there's only one official one from Google. It is in the Chrome Store. It's from Addy Osmani, [who] is a senior engineer for the Chrome platform. And I think we'll be able to share a link later with the recording. So we'll do that. But yeah, there's one from Chrome. You can also find more details on the Chrome GitHub page.
51:56
Brett: Perfect. Thank you. Thank you very much for that, Dikla. Dan, I've got another one that I want to throw at you. So here's a question. “Google Search Console is showing me that some of my pages have ‘needs improvement’, or it's even poor CWV? How will that impact their search ranking?”
52:20
Dan: Ask Dikla, she won't be able to answer either. Look at the end of the day, ranking is up to Google. And what I can say and what I'm allowed to say is based on what Google has said, that Google ranks primarily on stuff like content and, and authority and stuff like that, you know, content is king, people like to say in SEO. And that's the case, at the end of the day, Google wants to show you the things that you want to find.
The Core Web Vitals as part of the page experience signal, that's just one of hundreds of signals that are an input into the Google search engine. So if you're in a very competitive field, then it can be—sort of you can think about it as a sort of a tiebreaker. If you've got a certain quality of content, and your competitor has more or less the same quality of content and authority, then that page experience signal can be a tiebreaker. And within it, the performance can be the deciding factor.
Now what Google has said in the recent Google I/O, and that's all the information that I can give, because, you know, I don't work for Google. So I don't know what happens inside search. What they have said is that if they look at each one of these three metrics independently, and so you, for example, if you've got good FID, but poor LCP, you'll still get a ranking boost for potentially, get a ranking boost for FID, but not for LCP. So first of all, each one of them is taken independently.
And what they've also said is that if you get a poor value for a particular metric for one of these three Core Web Vitals, then you won't get a boost for that particular metric. If you get a Yellow or Needs Improvement, you will get a partial boost for it depending on how close you are to the good part. And the boost plateaus when you reach Good. So once you reach Good, you will get the maximum possible boost for that particular metric, and it won't improve anymore.
But like I said, from my perspective, actually the most important thing is that good-performing sites have good engagements. You know, if people get to your site, but then bounce because performance is poor, you know, what's the point? But that's what I can say about it.
54:54
Brett: I think that I think that's interesting. And it was another question I think that was asked as well. “Specifically Is there a PSI score that someone would shoot for to rank well on Google? Is there like a number, a gauge? What do you recommend?”
55:12
Dan: Again, PSI and Dikla, and jump in if she wants, but PSI in and of itself is not a ranking signal. As Dikla explained what Google uses to impact—as a ranking signal that impacts potentially, your rank within Google is the actual experience of actual visitors to your website, as collected into the CrUX database. Not PSI. PSI can be an indicator of you know what you may expect. So for example, if you don't get enough traffic yet, if you haven't published it, then you won't actually make it into CrUX, you only make it into CruX if you have sufficient traffic. So you can use PSI lab scores as a sort of an indicator of what you might expect to get.
Mostly though, I would use PSI as a means to see whether you're improving or regressing. So you can look at the score you're getting, make some changes, and see if you're able to push that score up. Now, how will that score correlate to what your users will actually experience? I don't know. It depends. I mean, you know, if your users are primarily coming, let’s say from Canada, where they generally have really fast connections, and people usually have fairly fast mobile devices, a lot of iPhones. Then it might be that your mobile scores will actually be dramatically better than what you might see in PSI, like two times better, three times better. Who knows?
56:50
Brett: Well, that makes sense. That makes sense. Dan, that makes a lot of sense. But I wanted to interject, Dikla, did you want to add to this?
56:57
Dikla: Yeah, I know what Dan is saying, in general about lab data is very true and we discussed it before. As for ranking, I can't comment. And also I don't know. But yeah, so also, as Dan mentioned, again, the bottom line here is to improve the user experience. And that's definitely something that's worth doing and looking both at lab and field data.
57:26
Dan: I have to mention that, again, everything that I said that's kind of related to ranking is not based on any special information that Google, you know, gave us because they haven't. It's all based on my understanding of public information that Google has released, for example, in the context of the recent Google I/O conference.
57:49
Brett: Well, I can say that this has been incredibly jam-packed with amazing info, some awesome tips. Both of y'all are absolute rockstars. I can't thank you enough for coming and sharing all of your information. I think we should probably do this weekly, I’m volunteering both of you, I'm just teasing, I'm teasing. But this has been incredible, incredible. So I want to say thank you on behalf of me, and I know the Partners that love this and everybody else that really want to optimize their sites and be awesome and get found and be successful. So huge thanks to both of you. I want to say thank you.