 Hi, everyone, and welcome to the June 10th edition of the JavaScript SEO Office Hours. I'm super happy to see that a few people joined the recording as well, and that lots of questions were submitted. So let's get going. I'll start with a question from YouTube, and then I'll ask the audience if there's any questions in the audience as well. So is Google Search Console a good way of identifying whether Google is able to crawl links that are coded up within JavaScript? It is if I run a URL that has lots of JavaScript on the page, and the source code, is the source code captured in Google Search Console a good way of identifying how Google is able to crawl that JavaScript? Yes, if you use any of the testing tools, so the URL inspection tool, in Search Console, the rich results test, or the mobile friendly test, or the AMP test, or whatever, you see the rendered HTML. That is what Google sees if something is in there, good. If something is not in there, not good. That means that we are not seeing it. That's relatively easily said and done. Do we have questions from the audience? I've actually got a question that I did submit as well. So it's just around. So it's on a bit of background. We basically have a number of customers that we help to do SEO. And a lot of the websites are built in platforms which don't give you the ability to control changing different elements, really basic elements, like title tags, headings, that sort of stuff. So we built a little JavaScript script that we added onto their website that would give us the ability, using JavaScript, to update some of these elements. Google didn't always seem to pick up the changes that we made. So it's kind of two questions. One was, is there a certain way in which we should load that JavaScript, a certain point at which it should be loaded in when the page is rendered? And then also, secondly, what's the best way to check to see that Google's picked up them changes? So generally, there's no problem with doing that. And I would say the earlier you do load the JavaScript, the better it is. Because we are running a bunch of heuristics to figure out when the page is done. So if it takes a lot longer, then basically, if the page does its thing and then a long time passes and then your script kicks in, we might actually miss that last bit. So the earlier you can do it, the better it is. Even better if you can do it server-side. If you can't, then that's fine as well. And to test this, the best thing is to use any of the testing tools and check in the rendered HTML. If what we are rendering there or what we are seeing there is what you expect us to see. OK. Yeah, because we started doing this quite a while ago, I think, before the new version of Search Console. So that wasn't kind of fully available at the time. And what we were doing was we were seeing within the actual search results page for the website the kind of the title that got brought back and the meta description that got brought back, whether that was the updated. Is that not a good way to test it? That's not really a good way to test it because we might rewrite that. The actual thing that was happening was it was actually showing the non-rendered title tag was showing in the search result and not the rendered. Yeah, that might happen if we think that that's a better choice. OK, that's fair enough. Yeah, that's fine. Then that's my question answered. Thank you. Awesome. You're welcome. Then we have a question on, hold on. Now I actually confused myself and I'm not sure if I am in the right thing. Yes, here. What's the definition of the load event in the DevTools? Mozilla says the load event is fired when the whole page has loaded, including all dependent resources, such as style sheets and images. But what is the definition of the whole page is loaded? So there's two events, technically speaking, that the DevTools highlight. One is the load event. One is the DOM content loaded event, I think. The DOM content loaded event is the moment when the DOM has entirely been parsed, but things might still be pending. So for instance, if the HTML has an image and an iframe and the style sheet and whatnot in there, then the DOM content loaded would fire the moment we have parsed the HTML. So even before we know what's in the iframe, before we know the image, if the image exists, what the image looks like. So that's basically when the HTML has been parsed and understood and the DOM has been constructed. And then the load event waits for everything to finish its thing. So if we have seen a script and a style sheet and two images and a video and an iframe, all of that would have to finish loading before the load event fires. But these scripts in turn might do things themselves, like load something. This might or might not be before the load event fires because the load event fundamentally says everything that is referenced in the DOM has been downloaded and is there. It does not mean that the scripts have been executed and also just imagine a script could hypothetically have a set timeout for five seconds and then after five seconds make a network request. So the load event wouldn't wait for that to happen. The load event would fire the moment everything has been downloaded that belongs to the page. Every style sheet, every image, every video, everything. It's content that is added afterwards by JavaScript is not considered in the load event. So the load event might fire before these things start to load. I know that's a little tricky sometimes to figure out why the load event is in a certain spot not later or earlier, but that's roughly how that works. All right, do we have other questions from the audience before I go to the YouTube questions? Yeah, I have a question about server-side rendering. So I'm considering doing a hybrid approach right now it's client-side rendering and to, let's say, save resources or prioritize. I'm asking what would you recommend for the approach to take on what to prioritize. So for example, content or title tag or canonical, what should I prioritize in terms of going server-side hybrid? I would, if you want the biggest bang for the buck when it comes to server-side rendering because server-side rendering is quite an investment both in coding effort as well as infrastructure. I would say everything that is critical content. So title, meta-description, canonical, and the actual content that the user is interested when they come to the page. So what that is depends a little bit on what your website looks like. If it's a shop, it's very likely that the main content that you want to server-side render is probably the actual product description and product images and stuff like that. If it's a blog, it's very likely the article content and then everything that is kind of secondary, I don't know, like comments, ratings, whatever, these kind of things can potentially be client-side rendered afterwards because you want the largest contentful paint, the big blob of things that the user is interested in. You want that as quickly as possible and as quickly as possible, usually means server-side rendered. Great, thanks. Also, in addition to that, the canonical right now on the server-side, almost on all pages is going to the home page and then the rendered goes to the inner page. So would you then prioritize that over critical content? I would say no. I would always go for the critical content over any of the meta information. But having that, it's probably better not having a canonical than having an incorrect canonical and then updating that or adding that using client-side rendering because it is unlikely, but it can happen that we get confused when you give us a canonical before the rendered version, after the rendered version. It is unlikely. I say that again because I know that there will be tweets and blog posts about this later. It is unlikely that this happens, but it can happen. It's just a matter of giving us misleading or conflicting information might mean that we picked the wrong one. One way that I tried to investigate to see if that's happening is a new page. So about April 2nd is when the site switched over to mobile first index. And after that, a new page was published. And the user declared canonical in the URL election is the desktop URL. And I have a separate mobile site with end dot. And I'm suspecting that the canonical is the cause of this. So instead I would expect to see the end dot as the canonical. With end dot and mobile friendly, sorry, mobile first indexing, there's like lots of variables in the error. It's hard to pin that down, but it could be. I guess what I was trying to say is that is Search Console or can I use Search Console URL inspection as an indicator if there is confusion regarding the canonical? Yeah. Okay. Thanks. You're welcome. All right. We have lots of questions through YouTube today. That's great. Is it a problem to return a robot no index in the HTTP header of JavaScript or CSS files? I know it's better if they're crawlable, but should they be indexable from an SEO point of view? I don't think it hurts. I don't see that much of a use for it because normally they don't get indexed. So I would say you can do it. I wouldn't, unless you are seeing a specific problem in that regard. I would not robots.txt block them. Different thing. I know that that's not in the question, but I'm saying this to make sure that no one gets this wrong. If your robots.txt, sorry, robots block JavaScript and CSS files from crawling, that might lead to problems in certain cases. So I would not do that. One more YouTube question. I use server with pure engine X and red is the CMS's WordPress, okay. Optimization optimizations are server level caching, may find native lazy loads, long form pages. Page speed score is 92. The loading speed components are mostly green with nothing going above 3.2 seconds, but cache your, so don't use cache. The cache colon URL thing is just a convenience feature. If it doesn't look right, that means nothing. Ignore cache. Cache is not a testing tool. It's not a testing tool. Don't use the testing tool. Search console inspect URL, that's a testing tool. Good. Feature shows HTML code where images are present, but cannot generate screenshot and throws an error each time trying to generate one. Tools that use head as Chromium also cannot generate screenshots and crash on throws. Honestly, I don't care about the screenshot. Look at the rendered HTML. Looks the way you expected. You're good. That's it. The screenshot is just a nice to have again and using head as Chromium as a testing tool, that's a nice thing on top of it, but that might crash for completely unrelated reasons. So I wouldn't worry too much about it. Smaller pages, images are loaded fine. Search console shows the HTML has the images URLs, generates screenshots and tools. Yeah, again, doesn't matter. It sounds like your website, like the long pages are just very long and they exceed memory limits and that's okay. That's not a problem. In indexing, we don't care. It's absolutely. As long as the rendered HTML looks good, you should be fine. Why is there such inconsistencies? Welcome to the world of software. Computers are terrible. Is it possible that if Googlebot and Chromium are glitching out visual render? No, no. This would not be counted against you. No. Does Googlebot have this Chromium support native lazy loading? Yes, it does. All right, then is it possible to not load scripts on specific pages if you do not use it there? For example, recaptures only used on the register page. Yeah, that is absolutely possible. The things you wanna look for is, or the term you wanna look for is code splitting. Why is there always a big difference in lighthouse score between desktop and mobile? Because mobile is a lot slower. The CPU is startled because mobile processors are very different from desktop processors, both architecture-wise and performance-wise. So mobile is kind of like the lowest common denominator, and I would watch more for mobile than for desktop if I were you because mobile devices usually are not as powerful as desktop devices are. And one last question before I go back to the audience, we want to improve the load time of our pages. We implemented lazy loading with a placeholder as it is advised by Google guidelines, which Google guidelines. But okay, my issues are we're calling Google to crawl the page. First, Google does not render the screenshot view, that does not have any images in the screenshot view. The screenshot view doesn't matter as much. The rendered HTML is more important actually. The source of the images in the rendered HTML, aha, are still displayed as placeholder images. That very likely means that your lazy loading is not implemented correctly, and we are not seeing the actual image URLs. So you definitely want to look into that. And if we are rendering the placeholder URL, that is very likely an issue. Right, back to the audience. Any questions in the audience? If nobody else has questions, I can still. Yeah. Sure. So I'm asking about intrusive interstitials. And for starters, there's some documentation about mobile obtrusive or intrusive interstitials. I'm asking about desktop. Does desktop affect at all your ranking? Obviously, user experience, it can have effect, but I'm wondering if a page would get devalued on desktop. That's a ranking questions and I don't really answer ranking questions. Gotcha. So maybe the question that I do have regarding this does touch on JavaScript a bit and maybe you can help out. I'm wondering about, let's say you have a privacy policy like in California, you need the privacy policy. So that's a full page. And I'm wondering just in the background, how does Google know that this is a privacy policy and that it's okay as opposed to something that's more advertising or promotion related? I guess it depends a little bit on how your interstitial looks like. I think if it blocks the entire page, it's probably not fantastic if it's a pop-up or like a pop-over kind of thing, like a cookie banner or whatever, it's probably better. But that's actually a question that is not really with me. That's probably more for the general office hours with John. Okay, I'll bring it up. Awesome. Thanks. You're welcome. And I see that someone submitted something into chat that is also submitted on YouTube, but I'll take it anyway. Since rendering of widgets components via JavaScript are considered not useful for SEO, but developers are always happy in doing more rendering some client-side JavaScript as it helps in reducing there's like random notation in here. JavaScript as it helps in reducing the page load time with a big margin, what? But ever since ever going Googlebot has already been announced, so it is being used seeing the much updated version of Chrome as a result. We'll be able to see the JavaScript Ajax just an item. So will the widgets rendered by JavaScript? Oh my God. I don't know what you mean by widgets. If it's content that is put in the page by client-side JavaScript, we'll probably see it and then we'll probably also use it. So yeah, I mean, we are running the evergreen Googlebot. There's no problem with client-side rendering per se. If it's in the rendered HTML, we can use it. Depends a little bit on what you mean with widgets and visualization. Not 100% sure what that means. Right. Do you have any current documentation with recommendations for processes and tools to use for how SEOs should go about diagnosing issues with JavaScript-based websites? Yes, we do. If you go to developers.google.com slash search, then click on guides. There's an entire section on JavaScript. And my favorite one is go.gle slash js. Actually, now I have to see if, what was it? go.gle slash js.seo, js dash seo dash base. Screw it. I'll just post it in the chat. And actually, I'm not in the chat, but under the question. There we go. So if you go to developers.google.com slash search, you'll see our guides multiple on JavaScript SEO. And they are pretty much up to date because I keep them up to date. Some websites use different approaches or user behavior for desktop, mobile, and AMP. Uh-huh. On m.web, browsing user-layered approach, what is a layered approach? On click, a page layer opens with may lesser content against web version. OK. On desktop, regular click to URL approach. Redirects regular web page. On AMP, again, maybe click to URL since AMP doesn't give flexibility to do so. Will this be a not recommended or a good practice? I think this sounds more complicated than it's worth. I wouldn't do it. It's not per se bad. It's just it invites problems. It's more complicated. Like, the possible downside is much bigger than the possible upside of it, so I wouldn't do it. Um, that's Kieran's question that we answered earlier. That's Gautam's question that I tried to answer earlier. And then that's the questions for this. I know that last week we skipped, so I'll have a look at what was submitted last week. Our client has a website built on WordPress where he's using a very JS-dependent theme. Basically, after I disabled JavaScript, the website itself stops working, and there's almost no content in it. Is this a huge problem from SEO point of view? Is there something we can do other than switching themes of the website and therefore rebuilding it? It could be a problem. It doesn't have to be a problem. If you are seeing issues with the site being indexed and showing up in Google, then this might be the reason, because that sounds like it's less robust than it could be. But then again, if it works fine, then I wouldn't fix it, because fixing something that isn't broken usually means you're actually breaking it. However, I think reducing the dependence on JavaScript is always useful. So I would probably actually switch themes or at least understand why there is so much JavaScript and what this JavaScript does, and try to weed out the JavaScript that isn't absolutely essential. But that in itself is a lot of work as well. So you have to decide if the work invested there is worth it. And if it's not broken, I wouldn't fix it, because it's not broken. I recently have a client that had an amazing first input delay score, but terrible time to interactive and terrible total blocking time. How can this happen? I suppose when the JavaScript exploded overall, but split into smaller bundles, it might cause this, but not sure this is the cause. Also, if I have amazing first input delay, we still need to care about that time to interactive and time, total blocking time. That's a tricky one, because I'm not 100% sure how TTI and TBT are calculated these days. I think what I could imagine is that something does block the main thread in certain intervals, and that we are not picking this up when calculating the FID. And then it's one of these cases where measuring these things automatically is just really hard, and you have to see how it actually looks for a real user. And I would assume that if your first input delay is pretty low, and the user has an interactive page, then TTI and TBT don't, none of these metrics make sense when the real user experience is actually pretty good. Hypothetically, in a perfect world, that would never happen. In the perfect world, our metrics would reflect 100% what the user actually experiences, but surprise, surprise, we don't live in a perfect world, and these metrics are sometimes just off. But that's something that I would ask the Lighthouse team or open a bug in Lighthouse with the sample URL, because it sounds like an edge case that isn't quite usual or quite frequently happening, or maybe they know something that I don't know. But that's what I would think from the way that I rationalize about these metrics that this is an interesting edge case. Then we had the load event question, I answered that. If nothing can be painted before CSS is downloaded and the CSS object model is constructed, how can flash of unstyled content logically happen? Because things can be painted before the CSS object model is done. The reason for that is that the browser has a default style sheet, it has a deep, like if you don't specify any styles and you have like headline and the paragraph and the button and the link, all of these things have a default style, which is kind of unstyled content. I mean, you get like a sans font from the system and headlines are big and black and then links are blue and underlined and stuff like that. That is what I would consider a flash of unstyled content if it takes too long to actually get the resource from the server to actually start loading your CSS. That's why it's suggested to prevent that from happening by inlining the critical styles. So everything that is very, very layout critical, like how large our headlines, how roughly do our paragraphs look like, all this kind of stuff. So that the moment it starts parsing the HTML, it parses the inline CSS for the critical styles and then it continues parsing the actual content. So when it constructs the contents, it can automatically link that to the CSS object model and have the actual styles rather than like the default styles. So that's how that works. The DOM can start rendering before the CSS is loaded, hypothetically. All right, questions from the audience? Oh, few questions in the chat. All right, let's see. Do JavaScript websites consume additional crawl budget compared to a non-JS website with a similar number of pages? Do the non-JavaScript websites have an advantage over JavaScript websites in terms of crawl budget? Maybe is the answer to that. I say maybe because I don't wanna say it depends so often. It does depend. Assuming that you have a static website that has let's say five HTML pages and each of these five HTML pages has one image inside and one style sheet is like the same across all the pages. So like you have a style CSS that is loaded on all of these pages, all of these five HTML pages, and then you have five different images on each of these five HTML pages and they're static and there's no JavaScript involved. Then what would happen is we would do five requests for the HTML files. We would do one request for the CSS file because we cache it. So we request the first HTML file we request. We also request the image and we request the CSS file. We cache the image, we cache the CSS file. So when we request the second HTML file which loads the same CSS file that we cached here, we're not gonna request it again. We do request the other image because it's a different image. So okay, so that would mean we have five HTML files, we have five image files. So that's 10 requests. And then we have one style CSS file. That's the 11th request. So that these five pages would cause 11 requests which is kind of what your crawl budget is or affects. If you have a JavaScript in there that adds some funky functionality and it's the same JavaScript on all of these pages or three of these pages have the same JavaScript. The other two doesn't even load any JavaScript. Then the same thing with the CSS would happen. If all five HTML pages have the same JavaScript applied to them and it doesn't make any additional network requests, then we would download that JavaScript file, we would cache it and then the other pages would just use the cached version of that. If this JavaScript however does network requests, API requests, loading additional images, whatever, these requests also count against the crawl budget. But let's say you have a JavaScript that loads, I don't know, loads man, a counter, like a visitor counter from a network database on an API or whatever. It makes an API call, it makes the same API call on all of these pages. Again, we would make this API call once and then cache the result for the other pages. So it does have impact on your crawl budget, but it doesn't automatically mean that you have a problem. Honestly, most pages, unless most sites unless they are like sites with like tens of millions of URLs or sites that have a really bad server don't really hit this problem. So I wouldn't say that JavaScript has a huge impact on crawl budget to be honest, it can have a bit of an impact on crawl budget, but I would say it's not as relevant as people might think it is. Next question, if the website is completely blocked with no possible user engagement when JavaScript is disabled and if we display a message, please enable JavaScript. Yeah, that's kind of bad. I mean, not for SEO necessarily, if you say like, oh, you don't have JavaScript enabled and screw you, but it just wraps me the wrong way, the sense of if JavaScript goes wrong and JavaScript is more likely to go wrong than HTML downloads or CSS downloads because these things can be starting to have an impact as they download, whereas JavaScript has to be fully downloaded, then parsed and then executed. It's just more potential for things going wrong. It's not a problem per se. It also isn't exactly great for the user, especially if they decide to browse without JavaScript or there is a problem with your JavaScript. I wouldn't fix it if you don't experience problems or bad feedback from users, but if I were to build a website today, I wouldn't build it that way, I think. We used to do that in 2012 or something. I remember that was like the default thing to do and it felt wrong back then and it does feel wrong today if you ask me, but there's no inherent SEO downside or any inherent problem with it from Google's perspective, at least. Why field data and lab data have differences for page speed? Well, surprise, they are not the same thing. Field data is coming from real users, whereas lab data comes from a quite strong machine with probably good internet from somewhere around the world. So you might not see the same results if the lab data is from, I don't know, Mountain View or actually, let's make an example. If I run my server here in Switzerland and my lab data comes from Switzerland, then that's gonna be really fast, like we're gonna have a fantastic network connection in between the two. If the lab data is gathered on my MacBook here with has, I don't know how many cores and how much memory and I don't even, like it has quite a bit of power under the hood and it has a fantastic network connection. It's also a very short network connection if the like Zurich or Switzerland is a small country. So the time, the physical time it takes to go to the server and the other end of Switzerland and come back is minimal. So my lab data would look fantastic if my users are actually in the US and they are in rural US where they only have mobile connections and they might not be on a fancy latest generation laptop but they might have a laptop that has, I don't know, seen the likes of Windows XP or something. Like it's an older laptop. Then this field data wouldn't look as great because A, the data has to travel across the Atlantic and back. Well, actually it comes from the other side of the Atlantic, it goes back over the Atlantic. That takes longer. Their connection is probably spotty and slow. That makes everything slower. And then their laptop isn't very fast and fancy. So executing all my JavaScript is very likely also going to be slower. In that case, my lab data looks amazing. And then my field data, because my users are sitting in the other end of the world, looks terrible. That's what happens because the lab data is only synthetic. It's only a approximation of what happens in the real world. And then you have field data, which surprisingly gives you the actual thing that people are experiencing. So if you know that you are serving users on slow old phones or on rural spotty internet connections, this is what happens. This is where the field data looks a lot worse than what you see in lab data. And that's a general problem. Developers usually work with fantastic internet connections on modern laptops. And then the real world user is on an old iPhone 2 somewhere in rural northern Germany where you have edge internet connection if you are lucky. And then everything looks terrible for them. And you're like, I don't understand why our users are complaining that everything is slow. It's it loads within a second for us. It's like, yeah, for you, but not for your actual users. So again, field data is probably a better indicator for how real users are experiencing your website than lab data. Because lab data is literally just someone's server making a request to your thing. And if that server happens to be quite beefy, then you get pretty good looking numbers, but then the real world isn't as beefy and nice. All right, do we have any other questions? I've got one if that's okay, Martin. Yeah, sure. Yeah, I watched your thing yesterday with only about the render I say that's very good. You mentioned that you'll look at the render tree rather than the, you know, in general. Is that something most people would actually need to worry about? And if so, is there something that we can look at from a Google perspective other than maybe just a screenshot in mobile friendly? So, yeah, that's a good question. So what I said yesterday in the only webinar is that we do use the render tree rather than painting the actual pixels. But that's not something that you normally need to worry about unless there are bigger problems that culminate in a problem with layouting. Normally it is enough to look at the rendered HTML to see if your content is there. If the content roughly looks in a real browser like you would expect it to look like and then you should be fine. There are very rare cases where everything on a website is so screwed up. And I literally mean like everything is screwed up that the layouting becomes an issue that like topples over our ability to make guesswork happen. But if Google search needs to guess things on your website like, is this the main content? I don't know because everything is in one large div. Then you are already on a very, very dark path and should definitely backtrack. So normally you don't have to worry about this. It's an implementation detail. It's quite geeky to begin with and no one has to understand this or worry about this realistically. Awesome. More questions from the audience? You can also use the chat. Chat is perfectly fine. I'm scrolling down. Oh yeah, here we go. In Google search console, we see this under URL inspection. Crawled page, more info, page resources, 36 out of the 73 couldn't be loaded. Some have a label other error. How can we debug this error further? Ah, you can't really. That's the unfortunate thing here. Two things. First thing, a resource not loaded isn't per se a problem. It just means that we didn't load it. If you have things like Google Analytics on the page, we are very likely not loading this one because it doesn't really add benefit to our rendering. So a resource not loaded isn't a problem per se. The other error is the most dreadful possible error because it means something that you don't really have an option to act on has happened and most likely what happens. So most of the time other error means we don't want to let you wait for an hour until we actually get a spot to download this resource through our infrastructure. So we are cutting it short here. I know that's not fantastic, but that's a trade-off that we have to do with the testing tools. The indexing infrastructure can afford to just wait for things. We also cache things heavily. Both of these things are not available or not feasible in a testing tool, right? We want to show you the latest thing according to what is on your page. So we are not using caching. So we have to request everything. The way that we are building the testing tools is we're trying to be as close as possible to the actual indexing infrastructure, which means we're using the indexing infrastructure. However, the way the indexing infrastructure is designed is for background batch usage. So like Googlebot basically has infinite amount of time to wait for things, right? We can hypothetically say like download this thing and then it's okay if that download is only, like if this is in a queue for an hour or something and then it actually gets downloaded. That's fine for indexing because it doesn't really matter. The rest of the pipeline will run as the download has happened. We can't let you wait an hour in front of the mobile friendly test until we wait for actually getting this resource. Images are very likely not necessary for the actual rendered HTML to show up correctly. It's just for the screenshot. So images are the first to actually get kicked out really. So as long as it's images, as you say, like most of them or some of them are images, doesn't matter. We are not really downloading the images in indexing either as these for main web crawling. We don't have to do that because we are only interested in the URL of the image really and the out text and the context that the image is in rather than the actual image pixel data. So if that doesn't show up on the screenshot, that doesn't mean much. As long as the image URL is correct in the rendered HTML, you're good. On slow connections, I'm getting more blocking time due to AdSense ad. So what can we do? I would ask the ads team. I don't know about AdSense. There's probably something that they allow you to do to make things faster, but I don't know. So I would ask the AdSense folks for this. All right. Any other questions? Because I think we have exhausted our YouTube questions. At least I'm not seeing any others. No, answer that. Not going to answer that one. Yeah. All right. Last chance for questions. Five, four, three, two, one. If there are no further questions, then I'd like to thank you all for joining the recording. Thank you all for watching this later on YouTube. And thanks for being fantastic, build cool stuff on the web and stay safe, stay healthy. Bye-bye. Thanks for joining.