Arjen Karel Core Web Vitals Podcast: Audio automatically transcribed by Sonix

Download the "Arjen Karel Core Web Vitals Podcast audio file directly.

Arjen Karel Core Web Vitals Podcast: this mp3 audio file was automatically transcribed by Sonix with the best speech-to-text algorithms. This transcript may contain errors.

Andrew:
Welcome back to the Clientside podcast. I'm your host, Andrew Armitage, and it's great to be back with you again. We've got another great episode today and a fantastic guest lined up to talk about something that could affect a significant number of websites over the coming months. So I think you'll really enjoy today's show. As usual the podcast is sponsored by the digital agency I founded called A Digital. And this is the podcast where we talk about aspects of websites and digital marketing that are relevant for marketing managers, business owners, entrepreneurs, company directors who want to make the most from their digital activities to support their growth.

Andrew:
Now, whether you like it or not, any website owner is dependent on Google to a greater or lesser extent. Some of you will rely heavily for your organic listings. Others will find organic SEO more challenging and competitive and therefore have to face up to running ad campaigns. But when Google changes its algorithm, it's fair to say that every site owner will be affected one way or another. The trick, of course, is to try and stay one step ahead of the game. But that can be difficult. As search engine optimisation becomes increasingly technical and complex, with multiple ranking factors influencing the position of your site when it comes to both organic and paid search results. You might have heard about something called Core Web Vitals, which is the latest range of metrics that Google are using to determine how they might rank your site in their index.

Andrew:
The core web vitals update was due to be rolled out last year, but as a result of the covid pandemic, the rollout was deferred. But the change is rapidly approaching and will be taking place across the next few months. So when Google blinks, the world listens. And today I'm delighted to be joined by someone who's going to tell us a bit more about what core Web vitals is and what it might mean for your site. Now, the episode does carry a little bit of a health warning because there are some technical terms that we talk about that can't really be avoided. But as a website owner or marketing manager, you've probably heard most of these before, but I'm sure you'll still find this a really valuable discussion. So Arjen Karel joins me from the Netherlands. And he is a page speed wizard and he's worked with well-known brands including Nestlé, Harvard University and Erasmus, as well as providing support to marketing agencies to ensure page speed not only influences search engine rankings, but also maximizes the user experience that demanding visitors have come to expect. Welcome to the show Arjen. And thank you for joining me today.

Arjen:
Well thank you very much. Lovely to be here.

Andrew:
And so just to kick things off, just tell listeners a little bit about yourself and what led you to becoming a speed wizard?

Arjen:
Well, my name Arjen, I used to be a psychologist. And I started working for a university that's where I really started to love technology and what people did on the internet, how to communicate it. And I started digging deeper into the technical aspects of the web.

Andrew:
Great. OK, so, I mean, let's let's talk a little bit about performance then, because performance has been a search engine ranking factor for some time. So let's just go back to basics a little bit. And can you explain what core web vitals is and how that differs from historical measures of page speed and performance?

Arjen:
Yeah, well, page speed always used to be important. It might have been a ranking factor, Google was not very clear about that, but it's certainly an indirect ranking factor. You know, a good fast website will gain more more traffic, more appreciation and even more back links. So it's it's always been important. And lately, Google just specified some some metrics and they said, well, this is very important. This is going to be important in the future and we're going to call it the core web vitals.

Andrew:
Ok, and there's obviously, it's like a suite of metrics, I think, isn't it? I mean, I certainly don't understand all the technical terms around that, but there's there's a handful of different metrics that that really make up core web vitals, if I'm understanding that correctly.

Arjen:
It's basically three, three, three metrics. It's rendering, the painting part of content should be on the screen really, really fast. And the page speed should react to user input and should not block the main track for too long and the layout should be stable. So there's this metric called layout shift and it measures if things don't jump around on the page too much.

Andrew:
Ok, so that's that's quite an interesting one because there's a lot of pages now quite interactive and and do have a lot of behaviours. So is that sort of suggesting that a page with fewer behaviours potentially could perform better?

Arjen:
Well, you know, you can fix the layout shift for almost any page, for simple pages and for really interactive pages. It's just a new way of thinking about it. So don't just inject buttons and behaviour into a page, but make sure the space, for example, is reserved.

Andrew:
Ok, so you're suggesting more of let's say you've; and this is something we see quite commonly on on online booking pages for hotels perhaps the maybe there's an iFrame where a booking page almost sits within a page, within a page. Is that the sort of thing that the layout shift is targeting whereby the page might load and then all of a sudden something else loads in afterwards?

Arjen:
Yeah, that's something it's targeting for example. That's a really great example by the way, more common examples are images that don't have the width and height specified and they will appear on the page at zero by zero pixels then they load and they will they will just increase their size. Or another usual suspects are fonts for example, people are using a lot of web fonts nowadays and web fonts take some time to load, so the page might render with another font first and then the font will switch.

Andrew:
It's that flash of unstyled content that it used to be known as that. That is, as you see the page loading as things start and move around. That's that's really a measure to Google that actually this page could load a little bit quicker than it is doing.

Arjen:
It's not about it's not about speed this one this is about visual stability.

Andrew:
Core Web Vitals is something that was going to be rolled out last year. But because of the pandemic, it's been deferred. What's the current timeline that Google are rolling core web vitals out into their ranking algorithm?

Arjen:
Yeah, that's that's something only Google really knows.

Andrew:
Right.

Arjen:
It's going to be there imminent, but it probably will take quite some time for it to be completely rolled out

Andrew:
Like most things Google, they they tend to keep their cards close to the chest, don't they,

Arjen:
Yeah they do. And they're probably going to change it a little bit. And, you know, I've noticed that they're just announcing these really big and making sure everybody has time to prepare. So the impact that starts hopefully won't be, it won't be too much and they might increase it later, but, you know, no one knows.

Andrew:
Yeah, sure.

Andrew:
Do you have a view on who's likely to be affected? Is this going to affect the vast majority of sites, do you think a lot of sites will be already in a fairly good position as far as core web vitals, or do you see there's there's probably going to be quite a lot of work that's needed for for site owners to get their sites in line and sort of ticking the boxes for core web vitals?

Arjen:
Most of the sites are pretty bad for web vitals. So, yeah, it's going to be a huge opportunity. I'd rather speak of opportunities because, you know, if if the majority of sites have bad core web vitals not much will change for them. But if, you know, someone improves their core web vitals, they're going to have an advantage.

Andrew:
So is there a view that a poor performing site could suddenly be impacted and sort of essentially knocked down the rankings? Or is it not quite as severe as that?

Arjen:
Well, no one knows. I would be surprised if it's going to be Armageddon. But yeah, if there's a lot of difference between between the sites that are now ranking, some fast sites and some really slow sites, those slow sites are going to be impacted for sure.

Andrew:
Yeah, yeah. So like most things, when when Google announced something, it's something that people should really pay attention to.

Arjen:
They should they should have done this years ago.

Andrew:
Right. Yeah. Well, like we said, it's nothing new, really. It's just I suppose they've wrapped it up in a new name and they've given it a bit more publicity over over the last 12 months or so.

Arjen:
Yeah, that's correct. And the funny thing is I see a lot of websites that might really page speed-wise they made really poor choices over the years. And now they're kind of stuck with these choices. So that's that's going to be the major problem for a lot of websites, they use stuff like Elementor and they use HubSpot farms and they'll use all sorts of third party scripts and they really need them now. But then on the other side, on the other hand, they slow down the page by a lot. So that's going to be a big challenge for for a lot of companies.

Andrew:
Yeah, it's something we we term technical debt. So you've got to get over that technical debt before you can start and build in improvements. And that was one really interesting point, because your page speed is 100 percent, as we might expect from someone who does this all the time, 100 percent in Google Page speeding sites for both desktop and mobile, which is pretty amazing. And I'm pleased with some of the results we've achieved ourselves. But what's really interesting, I mean, you touched on hubspot there. But as soon as you add things like live chat, widgets, scripts that connect into marketing platforms or even Google's own analytics code, you immediately start to see percentage points drop off your score. So aside from not using those services, is there anything that can be done to limit their impact or is that down to their services themselves to improve their own performance?

Arjen:
Yeah, it's a combination. For example, you talked about analytics. If page speed is really important for you, there are some options. There's minimal analytics, which is which is slightly faster or there's server side analytics. So it's always going to be a choice. What's important for you, how much time you want to invest and something I see quite commonly, even on your site. It's for example, it's the Google reCAPTCHA. Which I see this all the time, people who want to protect their their forms, so they use Google reCAPTCHA and they load it immediately on page slot, which doesn't make any sense because. You know, nobody's going not going to fill out a form immediately and page slot.

Andrew:
So you can afford to defer the loading in a nutshell.

Arjen:
You can add ab interaction observer, for example, and only load it when the form is in the visible field port.

Andrew:
Yeah, there's a certain irony, I think, that some of Google's own tools can impact on page speed, but I guess it's the way that you actually trigger them. And at what stage of the the page rendering you're determined to load or run that script?

Arjen:
Yeah, it is. So, you know, some scripts are really important for a company and they slow down the page and sometimes there's really no good alternative. So then just accept the slower page speed. But usually you know that they never really considered the page speed and the marketing guy said, well, I mean this and this and this. And they just injected the code and then the page was slow.

Andrew:
Yeah, yeah. So aside from people sort of seeing whether there's a performance problem that they, you know, as they're visiting their own site, because, of course, that could be affected by in some cases, perhaps their own computer. Obviously, the bandwidth on their broadband connection can have an impact. How will people generally find out or how will they know if they've got a performance problem with their site?

Arjen:
Well, search consoles a really great place to start. It will tell you if you have a problem with your core web vitals, you can measure it yourself just right click your page, you'll see click inspect element, click on the lighthouse, and run the lighthouse analysis. And that will give you a pretty good idea of the page speed. Now that's just the lab test, as you said, bandwidth might impact that the performance. Well, actually, it doesn't really. But, you know, real time users, real life users, they have different use cases. They they might have different screen resolutions, different amount of memories, different processor speeds. And that will really make a difference for the page speed sometimes. So that's why you should really use the search console, because they tell you that the scores of the actual users.

Andrew:
Right. That's Google search console, which in theory, most sites should have access to as they've been set up.

Arjen:
And that will give you some historic insight into the core web vitals of your page. And if you want to start improving it, start with Lighthouse, that will give you a great idea. But once you've done lighthouse, I always go directly to the performance step and then run a performance dress. And that will give you the most insight into what's actually happening on the page. Because page speed usually it doesn't have that much to do with the connection speed, it's more about rendering. How does the page render? That's the main question.

Andrew:
Right, and of course, I mean, pages have got bigger over over the years. I think there was was it the Oakly website I remember a number of years ago which created a bit of uproar because it was something like 25 megabytes in size with all its content. But clearly a larger site is going to take longer to download and things like streaming videos, more interactive elements they could all have an impact on, on the overall rendering and speed of a perceived speed sometimes as well. It's not just the actual speed.

Arjen:
They can, but not necessarily. Page speed it kind of works like this. Your browser connects to a server, your browser downloads HTML, it will start building the model, it will start building the CSS object model. Then it will combine those two and from there it will start rendering. And if there's no stuff that's blocking the creation of the rendering, the page will be faster. You can have a pretty large page with lots of stuff in it, lots of interactivity, and your first content and largest content and will probably still be really, really good.

Andrew:
OK. So do you find then that most page speed issues when you when you're running audits on a site to find that it's mainly within the underlying code base of a site, or is it underperforming hosting? Is it a combination of the two or is it bad housekeeping where people are putting large images up that haven't been scaled down? What tends to be sort of the core challenge around page speed?

Arjen:
Yeah, it's usually a combination of at least two factors. The first one is fixing the the stuff they didn't know would slow down the page render blocking JavaScript too much CSS, fonts loaded from Google fonts all sorts of stuff that has faster alternatives. The wrong image containers, the... Just all sorts of stuff that can be done faster and after that, it's usually it's usually Javascript and people tend to add so much third party JavaScript. And that's always the second challenge, talking, talking with the managers, trying to figure out what's actually necessary and how important this page speed vs the data that you want to collect to third parties.

Andrew:
It's really important, then to understand what you need to get out of the sights rather than just thinking, oh, well, just because we can we will add this piece of third party code, because actually that could be having quite a negative impact. And if you're not using that information or you're not gathering or using that data in a particular way, then it's probably not worth it. But it could still be having a negative impact on your site.

Arjen:
Yeah, yeah it is.

Andrew:
So those decisions are all all important. And is there any particular need to score? I mean, my answer would be yes, because ultimately it comes back to the user experience. But when you when you do a lighthouse test or you look at the page speed sites, you get a score for desktop and mobile. How important is it to be scoring highly on both from a search engine perspective? Do you do you sort of get marked down potentially for having a low score on mobile that could impact on the search results that you see on a mobile device? Is there any sort of differences that you've seen there?

Arjen:
It will be both a ranking factor on desktop and mobile, though how large of a ranking factor? Nobody knows. But but it's always been really, really important that it's always been sort of a catalyst for growth. And, you know, you said desktop versus mobile. The funny thing is, unless unless you did something really stupid. If you have good scores for mobile, desktop will be really great. So if you if you're starting with page speeds, start with mobile, always start with mobile and later check desktop, there might be a layout shift and there might be some some large element element that's just not displayed on mobile. Usually mobile is the first thing you want to improve.

Andrew:
So if you score highly on mobile, chances are you're going to score reasonably well on desktop by default.

Arjen:
I've never in theory, it might be possible to score really good on mobile and badly on desktop, but I've never seen that and I've seen a lot of sites.

Andrew:
Yeah. So OK, Just coming back to the distinction between desktop and mobile. What about the distinction between different URLs within a site? So, you know, I guess it's very easy for a lot of people to go to page speed in sites and they'll put their homepage in there. And obviously that will score whatever it does. But clearly, there's a lot more that sits behind the home page in the vast majority of sites, you know, particularly commerce sites. So is is do you see the ranking factor being sort of differentiated between sort of a site wide view of performance? In other words, sort of like an aggregated score for a site versus individual URLs? Do you think there'll be any difference there or I guess from your point of view, you're just going to advocate high performance across the board? But I'm wondering from from a Google point of view whether you think there's going to be a difference?

Arjen:
Well, from from a Google point of view, from a customer point of view, your homepage really isn't the most important page. Usually it's not where the traffic is. It's not where the conversion is. And yeah, I advocate good scores for every page, but usually the page speed is about improving things site wide across the entire site. If you make a mistake in front page, chances are you're making them on every page. So the first thing I always do is look at the templates and see what what can be improved there, because if improve something on a template it will be improved sitewide It's a good overall page score much might you some sitewide trust, nobody knows, but it makes sense to do. If I were a search engine, I would maybe reconsider sending people to the website that has one fast page and 500 slow pages.

Andrew:
Another question which I had was, you know, lots of websites are built on platforms. WordPress being by far the most popular. And of course, there's a whole multitude of platforms. We use platform called Craft CMS in our agency. And some of these platforms give you more access to the code base than others. Some of it might come down to good housekeeping, but then you've got sites that are hosted platforms so Shopify, Squarespace and so on. Are you a bit more limited in terms of what you can influence and what you can achieve with those hosted platforms or the sort of techniques that you can, I suppose, work around the core web vitals?

Arjen:
Yeah, you're extremely limited. For example, Shopify will just inject their own code into any page and that code is really slow. So, yeah, it's you're always going to have a disadvantage when you use you use stuff like that. There are workarounds and it kind of depends on the platform. So have more workarounds some have more options, and some just are really terrible to work with. So, for example, Shopify won't allow you to to generate critical CSS so that that will make the CSS render blocking or you have to add the critical CSS yourself, which is not that great, because if you change something and if you change your style, you have to regenerate all the critical CSS manually.

Andrew:
Right. Yeah. So, critical CSS. Yes. I mean, I'm a former developer and I know it's something our team use.

Arjen:
I'll explain. So maybe you remember a browser fetches the HTML, it creates the document object model and then the render tree. So you need the CSS to create the render tree. Without the CSS the browser doesn't know how to style the page and it won't show anything. So CSS always, not always. But in most cases it's render blocking. So critical CSS is a collection of the CSS styles you're using in the visible viewport so you can inject, so you can add to those only those those styles that you need to render the visible part of speech directly into the head of the page and lays out the original CSS styles. That will make it far easier for the browser to start rendering and you will have the content on the screen first, that's critical CSS.

Andrew:
Well explained. It's essentially prioritizing the styles that are needed to render the visible part of the page, isn't it. So a bit more limited than with with hosted platforms. But you have do you find there are some platforms that perform better than others? I mean, like, say, WordPress, is hugely popular. I presume that on the whole, that is pretty performance as an application. But of course, it goes beyond that because what a developer does, what people might upload into the site, how complex things like plug ins, I suppose they also influence the performance of the application and therefore the rendering and the response that you can expect in the core web vitals.

Arjen:
Mm hmm. So WordPress has the potential to be fast, but you really have to have to think about it when you when you create a Wordpress site that you just download a template somewhere and then add a bunch of plugins, it's probably going to be slow. Plug ins and WordPress sometimes behave really badly and then just inject there the JavaScript in their styles onto every page, Even if it's not used.

Andrew:
There's a lesson to be learned there. I've been selective over the types of plugins that you might want to use on your site, just in the same way there might be for third party external services that you want to connect to.

Arjen:
Well, in the basis you don't want to use, you don't want to use plugins. I'm just talking page speed here. So if you're building a Wordpress site, create a template for each page type that you're going to use and at those those functions, at the functionality that that that you're going to want to need manually, but don't rely on plugins to do it because the plugins. They're programmed to not cause any errors. So most programmers will just inject their JavaScript and their styles, render blocking, and then they're sure they're not going to going to going to get an error because some dependency wasn't loaded.

Andrew:
Right. So you can do a particular page speed audit that's going to come out with some recommendations. This is clearly a piece of work that you can then do around improving and delivering some some performance benefits then. But what might a page speech strategy look like? Is it something that is an ongoing task? Is it something that you can put certain things in place that then can be maintained by good housekeeping? Or is it something that is really an ongoing task that you ought to be sort of running an audit, let's say, every three to six months or even more regular than that? What's what's the best approach when looking at a broader page speech strategy?

Arjen:
Well, that's a great question. Well, it has a lot to do with mindset. Most people come to me that they have really great teams, that they're really good programmers, but they never really considered how a page would render, and that the most important thing. They're thinking only about their code base and how this will work on their part. But they never consider that that the page actually has to render on a lot of devices, devices with limited CPU or really large desktops. And that's what they need to consider. Then if you if you create a page speed strategy around that, you should be able to do to create a pretty fast page. And it should be pretty fast for pretty long. I have I have created a website, I think. ..Twenty two years ago, which still I haven't touched it since, and it still has a 98 page speed score. So if you create a good page speed strategy, it should be fast for a really long time. But yeah, things do change. There is there's lots of new opportunities and new technologies being developed, which will give you a page speed advantage.

Andrew:
And an aside from getting a faster site and potentially improving on your rankings. What are the other benefits of putting a page speed strategy in place over the longer term?

Arjen:
Well, the most important thing is that if you have a really, really fast site. Your visitors will tend to trust you more. It will look more professional, you will get more conversion and you will get more sales. Everything that you want for out of a website will just be a lot easier.

Andrew:
Yeah, just get get better performance all around, not just in a speed sense, but also in a business growth factor as well. Yeah. And one of the things that I've often seen, I think, you know, a lot of major websites do it like the BBC and so on, they'll they'll sometimes put in place holders image placeholders to represent text or images, while clearly there's a bit of lazy loading going on behind the scenes. Is that, is that an approach that can sort of help to enhance your core web vital scores or is that just something that is done to really try and improve the perceived performance of the page?

Arjen:
Well, if you notice lazy loading, you obviously didn't implement it correctly so, but yeah, it's really great. Do not load stuff that you don't need. That's really good practice. So if there's images below the physical viewport, do not load them yet but make sure they are loaded or at least partially loaded or loaded at a lower quality or whatever when they scroll and into view.

Andrew:
I think, you know, it's all well and good looking at page speed strategy once you've got a site. But actually, if you're at the point of starting with a new site, what I'm hearing is there's there's certain elements that you can consider right from the outset and build in. It's almost like building efficiency into a house that you build. You know, you can improve the insulation before you actually fit it. You can generate more sustainable heating or things like that before you install it. And the same sounds like it applies to a website. You can actually influence your page speed quite early on in a build process of a new site.

Arjen:
Yeah, yeah. A lot of companies come to me when they when they when they are developing a new template and they ask me, Arjen will you have a look at it and I think that's a great idea because early on now I can just tell them, well, you should consider this, have you thought about that? Did you know that this would slow down your page.. And then they can fix it without it it's affecting stuff that that's already online.

Andrew:
All right, well, that's been really fascinating to talk in in detail about performance, and page speed insights and obviously, core web vitals, we've touched on Lighthouse and obviously there's the page speeding site inside site, I guess, for for a non-technical person, really, they're just looking to get the highest possible score they can on both their desktop and the mobile.

Arjen:
Yeah, that that sounds really great. That's that's not always the best, best solution. You know, if you want to get a really high score pre add a page, add some text and it should be really, really fast. But, you know, if you're a photographer, you should have really high quality images and that will slow down the page. I always distinguish between slow by mistake and slow by design. And sometimes you made a mistake. You didn't know this would slow down the page. You meant you did something that that that could have could have been faster. And that's fixable. Slow by design. That's a design choice. And that's alright. Just make sure you're faster than your competitors.

Andrew:
Right? Yes. Yeah. You can't have it all in some cases, I think is.

Arjen:
And then. That's right. You know, it's it's not the Holy Grail If you consider page speed. Know what it is. Know hat rendering does. Know alot about page speed. But then there's the option to make choices, to make informed choices. Do I want it to be fast or do I want it to be really, really pretty? And do I want to have a really large video on the homepage that's going to slow it down of course, but if that's important for conversion? Well, there's ways to sort of have both.

Andrew:
Now, all good advice. Well, Arjen we're very much out of time, so you provide an audit and obviously you work directly with with companies and brands to help them improve their page speed. Where can people find out more details of the services that you offer.

Arjen:
My site is www.corewebwitevitals.io

Andrew:
What a great domain name choice you must have had that registered for some time by now.

Arjen:
Well, I think I think the day they announced core web vitals, I registered a few domains.

Andrew:
Yeah, yeah. Good thinking. So the timeline is sort of imminent sort of any time from now in terms of the rollout on Google, it's not going to be the be all and end all. You know, there are other search engine factors clearly that are going to influence ranking. And as you were suggesting earlier, OK none of us know just exactly what Google's rollout plan will be, but it's probably not going to be a sudden panic situation. It's probably something that'll turn the volume up a little bit over time, in a sense, as they increase the speed of the rollout. And I guess they'll learn as part of the rollout as well. They'll be collecting data and reviewing that throughout and sort of trying to fine tune how they roll out the the sort of the full range of core Web vitals and how they apply them to their rankings over time.

Arjen:
Yeah, that's true because, you know, the core Web vitals they are not perfect yet. They never will be, but they keep changing them. And especially for if you have a spa application that the single page application, for example, written react. They really changed a lot for that. But it used to be really hard to get out to get an ok score. And now it's easier they just change the way they measure the core web vitals because that's more in line with how a user would actually view the page speed.

Andrew:
So, like most things are in the world, it's a constant state of change.

Arjen:
Yes, it is.

Andrew:
All right Arjen. Really appreciate you taking the time to join me on the podcast this morning. It's been great. I've learned a few things, I've enjoyed it. It's been a lot of fun. So thanks very much for taking the time. Really appreciate it.

Arjen:
Well, thank you too. It's has been a lot of fun for me to.

Andrew:
So my thanks to Arjen Karel for his wisdom on all things page speed, the good news seems to be that for most sites you're unlikely to see an immediate drop on page rankings. There are other factors that continue to be more important to Google than page speed alone. But with loyalty these days, measured by ease of use, performance is a critical factor in every digital experience. It's also worth considering that like a house with poor insulation, a website that is a slow performer will use more energy and serve resources, which all too often is an invisible cost. You add up all the poor performing sites across the world. The environmental impact of those is significant. So there's a strong case made for maximizing your website performance to help reduce your overall carbon footprint. Now, as expected, there were some technical terms that Arjen used which were really hard to avoid, as this does become quite a technical topic. But inevitably it has commercial implications, hence the importance of talking about it as Google starts to roll out their core Web vitals over the coming months. If you do have any questions on some of the terms we've talked about today that do get in touch with us here at A Digital, or of course, you can get in touch with Arjen, who specialises in page speed performance.

Andrew:
His website, corewebvitals.io, which we'll link up in the show notes at adigital.agency/podcast. So, a really fascinating conversation today and I hope you've learned something from it, even if your mind is just put at rest that you're unlikely to see a sudden drop down Google's rankings over the coming months. However, don't overlook page speed performance. Now is perhaps the time to drive down any technical debt in your site that could impact your performance in the future. So that wraps up another episode of the Clientside podcast. Do get in touch with any comments or feedback. You can email me hello@theclientside.show and of course we'd love to hear from you or if you can take the time to share the episode on your social media or even leave us a rating and a review that would all be much appreciated. So thanks for joining me today. Take care and I'll see you in a couple of weeks time.

Sonix is the world’s most advanced automated transcription, translation, and subtitling platform. Fast, accurate, and affordable.

Automatically convert your mp3 files to text (txt file), Microsoft Word (docx file), and SubRip Subtitle (srt file) in minutes.

Sonix has many features that you'd love including automated translation, automated transcription, enterprise-grade admin tools, powerful integrations and APIs, and easily transcribe your Zoom meetings. Try Sonix for free today.