Pratique du Shadowing: Next.js 16.3 got good (if you care) - Apprendre l'anglais à l'oral avec la vidéo

Choisissez un mode d'entraînement

Chaque mode ouvre une salle d'entraînement en plein écran.

218 phrases

Si les phrases sont trop courtes ou trop longues, cliquez sur Edit pour les ajuster.

So in the last two weeks, I was at Next.js Night London, and I was at Next.js Night in Amsterdam.

And at both of those events, I got to see members of the Vercel and Next.js team show off Next 16.3.

And admittedly, I hadn't looked at Next in quite a while.

I think my last real busy experience with Next was back in the day

when everything was cached and there was sort of nothing you could do about it.

But seeing how it's changed, and I saw the launch of cache components, I think, at last year's Next.js conference as well and seeing where the 16.3 preview is going.

It's really cool to see the emphasis on declarative cache controls over everything, which is excellent.

So you can be really specific about where you want that caching to be.

And also just to see how much dedication the team has to making sure that your application is fast.

And that's what the topic of my talk ended up being about.

I've been thinking a lot recently with my job at PlanetScale about reducing people's egress.

That is the amount of data that is being fetched from your database.

and I'll go through that in my talk, which I'm going to present here in this video.

But the reason I've titled this video what I have is like Next.js is back if you care, is that you need to have a degree of care to make sure that your application is really,

really great because the team building Next.js, it's very clear they desperately care about making sure your application loads really quickly

and it's as smooth and as good an experience as possible.

But while you've never been able to build apps faster than ever and you can build NextGest apps so quickly, you can build any kind of app so quickly now,

it's still not going to be excellent if you don't really care.

The agent's not going to care for you.

So it's about you knowing exactly what you want from your application and what is making it slow.

And if you don't know what's making it slow, I think that's probably what I'm most excited about with some of those updates.

And I want to show this off first.

This is the application that I chose to build for my talk at both of those nights.

And it's a NextGest application.

It's It's kind of like a block editor, like a rich text editing sort of experience like you'd have.

It's backed by Postgres database.

I've got a list of pages on the left-hand side that I'm working on, and I've got a title here and some blocks to be writing there.

But this insights thing, this was instant insights.

This is really cool to see is that if your app isn't as fast and as smooth as it could be, Next.js will now tell you in development mode, and that's really cool.

And there's all these different ways to copy prompts here to say, hey, would you rather stream this in and have a skeleton?

Or would you rather cache this if you know the parameters ahead of time?

Or are you just okay with this holding up rendering on the page?

And perhaps you can set a way to say, hey, ignore that.

And again, in a really declarative way, this is what I want my code to do.

And being declarative, a word I'm going to use a lot in this talk, as well as the word cache, definitely I'm going to wear that out.

It's good for a number of reasons.

It's good for you especially to know sort of what you want the code to do.

But it's good for agents as well the more hints

that you can leave through your code base of how you want things done, the better agents will work with that code.

And they'll continue to implement those patterns if they see why those things are implemented.

They'll only fetch the data that they need when they know what data the application uses.

So being very clear about your requirements has always been useful for humans.

It's especially useful for agents as well.

So without any further ado, I mean, what I'll do is I'll go back to cursor here and I'll put this code back in.

I had really optimized this app.

So I had thought before I built it.

And then I went to the first next year I was in Amsterdam and saw them show off these instant insights, upgraded to the preview and it spotted that this was an optimization that I could have made.

And so now the app loads really, really, really fast, which is excellent, faster than it did before.

So let's go and have a look at the talk.

So the talk that I gave was titled Faster and Cheaper.

And that's kind of the typical PlanetScale experience when you come and grab a PlanetScale database.

But this is the experience that all of your applications should have um

so at best

when you're working with ai development the code works right like that's kind of the baseline

that and and that's what you really want

and i know a lot of people have made an argument

that taste is going to be the differentiator and i'm not sure

that i agree with that personally because you know and i know

that there's a lot of applications and services

that are they dominate their sector they dominate their industry

and yet they're quite terrible applications we all have worked with those applications we didn't want to before

but that's just what the sector uses so it's great

that the code works

but ideally i hope this is why you would go to a thing like next.js night

and this is why the people who build next.js are building it the way they are

and and that's why you're watching this video is

because you want to make better things um ideally your application's fast

and it works really well and it's very smooth that's that's the that's the better state

but but it only gets there if you care.

And at worst, and that's what I really want to highlight in this video today, is at worst, if your application's bad, it's not just slow, but it can cost you money.

If your application is fetching too much and too often, you're going to run up your egress rates.

And so like your CPU is going to work too hard.

You're going to fetch too much data too often.

And that can add up when you hit scale.

You don't want to, you know, the thing used to be about, if I hit Hacker News, I don't want my website to go down.

You know, I think that's less of a likelihood now.

But if for whatever reason, you know, your app hits wild popularity and all of those unoptimized fetches you were doing, now they quickly add up.

You blast through your egress quota.

It can cost you money.

So it's important to look at slop for both making your application faster, but also make sure it doesn't cost you money.

And prematurely optimizing is not a bad thing in this instance.

You don't want to wait until you get that scary bill.

Oh, no, you hit scale.

Now it's cost you a lot of money.

You don't have to wait for that moment as a forcing function to fix these things.

You fix them in advance, you'll get a better application sooner.

So I wanted to illustrate a few patterns that are really worth keeping an eye on when it comes to developing.

So you know and I know we don't write the code anymore, right?

But there are still patterns in code that as of this moment, agents will typically get wrong or bad.

And this is what I really want to highlight here at the moment is

that I'm not saying here's a code snippet you should copy, but rather here's the sorts of things that agents will do unsupervised.

And you could take like this video or my blog post

that I wrote about this on the PlanetScale blog and give it to your agent and say, hey, just check out these patterns.

And it'll, you know, do the job of double checking.

But I think it's worth building your personal context to know what to look for, to make sure the apps that you're building are really, really good.

And so here on the left hand side, like just having a query function from here's like I'm using

drizzle orm you know just having a query that's going to

select every column from a particular row that's going to fetch way too much

or worse again because it's imperative you're not saying exactly what you need it's unclear to the agent

100

and to humans what you're actually using in the application from

101

that row in the database

102

so returning only what you use there on the right hand

103

side that's really important for both things to limit the amount of content

104

that you're pulling and also to make it very clear what you need

105

because you know in this instance get posts that function is probably pulling this post list on the left-hand side.

106

And I don't need to pull in all of the content.

107

If I was grabbing everything, I'd be grabbing this whole content column, which is a huge JSONB column.

108

So you can imagine how much slower it'd make this query

109

to fetch all of those every time I load the list of posts.

110

I don't need to do that.

111

I only want what I need.

112

So you also want to make sure that you're returning less data.

113

So this is an instance where writing which is ingress can actually become egress.

114

And that is to make sure that, if your function has this method on the end,

115

this returning one, which I was only writing another demo application today and it did this exact thing.

116

You know, I was writing something to the database and it just returned everything.

117

And this will actually return more than you actually wrote.

118

So if I was to just like update the post and update the title, but say, hey, return everything from that row.

119

Again, it could be returning the entire JSON body of that big content area, which again, it's not what I want.

120

So only return what you need if you need to return anything at all.

121

Agents will typically write too much code.

122

And so they'll return the whole row, even if you weren't using it in the application.

123

So you want to fetch less often.

124

And that's where we start to use these caching functions.

125

You might have different frameworks, different places to cache.

126

Next.js's caching controls are really, really great.

127

And here you can see this declarative nature of them.

128

So first of all, when you write use cache there, that's part of that cache components.

129

That is a signal to Next.js.

130

I want you to cache this function invocation and the parameters that it has.

131

And then you give it a name.

132

So you write this cache tag here.

133

You say, I'm using this human readable identifier to say that

134

if I ever want to invalidate this cache and force a revalidation of it, then I just need to invalidate this particular tag.

135

And so that's what the relationship of these two things.

136

That one, top one, use for cache, that's for Next.js, cache tag, that's for you.

137

And so to have that same getPost function from before, but then have a cached version of it, that means that I can still fetch on demand when I want to have fresh data,

138

but I can fetch a cached version of it, which is going to be much faster as well.

139

And this can be dynamic too.

140

So if I'm going to get the post by the slug, then I can use a cache tag there that is dynamic in that it's using just this unique value,

141

which means I can still invalidate just that page and just that fetch in the cache.

142

So we want to invalidate and refresh on demand as well.

143

So there's instances where you might want to revalidate where it's

144

okay to leave stale data on the page for a short amount of time.

145

There's going to be instances where that is definitely not okay.

146

So for example, deleting a post from the database, I want to update this tag to say, hey, I've deleted this post.

147

Let's get rid of that immediately out of the cache as well as out of the database.

148

So you get controls on when to set up that cache, but also when to tear it down.

149

It's important too to limit the blast radius of updates.

150

So for example, not all updates are created equal.

151

If we go back to my document here, making a change to this content area, that is going to send quite a large transfer over the wire.

152

So I don't want to have to update the entire page here and all these layouts

153

because I'm only updating that content area there where, for example, if I'm going to edit just this title section, I've got a different function there because that is going to need to invalidate this list.

154

And so that list is going to need to be refreshed.

155

So that means that when I'm making changes within this content area here, I'm not forcing a revalidation or re-rendering of the post list on the left-hand side.

156

But when I do need to force that rendering, I can change this title here.

157

And so that's using a different function.

158

So splitting up those functions to perform those edits can be really important just to make sure

159

that those changes and the impact of them ripple through as little of the application as possible.

160

So it's important too to fetch in priority order.

161

So not all content on the page needs to be seen at the same time.

162

So here on the left-hand side, if I'm loading the URL to load this particular page, this content area is the primary thing that I want to see first and the list on the left-hand side,

163

I can suspend that and stream that in later.

164

I don't mind.

165

I could put a loading spinner there, but personally, I hate loading spinners and fetches from PlanetScale should be so quick that you really need to see them anyway.

166

But yeah, I've set this up that I've actually suspended this list of posts here.

167

But this content area on the right-hand side is actually server-side rendered.

168

And so what I've done here, because this editor here, this editing block editor component that I've got,

169

it's called Portable Text and it has a rendering component as well as an editing component.

170

Now the editing component is super heavy and very interactive.

171

So it has to be a client component, but I've got a server rendered version of it

172

and you might see a flash for a second there where it's like half opacity and then it sort of fades in.

173

And I did that deliberately because I wanted the page to load incredibly quickly.

174

We're doing the smallest possible piece amount of work on the server side to render that as quickly as possible.

175

But as soon as it can become interactive, it is.

176

So we're sort of fetching and rendering in priority order.

177

I think I've stolen the next slide.

178

Yeah, rendering in priority order.

179

So that's what I was sort of saying there is to have that sort of static content rendering.

180

And then as soon as the editor is ready, that gets rendered in there, you know, where it's live.

181

And also I've got some import things there to say that, hey, the editor should not be part of that server side rendered bundle.

182

So I'm keeping that as small as possible on the server

183

and then only bringing it into the client side when I need it.

184

It's also important to cache as few keys as possible, particularly when it comes to user input.

185

So we have those dynamic tags for caching, and that's excellent.

186

But when it comes to user input that's going to result in a cache, we want to reduce the number of potential caches that we can create.

187

So, for example, here, if I was going to change the weather selector here, you know, if I'm searching for London or, you know, London in all caps with spaces either side of it,

188

those shouldn't end up in different cache entries.

189

You know, we can normalize that, make it all lowercase, trim off any white space, and that's going to be useful.

190

So just to, I mean, that's just one very specific example, but in any way where you can reduce the number of tags that are going to return the same data, that's incredibly important.

191

And especially again, when it comes to user input.

192

And fetching more or less often, you do get controls in Next.js as well over the lifetime of the cache too.

193

So things like weather updates, I'd only wanna cache it for a few minutes at the most because that can change quite variably, but there are other things that could last for hours and they're likely going to be okay.

194

So you're in control of the length of time, and you can also even change the settings in the next

195

config to sort of create your own named values for when things are cached and when they are revalidated, which is really cool again.

196

And again, it's just all these controls that you get to put in your code so agents can read them.

197

It's really, really neat.

198

And then caching about streaming children.

199

This was a sort of important thing when building this demo as well, is that this component here, because this has to do an asynchronous lookup to fetch the weather,

200

I didn't want loading those components to hold up that server-side rendered data fetch.

201

So the server-ended version, it uses a cached version of this data if it has access to it.

202

But on the first load, it isn't going to wait for those asynchronous fetches to complete in order to render this component.

203

And so you can see there, there's a small, on the first load there, it said loading weather, dot, dot, dot.

204

And then on the second load, it was already there.

205

So that meant that that was going to come from the server as fast as possible because these child components, children components, weren't going to wait on their own asynchronous fetches,

206

but we could just load the shell and then stream those in when they're ready.

207

And then as soon as they're ready, they're cached for the next person and for the next visit to see, which is really, really cool.

208

And then if you wanted to go further with this, there's also this idea of cache navigations and also remote caching as well.

209

So if the in-memory cache isn't sort of long lived enough for you, you can reach out to an external service and start saving those cache entries in there as well.

210

So you get an even longer lived cache.

211

But yeah, I mean, that was the talk

212

that I gave at both of those meetups and it was just very cool to see where Next.js is now.

213

But like I said at the beginning, above all else, seeing just how much

214

that team care about making really performant apps and it's really quite inspiring to see and inspiring to show that, you know, we can all build things very quickly.

215

But if you care, you're going to build something really great and you can do that with Next.js, which is cool.

216

So I hope you enjoyed this.

217

If you have any questions, let me know.

218

I'll put a link to the demo app in the description as well, and you can grab that on GitHub, and I'll see you in the next one.

Télécharger l'application

Tout pour parler couramment

Prononciation IAChaque phrase notée

Phonétique (IPA)Maîtrisez chaque son

VocabulaireEnrichissez votre lexique

Jeu de vocabulaireApprenez en jouant

Scanner le QR

Download on theApp Store Get it onGoogle Play

✨ Vidéo recommandée

239 phrases

Vocabulaire et conseils d’expression pour cette leçon

Cette leçon d’expression orale de niveau C1 s’appuie sur la vidéo « Next.js 16.3 got good ». Cette vidéo contient 218 phrases et 3420 mots à répéter en shadowing. La partie parlée dure 14:56. Le locuteur parle vite, environ 229 mots par minute : attendez-vous à des liaisons et à des sons réduits. 85 % des mots font partie des 3 000 mots les plus courants en anglais ; le reste mérite d’être vu avant de commencer.

Vocabulaire clé de cette vidéo

Les 15 mots les plus avancés de la vidéo, avec leur prononciation et leur sens :

Mot	Prononciation	Sens
cache nom	/kæʃ/	cache, mémoire cache
fetch verbe	/fɛt͡ʃ/	ramener, rapporter
render verbe	/ˈɹɛn.dɚ/	rendre
invalidate verbe	/ɪnˈvæl.əˌdeɪt/	invalider
declarative adjectif	/dɪˈklæɹ.ə.tɪv/	déclaratif
egress nom	/ˈiːɡɹɛs/	sortie
asynchronous adjectif	/eɪˈsɪŋ.kɹə.nəs/	asynchrone
query nom	/ˈkwɪɹ.i/	question
demo nom	/ˈdɛm.oʊ/	démo, démonstration
optimize verbe	/ˈɑptɪmaɪz/	agir en optimiste
revalidation nom		revalidation
spinner nom	/ˈspɪnɚ/	casserole
parameter nom	/pəˈɹæm.ə.tɚ/	paramètre
refresh verbe	/ɹɪˈfɹɛʃ/	revigorer, rafraîchir
suspend verbe	/səsˈpɛnd/	suspendre

Les verbes à particule que vous entendrez

Mot	Prononciation	Sens
add up verbe		additionner
hold up verbe		retenir
show off verbe		crâner, faire le malin
check out verbe		mater, regarder
end up verbe		se terminer, se finir
go down verbe		descendre
go through verbe		traverser
set up verbe	/ˌsɛt ˈʌp/	mettre en place, installer

Des phrases à répéter

Des phrases courtes et complètes de la vidéo, à réutiliser dans la conversation de tous les jours :

The agent's not going to care for you.
You're going to fetch too much data too often.
I don't need to do that.
I think I've stolen the next slide.

La grammaire de cette vidéo

Les structures que le locuteur utilise le plus, avec les mots exacts de la vidéo :

Structure	Dans la vidéo
Present perfect have/has + participe passé — une action passée qui compte encore maintenant	I've titled · you've never been · has always been
Voix passive be + participe passé — l’accent est mis sur ce qui arrive, pas sur qui le fait	was cached · being fetched · are implemented
Propositions relatives who / which + proposition — une précision sur une personne ou une chose	everything, which is · fast, which is · people who build

Prononciation à surveiller

Le locuteur utilise 86 contractions et formes réduites, comme I'm, I've, don't. Prononcez-les sous leur forme courte, telles que vous les entendez.

Les sons « sh » et « zh »: cache /kæʃ/, refresh /ɹɪˈfɹɛʃ/, differentiator /dɪf.əˈɹɛn.ʃi.eɪ.tə/, invocation /ˌɪn.voʊˈkeɪ.ʃən/, optimization /ˌɑptəmaɪˈzeɪʃən/
Mots longs — placez bien l’accent: invalidate /ɪnˈvæl.əˌdeɪt/, declarative /dɪˈklæɹ.ə.tɪv/, asynchronous /eɪˈsɪŋ.kɹə.nəs/, parameter /pəˈɹæm.ə.tɚ/, ideally /aɪˈdi.ə.li/

Les sons difficiles pour les francophones :

/h/ — il se souffle, il n’est pas muet: likelihood /ˈlaɪklihʊd/, hint /hɪnt/
/r/ anglais — langue recourbée, sans frotter la gorge: render /ˈɹɛn.dɚ/, declarative /dɪˈklæɹ.ə.tɪv/, egress /ˈiːɡɹɛs/, asynchronous /eɪˈsɪŋ.kɹə.nəs/, query /ˈkwɪɹ.i/

Comment s’entraîner avec cette vidéo

Écoutez la vidéo en entier une fois sans parler et notez les mots que vous ne connaissez pas.
Commencez à la vitesse 0,75×, répétez phrase par phrase, puis revenez à la vitesse normale quand cela devient facile.
Enregistrez-vous et comparez avec l’original, en faisant attention à des mots comme cache, fetch, render.

Qu'est-ce que la technique du Shadowing ?

Le Shadowing est une technique d'apprentissage des langues fondée sur la science, développée à l'origine pour la formation des interprètes professionnels. Le principe est simple mais puissant : vous écoutez de l'anglais natif et le répétez immédiatement à voix haute — comme une ombre suivant le locuteur avec un décalage de 1 à 2 secondes. Les recherches montrent une amélioration significative de la précision de la prononciation, de l'intonation, du rythme, des liaisons, de la compréhension orale et de la fluidité.

Technique du shadowing : lire le guide complet étape par étape →

Pratique du Shadowing: Next.js 16.3 got good (if you care) - Apprendre l'anglais à l'oral avec la vidéo

Choisissez un mode d'entraînement

Télécharger l'application

My 4.9-Star iOS App Is Actually a Website: Here’s How I Built It

Armchair Architects: Resiliency in the Cloud – Core Patterns

Why Coding Agents Keep Making Your Codebase Worse

We've got separation of concerns wrong

Video

I Bet Nobody Has Ever Explained the Backend Ecosystem Like This Before

This Mouse Makes You a Better Gamer.

Go’s Big Mistake

The Only SaaS Moats Left in 2026

Does Anyone Use JavaScript Anymore?

10 Minutes of Advanced English Listening: Boost Your C1 Comprehension Fast

8 Most Important System Design Concepts You Should Know