How Browsers Really Parse HTML (and What That Means for SEO)

14:23Martin Splitt:Well, exactly, because that assumes that the page finished loading the things, right? That should be in the head. So, for example, if you put a paragraph, like a P element in the head, that's basically content. Metadata is not shown on the page. True, true, true, true, true, true, true.

14:44Gary Illyes:Right. So the metadata is in the head, and then whenever we see something that isn't metadata, then the browser has to assume that the intention was that this is shown into the user, and that would mean that the body has started. And it, quote unquote, has missed that the body has started. So it starts the body for us automatically. OK, got it.

15:03Martin Splitt:JOHN MUELLER - Yeah, I think so. And for search engines, that's probably the same. Like, they try, at least, to behave more like browsers. Sometimes that works. Sometimes that doesn't work. And they would accept these tags, elements in the head, but not in the body. Right. And some of the things that you can specify for search engines actually carry a lot of weight. Let's say RACA. Yeah. That's a pretty strong signal to a search engine. Yeah. Yeah. But if we allowed that in the body, then Mischievous Martin Splitt could show up on my blog and put it in a comment, and because I'm really bad at escaping HTML, Martin could hijack my page, point with a real conical to his blog, and suddenly I don't have anything in search anymore.

15:58Gary Illyes:MARTIN SPLITT - Ah, OK. But wait, interesting point, but counterpoint. If I have the power to inject random markup that gets parsed as markup, I could inject the script and ask it to add the link rel canonical to the head as well, no? Yeah.

16:16Martin Splitt:Isn't it much simpler to just have a link tag? Like, you would want to go for the simplest.

16:21Gary Illyes:Sure, but if it doesn't work, then I can still use JavaScript to get around that limitation. Ah. Sure. Oh. See, mischievous Martin Splitt is mischievous. Mischievous, mischievous. I see what you mean. Yeah.

16:38Martin Splitt:Ah. But we can get around that. By not rendering. By rendering. Oh. How? Oh, wait. No. No. I was thinking that if the link was introduced by rendering.

16:56Gary Illyes:We can tell that because we have the original thing and we have the thing after rendering.

17:02Martin Splitt:Yeah. I wanted to say something relatively stupid. It's like we don't accept the link for Alcanonical if it was injected by rendering. but we cannot do that. We have to accept the linker economic belief.

17:13Gary Illyes:Because there's legitimate cases where that is done. I think we're coming to a point where we need to realize as well as the people listening to us and this is interesting because we actually are thinking about this as we speak that there are decisions to be made by whoever is consuming HTML that are going beyond the standard, right? The standard is just like, you should do this if you want to work with a HTML document. But there are additional rules that you can and probably have to put on top of the standard that are not defined by the standard because they are application specific. So this is interesting because I know that browsers are doing a few things that are not exactly described in the standard either.

17:59Gary Illyes:as in like when you run into a script tag, normally unless you use any modifying attributes to the script tag, the browser kind of stops doing things there, executes the JavaScript, and then carries on. Otherwise, if it's basically just like HTML, heads with some metadata, body, some text, some images, then it kind of does like a preliminary scan to see if there's any images so it can in the background start downloading those. And then kind of starts building the DOM tree and the render tree and making sure that you basically start seeing text as soon as it possibly can. So it doesn't parse the whole HTML and then show you things.

18:42Gary Illyes:It shows you things as it goes through the HTML. And the standard doesn't specify how that works. That's how browsers kind of work, I believe. Yeah. Yeah. But there are exceptions. There are specific metadata bits and pieces that do give us as the website owners and us in terms of us as a search engine company hints and suggestions as to what to prioritize and how to do things, right? There's like DNS prefetch. Yeah. There's preload, I believe, as well. And then there's like script defer, script async. Are we using any of that? Sure.

19:24Martin Splitt:Nice. Like, I don't know what we are using from those things. I don't think we are using much because we don't need to. Okay. Like, it's very helpful if you have, like, a crappy internet to do DNS prefetching, for example. In our case, we don't need to because we can talk very fast to all the cascading DNS servers, for example, to resolve whatever. Or pre-connect. Like, why would we pre-connect? Like, we are not following links, right? True. For example, and even for rendering, the fetching of resources is not synchronous. Right? True, yeah, because we're doing batch stuff. Yeah, and we don't refetch the resources necessary for a page all the time.

20:10Martin Splitt:It's basically we are caching on our side or, well, yeah, we are caching on our side the resources to save some bandwidth and host load and whatnot for the site itself. Same with preload. If we are not synchronous, then we don't particularly need to listen and look at preload. So these are very useful for browsers. I was super, super, super excited about it when this came out in the late 2000s, I think, because it was so easy to see how much it helps. Like you just dropped one of these tags or keywords in a link element and it sped up things so much because you were on an internet that was not necessarily great.

21:00Martin Splitt:You had to connect from your location to servers that were thousands of kilometers or miles away. And all these little things like pre-connect and, I don't know, DNS prefetch and preload or prefetch, they were doing stuff in the background that you didn't have to do anymore. Yeah. So, yeah. I remember at one point Google introduced this link. I think it was preload for the first search result or something like that, or first two or first three or whatever, something like that. And when I noticed that in my brain, again, this was before I joined Google, in my brain that was nothing short of magic because it loaded the page, the search result page, and I clicked the first result because I'm a sheep and I do what other people are also doing, click the first search result, and it, like that, just, it was on my screen immediately.

22:06Martin Splitt:And to me, that was mind-blowing. So for browsers, it can make a huge difference to use these. But for search, eh.

22:16Gary Illyes:Did you know that one of the couple of reasons that we had this mcache was the preload thing? No. Because preload has a few problems. And that's why it was deactivated. I'm not sure if it's back, but I think it was deactivated for a while in browsers. Because with preload, the problem is you're effectively triggering an action that normally a user would. And then you're giving cookies and stuff. So people could infer, like, ah, they have seen me in search results or somewhere else. And that was problematic. Of course. And you could avoid that by having the mcache in between. because then the mcache would download things from the server without cookies and without being able to trace it back to your user.

22:59Gary Illyes:That's one of the things where I'm like, oh, the mcache makes sense, but then the discussion was so heated that people had other issues with it, and it had a lot of issues, so I think that's fair. So you would say these link rel prefetch and stuff is not useful from an SEO perspective, but it is very, very useful for users still.

23:19Martin Splitt:I mean, it depends how far do you want to go with SEO, because there are plenty of studies out there, independent studies even, that show that people do appreciate quite a bit when things load fast. Of course, yeah. And they convert better. I don't remember what the studies say, but I kind of remember that they convert better. Retention is higher, yeah. Yeah, retention is higher. So if SEO is just about search engine optimization and just a technical part of it, then these link hints or link keywords don't really matter. If you step beyond the technical SEO and you also start looking at once the user is on my side or on the side that I manage, how can I retain them?

24:06Martin Splitt:How can I convert them better? Then they can become quite useful. No?

24:13Gary Illyes:Yeah, but it's tricky to measure that, right? So that's why not many people are paying attention to it. So I'm happy that we're calling this out. And I think in general, it makes sense as an SEO, especially if you're on the technical side, to understand what valid markup should look like and if a deviation from the specification is OK or if it's a deviation

24:36Martin Splitt:that is potentially problematic. Right. So would you agree that, for example, meta tags and link tags belong in the head? I would agree, yes. When they provide hints for search engines, at least.

24:49Gary Illyes:Yeah, I would say so. especially because you can assume that something that is in the body was probably not put there deliberately or at least not in good intentions. Right. Because sometimes we have this problem with like mixed signals, especially when JavaScript is involved. Like if you have a canonical that is there at the first time we fetch the HTML from the server and then the JavaScript changes it, we actually advise against doing that, changing something with JavaScript because then it's like, what is the intention here? Was the other one kind of like accidental? Yeah. Was the other one the right one and now accidentally they changed?

25:26Gary Illyes:Yeah. I understand that there are situations where for whatever technical reason, you can't have them in the initial HTML, then add them with JavaScript. Fine. But like these mixed signals are difficult and tricky to understand the intention. So giving as clear intention as possible, I think, is generally the course of action. And I believe that the metadata then should also sit in the head to be very, very explicit, like this is our intention.

25:53Martin Splitt:Yeah, yeah.

25:54Gary Illyes:Okay. Huh. Cool. I think that made sense, which is surprising. So, okay, we talked about parsing. We talked about hints in the metadata. We talked about metadata in general. I think that caught us up on the topic.

26:13Martin Splitt:We finally discussed this in the podcast. I mean, you still have the body, but I think the body itself is kind of boring. Yeah. That's just the concept. Right. But there's no, like, I don't see how there are gotchas there. Like there's stylistic choices that you can make. And I'm talking about the source, not the, like what you see. Yeah. Not what you see. Like there are stylistic choices that you can make. Like, for example, internally, I'm really fussy about breaking lines close to 80 characters, because then it's easier to review stuff. Yeah, it's easier to review on your Commodore 64. Sure.

26:54Martin Splitt:Have you seen my setup? Yeah, it's a nice setup. I like the vintage. Anyway, but for majority of the programming languages that we use at Google, one of the big ones is C++, and I wrote a lot of C++ at Google. or C and C++. And for that, you have to break the line into 80. So everything needs to fit in 80. So that's the style guide, yeah. That's the style guide, yes. And most of our review apps or software that we have, they will tailor for that, for those 80 characters. So the review platform that we are using is going to do really weird things when something runs more than 80 characters. And then if you are reviewing big documents, all those little weird line breaks is going to be really weird to review.

27:50Martin Splitt:So yeah, I'm breaking at 80 characters as much as possible, even HTML. But other than that, I cannot think of other things that you can...

28:01Gary Illyes:I actually have a question for the body. All right. What's your stance on semantic markup? So are you... What's that? Expecting a difference between me just having like a paragraph element and then some text with links and images and another paragraph and another paragraph and me kind of like using headlines randomly. Or there's like an HTML5 algorithm or structure like the standard says like, oh, you should do this with like one H1. And then you can use article and section elements on a page to kind of give more semantic meaning and header and footer and nav and all this kind of stuff. Does that make a difference from a search engine perspective?

28:38Gary Illyes:I don't think so unless you do something really weird. Okay. I think it helps as in like for the users and for the browsers, but I don't think it helps a search engine that much as well.

28:51Martin Splitt:Well, you asked me about search engines. Yeah. So search engines, you think it's like a small difference in practice? I think so because like you can say that something is valid. That's a binary thing. It's very hard to say that something is close to valid. And then, like, what do you do there when something is just close to valid? For example, and this doesn't exist, so don't try to come up with conspiracies, but you cannot give a ranking boost to valid HTML, for example. True, true. Because, for example, if I miss a closing span, then suddenly my HTML is not valid. It will not change anything for the user.

29:31Gary Illyes:True. Hmm, interesting. But that's good to know. And that's something that I think comes up every now and then. It's like, oh, we should use only one H1 element and then H2 for all the different sections versus just use H1s for all my sections. I think that's generally fine, especially because visually you can still do something with it if you don't care too much about the structure semantically. Okay, cool. That was an interesting conversation. Thank you so much, Gary, for talking about parsing with me. That was wild. MARK MANDELSKI. Yeah. MARK MANDELSKI. I liked it. That was good. So we can take away a few things that I didn't know or wasn't sure about beforehand.

30:13Gary Illyes:MARK MANDELSKI. OK. MARK MANDELSKI. Like metadata in the body, for instance. Not necessarily a great idea, as we discussed. HTML validity, not as important as we developers like to think sometimes. MARK MANDELSKI. What else? MARK MANDELSKI. Semantic markup, not that important. useful for accessibility and users, but not that important for search engines at least. Right. And I think like performance and performance improvements for users do have sort of secondary effects on SEO, but not necessarily primary effects because the way that we as a search engine are using the documents is different from how browsers for users are using them.

30:48Gary Illyes:So indeed. Yeah, I think that was really interesting. And I think those are a few really good takeaways. We can ask the audience, like feel free to comment on this podcast and reach out on social media to me because Gary doesn't like to be talked to, I hear. Yep. Yeah. Would be interesting to hear if you would like more of this kind of stuff or if this is too nerdy.

31:07Martin Splitt:Yeah. And I think one of the problems is that Martin and I probably can talk about this for seven more hours because it is a wild topic and it is quirky, to say the least. Yep. And there's lots of facets that we can explore. So if you have questions, just yell at Martin or John Miller and leave me out of the yelling. Thank you.

31:31Gary Illyes:Leave us comments below this episode on the podcast platform that you are most happy with and we look forward to hear if this is something that you all are interested in or if this is a nerdy echo chamber. Anyway, thank you all so, so much for listening and thanks a lot to Gary for being here with me today. Thank you.

31:51Martin Splitt:Yeah.

31:54Gary Illyes:I wish you all a fantastic day. Take care and talk to you next time. Goodbye. Goodbye.

32:04Gary Illyes:We've been having fun with these podcast episodes. I hope you, the listener, have found them both entertaining and insightful too. Feel free to drop us a note on LinkedIn or chat with us at one of our next events we go to. If you have any thoughts, let us know. And of course, do not forget to like and subscribe. Thank you so much for listening and goodbye.