JavaScript SEO office hours October 14th, 2020

Key Takeaways

all right hello and welcome everybody to the javascript seo office hours after a bit of a break i'm back and i hope to do these now on a bi-weekly basis or fortnightly basis as the british would probably say um so every 14 days there will be an opportunity and i'll try to switch the different time zones so that we have both apac friendly hours as well as emea america's 20 hours too sweet so let's go through the questions that were submitted on youtube uh blackcat go asks how does google's web rendering service handle course so cross-origin resource sharing does it inherit the policies of the chromium version in use yes uh it is also bound by the course principles and apis and uh headers so that means that if you have course requests or cross-origin requests so requests to another subdomain or another origin you want to make sure that these are allowed as per the specification as well then we have monsev asking two questions actually the first one is it's safe from an seo perspective that next view store the duplicated data in a script tag yeah that's that's fine that's not an issue and the same question about view server side rendering hydration and seo is it better to do lazy hydration which means hydrate the content or refill the content that you sent from the server as well just before the user reached the components to decrease time to interactive um it's also a user experience question and i think it would be good to lazy hydrate but if that causes problems or if you notice in the testing tools that your content doesn't show up in the rendered html then that means that lazy hydration does not work with googlebot very well i haven't really tested that try it out and if it does not work then i would not hydrate lazily but hypothetically the content should be there and from the server side rendered version anyway so you should be fine but definitely test everything and also things can change over time so testing is always the best uh possible strategy here also if there is a popular sorry caillou asks if there is a popular resource like a popular javascript library from a wordpress plugin or something from node.js can google cache it in a single place to render pages from different domains so in the wordpress plugin example let's say you have a local link from my javascript resource and that's broken can google still render the webpage because it's a popular resource and therefore cached from other pages no we cannot do that um for the simple reason that that would allow cash poisoning and that's a very very risky vulnerability so what you can do is you can include them from cdns if you trust these cdns or public places where these are might be hosted then you can use those versions instead of your version and we might be able to use them from the cache on the other hand you don't really have to worry about it because popular or not our cache is very aggressive so we are generally over caching with under caching so if something is broken momentarily that normally isn't the problem because we're not fetching it in every render anyways in the first place um but there is no such thing as oh yeah jquery is broken on your site so we'll just fetch it from somewhere else um the only situation where i could see that as potentially feasible is if you have a subsurface sub resource ref what's what's it called in resource integrity token uh in your code and even then it is tricky because there's so many different versions so we are not implementing that really um but again don't worry about it normally we are over caching rather than under caching so even if you have a momentarily broken uh link to a resource from you um or if you're from your site then that's not not necessarily a problem also we retry renders if that is necessary so don't worry too much about so the follow-up question is from what i understand the caching is more or less uh domain based so yeah yeah we'll cache everything my domain needs even if i request the results from a cdn or from other well no because then we would potentially be able to catch that on that domain as well okay yeah it makes sense that made yeah that makes that possible and i believe the follow up question that will come with that is how does that affect crowd budget and everything so let's say i fetch the results from a different source from different procedure does that have impact micro budgets or their crowd budget i'm not 100 sure to be honest because i haven't really thought about this but i think it does not affect your crawl budget or at least it doesn't do so directly but then again it might do indirectly um i wouldn't worry about it too much because i assume that you're not having thousands of resources that you need to download i hope you don't i hope so too thanks you're welcome um hey martin follow-up question about that resource availability right yes so roc and a lot of url inspector tests a high level of the resources not being available that leads me to ask does google do a fresh fresh fetch for each resource when you do a url inspection test or is that really representative of the availability rate you're probably mostly riffing off of the other error that you might see in the testing tools right is that what you're getting or is that uh does that look different be in the testing tools uh what i'm referring to is when you go into the more info and you look at resource availability and you know of a page called 150 i've got some rather complex folks i've worked with who have 104 of those missing unavailable and some of them i've seen from being dependencies so their jquery resource didn't respond that was unavailable and then the five scripts executed off of that also listed isn't available because domino effect some periods if those tests are actually representative of what googlebot is seeing or just an isolated individual we tried to fetch everything right so okay the general answer to that is um unlike the actual indexing runs the test for the obvious reasons uh actually does run um a fresh fetch because we want to give you the opportunity to test the latest version of everything that you've got which means that we are definitely bypassing the cache so the testing tools do bypass cache uh which is not something that happens in the in the actual crawls on the actual um indexing runs i know that that sometimes causes a few confusion or confusing moments but when you say like resource available do you mean basically you go in the url inspection tool for instance you go to page resources and then you see like some resources can't be loaded right uh yes so right there's uh the screenshot the rendered html the more info tab it says x out of x resources unavailable and you look through those so that's the piece i'm hearing about um if google has a proper copy of that resource at any given point it sounds like that will behave differently than the test you can exactly you can double check this uh if you look at the crawled page instead of the live test that you do you would see how that looks like in terms of the page resource and not everything that is in there is necessarily a problem sometimes other error just means that we didn't deem this resource to be very important that happens specifically with images that are usually skipped and fetching because we don't really have to fetch the images uh for some of the stuff and um or most of the idea being image is static so once you have it you're not going to worry about grabbing it again yeah but right now i mean we are we are updating the images it's just that for the indexing run that doesn't necessarily report well because the image index is a separate entity anyway okay um so generally speaking you shouldn't need to worry too much about a resource not showing up in the live test because we are skipping the cache but you still want to make sure that you have a look at the crawled page to make sure that all the content that you expect shows up there if that doesn't show up and you see a related resource issue let's say like some content is drawn from an api endpoint that is fetched by your app.js file and then that app.js file shows up as failed to load in the crawled page report so again you basically click view crawl page and then you get more info page resources if something shows up there is an error and you see the matching missing content in the rendered html to see the the content that should be loaded by this resource missing then that's a strong hint for something going wrong in terms of us not being able to cache it or maybe we cached it in the past and we couldn't refresh the cache or the cache has expired um but generally speaking yes the live test tools all of them so that's the amp test the rich results test the mobile friendly test and the live testing google search console they skip the cache that's correct thank you you're welcome all right i see that we are through the youtube questions and uh that means that i'm opening up the questions to the live audience all right martin i have another question then sure this is based on something i've been seeing on the forum so let's say i have uh i want to have a lighter version of my website for mobile and i don't want to show all the resources on the mobile page uh i don't know maybe i don't want to show a carousel because it takes too much space one way to do that is to use css display none but that will just the the resource will be fetch anyway right so what do you yeah i think so as well but i'm not sure so do you have any suggestions on what do you suggest server side rendering what's what would be the best thing to do to there's a bunch of different ways of going about having a mobile friendly version of your site um and and not loading resources one way is that if it's a component that is dynamically inserted um like it sounds like that uh if you say like additional resources are being fetched um then what you could do is you could do conditional fetching based on the media selector so you can say like oh this is a small screen and i think on small screens this carousel does not make sense uh that's one way of doing it that is possible you can also just serve a side render i mean you would also always have to find a way to to adapt to things but if you serve a site render then you should not necessarily have to fetch much in terms of resources because these resources will be inlined into the page as at least the html will be there it will still load the images of course um what you can do is if especially if it's an image carousel specifically you can lazy load the images and then display none would mean that the images aren't being loaded because they are never in the viewport um that is an option for this as well so you have different options to make your design responsive to the different screen sizes and and you have to try them out to see what works best for your approach because they have for from a search perspective it doesn't really matter which one you go with but i think from a user experience point of view as well as from an implementation point of view that will very likely be the the bigger bits to understand what works best or what doesn't work so great because some might be easier for instance the css display none that's really easy to implement i guess whereas a dynamic switch depending on the media query might not be as easy to implement depending on the solutions being used but it might be more effective as it would take out the content entirely if the screen size doesn't warrant for displaying it um yeah so and of course you are suggesting that this should be dynamic based on the screen size not on user agent or any other way don't base it on user agent yeah yeah i don't think i saw the anyone much later people using this with user agent but then i was i was thinking now for the core web vitals uh scores when they are testing for at least in lighthouse if they are tested for mobile and for desktop the only thing that's changing there is the screen size when they are doing so yeah okay makes sense thanks you're welcome good to have so many questions in the first one after the longer break more questions anyone else having a question oh yeah is is there any difference between the mobile friendly testing tool and the rich results test and the url inspection test big question i know there is but in terms of the fire mic that they use um specifically we had someone come in the forum it was very weird case of a site that would render the html in the mobile friendly testing tool but with in the rich results test and from what they were reporting to us it wouldn't end your own inspection either um and apparently you know that seemed to reflect more the what they were actually getting um but is there anything around that the only thing that i could think why the mobile friendly test was possibly working is there's something about a viewport thing because i attempt to paint but i couldn't really see anything but there's nothing kind of too different about those other than that i suppose no so internally that's a very good question actually i think i saw the thread it's like a react page that has uh suspected that it's reacting i don't think i did see some one guy the other day who reacted but i think that was basically it was just incredibly slow he was just turning out it was legitimately um so internally all of these are uh called the single url inspection tools or sweet or suit depending on yeah i think suit is how you properly pronounce that then s-u-i-t is the internal acronym it all goes to the same pipeline obviously then there are a few changes for instance the rich results test allows you to specify if you want mobile or not whereas the mobile friendly test always opts for the mobile route uh the url inspection tool goes for if the page is mobile first index then it goes for the mobile route if it is not then it goes for the desktop route but you can't switch that so there might be small issues or small differences especially if it's a non-mfi so not mobile first index page it might go through the desktop route and then you can get different results in the rich results test and in the um mobile friendly test because those go the the mobile route instead so there's like a small a few small different code paths that could be triggered hypothetically but it is the same infrastructure and so far as you say like most of the times i've seen this either with intermittent errors on which resources are fetched because we are bypassing the cache then different resources might time out or might fail to to complete their requests in time um and then you might get different results in one even in the same tool i think the the thread that i looked at at least uh they used the same tools multiple times and they got like yeah the url inspection tool doesn't work but the mobile friendly test does and the rich result says also doesn't work and then the next time they post it was like the url inspection tool doesn't work but the mobile first indexing tool doesn't and the rich results test does and it's basically like it was different combinations of the three where it worked and it didn't i'm like well if you're running it through the same three tools different multiple times and you get different results then that takes tells you that there's something intermittently wrong and not necessarily um a fundamental issue um must be very educated it was consistent it was consistent with no page results loading errors at all it was consistently failed in rich results and worked in is that the mft that you escalated recently uh yes i think i might have escalated it because that is an issue on my on my desk to find out i just didn't have the time yet but it looks like it might happen either tomorrow or on friday that i can look into it so that's fun that's timely um so yeah just just for the general population and public out there uh if you are seeing a fundamental issue that can't be solved in the webmaster forum then sometimes these issues get escalated through googlers who work on the forum and then these are being investigated i can't give you please don't send me direct messages or something because i can't investigate every page out there but if it looks like this might be something that where the the public channels fail to support your case and give you support then we might look into it as a potential general larger issue and if that is true then we will fix that larger issue but if it's just your site then we'll find a way to give you more public feedback so that the next person running into the exact same situation sees that forum fed and can use that as a reference point so that's what i'm i'll be doing later this week as well it's an interesting case it's a curious case when when i saw when i saw that i was like interesting it goes to the same pipeline how is this different we'll find out thanks for the question that's a really good question more questions okay so i'll give it a 5 4 for your questions there we go oh multiple people jump so in in thinking about how to approach uh understanding rendering and resource availability better aside from doing the manual breakdown of that render html associating it with the script that creates that is there another way to figure out if a resource has been persistently unavailable to google on that script which generates content is problematic that's not really easy to do that especially over time as the um the the crawled page is basically just a snapshot um i mean in the end if you see uh your page for instance dropping out of the index every now and then and dropping back in that's something that you probably want to investigate in general uh if that is an issue with um with intermittent resource issues generally these issues are really really rare because as i said we have a cache we have a very aggressive cache so even if your server gives us the script once and then doesn't give it out for the next month you should not see intermittent resource issues this is more a problem with a live test than a real issue um is there an index coverage type that we should look for at moving from indexed and submitted or whatever not not really not really as long as it is indexed and you want it indexed then i think that's fine um i don't think you can monitor for anything specific there except for it landing in the error category or in the excluded category if a page that you really care for lands in the excluded category every now and then then that's probably something where you want to look into it doesn't mean that it's a rendering problem though would crawl anomaly be the closest uh rejection or excluded type to indicate that not really either because koala normally normally is not a rendering issue but an issue in crawling already also can be pretty much anything that's a really broad category i wouldn't say there is a clear category or there are candidates where you would need to worry about rendering more than others couldn't think of any because rendering is more or less a transparent part of indexing so it's not that we report a very specific error back because we are retrying errors so no again normally you should never run into this problem in real life where a resource uh is temporarily not available to us unless of course you 404 a resource and then the page drops out because it's now basically empty or baron of content but i wouldn't know how you would spot this in search console patterns thank you you're welcome i'm sorry that i don't have a better answer for this um probably crawled currently not indexed might might point at that problem um if it is something with the sometimes it might affect the the canonical if the canonical on the html looks different than from what is in the in the rendered version then that might come out as like alternate page with proper canonical tag or duplicate without user selected canonical but i wouldn't say that these are inherently signals that that's a rendering problem they might be but they don't have to be that's as good as i can can do at this point damn martin the live tests in the url inspection 2 use the same pipeline as the testing tools the which results tests yeah yeah and it doesn't take up caching when you do the live test right yeah yeah okay but uh i have another question related to lazy loading native lazy loading as an attribute of image i was looking here in can i use and i noticed that it doesn't run on safari yet it's an experimental feature on safari so maybe if i implement that on a web page it could cause some slowness in real-time measurements right uh i know that google bot uses evergreen chrome but if i'm looking at the the field measurements in search console for speed and things like that maybe uh maybe the using native lazy loading will slow down we would expect to slow down for ios users or macos users something like that well i mean yeah yeah exactly if you have a fallback then that's the best you can do if you don't have a fallback then it wouldn't slow it down but it would be slower than in chrome where native lazy loading is implemented yeah that's true yeah so it should it should appear on the on the field testing results on search console what do you think i think we are mostly sourcing them from the chrome usability uh report so i don't think they show up unless ios safari does play into this because when you're running a chrome on ios you are effectively running safari but i'm not sure if that is the case i'm not sure if we can somehow i don't know uh it might be all right in any case tests on the real thing right definitely test okay all right more questions all right five four three two [Music] one awesome that was fantastic thank you so much everyone for submitting your questions on youtube as well as everyone who joined uh tonight or this morning or this evening or this afternoon depending on where you all are based it has been huge fun and again as i said at the beginning we will do these uh every two weeks so definitely keep your eyes peeled for the post for the next episodes question time where you can post um your questions and the link to the hangouts if you want to join next the next edition i wasn't saying like next week's hangout but it's not in a week it's the next the week after next week's hangout wow okay it's quite late here i'm sorry uh in that case thank you very much everyone who's watching uh have a great time stay safe stay healthy and bye bye bye bye bye thank you thank you very much for joining