Transcription
Thank you for joining us on our new time. Uh, we will be at 9:00 a.m. Pacific Time on Wednesdays going forward. I'll let Kyle explain why. Uh, well, it's because I'm in Thailand and 11 was 1 AM, and that was a bit rough. It's 11 PM now, and that's a little bit more doable for the Thailand time.
All right, let me pop out the chat. Do you need to let Clinton? I think we do. We got him. Excellent. Let me kill Skype. All right, and I will share my presentation. And I should put it in presentation mode. Cool, like a pro. We're proud of you.
All right, so, uh, today we're gonna be talking about Core Web Vitals, which I think is long overdue. It's a six-month-old topic that we're just now getting to. Uh, I don't like to hop on the bandwagon with these new, you know, the new way search will work forever going forward, it changes everything. Uh, what do you, uh, feel about these types of announcements? Not this specific one, but in general, these types of, "this changes everything in search" announcements?
Well, you know, we've, we've seen this in the past, like with Mobilegeddon and, uh, what, like HTTPS and stuff like that. Um, they, they seem and end up more like a Y2K situation where it's much ado about nothing. Um, the, uh, what I really think we should do, though, I've been thinking about this, is that we should say that the proper pronunciation is "vitals" and and get that going because I think it might be a lot more interesting if, if we're like, "No, it's not Web Vitals, it's 'beetales'," and then like that becomes, it gains its own meaning in in terms of what it actually is.
Well, it, it's funny that you bring that up because, you know, I was thinking about the name of this thing. You know, "core," it's fundamental, it's foundation, you know, it's at the essence. And and "vital," you know, you need this to live. It's like your heart rate, it's like blood oxygen level, it's brain activity. You know, these are the the foundations of survival on the web. And, you know, when I dove into the technical documentation on what this is, uh, you know, it's, it's a hype name. You know, it's, it's kind of like when politicians make, you know, bills and they call it, "You must hate freedom if you don't vote for this bill," you know, it's that kind of game almost. But we'll get into that after some boilerplate.
So Clint, what can people expect on SEO This Week? Which is backwards on your graphic overlay. That's because I always want to, you know, [Laughter] you and your twos. And then you're supposed to have that. You don't want to get any copyright issues, right? Uh, this week, I go over seven news stories. One of them is more of a kind of, "this is a cool guy thing you can do with your websites and graphics and stuff," and it's really easy to duplicate. Uh, and then we look at keyword research, how I approach it, and judging the competition, and how I want to, if I, if and I could possibly rank for that. Um, and just some of the tools that I use to go over that process. And then I have to answer a whole bunch of questions too. So we kind of go off on a rampage. It was supposed to be 30 minutes and ended up being an hour. Cool.
Yeah, I highly recommend you check out Clint's show if you haven't. Uh, you can find it at digitalear.com or you can go search for SEO This Week on YouTube. Uh, both are pretty direct ways to getting to his content. It's a great show, so be sure to subscribe. You know, we, we live or die based on those subscription numbers. They are our core YouTube vitals. So please do subscribe.
Uh, we also have Trey in the audience. Let's see if he can tell us what's coming up on his channel. Hey Trey, I'm gonna make you a presenter. Just turn on your camera and mic if you want to tell everyone what's coming up and what they can find. Hi Trey, I can't hear you. Professionally. Oh, here we go. Here we go. Here we go. All right, what's up, IMG family? I just wanted to say what's up, you guys, and thank you for all the love and support. But this week, we have Lily Ray coming by to talk about E-A-T. Um, she's gonna, she's like the expert out there. She does a lot of speaking gigs, and she's also a DJ. So stay tuned at the very end for that musical treat, and I hope to see you there.
I was going to ask you about that. So she's going to do some DJing at the end? Well, I got, I was trying to get her to do it live, but she says, "I'll, I'll send you a video." I was like, "Oh, that's fine. It's totally fine." Live would have been amazing. Yeah, she does a lot of Periscope DJ sets, so I was like, "Yeah, yeah." I was hoping that she would do that. But, but thanks, guys, for all the very, very cool.
So yeah, if you haven't seen this show, he, he does a little bit of news and tips and tricks, but it's mainly about an interview where he really dives into the background of how people's careers came to be and how they see the world. So I highly recommend you check it out. You can learn a lot, not just about SEO, but about business and life in general. So it's a very cool show. Um, and let's see, what do we get next? Uh, we have, what's coming up next? Uh, let me make Lauren a presenter here. And Lauren, do you wanna tell us about This Week in IMG?
Yeah, so this weekend IMG, we have on Thursday the SEO Testing Mastermind, and that's always really exciting. That's at 5:30 PM PST. And then we also have Part Four of the HV SEO Audit, and that is a presentation of an audit. Then on Friday, we have an SEO Pro Tip, as well as a special giveaway with a thousand-dollar value. So look for that in IMG. And then on Tuesday, we have an AMA with Kyle Roof.
Very cool. So yeah, thank you for that. There's a lot of stuff going on, so I hope you, uh, get involved because there's some amazing content happening. And I know that the Kyle Roof AMAs tend to be off the hook. There tends to be a lot of questions. So I recommend even if you don't plan on attending because of time zones, that you get your questions into Kyle or Lauren or into the IMG community because you can always watch the replay, and they go over all those questions too, even if you're not in attendance.
So with that, we will move on to our topic. Thank you, Lauren. Um, so today we're talking about Core Web Vitals. So, uh, this is something, so Kyle has corrected my pronunciation. Um, this is something that came out a while ago. There's a lot of teasing that this was going to be new, important factors that will change the way search works. Um, and lots of tools and APIs built around it. It's digging deep into the internals of Chrome to get at this important data. And I will give the concession that the data that they're measuring in the three buckets of the Core Web Vitals are difficult to measure. Like, you pretty much need to author a web browser to be able to measure these things. So it's cool that there are like Chrome APIs for accessing this data, but that's not the problem. That's the cool part. You know, good job to the authors of Chrome for making this data available. Where it gets problematic is when Google starts saying these are going to become important ranking factors. And so that's why I want to kind of talk about this today.
So the three buckets and Core Web Vitals is not for the faint of heart. If you are a career SEO but not a computer engineer, this is getting into the tall weeds. Uh, this is something that I think that even seasoned, uh, software engineers, uh, with a, with a lot of experience, uh, in optimizing code can mess up. And I think that for a layperson trying to get into the technical aspects of tuning these for SEO, I think it's a very difficult thing to do. Let me turn off my camera.
And we have these three areas. So we have the Largest Contentful Paint. All right. And so we're gonna get into that one first, and we'll define these. But this one, you know, kind of in a nutshell, uh, they're looking, they're trying to approximate how long does it take the main content of the page to render? But even with the definition like that, there are big problems and how it actually works.
The next one is the First Input Delay. And so this is kind of looking at, okay, so we've rendered the page. There are clickable things on the page. If you were to click one of those, how long would it take the website to respond to the click? And so that, that's what that one's trying to get at. And so that one's, uh, complicated because you need at least a partial page render to have clickable things on the page, and it needs to be in a state that your events can be processed. And then you have to have an event to process a click on some element, and then your timing from when you click to when you get the response for the click. Uh, so that's a tough one to measure.
And then there's the Cumulative Layout Shift. And this one, we've seen our whole lives in SEO. This is when you load a page and you start reading it, but because everything hasn't loaded, the content starts shifting around as the elements get loaded. That's the layout shift. So anytime, uh, the content starts changing size or position, uh, and creates a bad user experience because on a slow connection, like on a cell phone at a bus stop, you've started reading the article, you're halfway through the paragraph, and then some jumbo image loads, and you've lost your spot. And so that's the layout shift. And so those are the three buckets of, uh, the Core Web Vitals. And Google had said that, you know, these are gonna become a ranking factor. And so just recently, uh, they started backpedaling. And so, you know, six months ago, they said it was going this way, and now six months is here, and they're now saying, "Whoa, whoa, whoa. We said it would be a ranking factor. We never said it would be a *big* ranking factor." And and that's a pretty big backpedal. I mean, they put a lot of hype into it. Um, and, you know, if we, if we go back and look at that title, you know, the Core Web Vitals, you know, it's, it's core, it's foundational, it's vital. You know, it's, it's like, you know, your blood oxygen level or heartbeat or brain activity. You need it to live. And, you know, I'd even argue that "web" might not even be appropriate for describing what it's measuring. Um, so, you know, there's, there's a lot of hype on it. And let's kind of dig deeper into what it is.
A Search Engine Journal has one of the top-ranking pieces of content talking about it. Uh, and I just, I wanted to pull this up because there are so many problems with even defining what it is. So here it says, "LCP is a measurement of how long it takes for the main content of the page to download and to be ready to be interacted with. What is measured is the largest image or block of..." I think they meant "content" instead of "context." "...within the user viewport. Important detail: anything that extends beyond the screen does not count." Like, this is a very specific definition of what this is. And if we go by that, here's the mobile viewport. By that definition, anything outside of this viewport does not count. So what you get is the logo, an ad, a cookie pop-up, and an obstructed heading. That's it. That's your main content by this algorithm.
So, uh, Clint, do you think that's a good definition of approximating main content? I, I don't. I've, you know, playing around with it and stuff, I just, I have a whole lot of issues with this. Looking forward to discussion point in this conversation. Any thoughts, Kyle?
I honestly have no idea what any of this is. I mean, really. You know, I've read through the, you know, you can go to like, was it web.dev or something like that? Yeah. I've read through like five or six times, and it's just all I see is just like words, words, words, words, words. And then I just, yeah, it's very technical. Like, if you're not a software engineer, you're going to have a hard time tuning for these qualities. But yeah, you can see there's clearly a problem. This is not the main content, but this is what the main content will be based on Search Engine Journal's understanding of it.
Fortunately for the Web Vitals, I think Search Engine Journal didn't get it quite right. So, uh, right here, this is from that source that Kyle just mentioned. LCP uses the largest element, so an HTML element, to approximate the main content. So it isn't measuring the main content. It's an attempt to approximate the main content on that page. And so if we tried to correct this based on the actual documentation about what LCP is, it should be: LCP is an approximation of how long it takes for the largest HTML element of a page at the initial load time. Important detail that they overlooked in their definition, to be drawn to the screen. Has nothing to do with interaction. It's all about drawing to the screen. This is an estimation of page speed based on rendering time. And that by itself is also problematic.
See, because it's based on rendering time, we know that the client-side hardware can dramatically affect the measurement because rendering time is affected by CPU speed, number of cores, the memory available, the CPU available, the resolution of your monitor, any acceleration you have in your graphics, the number of running processes, and your internet connection speed. So from one visitor to the next, you're gonna get very different measurements for LCP because it's all about render time. And these things change render time. So if you're on a cell phone, you get a different render time than if you're on a 32-core Threadripper. That's just the nature of rendering. And so LCP from one visitor to the next is going to be a relative indicator of the visitor's hardware. And in aggregate, you know, Google could use this to score, you know, which pages render the fastest for certain hardware profiles on the client side. That's one thing you could do with it. Uh, Google could say, "Well, you know, we're using Google Bot, and we only care about Google Bot scores. We don't care about your average viewer scores." But even with Google Bot, not all Google Bots are the same. They are thousands of servers, many of which have different configurations, and they're busy. I mean, those, they have lots of web pages open on those servers. They're not dedicating a whole server to a single instance of Google Bot. That's not how that works. And so what this ends up doing, if this is a factor, it, it's gonna, and you make it a strong factor, if you say, "Yeah, LCP needs to be a strong factor," you're basically saying that relevancy should count less for people at bus stops. That person on the poor hardware at the bus stop should see different results than somebody with the 32-core Threadripper. So it creates a dilemma that relevancy should factor less at bus stops, and that's a terrible factor. I can't imagine that being a good thing.
And even though it is a page speed measurement based on render time, we're not even sure that page speed is actually a factor. I think there's more evidence to say it behaves like a filter, and it affects how much traffic you get because when your pages are faster, you appear in more searches. But that can happen without your rankings ever changing. And typically, when you make your website faster, you get better conversions and more organic traffic. You don't necessarily see your rankings go up or down. And so we still have questions as to whether or not page speed itself is even a factor. So, uh, any thoughts on that so far?
No, right with you on it. So the next bucket in the Core Web Vitals is that First Input Delay. And so, like I, I mentioned, this is measuring, uh, once the page is loaded and there are clickable elements on the screen, if you were to click one of those elements, how much more time would it take the server to respond to that click? So that's what this is. And there are problems with this, and that if you use JavaScript click handlers, uh, you're at a disadvantage to using just old-school links. So if you have, you know, frameworks or fancy UI, uh, you know, that technically could work against you on this factor. And just having a simple link in an A tag is gonna get parsed and processed and be clickable than waiting for JavaScript to execute to create the event listeners to create the event, uh, cues that, that, and the consumers that will process the the click events going through JavaScript handlers. So it, there's a problem in that this is going against the advancement of those web technologies that everybody is moving towards. So when you go and get a WordPress template that has, you know, cool, you know, layouts, cool navigation, lots of interactive widgets, most of those are in jQuery and in other frameworks, and they're all JavaScript-based. But you're gonna have a handicap compared to just being simple HTML only. And so that's counter progress.
And this estimation of responsiveness will vary from one browser to the next because you have to remember that Safari and Firefox and Opera and any other web browser you have is gonna render differently than Chrome does. So from browser to browser, uh, this metric won't make much sense. It'll be apples and oranges. So it's only a Chrome thing. And it's also greatly influenced by client-side hardware and network connection because you're waiting for the page to render because there may be things happening asynchronously and in parallel. It, your CPU could be busy based on how much hardware you have at the time you make the click. Somebody on a cell phone is typically going to have worse input delay than somebody on that Threadripper on a broadband connection. So, you know, again, it creates a dilemma of, "Should relevancy factor less at bus stops?" Because if you make this a strong factor, you're basically saying that the person at the bus stop on the crappy hardware should see different search results. And that's why I say it's a dilemma of, "Should relevancy factor less at bus stops?" And it, it just boggles my mind that people would go, "Yes, we should make that a factor. We should make, we should make, uh, the quality of the hardware matter a lot more than the relevancy of the page for the keyword." And so I have a hard time seeing that as a strong factor.
Another website posted this graphic, and I wanted to talk about it because I, I thought it was an interesting graphic. So this is a hypothetical waterfall. So you have the page load, the HTML of the page, and these are resource loads like a stylesheet and three JavaScript files that are loading. And when I see a waterfall like this, which is pretty common and typical, uh, it's interesting. So this gray bar here is the main thread. This is how busy your computer is. And the yellow bars are too busy to respond. And because there's this big yellow bar that only exists during this script's execution time, that leads me to believe that this JavaScript has a performance problem. So for this First Input Delay right here, I, I would suspect that this JavaScript is a problem causing that issue. But there's many ways to do it. You can send your engineer to go find whatever is being the CPU hog in this script and make it better. You could also take these external files and make them all inlined in the HTML, and that reduces the asynchronous requests, and that has the effect of taking all these yellow blocks, pushing them together, and shoving them to the left. And for all practical purposes, makes this input delay feel a lot smaller because it happens much earlier in the timeline.
The problem is, is if you tune, if you try to fix your input delay by reducing asynchronous requests, which can be a beneficial thing, you end up hurting yourself. I go back here. So we eliminate those asynchronous requests, and don't worry too much if you're not following it. But those asynchronous requests allow for caching of those JavaScript files, of CSS files. And that caching potentially makes your LCP, your Largest Contentful Paint, and your Cumulative Layout Shift a lot better. You get better scores on repeat visitors because of that caching. The only way you could know that is if you're a highly technical SEO, like you're doing your own web development and you're into optimizing code. But the important point is, there are things you can do to address these buckets that hurt one or both of the other buckets. There are things you can do to fix CLS that will hurt your paint. There are things you can do to fix your paint that will hurt your input delay. So if you don't know what you're doing here, you can just, you know, be chasing your tail trying to get these balanced and scoring well.
And so that brings us to the third bucket, the Layout Shift. And so any time a visible element on your page changes size or position, uh, then you have a layout shift, and that's considered bad. This is the bucket that is probably the easiest to address, and, you know, you probably should. Uh, you generally just want to use width and height on your images. If you have variable slots where different size content appears, you know, scope it to a min and max. Try to avoid dynamic content. Uh, and use preload with your web fonts. You know, these things minimize the layout shift. So those, those are all good things. But, you know, again, faster client-side computers with faster internet connections see layout shift for less time. So if you're on that Threadripper with gigabit internet, the fact that there's layout shift that happens over the course of 40 milliseconds doesn't really matter. But when you're on that cell phone on a 4G connection, and it takes four and a half seconds for the layout shift to end, uh, you know, that's a really bad score. So again, the client-side hardware on this dramatically affects the scores you get. And so again, you know, it creates that dilemma of, "Should relevancy factor less at bus stops?" And I have a hard time trying to find a reason why you would ever want relevancy to weaken at bus stops. I, I just don't get that concept. And when it comes to, you know, trying to tune for it, yes, there's a little bit of control you have on your web page, but because it is so dependent upon the client-side hardware, how do you plan to tune your average visitor's hardware and connection speed? I mean, the bulk of what needs to change to make these scores dramatically change is out of your control.
And so it brings us back to, why did Google even do this in the first place? And, you know, I, I don't know why they did it in the first place, but my guess is that if average, you know, page render times and interaction times are faster, it's probably a big cost reduction for Google to be able to crawl the whole web. So they probably want to see these things because being able to render a page faster and being able to interact with that page faster lets Google Bot go faster. And, you know, that's an important thing that lets Google crawl the 200 trillion URLs faster with fewer computers and less power and less bandwidth. And, uh, well, maybe not less bandwidth, misspoke on that one. Uh, but, you know, it's, it's a cost reduction. And it brings the question of, does Google, if you make your page render faster, and if you make it interact faster, does Google reward that with better rankings? Because that's what being a factor is. If you're a ranking factor, when you do that, you rank better. And does Google reward these measurements? Uh, or, you know, does rewarding these measurements produce a better search result? And, you know, like I said before, you know, if you're making relevancy factor less, does that produce a better outcome? And, and I just don't think it does. And these metrics that they're doing have nothing to do with relevance or authority or expertise or trust. I mean, they may, you know, very indirectly be trust because you've invested so much in getting good scores in them, but I just, I highly doubt it. I have a hard time seeing that. And tuning for these is so technical that the measurements from one site to the next probably look like random numbers because websites in general can't do it. And so anything where the measurements look like random numbers, I mean, that's a crazy thing to to introduce as a strong factor. Uh, and in general, these concepts work against long-form content. If it's ignoring everything outside of the viewport, your long-count, your long-form content just doesn't matter for that.
So finally, it brings us to, why tune for speed at all? And what I try to tell people again and again and again is, you don't tune for speed to get rankings. If you tell your employer, "We need to tune for speed so we rank better," you're probably going to look really bad when that doesn't happen. In general, when you make your pages faster, what you tend to see is more organic traffic to the page without your rankings really shifting much, if any at all. And that's simply because we tend to see page speed behaving like a filter. When a person on a ferry boat checks their rankings, the slow websites don't appear in the search at all. So when you get into the office and recheck your rankings, you see different competitors because on that broadband connection, it includes the slow sites. So by having a fast site, you appeared in more searches. You appeared on the broadband, and you appeared on the ferry boat. It doesn't mean you ranked at a different position. And so because of that, if you're tuning for speed, which is a good thing to do, everyone should do it, and we have been doing it in very good ways, if you're tuning for speed, you're tuning for traffic, more organic traffic, and you're tuning for better conversion on your website by having a better experience. The one thing that isn't in that rationale for doing it is rankings.
So any, uh, thoughts on all of that, guys? The one thing that I was thinking, Ted, is that, you know, in the same way that Google might exploit time and speed things up, could they do the same sort of thing with, uh, kind of like running things in parallel as like a quote unquote, like average computer, or what they, can they assume is an average computer in order to get those scores? So it's not necessarily dependent upon the user making an actual search, but Google does it in a virtual realm where they approximate what they think normal computer speed is.
They, they would have to. Uh, it's the, the only way they could do it. But again, you know, when they make a determination on that, they're going to be favoring a context. Are they favoring the desktop computer on the corporate intranet, or are they favoring the cell phone at the bus stop profile? And Google Bot is not a, is not an analog to one browser on one system. Google Bot is most likely, you know, hundreds of browsers operating in parallel on a single system because they want to maximize, uh, the output of that, that hardware allocation. So that would be akin to trying to, to measure these very subtle render times while opening hundreds of browser tabs at the same time. So, you know, is Google going to dedicate a typical system for every URL to get an apples-to-apples measurement? I think that's cost-prohibitive to allocate that much unused CPU to get that measurement. So could they do it? Possibly. I think it's highly unlikely, though.
Yeah, makes sense. What about you, Clint? How do you feel about Core Web Vitals?
To go back on your point when you first started, I think that Google has used this method, uh, quite often, and eventually SEOs are going to get smart and stop allowing them to go to this well. And that well is, "Hey, we've launched this new feature, it's going to be a ranking factor. You guys should adopt it right away." And then six months later, when everyone does it, "Oh, it's not, well, no, it's not a ranking factor. It's kind of like a ranking suggestion." And that's right along the lines with HTTPS. That's how they build Google AdWords. They go into the community like ours, the affiliates, and the SEOs, people that they know that are living and dying based off of the Google algorithm and being, the ability to rank pages, etc. And they're getting us to embrace their new and exciting tool, and then pulling out the rug and killing, kind of doing an "Ookie Dookey."
So, uh, it's, you kind of had to really see it coming if you've been around long enough and you know that they launch things. The white hat crowd predominantly are the ones that jump on it and embrace it. The black hat crowd does it as long as it's working. But the white hat crowd are the ones that might really promote it out there and do tons of blog posts and create software and do integrations right away and say that, "You need to adapt. You need to use this." And, um, love them or hate them, the white hat crowd has the ear of most business owners. And then six months later, as you see, Google says, "Ah, well, you know, it's not necessarily as important as we may have went on." And they don't want to say that out loud, but essentially, you read between the lines, and that's what I'm saying. I think it's, it's kind of short-term memory on the part of SEOs. Is this Google does that to you all the time, and they get you to embrace this new technology, etc., and then they pull the rug out from under it when it just doesn't work out well for them. SSL, AMP, and now Core Web Vitals. Search Console, that turd of the software is coming out. The Rich Snippets Testing Tool, so they can deprecate the, the best testing tool that was out there, so they can create another turd. It's, it's a, it's a cycle that unfortunately you were kind of stuck in.
Yeah, I, I think the ROI on tuning for these three buckets of measurements is close to zero. I, I think the cost of getting the technical expertise to do it well is extremely prohibitive. I, I don't even know of large corporations that could justify hiring that caliber of content for this business problem. So, you know, my, my official recommendation to people is, you want to have a fast, responsive page, but you can basically blow off Core Web Vitals because it's highly unlikely that you would address it properly without having extremely expensive engineers doing it for you. I offered service on page speed. You guys know that. Probably one of the first people who actually offered a service on page speed optimization. And I, I tell people all the time, "Don't even, don't even look at it." I mean, it's there, it looks cool, but if you get your clients hooked on it, or if you get hooked on it, you're setting yourself up for failure. And page speed, while important, uh, is more important for the user than it is for Google. And as long as you've meeting this set standard that Google looks for, and in my experience of all the sites that I've looked at, well over a thousand, if your site is loading completely three seconds or better, and people can use it in three seconds or better at the bus stop or anywhere else, then your site's good. You've, you've invested enough time and energy in the page speed optimization.
Yeah, and it's also important to know that tuning for page speed is different than tuning for Core Web Vitals because, like we pointed out in the beginning, Core Web Vitals is about optimizing for rendering time. It's all based on rendering time. And your page speed is more about how fast does your web application respond from the server. So one is a server-side problem, the other is a client-side problem. And so when you get Clint's service for tuning for page speed, that is much more important in my opinion than trying to tune for Core Web Vitals.
Let's get Lee in here. See if he has any feelings about the Core Web Vitals. Lee, what do you think? Can you hear me? Yep. Um, my, my thoughts come, I just came late to this. I was training a tester actually, but, um, the thoughts come from, you know, our discussion yesterday on this. It looked like, uh, based on what you were describing, and I loved Clint's rant on this, I'll just, you know, echo what he said. It looks like another thing that they're throwing out there that they're going to pull the rug out from under you, and it's not really something that you should spend a lot of time on. It benefits them, uh, and not, uh, not us as SEOs or, or the clients for that matter. So that's kind of where I, uh, landed on it. But yeah, that's, that's how I feel too.
So, uh, you know, with that, that's our show. I don't know if there are any questions. Uh, let's see. And I wouldn't suspect any questions on this. It's a pretty technical topic. I think the main takeaway is you don't want to invest heavily in it.
Yeah, you went. [Laughter] It's funny because when I came on, uh, I came on just in time to on this, and I thought, "What a perfect ending for the show." Yeah. Well, you know, the important takeaway is this is largely based on rendering behaviors. Rendering behaviors are completely determined by the client-side hardware. And so can the client-side hardware actually be a strong ranking factor for your page that has nothing to do with that hardware? And so it's, it's very problematic for me. They, they have some explaining to do if they're saying this is a ranking factor. But with that, that's our show. And I want to thank everyone and remind everyone again that we will, uh, for, uh, the future going forward, we will be at 9:00 AM Pacific Time on Wednesdays. So be sure to change your calendars if you like to attend, uh, each week. And thank you again for attending, everyone. Bye, everybody. See ya.