 Welcome, everyone, to a special episode of Ask Google Webmasters. Here today is Martin. Hi, everyone, and this is John. Hi. Yeah, we're going to be answering questions on the topic of speed that we're submitted with the hashtag Ask Google Webmasters on Twitter. So let's start off with a question from Rohit. What is the ideal page speed of any content for better ranking on Search? Oh, you're asking me that question. OK. So basically, we are categorizing pages more or less as like really good and pretty bad. So there's not really like a threshold in between. It's just like we are more or less roughly categorizing the speed experience for users. And how are we actually doing that? Where do we get the data from? Yeah, that's important. So we mostly get data from two places. On the one hand, we try to calculate a theoretical speed of a page using lab data. And then we also use real field data from users who've actually tried to use those pages. And that field data is similar to the Chrome user experience report data. Cool. So we are having like hypothetical data and practical data. So we don't really have a threshold to give away, but basically the recommendation I would say is just make sites fast for users. That's what it boils down to. That sounds good, yeah. The next question comes from Olga. And Olga is wondering, if a website's mobile speed is best looked at using the TestMySite tool, the GT metrics tool, or PageSpeed Insights? That's a really good question. What's the most important tool for SEO? We have multiple tools that measure multiple things. And I can understand that that can be kind of confusing at times. In general, these tools measure things in slightly different ways. So what I usually recommend is taking these different tools, getting the data that you get back from that, and using them to discover kind of low hanging fruit on your web pages. So things that you can easily improve to really give your page a speed bump. How's that sound? Yeah, that sounds pretty good. And also, the tools are differently aimed, right? Some of these tools like TestMySite is pretty high level, so everyone understands roughly what's going on there. Whereas GT metrics is a lot more technical and PageSpeed insights, I think it's kind of in the middle of that. So depending on who you are catering to, who you're trying to give this report to, to get things fixed, you might use one or the other. So figuring out what is the low hanging fruit and using the tool that gives you the best insight into that for the audience that you're trying to convince. Is it a C level? Is it a other marketer? Is it someone from the tech side? Like, is this a developer? Then you probably pick a different tool. Next question comes from Honor. Honor is asking, I am testing an almost empty page on DevTool audits. And it usually gives me minimum results which are 0.8 milliseconds for everything and 20 milliseconds for FID, what is FID? First input delay. First input delay, of course. But sometimes it gives worse results for TTI, FCI, and FID. Right, okay, let's talk about these metrics. FID, we have covered first input delay. TTI is time to interactive. That's when you can first interact with a page. And FCI is first CPU idle, which means that there's no more, well, JavaScript work or other work that needs to be done by the CPU. So it's the same page, same code, different numbers. Why would that happen? Well, first things first, these measurements aren't perfect, right? So if it's between 0.8 milliseconds and 20 milliseconds, 20 milliseconds is a lot more than 0.8, but it's still quite a short amount of time if you think about it. You roughly have 10 milliseconds for a single frame to draw. So yeah, 20 milliseconds isn't too bad. So you will always see some basically noise in that measurement. And also don't get too hung up on these metrics specifically. If you see that there's a perceptible problem and there's actually like an issue that your site stays like working on the main thread and doing CPU work for a minute or 20 seconds, that's what you wanna investigate. If it's 20 milliseconds, it's probably fine. Our next question comes from Drew and Drew asks us, what is or are the best metric or metrics to look at when you wanna decide if a page is fast or slow? And why or why not would you just look at things like FCP, which is first contentful paint, FMP, which is first meaningful paint instead of just the scores that these tools give you? Wow. I don't know, Martin. You need to tell me some more about that. Right, okay. So I guess the question here really boils down to what's the metric that you should look at? And that's a really tricky one because I guess it depends on the site. It's the typical, it depends answer. If you have just a website where people are reading your content and not interacting as much then I think first meaningful paint or first contentful paint is probably more important than first interactive delay or first, sorry, first input delay or time to interactive. But if it's a really interactive web application where you want people to immediately jump in and do something then probably that metric is more important. So don't try to break it down and that brings us to the scores. The problem with the scores is they are oversimplifying things, aren't they? Yeah, it sounds like it. I mean, all of these measurements sound like they're measuring different things and ultimately trying to understand what a user would perceive when they access the page. So the score might be, I guess, a simple way to look at it overall but it's probably not all of the details that you'd need. It just gives you a ballpark, really. It's like, how fast is this page? Five, what does that mean? It doesn't really convey meaning, doesn't it? So I would say use that to figure out how you're roughly doing and then use the specific insights the different tools give you to figure out where you have to improve or what isn't going so well. Wow, sounds like speed is a tricky topic and you kind of have to know what you're measuring so that you can take action on the right things. Yep. So would that kind of explain why there's no simple number that Google is just giving? Yeah, so that definitely explains it because if you think about it you can't break down speed into one simple number. It is a bunch of factors. If I'm painting really quickly but then my app is all about interaction, it's a messenger, so I show everything, I show the message history but if I try to answer the message that I just got and it takes me 20 seconds until I actually can tap on the input field and start typing, is that fast? Not really, but is it so important that I can use the contact form on the bottom of a blog post within the first 10 seconds? Not necessarily, is it? So how would you put that into a number? You don't. So I guess speed's hard. Speed? Speed sounds hard. What do you think? Will this get easier? I guess it will get easier but it will never go to a point where you just have a score that you optimize for and be done with it, right? It is such a broad topic that it's really hard to break that down into like one number. Okay, so you imagine the more advanced people will continue to focus on the tiny metrics and counting milliseconds and others will look at kind of a bigger overview picture. I guess so. And together, we'll try to find ways to improve the speed of the pages overall. I think browsers are also doing a lot of work to make things faster in general and easier to understand, but generally speaking, you will still need to go and do the work of figuring out what matters to you, your audience and your website, right? Is it interactive? Is it contentful pains? Depends. That sounds cool, yeah. So I expect more questions on speed on the hashtag Ask Google Webmasters and as we get those questions, we'll ask an expert like Martin who knows all of these three-letter abbreviations and who can help us figure out which ones are the right ones. So thanks for submitting all of these questions and hopefully see you again on one of the future episodes. Hopefully, thank you very much for having me and thanks for all the questions.