Optimizing Third-Party Loading in Next.js with Houssein Djirdeh
===

[00:00:00] Hi there, and welcome to PodRocket, a web development podcast brought to you by LogRocket. LogRocket helps software teams improve user experience with Chess and Replay, error tracking, and product analytics. Try it for free at LogRocket. com today. My name is Paul, and joined with us is Hussain Jirdeh. He is a senior software engineer over at Google, and we're going to be digging into his latest talk that he gave at Next.

js Conf that just happened in 2023, optimizing third party loading in Next. js. Welcome to the show Hussein.

Thank you so much. And thank you for having me.

This is kind of an interesting topic because third party loading is not something that everybody thinks about when they think about features and plugins and even like how to do something right. So third party libraries, what are they? What are we talking about? And why is it like a stickling point if you're trying to build a performant website?

So the way I like to characterize third parties are essentially anything that's outside of the control of the developer, but is [00:01:00] included by the choice of the developer. So you can think of it as any sort of functionality they want to include into their site. But they would rather not actually write it custom.

And they'll likely just pull it off the shelf. It could be an NPM library. It can be a CDN script tag. You know, It could be a style sheet retrieved from elsewhere. It's just anything outside of the control of the developer. And one of the reasons why, my team and I were focusing on it quite heavily is, and I can go into a bit more detail about my team, is we look at a lot of sites in general and how well they perform.

And one of the biggest performance issues are third parties, because as you can imagine, If it's not in the control of the developer, if it's causing issues, there's not much a developer can do, right? So a lot of the, right? And a lot of the times when we see like, Optimization guidance or even conference talks is usually about the control, the code that's in the control of the developer, which makes total sense.

But you're missing a very big piece if you're not also considering the third party code you're including.

Gotcha. So that kind of makes sense. We're talking about things that a developer might bring into their project [00:02:00] that they don't have inherent control over. I'm thinking about script tags and stuff like that. And you mentioned your team, right? So you guys are looking at sites, their performance, the team you work on Google's Aurora team.

Am I saying that right? 

Yeah, no, you're saying it perfectly right. Yeah, our specific team is Aurora, and we're part of Chrome. A lot of the times when I describe my team, I just say Chrome Aurora. So I just combine those two words. Google Aurora is also fine. But yeah, what we do in our team is we work with open source frameworks and tools in the JavaScript ecosystem.

And we try to actually improve them from the source. So the idea being is, there are millions of developers that use popular JavaScript frameworks and libraries. And if we actually want to see a shift in web performance and in any aspect of page quality of web we need to improve the tools that so many developers rely on.

So hence why we collaborate very closely with the Next. js team and why I also had a talk about the work that we do at Next. conf.

So , how did you get into this field of research into the Google? Stack [00:03:00] and trying to help specifically next JS because as somebody who's like also used it on the side You're like wow Google's watching us and they're taking stats at like I didn't know that so how do you how'd you get into that?

Yeah, no, that's a great question. I can also give some background about myself. After I graduated out of university, I worked at a few different companies, and then I started just doing web development. I worked in a pretty large consultancy first, and then an agency.

And then, you know, during my free time, I just happened to be very interested into web performance. Right? I was very fascinated about what makes certain websites load faster than other websites. And this is prior before joining Google. So I would give some small meetup talks. I had a very small blog that I would write some articles on.

And in the agency that I worked at, we were using different frameworks quite heavily. So we had a ton of different projects. And we would use angular for some react for others, right? So I was also just very in tune with what these frameworks did. So the angle that I always will try to look into it was, if a developer is relying into, [00:04:00] On one of these frameworks, what can they do to improve the performance of their site?

And then I, I did some open source work. And then I joined Google as a developer advocate at first. And the focus was web performance. But because I had that framework angle to begin with, a lot of the guidance that I put out was very framework related. And I think a lot of developers also related to that.

And then after a year and a half, I think, or two years, of being a developer advocate, The Aurora project was being started by a different team in Chrome. But it was also very similar to what I was doing in general, right? And I was just very interested because here I am giving out guidance, like telling developers, hey, here's what you should be doing if you're using React or Next.

js and so forth. And then I found out there's a team in Google that's considering collaborating with these frameworks. So I just reached out, I started working with them on a part time basis, made a transfer to be with them full time. And yeah, it's been going pretty well ever since. And we started, I think, our collaboration with Next.

js. The Next. js team has just been a pleasure to work with. But now we're also collaborating quite heavily with the Angular team, with the Nuxt team, and so forth.

and [00:05:00] we're obviously focusing on the third party Library area of your research and your team's research here and how that affects websites What caused you guys to turn your eye and your head in that direction of focusing on that? What are some of the research the results? And what made you hop beyond this is not a correlation causation, like happy accident.

Like There's something real here.

so third parties are not our only focus. It just happens to be what I am focusing currently quite heavily on. And I think now our biggest project with the Next. js team. The way we tried to look at this in the very beginning was, a lot of teams, including ours, In Chrome, we tend to do a lot of research, We want to see what makes websites tick. What are their biggest issues, right? When we actually trace, say, every React site out there, and we notice that, I don't know, a significant portion is not doing very well, we want to know why, right? Is it because they're loading very heavy images? Is it because they're loading a lot of third parties?

Is it because they're using, I don't know, certain tools that are causing these issues? Is it because of the developer, right? So we've done [00:06:00] that quite a bit and the way we started working on different projects was we tried to find what the biggest issues were and then think about ways we can make the default experience in a framework like Next.

js better, but also make the developer experience better. So Next. js, the image component was one of them, right? So we noticed that a lot of sites that we trace tend to have very large images. They're not compressed, they're not optimized, they're not being lazy loaded. And then we started working on the image component with the Next.

js team to solve these issues. And then, ever since I even joined Google, third parties was always a very big thing. Every single time we trace a site, many times a developer could be doing super cool optimizations to make the site work well, but then they're loading 20 third parties that are performing, either blocking the main critical path, or it's causing layout shifts and so forth.

And it's definitely, I think, from, in my opinion, a bit trickier, because here we are trying to think about ways to mitigate that third party impact. But at the same time, we again, don't have access to that third party code, right? So we've been thinking about different ways for quite a while. And then we had the idea of the script component.

[00:07:00] And then my talk in Next. js was the successor to that, like the next third party's library. What can we do to make this build up experience of loading popular third parties easier, but also try to mitigate that user experience hit as much as possible?

Gotcha. So what would you say is the defining line between me importing my like Calendly component with the script tag and the ethos of the the new package that you guys are putting out here,

Yeah, no, that's a great question. So when we rolled out the script component, and one of the engineers on my team, Ralph pretty much built the entire thing. He had the great idea of could we make it easier for developers to control when certain third party scripts load? And if they don't really know, make that default experience load after React either fully hydrates or at least partially hydrates on the page and like the majority of Next.

js chunks load. So we definitely wanted to make that default experience easier. So quite a few Next. js sites use a script component. It makes things a lot easier in sense of also just [00:08:00] loading third parties. Now, developers just don't have to worry about how do I include a script, normal script tag into my Next.

js app. There's a built in component for that. Things like, oh, if you want to move to the app router, we'll try to make sure that the process remains the same, just use the same script component. So a lot of developers found a lot of success using it. But we also got a lot of feedback coming in where they're like, okay, this is great.

But it also isn't really fully the easiest way to load certain third parties. For example, you made the calendar example. You still have to do some control, right? You still have to think about where do I place the script component? Do I use beforeInteract? If the afterInteract, the strategy lays on load.

So there's still some sort of control, which is good. You want to give developers enough control. So one thing that we thought of, what if we can just make loading popular third parties a lot easier? And if developers want to have more fine grained control, they can just fall back to using the script component.

Say Google Tag Manager, for example. I don't know if I remember the exact number off my head, but at least 50%, possibly 60 percent of all Next. js sites use Google Tag Manager. So I think the numbers are probably the same with React and other frameworks [00:09:00] as well. So many developers use Google Tag Manager.

So many developers are probably confused about how to use a script component with Google Tag Manager. They also don't know if they're doing it the very best way. So what if we just had a library that made you plug in a component? And, you know, at least there's a team that's trying to optimize it to the best of their ability.

We'll take care of the work, trying to figure out if it's the most optimal way to load. If there's a better way we find out in the future, we'll figure that out as well. But again, if you really want that fine grained control yourself, you could use a script component. But we think at least giving that easier ability is going to make a lot of developers lives easier.

So it's just, you guys are essentially answering a customer need here. You're building on the immediate, just people are saying, Hey, like we want the most optimized way to do this. Can you do it? And you guys are doing that research. He's doing the legwork. What's an example of an import that somebody might give with a script component that you would say, objectively, that's probably not the best way to do it.

So we patched it. Let's run with the GTM example, the Google tag manager,

[00:10:00] so like, right now, if a developer wanted to import Google Tag Manager, you'd have to go to the Google Tag Manager documentation. Find that sort of inline script that they suggest, copy it, paste it into the script component. And then you also have to decide, okay, this should just be in like the layout level, the page level, component level.

Once you do that, you might also have to think about which strategy do I use? Do I use the default strategy the script component gives me? Do I change it? Because one thing that a lot of third parties suggest is they tell you to load their third party, the earliest possible ability.

of course.

And because for the third party, that's what they want.

They want to make sure that the third party actually fires. But you can also imagine a lot of developers reading the documentation might be like, Okay, I'll just use the before interactive strategy, make sure it loads before even Next. js loads to my page. And that's a big no in terms of performance, right?

So like there are some of those easy like foot guns developers can run into and we're trying to mitigate that especially if we're very popular third parties. So it's hey, instead of you having to think about that process, possibly making the mistake of loading something way too early when you probably [00:11:00] shouldn't, just use our component.

We've done the research, right? And obviously, if we think about future optimizations, we can improve it. But just use what we have now. And then, we're not going to be able to support every third party out there, but at least for the very popular ones, like Google Tag Manager, Google Analytics, Facebook Pixel.

We can at least do our best to do so.

yeah, I'd actually love to get into a little bit about where your sites are now and where they're going to be with what's being supported. Right before we do that, though, I just want to remind our listeners that this podcast is brought to you by LogRocket. So if you're making the next app, or any type of app, and you're targeting like load issues, how do you optimize your page, LogRocket can definitely help you out.

You can find and surface trends you might not have noticed. heatmaps, session replay, and all sorts of great stuff. So head over to logrocket. com today. You can spend more time building and less time debugging. Turning back to what your team is currently building with the next scripts, what is implemented right now?

What are some of the things that you can share with us that you are going to include [00:12:00] into your research? And is there anything that you have marked as, that's just not in the domain of what we're going to be roping into the timeline here?

Yeah, right now, we are very early. The next third party's library is still experimental. It's going to go through a lot of changes. We've just introduced some very early third parties. So Google Maps Embed, YouTube Embed, and Google Tag Manager to start. For Google Tag Manager, right now it's just a pretty basic wrapper around the script component.

And then we also give like a send GTM event hook to make it also easier to send GTM events. Now we think that's definitely the suggested approach, right? And honestly developers can do the work themselves. The wrapper doesn't add that much complexity just yet. What we want to do in the near future is one thing we've been trying to see is, could we make the process of offloading to a web worker a lot easier?

So I think about a year ago, maybe a year and a half ago, I rolled out a worker strategy for the script components to make offloading to a worker using party town possible next. Yes. It's still, that's also experimental, [00:13:00] but one thing we've noticed that a lot of developers have when they try that approach is they've run into a lot of issues because a sometimes they don't know when their third parties are actually working in a worker.

They don't know what's happening. Be if they. say, the third parties are failing to load in a worker, they don't exactly know how to solve that issue. And then there's sometimes there's a lot of work you need to do about setting up reverse proxies and just solving CORS issues to make sure that scripts just run in a worker.

So a lot of times we see feedback saying, we want to use this feature, but it's still a lot of work trying to set things up to put into a worker. So one idea that we had was, now that we're building sort of like this opinionated next third party's library, What if we can make the process of offloading to a worker a lot easier?

So in a future iteration what I would like to see in the Google Tag Manager component would be most likely an opt in Because it's still a an early idea, but hey, you can use the default approach but if you want to use a worker use this, I don't know prop or hook and We've set up a [00:14:00] lot of the tooling for you And we'll also do our very best to make sure that if you're running into issues, we'll flag those issues for you Just to make that developer experience a lot easier.

So that's one thing we have, I think, planned in the near future. We're also planning to just roll out a lot more third party support. Google Analytics, Facebook Pixel, are the next two we'll likely include. And the way we've been trying to include third parties, honestly, has been in terms of adoption.

It's got like, what are the most widely used third parties out there? A lot of Google ones are. Facebook Pixel also is one of them. And then we're actually going down the list from there. And we're also trying to see... If we do include this third party, can we make the biggest performance win for developers while also minimizing developer experience?

One thing that I don't want to happen in the future is see just this support, provide support for hundreds of third parties, but not actually make any significant difference for those third parties. So we're trying to at least start very small and then grow very slowly. Another thing we're also actively doing is whatever things we find from building this work, we're also trying to talk to third party providers themselves.

Kind of just give them what we've learned, right? Say, [00:15:00] hey, we've rolled out this tool in Next. js. We're experimenting with a worker approach. Here are our learnings, right? Maybe we're like, oh, we need to see the third party get better from the source by just yielding in better ways that we can't do ourselves.

We can try to bring that conversation back to third party. So that's something else we're also trying to see. 

We got a little bit of, about what's here, what's coming. Even some methodology. You guys are going a slow burn to make sure that you're making the nooks and crannies of optimization realized where they can be.

Exactly. Quality over quantity.

Quality over quantity. Love to hear that in this day and age,

Right? 

so who is like the main customer of this package? Obviously it's somebody who has a Next. js site, but like me with my blog, I don't know if you're thinking that type of person would benefit the most from using third party imports or is it somebody that has like bunch of them? Or maybe the person who does a bunch of them already knows what they're doing.

I'm not sure. 

Yeah, I think the way that I see it is we're trying to make the biggest impact [00:16:00] earlier on, right? I think that's why we're trying to focus on the more popular third parties to begin with. we know, say, hey, 50 percent of Next. js developers are using this third party. A lot of the research we've done has seen that this third party causes issues.

Let's roll out a solution to make even a significant chunk of that 50%. sites faster, right? So that's the kind of approach that we're doing. And I think so our target audience would be definitely any Next. js developer that uses these third parties, right? Whether you're building a very small blog, whether you're building a massive site anyone that's using popular third parties, we hope would like to just use this wrapper to make their lives easier.

That being said, we do think the likelihood of sites that are using this and leveraging this would most likely be sites that have so many third parties. And just don't have the time to try and optimize it themselves, right? It's like they're working on so many different features. They've got a bunch of things that they need to ship.

Let's just use the Aurora suggested approach and not try to fiddle with the optimization themselves. We do think this also applies to, developers, like single developers building very hyper [00:17:00] optimized sites themselves. But chances are they will also have some of the know how, maybe the time, to look into PartyTown themselves or...

Maybe look into the script component themselves. We definitely want to make this a lot easier for everyone. But we think the larger sites, we're going to see the more benefit, I think.

And I haven't asked this question earlier on, I don't know why, but is this an open source project? And yes or no, depending on what the answer is to that, how do you see expanding what gets brought in there? Expanding the team, slash how can developers get involved if they're interested?

Yeah, it is open source. It's a standalone package. Maybe I should have mentioned that too. It's not part of NextCore. It's literally just, it's part of the monorepo. But it's just a separate package. If developers want to include it, they'll have to npm install next to their parties. If they don't want to include it for whatever reason, they don't have to.

The code is available to anyone. I've published a I think one RFC or maybe two, definitely one, but I may have published two on the GitHub repo for Next. js. If anyone has suggestions, please comment there. If you want to even open up issues, feel free. Tag me. [00:18:00] Now that the library is still experimental, we're trying to just get as much feedback as we can, right?

Like what issues are people running into? to see instead of say, a component that will make the developer experience better? That kind of feedback is super useful to us. And one thing that we're also thinking about very actively now is a lot of the guidance we're including for this specific library, could we consolidate it somewhere to where other frameworks and other developers can pull in that same guidance?

So one thing that I started, it's also very early days, is this repo called Third Party Capital. And all it is right now is just a bunch of JSON files. But it's a schema that's trying to tell developers what the best way is to load popular third parties. The next third party's package uses this right now.

And we're working with the Nuxt team to also use that same package. The idea being, moving forward, if say, for a certain third party, we find out that there's a better way to optimize its loading, instead of going to every one of these frameworks, or reaching out to every developer that's using these libraries, and say, hey, actually you need to switch, [00:19:00] or shipping PRs to make them switch their technique, what if we can just do it in one place, so that all the consumers can benefit from it.

So that's an early idea, we're currently exploring that too. But if people also have feedback from that's also open source. That project is called Third Party Capital. Feel free to comment. Any feedback would be super appreciated. 

Now, some question that might be a little global here. If you're looking at all your research and all these repos, and maybe you're looking at this JSON repository, right? Of how to load things. Is there a takeaway? That you feel like, or opinion that you might have slowly grown in your head about the way that you have observed the developer body in general of how they interact with third party libraries and scripts. Do you notice a trend that maybe you didn't expect to notice?

, I don't know if this answers the question, but before we started this project, we actually weren't 100 percent sure that it should be a library. Right? One thing that we thought of earlier on was maybe we just need better documentation. Can we like just roll out better documentation [00:20:00] to tell developers what's the best way to load popular third party?

One thing we found out even like after rolling out the script component was some developers yes will leverage those that documentation, but a significant number of developers just don't have the time or energy to think about their third parties, and they're just going to include it for marketing reasons, business reasons, and they just need to work on first party code, and they'll see a performance hit because of third parties.

And I've talked to so many developers that just say, I don't know what to do. I don't have the time to look into it. That's spurred us and made us realize we do need to actually ship wrappers and code to make developers lives easier. 

I think that also hails to the, I'm buying this thing. It's a product. The product should just work. Obviously there's things to consider, but that meant consumer mentality.

Developers are consumers too.

No, a hundred percent. And that's a very good point. It's and for many developers, you can't blame them, right? Like they're pulling in a library. They're following the recommended approach given by the third party provider. They're seeing a huge performance hit.

And I think for a lot of [00:21:00] developers, it's a decision of either I include it or I don't include it. And for many teams, not including it's just not possible, because maybe they're getting the marketing or someone telling them that they have to include it, right? So as a developer, you're stuck. It's what do you do in that situation?

And I think another thing that also might answer your question was, very early on, before this project even started, before the script component even started, I was under the impression that we can make a change directly at the source of third parties. It's Instead of having to build these wrappers, right?

An ideal situation is to make the third party code as optimized as possible so that everybody that uses it benefits, right? So I was always under the impression that we can just have conversations with third party providers, convince them to make these changes. And, sometimes, yes, that can happen.

And many times I've had these conversations and they've been very eager to. But then when I realized after I joined Google and after I started working on the Aurora project, is that for many of these third party providers, Their priorities might not only be performance, right? Plus, when they're, let's say, shipping third party code to the majority of the web, they're very careful about making changes, [00:22:00] like even incremental changes to improve performance because they can't even take the risk of seeing lower click rates or lower, I don't know, impressions, right?

So that's one thing that I've realized is that, yeah, that's something we're still trying to do, but that can take years. Where previously I thought it was just a bunch of conversations and let's, get performance in built in really quickly. But then that kind of also made us realize we need to build this code for developers Because that might take years might take him even take four or five six years developers need a solution now.

And what about future proofing? Are there any things that you and the team have thought about in terms of we're putting in time and effort now, this, there might be a sync synchronization drift right between like how this third party library works, and how we're actually optimizing it.

Yeah, we are thinking about that very actively now and I think that's one of the reasons why we built that third party capital library is If we can just have a single source that shows what we're suggesting to developers I think it also makes the conversations we have with third party providers easier, right?

So down the line if we [00:23:00] say Hey, here's this library that three or four framework consumers are using. Hundreds of thousands of developers are relying on it. Here's our suggested approach. Does this look right or should it change, right? And if they say, no, I think you should change the loading strategy from whatever async to defer.

We can change it in one place, as opposed to just trying to explain how we've plugged this in to so many different frameworks. that's one way. And I think the more leverage we get in the future with more developers relying on this one tool, as well as like next third parties and so forth. I'm hoping the more conversations we can have with third party developers to tell them, Hey, there is a need for this.

So many developers are using this, right? If there's any changes that think you, that are coming in the near future, let us know before you ship it so we can actually make millions of developers lives easier and not make them, harder with the new change coming in.

And just to reiterate, when you said there's already third party libraries and people might, you know, they have to include it because another department needs it in there, that's one user story we can think about. But there's also that other one you mentioned, which is that they might not just [00:24:00] maybe not include it, go use something else.

Do you find that this initiative being put forth by Google and your team is going to have more a result of speeding up that which exists? Or is it gonna, in your mind, more importantly, open up that funnel to let people experience the benefit of third party plugins where they might not have originally dipped their toes into?

Yeah, I think the latter, right? Because

I think the way I look at it is, say, as a developer, you're very concerned. You don't want to include this. Third party library, because you know, it's going to affect your performance. You don't even know exactly what you should be doing to include it. And C, you don't even want to take the effort to figure out how to do it and say your next JS app.

I'm hoping that a lot of those developers can now see, Oh, wow. Okay. There's a Chrome team that are working on a recommended approach. Not only is it going to improve performance. It's also just so much easier to plug in. I don't have to worry about plugging script tags in random places. I could just import a React component, stick to idiomatic approach.

So I think [00:25:00] a lot of those people that are very concerned, hopefully their lives would just be so much easier and they'll start to see that very early on.

Awesome. Hussein, if people wanted to keep up to tabs themselves with the development going on with the next third party's library, like you mentioned, it's in the mono repo, right? So you can go check out the source code there. Do you have any postings pages or forum sort of spots for the Aurora team?

Yep. Like your first comment. The package is open source, anyone feel free to take a look at it. Leave comments. Just any certain third parties you want to see included. Let us know. Let us know why. And yes, we do. So right now I think it's developers. chrome. com. I think, I don't know if I have the URL right, but developers.

google and look at the Project Aurora landing page. We have a landing page there of just all the work that we're doing and. In the coming weeks, I'm hoping to include an article, at least, if not more about why we're working on this third party effort and like our roadmap of what we're thinking in the near future.

So definitely take a look at that. As well as Twitter, I try to be as active as I can [00:26:00] on Twitter. So if you have any questions that may be better in a DM format or you want to tweet at me, feel free. And I can just reply back and let you know what we're thinking.

And since we are having a kind of a technical in the weeds conversation, even about a particular part of the monorepo, what is your GitHub handle if people wanted to tag you, bring up an issue or something? Cause I know you mentioned people should feel free to do that earlier on.

Yes. Yeah. So my GitHub handle is my first name and last name connected. So it's Hussein Jourdain, H O U S S E I N. D J I R D E H.

Awesome. Hussein, thank you for your time coming on. It's been a pleasure talking about next third parties. It's something that everybody uses, though a lot of people don't want to spend a lot of time thinking about. So we appreciate the effort you guys are putting in over on your team. But yeah it's been a pleasure having you on.

Thank you. And again, thank you for having me. I hope this makes a lot of people's development and user experience lives a lot better. Thank you.