The Knowledge Panel Episode 21: JavaScript SEO

How do you ensure that websites that are built with JavaScript are easy for search engines to find and understand? That’s what we’re going to be discussion on Episode 21 of the Knowledge Panel. Joining Dixon Jones is Jamie Indigo and Joe Hall.

---

Sign up below to watch future episodes live…

Want to Read Instead? Here is the Transcript.

Dixon: Hi, guys, and welcome to the “Knowledge Panel” episode 21, and we’re talking about JavaScript SEO. And as normal, I’ve got a fantastic panel with Jamie, and I was chatting with them before we came on. And it’s really good to have Joe and Jamie. I reckon these guys are going to, certainly, put me in my place when I start going off from one topic to…

Jamie: You know what you did.

Dixon: Yes, absolutely. So we got…and it’s really nice to see you guys as well. Joe, why don’t you, for the benefit of the audience, tell everyone who you are and where you come from?

Joe: My name is Joe Hall. I am a technical SEO consultant. I’ve been doing this for way too long. I am from Columbia, South Carolina.

Dixon: And we met 12 years ago, something like that.

Joe: Yeah, something like that. It was in a time when it was much a hazier time for both of us, I think.

Dixon: Yeah. I’d like to say I’ve stopped drinking since then, but you know, there you go.

Joe: Nobody’s perfect. Nobody’s perfect, Dixon.

Dixon: No, I know. I know.

Joe: Except for me. Yeah.

Dixon: Anyways, good to see you again, albeit online. And, Jamie, how are you?

Jamie: Hi, love. I’m doing very well. Yesterday, in Denver, it was 65. It is snowing right now. I am a technical SEO.

Dixon: How did you do that? That’s incredible. That’s just Denver for you, isn’t it?

Jamie: It’s like, if you don’t like the weather, just wait a day. And that’s really where we’re at. There’s actually a lot of the DeepCrawl crew based out of Denver, which is pretty great. I can see my teammates even though we’re all remote. I’m a senior technical SEO with the DeepCrawl group.

Dixon: And I’ve just been told…you told me that you’re coming over to Brighton.

Jamie: Yes, exciting news. Fingers crossed. Ticket isn’t booked yet. But it should be good to go out and see all of you, lovely folks. I haven’t been to an event since a long, long ago, the before times. I’ll be out there.

Dixon: I was going to say, you know, I think I’ve just used my spare free ticket. But DeepCrawl is bound to have loads of tickets, you know, because they’re gonna sponsor everything.

Jamie: Come hang out. Come, be our friends. It’ll be fun.

Dixon: Yeah, absolutely. Good. Well, it would be nice to see you in Brighton, so let’s go. And, Joe, you’re thinking about going to Mexico for DeepSEO.

Joe: I know for certain that I’m speaking at DeepSEO. I don’t know if I will be there.

Dixon: Okay.

Joe: It is sort of a hybrid event, I think, but it is in Mexico. The last time I went to Mexico, it’s a really long story, but I’ve had some trouble getting back. And I don’t want to jinx it and do that again. So, yeah, so.

Dixon: We’ve got a few months to try and convince you otherwise then.

Joe: Yeah, exactly, yeah. But I will definitely be speaking there. You know, one way or the other, I’ll be speaking. So, yeah.

Dixon: Excellent. Oh, my friend, Lukasz, is sitting there in the audience as well. So thanks for coming in, Lukasz. I know, in about 30 seconds, you’ll be concentrating on something else, but if you guys want to jump in with any questions or add your 2p, Lukasz, please, do type in the chat, and it’d be great. And of course, this wouldn’t all work without my producer. David, do you want to come in and tell me all the things I should have talked about that I forgot before we start?

David: I just want to mention the fact that many people will be listening to this in Apple Podcast, Spotify, Google Podcast, but if you’re doing that, come and watch us live. Just sign up at theknowledgepanelshow.com. We’ve got another show coming up next month that I will tell you about towards the end of this one. So if you can watch us live, that’s absolutely wonderful. Then you can interact a little bit, and you can ask your own questions.

Dixon: Brilliant. Excellent. And so, guys, I want to jump in with JavaScript and JavaScript SEO, and I tend to start these things with some… So if people haven’t got the time to stay for the whole show and they’ve come in and said, “Right, you know, I think I should know about something about JavaScript and JavaScript SEO,” what one takeaway, Jamie, should people, you know, run off with? What’s the bit that you kind of wish everybody, you know, knew before they came in?

Jamie: First off, hi, loves. Thank you for listening to the podcast. I hope your errands go great and your hair looks fabulous today. The downside, bad news I’m going to share with you is even if you hate JavaScript, it’s not going anywhere. Just because SEOs don’t love it doesn’t mean we can stop it. So embrace the chaos, ride the wave, don’t forget to pick up your dry cleaning, and have a lovely day.

Dixon: But didn’t we say that about Flash and it’s gone?

Jamie: Well, 98% of the internet wasn’t using Flash. So let’s counterbalance that expectation.

Dixon: Well, that’s true. That’s true, yeah. Joe, what about you? A takeaway that people might go away with that they need to know about JavaScript SEO.

Joe: Yeah, I think Jamie’s right. I mean, I don’t think it’s going anywhere, and I think that that’s a lesson that I’ve learned over the years is that, with SEO, you have to kind of always kind of accept what you cannot change, you know. It’s the old Serenity Prayer, you know. But you know, I think that one thing with JavaScript is I think that people need to understand how it should be utilized to build different types of content and then how it shouldn’t. And I think that, for me, my major frustration with JavaScript is that it’s being utilized in ways that, you know, it doesn’t need to be utilized and for ways and reasons that don’t really make a lot of sense from a marketing perspective.

Dixon: Can you give an example?

Joe: Well, I just think that, like, there’s a lot of really great JavaScript libraries out there, like Angular and React, and whatnot. And, Jamie, you’re an expert on those kind of things. But I think that those are really great for building things like web applications and things that need to have, like, that client-side rendering and client-side processing. But from a marketing perspective, we’re dealing with a code base that doesn’t need to be so complicated on the client side, and it needs to really focus on, you know, accessibility from not just standard accessibility but also just the general accessibility for robots, and crawlers, and users, and screen readers, and everybody, you know. And so we don’t need to focus so totally on such a heavy JavaScript, you know, framework, like Angular or whatever, you know.

Jamie: Hear me out. I’m gonna counter that one, because usually, it’s not Angular’s fault, it’s not React’s fault. It is these 75 marketing pixels. Why do you have all of them? The next time a vendor comes to you and says, “It’s magic. Just plug and play this directly above the opening head tag,” tell them, “Not today.” If your tools…measure the ROI of these third-party tools. They impact your performance. If it’s a blocking script, you are dependent on their response time to be performant. Don’t blame the poor Angular.

Dixon: Those little scripts, those little pixel scripts and things that you’ve got all over the place. And I hear you, you know. I kind of sit there, and every time my page is looking slow to load, I’m sitting there, looking down in the bottom left-hand corner of my screen. And awesome fonts or something is sitting there. It’s sitting there, taking up some time, you know. And it seems that all these third-party scripts are taking the time, you know. How many of those get fixed with a defer tag? Because at InLinks, we use…you know, InLinks is all built around people injecting one line of JavaScript code on the website, and it injects the schema and the internal links and stuff, which is, you know, good or bad, depending on who you are. But we use defer tags so that it shouldn’t be a sort of anything that blocks the scripts.

Jamie: Render blocking resource. Yeah.

Dixon: And I wonder, you know, why can’t you use that with all those scripts, with all those things? Why can’t you just always use the defer tag?

Joe: I think you can, but I think the issue is the resource still has to load, eventually, you know. And I’m not sure that deferring JavaScript fixes things like First Interactive and stuff like that. The scripts still have to load, eventually.

Dixon: Sure. But if it’s a tracking script, you frankly don’t want it…you know, you don’t want it to load at the expense of the user.

Joe: Well, the other thing too, this is interesting that we’re talking about performance, because, you know, there’s been sort of a breakaway in the performance space where there’s been this debate of whether or not…should you be optimizing for, like, the tool sets, or should you be optimizing for the actual user experience, you know? And you can defer scripts like crazy, and you can even delay scripts and preload scripts, and all that stuff, and get these amazing scores, but it really doesn’t…it can screw things up in some ways. So, like, there’s a method that you can basically delay tracking scripts until user interaction. And when you do that, that’s great, but it could screw up your analytics as well, you know. And so I think it’s just one of those situations where you kind of have to balance the two, you know, and it’s a case-by-case basis, you know. It just depends, I guess, is the right way to say it, you know.

Dixon: I love the cat, Jamie. What’s the cat’s name?

Jamie: He decided yet again to crash the webinar. This is Tank. He is very professional. You can see his tiny little bow tie here, ready for business.

Dixon: Yeah. I do apologize to everybody on the podcast, actually. We might have to edit out the Tank cat thing, so, you know. And Giacomo seems to be very happy that we’ve got a cat involved in the whole thing in the audience there. Okay. So, fair enough, I’ll take your point. So defer tag could also screw up your website. That’s a fair point really. Okay. We’ve got a couple…oh, people are joining in here. Hang on. Lots of comments coming in, most of them about nice kitten, but there we go.

Anyway, let’s dive in to my next bugbear in JavaScript-based websites, and honestly, we’re talking about this. And Jamie was gonna give me sass, and I’m sure Joe will give me sass as well, you know. But one of my pet hates with JavaScript websites is I’m trying to use it and then there’s a bit that I want to share on social media with my colleagues, and it’s the same bloody link as five minutes ago because I’ve been doing everything using JavaScript and the URL hasn’t changed. So I can’t share anything with anybody on social. And the annoying thing is that also happens on inlinks.net as well. And Fred, the CTO at InLinks, who sponsored this, just in case, I needed to get an advert out for InLinks, he’s a bloody good SEO. So why the hell does he do this to me every single time? I want every bit of JavaScript to have a different URL. I don’t know. Why does that happen? Why is there so much stuff on the same URL?

Jamie: Can I tell you the good word? Have you heard the good word about history.pushState APIs? This beautiful thing where you can change the address, give each asset its own beautiful, unique location.

Dixon: Just, yeah, okay. So what is that? How do you do that?

Jamie: So pushState is going to go ahead and update the address bar when you’re doing, like, an infinite scroll, which sounds like, you know, you’re in another piece of content, you’ve been going and going and going, and you’re trying to share it out, but it’s not reflecting the content that you’re on now. This is also a problem people see when they’ve got infinite scroll on their sites. There’s a way to go ahead and update very easily and accept it across all browsers, the address that you’re on.

Dixon: So basically, so when do you use this command, this pushState command? I’m not a programmer.

Jamie: Anytime the content changes, update it.

Dixon: Okay.

Joe: But it is up to the developer to do that. I mean, they have to implement that, and I think that that’s a really good, I think, workaround the SEO should, I think, push more when working with sites, you know, that that type of push happens, you know. And that is the preferred method with continuous scroll, you know, sites to update. Although, I think it does it work with rel=next and rel=prev on that kind of thing. Yeah.

Jamie: Anytime they’re changing it.

Joe: Yeah. So, yeah, I mean, that kind of thing is great. I think that, from a usability standpoint, I think that’s what you’re mostly talking about, Dixon. I mean, doing what Jamie is saying, I think, is what Devs should be focusing on, you know, and that needs to be implemented more. We need to talk about that more, I guess.

Dixon: If you’re using an infinite scroll then, I guess I’m just trying to understand really as a simple-minded guy, in this regard at least, and I’m scrolling down an infinite scroll. Does that URL start changing in the address bar as you’re scrolling down?

Jamie: Yeah. That’s how, when you’re on a page, you can, like, go, and you come back, and you can stay where you were.

Dixon: Right.

Jamie: So you clicked a link, and then you wanted to go back to the content you were at instead of being shot to the top, and you’ve been scrolling for 10 minutes, and it’s game over. You’re not going back to that. That infinite scroll lets you go back, or the update of the address bar lets you go back to exactly where you were.

Dixon: Okay.

Joe: Yeah. As long as that’s implemented, that works really well. And we need to talk more about that. I think that that’s something that SEOs should talk more about is utilizing that as a workaround for, you know, the URL issue that you’re talking about, you know.

Dixon: So when you do do that, do you think Google is quite happy to then index? Because then, potentially then, you’ve got an infinite number of URLs, I guess. Because if you’ve got a scroll, there’s continually changing numbers as you’re scrolling down. If you then got infinite URLs, which could be argued as duplicate content, do you just change one problem for another?

Jamie: Well, it needs to have an index array. It needs to have a known limit. If you have 100 pages worth of content, don’t let it go ahead and start requesting page 200 or resolving with 200.

Dixon: Yeah. Okay.

Joe: Yeah. And then, also, I mean, that’s just an area where you would just use proper canonicalization, you know, depending on what the content is, depending on what we’re working with here. You might just want to use proper use of canonical tags, you know, in that situation, you know. It just depends on what the content is and what you’re trying to do.

Dixon: Yeah. I mean, on InLinks’s site, I mean, because you just got to go to the home page, and if, you know, you put a URL in, you don’t even have to log into the system. You can put a URL in, and what it does is it reads that page and runs our own natural language or an entity extraction algorithm, and it uses Google’s API and compares the entities that Google sees versus the ones that we see. And my URL hasn’t changed. I can’t show all these reports as a marketing guy. I’d like to just, you know, pimp that out and say, “Hey, look, Google can’t pick up these 300 entities on a page, and it just wasn’t built that way.” And we’re too busy building other stuff now to go [crosstalk 00:16:15].

Jamie: It’s a really low-lift change.

Dixon: Yeah, okay.

Jamie: It’s quite low-lift.

Dixon: I’m going to tell Fred this.

Jamie: For the ROI, being able to share these assets you’ve worked so hard to make, if you build them and no one else can access them, do they count?

Joe: Yeah.

Dixon: Well, yeah, I’m with you. It’s just the marketing guy telling the Dev guy, and they get into trouble at these kind of things when you try and do that. So I will try again. Excellent. Okay. Well, let’s talk about the difference between JavaScript SEO and JavaScript frameworks, because that’s something, Jamie, you were talking about before we came on really.

Jamie: Yeah.

Dixon: People have misconceptions about the two different… What is the difference? I’m in the crowd that has misconceptions.

Jamie: Most sites are using JavaScript. Ninety-eight percent of the internet has JavaScript running on it. JavaScript is expensive, and I think that’s one of the things, earlier, when we’re talking about, just because we can doesn’t mean we should, because to ship that, browser has to build it all. It’s expensive. It’s one of the heaviest things on the internet right now according to the last Internet Archive study. So the Web Almanac is a great resource. There’s a whole chapter in JavaScript in there. It’s really important to differentiate JavaScript running on any given page, which is, you know, how you have a lot of analytics firing off, your tag managers, versus the JavaScript framework, something like React, Vue, Angular. Honestly, you could…like, coffeemug.js is probably a framework by now. There’s millions of them. They’re everywhere.

And optimizing for them looks very different, depending on what they are, because some of these are client-side render, which means it’s like an IKEA ship. They send you all the parts, your browser builds it up. Some of them, the server builds it when you request it, and they send it back. So that’s their server-side render. Static, they have a copy ready to go. It’s like, when you go to Voodoo Doughnut, which is a great place here in Denver, and you pick out a very bougie, fancy Portland cream donut. You know, there’s one in display, but there’s also a bunch ready to hand over to you. Optimizing for them looks different, because it depends on how they’re built. If everything is client-side, I’m really sorry. That is a nightmare. Every script that is rendered client-side has a probability of breaking, and you have no insight into when or how it broke. Something could be broken for a fair amount of time, and you have no earthly idea.

Dixon: So, okay, I get that. Joe, I mean, what do you find yourself mostly playing with, you know? You said earlier on, before we came on, you hate doing SEO for JavaScript, but you quite like programming in it, which I guess is that is the difference between server-side and client-side JavaScript.

Joe: Yeah. Well, I hate to admit what I enjoy programming in, but I’m an old-school guy. So I really like jQuery. And I know a lot of people don’t like jQuery, but I still really like jQuery. I think it’s really easy to use. But going back to what Jamie said, I think that this is what I was talking about before we started the podcast about how we, as a community, talk about these frameworks and talk about how they’re utilized and whatnot, and what you were saying, Jamie, about how the likelihood that some things are gonna break or whatever, is something that we don’t talk about enough. And I think that that’s something that needs to be understood is that…and I’m guilty of this as well, it’s, we’ll do a test, I’ll run a test on to see if this works or whatever, and then I’ll come out and put a tweet out and say, you know, “Oh, I just tested this thing in JavaScript, and it works,” you know.

But at least for myself and I imagine for many other people, when we do tests like that, we don’t do them at scale, right? So just because it worked on one page when I wrote the script on…

Jamie: It works on my machine.

Joe: Yeah, yeah, exactly. It works on my browser. It worked here. You know, it worked here where, you know, it works this one time that Google indexed the page. But the problem I have, the problem I see a lot of is these pages that have, like, you know, 10,000, 20,000 URLs that are utilizing a client-side render on each page. And if it’s something like, you know, they’re client-side rendering a batch of internal links on every page, well, okay. If just one of those pages has an error during the crawl or maybe even a batch of those pages have an error during the crawl, it can significantly cut down the internal crawl and the internal link equity spread for that crawl. And like Jamie said, if you don’t know how long it’s been like that, then you could significantly be cutting down internal link equity spread as a result of that.

And so it’s one of those situations where I really don’t like client-side rendering for that reason, because I’m worried that there’s all these opportunities for it to break on the search engine side, and it’s gonna significantly hurt you if it does break. And that’s why I’m just kind of always really uneasy about it, even when I see things, like, that work well, because, like, you know, Angular and React, they both have kind of good ways to get around all that. Like, they’ve got different things you can do to implement server-side rendering and whatnot. But it’s still that opportunity for failure can still occur, you know. And so I think that we need to talk about, like, as a community, when we talk about these things, we should say, “Okay, look, like, you can do this, but should you?” you know. And you can implement these tools and whatnot, but here are the risks in doing that, you know, not just saying, “Yes, well, it works, so do it,” you know. I think that’s kind of dangerous for some sites, you know.

Dixon: So I mean, on that then, you know, how do you check it? I mean, surely, there’s got to be a way to check that the JavaScript is running properly on pages. How do you go about checking that sort of stuff? Jamie, are you going to say, “Use DeepCrawl,” [inaudible 00:22:40]?

Jamie: Well, here’s the thing, yeah, you can, but it’s a probability of failing. Every single one of them is a probability. So a lab test has a set boundary of where it’s running from, how it’s running, what it’s emulating. In the real world, somebody with shoddy cell phone reception walking behind a really blocking building could change how that page loads. And it’s worth noting that there’s four causes of poor LCP. One of them is client-side rendering. This is significant. You are asking that browser to go ahead and assemble everything many times. These users are on mobile. If they’re outside the U.S., data is expensive. And we are shipping so many things that they don’t need. You know, I gave the analogy of, like, client-side rendering is like going and getting a flat-pack bookshelf from IKEA. Well, half the time they ordered a bookshelf, we also sent them half a table set as well. They didn’t need it, it doesn’t function, it has no purpose, but we sent it, and they had to assemble it.

Dixon: I love that analogy.

Joe: Yeah, that makes sense. Yeah. And you know, to continue that analogy, Amazon now has a service where they will come to your place and assemble an item. Have you guys seen this? Like, you can actually hire somebody to come to your house and assemble whatever you’ve got. And I think that if we could work that into this JavaScript analogy, like, maybe somehow, if a site decides to use client-side rendering, could they somehow send us, like, a batch of more bandwidth or something? I don’t know how that would work, but, like, you know, that would be super cool if we could say, “Okay, like, the responsibility of making this work needs to be clearly on you if you decide to do this, the client-side rendering,” you know.

Dixon: But presumably, you can use a Lighthouse or something to just see which…or just look at the code to see which JavaScript files are being called and make a list and then have a look at whether those JavaScript files have got a good reputation maintained, because most of those are going to be names, file names, that are used all over the web, surely.

Jamie: They can be, but here’s the thing, anytime you’re relying on a third-party as code, you also have a security risk, your performance risk. The most performant and secure assets are those you don’t ship. So we tend to do kitchen sink tags on our sites. We keep adding scripts, and adding things, and adding features, and adding functionalities, until it is so absolutely bloated that we are just a dragon with a bunch of Allen wrench keys going, “This is fine.” It’s not how the experience we want to give our users. We can’t just ship all of this off without being considerate of how we’re using their bandwidth. There are options out there where we could do things that split the difference, something like progressive hydration that would let us ship the hero content, which the user is coming for, critical things like meta tags, all of the good bits. And then that secondary, that tertiary content, that can be loaded in the client’s browser. That footer, no one cares about your footer. Like, load that client-side. That’s fine.

Joe: Yeah. And then, also, again, this is kind of, in a way, this is where we kind of get into the marketing kind of thing, is one of the things I see having a lot of issues are all of the conversion tracking scripts. You know, those are really a pain in the butt, you know. And I think that it’s hard being an SEO and telling another marketing department, “Hey, like, please don’t load those scripts, like, because, yeah,” and they’re like, “Well, how are we supposed to do our job, the CROs, you know?” So I think that, like, I think what Jamie is talking about is loading those critical assets, you know, first and prioritizing everything else makes a lot of sense. It does get a little bit sticky, though, telling the CROs, “Hey, your JavaScript isn’t as important as everyone else’s, you know.” But, yeah.

Jamie: But it comes to another execution. I’ve been a CRO, and I’ve seen, when you use a global tag, when you block that entire page while you’re waiting for your third party A/B testing platform tool, you are crashing your conversion rate, rather [crosstalk 00:27:08].

Joe: Yeah, sure. That’s a good point.

Jamie: I have that.

Joe: That’s a good point, yeah.

Jamie: So only block what you need. Make that element.

Dixon: Here is…surely, this is the problem with that argument is that…and I remember Martin Splitt talking about it, who’s Google’s JavaScript SEO guy, for those who are on the podcast that want to know who he is, and he says, “Yeah. Well, it’s really good that you should only deliver JavaScript code when that page actually needs a code.” Don’t just bundle everything into one big JavaScript code that leaves…

Jamie: Please stop, yeah.

Joe: …that does everything. You know, break those out, but don’t break them out into 10 files. If all 10 files have to load, then you may as well just have one code to the computer, But the problem with that logic is that, you know, some pages need certain functionality and other pages don’t need that functionality, and it’s very difficult for us…well, I say us, for you guys, as the developers, to know in advance which pages, which of them is gonna be needed.

Jamie: There’s tools for that. There’s no way a human can go through and map that out, but there are tools for tree shaking and for code splitting. You can call a webpack in your pipeline, and it goes, “Okay, this page uses this code. I’m gonna ship that.”

Dixon: Yeah, but you don’t…so let’s say you’re using some kind of thing for resizing images, or something like that, you know. But the thing is you don’t necessarily know whether there are images on the pages that need resizing. You would if you went through manually and you found this kind of stuff out. But what I’m saying is that is the logic of trying to know exactly which JavaScript files to call and which ones not to call. Isn’t that easy to do in real life? Surely, it’s [inaudible 00:28:53].

Joe: I don’t think…you’re right, it’s not easy, but I think that more sites can do a better job of it. And I think that one of the ways that you do that is you have a good understanding of really, like, what I tend to do is I tend to break up sites into page types, you know. And I understand, like, if I say, “Okay, I know that blog posts don’t need this JavaScript. I know that your primary landing pages don’t need this JavaScript,” and give the developers more direction in that regard so that they can make some kind of case-based rules or whatever they want to on the back end to exclude certain pieces out of certain page types. I think that’s kind of the way you can kind of go with it, because, I mean, I’ve seen…I actually have a client right now who has about 30 pages that have video content embedded on them, and they have a video player, a JavaScript video player, but the site is, like, thousands of pages, and only 30 of them have video content, but they’re loading the JavaScript files for that content on every page, you know.

And so that kind of thing is kind of common sense. Like, say, “Okay, well, these JavaScript assets are only for, you know, your videos that are playing on these 30 pages in the video section. Let’s eliminate that site-wide except for those 30 pages.” So if you think that you can definitely…I mean, there’s a lot of opportunities for that where you look at opportunities like that, and there’s a lot of sites that can do better with that. But you’re right, it is difficult. If you really want to get granular with it, you can use a tool like DeepCrawl, for example. I imagine Jamie to figure that out on a page-by-page basis by looking at, like, individual footprints or whatever, to put in, to understand, “Okay, we know that these pages are the ones that need this asset because of what our crawl data says,” you know.

So I think it’s possible. When it is difficult, it’s a difficult task, and it’s a difficult ask from an SEO. It’s difficult to go to a development team and say, “Look, we need you to only load the JavaScript on these individual pages, because let’s face it, it’s just so much easier to slap it in a template somewhere and, you know, call it a day.” So I get it. Like, I think it’s possible. I think more websites could do a better job of it, you know, even if it’s hard, you know.

Dixon: So how would you go about optimizing that, you know, what script to call, Jamie?

Jamie: I would automate it using a library, like webpack, so it can go ahead and do the code splitting and tree shaking for me. Alternatively, if that’s not an option, let’s look at what’s in that global bin, what are we shipping in every page, and go, “Hmm, some of these only fire on specific templates.” So then we begin to enter that conditional logic Joe mentioned where, you know, if the template is the video player, then we load the script. Look in that global junk drawer.

Dixon: So webpack, I remember Martin Splitt also mentioning webpack, so, you know, that was a good sign. So can you explain webpack a little bit because it sounds like a resource that probably, you know, we should know about?

Jamie: Absolutely. It’s available on GitHub. It builds in to react really easily in a bunch of other frameworks. Simply, a library that you add, and when you go ahead and build the pages, it handles the identification of what scripts are used and where they’re used and will only ship what is needed. Because fundamentally, all of the discussion around JavaScript comes to the fallibility of rendering. And Core Web Vitals is measuring how effective we render. So if we can go ahead and load what matters when it matters, we provide a performance site, regardless of how much or how little JavaScript is in play.

Dixon: So if I’m a simpleton with a WordPress website…well, sorry, not simpleton. I am a WordPress man so I use my WordPress websites, and I’m sure that I’ve got loads and loads of plugins that are absolutely…well, hopefully, not too many. And I have had people telling me [crosstalk 00:33:09].

Jamie: That’s your junk drawer. It’s time for us to go through and clean that junk drawer.

Dixon: Yeah, that junk drawer. But of course, the junk drawer, you know, even when I decide, though, which plugins I do keep out of those, the majority of those plugins will probably load those JavaScript files on every single page. And a video player is a pretty good example of that. If I’ve got, you know, a video and I want to speed up that video, and I suddenly find a plugin that says, “This will, you know, load your video player much, much quicker,” so I put it in and add it and thinking I’m speeding up the website. But, Joe, what you’re telling me is I’m speeding up the page with the video and slowing down every other page. Is that right?

Joe: Yeah. I mean, it depends. Like, and I hate to…honestly, really I do a lot of WordPress development, and I have a WordPress bias. So I will say that, if you are loading a video plugin and it puts out JavaScript on every page, then it’s a bad plugin, right? Because there’s definitely ways to localize those scripts only on pages that they are needed. And then I hate to recommend using another plugin, but there are plugins out there that can help this process and streamline it. Perfmatters is a great plugin for WordPress that can help you eliminate unneeded JavaScript on pages that are not using it. There are some other options out there too, other plugins [inaudible 00:34:40].

Dixon: Is there a webpack for SEO, for WordPress? I don’t know. Is there a webpack plugin for WordPress?

Joe: I don’t know. Jamie, is there that you know?

Dixon: Looking it up where we’re going.

Jamie: There’s a million and one plugins for WordPress, and here’s the thing, you have to be judicious in deciding which ones to use. And they are very much an ecosystem where you could put in one that optimizes for one thing but hurts all the other things. So be patient. Be aware of security risks that come with any of these. Don’t forget that British Airways got hacked real good by 16 lines of JavaScript added onto a third-party script they fired in every page.

Joe: Yeah, I think that’s one thing about WordPress, it’s really easy to make mistakes, because there is so much out there, so much available. I will say, like, I don’t think that if you have a website, you know, a WordPress website that you care about, I would not add plugins without help if you don’t know what you’re doing. And you really need to understand what that plugin is doing and how that plugin works and what the major kind of features are for it. And also, you should only add plugins that are regularly maintained and regularly updated.

Dixon: And I think that’s pretty much, you know, you can have a look at the community behind that plugin really easily before you start.

Joe: Yeah, you can, yeah.

[crosstalk 00:36:11]

Joe: You absolutely can, yeah.

Jamie: I mean, I could go ahead and release a plugin right now that, like, makes your page faster, and it just puts flame decals on it.

Joe: Yeah.

Jamie: There’s not a lot of…

Dixon: Remove the code. Just remove the code, nice white page there.

Joe: Yeah.

Jamie: Oh, there’s a great library that’s called thanos.js, and it just snaps half the code off the page. I think it’s the best thing ever. Automatically makes you save more performance, 50% lighter.

Dixon: You’re only allowed to program in 20 lines of code. The whole page will go in 20 lines. That sounds like a good way to force people to optimize.

Jamie: Good JavaScript is like physics. It’s beautiful and simple and completely baffling.

Joe: That’s true.

Dixon: Okay. So let’s talk a little bit about DOMs and View Source versus Inspect and the differences for people, because another naive thing that I said before I came on is I never use View Source anymore, and you both kind of looked at me and said, “Why wouldn’t you use View Source?” Because I’m always using the Inspect and assuming that I don’t want to use View Source, because I want to see what the rendered code is. Why is View Source in the Chrome as an option when they’ve got Inspect, and what’s the difference anyway for everybody else?

Jamie: It’s part of the pixel pipeline, my friend. If you have a noindex tag in that View Source, it’s never going to get rendered to see the index. So it’s an order of operations. We think of google as this giant monolith. It’s code. Code runs in an order. It starts with viewing the HTTP responses, and it moves through the source. Then, it grabs all the resources and renders.

Dixon: So, but then, does that mean that if you put noindex in a JavaScript tag, it’ll render?

Jamie: If you put noindex in a JavaScript tag and it renders on the page out, it’s a way to handle software for us. Absolutely. It’ll render it, but it used a lot more resources to get there and then find out none of it was valuable.

Dixon: That it didn’t need any of it.

Joe: Yeah.

Dixon: Okay.

Jamie: Exactly.

Dixon: Yeah, yeah, okay. So the whole thing here is the difference between View Source and the rendered JavaScript. That’s where the interesting bit lies for trying to optimize JavaScript fir SEO, would you say?

Joe: Yeah, I think so.

Jamie: Oh, absolutely.

Joe: I mean, yeah, I think that, like, you know, the View Source is…so let me give you a little bit of a history of myself and how to explain my perspective. I come from a time when the term server-side rendering didn’t exist because that was all that we did. There was no such thing as client-side rendering. You know, JavaScript back then was kind of, like, included to create a more rich experience, but it never was responsible for, like, actually rendering content, you know. So I think that, with that perspective, View Source is server-side rendering. It is what comes directly from the server, and it’s not the client-side rendered version of the page.

So I think what I use View Source for a lot is comparing the two and understanding, “Okay, if there’s something showing up in the rendered version in Chrome tools, and it’s not showing up in the View Source, that means that it’s client-side rendered.” And if that is something that, you know, helps with SEO or as a part of the SEO process, then that should be understood, you know. And it doesn’t mean that the engines are not seeing it. It just means that they’re having to go through an extra layer of work to see it, you know. And so I think that that’s why I use the View Source and the Chrome DevTools, Inspect tools, and stuff like that, to make a difference between the two, you know.

Dixon: Okay.

Joe: Yeah.

Dixon: Jamie, do you want to jump in on anything of that, or?

Jamie: I mean, it should be part of your processing pipeline. No matter how far in the long, long ago, in the before times we all came from, like Hummingbird, Panda, the great farmer updates, this is where we are now. This is our reality. And just like your browser, you are optimizing for an experience that involves JavaScript. That pipeline starts with the initial request. We get that HTML, initial HTML response, which is the View Source. We can look at the Network tab in Chrome DevTools and see what resources are being called. So then we know what else Google has to go run and fetch in order to make that page. So we’ve moved from View Source to, like, “Let’s look at the Network tab.” If one of those resources is blocked, the content that it generates can’t attribute to the page.

When we see that full DOM, we could do something like comparing the output from URL inspector to that which we have in the live page, which you can copy and paste out of URL inspector. They added a fine functionality into the rendered HTML there, and I love it. You can compare that to what you have in your user’s page and see where the gaps are. It’s very useful. It’s important to note, though, when you do a live test, live test bypasses Google’s extremely aggressive cache. They are ignoring your max-age tag because no one used it right, and this is what happens.

So if you do a live test, you’re going to see a lot more resources unavailable, probably from asynchronous threads and chaos and cake. That’s okay. Use that cache version instead, compare and see, “Are pieces of my content missing?” If pieces of the content are missing and they’re in the View Source, they’re in our initial HTML, that means they were overwritten and not included in that DOM. Google flattens the DOM as it goes. It doesn’t keep a copy of the DOM, and this bit, and this bit, every piece of script as it runs. They don’t crawl the internet to be altruistic. And JavaScript is expensive. So it behooves them to go ahead and reuse resources where possible and to keep a single version rather than the layers and layers that we tend to have in our sites.

Dixon: Okay. So I love your alliteration as you walked through that, but I didn’t get…what’s a specter? What’s my specter?

Jamie: Specter? Inspector.

Dixon: You said specter. Oh, inspector, okay.

Jamie: Inspector. URL inspector.

Dixon: Sorry, okay, okay, sorry. Inspector. Inspector.

Jamie: Yes. I’m now going to call URL inspector Specter. It’s the ghost of a URL’s past.

Dixon: I thought it was something out of James Bond coming through here, yeah. So [crosstalk 00:42:45].

Jamie: Hello, Blofeld.

Dixon: I’m gonna finish with one last thing that I’d like to ask about, and it’s more of a theoretical, but I suspect it’s not theoretical. I bet it’s got some very real problems emerging on the horizon. Last few webinars that we’ve had on the podcast, Knowledge Panel, we’ve talked about the edge and doing things through Cloudflare or Akamai and using SEO, injecting links or injecting schema or redirects, or whatever, at the cloud level, at the edge level via the CDN. And I’m wondering now whether, you know, that’s trying to get in even earlier than the damn server, and I’m wondering now whether there is likely to be some clashes between JavaScript and, you know, injecting things through a CDN. I don’t know if that’s something you’ve found had issues with or got some theoretical problems with or never thought about before. I don’t know if anyone wants to jump in with any thoughts on that.

Joe: I don’t think that there are any major conflicts with it. I think it depends on how that CDN or the edge-level SEO is being implemented. I know some of the edge-level SEO that I’ve heard about utilizes JavaScript in some ways, and others don’t. But from a theoretical perspective only, you know, if the site is using the CDN, then it’s all kind of the same, especially if that CDN is utilizing some form of caching, like Cloudflare does, then you’re already making that request from the CDN, to begin with. So I don’t think there’d be a wild complex. I’m not sure, though. I mean, I don’t see it being an issue, though.

Dixon: Okay.

Jamie: I have some clients who’ve had great success. That’s really useful, particularly in sites with a lot of tech debt, where it’s a little bit of code spaghetti and Jenga. And something can seem really dumb, but if you remove it, everything stops working. So there’s a boon to it. They can go ahead and basically take all of the chaos that you were going to ship to the client and cruft out that which was necessary, add in some pieces that are. The only time…because, again, it’s following a pipeline, we’re going from server to CDN, then passing along to our users. Sometimes I could see a problem would be in the devil’s detail. So if, in the CDN, you are flattening everything, you are not shipping any of your JavaScript, things like your tracking tag would not run. But you can add exceptions into there. So it’s really about how you do it.

Joe: Yeah. Yeah. And another thing about the edge SEO that I’ve heard from most SEOs that utilize it is that it makes the SEO process much more manageable for, especially, when you’re working with a company that has a big team, and it’s hard…

Dixon: Sure, it does, However, if you’re the SEO and you go in control of Cloudflare… Rob Watts’ comment. I’ll ask that question in a second. But if you’re in control of Cloudflare, you could really screw up the developers because developers can’t work out why the hell that thing isn’t working.

Joe: Yeah, yeah, definitely. I mean, like, but it has to be sort of, like, this agreement, you know. I mean, if that team can’t get to your tickets for another six months, then they have to agree to giving you some…

Dixon: Give you a workaround, yeah.

Joe: Yeah, give you a workaround. And I mean, that’s just kind of, like, a simple kind of compromise you make with the Dev team and say, “Look, like, if you can’t give us this in six months, then at least let’s do this instead, and we’ll work with you to keep you informed of everything that we’re doing,” and kind of co-exist in that regard. But, yeah, it is a lot easier for a lot of SEOs that manage enterprise accounts and whatnot to have that level of access, you know.

Dixon: Okay. David, can you bring up that question from Joe…that comment from Rob Watts, and I’ll just read it out for the podcast.

Jamie: That’s a great one. Thanks, Rob.

Dixon: Rob Watts says, “Cloudflare I found, removed html comments which I used to test a little thing once. Took me ages to figure it all out! So, yes, you have to be careful for sure!” That’s kind of interesting.

Jamie: They’re doing modification. They’re cleaning it up so it’s a smaller file. They’re removing unneeded spaces, comments.

Dixon: Yeah, you don’t need comments when you have a code, do you? You know.

Jamie: Exactly.

Dixon: Like, this comment that says, “Please don’t read this.”

Jamie: Stop logging things in the client’s console.

Dixon: I remember, at PubCon, Brett Tabke used to use comments in the robots.txt file to advertise for job roles. So you know, once you’d started looking at his robots.txt, that’s when you can start applying for jobs at PubCon, so.

Joe: Well, you know, that brings up a good point. Rob’s point brings up a good point back to what Jamie was talking about, about having, like, a clear understanding of the sequence of events, right? So if you’re working with a client and stuff like that happens, all your comments disappear. If you are aware of the sequence, if you know that they’re using the CDN, then it makes it much more easier to troubleshoot that issue, because you can say, “Oh, well, I know they’re using Cloudflare, so let me go and check and see if that’s a Cloudflare issue.” Or it could even be, I’m a WordPress guy, so it could even be a WordPress plugin. A lot of these WordPress performance plugins will do the same thing. They’ll minify the JavaScript. They’ll minify the HTML and remove commas, and stuff like that. So if you know the process that you’re working in, the sequence of events for that initial request, then you can kind of debug that pretty quickly, just get through each process in the chain, you know.

Jamie: It’s visibility and awareness into your site’s PEMDAS, if you will.

Joe: Yeah.

Dixon: I like that. I mean, I think that pipe thinking order, Jamie, has been my…I mean, it’s pretty obvious when you think about it that, you know, of course, you know, what happens at the DNS level is much more important, ultimately, than what happens at the server level, which is much more important than what happens at the…but they can all wreck your website. It doesn’t really matter, so.

Jamie: I mean, I found a job posting in a header the other day. I thought that was very clever. It was like, “Hi, you found us. Come apply for us.”

Dixon: Absolutely, absolutely. Yeah. I think, you know, yeah, there’s other sites I know that do that as well. Guys, I think we got to the end of our time already. These things don’t take very long. I was going to ask about using Google GTM to mess around with your JavaScript tags and things, but I’ll have to leave that for another day. And so, you know, thanks very much for coming on. But just before we go, David, what have we got on next month, on the next session?

David: Sure. Next month, it’s not on the usual Monday. It’s actually on a Wednesday, and that’s because Monday, the 18th, is Easter Monday. So instead, we’re going to be doing it two days after that, on Wednesday, the 20th of April. And that particular subject is going to be technical SEO quick wins. We’ve got a couple of guests booked for that one already we’ve got Wilhemina Gilbertson-Davis from BAT, and we’ve got Cara McClure from Mindshare. So sign up to watch that one live over at theknowledgepanelshow.com.

Dixon: Okay, brilliant.

Joe: All right, cool.

Dixon: And thanks to InLinks for sponsoring this stuff, as always. I’m the CEO of InLinks, so they’re always going to have to sponsor this thing.

Jamie: Thank you for sponsoring you. We appreciate all of your efforts.

Dixon: That’s what you got to say really. Yeah, absolutely. So, guys, just before you go, if people wanted to find you, because clearly, I’ve got two very, very bright people on the panel, where do the people…Joe, how do they go and find you?

Joe: You can find me on Twitter, @joehall. I talk about SEO and hot dogs.

Dixon: And that’s Joe with an E for those who are on podcast.

Joe: Joe with an E H-A-L-L on twitter. And then on LinkedIn. Don’t find me on Facebook. I hate Facebook. I’m there, but I’m not pleasant there. So don’t find me there.

Jamie: I don’t think anybody is pleasant there.

Joe: Yeah. Sure, yeah.

Dixon: I try. I try to be pleasant there. I’m old. I like Facebook.

Joe: I don’t try. I don’t try.

Jamie: I like Twitter because it makes you fall in love with a stranger in 280 characters. Meanwhile, Facebook makes you hate your family, so.

Joe: Yeah, exactly. Exactly, yeah. Yeah.

Dixon: Yeah. Echo chamber is not good on Twitter. It’s true.

Joe: Yeah.

Jamie: No.

Dixon: Jamie, how about you? Where do people find you?

Jamie: I am on Twitter, @Jammer_Volts, or you can just look for the blue hair. It’s pretty easy to spot me.

Dixon: So, okay. So it’s Jammer, J-A-M-M-E-R…

Jamie: If you’re at Brighton, come, say hi.

Dixon: …underscore Volts, as in electrocute yourself.

Jamie: Yes.

Dixon: So, yeah, that’s brilliant. Guys, thank you ever so much for coming on. Really appreciate it. It’s been good. I know we were trying to get Nick on as well, Nick Ranger, but we’ll get her on another show. So we’ll get that sorted. And, guys, thanks very much. And for everyone that’s watching and listening, please come back again soon. Cheers. Bye, guys.

Jamie: Cheers.

Joe: Bye-bye. Thanks. Bye.