Opinionated Core Web Vitals - JSJ 647

they use this information at least to an extent. But I still think that there's a lot to discuss here and to take apart, and especially given that I'm going to take this kind of an opinionated view of this whole thing, very non corporate. So everything that I'm saying is my own opinions and nothing to do with my employers or anything like that. Hopefully I won't get into any trouble.

from ads. I think Google is like the biggest ad company in the world or something like that. Maybe Facebook might be giving them a run for that position, but other than that, I think they're the biggest by far. And most of that, not all of it, but most of it I think is coming from ads on websites.

So Google has this incentive that more people browse the web, because then more people will be exposed to their ads, and Google makes more money, and that means that they want a better web, a web that people spend more time on, and for me, as a proponent of the open web, that's really a good thing. So I'm really happy that this alignment has happened. And whatever their motivation, as long as is they're doing good things, well, I'm

happy about it. And when Google tries to push the industry in what they consider to be the right direction, they have like these two whips that they can use to prod us along, to get us going. And one huge whip is the Google Search. All of us want our websites to rank, because if you don't rank, then

you don't exist. And if they make something a ranking factor or ranking signal then and then go public about it telling everybody that that's the case, well, people have this huge incentive to invest in that aspect of their website. And that's one thing that they can do and they

have done in the past. And the other thing that the other whip that they hold is the Chrome web browser, which I think is the most popular web browser at least that's what I see when I look at the WIG statistics about the browsers that our visitors are mostly using. And that's also whip because they can adjust the Chrome UI to encourage certain things in websites. And I'll give

an example. A few years ago, Google decided that the web needs to be h GDPs everywhere, that if we want the web to be good, it needs to respect privacy, it needs to respect security, and for that it needs to be a GTPs. Now, you know, I still remember not so long ago, if you would go to some online store or whatever, and it would be just h GDP, and it wouldn't turn to HDPS until you were actually

at the checkout. And then let's say it might redirect to PayPal or something like that, and only then would it actually become AGTPS. But all the rest of the thing, the entire process was over at GDP, which from my perspective is also problematic because I don't want people to know what I'm shopping for. And Google rightfully, you know, concluded that that's a bad thing and that everybody should be AHGTPS all the time. I hope everybody agrees with

me here. And what they did is they exactly use these two whips that they had so in the in the search, they basically told people that h GTPs is going to be a ranking factor that all other things being equal, if there are like two sites that have equivalent that content and authority, one is a GTPs and the other is h GDP, the one that uses HDPS will rank over the one that just uses HTP. Now, to be fair, it doesn't even need to be true.

It's just sufficient that they say that that's what they're going to do, and that really gets a lot of people going. And the other thing that they did is that they modified the chrome UI initially to put this kind of a greenish background behind htps r LS and then put a reddish background behind h GDP or LS. I think that now there are that's done. They have this lock icon. I don't think they put the colors anymore.

But they got it into people's heads that h GDP was dangerous, that it's not a good thing, and then that you should prefer h GDPs, and they use chrome for that purpose. So by using these two things, these two whips, like I said, or prags, they got us all moving in the right direction. And now they are effectively doing or trying to do the exact same thing with regard to performance. And that's where core web vitals come into the picture.

It's interesting that Google has put themselves in a position to sort of push some of these ideas or push some of these technological choices right where I think a lot of other companies would have just let things coast, right. It would have been like, well, whatever people want to do, right, and so it would have been up to the public instead of up to folks like Google to push some of this stuff.

to be the experience when you're online. So that would be my guess. But like I said, I think that we're kind of lucky in that the overall the good of the web in most cases, not all cases, and we shouldn't always count on it to be true, but in a lot of cases, the good of the web and the good of financial benefit of Google currently align, which is lucky for us. Is don't aligned that much with Apple, for example, which is not really unfortunate for us.

website has good performance or not? And what does good performance actually constitute, how do you measure it, and what do you actually measure What might be good performance for one type of a website might be bad for a different type of website. Or it's also dependent on geographic locations because the web, let's say, in Canada, is much

faster than the web, let's say, in India. So it gets much more complicated when when you look at that factor of performance, and that that's kind of the reason that we had that big episode a while back on where are literally listed for an entire hour and in a bit of that entire recording, a whole bunch of performance metrics, because there are a lot of different measurements that you can take in when you're trying to gauge the performance of a particular website, so it really becomes

tricky and in order to kind of address so oh, let me put it differently. When Google decided that they're going to be focusing on performance, they concluded, and again rightfully so in my opinion, that it has to be metrics that are valid that actually indicate something real about the performance of a website, but it also can't be something It can't they can't have too many metrics. So you know, there are a lot of aspects of web performance that you can measure, but they're not going to

focus on everything all at once. Instead, they're going to focus on a particular subset of things what they would consider to be the most important things. Because the vast majority of web developers and designers and SEO people, et cetera that are out there are not performance experts, don't want to be, and shouldn't be, And if you came at them with something like twenty different metrics that they need to now analyze and measure and analyze and optimize,

it's just not going to happen. So what Google did essentially is like they did this two step process. First of all, they came up with something that which they called web vitals, which were a larger set of performance metrics. And then out of these they distilled three metrics which they refer to as core web vitals, which are the ones that they're going to focus on or now are

at present. And what they also said is that every year they're going to look at these three core web vitals see if they're still the ones that you need to focus on and potentially modify them, evaluate them, maybe even replace them with other metrics if they see a need. So so far, they've announced the set of three metrics back in twenty in the beginning of twenty twenty, I think, and so far they haven't changed them, so for now

at least, they're sticking with it. And these three core web vital metrics are LCP or largest Content for paint, FID which stands for first input delay, and CLS which stands for commulative layout shift. And these are the ones that they're focusing on, and these are the ones that they're now starting to use as a ranking signal into Google Search. Which means that the the values that get measured for your website for these metrics can impact the ranking of your site, at least in mobile searches.

hundred milliseconds kind of thing. They've got these benchmarks. So is it just when the bot hits it?

and that's totally not the case. People were also looking at measurement tools that Google put out there, like a Google Lighthouse and Google based with Insights and thought, hey, they're probably going to be using Lighthouse to measure your website and use that number. Well, again, that's totally not

the case. So I mentioned we had Rick VISCOMI on a previous episode, and Rick is the person at Google who manages a project called CRUX, which stands for Chrome User Experience and this and there is a reminder of what this thing is. It turns out that when you install Chrome on your device, or if it comes pre installed unless you opt out, then Chrome gathers data about all the websurfing that you're doing. To do people still

use the term websurfing. I don't know all the websites if you visit all your web sessions, Google collects information about that anonymous of course, and it gets sent up to the mothership. So it gets collected in this huge Google database, and that includes performance information. So they measure your Chrome measures the time that it takes for your website to load effectively, and that measurement or those measurements actually because it's more than one number, gets sent back

to Google and gets put into this database called CRUX. Now, Google then uses this information as the input as an input more accurately to their Google ranking algorithm. So the Google ranking algorithm receives a ton of signals from a lot of different sources, and the various analysis that they perform on a website they like look at things like

the quality of the content, the BACKLNK, the authority, et cetera. Well, now they have another ranking signal which incorporates the performance data that they get from this Crux database, which means ultimately that the number that they use or the numbers that they use in order to determine whether your website has good performance or not is based on actually the actual experience of real users who are using Google Chrome

as their browser. Unfortunately, they're not looking at people who are using other browsers, so Safari users, for example, have zero impact on this ranking signal. Likewise, Firefox users or even Edge users, even though Edge is using the same chromium engine as Chrome, because it's a Chrome thing, it's not a Chromium thing.

which is largest content for paint. It measures the time from the start of the session until when that the biggest content element within the initial viewport was rendered. Usually that would be an image, but it might also be text. Interestingly, svgs don't count, so what why? My guess is that svgs would be too easy to fake. Here's the thing about co web vitals that Google needs to take into account.

On the one hand, there are supposed to be these metrics that putting Google aside, there are supposed to be these metrics that if you optimize, if you improve, you will get a better website. I mean, getting good performance is not just about the rank. Like I said, the rank is kind of the whip. Getting good performance is also about the user experience. If you have good performance, you'll have better engagements, you'll have a lower bounce rate.

Those are the things that should really be of interest to a site owner if people If you have an online store, even if people find it but then it loads so slowly that they just leave without buying everything, that what have you gained? You want people to engage with your content, and that, amongst other things, requires good performance. So in an ideal world, the co web vitals what you would just think about, the youth, the visitor experience.

But once Google may has made them a ranking signal, they also need to take into account that people will do bad things in order to improve their rank. It's it's unfortunate, but it's well known that it happens. So think about me like putting this I don't know, an SBG box around my entire viewport just to create this big visual element, because it's as big as the entire viewport,

but it's effectively empty. It's like this one line SVG and it's embedded into the HTML, so it will be like the first thing to render, and I would get a really great LCP score even though I've literally done nothing to actually improve the actual user experience. Now I'm not saying that this is the reason why Google has done it, but that's my guess. Or let's put it

this way. They have another metric that's a web vital, but not a core web vital, which is first content for paint, which measures when the first element of content is rendered on the page, and that one does take SVG into account. So it's interesting that for the first contentful paint they do take svgs into account, but for the largest content for paint they actually don't take svgs

into account. Okay, it is what it is. So an LCP would be either the biggest image or the biggest piece of text, whichever is the bigger one between them. In the case of text, it's the rounding is the box that contains the text, So it would be let's say, if the text, let's say is inside of div, it would be the rectangle of that div, the closing rectangle of that div.

them more useful. Some people are kind of annoyed by it because people are working hard on optimizing these metrics, and then Google comes along and modifies how they actually measure one of the metrics that can be annoying or confusing. So, for example, in Chrome eighty eight, they modified the LCP metric to ignore full full viewpoint images, so if an image covered the entire viewport, they would actually ignore it.

And the motivation was that such an image is probably a background image and consequently it's not like the main content of the page, and therefore they decided to ignore it. By the way, the whole reason for picking largest contentful paint is that they kind of ran tests. They sat people,

at least that's what they told me. They sat people in front of computers, had them load website and like click a button when they thought the PA the site load was loaded and finished loaded, And what they found is that in most cases, the time, the point in time where the people clicked the button correlated to when the largest piece of content was rendered in the browser window.

So that's where this metric came from. Now, a big problem with LCP, though, is that you never know unless the content covers the entire viewport, in which case, like I said, for images, it's actually ignored. You never know if a bigger piece of content is not going to occur like a little bit later. So think about it. Let's say the page is loading, it draws something, it's that's the largest contentful paint until this point in time, but then something bigger might be drawn a second later,

which which it then becomes the largest contentful paine. So the question is kind of when do you stop? And and that's one of the problematic measure things about this measurement. So they stop when the user interacts with the page. So if the user scrolls or clicks, they say, okay, if the user does something with the page, it means that from the users with the visitor's perspective, the page is not so you know, no, no point in waiting

for more stuff. But that's kind of one of the problems with with LCP, and and that's one of the reasons why when it's measured in lap conditions, like by a tool like Lighthouse, you might get really different results and what you might get in the field because it might be stopping at a different point, And that's a problem with it. There are other issues with it as well, but those are like the main ones.

and so I want to improve this. How do I know what the large what the thing is that they're measuring, right, Because I mean ideally, what I'd like to do is I'd like to say, oh, they're measuring when I load this image or you know this, well whatever, right when I load in this piece, and so do I optim I'd like to be able to optimize that and then maybe something else take takes that on or I don't know, I'd like to know which piece to optimize. Is there a good way to know that?

Google Paid speed Insight. You put in the URL for the existing site, you put in the r L for the new site, and it essentially just simulates a session

in a certain configuration. For example, Paid speed Insight actually simulates the mobile device, the Moto G four on a three G network, and then it runs a test for a couple of seconds, loads the site, sees what's the largest piece of content within the initial viewport and basically measures how long until that got rendered, and you can compare the value that it gets for the existing site with the value that you're getting for the new version

that you're currently building. And not only that, it will actually show you which of the elements on the page is that is the one that it picked as the largest content for paint so it might be an image, and then you can go and check and say Hey, I'm actually loading this huge PNG. If I use converted to a JPEG instead, it would be tenths It would be a tenth of the size and it will download so much faster. Or maybe I can even use one of the newer formats like web or aviif and make

it even smaller than that. Or maybe I'll change the design of my page a little bit on mobiles so that instead of an image being my largest content and for paint, I'll make my headline text be slightly bigger, and then it will be my largest content for paint. And maybe instead of a web font, I'll use one of the quote unquote system fonts like Aril or even times in Roment or whatever, so it doesn't even need to download the font, and then I would get really

really good RCP value because it's just text. So yeah, so one way to go about it is a lab tool or synthetic tool like paid speed in sits like Lighthouse. The other way that you can go about it is that you can actually look if your site gets sufficient traffic, you can actually get data from that same Crux database that Google uses for ranking. So and Rick actually touched on that. So it's interesting. First of all, they don't

put every website into the Crux database. You need to get a certain amount of traffic before they even conder put you in that database. So, just so you know, if you create a new website that doesn't yet have any traffic, you're not going to get this boost for performance, even if your website is really fast, until you get

sufficient traffic to actually get into that database. And sufficient traffic I think is like a couple of one hundred visitors or thousands of visitors a day or something like that. So you do need to get a certain amount, minimal amount of traffic before you they even consider you. So you won't get penalized, but you won't get the boost for that, not because you're not fast enough, but because you just don't have you don't yet have enough traffic

to even be in that database. But suppose you are in that database, well, there are two ways for you to look at the values that Google is calculating for you. One way is using Google pay Speed Insights. In the middle of the page, they have a section called field data, and they will actually show you the values that you got over the past twenty eight days. So the sort of an aggregate value, and what they're looking at is

the seventy fifth percent time. So for example, for LCP, a good value is hundred two and a half seconds

or less. So they look at the seventy fifth percent time, that is the value that is slower than seventy five percent of your users and faster than your slowest twenty five percent of users, and see if that falls in the good range, which is two point five seconds or less, or in the quote unquote needs improvement range, which is between four seconds and two and a half seconds, or in the poor range, which is slower than four seconds. If it falls within that poor range, you won't get

a boost for that metric. If you fall within the needs improvement range, you will get a certain boost that's relative to how good you are. So it's like a it's a linear growth sort of a thing. They're not giving the exact formula, but let's assume that it's some sort of a linear growth. So the closer you are to the good section, the more boost you will get, and once you get to the good section, it plateaus.

So once you get to that two point five seconds, that's you get the maximum boost, and if you manage to improve it from two point five to one point five, you won't get any higher boost for your ranking. You might get happier users on your page, but in terms of the ranking, that's the maximum boost that you will get for that particular metric, So that that's LCP.

Does it kind of add up the time it takes including loading in whatever components I've put into my website so that this thing shows up or doesn't, and including all the CSS, And does it also include the time it takes to go back to the server and say okay, now I need this spreadsheet, now I need this JavaScript and stuff like that, or is it just the paint time?

their website. And you now have a co web vitals section or panel or tab call it whatever within your search console, and they will actually show you the current situation broken down by pages. So they will say pages of this type have let's say poor LCP or they need improvement for CLS. And again, this data is coming in from the Crux database. I think it doesn't really matter. It's the end of the day, it's the same source of data. Is that data that they collect from actual

Chrome sessions? They actually in this case, I think they actually do have like this daily moving average, but it's still averaged over a twenty eight day period. So even if you made a significant improvement, take into account that it will take some time for Google to actually notice it. But now going back to your question, and the answer is that yes, you know, modern web pages are complicated beasts. That's one of the reasons for this podcast, I think.

And there are a lot of moving parts. There's the back end, there's the network, whether or not you use CPNS. That's the media that you're downloading to the browser for its format. Are you downloading it via CDN or you know, using something like a cloud flare or something like that. How much JavaScript are you running on your browser? All these things impact performance and sense co ed vitals try to measure performance. All these things impact co ed vitals.

The bottom line in terms of LCP is that you want to get your primary content down, you know, in front of the visitor as quickly as possible. So, for example, if it's an image, you it's better if the HTML that is downloaded from the server already has that image SRC inside of it, rather than you first having to download let's say React and run React on the client side.

Because all you're actually serving is just blank HTML, you know what the emptydive, and you're totally constructing your entire user experience on the client side, you're probably going to get poorer performance. And that's that's just a reflection of reality because your visitors are gett a poor performance. You know, it might be easier for you to build your website this way, but the end of the day, I think what matters most should be the experience of our visitors

and customers and whatnot. So, yes, you do need to take into account your server time. If you're serving a really dynamic, dynamic content, then you need to think about

your database queries. Or maybe alternatively, you can use something like a static side generator, you know, like a gem stack sort of thing, and you're still doing all these database queries, but you're doing them at build time rather than in run time, and then the page just gets generated and pushed into a CDN and then it's delivered really really quickly. So yes, there are a lot of moving parts in modern websites and you need to think

about them. What can I say? Yeah, So moving on to the second core web vital, which is FID or first input delay. That one measure the time from the first interaction that the visitor has with a web page.

Let's say it could be a mouse click or button press whatever, until the browser can process that request, Which means that if there's let's say some client side JavaScript associated with with that mouse click, then until the browser can run that JavaScript, or if it's some sort of a default action, then until the browser can instigate that default action. So that's what gets measured by first input delay.

And the things that can cause a lengthy first input delay are, for example, if you're running a whole bunch of JavaScript on inside the browser, and the browsers well, they're much there. They're not single as single threaded as they used to be, but they're still pretty single threaded.

So if your main thread is busy because it's running a lot of JavaScript, and because of that, if the user clicks on something then nothing happens, then you'll get a poor ID And it only measures first the first one. That's the first input delay, I guess, because you don't get a second chance to make a first impression. And yeah, that's what it measures. And the thing here is is that it really annoys people when they try to interact with the user interface and that user interface does not

respond to their interactions. The example that I like to give is when standing in front of an elevator and you press the button, you don't expect the door to open immediately, so you don't actually expect that operation that you requested to instantly finish. You're happy if it happens, but usually it doesn't happen. But you do expect the button to instantly turn on, and you do expect the numbers to start counting towards your floor. And if you

click the button, then nothing happened. Where people do this sort of thing, it's called rage clicks. They start going to tap tap, tap, tap tap, and it's the same thing with web interface or app interface. You know, especially on mobile devices, people have become really used to this kind of an instantaneous response that when you tap something, it responds to your tap, and if it doesn't, well, it can drive you nuts. And that that is the thing that first input delay tries to measure now Here.

is being processed. So it could be some sort of a spinner color something, And you're totally correct that if I build a user interface where the visual cues or the visual feedback is so minimal that many users might not even notice it, you're doing damage. It's frustrating. So that's totally true. So just to finish that point on FID, as with LCP, it's kind of this green yellow red like street light, where the green part the good part,

is from zero to one hundred million seconds. So anything fast, if that's one hundred million seconds or faster, counts as good. If I d up to three hundred milliseconds counts as needs improvement, and anything above three hundred milliseconds count as poor. And that's based on a lot of user interface research that has been done over the years that shows that people consider anything better than one hundred milliseconds to be in effectively instantaneous.

these Cobb vitals is now calculated independently. Initially, when Google presented this model, there was the assumption that you're only going to get the boost if you're green that is good, and that you're only going to get the boost if you're good or green for all the three and recently they came out and said, no, each one of these metrics is going to be measured independently, and you're going to start getting a boost even in if you're in

the needs improvement range. You're going to achieve the maximum boost once you reach that good range. And then, like I said, it plateaus. I guess the reason that they've said that that they haven't been clear that. So it's not like they said, we change our minds, because they were never really explicit about it before. But that's what

most people understood. And I'm guessing that Google just looked at the results out there and said, hey, if we do it that way, then too many people won't get any boost and people would be just totally discouraged and not try to improve anything. So at least give them, then say, if they're like really bad on one of the metrics but might be good in the others, at least get give them an incentive to improve what they

can improve, at least for now. So they're going to measure each one of these metrics independently.

my code better. Instead of downloading I don't know a meg of JavaScript in order to get my page up and running, maybe I can download one hundred k of JavaScript to get my page up and running. Maybe I can download my JavaScript in parts so that in order to get that button up and running, I only need twenty k of JavaScript to be downloaded, parsed, and run, and I can download the rest. Even when somebody actually needs it, and so on and so forth, So that

would be the good way of improving my FID. So the nuts A good way would be to hide the button until I finished downloading all my JavaScript, and then there'll be nothing to press until I'm ready for you. I could do that, but and then people might just bounce off of the page. But if they do click, they will get a good FID value, so they're Like I said, there are good ways to improve things, and

there are not so good ways to improve things. But the best way to improve FID is, like I said, by reducing the JavaScript payload that is needed to support the initial interactions and also to avoid let's say, really complicated CSS. Maybe that could really create a bottleneck in terms of the rendering of the page and stuff like that. But the only thing that I can say here is that in most cases that I've seen, unless people do

really bad things, FID is usually pretty good. If I look at the other metrics, people are having a lot of problems with CLS, and people are having a lot of problems with LCP. Most websites that I've seen that actually make it into the Crux database usually have pretty good fight unless you're doing really bad stuff with JavaScript. Like I said, downloading a full mag of JavaScript jezip just to get things, just to get the ball rolling,

then then you've got a problem. But if that's not the case, then you should be okay for FID, which brings us to the last metric, which is CLS. And this is an interesting one that one actually tries to

measure what is called visual stability. I'm sure you've all encountered this situation where you've been reading some sort let's say an online article or blog post or whatever, and you're in the middle of reading a paragraph and then the page jumps because it just finished loading an image and that image pushed everything down, or maybe it replaced an AD and the new ad there's a different size from the previous ad, so things get either pulled up

or pushed down, and you've lost your position in the page. And that's obviously a very poor user experience. I hate it when it happens, and it definitely happens in a lot of new sites. So what CLS measures is how much things on the page jump around, not in response

to direct user interactions. So they look whenever something on the page moves, They first of all they check to see if it's you know, if there was a user interaction in the past half second or so, and if there has, then they ignore it because they say, well, there's a chance that it's in response to that user interaction,

will let it slide. But if it's not that, if nothing, like the user is just reading, then they look at the size of the thing that moved and at how far it moved, and they calculate a number based on that, like a sort of a ratio number, how much of the viewport has moved and how far has it. And it's cummulative in the sense that it's not like the LCP which is looking for the largest paint and ignoring the others, or FID, which looks at the first interaction

and then ignores subsequent interactions. It continues to measure to measure these movements. So the such movements that you have on the page, the bigger the value that you will get. And it just keeps on running and running and running throughout the entire session. And now they changed it now, and I'll explain how they change it in a second, but I just wanted to verify that that's clear, because

it's a kind of a complicated metric. And it's also complicated because unlike the other metrics, it doesn't measure time. In fact, it doesn't have really any sort of a units. It's just a number.

And Google have been making changes as they go along and as they receive feedback from the field, from partners and whatnot, but they have been as forthcoming as they could be about the stuff that they're actually measuring.

room do you get on this right? Do they give you any grace to the beginning or is it just hey, no, okay, so it's got to come in pretty solid then.

that image. And it has to do with the fact that in the browsers with HTML, everything kind of flows, so if you push something in the middle, it kind of pushes everything aside in order to make or down

in order to make room for that thing. And so what you should be doing is that you should be putting the dimensions of the expected dimensions of that image in the image HTML tag, so you can actually put with equals and high equals and then it will reserve that blank space for that image and then won't need to shift things around in order to make room for it. Or you could use CSS for that as well. But the point is that you want to reserve space for

things so that you don't need to shift things around. Now, it can get really complicated in some scenarios, like for example, with ads, because a lot of times you have very little control over AD sizes. But maybe that'll force the industry to kind of standardize on AD sizes. I don't

know now. What Google have done is they've made a recent change that they've made this measurement window, which means that they kind of divide your session into five second segments, and they measured the CLS within eah five second segment and report the CLS the biggest CLS that they've found. And the reason that they've done that is that they were getting pushedback that long lived sessions were getting really bad CLS scores simply because they were running for a

really long time. So for example, people would open I don't know, let's say a Facebook web page, have it opened for an entire day, and it would get this huge CLS value at the end of the day because of a million of tiny shifts that nobody ever actually noticed, which accumulated over the entire day. So in order to remedy that, they've recently modified it, as I explained, to kind of work in the sort of a windowed kind of a manner.

page and you're using CSS animation for that. If you're animating the actual X and Y of that element, you will get a really big CLS value. What you want to animate instead is that transform X and Y of that element. And the reason is that when you use transformations, you're not causing reflows, so the pay the stuff on the page doesn't actually move and therefore there's no layout shift,

and that's what you want to animate. So let's say you have a cookie banner and actually something that we had at Wix, so we added you know, GDPR and everything. We added the cookie banner, and we suddenly saw and we also measure obviously the corbet vitals for all our sessions, and we notice a jump in the CLS And it turns out that the developer created this cookie banner just animated on the X and Y, and we just modified it to animate on the transfer on the transform X

and Y, and visually there was absolutely no difference. If anything, it was slightly smoother and the CLS issue was fixed. So it's really so if you're using animations, it's really important that you animate on transformations rather than, for example, on the position or the size of the element. I hope that was clear.

transform CSS or the transformed options like you're talking about. If I don't get penalized for that, then that's definitely the way I want to go so that I can maintain the user experience that I'm building, but at the same time not get penalized for it by Google.

So unless you're creating your your stuff by hand, in which case watch out for it. If you're using some sort of a library, there's a you're probably getting the

correct behavior out of the box. But you can always use a tool like Lighthouse which I mentioned before, page speed Insights, and you know, add this component, throw it in there, measure it and if you suddenly see that your CLS is jumped, and it actually shows you as with LCP it actually pagemen Insight will actually show you which elements on the page cause the shift, and you can say Okay, I see that this animated thingy is causing a shift. Let me check my animation.

pretty fun and also like very beneficial. You can get really really really fine grained, as Dan was mentioning with your lighthouse scores and automating the regressions against those, so you can get super fine grained on every single one of these measurements. You can set what you're We were using get have Actions that I set up, but based on like you know, if you merge a pull request or put up a PR or something like that, probably for this you'd want to do it like when you

put up a PR. But there are some plugins I think sponsored by the Google team for get have Action where you can automate this stuff, and I highly recommend doing that.

doesn't increase or doesn't increase too much. And we also check the Lighthouse score and potentially other metrics and see if there's a regression in the score. And if there's a regression in the score, then the build is broken and it needs to get fixed before you can actually deploy. And so yeah, and it's a totally automated process.

And the other thing that I wanted to mention in this context is it's it's a good idea if you have enough traffic, if you're big enough to also look

at actual field data. Now Google is is the CrOx is a good place to start, built into your search console, and you can get it in the paid speed Insights and it's free and you can even look at how well you're doing compared to your competitors, but if you want to try to improve your current situation, then that twenty eight day cycle might be just too long, and then you might want to integrate some sort of a third party solution. I think you mentioned that we might

have people from ray Gun in an upcoming episode. I think there are also other tools out there. Speed curve comes to mind. They're very neuralic, I think have something.

So there are plenty of tools out there that obviously they're not free, but that you can incorporate into your or at least maybe there are also free solutions out there, but you can incorporate them into your website and start getting collecting real time data including cod vitals, and then you can do all sorts of sophisticated segmentations perhaps and get much faster feedback and also be able to do stuff like ap tests in the field and see how that impacts your CO or vital score. Yeah.

use classes to get the effect. You just include the thing on your page and your page looks better instantly, without learning anything, without having to know about grids, without

you know, it's just classless CSS. So there's a repository where there's a bunch of them mentioned, and then I'm going to link to that, and I will try to link to there's a couple ones specifically that I like because a lot of the ones that are pository is just it's just literally thirty different classless CSS styles and most of them suck, but there's two or three of them that are just on point. I am also going

to pick one Finance. I used to use Simple, and as all Simple users know, it's now gone and because it was acquired by a company that got by acquired by a company that got well that that then was later acquired by a company, and so they are they are gone, and I've switched over to one Finance. And the key difference about it is that it allows you to have basically as many accounts as you want without any overdraft fees or anything, or monthly fees or any

of that. It's to help you organize stuff so you can have, you know, the cable company, you can instead of giving them your main bank account, you can create an account that you give only to the cable company, and when something gets screwed up like it just makes it easier to budget and makes it easier to not

have to worry about giving away an account number. That I mean, anybody that's had a bank long enough bites you in the butt when you give away your account number, because eventually somebody starts doing something shady, like your internet or phone company starts giving you extra charges or anyway. So it's just it's cool. And I'm including a link that's one of those refer friend links, so I think it's I get fifty bucks, you get fifty bucks kind

of thing. So if that sounds useful to you, definitely check it out.

such and such. It actually goes over a couple people that are innocent as well, but just I love those psychology things. And then after that, just I'm still doing my Beyond Code thing. I'm not the course is not developed yet, but I've been doing a lot of live streams and little videos. There's an off library that I've

been working on. It's basically forty hours plus of live streaming now, so if you want to watch me code, you can, and I am going to get back to the little short videos of teaching programming concepts as well. I just kind of been overburdened with other things that I need to do anyway, So that's all my picks.

specifically was thinking. Oh that you can set up these budgets and just like you would, a test basically fail to build if when it runs that test on your branch or you know, that's assuming that you have your PR set up where there's some sort of like working URL that you can go to when you put up a PR. But getting into the weeds, but yeah, you can set up a budget to run your tests and fail to build if your branch drops below the budget

that you specified. So I'll drop the lake to both sloms and that's it for me.

well you can. Now you can do it based on the data in their CRUC database. So obviously their CRUC database doesn't contain every website if it contains something like the top ten million website according to the traffic that the chrome sees, but it's still fairly interesting. You can do all these all sorts of comparisons between different technologies and different products and different CMSs for example, and and stuff like that. So I'm posting the link here. It's

a it's an interesting tool. So that's one thing that I wanted to post. The other another thing that I wanted to post. I recently watched this excellent video called Math has a Fatal Flaw and it's it's amazing. He talks about go to the self referential paradox in in set theory and about the completion problem, and it's all of This entire video is like half an hour, and the amount of information that it covers in such an

understandable fashion an accessible way is astounding. Somebody on there literally said, I'm a professor in the university and this is like an entire course, this half an hour of video. So it's an amazing video and I highly recommend it. So I'm going to put a postal into that here as well. And the last thing is something that I'm actually kind of asking for help. As it were, I'm running out of stuff to watch. I'm unable to find good stuff on TV anymore, like then the Netflix and stuff.

I don't know, that's just the quality is not it's not there. So we watched Mayor of Eastern or East Town, which was really good with Kate Winslet, and I recommend it. But now that it's done. I don't know what to watch. So if anybody has a suggestion, you know, hit me up on Twitter or something and let me know what you recommend for for us to.

So I'm gonna pick that and then go check out dev Influencers podcast, Definite Influencers dot com, slash podcast, and yeah, that's what I got. So we'll go ahead and wrap up here. Thanks Dan, this was really interesting my pleasure.