The race to win over customers with the fastest website

When customers click on a link to your business, they expect to start interacting with content and receiving information quickly, which is why the performance of your website is a critical factor in your ability to compete for online traffic.

To ensure that web pages load quickly and smoothly while providing users with a high-quality experience, you need to measure essential factors known as Core Web Vitals. This means understanding what factors go into the performance of your website and what they mean for the customer experience.

Whether your focus is on improving the speed with which the largest content on a web page loads (Largest Contentful Paint), decreasing the time users need to wait before interacting with the page (First Input Delay), or preventing a page’s layout from shifting during the loading process (Cumulative Layout Shift), you’ll need to know what to look for, what good performance looks like, and what tools can track these metrics.

Once you’ve taken these measurements and acted accordingly, your website will be properly fine-tuned and ready to operate as a key asset that differentiates you from others within your industry!

Video transcript


So, let's start on time. Today there is a webinar, like, we're hosting a webinar: “The race to win over customers with the fastest websites. Core web vitals in the automotive industry.” And I will be the host and I will go through the whole presentation and show you around about the topic. To start with, the agenda of: today: I'll talk a little bit about Reffine.


Then, I will go through what are the Core Web Vitals, just so we all can understand exactly what we're talking about. Then, I'll go through how to measure Core Web Vitals and I'll end up with Core Web Vitals in action. So, we went the whole discussion with QA. If you have any questions, just write them down. You can put them into the app and I'll be able to answer in the end.


So, if you at any point have any questions, please write them so I'll be able to answer them in the end. So, Reffine is a company that helps out globally with customers to provide them websites across the globe. We have our own DXP solution. It's a lightweight DXP that helps out with providing websites for the whole company across the globe for each country. We specialize in automotive industry and work with, for example, JLR, which we help out with over 90 countries.


And we also have several solutions that help out the automotive industry. Like for example, stock Locator that helps us digitalize the whole showrooms and provide the cars that are available in stock and put them online. Me, personally, I'm Chief Growth Officer at Reffine. I help out with growing the company and also growing the customers, because we think that by growing customers and helping them out, we can also grow our own business. The needs of our customers are aligned directly to what we do at Reffine.


So, I wanted today to go through the Core Web Vitals because in our opinion, that's really essential when it comes to building a website. So, when you hear Core Web Vitals, what should you think about? First of all, Largest Content Paint. I'll go through each of these separately, but I just wanted to put them in a hole. So, the second is First Input Delay and the third one is Cumulative Layout Shift.


They were introduced by Google. They are measured by Google and they're an official ranking factor from Google's perspective. So, if you're thinking about getting more traffic and getting higher ranking, definitely you should look at Core Web Vitals and they make really a lot of sense because what they want to do is they want to improve how we browse the Internet. But basically when you hear Core Web Vitals, you have to think about your page has to load smooth and blazing fast. This is the essential quote I would put here.


So, it has to go smooth and really fast because that helps with a lot of things when you're browsing Internet. First of all, it helps with user experience. When a visitor enters your website, they want to have it really fast and smooth because this is how they browse the internet. If they have to wait a lot or everything jumps on the page, they will not have a good user experience. Second of all, something that I've already said about is it's an official ranking factor by Google.


Google added core web vitals to Google search console, so you can also check them on your website to see and understand better how, from Google perspective, your website looks like. And third of all, revenue. The faster the pages, the smoother it is, the higher the revenue is. And it's proven because there's a lot of research and I would just quote a few here.


1 second delay in page response can result in a 7% reduction in conversions. So, if you're thinking about an ecommerce site that is making $100,000 per day, just one second delay in the page would cost this company two and a half million in lost sales every year. That seems a lot and it's just worth to improve core web vitals because it actually has an impact on how much revenue can you make. So, let's start with the first one:Largest Contentful Paint. The Largest Contentful Paint shows the time that it takes your page to load its largest content elements.


So, just looking at this example from moz.com on the right, it's the time it takes the page to show exactly what we can find on the page. So more or less the Largest Contentful Paint. If we would talk about how it's similar to something different, we can think about cars. So, it's basically the acceleration from zero to 60. So, how fast the car can go to from zero to 60. This is how Largest Contentful Paint works.


And if you look at the grades, they’re always, like - with Core Web Vitals, there are three grades: red, orange, and green. To get green, you have to load the Largest Contentful Paint between zero and two-and-a-half-seconds. If you load the page between two-and-a-half to 4 seconds, it will be a moderate result, and over 4 seconds it will be slow from Google's perspective. The second core web vital is First Input Delay. First Input Delay measures how fast you can interact with the page.


So, basically when you see the page, you want to click it. You want to click a link on the page to interact with it. And Google tries to check how fast are you loading everything to your page so the person is actually able to interact with the page. So, like, to get a fast result, you have to be between zero and 1.8 seconds. To be moderate, it's 1.8 to three seconds. And when you have time over 3 seconds, it's basically slow and you need to improve First Input Delay.


It's very important from the user's perspective because they don't want only to see the page, but they want to actually browse it, they want to go through it, they want to fill out the form. If we don't help them out with actually letting them do that, it will result in a worse user experience. And the third core web vital that Google takes into account is Cumulative Layout Shift. Cumulative Layout Shift a metric shows how much the layout of the page moves when loading. So, basically if you think about the page when it's loading, often you see on some pages ads that are moving the content further.


This results in clicking, like - you want to just click a certain button and then all of a sudden when the page is loading, it's moved somewhere else. And just because of this, you can’t click the button fast. Even though the First Input Delay is fast, if the button is moving when the page is loading, it will be impossible to click it. And this is exactly what you can see on the image here. Somebody actually wants to click a CTA, so a button, and because the page is moving and loading, they're actually clicking something else, which is frustrating from a user's perspective and that's why Google looks at it.


But there are more web performance metrics that Google at the moment is not looking at. They're measuring it, but they don't add it to Core Web Vitals as the metrics that they take into account as a ranking factor. But they are also helping with user experience. The first one is First Contentful Paint. So, it's the time that it takes the page to actually show you anything on the page while the page is still loading. So, when exactly something appears on the page. Interaction to the Next Paint, that's like a very interesting metric. That shows how a person goes through your website and it's not about loading the first page, it's about loading the second, third, and fourth page.


So, once a person goes to your website, how fast they can interact and load the second page. And that's an interesting metric that Google is talking about to add to Core Web Vitals. But still we don't know what's the actual opinion of Google and if they will do it and when they will do it. Total Blocking Time, so, TPP. It’s how much time, when you're loading a page.


How much blocking time of getting additional information from, like, browser - how much time it takes a browser of additional time that is basically blocked because they can't retrieve specific files and they're waiting. Time to First Byte is basically the time that it takes the browser to get the first piece of content or at least byte of information when they're asking the server to retrieve specific data and page performance scores. It's kind of an overall score that takes into account a lot of actual metrics for web vitals and tries to give you one score for all of them. So, it's between zero and 100 to give you an overall information about how are you performing with Core Web Vitals. Not going into details.


So, all of these specific Core Web Vitals was like an overall score between zero and 100. But how to measure Core Web Vitals? So, at Refine, we try to measure Core Web Vitals at scale. And not only core web vitals, but also additional information about SEO. Because we have so many websites that we try to help with, we have to find a way to simplify it, because there are hundreds of websites that we take care of and we want to understand better what we can actually achieve with specific pages. And each page is different.


So, first of all, we're using GTmetrix. We have at the moment about 556 pages tested on our GTmetrix account. We went through over 10,000 individual tests of performance. So, we're testing a lot of pages multiple times. Actually, we have set up certain amount of pages to be tested automatically every day.


We use also ahrefs as a tool that helps out with information about SEO: how we're doing with technical SEO on our website to understand better where we are doing mistakes and were else we can improve. We’re also comparing data from GTmetrix to web page tests and we did over 300 tests there. And we're using sometimes UiPath to automate the whole thing. But from all of these, I would say UiPath is the least interesting for you.


I would certainly recommend testing your websites with GTmetrix. It's free, you don't have to pay for that. If you're testing just a few websites, you can go just there to the tool and test your page: how it's doing, how fast is it working?


Because we're working with so many websites across the globe, we've prepared on our own dashboard. It helps out to see what we are doing. And I want to show you two dashboards. One is for Mexico region, and the other one is  for Poland. So, to show you how it looks like: we’re taking data from CRUX.


It's basically the same tool as if you go to Page Speed Insights. CRUX is a tool by Google, actually. It's also shown in Google search console. So, it's the same data that is available for you in Pay, Speed Insights, or Google Search Console. So, what we did, we went actually through the websites that we are hosting and we compared it also to different brands, how they are doing.


So, for example, we look at it, like, we look at Largest Content Paint, how we're doing right now, and how we are compared to different brands. So, this helps us to first of all find what we can improve and it also helps us with finding how, like, we are doing in - what are we doing in time to understand. Because Core Web Vitals do change in time. If we add additional scripts to our pages, it's possible that we will lose at some Core Web Vitals and we want to actually know when we're doing it so we can notice when we can improve something. And the same goes with First Input Delay.


As you can see, we're doing quite good here. But, for example, with Cumulative Layout Shift, if we see that we're doing poorly, we understand that here's a place that we actually have to improve on. And at the moment we're working on that for Land Rover Mexico to improve, where we already found, like, specific things that we can improve. And this dashboard, when we constantly look at it and we constantly update it, helps us to find these small things that we can improve to make better performance for our customers. And we have a similar report for Poland.


So, we also compared to different brands. So, we have Porsche, Mercedes-Benz, Audi, Lexus, BMW and we can understand better how we're doing a niche. So, with First Input Delay, with Largest Content Paint, with Cumulative Layout Shift Coming back to our presentation, we not only look for how we can improve in Core Web Vitals- because this is just one thing - but we also try to understand better how we're doing from technical perspective with SEO and do we have many errors on our websites. And we use ahrefs for that. You can do it for free also..


Ahrefs gives the possibility of doing that. You just need to add your Google search console to ahrefs. And by doing that, Google - sorry, ahrefs - lets you do an audit of your page. What we do on our side, we try to keep the score over 80. Some of the pages that we have, have a score over 90.


If we can do better than that, that's, like, really good. But at least this is a trigger for us to find additional ways to improve that. We don't want to go under 80 in results. But Core Web Vitals in action, like, what actually can it give you. So, first of all, there's a lot of research on implication of performance, especially on congestion rate. And here's the research by Portent.


They went through millions of pages as far as I remember, and they’ve checked the conversion rate. Here’s, like, a conversion rate of submitting a form. So, it's not actually a buying journey. So, nobody is buying here anything. But they're checking what’s the conversion on the people that are filling out the form. And they thought that if you actually are able to load the page in a second or under, there's a 39% conversion rate.


But by adding additional seconds, you can see that if your page is loading 5 seconds or more, you just get 22% out of it. So, it's basically the half of all conversions. That's a huge impact because just by improving these couple of seconds of load, you can add an additional 100% of conversions. So, as you can see, the first 5 seconds are, like, there's a steep decline in conversion rate and it's worth the fight, I would say, for at least two, three seconds page load, because that gives you a lot of additional conversions, especially simple ones like filling out the form. If it goes for buying journey, the numbers are a lot lower, but you still can think about it.


Even if it's just like conversion rate at the level of 1%, it can be a difference, one to 2%. So, additional 100% conversions in the buying journey. So, it's, like, very important to keep the page really fast.


Vodafone made a research and they tested out two pages. One page loaded 31% – like, they’ve increased the Largest Contentful Paint by 31%. And they tested out the old version and the new version. And what they saw is just by increasing the Largest Content Paint, they increased 8%. They got 8% more sales, 15% improvement in their leads-to-visit rate and improvement in their cart-to-visit rates.


So, that's a huge improvement just by increasing Largest Contentful Paint by 31%. We did also a research to look at how the pages are loading. This is an example from Mexico. We wanted to visualize how the pages are loading second by second. So, the first column is first second.


The second column is 2 seconds load. 3 seconds load. Just to understand better visually how the pages are loading and what we can see. So, we ordered them from the fastest to the slowest pages. You can see that in Jaguar and Land Rover, the first content that you can see – some buttons – you don't have to see exactly word by word here. I know like everything here is small.


But just looking at first second, you can see that some CTAs, they are already there. And as you can see, they're placed in the right place, so there will be no shift in the content. Also, Lamborghini and Bentley, they are already showing something, a structure of a page. In the second second, you can see already some images appearing and it's possible to browse the page. That's really important because if you can browse the page fast, into maybe 3 seconds, then the interaction with the pages goes smoother, the user experience grows.


But as you can see, even though that you can see a lot on the streams, like in the second second, the page is still loading. So, it takes 10, 11 seconds for the whole page to load. But, like,  really that's important to have Largest Content Paint ready, even though that some additional scripts are loading. So, the person, the user can actually interact with the page. 


So, you can see Acura, also that not a lot is changing on the page during that time. Volvo is extremely fast across the globe because they simplified the page just for the performance. Like, looking at the performance from my perspective, I really admire Volvo for what they did and what kind of business decision they made just to improve the speed. Because they simplified the page a lot, they removed a lot from the page. They simplified the images to be able to have less weight on them and to load them faster.


That's, like, really an interesting example here. Also, like, in Mexico, you can see Audi, Lincoln, Buick, and other types of other brands of cars. We've also compared a similar research for Poland. As you can see for Jaguar and Land Rover, they look a little bit slower. You have to understand that even if you're looking at the same brand, there are differences because there are different scripts on each language, each country, and that causes a lot of changes and differences between the pages.


So, that's why you can see that these pages are a little bit slower than the ones that we saw in Mexico. And also, like, you can see at Porsche that they're loading their page really fast. And so, sometimes looking at visual effects, how actually a person loads the page, helps you to understand when the person can interact with the page, and how we can improve what we can do to improve how the page is loading. But you have to think about GTM Implications. This is research that we did on our own using some of our pages just to understand better what's the impact of GTM's Google Tag manager.


So, what's the impact of GTM to how the page is loading? And we found out that the impact is huge. And that's really, really important to clean Google Tag Manager because you can see that when we tested out the page with Google Tag Manager –


this is the graph on the left – there’s a huge green part. Basically it's Google Tag Manager and how many scripts are loaded with Google tag Manager. This is a wonderful view of all the files that are loaded when the person goes to a website.


And you can see the Largest Contentful Paint took 1.6 seconds to load. And Largest Contentful Paint without Google Tag Manager took 0.86 seconds, which is basically double the time. If you're only looking at the time that it took Google Tag Manager to be loaded, it basically added 100% of time to the website, how the website is loaded. But just remember, you can reduce Google Tag Manager to minimum.


You have to analyze the traffic. So you have, for example, scripts for analytics scripts. You have remarketing pixels. Sometimes you use some A/B test tools, you use Hotjar for recording. You have some social media scripts, additional scripts, which are important. But I'm just saying, think about what you can remove from Google Tag Manager because you're currently not using it. We saw many times that companies, because they were working, for example, with a digital agency, somebody added certain marketing pixels or Hotjar as a recording tool, and then when they stopped looking at it or using it, they forgot to remove it.


And just because, like, nobody knew what to do if somebody is using the certain script, nobody wanted to remove the script, even though that it was useless, because nobody was using it and it was causing additional page load. That's why I would recommend, like, from your side – because I think sometimes digital agency will not help you with that – to do a proper audit of everything that is in your Google Tag Manager and think about it if it's necessary to have it there. Because each script that you have there decreases the time that it takes to load the page.


So, you can look at tracking codes, remarketing pixels, recordings, A/B testing tools, social media spreads and everything else.


That's an example that, for example, we found a script that was adding stories from some social media and it was automatically adding stories about the brand, but it reduced the amount of the speed of the page. And the only problem that it was doing that because it was implemented in the wrong way. We still could use this script. It's not our page that I'm showing you here, I found a similar example. But just because they implemented the script in the wrong way, somebody added a script so they can show stories on their website, introduced the page load by additional 30%.


Also, I wanted to show you how, like how important it is to put scripts into Google Tag Manager in the right way. So, there are few ways, few triggers that you can use to put a certain script on the page. And I'm only talking about here a few examples of triggers that I wanted to show you first. Like Pavel Brecik made a test on his page how certain ways of putting scripts in Google Tag Manager impacts the speed of the page. So, first he tested out with remarking tags from kind of a pixel from Facebook Pixel or AdWords Pixel, just how the page works without the certain tag.


And it's loaded in under one second, which is fast, but we're using it as a reference. So, first trigger that we can implement the certain tag is page view. So, basically we are loading the script when the person is loading the page. Then we know that it will appear in the fastest way. So, the script will start working the fastest, but it will slow down the page the most.


So, it took over one-and-a-half second the page to load with the script, which was triggered on the page view. The second way of triggering a page is when DOM is ready. DOM is a structure of the page. When you look at the code, it's when the structure of the page is already loaded. Then we add the specific scripts, for example, analytics, and we load and start recording data using analytics.


It actually slowed down the page a lot by almost 60%.


But still, when DOM is ready, you can see that there is a small improvement in page load speed compared to page view because we're not loading it straight away, we're just waiting for the DOM – so for the structure of the page – to be ready. So, the third way of improving, like, the script is to, like, the speed, is to send it when the window is loaded. So, actually when your page is loaded, then we're adding the script. This improves the speed of page even further. But you have to understand, if you would, for example, trigger like that analytics, you wouldn't know anything that happened between, like, the page view and window loaded.


So, you will start recording the data once the window is loaded. So, you have to take into account that you might lose some data. But for example, if you have a retargeting pixel, it doesn't matter if you will put a pixel and put a cookie in the browser like two seconds later. If somebody will not stay on your page for two seconds, probably you don't want to retarget the person. And Pavel Pratic added actually a fourth way of loading a page, which is the fastest way. And he triggers not only he waits for the page to be loaded, but he adds additional one half second and then he loads the page, the actual script.


In my opinion, you can look through certain scripts in your GTM and if you just trigger them a little bit later, a second, two seconds, three seconds later than you do right now, that might improve the speed of your page. And sometimes, like in many scripts, it's not necessary to load them as early as possible. Like for example, all the retargeting pixels, you can wait really longer, even additional three, four seconds, not to impact the speed of the loading page because the most important part from your perspective is actually to load the page so the person can interact with it. And there's an additional thing that we found.


So, sometimes you can improve really the speed of the page by improving the DNS lookup. DNS lookup is how much time it takes to find the server, basically. So, if the browser goes to – if somebody types in your page into the browser, the browser asks for where should I look for the server to retrieve the data about the website, to basically take all the information so we can load the page. And sometimes it's just this ask, it's taking a lot of time because it goes through wrong routes or there are old DNS servers somewhere and you can improve the speed of it dramatically. And normally it takes, like, under 100 milliseconds to look up DNS.


So, basically there is a change here, half a second on each click. Basically each time when the person goes through the page and we need to load something additional, you can improve how fast it will show up. If the page is loading three seconds, you basically can take off half a second without losing anything basically. So, also look at this: how you can improve from the infrastructure perspective the DNS lookup. Turned up – like, I would go through key takeaways here, what I would do on your plate. So, first of all, test your page monthly.


I would recommend doing it with, for example, GTmetrix. You can also do Page Speed Insight, which uses Lighthouse for testing out the page, so better understand Core Web Vitals. So, these two evolve like I would do it monthly. First of all, if you do it every day, sometimes there's a glitch on the server, which will show you some different results. So, these results are not 100% accurate.


So, that's why, like, when you look at it in time every month, for example, to look at the speed of the page, you will actually understand better how your page is performing. You can also do some additional tests throughout the month to see how your page is doing within time to have a couple of more tests, not to just look at one, but I would recommend these two. So, first of all, GTmetrix, which is a free tool that you can use to test out your page. And the second one is to verify Core Web Vitals monthly with Page Speed Insights.


This accumulates – at least it used to accumulate data for the last 28 days. So, if you make changes right now, it will not see the changes that happen just right now. We have to wait a couple of days, at least weeks to understand better what are the changes and what's the impact on Core Web Vitals. Third thing, clean up your GTM. And that's on your side.


I would say you can get help from a digital agency to help you out, to help you better understand what scripts you can improve. But that's really important to clean up the GPM and just remove the unnecessary scripts because they're causing a lot of damage, they are causing additional 100% of loading time. Like, sometimes it's even more than that. So, look through all the scripts that you have in your Google Tag Manager and remove all the ones that you're not using. For example, if you're recording sessions, just record them when you need to.


Do a test when you actually, like, are doing a test. The fourth thing is test out your page for Core Web Vitals when you're implementing a new script on the page. Do it because you often don't know what's the impact of the Core Web Vitals and that's the easiest way to actually notice that the script that we're implementing to the page is causing an issue. Because if you're testing just before implementing a script and just after, you can see an impact of just this one script. And that's, like, really important because if you're just testing the whole website, you actually have to find in the waterfall view which script is causing the biggest delay, which is a lot harder.


So, when you're implementing a new script into Google Tag Manager or any metaheads or anywhere on your page, please test out just before implementing and after implementing to see the results and see the impact of the script. And the last thing, don't hesitate to ask your website provider about improvements, especially if you see that there are some problems on your website. Maybe they will not have a solution right now, but then they will actually look at things that they can improve and how they can improve, or you will get information that something will be hard to improve because of certain other problems. You should look at your page every so often because a lot of things on your page are changing. So, if you once increase certain Core Web Vitals, it doesn't mean that it will stay like that in the next month, for a year, because somebody else will add something additional to the page, which will change the score that you have in Core Web Vitals.


If you will have more questions and you would like to contact me about it, feel free. I'll be happy to answer them. If I can help you out with showing you how you can go through Core Web Vitals, how you can set it up inside your company to better understand it. I hope that this webinar was useful for you and will actually help you out of it. If you need to contact me, here's my email. Send me an email and let's talk.


It was great that you actually participated in the webinar and hopefully you will join the next webinar that we will have. Thanks a lot. Have a great day.