쉐도잉 연습: Next.js 16.3 got good (if you care) - 영상으로 영어 말하기 배우기

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.

✨ 추천 영상

239 문장

이 레슨의 어휘와 말하기 포인트

이 C1 수준 말하기 레슨은 영상 “Next.js 16.3 got good”을(를) 바탕으로 합니다. 이 영상에는 섀도잉할 문장 218개와 단어 3420개가 있습니다. 말하는 구간의 길이는 14:56입니다. 화자는 분당 약 229단어로 빠르게 말하므로 연음과 약하게 발음되는 소리가 많습니다. 단어의 85%가 영어에서 가장 많이 쓰이는 3,000단어에 속합니다. 나머지는 연습 전에 미리 확인해 두세요.

이 영상의 핵심 어휘

영상에서 가장 어려운 단어 15개를 발음, 뜻과 함께 정리했습니다.

단어	발음	뜻
cache 명사	/kæʃ/	캐시
fetch 동사	/fɛt͡ʃ/	가지고 오다
render 동사	/ˈɹɛn.dɚ/	일어나게 하다, 하게하다
query 명사	/ˈkwɪɹ.i/	질문
demo 명사	/ˈdɛm.oʊ/	데모
parameter 명사	/pəˈɹæm.ə.tɚ/	파라미터, 매개변수
refresh 동사	/ɹɪˈfɹɛʃ/	새롭게 하다
suspend 동사	/səsˈpɛnd/	보류하다, 유예하다
dominate 동사	/ˈdɑ.məˌneɪt/	지배(支配)하다
interactive 형용사	/ˌɪn.tɚˈæk.tɪv/	인터랙티브
cursor 명사	/ˈkɜːsə/	커서
drizzle 명사	/ˈdɹɪzəl/	이슬비
ripple 명사	/ˈɹɪp(ə)l/	물결, 연의
snippet 명사	/ˈsnɪpɪt/	끄트러기, 조각
quota 명사	/ˈkwəʊ.tə/	할당량, 쿼터

영상에 나오는 구동사

단어	뜻
show off 동사	나대다
go down 동사	내려가다

따라 말해 볼 만한 문장

영상에 나오는 짧고 완결된 문장으로, 일상 대화에서 그대로 쓸 수 있습니다:

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.

이 영상의 문법

화자가 가장 많이 쓰는 문형을 영상 속 실제 표현과 함께 정리했습니다.

문형	영상 속 표현
현재완료 have/has + 과거분사 — 과거의 일이 지금도 관련이 있을 때	I've titled · you've never been · has always been
수동태 be + 과거분사 — 누가 하는지보다 무슨 일이 일어나는지에 초점	was cached · being fetched · are implemented
관계절 who / which + 절 — 사람이나 사물에 대한 추가 정보	everything, which is · fast, which is · people who build

주의할 발음

화자는 I'm, I've, don't 같은 축약형과 약화된 형태를 86번 사용합니다. 들리는 대로 짧게 발음하세요.

“sh”와 “zh” 소리: cache /kæʃ/, refresh /ɹɪˈfɹɛʃ/, differentiator /dɪf.əˈɹɛn.ʃi.eɪ.tə/, invocation /ˌɪn.voʊˈkeɪ.ʃən/, optimization /ˌɑptəmaɪˈzeɪʃən/
긴 단어 — 강세 위치에 주의: 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/

한국어 화자가 어려워하는 소리:

/f/ — ㅍ(/p/)으로 바꾸지 말고 윗니를 아랫입술에 대기: fetch /fɛt͡ʃ/, refresh /ɹɪˈfɹɛʃ/, config /ˌkənˈfɪɡ/, differentiator /dɪf.əˈɹɛn.ʃi.eɪ.tə/, performant /pɚˈfɔɹmənt/
/v/ — ㅂ(/b/)과 구별하기: invalidate /ɪnˈvæl.əˌdeɪt/, declarative /dɪˈklæɹ.ə.tɪv/, preview /ˈpɹiːvjuː/, interactive /ˌɪn.tɚˈæk.tɪv/, invocation /ˌɪn.voʊˈkeɪ.ʃən/
/z/ — ㅈ이 아니라 성대를 울리는 /s/: optimize /ˈɑptɪmaɪz/, drizzle /ˈdɹɪzəl/, normalize /ˈnɔː.mə.laɪz/, optimization /ˌɑptəmaɪˈzeɪʃən/

이 영상으로 연습하는 방법

먼저 말하지 않고 영상을 끝까지 듣고 모르는 단어를 적어 둡니다.
0.75배속으로 한 문장씩 섀도잉을 시작하고, 익숙해지면 보통 속도로 돌아갑니다.
자신의 목소리를 녹음해 원본과 비교하고, cache, fetch, render 같은 단어에 특히 주의합니다.

쉐도잉이란? 영어 실력을 빠르게 키우는 과학적 방법

쉐도잉(Shadowing)은 원래 전문 통역사 훈련을 위해 개발된 언어 학습 기법으로, 다언어 학자인 Dr. Alexander Arguelles에 의해 대중화된 방법입니다. 핵심 원리는 간단하지만 매우 강력합니다: 원어민의 영어를 들으면서 1~2초의 짧은 지연으로 즉시 소리 내어 따라 말하는 것——마치 '그림자(shadow)'처럼 화자를 따라가는 것입니다. 문법 공부나 수동적인 청취와 달리, 쉐도잉은 뇌와 입 근육이 동시에 실시간으로 영어를 처리하고 재현하도록 훈련합니다. 연구에 따르면 이 방법은 발음 정확도, 억양, 리듬, 연음, 청취력, 말하기 유창성을 크게 향상시킵니다. IELTS 스피킹 준비와 자연스러운 영어 소통을 원하는 분들에게 특히 효과적입니다.

섀도잉 방법: 단계별 전체 가이드 읽기 →

쉐도잉 연습: Next.js 16.3 got good (if you care) - 영상으로 영어 말하기 배우기

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

Go’s Big Mistake

This Mouse Makes You a Better Gamer.

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

Technical deep dive on Managed Instance for App Service | BRK102