Prática de Shadowing: Next.js 16.3 got good (if you care) - Aprenda a falar inglês com vídeo

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.

✨ Vídeo recomendado

239 frases

Vocabulário e dicas de fala para esta lição

Esta aula de conversação de nível C1 usa o vídeo “Next.js 16.3 got good”. Este vídeo tem 218 frases e 3420 palavras para praticar shadowing. A fala dura 14:56. O falante fala rápido, cerca de 229 palavras por minuto, então espere sons ligados e reduzidos. 85% das palavras estão entre as 3.000 mais comuns do inglês; vale a pena estudar o restante antes de começar.

Vocabulário principal deste vídeo

As 15 palavras mais avançadas do vídeo, com pronúncia e significado:

Palavra	Pronúncia	Significado
cache substantivo	/kæʃ/	esconderijo
fetch verbo	/fɛt͡ʃ/	buscar
render verbo	/ˈɹɛn.dɚ/	tornar
declarative adjetivo	/dɪˈklæɹ.ə.tɪv/	declarativo
asynchronous adjetivo	/eɪˈsɪŋ.kɹə.nəs/	assíncrono
query substantivo	/ˈkwɪɹ.i/	pergunta
demo substantivo	/ˈdɛm.oʊ/	demonstração
optimize verbo	/ˈɑptɪmaɪz/	otimizar
parameter substantivo	/pəˈɹæm.ə.tɚ/	parâmetro
refresh verbo	/ɹɪˈfɹɛʃ/	refrescar
suspend verbo	/səsˈpɛnd/	suspender
dominate verbo	/ˈdɑ.məˌneɪt/	dominar
preview substantivo	/ˈpɹiːvjuː/	prévia
inspire verbo	/ɪnˈspaɪə(ɹ)/	inspirar
interactive adjetivo	/ˌɪn.tɚˈæk.tɪv/	interativo

Phrasal verbs que você vai ouvir

Palavra	Pronúncia	Significado
show off verbo		mostrar-se, jactar-se
check out verbo		verificar, sacar só
end up verbo		terminar, acabar
go down verbo		descer
set up verbo	/ˌsɛt ˈʌp/	preparar

Frases que vale a pena repetir

Frases curtas e completas do vídeo que você pode usar na conversa do dia a dia:

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.

Gramática neste vídeo

As estruturas que o falante mais usa, com as palavras exatas do vídeo:

Estrutura	No vídeo
Present perfect have/has + particípio passado — uma ação passada que ainda importa agora	I've titled · you've never been · has always been
Voz passiva be + particípio passado — o foco está no que acontece, não em quem faz	was cached · being fetched · are implemented
Orações relativas who / which + oração — informação extra sobre uma pessoa ou coisa	everything, which is · fast, which is · people who build

Pronúncia para ficar de olho

O falante usa 86 contrações e formas reduzidas, como I'm, I've, don't. Diga-as na forma curta, do jeito que você ouve.

Os sons de “sh” e “zh”: cache /kæʃ/, refresh /ɹɪˈfɹɛʃ/, differentiator /dɪf.əˈɹɛn.ʃi.eɪ.tə/, invocation /ˌɪn.voʊˈkeɪ.ʃən/, optimization /ˌɑptəmaɪˈzeɪʃən/
Palavras longas — acerte a sílaba tônica: 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/

Sons difíceis para falantes de português:

Consoante final — sem acrescentar um “i” depois: invalidate /ɪnˈvæl.əˌdeɪt/, suspend /səsˈpɛnd/, dominate /ˈdɑ.məˌneɪt/, config /ˌkənˈfɪɡ/, meetup /ˈmitˌʌp/
/l/ final — a língua toca o céu da boca, não vira “u”: drizzle /ˈdɹɪzəl/, readable /ˈɹiː.də.bəl/, ripple /ˈɹɪp(ə)l/
/h/ — um sopro suave, diferente do “r”: likelihood /ˈlaɪklihʊd/, hint /hɪnt/

Como praticar com este vídeo

Ouça o vídeo inteiro uma vez sem falar e anote as palavras que você não conhece.
Comece na velocidade 0,75×, faça shadowing frase por frase e volte à velocidade normal quando ficar fácil.
Grave a sua voz e compare com o original, prestando atenção a palavras como cache, fetch, render.

O que é a Técnica de Shadowing?

Shadowing é uma técnica de aprendizado de idiomas com base científica, originalmente desenvolvida para o treinamento de intérpretes profissionais. O método é simples, mas poderoso: você ouve áudio em inglês nativo e repete imediatamente em voz alta — como uma sombra seguindo o falante com 1-2 segundos de atraso. Pesquisas mostram melhora significativa na precisão da pronúncia, entonação, ritmo, sons conectados, compreensão auditiva e fluência na fala.

Técnica de shadowing: leia o guia completo passo a passo →

Prática de Shadowing: Next.js 16.3 got good (if you care) - Aprenda a falar inglês com vídeo

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

Next JS Interview Questions and Answers 2026 | Top 20 Most Asked Questions

You Just Don't Want It Enough.

We've got separation of concerns wrong

My Experience as a Tech Lead

LangChain in 5 Minutes (Explained Clearly)

New Skills! v1.3 brings /pr, /implement-spec, and /retro

8 Most Important System Design Concepts You Should Know

Does Anyone Use JavaScript Anymore?

Technical deep dive on Managed Instance for App Service | BRK102