Webinar: Why JavaScript Is Costing You Visibility (And What To Use Instead)

JavaScript-dependent content shows up in almost every technical SEO audit: content that renders fine for a user but sits invisible to a crawl bot, or bloats a page with several megabytes of framework code to do things HTML and CSS can now handle on their own.

You've probably encountered JavaScript SEO issues more than once.

Jono Alderson joins Jojo Furnival to talk through why that keeps happening, and what's changed in browsers over the last few years that makes so much of that JavaScript unnecessary.

Expect concrete techniques you can take straight to your dev team.

What we cover

• Why JavaScript-heavy pages often sit unindexed for days after Google's crawled them, and what's actually happening in that rendering queue

• Native CSS and HTML features — view transitions, popovers, content-visibility, speculation rules — doing jobs that used to need a JavaScript framework

• Spotting JS-dependent content in your own crawls, by comparing raw HTML against what actually gets rendered

• Hydration patterns in Next.js, Nuxt and Astro that quietly hide content and links from crawlers

• Talking points for your next conversation with developers about shipping less JavaScript

Webinar recording

And here are Jono's slides.

Webinar transcript

Jojo Furnival: Hi, everyone. We have got a very special presentation webinar today from the legendary technical SEO and speaker that is Jono Alderson.

I'm Jojo Furnival, marketing manager at Sitebulb. If you are joining us for the first time, Sitebulb is the only website crawling tool on the market to offer a desktop version and a cloud version. That means we can help every SEO. Yes, you can have a Sitebulb plan, you can have a Sitebulb plan, and you can have a Sitebulb plan. Find out — oh, dear. Find out more and access free trials at sitebulb.com.

As a reminder, this session is being recorded and I will email the recording out to you tonight or tomorrow. There will be time for Q&A at the end of today's session. If you have a question for Jono, I would if I were you, please put it in the Q&A tab next to the chat. You can also upvote other people's questions there.

Now to our guest. Jono is an award-winning, globally recognized SEO expert. He's the real deal, people. He helps brands gain a competitive edge with technical SEO, website performance, and structured data. And he's known for his outspoken views. Please give him a warm welcome in the chat. I'm going to hand over to Jono now, and I will see you later for Q&A.

Jono Alderson: Amazing. What a lovely intro. Thanks for having me. Incidentally, I wanna follow up on that plug — I used Sitebulb Cloud for the first time yesterday. A client I'm working with has it, and it was so nice to have a shared environment that we could all nip around in and do all that quality stuff in one place. Anyway, this isn't an advert. That's enough of that. Somebody keep me honest on timing in the chat. I'll keep you on it. And heckling is not only allowed, but encouraged. I see you, fans — let's do some SEO stuff.

So, yeah, I'm primarily still, I think, nowadays a technical SEO nerd, all of that stuff aside. Look under the hood of a lot of websites — big ones, small ones, small businesses, the world's biggest enterprises — they all have the same problems and issues and frustrations again and again and again. They're all slow. They're all broken. They're all over-engineered. They're all hemorrhaging potential and costing a fortune to run. And almost always, or at least more often than not, one of the main contributors and components of that, the main culprit often, is the misuse of JavaScript.

And I'll caveat this heavily to begin with, because we're gonna do a bit of digging at JavaScript. There is nothing inherently wrong with JavaScript. JavaScript can be an incredible tool. It's incredibly powerful. It's incredibly versatile. However, it is almost always misunderstood, misused, and the cost of that is existential. So, yeah, I think almost always, many of the problems we have with websites — the biggest ones — are the unnecessary use of JavaScript, using it incorrectly, using it when it shouldn't be used at all.

So before we get too deep into what does that look like and what should we do about it, I think we need to do a little bit of housekeeping on terminology and framing. A lot of the conversations in the SEO sphere around JavaScript use this phrase, JavaScript rendering, or talk about how we render JavaScript. I don't think that's a thing. I think people keep asking whether or not Google, for example, or ChatGPT can quote-unquote render JavaScript. And the problem with that — I see Barry Adams in the audience — is the same kind of problem as the difference between indexing and indexation. They're different things.

Rendering is a very specific technical word. JavaScript is executed, which is parsed, or it's downloaded. Resources, of which JavaScript is a type, are fetched. A document is constructed in a browser, and the resulting page is rendered. The JavaScript itself is never rendered. It's not a thing that can be rendered independently. And those distinctions, whilst maybe a little bit pedantic, do matter, because multiple different systems perform different parts of that process and they have different roles, and the implications of that are quite considerable when we look at performance, accessibility, discoverability, indexing, SEO, etcetera, etcetera.

So let's start at the beginning. When you or Google or ChatGPT types a URL into a browser and requests a page, the server, usually, if everything's configured right, will return a response. And usually that's going to be a bundle of HTML. That's the first version of the page that your browser, or Google, or ChatGPT gets — the raw document response sent by the server before anything else happens. That's the version that any basic tool, a fetcher, or retrieval system can see initially. But that HTML is not the page.

A page, a completed page, certainly post-1994, is assembled typically from multiple other resources, including the HTML. So the HTML will have references to things, obviously, like images, but also stylesheets, fonts, and other files, some of which may be on the same server and have the same kind of URLs as the website in question, some of which may be on other domains entirely. And the browser discovers those references as it downloads the HTML, makes additional requests to those assets, and combines the responses. And some of those assets might go on to make subsequent requests to other assets — all get fetched and recompiled back into the page.

So the page you see in your browser is a patchwork of stuff. It's constructed from a collection of resources, rules, and dependencies. So the initial HTML is the starting point, but not the finished product. The browser takes all of that, downloads and parses and evaluates all the CSS, loads all the fonts, all the images, calculates all of the layout, and then paints it, pixel by pixel, typically using your graphics card, onto the page.

And incidentally, Google, for the longest time, has done a very, very good job of running this process up to this stage. And in fact, nowadays, the crawling and rendering system — certainly the rendering systems and the browser systems that Google use — are the same Chrome browser more or less as you use as an independent human. And it can fetch most of the resources that a normal browser needs and construct something that is very close to the kind of page that you would see as a user. Caveat: there are some intentional minor differences, which aren't important for this. That is conventional web rendering.

And we haven't mentioned JavaScript yet, because this is where things get interesting. JavaScript makes this a lot more complicated because it can, and does often, rewrite and change anything, and often everything, about a page. So in that process of downloading and evaluating all the things on the page, we might discover that there's inline JavaScript, or it loads external scripts. And they contain instructions that can modify the document — after it's been loaded, or sometimes whilst it's still loading. They might, for example, rotate some other text. Or they might fetch product prices from a third-party API, or inject a recent news article, or replace the whole navigation system, or even, say, redirect the user if they are logged out and it's a Wednesday and there is a solar eclipse and blah blah blah blah. Or they might reconstruct, or construct from scratch, the entire layout and content layer of the page. So at one end of the scale JavaScript can make cosmetic adjustments and progressive enhancement and animation. And on the other hand, it can completely replace everything that the server originally returned — building on top of it, or destroying it and altering it entirely.

The mental model for how we think about JavaScript and how it interacts with pages and templates should be: we are running arbitrary software on top of the page that we got back from the server. Right? That's how separate this system is. Now Google is reasonably capable of fetching and executing JavaScript and has been for a long time, though it's not immediate always, and it's not perfect always. It receives the whole HTML, and then it may choose to render after loading resources and parsing scripts, etcetera, at a reasonable point in time.

Now what's interesting, with all of this AI-centric ecosystem we're entering — the world of ChatGPT and LLMs — those products and platforms almost always don't fetch sub-resources or run JavaScript. They might fetch CSS and they might fetch responses, though even that's rare. They very, very rarely execute and fetch JavaScript. So they're not rendering the page. They generally only have the initial response and whatever content can be extracted from that raw HTML. So different machines and different products and different services and different systems can encounter materially different pages at the same URL.

So if we think back to "does Google render JavaScript," and "does this thing render JavaScript" — what we're actually asking is, when the systems try to evaluate this page, are they seeing the same composite patchwork as a human? And often the answer is no. So you've got the initial server-supplied HTML, then there's the constructed document after stylesheets, images, and other resources, and then you might get another version of that page after the JavaScript is executed. And there might even be several successive states. A script may request and inject content and update the interface. This might not be as clean as version A and version B. What happens if I scroll down the page a little, then a bunch of JavaScript triggers requests to go and fetch some recent blog posts? You've got multiple different interpretations of what is this page. And we keep calling all of these things "the page," which is convenient for discussion but technically unhelpful and potentially confusing.

What happens when the raw HTML declares one canonical URL, and JavaScript replaces it with another? What happens if JavaScript redirects the user? What happens if that redirect depends on location or login status or cookies or device type or what experiment allocation? What if the title or structured data or navigation or primary content changes after that execution? OK? Those may all be manageable. You just wait for things to reconcile. But more complex: what happens if the JavaScript that powers that is blocked by robots.txt? Or if it lives on a different domain? Or if it lives on a different domain which is blocked by robots.txt? Or if it's slow to load for non-European users? So the problem isn't "can machines display the page." The problem is deciding which version of that page represents the truth.

And this is why we get confused. When we hit "view source" in our browsers, you get the raw server response, the initial HTML. But if you right-click and hit "inspect," you get the rendered page's HTML as it is right now, which isn't necessarily a fixed thing. Right? This might change. If I interact with a page, a whole bunch of JavaScript might run that changes the page's rendered HTML. If I click to open an FAQ accordion that's powered by JavaScript, maybe that content isn't even there if I hit view source. Maybe it's only loaded in via JavaScript after I click. So we've now got multiple different representations of this page through time, through interaction. This gets very, very complicated.

So the question of "does it render JavaScript" is probably the wrong question. We actually need to be thinking about three different questions. First is: does the system, whether it's Google or ChatGPT, fetch and execute JavaScript files and inline scripts? And the second question is: can it reconcile and understand and canonicalize those different states those scripts produce? And do we agree with the way that it does that? And then the third is: how does it handle bad paths? Like queuing, resource allocation, failures across all of that? This becomes quite muddy.

What I find really interesting is none of this is new. JavaScript has been changing web pages for years. Google has been trying to interpret those changes since 2005, I think — the first documented research from a Googler on how should we render JavaScript-powered content, I think, from The New York Times at that time. 2009, they trialed special crawling schemes because they admitted that dynamically generated content was difficult for them to access. We already knew conceptually that JavaScript could create multiple versions of a page, and that Google's mental model — and also ChatGPT by extension, etcetera, many of these systems are still powered by search — are still tied to the idea that one URL represents one static resource. It can change through time, but you certainly shouldn't get different versions of it depending on what's querying it. And none of that model really fits with how JavaScript can change on lots of pages.

None of this was a huge problem until the web changed. So what changed was, from about 2010, the way that we built websites and products and services was pretty fundamentally altered. Before that point, JavaScript was used fairly conservatively to enhance web pages. It was a scripting language that could validate form submissions, open menus on click, change styles and animate things, and revolve bits of content. Around 2010, maybe into 2011, a whole bunch of new development frameworks arrived onto the scene — for example, Angular JS and Backbone were very much the first. Later, in 2013, React came along, and these frameworks popularized a different model of how websites would be built.

And in this world, JavaScript wasn't really about modifying the page. It was responsible for building and architecting the entire page. The interface, loading the content asynchronously, managing navigation, controlling the experience, shipping an application to the user's device, whether it's a mobile phone or a desktop, and having that JavaScript bundle build the website using the user's computer or mobile phone resources, etcetera. JavaScript became very quickly the language in which you wrote the whole website. All of its logic and templates and processes.

So these new frameworks also attracted a new kind of developer to the web. Now at the time, browsers weren't great. Firefox was still a nightmare. Internet Explorer was still kicking around. Having CSS produce consistent results between different browsers was a pain in the bum. What you could do with websites and pages was quite limited. Whereas at the same time, apps were all the rage because they could be sleek, interactive, fluid in ways that the web wasn't. And — many of you will have experienced this — I've been in many, many meetings over the last two decades or so where at some point there's a discussion about developing and launching the new website. And the CMO says, "make it feel like an app."

And so businesses hire software developers, who are trained to build applications, on the web rather than web developers. And many of those people, bless them, didn't, and still very much don't, understand the web as a collection of documents, links, and browser behaviors. They are software engineers who understand containment and states, etcetera. So websites overnight started becoming much more app-like, whether they needed to or not.

So if we look at this technically, we take React, for example. React is a JavaScript framework; it doesn't just use the browser and build on top of it. It completely re-architects it. It creates its own model of the content, its own model of events, its own component life cycle. It decides when and how and what to render, and it constantly negotiates back and forth with the real browser underneath it. So if you're building with it and you don't know what you don't know — as many of these developers don't — it's extremely easy to build something which is slow, or uncrawlable, or inaccessible, or which uses buttons instead of links — we see that weekly — or which only loads the navigation dropdown when people click on it, failing to consider that Google doesn't click, etcetera, etcetera, etcetera.

Worse, every single framework, whether it's React or Vue or Vercel, does all of this slightly differently. And we've invented an entire alphabet soup of rendering acronyms to try and manage the abstraction and understand it. You'll have heard CSR, SSR, SSG, ISR, streaming, module federation, resumability. It is a committee meeting about abstraction that never, ever ends. And all of it is designed to make something that the browser can do reliably already, and has been able to do for over a decade — i.e. render HTML, manage state, and handle navigation — by rebuilding the entire browser inside the browser. And then we wonder why things are slow and cumbersome and brittle.

And, of course, it never stops. We are in a race to build frameworks to manage frameworks. We now have meta-frameworks. You'll possibly come across things like Next.js, Remix, Astro. These will be words you've heard if you've been subjected to this kind of nonsense — all layering on top of each other to solve problems we created by allowing engineers to abstract too far in the wrong direction. We've got linters and transpilers and hydration managers. We've turned runtimes into routers, into CDNs. It's exhausting. Every one of these layers adds complexity and tooling and build steps and breaking changes, which aren't necessary.

And you can tell — you can see this if you're an SEO. You've audited websites where you've seen this. You click the back button on a website, and you have no idea what's gonna happen. You might go back a step. You might reload the whole app for the home page. You might get a blank error page. Who knows? Because the person who built that application didn't build a website. They didn't think about or understand how browsers work. Practicing a form field while the page is still loading on a flaky mobile phone connection — anything at all could happen.

So what if we could just not build stuff manually? If we could just rely on the browser to do all of that sort of thing perfectly? Because now we have teams of developers who we all employ, and our clients employ, and our agencies employ, maintaining routers and histories and caches and hydration states just to reinvent things that the browser has already solved. I'd posit that 99% of the JavaScript that we're shipping — which is so often the heart of many of the problems that we get caught up in — isn't necessary.

And the web, as a result of all of this today, is objectively — not just speaking as an SEO, but as a user and a human being — it is slow. It is cumbersome. It is brittle and expensive. And we've normalized tolerating that, for the most part, as users and SEOs and businesses. We've got away with it. The problem is that that's gonna come back to bite us tomorrow. The technical debt, which we've all just suffered, will drown us in the world that's to come.

For the needs of tomorrow's users, whether they're human or intelligent. Whether they're audiences from developing countries with unstable network infrastructure who can't reliably download your 12-megabyte application. Or agentic browsers making split-second decisions on behalf of users in complex chains of custody. Or people who get really bored and less tolerant and frustrated of waiting, looking at loading spinners and waiting for things to load and watching things break.

So whilst our engineer friends continue to build all of these abstractions, the browser quietly grew up. Now it can do a bunch of the things that they turn to JS frameworks for. Since 2012, all of those things are solved. But developers are incentivized to chase the shiny thing, and to invest in job security rather than simplification. And your new CTO who comes in has to show that they've got something to prove, in order to validate why the old one was fired. Right? So we keep finding these terrible websites built with too much JavaScript, built objectively badly, in ways that destroy discoverability, crawlability, accessibility, and performance.

And so, as is so often the case in SEO, it is our job — unfortunately, whether we like it or not — to educate other people on how to do their jobs. That's how we make friends. Right? We need to educate our developers and engineers that the browser isn't a villain that needs defeating. It is now the hero that's here to save us, from the crappy code that they keep churning out that's ruining our strategies and websites and businesses. Because it's using the wrong tool for the wrong jobs — because they're building apps that use mountains of JavaScript instead of just building websites with simple native tooling. That is objectively the wrong modality for the modern web. This isn't an SEO rendering problem. All these conversations around "will it render" are reflections of a much broader architecture problem. And now the platform gives us better options to address this.

Let me give you an example. Here is circa 50 lines of custom, handwritten JavaScript for a very simple accordion. In 2015. Something like a show/hide behavior on an element, like expanding an FAQ. Don't worry that you can't read it. The point is not the details — it's that it's horrible. And this is extremely optimistic. It might easily have been five times as long. And if we zoom back a year earlier to 2014, it definitely would have been five times longer because of how children change, etcetera. The point is: this is monstrous to achieve a very simple piece of native functionality. This is what it looks like if I do it today. This is the same functionality, like an FAQ opening thing. With modern HTML, modern CSS, and no JavaScript. With complete browser support for anything that's been built in the last decade or so. Done.

We don't need to rebuild the platform and strip React and load 12 megabytes of JavaScript and build an application and hire a team of 20 engineers and take six months to ship it, just to create reliable, intuitive, performant, natively accessible interfaces. We just need the browser.

So I want to arm you with a bunch of stuff that browsers now do automatically, which let you push back the next time that you get stuck fighting against the dev saying, "oh, well, we do have to ship 10 megabytes of bundled application code, you know, blah blah blah blah blah." Things that you can use, or insist that your developers use today, instead of React or Vue or Next.js or whatever other garbage they're shipping. And generally, we aren't going to get technical — but don't worry. You don't need to understand the specific technical detail. All you need to do is get the gist enough that you're able to throw the names of these things into ChatGPT or Google, and say, "why is my developer insisting that we do it like this when I think we could do it like this?" And then push back on them when they build slow rubbish.

There is a meme and a strategy in SEO to buy your developers beer and donuts in order to get things done faster in the execution queue, etcetera. I say that's nonsense. I say instead, we should be using these kinds of evidence and techniques to weaponize shame, and fear, and to mobilize them into doing better work. Isn't that a friendly message?

So, for example, I wanna talk about — there's a whole bunch of these, and we'll skim over some of them. But one of the most interesting and valuable and important things I think it's worth seeing and understanding as an SEO who is faced with these kinds of big, heavy JavaScript websites — which exist largely because the CMO at some point said, "make it feel like an app," I get it, we want that fluidity or flexibility — this is View Transitions. So one of the things that the CMO wants, and the reason that these app developers get hired, is that when a user clicks a link between two pages, you don't get the browser-native click, wait, white blank page, load the next one. Right? CMOs hate that, you know, because they've been taught that apps are good. Right? And that fluid app-swiping-effect stuff is much better. This, that you can see in the example, is native HTML and CSS, on a normal website, without any JavaScript.

This isn't a particularly sophisticated example, but you can see that as you click links and elements, it feels like it's fluidly transitioning between states, like an app. Then you can make this much prettier and much thicker, etcetera. But the core principle here is: this is a normal website with normal HTML links, a href equals whatever, and, like, three lines of CSS, to say "when I click on this link, execute this animation transition."

And now, I don't know, 50% of the websites that I audit professionally — somebody has said, "hey, help us make this faster. Help us fix this SEO, Google. Why aren't we ranking for anything? Or why is Google not indexing all of our pages?" Still, half of them — it's largely because the root issue is they've built an app rather than a website, because they wanted it to be sleek. And it's never sleek. It's slow and it's awful and it's broken, but that was the objective that they never hit. This replaces all of that modality. And now, in those early conversations, you can say, "hey, instead of shipping 12 megabytes of JavaScript, what if we ship four lines of CSS? What if we just define those transitions ourselves?"

This is a slightly nicer example. This is one line of CSS. One line. The only thing you can't do with this is persistent audio across tabs, which is an anti-pattern anyway. This replaces almost all of the JavaScript tech debt that we have with clients and websites and building the wrong things in the wrong way. Isn't that nice? Yeah. Look up View Transitions and start asking your teams why you're not using this, instead of big hydration booting. I could not — I had a client last week. I was looking at their website. They loaded four megabytes of JavaScript in order to preload the next page so that it loaded instantly for, like, a fade transition. Then all of that in, like, one line of CSS.

So this is actually really funny, I think — really funny, dev-joke funny. React as a framework is only just getting its own version of View Transitions. So the native web platform is now ahead of the JavaScript frameworks and ecosystem. So all of these things are shipping their own worse versions than the native browser stuff on top of it. It's mad. Absolutely mad. You're gonna love the JS pros.

And one of the other things that you might like to look at is pure CSS carousels. Now I will admit that support for this on Firefox is a little bit spotty still, but that will be resolved in the next few weeks. What is a carousel? A carousel is anything where you can swipe or click through a series of components. Two examples in this picture: the conventional kind of product gallery structure you'll recognize, and behind that, the "here are multiple cards you can track and see." So, historically, that is six megabytes of JavaScript and a team of four developers who take four months to ship anything and do so grumpily and badly, in ways that aren't indexed, and they forget to load all the images, yada yada yada. We all know this nightmare. This is 20 lines of CSS that natively replaces all of that and allows you to have all of those interactions and all sorts of stuff. This is trivially easy to implement and replaces all of that overhead.

Also worth mentioning briefly: popover. Anything where you might click an element or activate an element, say by keyboard navigation, to get anything that feels like a modal overlay. So in this example, "I'm a popover with more information," fine. No event listeners, and they would have coded it as a button instead of a link, bada bada bada — hate developers, they would have done it wrong. Now, we can do that same kind of thing with just CSS and just HTML. This is the same code, the same behavior. This is natively accessible, keyboard accessible, performant, indexable, crawlable, fast, easy. This is 30 or 40 lines of CSS animation — I'm just clicking an element, and then that's triggering CSS animations that trigger this pop-up. This requires no JavaScript. Again, you are managing and hiring and employing teams of people whose job is to remain employed and keep drawing a hefty salary to make this feel harder than it is. This stuff is trivially easy.

I'll skip over some of this, but there's similar stuff for dialogues with forms in them. Again, all of this kind of "upload a file, confirm your address, are you sure you want to do this" — those kinds of raw primitive web components, all of this can now be done and styled nicely in native CSS and HTML.

Next up, my favorite, you have almost certainly experienced this as a user. When you initially load a heavy, complex page — think of Facebook or LinkedIn, etcetera — you get this kind of awful skeleton loading interface where everything pulses nastily, and behind that there's, like, React-flavored overheads of lazy loading of components and blah blah blah, and all of this stuff is slamming megabytes and megabytes of data down into your browser so that your browser figures out how this stuff should load, rather than developers thinking about how the server should make it load. Because it's easier to make it your problem. All of this can go in the bin. All of this nasty kind of warm loading state, or below-the-fold state — all of this can be replaced with content-visibility. This is two lines of CSS that says "lazy-load this component." So you're familiar with lazy loading for images. You can say loading equals lazy, and then the thing doesn't load until it's below the fold. You can lazy-render anything natively in CSS on a complex page or a long page — that might shave two to three hundred milliseconds off the rendering and painting process. Two lines of CSS. Hi, developers.

Slightly off-topic, but relatedly: if you want to squeeze even more performance out, you can describe to the browser, using this one line of CSS, whether or not individual components will expand outside of their initial state. So if I have a card — you're familiar with card components as a UI on the web, right? I've got an image and a title and some text and a link. I know that that card will never change color, and I know that the image will never spill outside of that card. If I tell the browser that with a line of CSS, it can be more efficient in how it paints and renders it, and you again can shave off 20, 30 milliseconds. And this is stuff, again, that JavaScript developers will ship megabytes of components and libraries for, which in turn load other libraries, which are loaded on top of other libraries, which all now have critical security vulnerabilities because npm and similar are shipping all of these out. So you can bin all of that, and not just speed things up and make the SEOs happy, but remove masses and masses of security targets on your site.

Also, even more nerdy: if you're animating things, moving them, rotating them, etcetera, you can bin off a whole bunch of JavaScript, historical nasty stuff, around using the GPU to render instead of the CPU, and tell the browser via will-change transform that you are going to change how a thing looks or is laid out, etcetera. And then the browser can put it to one side and say, "we know we're gonna animate this." You will all have encountered scenarios where, on a website, when you click or interact with something, the first few frames of an animation are stuttering and unpleasant. Because the browser didn't know it was gonna be animated. And again, people will ship megabytes of JavaScript in order to preload the animation. You don't need to. You just tell the browser natively with CSS. This stuff is trivially easy.

Next big toy that you should definitely be aware of, because people will ship 12 megabytes — I kid you not — of JavaScript, and React does this: speculation rules. This allows you to intelligently, automatically prefetch or preload the next page as a user moves their mouse over. So if I move my mouse over a link on a page, in the time it takes me to push my finger down onto the mouse and release it, the page has already started loading in the background. Again, there are massive JavaScript frameworks that do this. Most React builds, most Next.js, most Vue builds out of the box ship their own awful version of this, which actively downloads multiple megabytes of unneeded page content in the background. Now the browser can do this natively. You can say what types of URLs to match. You can say how aggressive it should be in the preloading. You can distinguish whether you want to prefetch or prerender. There's more nuance to this, which I don't have time to go into, but you can describe all of these rules natively with a single line of script on your own site that bins off all the need for all of that. You'd be amazed at how many trees and forests these websites are burning by preloading stuff that didn't need to be preloaded, that the user never saw, shipping megabytes and megabytes of JavaScript to devices that never ever use them. It is obnoxious. Like, existentially unpleasant. All of this goes away.

Other nice stuff that you can do now without mountains of JavaScript: style forms. Everybody hates forms. Developers hate forms. And historically, we have all shipped four-megabyte libraries to make dropdown fields look nicer, to put input masking in date-of-birth fields, etcetera. All of that now works natively. This is super powerful and super easy. There are some support issues, I think, around Firefox still, but that's also getting fixed in the next few weeks. This is super powerful.

The really interesting bit, if you wanna get super nerdy, is forms. Now, you can describe business logic in CSS in a way that allows you to do cool stuff, and forms are a really good example. So this first example,

form:has(:invalid)

, lets me say, if this form contains an invalid field — i.e. somebody's not filled out their password properly — make the outline of the form red. Now that doesn't sound incredibly sophisticated, but that's the opposite way that CSS usually works. In CSS, you have to say "target the thing within the thing within the thing and make it work like this," and that's been the world forever. Now you can target based on conditionality in ways that — hey, here's the surprise — take away your five megabytes of JavaScript and all the event handling. If this field has invalid input, change the color of the label red. Right? This is stuff that would have been clunky, or you would have had JavaScript doing custom event listeners, listening to when the user clicks in the form field and when they click out. You've all experienced this. When I click in a form to enter my name and it says "error, you have not entered your name" — because I haven't done it yet. That's because all that clunky JavaScript is not sophisticated. And it was built by morons. You can bin all of that and just describe it in the CSS.

Also, very, very nice: as of May this year, you can lazy-load video in the same way that you can lazy-load images. This is the only time I'll say this, but thank you to the Squarespace team. They sponsor a contributor to the WHATWG HTML standard, and this person just went and wrote a bunch of proposals — and there have been loads of these going back years — but then spent the time describing how they should work in browsers and how they should be interpreted, etcetera, and how they should interact with the poster attribute and preloading. And then the Chromium team picked it up and shipped it, and so did everybody else. You can now lazy-load video with one line of code. Really nice.

We'll skip over that search feature because that's super nerdy. Also, another quick one: if you've got table-of-contents components, typically they use a whole bunch of JavaScript to detect where the user is on the page, and then conditionally format and color, for example, the bit that's active. All of that you can sack off and now use CSS for. Your team of 12 developers can now be two — with a decent AI, maybe even one.

There is so much stuff in this. Again, you don't need to understand it in detail. You just need to know where you can find it, and what you need to Google. And this one's really nice if you're stuck with JavaScript that you can't get rid of. If you have a 12-megabyte JavaScript file that, for some arcane reason, absolutely has to be loaded — and your developers will tell you it has to be loaded, they are wrong, but they will insist — the very least you can do is put this one line of code at the very, very top of it, a compile hint that tells the browser that file is going to be used immediately when the page loads, so it can precompile it in a way that might shave off six hundred milliseconds off the page. So if you're stuck with something that you really can't get around for whatever political reasons, because your devs are idiots, then this might at least catch some of that bad behavior. Pretty nice.

The nice thing about all of this is that all of these browser APIs and systems and capabilities play nicely together, in a way that a lot of the JavaScript stuff doesn't. So if I have a JavaScript-flavored table of contents, and a preloading system, and a video-loading, lazy-loading system, I am reliant on my team of developers knowing what the hell they're doing, working together, and making sure that the stuff they're coding over here doesn't disagree with the stuff they're coding over there. And what? All of this stuff just works. It's built to go together and behave really nicely.

What I'm trying to get across, for your developers, is that the browser's native solutions aren't just simpler, but they're also faster and easier and more accessible. The browser already knows about focus state and tab order and screen readers and paint reflow. When we replace bits of that with JavaScript, by building systems on top of those, we lose a lot of what you get for free — like, how does the back button work? Accessibility, performance, maintainability, indexability, crawlability, discoverability — these are native features of the web which we have erased with JavaScript. JavaScript breaks all of the things that we get for free, and then we rebuild them badly, because we want our developers to get paid for doing bad work. None of this makes sense. Native wins every time.

Further, the other big part of doing this right — and this is a hill I'm happy to die on — means rendering on the server, not on the client. Browsers are optimized for sending and receiving HTML. Sending markup will always beat sending a 12-megabyte runtime. Even ideology aside, server-side-first architectures scale better. They are more performant, they cache better natively in the browser, and they fail better. Progressive enhancement is not a downgrade. It's an architecture pattern which the JavaScript pros have forgotten existed. You can scale up from HTML. You can't scale down from JavaScript. And ironically, some of the newer, more cutting-edge JavaScript single-page-application frameworks are trying to do just that. They're trying to get back to server-side rendering as a default, and they're increasingly just rebuilding things that PHP solved twenty years ago.

It's time to stop pretending that HTML is a legacy format, that it's a byproduct of an application output, and to start considering it as the de facto most important thing that our servers and our systems and now applications — maybe our websites — should be producing. This, I hope, is the moment where the browser starts to get credit. It's not the bottleneck anymore. It was problematic. And in 2012, using React may have been the right idea if you wanted to build something that felt more like an app than a website at the time. Now that is not true. And the whole ideology and approach and modality of JavaScript-centric websites is wrong for where we need to go. It's time for us collectively to start fighting that harder. We have to teach people to trust the platform, to build less, to ship less, to move faster.

So I should note, heavy caveat: all of my anti-JavaScript, anti-framework positioning jars heavily with conventional engineering wisdom. Developers do not like it when I talk about this stuff, because it threatens how they think, and how they work, and how they get paid. And in fairness, we collectively have normalized a world where build processes and bundles and Angular and React and Vue and Vercel exist broadly for good reasons at the time, for legacy pieces. And those practices get perpetuated, and still get perpetuated, because of momentum. And, as a brief aside, because the people at Vercel — who are objectively awful — put a lot of money behind pushing their services and behind miseducating developers. But that's a different story. It's mostly because it's easier for people not to have to care about semantic HTML, about sending the right HTTP status on the server, when you can just abstract all of that away by installing a dependency that installs 12 dev dependencies that install 12 megabytes of JavaScript that will get hacked.

I think it's worth zooming out for a moment and thinking briefly about why this is the right approach, and why a server-side, browser-first, HTML-first approach makes sense now and moving forward. Because if we're going to have to go down this hill, let's make sure it's the right one. The most important, potentially, is accessibility. Because accessibility is what happens automatically when you build with the grain of the platform. Screen readers, tables, focus states — they're not extras that you have to build or add JavaScript frameworks on for. They're built-in capabilities. And the browser gives us those for free if we don't fight it. When we replace native patterns with div soup and custom event handlers, we break all of that. And this is particularly important when you look at the evolving legal space growing in Europe, and now in the US and eventually more broadly, where you get sued if your website is not accessible.

And when I say accessibility, I don't just mean for humans. I don't just mean humans who maybe have difficulty interacting with keyboards, or passing certain color contrast, or focusing on certain areas of the screen, interacting with our JavaScript monstrosities. Because it is not just humans interacting with our pages anymore. Over half of your traffic is probably bots by now. And an increasing percentage of that half is going to be agentic stuff. Search engines, assistants, AI agents consuming HTML directly — maybe parsing, maybe rendering, not yet. And even if they do, they'll still parse your structure, your metadata, and your content. Which is why SSR — server-side rendering — semantic HTML, and clean markup are becoming, and always were, business-critical. If your content is trapped behind JavaScript, or your interactions are blah blah blah, you're invisible to the next generation of crawling, of discovery, of indexing, and render.

So here's the fun twist. AI readiness, technically, and browser readiness become very much the same thing. And it's no more complex than having clean, semantic, server-rendered markup. That's not retro. It was always the right model, and we just got distracted. And the same design principles that make your site resilient also make it legible to AI. So when we trust the browser, we future-proof our content for the next audience — the multimodality, for MCP, for whatever comes next. So this is the real endgame, I think, of the modern stack. We build natively, semantically, and legibly, because we want to build for everyone. Whether that's a user on a slow connection, whether it's somebody using a screen reader, whether it is a Google search crawler, whether it is an AI agent. They all understand your intent and your business and your content and your messaging better, because you let the browser express it in a way that it was designed to in 1996. That's the real streaming revolution — not just faster delivery, but clearer meaning. The web becomes readable again for everyone.

So I think it's imperative that we collectively rediscover the web's foundations, and fight to use those primitives — those new primitives, in some cases — instead of automatically allowing our developers to reach for abstraction and heavy JavaScript that cripples businesses. And I'm saying that caring — actively caring about, and looking about and caring about, your HTML, your CSS — is more important than ever. And I know outside of this, there are bigger, better, newer, faster, more lightweight JavaScript frameworks that purport to solve all of this, but they are still objectively the wrong modality, and the wrong stack structure, for the modern web. So please: build less, trust more, treat the browser as our ally, and treat JavaScript as the enemy, and fight those points, and don't allow this perpetuation of mediocrity. Good luck. Thank you.

Jojo Furnival: So good. What a rousing speech. I feel like — it was like you were, you know, getting an army behind you.

Jono Alderson: I hope so.

Jojo Furnival: Yes. Well, there's lots going on in the chat. We've had a little bit of debate, a little bit of banter, some defense for the hardworking devs out there.

Jono Alderson: But there aren't any. There aren't any. No. Have none of it.

Jojo Furnival: Also, I'm gonna throw it out there that if everybody stops using JavaScript, that is gonna make Sitebulb's JavaScript auditing functionality somewhat redundant. So, anyway — no. But that was brilliant. We have got lots of questions now, so let's get stuck in. Barry has submitted 3,000 questions. But this one's got a few upvotes. So: what's the least shit JavaScript framework? Is there one?

Jono Alderson: It's just come out of my head — what's it called? Astro. Astro is the least terrible. I use it for static site building and stuff, but that comes with its own set of headaches. But yeah, look at Astro.

Jojo Furnival: Splendid. Astro, everybody. Another one from Barry. What about GTM containers and their insertion of JS blocks? How can you manage that? How does he manage that?

Jono Alderson: So I see this all the time, where the marketing department has gone crazy with Google Tag Manager, or a different tag manager. And they've just put in a hundred tags. There are a few really sticky points there that I think are worth looking at. One is consent. Quite often a poorly configured tag manager setup — which, hint, is all of them — are quite often not compliant when it comes to GDPR, the privacy directive, etcetera. And you can make a strong argument for stripping out a lot of that noise on the premise that it doesn't ask for consent properly, and then you can reduce the size of it by 50%. The other thing people don't realize is that in Google Tag Manager, for example, paused tags still sit in the JavaScript that gets shipped. If you've got a hundred tags and half of them are switched off, you're still shipping 50 dead tags' worth of overhead. Don't pause tags — delete them, check them out, version your containers, etcetera.

I would say the inverse is actually quite often the bigger problem — that people will be running, say, Google Tag Manager, but they will also still have a whole bunch of hard-coded Facebook pixels or LinkedIn pixels firing on the page alongside it. Having the robust process where you make sure that all of the third-party tags are in a tag manager container and managed makes sense. There is one strong argument that if you have a very good team of very capable, competent developers, rip it out and do it yourself. Because even an empty Google Tag Manager container is gonna be 80 or 90 kilobytes of JavaScript, multiple third-party HTTP requests with dependencies, etcetera. And even the best setup is still gonna create some overhead and cause some JavaScript headaches. If you are capable — hashtag asterisk, I don't think I've ever met anyone who is, but — you could ship your own comprehensive version. You're stuck with it somewhat, but you can definitely audit it and manage it better.

Jojo Furnival: Okay. This is one from our friend Greg. Could you share a checklist or recommend some browser tools that SEOs could use to quickly audit pages?

Jono Alderson: Yes. I'll give you two. One is Sitebulb. And two, if you want to get a bit more hands-on: just Chrome's developer tools. Like, 90% of the auditing I do is right-clicking on a page, hit inspect, and looking at the network tab and the console tab. The network tab is gold. If you hard-refresh that page and you see a list of every asset that that page loads, in order — what was the file size, what did it load before it, where is it bottlenecked, where are the blocking elements, which domain did it come from, was it cached — all the information that you need is in there. And you can see why does this brochure web page load 138 tiny little JavaScript files from a third-party CDN? That is a great question. And you don't need to be a technical expert to ask that question. You don't need to know what they are. You just need to point at it and say, "this looks bad." And then put the onus on the developers to justify why it's the right approach, and then you can say, "actually, what if we just didn't do that?" So yeah — Chrome is great.

Jojo Furnival: Well, okay. So that moves us neatly onto — because you make this communication with devs sound so easy — and there was another question in here, I think, too, about how do you — do you have any tips, a) for getting devs to listen to you, and b) for getting in on a project from, you know, from the get-go, as an SEO?

Jono Alderson: Yeah. On getting them to listen to you — again, I'll touch on this — the conventional wisdom is buy them beers and donuts. That can work for tactical one-off instances, but it doesn't scale, and it continues to position you as a kind of peasant begging at the gates for crumbs, which isn't how the ship should be structured. It just sounds awful. But weaponizing shame is very, very effective. Like, show them how bad their thing is. Quantify it, using stuff like Google's Chrome network tab and Lighthouse. And then point them at the resource and the kinds of things I've shown them, saying, "so why can't we do it like this?" And then fire up, I don't know, Claude Code or ChatGPT, and ask that to make a better version of it. Show them and say, "look, I did this in five minutes with a naive prompt to an AI thing. Why is ours bad?" And put the onus on them to defend why it's wrong. And make it their fault.

Jojo Furnival: I feel like all devs must hate you. Do they hate you?

Jono Alderson: Yes. Yeah, yeah, yeah. But I get things changed and done and improved.

Jojo Furnival: True. Very true. Okay. So that's —

Jono Alderson: But — actually, we should dwell on that here, because one of the big problems there is the buying-them-donuts approach and similar, and trying to befriend them, puts them in a position of power in that organization that they shouldn't have. Companies should have senior leadership — CMOs, CTOs, etcetera — which decide the roadmap, which discuss priority, which determine resourcing, etcetera. Many, many organizations — because dev is archaic, and because they've been left to do their own thing, and because they're comfortably insulating themselves from the way they should work because they get paid lots, etcetera — means that they've developed this weird culture where they just get work done how they decide. None of that is normal. No other department or team or business function works like that. So breaking that kind of weird fiefdom thing is quite important.

Jojo Furnival: What about — there was a two-part question — what about getting SEOs involved earlier on in the project? Any tips for that?

Jono Alderson: Yeah. That's the dream. Right? It's so incredibly rare. I don't think there's an easy fix for that, other than: look, we just have to accept that we're almost always gonna be brought in totally late, in the wrong team, with the wrong remit. I think the one thing I've found reasonably true is that deadlines are almost always artificial. And that if you get brought in three weeks before the site is due to launch, you can push it back and say, "actually, we've evaluated the risk of this. If we don't fix all this stuff and rip out all this JavaScript, we are going to toast our business for the next six months. So we are gonna slow down our subsequent development for the next five years," blah blah blah. And you can make an argument and say, "you know what? This needs another month," whatever. Almost always, those deadlines are just ego or vanity, or tied to something that can move.

Jojo Furnival: Yeah. Mark Williams-Cook said something very, very similar when he was doing some training for us on website migrations. Basically to say, yeah — why? The deadline is this. Why? Why? And then keep saying why. Like a child.

Jono Alderson: Yeah. Because the CEO has said so — and you're like, "well, I can just go tell him that it's not worth it." Yeah. It's fine.

Jojo Furnival: Okay. So this is a question from a developer. A lot of code is being written by LLMs rather than directly by developers. How do you feel about things like Google and — morgan? — web...

Jono Alderson: Yeah. So this is super interesting, because a lot of the content and code that these systems have been trained on — and a lot of the most popular content on places like Stack Overflow, etcetera — is the bad stuff. It's the heavy JavaScript frameworks, etcetera, because those people are noisy, and it's the norm, and that whole ecosystem is flooded with code samples and drag-and-drop and build-and-play stuff that is almost all bad. So yeah, when you prompt this stuff, unless you explicitly say, "render this server-side, consider native browser performance, make sure it's accessible inherently, don't use a button for a link, actually use a link," and so on — "and do this bloody right" — you get back bad stuff quite often. So you have to make it that degree of explicit.

The good side of the story is that MDN docs — which is the body which publishes all of the kind of formal documentation on "should a link work" and "what is an image tag exactly" and blah blah blah — has an MCP system now. And it's all very LLM-friendly. Web.dev is one of Google's portals for a whole bunch of really, really quite profoundly good education on "how do I build a responsive website, how do I make my API calls fast," and so on, across all aspects of this sort of stuff. It's also very LLM-friendly. So if you're pointing your prompts at the right thing, at least, you've got a reasonable chance that it's gonna do a not-terrible job. And those platforms are brilliantly maintained, really well invested, loads of new stuff coming there. So hopefully they start to win out over the longer term.

Jojo Furnival: Okey dokey. Hector: how does the skeleton loader affect the AI or Google bots' crawling of PDPs?

Jono Alderson: Great question. Goes right back to the beginning of what we were talking about. If the initial response from the server, when you put the URL in, is a bunch of HTML that just says "loading," then that's what ChatGPT is seeing — it's seeing the word "loading." And maybe Google sees the stuff after the skeleton loads — like, how long does it take to finish loading, how many megabytes of JavaScript was that, is it coded in a way that Google will notice when the change happens, blah blah blah. It's a gamble. The chances are, other systems are seeing nothing. Maybe Google is seeing something, and that's why we've continued to get away with these poor architectures for so long. Because Google has got good enough at crawling and parsing and rendering these pages. Other systems aren't. Like, I don't see a world where OpenAI or Anthropic or any of the other big players have enough time or money or runway to prioritize building the kinds of infrastructure and systems they would need to render pages the same way that Google does. Especially as, excuse me, as we all know now, these systems are kind of stuck being built on top of Google and Bing, etcetera, at least for that primary RAG and indexing stuff. So I don't see — will that change anytime soon? So yeah, if your initial state is just a loading skeleton thing, then the actual content is invisible.

Jojo Furnival: Okay. Martin says: my server-side JS compiler vomits a buttload of HTML. I've got paragraphs 12 divs deep, all within the same manic Tailwind classes, but they're stripped out right when fetched. Copy, images and such are in the source. So are all those tips okay?

Jono Alderson: I have mixed feelings on this one. So I see this a lot, and it is viscerally unpleasant. Right? If I wanna put a picture of a cat on a web page, I should have H1, cat, image tag. That shouldn't need repeat, repeat, repeat. It shouldn't need all that. Now, is that the end of the world? Probably not. That stuff compresses phenomenally well if you've got your server running gzip or something similar, which most people do, even out of the box. The browser is quite good at parsing all of that. Except, if you've got a bigger or complex page, that will slow down the painting of the page. And if you've got complex or lots of CSS, it will slow down the browser's computation of all of that, and working out which bit affects which bit. And then if you've got any interactions — like if I click on a thing, it moves a thing or it loads a thing in — all of that will be slower, because it's gonna have to work out how it interacts with all of that page.

Tailwind I'm on the fence about. I think there are definitely strong arguments for utility CSS classes, and that can be better if you've got a team, if it's a project you're unfamiliar with. Generally, it's gonna create more margin than it's worth. I would definitely look — if it's a big site or a complex site, or if crawl budget looks like it's a problem — I would be wanting to strip some of that out. And then you look at the accessibility and the semantics argument. I don't think Google or ChatGPT or any of these systems are explicitly looking for someone to catch a signal — they don't care if it's a div, an aside, or a main. But if using those tags does give clues to assistive devices, to screen readers, it does help demark sections of the page, which might help with performance. Again, it's good for a whole bunch of other reasons. And if you're stuck with div, div, div, div, div, then all of your development work is gonna be 10 times slower and harder. So yeah, I would aim to make that cleaner.

Jojo Furnival: Laura says: do you ever do an SEO induction with the dev teams you work with? Because I recently did one, and it went really well, but I can't tell if it's done anything just yet, apart from getting them more interested in search.

Jono Alderson: Yeah. I think getting them interested is valuable. I think having them be open and willing and wanting to do their own research is useful. Like, there are good assets out there, like web.dev — if you can convince them, get them excited to go and learn, great. What I don't think you can do is brief things proactively. Like, so much of the problem in this ecosystem is people who don't know what they don't know. And your briefing and your induction can never be comprehensive enough to account for all the stupid stuff that they might do. Like, your briefing will never have a section on "and here's why you shouldn't make all of the text upside down on Thursdays." But that will be something that will happen. You can't anticipate that practically. So I think, yeah, if you can onboard them, get them interested, get them invested, tie their success to yours, etcetera — but you can't run a training session and expect them to get everything right.

Jojo Furnival: Yeah. This one is following on from Kev's question earlier. I think it's: can you propose prompt guardrails that can encapsulate the heuristics you're showing today?

Jono Alderson: Yes. These already exist. So Lighthouse will do a chunk of this — Google's Lighthouse tool. I have my own version, which I think is better and a bit ruder. That's quite fun. But yeah. And Sitebulb as well, right? You have some really great stuff that I think is actually quite interesting, because other products don't do this. A lot of these problems exist at template level, or site-wide. Like, if there is, I don't know, an image in the footer that should be lazy-loaded but isn't, you want to capture that, but you don't want to say "you have 3,000 images that aren't lazy-loaded." You want to understand that there is one consistent problem here — right, you wanna gather information, aggregate it at a template level. Google's Lighthouse scores, aggregated and averaged across templates — really, really useful. And it will flag things like "the largest image on the page takes forty-eight seconds to load." That's not cool.

And it will benchmark that through time. Google's CrUX data will give you that for real users through time — you don't have to opt in for that, they collect it passively through Chromium browsers, and some Firefox. You can go and look at all of your Core Web Vitals scores through time. That's quite nice. And then, if you want to get even more advanced, you can run your own version of Lighthouse. You can put performance budgeting in. So you can say: when our developers ship a new bundle of code, in the process of it going out to GitHub, wherever it goes, run this scan. And if there is more than a two-hundred-millisecond delay on this page, deny it. And flag it and throw it back at them and say, "nope, you've crossed us." So if there are more than 12 JS files, or whatever, you can set all those criteria, and then you've automated all those guardrails for the more easily detectable, obvious day-to-day stuff. And again, a lot of that kind of approach makes sense, because if your approach is "try and convince and control, try and buy them beers and donuts to get them to fix one thing at a time," you just end up stuck in whack-a-mole hell, and you never get ahead of it. Like, you need them to be building inherently good stuff. Putting those frameworks in place. So yeah, great question.

Jojo Furnival: This is another good one. And there was a similar question — well, Barry had a question around how do you recommend staying up to date? And this question is: where should somebody who's new to SEO — where can they learn about CSS and HTML?

Jono Alderson: Excellent. I will answer the same to each question. Web.dev is great. And I guess — this is Google's; I think they have an aspiration that other people get involved, but this is the home of all of the documentation on best practices and standards for "how do I center a line natively efficiently," etcetera, etcetera. It's really, really good. Some of the smartest people I know work in, like, Google's performance teams and stuff, and they author a whole bunch of those documents. Go search on there for anything written by Barry Pollard. Read anything he's ever written. You will learn far more than you ever thought you needed to know about how browsers put pictures on screens. And this stuff is super relevant, right? I know it's technical SEO, but how browsers paint pixels onto screens is such a fundamental architectural layer of everything else we do. How they evaluate content, how they crawl, how they allocate resources, how they understand what they see, how they prioritize — all of this is built on this foundational level of graphics cards painting pixels. So it's worth having some understanding of how those layers and systems work. And HTML and CSS are definitely a good call of that.

Jojo Furnival: Amazing. Oh, we've got — well, I'm gonna put this one on, because Doug is desperate for you to just hide the thing, the bottom — the sharing thing that —

Jono Alderson: No. It's too late. It's too late. I noticed it, but it's too late, man.

Jojo Furnival: No, because it might be for screenshot purposes. Hey, there we go.

Jono Alderson: You just wanna see my hyper-organized toolbar at the bottom there.

Jojo Furnival: You know? That is it. That is time. So thank you so much. Thank you to everybody for attending. Thank you for the questions. Thank you, Jono, for your time. Our next webinar is a tutorial with Tory Gray on building your own AI skills. That's in a couple of weeks' time. I hope to see you then. Goodbye.

Jono Alderson: Thank you, everyone. That was lovely.

The speakers

Jono Alderson is an award-winning technical SEO consultant who helps brands to compete on technical SEO, website performance, and structured data. He's spent the last few years pulling apart JavaScript frameworks to work out what browsers can now do without them, and this session builds on that work — why so much of the modern web is over-engineered for problems browsers solved years ago.