Speaker 1: Hey everybody, and welcome back to another episode of JavaScript Jabber.
Speaker 1: This week, on our panel, we have a j O'Neill.
Speaker 2: Yo, yeah yo, coming at you live from Pleasant, Pleasant Grove.
Speaker 1: Amy Knight he hey from Nashville. Dan Shapier Hi from
Speaker 1: Tel Aviv. I'm Charles max Wood from dev chat dot TV.
Speaker 1: And Dan, you were kind of filling us in a
Speaker 1: little bit before the show talking about core web vitals.
Speaker 3: Is that what that's called? Yeah, that's that's what I
Speaker 3: thought that it'll be interesting to speak about. It's not
Speaker 3: like we haven't exactly spoken about it before. I actually
Speaker 3: was a guest on a previous show that was all
Speaker 3: about the alphabet soup of performance metrics. I called the
Speaker 3: ad different acronyms, And later on we had Rick Viscomi
Speaker 3: from Google talking about how they collect this information, and
Speaker 3: then we had Martin Split from Google talking about how
Speaker 3: they use this information at least to an extent. But
Speaker 3: I still think that there's a lot to discuss here
Speaker 3: and to take apart, and especially given that I'm going
Speaker 3: to take this kind of an opinionated view of this
Speaker 3: whole thing, very non corporate. So everything that I'm saying
Speaker 3: is my own opinions and nothing to do with my
Speaker 3: employers or anything like that. Hopefully I won't get into
Speaker 3: any trouble.
Speaker 1: Yeah. So yeah, what what are core web vitals? I
Speaker 1: think that's a good place to start.
Speaker 3: Well, that's yeah, that's a good place to start. So
Speaker 3: it turns out that Google thinks that the web should
Speaker 3: be faster. That that is that when people visit websites,
Speaker 3: the websites should should load faster, should respond faster, and
Speaker 3: overall provide a better experience to those visitors. I like
Speaker 3: to say that, you know, we're kind of lucky that
Speaker 3: the good of the web, not always, but in many
Speaker 3: cases kind of aligns with the Google's bots online. They
Speaker 3: make most of of their money, most of their revenue
Speaker 3: from ads. I think Google is like the biggest ad
Speaker 3: company in the world or something like that. Maybe Facebook
Speaker 3: might be giving them a run for that position, but
Speaker 3: other than that, I think they're the biggest by far.
Speaker 3: And most of that, not all of it, but most
Speaker 3: of it I think is coming from ads on websites.
Speaker 3: So Google has this incentive that more people browse the web,
Speaker 3: because then more people will be exposed to their ads,
Speaker 3: and Google makes more money, and that means that they
Speaker 3: want a better web, a web that people spend more
Speaker 3: time on, and for me, as a proponent of the
Speaker 3: open web, that's really a good thing. So I'm really
Speaker 3: happy that this alignment has happened. And whatever their motivation,
Speaker 3: as long as is they're doing good things, well, I'm
Speaker 3: happy about it. And when Google tries to push the
Speaker 3: industry in what they consider to be the right direction,
Speaker 3: they have like these two whips that they can use
Speaker 3: to prod us along, to get us going. And one
Speaker 3: huge whip is the Google Search. All of us want
Speaker 3: our websites to rank, because if you don't rank, then
Speaker 3: you don't exist. And if they make something a ranking
Speaker 3: factor or ranking signal then and then go public about
Speaker 3: it telling everybody that that's the case, well, people have
Speaker 3: this huge incentive to invest in that aspect of their website.
Speaker 3: And that's one thing that they can do and they
Speaker 3: have done in the past. And the other thing that
Speaker 3: the other whip that they hold is the Chrome web browser,
Speaker 3: which I think is the most popular web browser at
Speaker 3: least that's what I see when I look at the
Speaker 3: WIG statistics about the browsers that our visitors are mostly using.
Speaker 3: And that's also whip because they can adjust the Chrome
Speaker 3: UI to encourage certain things in websites. And I'll give
Speaker 3: an example. A few years ago, Google decided that the
Speaker 3: web needs to be h GDPs everywhere, that if we
Speaker 3: want the web to be good, it needs to respect privacy,
Speaker 3: it needs to respect security, and for that it needs
Speaker 3: to be a GTPs. Now, you know, I still remember
Speaker 3: not so long ago, if you would go to some
Speaker 3: online store or whatever, and it would be just h GDP,
Speaker 3: and it wouldn't turn to HDPS until you were actually
Speaker 3: at the checkout. And then let's say it might redirect
Speaker 3: to PayPal or something like that, and only then would
Speaker 3: it actually become AGTPS. But all the rest of the thing,
Speaker 3: the entire process was over at GDP, which from my
Speaker 3: perspective is also problematic because I don't want people to
Speaker 3: know what I'm shopping for. And Google rightfully, you know,
Speaker 3: concluded that that's a bad thing and that everybody should
Speaker 3: be AHGTPS all the time. I hope everybody agrees with
Speaker 3: me here. And what they did is they exactly use
Speaker 3: these two whips that they had so in the in
Speaker 3: the search, they basically told people that h GTPs is
Speaker 3: going to be a ranking factor that all other things
Speaker 3: being equal, if there are like two sites that have
Speaker 3: equivalent that content and authority, one is a GTPs and
Speaker 3: the other is h GDP, the one that uses HDPS
Speaker 3: will rank over the one that just uses HTP. Now,
Speaker 3: to be fair, it doesn't even need to be true.
Speaker 3: It's just sufficient that they say that that's what they're
Speaker 3: going to do, and that really gets a lot of
Speaker 3: people going. And the other thing that they did is
Speaker 3: that they modified the chrome UI initially to put this
Speaker 3: kind of a greenish background behind htps r LS and
Speaker 3: then put a reddish background behind h GDP or LS. I
Speaker 3: think that now there are that's done. They have this
Speaker 3: lock icon. I don't think they put the colors anymore.
Speaker 3: But they got it into people's heads that h GDP
Speaker 3: was dangerous, that it's not a good thing, and then
Speaker 3: that you should prefer h GDPs, and they use chrome
Speaker 3: for that purpose. So by using these two things, these
Speaker 3: two whips, like I said, or prags, they got us
Speaker 3: all moving in the right direction. And now they are
Speaker 3: effectively doing or trying to do the exact same thing
Speaker 3: with regard to performance. And that's where core web vitals
Speaker 3: come into the picture.
Speaker 1: Now, yeah, that makes sense. It's funny too, because I
Speaker 1: remember when they made some of those changes, people were
Speaker 1: especially your HTTPS example, a lot of folks were frustrated
Speaker 1: because they were just content sites and things like that
Speaker 1: and they didn't want to have to go to HTTPS.
Speaker 1: But yeah, I agree with you that that makes sense.
Speaker 1: It's interesting that Google has put themselves in a position
Speaker 1: to sort of push some of these ideas or push
Speaker 1: some of these technological choices right where I think a
Speaker 1: lot of other companies would have just let things coast, right.
Speaker 1: It would have been like, well, whatever people want to do, right,
Speaker 1: and so it would have been up to the public
Speaker 1: instead of up to folks like Google to push some
Speaker 1: of this stuff.
Speaker 2: I don't want to get a soft track, so just
Speaker 2: don't answer if it does. But what is the incentive
Speaker 2: for Google wanting people to have HTTPS? I get why
Speaker 2: it's good for me, but I don't get why it's
Speaker 2: good for them. Well, AD revenue, ad revenue, they not
Speaker 2: getting those malicious ad jacker things.
Speaker 3: Maybe is that it's a sad look. I haven't tried
Speaker 3: to do a deeper specific analysis of that, but I
Speaker 3: tend to agree. But like I said at the beginning,
Speaker 3: Google wants the web to be a pleasant and and
Speaker 3: a safe place that people want to use. Like you
Speaker 3: wouldn't go to buy at the store that where there
Speaker 3: are a lot of pickpockets hanging around and maybe stealing
Speaker 3: your stuff or whatever. You want to go somewhere where
Speaker 3: you feel safe while doing the shopping, and they wanted
Speaker 3: to be the experience when you're online. So that would
Speaker 3: be my guess. But like I said, I think that
Speaker 3: we're kind of lucky in that the overall the good
Speaker 3: of the web in most cases, not all cases, and
Speaker 3: we shouldn't always count on it to be true, but
Speaker 3: in a lot of cases, the good of the web
Speaker 3: and the good of financial benefit of Google currently align,
Speaker 3: which is lucky for us. Is don't aligned that much
Speaker 3: with Apple, for example, which is not really unfortunate for us.
Speaker 1: So I guess the point, you know, coming back to
Speaker 1: the web vitals and performance is again they want it
Speaker 1: to be a good experience where people are happy to
Speaker 1: come to the web, and so they're encouraging people now
Speaker 1: on performance in the same way they did for HTTPS,
Speaker 1: in the sense that yeah, it's good for the web,
Speaker 1: it's good for the consumers of the web, and so
Speaker 1: Google is going to push it forward because more people
Speaker 1: on the web is good for them.
Speaker 3: Yes, at least that's how I see it. And again
Speaker 3: this is my opinion. Like I said, is going to
Speaker 3: be an opinionated episode, and that's my understanding of the situation.
Speaker 3: But it also raises the problem that they were facing
Speaker 3: because with HGDPS, it's really clear cut either the site
Speaker 3: uses HGTPS or or it doesn't, and it's very easy
Speaker 3: for them to see that that's the case. In the
Speaker 3: case of performance, how do you actually determine if a
Speaker 3: website has good performance or not? And what does good
Speaker 3: performance actually constitute, how do you measure it, and what
Speaker 3: do you actually measure What might be good performance for
Speaker 3: one type of a website might be bad for a
Speaker 3: different type of website. Or it's also dependent on geographic
Speaker 3: locations because the web, let's say, in Canada, is much
Speaker 3: faster than the web, let's say, in India. So it
Speaker 3: gets much more complicated when when you look at that
Speaker 3: factor of performance, and that that's kind of the reason
Speaker 3: that we had that big episode a while back on
Speaker 3: where are literally listed for an entire hour and in
Speaker 3: a bit of that entire recording, a whole bunch of
Speaker 3: performance metrics, because there are a lot of different measurements
Speaker 3: that you can take in when you're trying to gauge
Speaker 3: the performance of a particular website, so it really becomes
Speaker 3: tricky and in order to kind of address so oh,
Speaker 3: let me put it differently. When Google decided that they're
Speaker 3: going to be focusing on performance, they concluded, and again
Speaker 3: rightfully so in my opinion, that it has to be
Speaker 3: metrics that are valid that actually indicate something real about
Speaker 3: the performance of a website, but it also can't be
Speaker 3: something It can't they can't have too many metrics. So
Speaker 3: you know, there are a lot of aspects of web
Speaker 3: performance that you can measure, but they're not going to
Speaker 3: focus on everything all at once. Instead, they're going to
Speaker 3: focus on a particular subset of things what they would
Speaker 3: consider to be the most important things. Because the vast
Speaker 3: majority of web developers and designers and SEO people, et
Speaker 3: cetera that are out there are not performance experts, don't
Speaker 3: want to be, and shouldn't be, And if you came
Speaker 3: at them with something like twenty different metrics that they
Speaker 3: need to now analyze and measure and analyze and optimize,
Speaker 3: it's just not going to happen. So what Google did
Speaker 3: essentially is like they did this two step process. First
Speaker 3: of all, they came up with something that which they
Speaker 3: called web vitals, which were a larger set of performance metrics.
Speaker 3: And then out of these they distilled three metrics which
Speaker 3: they refer to as core web vitals, which are the
Speaker 3: ones that they're going to focus on or now are
Speaker 3: at present. And what they also said is that every
Speaker 3: year they're going to look at these three core web
Speaker 3: vitals see if they're still the ones that you need
Speaker 3: to focus on and potentially modify them, evaluate them, maybe
Speaker 3: even replace them with other metrics if they see a need.
Speaker 3: So so far, they've announced the set of three metrics
Speaker 3: back in twenty in the beginning of twenty twenty, I think,
Speaker 3: and so far they haven't changed them, so for now
Speaker 3: at least, they're sticking with it. And these three core
Speaker 3: web vital metrics are LCP or largest Content for paint,
Speaker 3: FID which stands for first input delay, and CLS which
Speaker 3: stands for commulative layout shift. And these are the ones
Speaker 3: that they're focusing on, and these are the ones that
Speaker 3: they're now starting to use as a ranking signal into
Speaker 3: Google Search. Which means that the the values that get
Speaker 3: measured for your website for these metrics can impact the
Speaker 3: ranking of your site, at least in mobile searches.
Speaker 1: So you kind of made this point before, Dan, and
Speaker 1: I'm a little curious to see how this goes. But
Speaker 1: you basically said, not all Internet connections are created equal,
Speaker 1: and not all devices are created equal either, And so
Speaker 1: I'm wondering exactly how do you measure these numbers? Right,
Speaker 1: because it looks like it's I pulled up one website
Speaker 1: where they kind of explained what these three measures are
Speaker 1: and it's, hey, ask to be two point five seconds
Speaker 1: or four seconds or you know, one hundred milliseconds, three
Speaker 1: hundred milliseconds kind of thing. They've got these benchmarks. So
Speaker 1: is it just when the bot hits it?
Speaker 3: Or that's an excellent question. A lot of people initially
Speaker 3: assume that it's going to be the Google bot or
Speaker 3: something that Google is going to hit your website measure
Speaker 3: how long it takes for the bot to do whatever,
Speaker 3: and those are the numbers that they're going to use,
Speaker 3: and that's totally not the case. People were also looking
Speaker 3: at measurement tools that Google put out there, like a
Speaker 3: Google Lighthouse and Google based with Insights and thought, hey,
Speaker 3: they're probably going to be using Lighthouse to measure your
Speaker 3: website and use that number. Well, again, that's totally not
Speaker 3: the case. So I mentioned we had Rick VISCOMI on
Speaker 3: a previous episode, and Rick is the person at Google
Speaker 3: who manages a project called CRUX, which stands for Chrome
Speaker 3: User Experience and this and there is a reminder of
Speaker 3: what this thing is. It turns out that when you
Speaker 3: install Chrome on your device, or if it comes pre
Speaker 3: installed unless you opt out, then Chrome gathers data about
Speaker 3: all the websurfing that you're doing. To do people still
Speaker 3: use the term websurfing. I don't know all the websites
Speaker 3: if you visit all your web sessions, Google collects information
Speaker 3: about that anonymous of course, and it gets sent up
Speaker 3: to the mothership. So it gets collected in this huge
Speaker 3: Google database, and that includes performance information. So they measure
Speaker 3: your Chrome measures the time that it takes for your
Speaker 3: website to load effectively, and that measurement or those measurements
Speaker 3: actually because it's more than one number, gets sent back
Speaker 3: to Google and gets put into this database called CRUX. Now,
Speaker 3: Google then uses this information as the input as an
Speaker 3: input more accurately to their Google ranking algorithm. So the
Speaker 3: Google ranking algorithm receives a ton of signals from a
Speaker 3: lot of different sources, and the various analysis that they
Speaker 3: perform on a website they like look at things like
Speaker 3: the quality of the content, the BACKLNK, the authority, et cetera. Well,
Speaker 3: now they have another ranking signal which incorporates the performance
Speaker 3: data that they get from this Crux database, which means
Speaker 3: ultimately that the number that they use or the numbers
Speaker 3: that they use in order to determine whether your website
Speaker 3: has good performance or not is based on actually the
Speaker 3: actual experience of real users who are using Google Chrome
Speaker 3: as their browser. Unfortunately, they're not looking at people who
Speaker 3: are using other browsers, so Safari users, for example, have
Speaker 3: zero impact on this ranking signal. Likewise, Firefox users or
Speaker 3: even Edge users, even though Edge is using the same
Speaker 3: chromium engine as Chrome, because it's a Chrome thing, it's
Speaker 3: not a Chromium thing.
Speaker 2: You forgot Brave.
Speaker 3: Brave certainly does not send data to the Google servers.
Speaker 3: I think Brad and I would like become apoplectic if
Speaker 3: it happened. I know right now, I think they're introducing
Speaker 3: their own search engine even so.
Speaker 2: And it works remarkably well. Actually, like I have not
Speaker 2: even I think that the Brave search is getting me
Speaker 2: really good results for the type of searches that I do,
Speaker 2: which I'm surprised by.
Speaker 3: I think that is it something that they developed or
Speaker 3: I think they bought some company or merged with some company.
Speaker 3: I think. I'm not sure. Anyway, it's kind of off topic.
Speaker 3: I don't know. Yeah, probably we should probably bring somebody
Speaker 3: from Brave just to talk about that. It does sound
Speaker 3: like an interesting topic. But anyway, I digress. So, as
Speaker 3: I mentioned, there are these three main metrics which are
Speaker 3: the core web vitals. The first one I mentioned is LCP,
Speaker 3: which is largest content for paint. It measures the time
Speaker 3: from the start of the session until when that the
Speaker 3: biggest content element within the initial viewport was rendered. Usually
Speaker 3: that would be an image, but it might also be text. Interestingly,
Speaker 3: svgs don't count, so what why? My guess is that
Speaker 3: svgs would be too easy to fake. Here's the thing
Speaker 3: about co web vitals that Google needs to take into account.
Speaker 3: On the one hand, there are supposed to be these
Speaker 3: metrics that putting Google aside, there are supposed to be
Speaker 3: these metrics that if you optimize, if you improve, you
Speaker 3: will get a better website. I mean, getting good performance
Speaker 3: is not just about the rank. Like I said, the
Speaker 3: rank is kind of the whip. Getting good performance is
Speaker 3: also about the user experience. If you have good performance,
Speaker 3: you'll have better engagements, you'll have a lower bounce rate.
Speaker 3: Those are the things that should really be of interest
Speaker 3: to a site owner if people If you have an
Speaker 3: online store, even if people find it but then it
Speaker 3: loads so slowly that they just leave without buying everything,
Speaker 3: that what have you gained? You want people to engage
Speaker 3: with your content, and that, amongst other things, requires good performance.
Speaker 3: So in an ideal world, the co web vitals what
Speaker 3: you would just think about, the youth, the visitor experience.
Speaker 3: But once Google may has made them a ranking signal,
Speaker 3: they also need to take into account that people will
Speaker 3: do bad things in order to improve their rank. It's
Speaker 3: it's unfortunate, but it's well known that it happens. So
Speaker 3: think about me like putting this I don't know, an
Speaker 3: SBG box around my entire viewport just to create this
Speaker 3: big visual element, because it's as big as the entire viewport,
Speaker 3: but it's effectively empty. It's like this one line SVG
Speaker 3: and it's embedded into the HTML, so it will be
Speaker 3: like the first thing to render, and I would get
Speaker 3: a really great LCP score even though I've literally done
Speaker 3: nothing to actually improve the actual user experience. Now I'm
Speaker 3: not saying that this is the reason why Google has
Speaker 3: done it, but that's my guess. Or let's put it
Speaker 3: this way. They have another metric that's a web vital,
Speaker 3: but not a core web vital, which is first content
Speaker 3: for paint, which measures when the first element of content
Speaker 3: is rendered on the page, and that one does take
Speaker 3: SVG into account. So it's interesting that for the first
Speaker 3: contentful paint they do take svgs into account, but for
Speaker 3: the largest content for paint they actually don't take svgs
Speaker 3: into account. Okay, it is what it is. So an
Speaker 3: LCP would be either the biggest image or the biggest
Speaker 3: piece of text, whichever is the bigger one between them.
Speaker 3: In the case of text, it's the rounding is the
Speaker 3: box that contains the text, So it would be let's say,
Speaker 3: if the text, let's say is inside of div, it
Speaker 3: would be the rectangle of that div, the closing rectangle
Speaker 3: of that div.
Speaker 1: All right, So when you say largest, you're saying by
Speaker 1: real estate on my page.
Speaker 3: Yes, although in the case of images, they also like
Speaker 3: factor in the image quality. So if you've got a
Speaker 3: low res image that you then stretch to cover a
Speaker 3: large area, they will kind of factor it down to
Speaker 3: account for the fact that it's low res. Right. Interesting anyway,
Speaker 3: they're also playing with these metrics. They're trying to make
Speaker 3: them more useful. Some people are kind of annoyed by
Speaker 3: it because people are working hard on optimizing these metrics,
Speaker 3: and then Google comes along and modifies how they actually
Speaker 3: measure one of the metrics that can be annoying or confusing. So,
Speaker 3: for example, in Chrome eighty eight, they modified the LCP
Speaker 3: metric to ignore full full viewpoint images, so if an
Speaker 3: image covered the entire viewport, they would actually ignore it.
Speaker 3: And the motivation was that such an image is probably
Speaker 3: a background image and consequently it's not like the main
Speaker 3: content of the page, and therefore they decided to ignore it.
Speaker 3: By the way, the whole reason for picking largest contentful
Speaker 3: paint is that they kind of ran tests. They sat people,
Speaker 3: at least that's what they told me. They sat people
Speaker 3: in front of computers, had them load website and like
Speaker 3: click a button when they thought the PA the site
Speaker 3: load was loaded and finished loaded, And what they found
Speaker 3: is that in most cases, the time, the point in
Speaker 3: time where the people clicked the button correlated to when
Speaker 3: the largest piece of content was rendered in the browser window.
Speaker 3: So that's where this metric came from. Now, a big
Speaker 3: problem with LCP, though, is that you never know unless
Speaker 3: the content covers the entire viewport, in which case, like
Speaker 3: I said, for images, it's actually ignored. You never know
Speaker 3: if a bigger piece of content is not going to
Speaker 3: occur like a little bit later. So think about it.
Speaker 3: Let's say the page is loading, it draws something, it's
Speaker 3: that's the largest contentful paint until this point in time,
Speaker 3: but then something bigger might be drawn a second later,
Speaker 3: which which it then becomes the largest contentful paine. So
Speaker 3: the question is kind of when do you stop? And
Speaker 3: and that's one of the problematic measure things about this measurement.
Speaker 3: So they stop when the user interacts with the page.
Speaker 3: So if the user scrolls or clicks, they say, okay,
Speaker 3: if the user does something with the page, it means
Speaker 3: that from the users with the visitor's perspective, the page
Speaker 3: is not so you know, no, no point in waiting
Speaker 3: for more stuff. But that's kind of one of the
Speaker 3: problems with with LCP, and and that's one of the
Speaker 3: reasons why when it's measured in lap conditions, like by
Speaker 3: a tool like Lighthouse, you might get really different results
Speaker 3: and what you might get in the field because it
Speaker 3: might be stopping at a different point, And that's a
Speaker 3: problem with it. There are other issues with it as well,
Speaker 3: but those are like the main ones.
Speaker 1: I guess My question here is is, let's say that
Speaker 1: I have a content website I don't know that has
Speaker 1: podcasts on it maybe, and I care about my Google ranking,
Speaker 1: and so I want to improve this. How do I
Speaker 1: know what the large what the thing is that they're measuring, right,
Speaker 1: Because I mean ideally, what I'd like to do is
Speaker 1: I'd like to say, oh, they're measuring when I load
Speaker 1: this image or you know this, well whatever, right when
Speaker 1: I load in this piece, and so do I optim
Speaker 1: I'd like to be able to optimize that and then
Speaker 1: maybe something else take takes that on or I don't know,
Speaker 1: I'd like to know which piece to optimize. Is there
Speaker 1: a good way to know that?
Speaker 3: Yeah, So there are actually two ways to go about it.
Speaker 3: So one way is the lab way or the synthetic way.
Speaker 3: So you're working on your website or a new version
Speaker 3: of your website. You still don't have actual visitors or
Speaker 3: people coming to this new version, but you want to
Speaker 3: compare it to the older version to see or to
Speaker 3: the current version to see whether you're improving or regressing
Speaker 3: or whatever. So you can use a lab tool like
Speaker 3: Google Paid speed Insight. You put in the URL for
Speaker 3: the existing site, you put in the r L for
Speaker 3: the new site, and it essentially just simulates a session
Speaker 3: in a certain configuration. For example, Paid speed Insight actually
Speaker 3: simulates the mobile device, the Moto G four on a
Speaker 3: three G network, and then it runs a test for
Speaker 3: a couple of seconds, loads the site, sees what's the
Speaker 3: largest piece of content within the initial viewport and basically
Speaker 3: measures how long until that got rendered, and you can
Speaker 3: compare the value that it gets for the existing site
Speaker 3: with the value that you're getting for the new version
Speaker 3: that you're currently building. And not only that, it will
Speaker 3: actually show you which of the elements on the page
Speaker 3: is that is the one that it picked as the
Speaker 3: largest content for paint so it might be an image,
Speaker 3: and then you can go and check and say Hey,
Speaker 3: I'm actually loading this huge PNG. If I use converted
Speaker 3: to a JPEG instead, it would be tenths It would
Speaker 3: be a tenth of the size and it will download
Speaker 3: so much faster. Or maybe I can even use one
Speaker 3: of the newer formats like web or aviif and make
Speaker 3: it even smaller than that. Or maybe I'll change the
Speaker 3: design of my page a little bit on mobiles so
Speaker 3: that instead of an image being my largest content and
Speaker 3: for paint, I'll make my headline text be slightly bigger,
Speaker 3: and then it will be my largest content for paint.
Speaker 3: And maybe instead of a web font, I'll use one
Speaker 3: of the quote unquote system fonts like Aril or even
Speaker 3: times in Roment or whatever, so it doesn't even need
Speaker 3: to download the font, and then I would get really
Speaker 3: really good RCP value because it's just text. So yeah,
Speaker 3: so one way to go about it is a lab
Speaker 3: tool or synthetic tool like paid speed in sits like Lighthouse.
Speaker 3: The other way that you can go about it is
Speaker 3: that you can actually look if your site gets sufficient traffic,
Speaker 3: you can actually get data from that same Crux database
Speaker 3: that Google uses for ranking. So and Rick actually touched
Speaker 3: on that. So it's interesting. First of all, they don't
Speaker 3: put every website into the Crux database. You need to
Speaker 3: get a certain amount of traffic before they even conder
Speaker 3: put you in that database. So, just so you know,
Speaker 3: if you create a new website that doesn't yet have
Speaker 3: any traffic, you're not going to get this boost for performance,
Speaker 3: even if your website is really fast, until you get
Speaker 3: sufficient traffic to actually get into that database. And sufficient
Speaker 3: traffic I think is like a couple of one hundred
Speaker 3: visitors or thousands of visitors a day or something like that.
Speaker 3: So you do need to get a certain amount, minimal
Speaker 3: amount of traffic before you they even consider you. So
Speaker 3: you won't get penalized, but you won't get the boost
Speaker 3: for that, not because you're not fast enough, but because
Speaker 3: you just don't have you don't yet have enough traffic
Speaker 3: to even be in that database. But suppose you are
Speaker 3: in that database, well, there are two ways for you
Speaker 3: to look at the values that Google is calculating for you.
Speaker 3: One way is using Google pay Speed Insights. In the
Speaker 3: middle of the page, they have a section called field data,
Speaker 3: and they will actually show you the values that you
Speaker 3: got over the past twenty eight days. So the sort
Speaker 3: of an aggregate value, and what they're looking at is
Speaker 3: the seventy fifth percent time. So for example, for LCP,
Speaker 3: a good value is hundred two and a half seconds
Speaker 3: or less. So they look at the seventy fifth percent time,
Speaker 3: that is the value that is slower than seventy five
Speaker 3: percent of your users and faster than your slowest twenty
Speaker 3: five percent of users, and see if that falls in
Speaker 3: the good range, which is two point five seconds or less,
Speaker 3: or in the quote unquote needs improvement range, which is
Speaker 3: between four seconds and two and a half seconds, or
Speaker 3: in the poor range, which is slower than four seconds.
Speaker 3: If it falls within that poor range, you won't get
Speaker 3: a boost for that metric. If you fall within the
Speaker 3: needs improvement range, you will get a certain boost that's
Speaker 3: relative to how good you are. So it's like a
Speaker 3: it's a linear growth sort of a thing. They're not
Speaker 3: giving the exact formula, but let's assume that it's some
Speaker 3: sort of a linear growth. So the closer you are
Speaker 3: to the good section, the more boost you will get,
Speaker 3: and once you get to the good section, it plateaus.
Speaker 3: So once you get to that two point five seconds,
Speaker 3: that's you get the maximum boost, and if you manage
Speaker 3: to improve it from two point five to one point five,
Speaker 3: you won't get any higher boost for your ranking. You
Speaker 3: might get happier users on your page, but in terms
Speaker 3: of the ranking, that's the maximum boost that you will
Speaker 3: get for that particular metric, So that that's LCP.
Speaker 1: So I guess I have another question related to this,
Speaker 1: and that is, for a long time, I've kind of
Speaker 1: focused my concerns over performance into say the back end, right,
Speaker 1: and so however long it takes to render HTML blah
Speaker 1: blah blah. And this comes primarily because my background's mostly
Speaker 1: we're beyond rails, right, and so it's all almost all
Speaker 1: server rendered.
Speaker 3: Right.
Speaker 1: But now I'm thinking, okay, well, what if I put
Speaker 1: in say a stimulus JS or a react or an
Speaker 1: Angular or something, right, how does that affect this? Right?
Speaker 1: Does it kind of add up the time it takes
Speaker 1: including loading in whatever components I've put into my website
Speaker 1: so that this thing shows up or doesn't, and including
Speaker 1: all the CSS, And does it also include the time
Speaker 1: it takes to go back to the server and say okay,
Speaker 1: now I need this spreadsheet, now I need this JavaScript
Speaker 1: and stuff like that, or is it just the paint time?
Speaker 3: So the answer to that is yes. But before I
Speaker 3: go there, I just wanted to finish one point. So
Speaker 3: I mentioned that you can get the field data through
Speaker 3: Google Page with Insights. I just want to mention that
Speaker 3: there's another source that's really useful for getting the field data,
Speaker 3: and that's the Chrome Search console. So most people who
Speaker 3: run who have a website for professional reasons usually use
Speaker 3: the search console to make sure that Google properly sees
Speaker 3: their website. And you now have a co web vitals
Speaker 3: section or panel or tab call it whatever within your
Speaker 3: search console, and they will actually show you the current
Speaker 3: situation broken down by pages. So they will say pages
Speaker 3: of this type have let's say poor LCP or they
Speaker 3: need improvement for CLS. And again, this data is coming
Speaker 3: in from the Crux database. I think it doesn't really matter.
Speaker 3: It's the end of the day, it's the same source
Speaker 3: of data. Is that data that they collect from actual
Speaker 3: Chrome sessions? They actually in this case, I think they
Speaker 3: actually do have like this daily moving average, but it's
Speaker 3: still averaged over a twenty eight day period. So even
Speaker 3: if you made a significant improvement, take into account that
Speaker 3: it will take some time for Google to actually notice it.
Speaker 3: But now going back to your question, and the answer
Speaker 3: is that yes, you know, modern web pages are complicated beasts.
Speaker 3: That's one of the reasons for this podcast, I think.
Speaker 3: And there are a lot of moving parts. There's the
Speaker 3: back end, there's the network, whether or not you use CPNS.
Speaker 3: That's the media that you're downloading to the browser for
Speaker 3: its format. Are you downloading it via CDN or you know,
Speaker 3: using something like a cloud flare or something like that.
Speaker 3: How much JavaScript are you running on your browser? All
Speaker 3: these things impact performance and sense co ed vitals try
Speaker 3: to measure performance. All these things impact co ed vitals.
Speaker 3: The bottom line in terms of LCP is that you
Speaker 3: want to get your primary content down, you know, in
Speaker 3: front of the visitor as quickly as possible. So, for example,
Speaker 3: if it's an image, you it's better if the HTML
Speaker 3: that is downloaded from the server already has that image
Speaker 3: SRC inside of it, rather than you first having to
Speaker 3: download let's say React and run React on the client side.
Speaker 3: Because all you're actually serving is just blank HTML, you
Speaker 3: know what the emptydive, and you're totally constructing your entire
Speaker 3: user experience on the client side, you're probably going to
Speaker 3: get poorer performance. And that's that's just a reflection of
Speaker 3: reality because your visitors are gett a poor performance. You know,
Speaker 3: it might be easier for you to build your website
Speaker 3: this way, but the end of the day, I think
Speaker 3: what matters most should be the experience of our visitors
Speaker 3: and customers and whatnot. So, yes, you do need to
Speaker 3: take into account your server time. If you're serving a
Speaker 3: really dynamic, dynamic content, then you need to think about
Speaker 3: your database queries. Or maybe alternatively, you can use something
Speaker 3: like a static side generator, you know, like a gem
Speaker 3: stack sort of thing, and you're still doing all these
Speaker 3: database queries, but you're doing them at build time rather
Speaker 3: than in run time, and then the page just gets
Speaker 3: generated and pushed into a CDN and then it's delivered
Speaker 3: really really quickly. So yes, there are a lot of
Speaker 3: moving parts in modern websites and you need to think
Speaker 3: about them. What can I say? Yeah, So moving on
Speaker 3: to the second core web vital, which is FID or
Speaker 3: first input delay. That one measure the time from the
Speaker 3: first interaction that the visitor has with a web page.
Speaker 3: Let's say it could be a mouse click or button
Speaker 3: press whatever, until the browser can process that request, Which
Speaker 3: means that if there's let's say some client side JavaScript
Speaker 3: associated with with that mouse click, then until the browser
Speaker 3: can run that JavaScript, or if it's some sort of
Speaker 3: a default action, then until the browser can instigate that
Speaker 3: default action. So that's what gets measured by first input delay.
Speaker 3: And the things that can cause a lengthy first input
Speaker 3: delay are, for example, if you're running a whole bunch
Speaker 3: of JavaScript on inside the browser, and the browsers well,
Speaker 3: they're much there. They're not single as single threaded as
Speaker 3: they used to be, but they're still pretty single threaded.
Speaker 3: So if your main thread is busy because it's running
Speaker 3: a lot of JavaScript, and because of that, if the
Speaker 3: user clicks on something then nothing happens, then you'll get
Speaker 3: a poor ID And it only measures first the first one.
Speaker 3: That's the first input delay, I guess, because you don't
Speaker 3: get a second chance to make a first impression. And yeah,
Speaker 3: that's what it measures. And the thing here is is
Speaker 3: that it really annoys people when they try to interact
Speaker 3: with the user interface and that user interface does not
Speaker 3: respond to their interactions. The example that I like to
Speaker 3: give is when standing in front of an elevator and
Speaker 3: you press the button, you don't expect the door to
Speaker 3: open immediately, so you don't actually expect that operation that
Speaker 3: you requested to instantly finish. You're happy if it happens,
Speaker 3: but usually it doesn't happen. But you do expect the
Speaker 3: button to instantly turn on, and you do expect the
Speaker 3: numbers to start counting towards your floor. And if you
Speaker 3: click the button, then nothing happened. Where people do this
Speaker 3: sort of thing, it's called rage clicks. They start going
Speaker 3: to tap tap, tap, tap tap, and it's the same
Speaker 3: thing with web interface or app interface. You know, especially
Speaker 3: on mobile devices, people have become really used to this
Speaker 3: kind of an instantaneous response that when you tap something,
Speaker 3: it responds to your tap, and if it doesn't, well,
Speaker 3: it can drive you nuts. And that that is the
Speaker 3: thing that first input delay tries to measure now Here.
Speaker 2: Yeah, well, in the case of flat design and things
Speaker 2: really annoying about this, it's pretty much all visual cues
Speaker 2: are eliminated. When I say flat design, I mean most
Speaker 2: flat design, not the theoretical best flat design that could occur.
Speaker 2: But you know, they get rid of the shadows, they
Speaker 2: get rid of the colors. Yeah, super frustrating.
Speaker 3: Oh, I totally agree, And I'll give an example from
Speaker 3: a Wix tool. We have the Wix editor where you
Speaker 3: build your website and when you click the save button,
Speaker 3: and the save operation is a lengthy operation can't be
Speaker 3: made instantaneous. But like I said, people don't expect the
Speaker 3: elevator door to open immediately, so we do need to
Speaker 3: when we start the save operation, we do need to
Speaker 3: provide immediate feedback to the user that their save request
Speaker 3: is being processed. So it could be some sort of
Speaker 3: a spinner color something, And you're totally correct that if
Speaker 3: I build a user interface where the visual cues or
Speaker 3: the visual feedback is so minimal that many users might
Speaker 3: not even notice it, you're doing damage. It's frustrating. So
Speaker 3: that's totally true. So just to finish that point on FID,
Speaker 3: as with LCP, it's kind of this green yellow red
Speaker 3: like street light, where the green part the good part,
Speaker 3: is from zero to one hundred million seconds. So anything fast,
Speaker 3: if that's one hundred million seconds or faster, counts as good.
Speaker 3: If I d up to three hundred milliseconds counts as
Speaker 3: needs improvement, and anything above three hundred milliseconds count as poor.
Speaker 3: And that's based on a lot of user interface research
Speaker 3: that has been done over the years that shows that
Speaker 3: people consider anything better than one hundred milliseconds to be
Speaker 3: in effectively instantaneous.
Speaker 2: And I missed for that. You want it to be
Speaker 2: at least one hundred.
Speaker 3: Milliseconds at most, at mostred, No, at least No, you
Speaker 3: want it to be one hundred and threty seconds or less.
Speaker 2: No, But if that happens, no, nobody wants it to
Speaker 2: be less because then.
Speaker 1: When you click, when it responds, it needs to respond
Speaker 1: within one hundred milliseconds.
Speaker 2: Okay, So are we saying respond as in some much Okay, yes, yes, agreed, agreed, agreed,
Speaker 2: But like like, if a transition is less than one
Speaker 2: hundred milliseconds, it looks really jarring.
Speaker 3: Yeah, but the transition needs to start.
Speaker 2: Yes, agreed, agreed, Okay, okay, one hundred percent agreed.
Speaker 3: And they and again they do the same sort of
Speaker 3: a calculation on the ranking signal, So each one of
Speaker 3: these Cobb vitals is now calculated independently. Initially, when Google
Speaker 3: presented this model, there was the assumption that you're only
Speaker 3: going to get the boost if you're green that is good,
Speaker 3: and that you're only going to get the boost if
Speaker 3: you're good or green for all the three and recently
Speaker 3: they came out and said, no, each one of these
Speaker 3: metrics is going to be measured independently, and you're going
Speaker 3: to start getting a boost even in if you're in
Speaker 3: the needs improvement range. You're going to achieve the maximum
Speaker 3: boost once you reach that good range. And then, like
Speaker 3: I said, it plateaus. I guess the reason that they've
Speaker 3: said that that they haven't been clear that. So it's
Speaker 3: not like they said, we change our minds, because they
Speaker 3: were never really explicit about it before. But that's what
Speaker 3: most people understood. And I'm guessing that Google just looked
Speaker 3: at the results out there and said, hey, if we
Speaker 3: do it that way, then too many people won't get
Speaker 3: any boost and people would be just totally discouraged and
Speaker 3: not try to improve anything. So at least give them,
Speaker 3: then say, if they're like really bad on one of
Speaker 3: the metrics but might be good in the others, at
Speaker 3: least get give them an incentive to improve what they
Speaker 3: can improve, at least for now. So they're going to
Speaker 3: measure each one of these metrics independently.
Speaker 1: So I can imagine people here. We kind of talked
Speaker 1: about managing what that largest thing is on your page
Speaker 1: so that it's something that will load fast, and I
Speaker 1: can imagine something here where you create or kind of
Speaker 1: steer people towards something that you know you can get
Speaker 1: them to click on that will start to interact quickly.
Speaker 3: Right, Yeah, So there are good ways to improve the fight,
Speaker 3: and then there are I don't know less good ways
Speaker 3: to improve the fight. So let's say I'm.
Speaker 1: My loading spinner is going to come in so day fast.
Speaker 3: Yeah. So let's say that I'm building an online store,
Speaker 3: and obviously the thing that I want people to click
Speaker 3: on is the buy button, and I want the buy
Speaker 3: button to be really quickly respond because if people get
Speaker 3: frustrated while pressing that button, it's really bad experience for
Speaker 3: your store. So and let's say I do have poor FID.
Speaker 3: So the good way to fix it is to make
Speaker 3: my code better. Instead of downloading I don't know a
Speaker 3: meg of JavaScript in order to get my page up
Speaker 3: and running, maybe I can download one hundred k of
Speaker 3: JavaScript to get my page up and running. Maybe I
Speaker 3: can download my JavaScript in parts so that in order
Speaker 3: to get that button up and running, I only need
Speaker 3: twenty k of JavaScript to be downloaded, parsed, and run,
Speaker 3: and I can download the rest. Even when somebody actually
Speaker 3: needs it, and so on and so forth, So that
Speaker 3: would be the good way of improving my FID. So
Speaker 3: the nuts A good way would be to hide the
Speaker 3: button until I finished downloading all my JavaScript, and then
Speaker 3: there'll be nothing to press until I'm ready for you.
Speaker 3: I could do that, but and then people might just
Speaker 3: bounce off of the page. But if they do click,
Speaker 3: they will get a good FID value, so they're Like
Speaker 3: I said, there are good ways to improve things, and
Speaker 3: there are not so good ways to improve things. But
Speaker 3: the best way to improve FID is, like I said,
Speaker 3: by reducing the JavaScript payload that is needed to support
Speaker 3: the initial interactions and also to avoid let's say, really
Speaker 3: complicated CSS. Maybe that could really create a bottleneck in
Speaker 3: terms of the rendering of the page and stuff like that.
Speaker 3: But the only thing that I can say here is
Speaker 3: that in most cases that I've seen, unless people do
Speaker 3: really bad things, FID is usually pretty good. If I
Speaker 3: look at the other metrics, people are having a lot
Speaker 3: of problems with CLS, and people are having a lot
Speaker 3: of problems with LCP. Most websites that I've seen that
Speaker 3: actually make it into the Crux database usually have pretty
Speaker 3: good fight unless you're doing really bad stuff with JavaScript.
Speaker 3: Like I said, downloading a full mag of JavaScript jezip
Speaker 3: just to get things, just to get the ball rolling,
Speaker 3: then then you've got a problem. But if that's not
Speaker 3: the case, then you should be okay for FID, which
Speaker 3: brings us to the last metric, which is CLS. And
Speaker 3: this is an interesting one that one actually tries to
Speaker 3: measure what is called visual stability. I'm sure you've all
Speaker 3: encountered this situation where you've been reading some sort let's
Speaker 3: say an online article or blog post or whatever, and
Speaker 3: you're in the middle of reading a paragraph and then
Speaker 3: the page jumps because it just finished loading an image
Speaker 3: and that image pushed everything down, or maybe it replaced
Speaker 3: an AD and the new ad there's a different size
Speaker 3: from the previous ad, so things get either pulled up
Speaker 3: or pushed down, and you've lost your position in the page.
Speaker 3: And that's obviously a very poor user experience. I hate
Speaker 3: it when it happens, and it definitely happens in a
Speaker 3: lot of new sites. So what CLS measures is how
Speaker 3: much things on the page jump around, not in response
Speaker 3: to direct user interactions. So they look whenever something on
Speaker 3: the page moves, They first of all they check to
Speaker 3: see if it's you know, if there was a user
Speaker 3: interaction in the past half second or so, and if
Speaker 3: there has, then they ignore it because they say, well,
Speaker 3: there's a chance that it's in response to that user interaction,
Speaker 3: will let it slide. But if it's not that, if nothing,
Speaker 3: like the user is just reading, then they look at
Speaker 3: the size of the thing that moved and at how
Speaker 3: far it moved, and they calculate a number based on that,
Speaker 3: like a sort of a ratio number, how much of
Speaker 3: the viewport has moved and how far has it. And
Speaker 3: it's cummulative in the sense that it's not like the
Speaker 3: LCP which is looking for the largest paint and ignoring
Speaker 3: the others, or FID, which looks at the first interaction
Speaker 3: and then ignores subsequent interactions. It continues to measure to
Speaker 3: measure these movements. So the such movements that you have
Speaker 3: on the page, the bigger the value that you will get.
Speaker 3: And it just keeps on running and running and running
Speaker 3: throughout the entire session. And now they changed it now,
Speaker 3: and I'll explain how they change it in a second,
Speaker 3: but I just wanted to verify that that's clear, because
Speaker 3: it's a kind of a complicated metric. And it's also
Speaker 3: complicated because unlike the other metrics, it doesn't measure time.
Speaker 3: In fact, it doesn't have really any sort of a units.
Speaker 3: It's just a number.
Speaker 2: So remind me again, how are you getting all of
Speaker 2: this deep, dark secret knowledge.
Speaker 3: Actually, Google have been fairly forthcoming about these metrics. So,
Speaker 3: for example, there's a site web dot dev which is
Speaker 3: run by Google, and it has articles explaining these three metrics,
Speaker 3: and Google have been fairly forthcoming about that. There's still
Speaker 3: a lot of confusion out there, because you know, whenever
Speaker 3: there's a technical topic, there's bound to be confusion about it.
Speaker 3: And Google have been making changes as they go along
Speaker 3: and as they receive feedback from the field, from partners
Speaker 3: and whatnot, but they have been as forthcoming as they
Speaker 3: could be about the stuff that they're actually measuring.
Speaker 1: Yeah, I have a question. Yeah, that's actually what I've
Speaker 1: been looking at it. I just posted the links we
Speaker 1: put in the show notes, So I'm looking at the
Speaker 1: cumulative layout shift that you're talking about, Dan, And I've
Speaker 1: been to some pages and I've had some of my
Speaker 1: pages do this too. Right, whereas things kind of get
Speaker 1: loaded in some images or things like that on the
Speaker 1: initial load, a lot of stuff will shift right, but
Speaker 1: then after that then it's pretty stable. So how much
Speaker 1: room do you get on this right? Do they give
Speaker 1: you any grace to the beginning or is it just hey, no, okay,
Speaker 1: so it's got to come in pretty solid then.
Speaker 3: So for example, you were you were mentioning images, and
Speaker 3: that's a great example. A lot of people have issues
Speaker 3: around images because you're put in an image tag and
Speaker 3: then initially there's no space reserved for that image, and
Speaker 3: then the image downloads, and only when the image finishes
Speaker 3: downloading and the bar and the browser can actually parse
Speaker 3: that image, it actually sees that the size of that
Speaker 3: image and shifts everything in order to make room for
Speaker 3: that image. And it has to do with the fact
Speaker 3: that in the browsers with HTML, everything kind of flows,
Speaker 3: so if you push something in the middle, it kind
Speaker 3: of pushes everything aside in order to make or down
Speaker 3: in order to make room for that thing. And so
Speaker 3: what you should be doing is that you should be
Speaker 3: putting the dimensions of the expected dimensions of that image
Speaker 3: in the image HTML tag, so you can actually put
Speaker 3: with equals and high equals and then it will reserve
Speaker 3: that blank space for that image and then won't need
Speaker 3: to shift things around in order to make room for it.
Speaker 3: Or you could use CSS for that as well. But
Speaker 3: the point is that you want to reserve space for
Speaker 3: things so that you don't need to shift things around. Now,
Speaker 3: it can get really complicated in some scenarios, like for example,
Speaker 3: with ads, because a lot of times you have very
Speaker 3: little control over AD sizes. But maybe that'll force the
Speaker 3: industry to kind of standardize on AD sizes. I don't
Speaker 3: know now. What Google have done is they've made a
Speaker 3: recent change that they've made this measurement window, which means
Speaker 3: that they kind of divide your session into five second segments,
Speaker 3: and they measured the CLS within eah five second segment
Speaker 3: and report the CLS the biggest CLS that they've found.
Speaker 3: And the reason that they've done that is that they
Speaker 3: were getting pushedback that long lived sessions were getting really
Speaker 3: bad CLS scores simply because they were running for a
Speaker 3: really long time. So for example, people would open I
Speaker 3: don't know, let's say a Facebook web page, have it
Speaker 3: opened for an entire day, and it would get this
Speaker 3: huge CLS value at the end of the day because
Speaker 3: of a million of tiny shifts that nobody ever actually noticed,
Speaker 3: which accumulated over the entire day. So in order to
Speaker 3: remedy that, they've recently modified it, as I explained, to
Speaker 3: kind of work in the sort of a windowed kind
Speaker 3: of a manner.
Speaker 2: But it seems like I'm not too concerned with valueless
Speaker 2: applications that just scroll things all day. I would be
Speaker 2: happy if those got penalized. That seems like the right
Speaker 2: thing to do. Do we really want TikTok and Facebook
Speaker 2: to be ranking higher because they're programming people to be.
Speaker 3: No To be fair, I don't think Facebook has a
Speaker 3: ranking issue. I don't think they care that much how
Speaker 3: high they rank on Google.
Speaker 2: I don't think they need Google at this point. I
Speaker 2: think if Facebook did not come up in a Google search,
Speaker 2: they probably would have zero change.
Speaker 3: I think they intentionally don't come up in Google searches.
Speaker 3: Can you actually search for things in Facebook?
Speaker 2: I guess not anymore.
Speaker 3: You used to think so.
Speaker 2: They're kind of competitors in terms of they're both on
Speaker 2: ads and face. Facebook's goal is to keep everything off
Speaker 2: of Google because Google's been, you know, to be fair,
Speaker 2: Google has been playing dirty and ripping people off of
Speaker 2: their ad revenue. By putting snippets and the search results
Speaker 2: and stuff like that.
Speaker 3: It's an interesting discussion and I won't go there, no,
Speaker 3: but it's a really interesting discussion, but I think it's
Speaker 3: beyond the scope. But just to finish on that CLS topic,
Speaker 3: so I gave one example, which is reserving space. Another
Speaker 3: one that I want to mention, which just might help
Speaker 3: people out improving their CLS values, is when you use
Speaker 3: CSS animation, it's really important what you animate. So let's say,
Speaker 3: for example, you want to move something around on your
Speaker 3: page and you're using CSS animation for that. If you're
Speaker 3: animating the actual X and Y of that element, you
Speaker 3: will get a really big CLS value. What you want
Speaker 3: to animate instead is that transform X and Y of
Speaker 3: that element. And the reason is that when you use transformations,
Speaker 3: you're not causing reflows, so the pay the stuff on
Speaker 3: the page doesn't actually move and therefore there's no layout shift,
Speaker 3: and that's what you want to animate. So let's say
Speaker 3: you have a cookie banner and actually something that we
Speaker 3: had at Wix, so we added you know, GDPR and everything.
Speaker 3: We added the cookie banner, and we suddenly saw and
Speaker 3: we also measure obviously the corbet vitals for all our sessions,
Speaker 3: and we notice a jump in the CLS And it
Speaker 3: turns out that the developer created this cookie banner just
Speaker 3: animated on the X and Y, and we just modified
Speaker 3: it to animate on the transfer on the transform X
Speaker 3: and Y, and visually there was absolutely no difference. If anything,
Speaker 3: it was slightly smoother and the CLS issue was fixed.
Speaker 3: So it's really so if you're using animations, it's really
Speaker 3: important that you animate on transformations rather than, for example,
Speaker 3: on the position or the size of the element. I
Speaker 3: hope that was clear.
Speaker 2: There's money.
Speaker 1: It makes sense to me, And I think the reason
Speaker 1: that we're kind of going through this is because, yeah,
Speaker 1: my tendency is, yeah, you know, it's just like, okay,
Speaker 1: I need this to move or slide in or slide
Speaker 1: out or whatever, so just move it or slide in
Speaker 1: or slide out, right, And I would manage some of
Speaker 1: that by, yeah, by just managing X and Y or
Speaker 1: managing the height right, just changing the height, and so
Speaker 1: thinking through this and going okay, yeah, by managing the
Speaker 1: transform CSS or the transformed options like you're talking about.
Speaker 1: If I don't get penalized for that, then that's definitely
Speaker 1: the way I want to go so that I can
Speaker 1: maintain the user experience that I'm building, but at the
Speaker 1: same time not get penalized for it by Google.
Speaker 3: And it results in better in actual better user experience
Speaker 3: because the transform, like I said, doesn't force the browser
Speaker 3: to do a reflow, so it's it's better, it's smoother,
Speaker 3: it's it's GPU accelerated, it uses less battery on mobile devices,
Speaker 3: so it's it's better all around. So it's it's Google
Speaker 3: pushing the and and you know what, most cases, if
Speaker 3: you're using like a CSS library or some animation library,
Speaker 3: it's a good bet that that's what they're doing anyway.
Speaker 3: So unless you're creating your your stuff by hand, in
Speaker 3: which case watch out for it. If you're using some
Speaker 3: sort of a library, there's a you're probably getting the
Speaker 3: correct behavior out of the box. But you can always
Speaker 3: use a tool like Lighthouse which I mentioned before, page
Speaker 3: speed Insights, and you know, add this component, throw it
Speaker 3: in there, measure it and if you suddenly see that
Speaker 3: your CLS is jumped, and it actually shows you as
Speaker 3: with LCP it actually pagemen Insight will actually show you
Speaker 3: which elements on the page cause the shift, and you
Speaker 3: can say Okay, I see that this animated thingy is
Speaker 3: causing a shift. Let me check my animation.
Speaker 1: Maybe I'm doing it wrong, makes sense, Amy Steve, you
Speaker 1: guys have been pretty quiet. Anything you want to add
Speaker 1: or Chinese?
Speaker 4: Yeah? Yeah, I was trying to debate when the best
Speaker 4: time to add this. So a couple of things that
Speaker 4: I wanted to add. The first thing is Dan. I
Speaker 4: kind of talked to him a good bit about this
Speaker 4: at my prior job.
Speaker 1: But this is a really.
Speaker 4: Good thing for people to work on if you're in
Speaker 4: like a very product heavy environment, because it is a
Speaker 4: good argument to product type people, especially like if you
Speaker 4: have a consumer application, to get the bandwidth to work
Speaker 4: on this kind of stuff is pretty fun too, So
Speaker 4: that was just like a little tingential thing I was
Speaker 4: going to add. But then the I feel like the
Speaker 4: more important thing I was going to add is at
Speaker 4: my last job, one thing that we did which was
Speaker 4: pretty fun and also like very beneficial. You can get
Speaker 4: really really really fine grained, as Dan was mentioning with
Speaker 4: your lighthouse scores and automating the regressions against those, so
Speaker 4: you can get super fine grained on every single one
Speaker 4: of these measurements. You can set what you're We were
Speaker 4: using get have Actions that I set up, but based
Speaker 4: on like you know, if you merge a pull request
Speaker 4: or put up a PR or something like that, probably
Speaker 4: for this you'd want to do it like when you
Speaker 4: put up a PR. But there are some plugins I
Speaker 4: think sponsored by the Google team for get have Action
Speaker 4: where you can automate this stuff, and I highly recommend
Speaker 4: doing that.
Speaker 3: Oh, I totally agree. And the various tools out there.
Speaker 3: So get up Actions is one option. There are other
Speaker 3: tools out there. It's essentially called performance budgets. You want
Speaker 3: to have this as a part of your CICD process. So,
Speaker 3: for example, at Wix, we measure whenever we build a
Speaker 3: new version of a component. We have let's say a
Speaker 3: test site or a test page, and we look at
Speaker 3: the JavaScript download size, so we see we check to
Speaker 3: see that the size of the JavaScript download doesn't it
Speaker 3: doesn't increase or doesn't increase too much. And we also
Speaker 3: check the Lighthouse score and potentially other metrics and see
Speaker 3: if there's a regression in the score. And if there's
Speaker 3: a regression in the score, then the build is broken
Speaker 3: and it needs to get fixed before you can actually deploy.
Speaker 3: And so yeah, and it's a totally automated process.
Speaker 1: So what tool are you using for that your sees such.
Speaker 3: In our case, we're using in house developed tools, but
Speaker 3: there are plenty of other tools out there. Like Amy said, yeah,
Speaker 3: go for it.
Speaker 4: Yeah, I'm going to say, so where you're using a
Speaker 4: GitHub action, I can try to find it before picks
Speaker 4: and drop it in the show notes.
Speaker 3: Yeah. So so Google had something called light wallet, but
Speaker 3: I think they might have renamed it. So basically, there
Speaker 3: are plenty of solutions out there, a lot of them
Speaker 3: built over on top of Lighthouse that just turn it
Speaker 3: into something that's that you can incorporate into your CICP process.
Speaker 3: So just search for performance budget or automate lighthouse or
Speaker 3: stuff like that, and you should be able to find something.
Speaker 3: And the other thing that I wanted to mention in
Speaker 3: this context is it's it's a good idea if you
Speaker 3: have enough traffic, if you're big enough to also look
Speaker 3: at actual field data. Now Google is is the CrOx
Speaker 3: is a good place to start, built into your search console,
Speaker 3: and you can get it in the paid speed Insights
Speaker 3: and it's free and you can even look at how
Speaker 3: well you're doing compared to your competitors, but if you
Speaker 3: want to try to improve your current situation, then that
Speaker 3: twenty eight day cycle might be just too long, and
Speaker 3: then you might want to integrate some sort of a
Speaker 3: third party solution. I think you mentioned that we might
Speaker 3: have people from ray Gun in an upcoming episode. I
Speaker 3: think there are also other tools out there. Speed curve
Speaker 3: comes to mind. They're very neuralic, I think have something.
Speaker 3: So there are plenty of tools out there that obviously
Speaker 3: they're not free, but that you can incorporate into your
Speaker 3: or at least maybe there are also free solutions out there,
Speaker 3: but you can incorporate them into your website and start
Speaker 3: getting collecting real time data including cod vitals, and then
Speaker 3: you can do all sorts of sophisticated segmentations perhaps and
Speaker 3: get much faster feedback and also be able to do
Speaker 3: stuff like ap tests in the field and see how
Speaker 3: that impacts your CO or vital score. Yeah.
Speaker 1: I was gonna ask, because both raygun and Sentry are sponsors,
Speaker 1: and so I was gonna I was gonna say, I
Speaker 1: haven't looked to see if they incorporate these numbers, but
Speaker 1: I would imagine that if they don't have them in
Speaker 1: there now, they will soon, because this is something that
Speaker 1: people are going to care about.
Speaker 3: I think they both do. Actually, yeah, so I think
Speaker 3: I've more or less covered the things I wanted to cover.
Speaker 3: Unless there are any other questions, I guess we can move
Speaker 3: to picks.
Speaker 1: Yeah. I think I think we've covered pretty much everything
Speaker 1: there is. Right, Well, let's go ahead and do some
Speaker 1: picks then, AJ, why don't you start us out?
Speaker 2: All right, I'll start us out with a great technical pick,
Speaker 2: classless CSS. I picked this before, but I'm picking it
Speaker 2: again because it's just really really good. Basically, it's CSS.
Speaker 2: It's a buzzword that's not as buzzy as other buzzwords.
Speaker 2: But classless CSS means that just works CSS that you
Speaker 2: could use for a blog, or for markdown or for
Speaker 2: other things. Where As it says you don't have to
Speaker 2: use classes to get the effect. You just include the
Speaker 2: thing on your page and your page looks better instantly,
Speaker 2: without learning anything, without having to know about grids, without
Speaker 2: you know, it's just classless CSS. So there's a repository
Speaker 2: where there's a bunch of them mentioned, and then I'm
Speaker 2: going to link to that, and I will try to
Speaker 2: link to there's a couple ones specifically that I like
Speaker 2: because a lot of the ones that are pository is
Speaker 2: just it's just literally thirty different classless CSS styles and
Speaker 2: most of them suck, but there's two or three of
Speaker 2: them that are just on point. I am also going
Speaker 2: to pick one Finance. I used to use Simple, and
Speaker 2: as all Simple users know, it's now gone and because
Speaker 2: it was acquired by a company that got by acquired
Speaker 2: by a company that got well that that then was
Speaker 2: later acquired by a company, and so they are they
Speaker 2: are gone, and I've switched over to one Finance. And
Speaker 2: the key difference about it is that it allows you
Speaker 2: to have basically as many accounts as you want without
Speaker 2: any overdraft fees or anything, or monthly fees or any
Speaker 2: of that. It's to help you organize stuff so you
Speaker 2: can have, you know, the cable company, you can instead
Speaker 2: of giving them your main bank account, you can create
Speaker 2: an account that you give only to the cable company,
Speaker 2: and when something gets screwed up like it just makes
Speaker 2: it easier to budget and makes it easier to not
Speaker 2: have to worry about giving away an account number. That
Speaker 2: I mean, anybody that's had a bank long enough bites
Speaker 2: you in the butt when you give away your account number,
Speaker 2: because eventually somebody starts doing something shady, like your internet
Speaker 2: or phone company starts giving you extra charges or anyway.
Speaker 2: So it's just it's cool. And I'm including a link
Speaker 2: that's one of those refer friend links, so I think
Speaker 2: it's I get fifty bucks, you get fifty bucks kind
Speaker 2: of thing. So if that sounds useful to you, definitely
Speaker 2: check it out.
Speaker 3: Also.
Speaker 2: JCS Criminology is a YouTube channel that I've been following lately.
Speaker 2: It's it's kind of like a criminology podcast. It's kind
Speaker 2: of PG thirteen maybe MA because it is about real
Speaker 2: criminals and real crime, and it's a dude analyzing kind
Speaker 2: of the psychology of people and pointing out like, oh,
Speaker 2: you notice in this video when they're doing this, notice
Speaker 2: how their eyes shift. This is generally an indication of
Speaker 2: such and such. It actually goes over a couple people
Speaker 2: that are innocent as well, but just I love those
Speaker 2: psychology things. And then after that, just I'm still doing
Speaker 2: my Beyond Code thing. I'm not the course is not
Speaker 2: developed yet, but I've been doing a lot of live
Speaker 2: streams and little videos. There's an off library that I've
Speaker 2: been working on. It's basically forty hours plus of live
Speaker 2: streaming now, so if you want to watch me code,
Speaker 2: you can, and I am going to get back to
Speaker 2: the little short videos of teaching programming concepts as well.
Speaker 2: I just kind of been overburdened with other things that
Speaker 2: I need to do anyway, So that's all my picks.
Speaker 1: All right, Amy, what are your picks?
Speaker 4: Okay? So I was able to find these, and the
Speaker 4: first one is they do different things. So the first
Speaker 4: one is by the Lighthouse team, and this is this
Speaker 4: just runs based on you know, whatever actions use or whatever,
Speaker 4: you don't know what they typically call them and get,
Speaker 4: but like whatever hooks or events that are happening in
Speaker 4: a repo, it'll run a Lighthouse test against that branch.
Speaker 4: And then the one that I was thinking of, So
Speaker 4: that's the first link. I'll drop the one that I
Speaker 4: specifically was thinking. Oh that you can set up these
Speaker 4: budgets and just like you would, a test basically fail
Speaker 4: to build if when it runs that test on your
Speaker 4: branch or you know, that's assuming that you have your
Speaker 4: PR set up where there's some sort of like working
Speaker 4: URL that you can go to when you put up
Speaker 4: a PR. But getting into the weeds, but yeah, you
Speaker 4: can set up a budget to run your tests and
Speaker 4: fail to build if your branch drops below the budget
Speaker 4: that you specified. So I'll drop the lake to both
Speaker 4: sloms and that's it for me.
Speaker 1: Right, Dan, your picks?
Speaker 3: Okay, So my first pick is something that I actually
Speaker 3: should have mentioned while we were talking about it. So
Speaker 3: Google actually also recently, like a couple of days ago
Speaker 3: is the time of this recording, built a data studio
Speaker 3: on top of the CrOx API which enables you to
Speaker 3: graph coweb vitals related stuff for various technologies. So, for example,
Speaker 3: you want to compare the performance of all the sites
Speaker 3: that are out there that use React compared to all
Speaker 3: the sites that are out there that can that use Angular,
Speaker 3: well you can. Now you can do it based on
Speaker 3: the data in their CRUC database. So obviously their CRUC
Speaker 3: database doesn't contain every website if it contains something like
Speaker 3: the top ten million website according to the traffic that
Speaker 3: the chrome sees, but it's still fairly interesting. You can
Speaker 3: do all these all sorts of comparisons between different technologies
Speaker 3: and different products and different CMSs for example, and and
Speaker 3: stuff like that. So I'm posting the link here. It's
Speaker 3: a it's an interesting tool. So that's one thing that
Speaker 3: I wanted to post. The other another thing that I
Speaker 3: wanted to post. I recently watched this excellent video called
Speaker 3: Math has a Fatal Flaw and it's it's amazing. He
Speaker 3: talks about go to the self referential paradox in in
Speaker 3: set theory and about the completion problem, and it's all
Speaker 3: of This entire video is like half an hour, and
Speaker 3: the amount of information that it covers in such an
Speaker 3: understandable fashion an accessible way is astounding. Somebody on there
Speaker 3: literally said, I'm a professor in the university and this
Speaker 3: is like an entire course, this half an hour of video.
Speaker 3: So it's an amazing video and I highly recommend it.
Speaker 3: So I'm going to put a postal into that here
Speaker 3: as well. And the last thing is something that I'm
Speaker 3: actually kind of asking for help. As it were, I'm
Speaker 3: running out of stuff to watch. I'm unable to find
Speaker 3: good stuff on TV anymore, like then the Netflix and stuff.
Speaker 3: I don't know, that's just the quality is not it's
Speaker 3: not there. So we watched Mayor of Eastern or East Town,
Speaker 3: which was really good with Kate Winslet, and I recommend it.
Speaker 3: But now that it's done. I don't know what to watch.
Speaker 3: So if anybody has a suggestion, you know, hit me
Speaker 3: up on Twitter or something and let me know what
Speaker 3: you recommend for for us to.
Speaker 2: Watch anime and always anime?
Speaker 3: Which anime? Most animes are stupid? Well, I didn't say
Speaker 3: all anime. I said most anime. There are a couple
Speaker 3: of good ones, but most of them I lose interest
Speaker 3: within like the first episode.
Speaker 2: We'll talk. Then we'll talk.
Speaker 4: You better be careful and lock your doors at night.
Speaker 3: Now again, I didn't say all anime. I said most anime. Well,
Speaker 3: most content is crap exactly. Most anime falls within most
Speaker 3: content we just talked about. I totally agree.
Speaker 1: All right, I'm going to throw somebody can.
Speaker 3: Point me sorry, if somebody can point me at the
Speaker 3: good anime, i'd appreciate it.
Speaker 1: All right, I've got another call I need to get to,
Speaker 1: so I'm gonna do this real fast. But I started
Speaker 1: reading another book and some of you may or may
Speaker 1: not have heard of it. It's Atlas Shrugged, and I
Speaker 1: have to say I'm about a quarter of the way
Speaker 1: through it, and by reading, I mean listening to on audible.
Speaker 1: I love this book. It is so far. It is
Speaker 1: just amazing.
Speaker 3: Isn't Ian run something that as someone who's we are
Speaker 3: supposed to read in our teens or something.
Speaker 1: I don't know that it was ever something that, yeah,
Speaker 1: in any of the classes that I took we had
Speaker 1: to read. But I'll tell you, I really identify with
Speaker 1: the characters that are in there and with some of
Speaker 1: the things that are I feel like some of the
Speaker 1: stuff that she talks about. I just look at the
Speaker 1: world today and go, oh, yeah, this is applicable. So anyway,
Speaker 1: it's making me think, which is always a positive thing.
Speaker 1: So I'm gonna pick that and then go check out
Speaker 1: dev Influencers podcast, Definite Influencers dot com, slash podcast, and yeah,
Speaker 1: that's what I got. So we'll go ahead and wrap
Speaker 1: up here. Thanks Dan, this was really interesting my pleasure.
Speaker 3: And as usual for anybody who's interested in performance related
Speaker 3: stuff or JavaScript stuff, you know, hit me up on Twitter.
Speaker 3: I'm Dan Ship here on Twitter. I usually follow back
Speaker 3: and go for it.
Speaker 1: All right, folks, We're going to wrap up here until
Speaker 1: next time, folks, max out.
Speaker 3: Bye.