 All right, welcome everyone to the first episode of Search Off the Record, a podcast that we're trying out a little bit to see how we can bring across some more information from behind the scenes from the Google search side. So my name is John Mueller. I'm a webmaster trends analyst or search relations person at Google, together with Gary and Martin, who are also part of the search relations team. And our plan is to talk a little bit about how things are working behind the scenes, maybe to have some fun along the way as well. So what's been happening on your side, Gary? Nothing, really? Nothing? OK, Martin, anything happening on your side? Yeah, actually, I'm really happy that we are recording the podcast now, even though we don't have pop filters because we ordered them, but then the supplier couldn't meet the deadline. So this pop cast is probably going to pop a little more. Pop. Pop. OK, cool. On the bright side, I've never said marry pop in so often. That pops. Very nice pop culture reference. So yeah, I'm wondering when we get a follow up on the pop filter situation so that we hopefully have pop filters for the next episode. Speaking of following things, I know that recently, yeah, there was a little bit of a conversation happening on Twitter, Gary. No? I mean, no follow is always a topic in one part of the world or the internet. And it's fine. It's a big topic. It's something that many people are passionate about for various reasons. And we are asked about it quite a bit. And we had two dates announced, not the fruit, but the unit of measurement of time. And one was, I think, September 1, which was when we could have potentially used no follow in our ranking algorithms. And then the second date was March 1, I think, which was when we allowed ourselves to use no follow in crawling and indexing. And the question typically is whether we started using any of those or in any of those fields. And we don't really have anything to announce still. We are working on a few things that will be helpful, I think, for the web and also probably helpful for webmasters. Think along the lines of what would be a good example. Like, you have those sites that can, for example, redirect to the new site when they move. And they just leave up a link saying that visit us on our new site. And often those links are no followed. And it would be very helpful, for example, for us to follow those links and essentially help webmasters have their new site discovered much faster. And we are also thinking about other things, really. But yeah, I really don't want to name those things because they might actually not happen at all. And it might just turn out bad. But if you think about it, those no follow links could be very, very helpful for discovering malicious sites, for example, the ones that force downloads and whatnot or spam even, I guess. So yeah, I think no follow links could be helpful, but we just don't have anything yet to say about how we use them. But you're trying things out? Yes. I am actually working on, I think, three projects, like sub projects or whatever, trying to see if it would make sense to actually use no follow in those cases. And I know that one of our ranking leads actually asked us to, if we get to launch with one of the projects, then we should announce it publicly. So if we are going to launch with at least one of these things, then you are going to know about it publicly because we kind of have to announce it. Cool. It sounds like this is more to, on the one hand, catch errors that people are making on the website and to be able to understand the problematic parts of the web a little bit better and less something that people will need to optimize. If you have an existing website, you don't need to think about this if you're doing those parts correct already, right? Exactly. With the changes that we announced, you already don't have to do anything. You can help us with the new rail attributes if you want to. And those could be helpful for training machine learning models. For example, I'm definitely not saying that we are doing that, but it could be helpful. But you really don't have to do anything. This was always an optional thing for everybody. It's good to see that people still adopted them, like Ralph Sponsored is used on millions of sites already, even though we just said that, like, really, you don't have to, only if you want to. And they were just like, yeah, sure, why not? So it's kind of cool. It was an exciting project. Cool. Yeah, I think what I find fascinating about the NoFollow changes is that we introduced these in response to things that we found on the web, which were a bit problematic. And now the web has evolved. And we've been able to kind of change these things as well, because the rest of the web has been moving forwards at such a nice pace. So I think that's really cool. Yeah. The other thing that I found interesting when we were working with the leads on the NoFollow change and the initial announcement was that I briefly talked to other search engines about it. And they were pretty much all of them were like, well, we've been doing this for a very long time. And it turned out that we were the only ones who don't do it. That was kind of funny. Oh, man. OK. And I'm starting a blog. A new blog. A cooking blog. A blog. Oh, you're creating a site. OK, cool. I am creating a site and then I will know how to rank best. Wow. Oh, my gosh. Gary's becoming a webmaster. No, I'm becoming an MSEO. Oh, my God. No way. Well, both. So it's spaghetti experience optimizer. Yes, Japanese spaghetti optimizer. Oh, God. You know, it's very rude when you call those noodles spaghetti. Just FYI. It's kind of offensive. Oh, OK. Just FYI. Oh, my goodness. OK, fine. Looking forward to your non-spaghetti recipes. Thank you. I was talking to Lizzie. Lizzie Haraway, who's our tech writer on our team. And she brought up that we could just test the structure data that we published on the blog, like recipe markup and whatnot. And basically, I would just give her access to whatever generates the HTML. And then she can go nuts on it and see what happens, whether I get better rankings or not. We shall see. That's cool. That'd be cool. Yeah. I think it's always tricky with a lot of these recommendations that we give to people. We obviously see how some sites are implementing them. But it would be really nice to be able to try them out ourselves so that we can talk a little bit more from a practical point of view rather than from a purely theoretical point of view. Yeah. So that'd be cool. Yeah. I mean, I did that recently with the tests for figuring out how we are parsing structure data that was generated by JavaScript. And I think the things that I noticed and where the team went, oh, interesting, we should definitely practice a lot more of these things. OK. Yeah. So does it work? JavaScript with structured data? Yes. Yeah. Yeah. That works. There's documentation on the dev side for this. I will be talking a little bit more about that soon-ish. But all of it is documented. It just doesn't work in the structure data testing tool. But as long as you use the rich results test, for instance, or Search Console, it works fine. Cool. Is the discovery of the structure data delayed because first we have to render? Not really, because we're pretty much rendering any page anyways. And the render queue median time is like five seconds. So normally that isn't a significant delay. However, if you are talking about Google shopping, that is different because in the Google Merchant Center, they are trying to not render as long as they can. Like basically they look at the HTML first, and then only if they don't find the information they are looking for, only then they render. So if you are doing e-commerce, it is a little different. But for Search itself, that's not a problem. Interesting. Then you can make your site a JavaScript site, Gary. Single-page app with non-spaghetti recipes. You can write spaghetti code. No. Really no. I really don't like JavaScript. Sorry, Martin. Gary, how dare you? I'm actually not sorry. I demand a Japanese dessert. Sure. Come pick it up. Yes. Why don't you like JavaScript, Gary? Let it out. I think if I start letting it out, then suddenly this podcast becomes R rated. So I would rather not. I just don't like it really. Like I have the same thing with, for example, Go. I also don't like Go. You're just old school, Gary. I like C++. I can like Python. What? Yeah. Over Go. How dare you? Oh, yeah. How dare you? OK. But not Python 3. So you'll use tables in your site's design? I will only use tables. Tables. OK. Yeah. They are very good for ranking. I guess you have to put your dishes on tables anyway, right? Yeah. Putting this aside. OK. Putting it aside, moving forward fairly quickly, we launched a whole bunch of speed metrics. Hey. It seems like there are lots of these metrics out there. I don't know, Martin, can you give us a quick rundown on what's all involved with these new speed metrics? Ooh, OK. And just for the record, I would also appreciate that because I don't understand it. So it has been a longstanding ongoing effort to understand how to measure performance in the sense of performance for the user, right? So what is a good, fast website? What is a not-so-good, not-so-fast website from a user's perspective? Now, that is surprisingly hard because there are so many things that you can potentially look at. And the first thing we had like 10 years ago was to look at how fast does the server actually respond with the data. And that's not a good metric because we have a lot of websites that are not just a bunch of HTML and images and videos and whatnot that need to be transferred from the server to the client. But we also have situations where you deliver the initial HTML, you deliver a bunch of JavaScript, and then the JavaScript has to generate all the content. So the server responds within less than a second. The network has the data in, let's say, like 1.2 seconds. So the browser has everything it needs within 1.2 seconds, let's say. But the page is still blank because the JavaScript needs to be executed and needs to create all the content. And then that metric became relatively useless because the server response time didn't say anything about how fast the page is to the user. So then we looked at, OK, so maybe we can try to find out when do we start actually painting content. So when does the page that you see in your browser start to not be just a white window? That is what we call the first contentful paint. And that is definitely helpful. And that was what we used the last couple of years. But we figured that's not helpful either. Because when you start painting, let's say, like a little bit of text, but this website is about images and the images only pop in like five seconds later, then that's still a slow website. So that's not helpful either. So maybe we need to find out when most of the content is visible. So that's the largest contentful paint. Like what's the moment when most of the content is actually user consumable, visible to the user? That's helpful, but that's still not the entire picture. Because if it's not just a website like Wikipedia or even if it's just a website like Wikipedia, you want to probably also scroll and interact with the content. Like you click buttons, you click on links, you click on whatnot. And the fact that we paint this quickly on screen doesn't actually mean that you can interact with it. And you oftentimes see that like the website looks like it's there, you click on a link, nothing happens. You click again, you click again, you click again, and then after like five seconds, it actually does the thing that you did. Or there's like a drop down and you click on it and nothing happens. That's frustrating. So we needed to figure out how to measure that and expose that as a measurable metric. That is what the first input delay is for. So now we can tell when the website starts to become interactive for the user. That's great too. But then there's one more thing that is very, very annoying and it's my pet peeve to be annoyed about this. We have a website that shows you the thing you want and there is a link that you want to click on and you tap that link and then something else loads. Most of the time it's actually adds, but like sometimes it's also just like the image loads or something like that. And then the link moves down and something else is in the space where I clicked now and now I click on this completely unrelated thing because I didn't actually do anything. I tapped on something. It wasn't interactive at that point. And then when it becomes interactive there's different content there. And what happens then is that I click on something completely unrelated without actually wanting it and then I get taken to another page and I'm like, ah, I didn't wanna be here. Why did that happen? How did that happen? And that was very, very hard to find out or quantify as a metric. I mean, as a user you see it, you tap on something, it moves. You tap on something else that is in its place now. You get annoyed. But how do you measure that? How do you quantify that into a number or a time or something like that? And we recently did that as a new metric called cumulative layout shifting or shift. And the frustration or the challenge for webmasters was that as we developed these new metrics it became a little unclear what to look out for. There were so many different metrics. There was speed index at some point. There was first contentful paint, first meaningful paint. A bunch of metrics were designed to better understand and reflect what user performance looks like or website performance from a user's perspective looks like. And we have been changing our understanding of that quite irregularly. So it was relatively hard to figure out which metric should I actually be looking at at this point in time. So someone who has optimized for speed index which was a very old metric to model how performance from a user's perspective looks like, they would optimize for that and then find out once they have invested all the time to actually make their website appear fast in that metric that this metric was no longer used and that was frustrating to say the least. So we came up with this idea of coming up with core web vitals. So basically a set of metrics that is our best current understanding of what a measurably fast website looks like. And we understand that A, this is an ongoing process. We do see new things happen on the web and they shape the way that the web works differently which means that also you measure performance differently and we're still not fully understanding or quantifying the user performance perfectly. So we need to iterate on this on one hand. On the other hand, we want to give as clear as possible of a guidance to users and webmasters alike to figure out what is a fast and good website. So how do we reconcile this? On one hand, we need to iterate the metrics. On the other hand, we want a stable as possible metric set for users and webmasters to look for. And we came up with a core web vitals saying that we would update them roughly on a yearly basis and the first iteration of that is three metrics, the first input delay that I already discussed, the largest contentful pane that I discussed as well, and the cumulative layout shifting. These three metrics are basically the current model of what we consider a fast website or a measurably fast website. This isn't perfect, but this is the best we have at this point and we're gonna revisit this set of metrics next year and probably iterate on it as well, but we will communicate upfront before we make any changes. And we use these metrics to give developers guidance to say like, okay, my website is objectively set, measurably set fast or not so fast or terribly slow to then iterate on their own websites. We can also use these metrics in other places like Lighthouse uses it to score your website, PageSpeed Insights uses it. There's a Chrome extension that shows you how a website is doing in terms of these three metrics. There's a bunch of APIs in the browser that allow you to measure these things for yourself and maybe like log them or something. So there's a bunch of tooling for webmasters available now that helps them figure out how fast their website is in the eyes of a user and currently it's these three metrics. Cool. And if you were ever wondering if Martin can have an eight minute long monologue, yes, he can. I can, I could have spoken longer but I just wanted to be as clear as possible. As fast, I guess. We need four. I was about to jump in and just say something funny and I was like, no, let's see how long you can go on. Eight minutes is the current maximum. That was really cool. Okay, so on the one hand, like getting back to Gary's fascination about JavaScript. It sounds like a lot of this is based on websites that do fancy stuff in the browser. Would that be correct? Like if you have a static HTML site, does that mean like everything loads instantly and you can interact with it right away and nothing shifts around? Yeah, no, that's the thing, right? So like, of course, JavaScript is the biggest culprit here but you can also screw it up with HTML. So for instance, if you have super huge images that if you are a photographer, you probably want to upload the highest possible quality and then you just put these images in and you just make them look small in the browser but the browser has to actually download the full, I don't know, like 20 megapixel image which is like multiple floppy disks in size, then your website would probably be like... Why would I want to download floppy disks? Well, who downloads floppy disks, Martin? You would download... How old are you? You wouldn't download a car. I actually would. No, I think like floppy disks is just such an archaic medium at this point and it's such a reasonable size. And when I see like people are throwing 10 megabyte images on me and I'm like, that's like seven floppy disks. What are you doing? Because I remember the times where you would install a game and going like, insert floppy disk 12 out of 15. So yeah, I'm old. But still young, at heart. No, but yeah. So if you have like super huge images on your website and you force the browser to download them, then you might actually run into situations like the cumulative layout shift where the image isn't showing up yet. I click on a link and then the image loads and then somehow another link is in its place. And then I click on that accidentally. And so you can run into these problems without actually using JavaScript. It's just less likely. Cool. So Gary is like, if you're gonna put any photos on your blog, it sounds like you need to watch out for this too. And I guess if you don't measure those metrics, I'm sure Martin will run those tests for you. Lighthouse. I'll run all the lighthouse tests. Marking sucks. No, this is fantastic. Marking hates me. I don't. I really, really like you, Gary. And you don't like that. That's true. But I'm sure those non-spaghetti recipes will be good and fast. Like, will you make them so that they're fast to cook, not just fast to load? Or does the cooking speed not reflect quality? It's not a web vital yet. What? Like, just what? Gary, just cook spaghetti, but not write spaghetti code. You will be good. No. So how is life in kind of the pandemic times of corona? How is it treating you guys? Are you coping? Are you getting all your work done, working faster, more efficiently now that you don't have distractions like cooks that bring you food? Gary cooks. I don't bring food. You have to come here and pick it up. You have to come to Gary Will and pick up your own food. I'm actually cooking for, I think, seven people, plus Martin. Because I'm not people. Wow. Well, you're like in a unicorn or something. Oh. So why are you eating food for seven people, Gary? No, this is just OK. Just cheese. OK. I'm actually losing weight. Wow. OK. Yes, he is. Yeah, I saw a lot of your recipe photos on Twitter. They look really cool. It's not recipe photos. It's food photos. But sure, you don't see the recipes. OK, fine. I just saw the end result. On Twitter, it's always hard to judge. Like, does this just look good? Or is this actually something that will taste good? But I kind of trust you. It depends. Oh, no. That's actually interesting. And it depends. That's the easiest answer, as with many things in SEO, because now cooking is also SEO. So I have some experimental, like my father was a chef. And what we did in the kitchen was lots of experimentation because he had to experiment and we hated it. But I also do the same thing. And now I kind of understand his fascination with experimentation in the kitchen. And sometimes my food comes out pretty much inedible, even though I can't present pretty much anything really nice. And then other times, I just spend, like, five minutes on a dish, like, suga-chi-based soba, or suga-chi soba. And it doesn't take more than five minutes to make. And it tastes heavenly. So yeah, it depends. It depends. Oh my god. It's almost like you can use that for non-SEO answers as well. So awesome. Yeah, we should make a challenge. Use it depends more. I don't know. Martin, what do you think? I think it depends. But I think we can totally do that, depending on the situation. You can definitely use it depends as an answer. Cool. So how is it working for you, Martin? It's a mixed bag. It depends, actually. It depends on when you ask me. So most of the time, I'm doing relatively well. I use the opportunity that I'm more at home to do more virtual events, which aren't as great. I mean, it depends. Oh god. It depends on the event. You don't get the same feedback. You don't get the same interaction with the audience as you do in an in-person event. But I think it's still OK to do this, especially as we are all at home. I do Twitch streams, which is quite cool. So I had a doc draft, actually the one for JavaScript and structured data. I had the draft pretty much ready. And then just we're mulling over a few phrases and a few ways of formulating things. And I was just putting it into the Twitch stream. And then people were giving feedback and asking questions. And based on that, I was able to improve the draft even more. So that was kind of cool, so this collaborative side of things. I'm planning a few more virtual events that are a little different from the normal one-person talking, everyone listening kind of situation. Because I think that translates really badly to online. But hey, we do have the webmaster lightning talk. So that's pretty cool. I do go biking a lot. So that's nice. Yeah, I don't know. But some days it's just not great. Let's put it that way. Yesterday, I had a bit of a meltdown kind of, but I'm fine today. Cool, OK. Glad to hear that it's better. I don't know, for me, it's like not interacting with the bigger office or people that you see when you travel to work. I don't know, I find that really hard to adjust to. But I mean, we've been doing this for a while now. It's not completely new. I think the times that really get to me are more on the weekends, where it's like, well, I've spent all day or all week at the office. And then on the weekend, I'm essentially still in the office. I mean, technically it's like maybe I'm not in front of this computer, but I'm like five meters over to the side. But it's still all the same place, all the same stuff. So yeah, I don't know. Like you, some days it works well, sometimes it doesn't work well. I think in general, there'll be some things that hopefully we'll be kind of able to keep doing. But it would really be nice to get back to the office and see people in person and fight for meeting rooms and all of the things that you thought were frustrating or kind of the just the, I don't know, different things happening all the time. Be cool. It spices up the life kind of. Yeah, yeah. I think change in setting can be very helpful or so I found. Like yesterday I went out and had a coffee at my favorite bistro and I was just sitting there watching people pass by and I was basically learning to lip read because the waiter was like a kilometer away from the table. Also for the people who use imperial units, one kilometer is about 3,333 caterpillars. Just to put in perspective for you. I calculated this yesterday. So I'm actually fairly certain about that number. Oh, it's brown caterpillars. It's not any kind of caterpillar. I was about to ask which kind of caterpillars. Yeah, okay. And I found that super helpful. Just like getting out the house and just sitting somewhere where you can see people pass by like you don't interact with them and you are quite far away from them. It was really nice. Yeah, I think that's kind of the lucky situation where we're in here in Switzerland and probably not the same for everyone else. Like some people are interacting more or some people are kind of isolating more. It's like, ah, it's still gonna be a long time. But on the other hand, a long time means a lot of podcasts from us. That's true. So exciting. I'm uncomfortably excited. So cool. All right. I think we'll continue to do these and try these out. It will be great to have feedback from anyone that happens to be listening to this. Let us know which kind of things you enjoyed, what kind of things maybe we could do differently. If you like the podcast, then of course give us a link or a thumbs up or... Just make it nofollow. A nofollow link. Yes. So you're saying the nofollow link would count just as well? Don't read too much into it. Just give us a nofollow link. Okay. Give us a nofollow link and point other people to the podcast so that they can listen to it as well. The podcast should be on all kinds of the usual podcast platforms where you can get podcasts. So subscribe to the podcast. Watch out for the next ones. And hopefully, if all goes well, we'll continue to do these on a fairly regular basis. Especially now that we are stuck at home. Yep. Yep. And maybe next time we'll have pop filters and... Pop music. Pop filters. I mean, like if they're pop filters then we can't do pop music. But we can do pop culture references. I'm actually in the red when I say pop filters. Uh-oh. I just noticed the same, yeah? Well. Pop. Well, our producer will kill me, but that's fine. Okay. So maybe we should take a break here. Thank you guys for joining in. Thank you to everyone who's listening to this, who's linking to this with a nofollow link, of course. And hope to see you all again in one of the future episodes. Yeah, yeah, yeah. Bye-bye. Bye. Have a day.