708：我们如何让 Syntax.fm 更快

星期一。

Monday.

星期一。

Monday.

星期一。

Monday.

打开吧，开发者粉丝们。

Open wide dev fans.

准备好大快朵颐吧：JavaScript、CSS、Node 模块，还有烧烤小贴士。

Get ready to stuff your face with JavaScript, CSS, node modules, barbecue tips.

掌握工作流程、霹雳舞、软技能和网页开发。

Get workflows, breakdancing, soft skills, web development.

最匆忙、最疯狂、最美味的网页开发盛宴即将登场。

The hastiest, the craziest, the tastiest web development treats coming in hot.

这里是 Wes、Barracuda、老板和 Scott，El Toroloco Tolinsky。

Here is Wes, Barracuda, boss, and Scott, El Toroloco Tolinsky.

欢迎来到Syntax。

Welcome to Syntax.

这是第708期，我们感觉很棒。

It's episode number seven zero eight, and we're feeling great.

我们将要讨论性能问题。

We're gonna be talking about performance here.

我们上线了全新的Syntax网站。

We pushed, you know, a new Syntax website.

我们为它投入了大量的工作。

We did a ton of work into it.

你知道吗？

And you know what?

它还可以更快。

It could always be faster.

所以你知道我们做了什么吗？

So you know what we did?

我们亲自上手做了优化。

We we got our hands dirty.

我们查看了各种指标。

We looked at metrics.

我们分析了时间线、火焰图以及所有相关数据，最终让网站更快了。

We looked at timelines, flame graphs, and all that stuff, and we made it faster.

我们会向你们详细介绍我们为提升性能所采用的所有技巧和方法、使用的工具，以及过程中学到的经验。

We're gonna be telling you all about the tips and techniques that we implemented to make this thing faster, what tools we used, and what we learned along the way.

我叫斯科特·塔林斯基。

My name is Scott Talinski.

我是一名开发者。

I'm a developer.

我来自丹佛。

I'm from Denver.

和往常一样，和我一起的是韦斯·博斯。

With me as always is Wes Boss.

嘿，老兄，最近怎么样？

What's up my man?

嗨。

Hey.

我非常期待聊这个话题，因为新网站上有几个地方有点卡顿，你知道的，原因各不相同。

I am excited to talk about this because there was several spots in the the new website that were a little sluggish, you know, and for different reasons.

所以我觉得这集挺有意思的，我们可以聊聊：这些就是我们在性能各方面遇到的问题，我们是怎么找出拖慢速度的原因的，以及我们最终是怎么让它变快的。

So it's I think it's kind of an interesting episode to sort of say, all right, these are the problems that we hit on the different aspects of performance, and and here's how we figured out what was causing it to be slow, and here's how we actually made it faster.

完全没错。

Totally.

而且我觉得也很重要的是要说明，嘿，我们上线了，从一个相对简单的网站开始。

And I think it's also important to note that, like, Hey, we launched and we went from a site that was relatively simple.

所有内容都是动态生成的。

Everything was really generated.

那是一个静态网站。

It was a static site.

当时，这些展示网站都是在编译时生成为HTML的，这对于内容不太频繁变动的网站来说非常理想。

It was, it, it was basically any of these show websites were generated into HTML at compile time, which is really great with a site that doesn't change dynamically that much.

但当我们转向这个新网站时，一个重大变化是我们有了数据库。

But one of the big changes that we had when moving to this new site was that, Hey, we got a database now.

一旦引入了数据库，你就同时引入了服务器端的处理流程之类的东西。

And the moment you bring in a database, you bring in server side processes and things like that.

你突然间就得担心一些新问题了。

You suddenly have some things you have to worry about.

你得面对一些更容易变慢的环节，因为数据不再是以单个文件的形式缓存、随时可加载，而是必须执行数据库查询。

You have areas where it's much easier to be slow because instead of having that data be cached as single files that can be loaded and ready to go, gotta do a database query.

你得检查一些东西，得完成各种额外的步骤，这些都可能导致速度变慢。

You gotta check You some things gotta have all sorts of additional steps that can bring on slowness.

而这些问题的根源大多就在于此。

And that's really what the problems mostly were.

我认为我们遇到的所有问题，几乎都是通过服务器端的修复解决的，而不是客户端的修复。

I I would say just about all of our problems were solved with server side fixes rather than client side fixes.

是的。

Yeah.

不过，我得纠正你一下。

And I'll I'll correct you there, though.

旧网站并不是预生成的。

The old site wasn't pregenerated.

像，不是

Like, wasn't

它不是。

It wasn't.

HTML。

HTML.

哦，是吗？

Oh, is it?

不是。

No.

它是按需生成的。

It it was generated on demand.

之所以按需生成，是因为我们需要在新剧集一发布就立即推送，而不想在每周五早上9点重新生成所有内容。

And the only reason it was generated on demand is because we needed to be able to push out new shows as soon as they were released, and we didn't wanna have to regenerate every single at like 9AM on

哦，对。

Oh, right.

周五早上。

Friday morning.

所以我们采用了‘过期时重新验证’的策略：用户访问网站时，系统会先返回缓存的版本，同时在后台为下一位用户生成新版本。

So we we did the stale while revalidate where you visited the website and then it gave you the cached version and then it generated a new version in the background for the next person.

是的。

Yes.

这是在 Next.js 中实现的。

And that was in Next.

Js。

Js.

我之所以搞错了，其中一个原因是韦斯主要负责搭建了那个最初的网站。

The one of the reasons why I got that wrong is because Wes Wes primarily knocked out the the first website.

所以我最初并没有参与太多建设工作。

So I didn't have a whole lot of hand in building it initially.

但这个网站，同样，它没有数据库。

But this website, again, that one didn't have a database.

我认为这是最关键的一点。

I think it was the big thing.

而数据库方面——

And the database aspect-

只是用 Markdown 文件。

Just markdown files.

是的。

Yeah.

这其实是整个系统中最繁重的部分之一。

Is really one of the heavier loads of it all.

所以首先，我们是怎么知道它很慢的？

So first and foremost, how did we know it was slow?

我们去了哪里？

Where did we go?

我们做了什么来诊断它慢的问题？

What did we do to diagnose this for being slow and diagnose this for being slow?

对我来说，你有一部分是靠肉眼观察。

For me, you you had some of it was the eye test.

你使用这个网站时，会觉得它没有应有的响应速度。

You use the site and you say, this thing doesn't feel as fast as it should feel.

我的网络速度非常快。

And I have really fast internet.

我认为这里肯定存在问题，而且这些情况可以通过各种数据来验证。

I would imagine that there's some issues here and that can be backed up by all kinds of data.

当然，你可以打开开发者工具。

I mean, granted you could load up your dev tools.

你可以把你的网络速度设置为3G，然后在网络标签页中加载，这样就能进行测量。

You could, you know, set your Internet speed to be three g and your your network tab, and you can load it up that way and measure it.

你也可以用Lighthouse或者其他各种工具来运行测试。

You can run it through lighthouse or all kinds of things.

但因为我们现在是由Sentry赞助的，所以我们使用了Sentry，我不希望整个这一集变成Sentry的广告，但我们确实大量使用了Sentry的性能工具来解决我们的问题。

But what we did is since, you know, we're presented by Sentry here, we use Sentry and I don't want this whole episode to turn into a Sentry ad, but we did use Sentry's performance tools in absurd amount to solve our issues.

而且我认为有必要强调这一点，因为我们加载了Sentry的性能工具，它会展示每个路由的Web核心指标。

And and I think it's important to highlight that because we loaded up the the Sentry performance tools and they're showing you web vitals across every route.

在这个页面上首先显示的信息就是：这是你网站中最慢的路由，不一定是页面最慢，而是路由最慢。

And one of the things that shows you first and foremost on that page is that here is the slowest route of your site, not the slowest page necessarily, the slowest route.

它能告诉我们，正斜杠加slug这个路由是最慢的。

It's able to see show us that the forward slash, show number forward slash slug is the slowest route.

实际上，现在它是最慢的路由，但以前并不是，因为我们之后会谈到在那里所做的某些更改。

And, actually, that's the slowest route now, but it wasn't because we'll talk about some of the changes we made there.

它还会告诉你各种信息，比如首次绘制的平均时间、机会评分，也就是提醒你：很多人访问这个页面，而它却很慢。

And it tells you all kinds of information, like the average time to first bite, the opportunity score, which is like, hey, a lot of people are hitting this thing and it is slow.

因此，这里有很大的优化空间。

Therefore, there's a lot of opportunity here.

对吧？

Right?

正因为如此，我们能够准确地看出首先应该关注哪些方面，也就是那些最慢、最有潜力提速的页面。

And because of that, we were able to see exactly what are the things we should be focusing on first, which are the slowest pages, which have the most opportunity to speed up.

我们发现网站一些关键页面的性能评分偏低，主要是首页和展示页，这两个是最突出的。

And we were seeing a handful of red perf scores for some of the key pages on the site, the index page and the show page primarily were the two biggest ones.

这就是网页核心指标。

So that's the web vitals.

对吧？

Right?

你看到首次绘制时间了。

You're seeing time to first bite.

你看到最大内容绘制（LCP）是多少吗？

You're seeing the what is the LCP largest?

最大内容绘制。

Largest Contentful Paint.

最大内容绘制、首次内容绘制、首次输入延迟、累计布局偏移。

Largest Contentful Paint, the first Contentful Paint, first input delay, cumulative layout shift.

我们正在查看我们网站所有路由的这些信息。

We're seeing all of that information across all of the routes of our site.

使用Sentry中的查询功能，我们还能查看所有的数据库查询，并识别出哪些数据库查询持续最慢。

Another thing that we're able to see using the queries feature within Sentry is we were able to look at all of our database queries and we're able to see which of our database queries were the slowest consistently.

其中有几项查询明显持续缓慢。

And there were a handful of ones that stood out as consistently being slow.

有了这些信息，你就掌握了网页性能指标、查询数据、Sentry中的整体性能功能，再加上直观体验。

And so with that information, you have the the web vitals, you have the queries, you have the general performance features here in Sentry, and then you have things like the eye test.

你正在使用这个网站。

You're using the site.

你感受到它有多慢。

You're feeling how slow it is.

你可以精准地确定首先应该关注哪些最重要的问题，然后从那里开始。

You can really dial in exactly what are the biggest things you should be looking at first and then start there.

因此，我们知道这里有一个数据库后，第一件事就是专门查看数据库调用。

So the first thing we did knowing that we have a database here was we looked into the database calls specifically.

通过查询标签，我们能够看到，我发现了一堆非常慢的数据库查询，而且它们全部都是 Prisma 中的 findFirst 方法。

So using the queries tab, we're able to see, okay, I'm seeing that I have a bunch of really slow database queries and all of them were the find first method within Prisma.

这让我想到了一件事。

And that made me think about something.

这确实是我的第一个大型 Prisma 项目。

This is, you know, really my first big site with Prisma.

我当时在想，findFirst，也许这个方法本身有问题。

And I was thinking find first, maybe there maybe there's an issue with find first.

也许我们漏掉了某个索引之类的东西。

Maybe we're missing an index or something.

结果发现，findFirst 其实就是带有限制为一的 find 方法。

Well, it turns out that find first is really just a find mini with a limit of one.

而我们实际上应该使用的方法是 find unique，性能更好。

And the method that we actually wanted to use was find unique, better performance.

这很容易解决。

That's an easy fix right there.

所以我们把所有 find first 都改成了 find unique。

So we just changed all of our find first to find unique.

简单修复，性能提升，不错。

Easy fix, performance win, nice.

我们遇到的另一个问题是字幕被加载了。

So the other thing we had was the transcripts were being loaded.

我们制作节目页面的方式是，当你访问 Syntax 上的某一集时，页面上会有播放器、该集的节目笔记以及其他一些内容。

The way that we did the show page so when you visit one of the episodes on Syntax, we just had like we had the player, we had the show notes for that specific show, and a couple of other items on that page.

当需要实现字幕功能时，我想了想，好吧。

And then when it came time to implement the transcripts, what I did is I was like, okay.

字幕不需要出现在每个页面上，所以它应该作为一个独立的标签页存在。

Like, the transcript doesn't need to be on every page, so it needs to be on its own, like a separate tab.

对吧？

Right?

所以我写了一些标签页，然后写了一个路由，用来判断你是处于节目页面，还是处于节目页面/字幕页面，然后根据情况隐藏或显示相应内容。

So I I wrote some tabs and then I wrote a route that would catch whether you're on the show page or if you're on the show page forward slash transcripts, then hide and show depending on on what we have there.

然而，首先，在这一切发生之前，字幕文件本身非常庞大，因为

However, first of all, before any of this stuff happened, the transcripts itself are they're absolutely massive because

是的。

Yeah.

你拥有完整的字幕内容。

You have the entire transcript.

而在这些字幕中，包含了一种叫做“语段”的内容，每个语段大概是一个词，或者一两句话。

And inside of that, you have what are called utterances, which is like a a word or, I don't know, two or three sentences.

而在每个语段中，又包含了每一个单词。

And then inside of the utterances, you have every single word.

它还会记录每个单词的开始和结束时间。

And it tells you when the words have started and stopped.

我把所有这些数据都保存在数据库中，因为将来可能需要开发一个视频工具，用来高亮显示当前正在说的单词。

And I've saved all that data in the database because there may be a time when we wanna build like some sort of video tool that will you know, if you wanna highlight the currently spoken word.

所以我心想，好吧，我们就把所有这些数据都保存下来。

So I was like, alright, we'll save all that data.

在开发过程中，我加载了每一个单词的数据。

And I was loading the data for every single word just in in dev.

但这实在太慢了，因为需要处理的 JSON 数据量太大了——想象一下一小时的对话，每个单词都有开始时间、结束时间、置信度和说话人 ID。

And it was just it's way too slow because the amount of JSON you need like, imagine an hour's worth of talking and every word has a start, a stop, a confidence, and a speaker ID attached to every single one.

数据量实在太大了。

It's just way too big.

所以我们放弃了高亮当前所说单词的功能，改为只获取每一个语句，然后根据具体时间判断当前正在说的语句。

So we I scrapped being able to highlight the currently spoken word, and I'm just getting the every single utterance that I'm able to figure out the currently spoken utterance depending on the the specific time.

但我们设置标签的方式是，转录数据在你访问节目页面时才加载，这对性能来说是好的。

But the the way that we did the tabs was that the transcript data was being loaded on when you were visiting the actual show page, which is is is good for, like, performance.

你切换过去时，加载时间却太长了。

You you flip over to it, but it's it takes way too long.

有人访问页面并点击进入字幕的可能性很低。

And the chances of somebody visiting the page and clicking over to the transcript is is pretty low.

对吧？

Right?

大多数人可能不会去查看字幕标签页。

Most people are probably not going to the transcript tab.

如果你去了，那也没关系。

And if you are, that's fine.

在那个页面上多加载一点内容没问题，但其实没必要提前加载。

That's fine to have a bit of a larger load on that page, but it doesn't need to be loaded.

当你访问主页面时，这些数据并不需要被加载。

That data doesn't need to be loaded when you visit just the actual page.

所以你重新调整了 SvelteKit 的所有嵌套路由？

So you rejigged how SvelteKit did all the nested routes?

是的。

Yeah.

这并不是嵌套布局能力的证明。

And this isn't a testament to the the abilities of nested layout.

所以，你知道，我们以前的做法是，在页面上一次性执行了两个查询，对吧？

So, you know, the way that we had it before was that both of the queries were being done in one fell swoop on the page, right?

那是展示页面。

It was the show page.

然后我们只是用一个if语句来显示或隐藏字幕。

And then we were just using like basically an if statement to show or hide the transcripts.

对吧？

Right?

我们意识到，并不是每个访问页面的人都会点击那个字幕标签来加载字幕内容。

And we realized that not everybody who hits the page is even gonna click on that transcripts transcripts tab to load those transcripts.

那为什么我们要在页面初次加载时，为所有人做这些繁重的工作呢？

So why are we doing that heavy lifting for everybody on the initial load of the page?

所以我们把大部分节目信息的数据库调用移到了布局本身，并将大部分HTML内容也移到了页面的布局中。

So what we did is we moved the database calls for most of the show information to the layout itself, and we moved most of the HTML into the layout of the page.

通过嵌套布局路由，我们能够通过插槽传入显示节点或字幕，也就是根据当前激活的标签来决定。

Then using nested layout routing, we were able to pass in via a slot either the the show nodes or the transcript, basically, whichever tab there.

因此，不再使用带有 if 语句的标签功能，而是通过嵌套布局路由来切换。

So instead of having that tab function with a if statement is being toggled with the nested layout route.

同样，我们将字幕的数据库调用移到了字幕页面本身，也就是说，我们现在可以利用这个功能，将这些信息作为真正的嵌套路由包裹在其他信息之外。

And likewise, we moved the transcript database call to the page of the transcript page, basically saying, Hey, we are now able to use this feature where we can pull out and have this information wrapping some other information as a true nested route.

这样一来，就像之前一样，你可以直接访问 /transcript 进入字幕页面，但只有在那时才会执行那个庞大的数据库查询，这为我们节省了大量时间。

And that way, just like before, you could hit forward slash transcript and get to the transcript page, but only then are you going to be having to do that massive DB call, which is going to save us a considerable amount of time and did.

因此，我们在数据库层面做了这些重大改进，以提升最重页面的加载速度，仅这一项就带来了巨大影响。

So those were some big, big things that we did on the database side of things to improve loading on the heaviest pages, and it it that alone had a huge impact.

我在数据库和按页面加载数据时经常遇到这种情况。

And I I I run into this quite a bit with databases and loading data per page.

我几乎总是对自己说，真希望能把查询直接放在组件内部。

And I almost always tell myself, I wish I could put the query in the component itself.

是的。

Yeah.

知道吗？

Know?

而且那正是

And that was

是的。

Yeah.

有

Have

服务端组件。

server components.

是的。

Yeah.

使用 Apollo，他们就是这样做的。

With Apollo, they do that.

比如，Apollo 会处理 Next。

Like, Apollo will take a Next.

一个 JS 网站，遍历组件树来查找查询。

Js site and walk the component tree looking for queries.

我认为 Quick 也是这样做的，比如

And I think Quick does that as well where

你是在说 Apollo 吗？

Are you talking about Apollo?

是的。

Yeah.

Apollo，就像 Apollo GraphQL。

Apollo, like Apollo GraphQL.

好的。

Okay.

这样更好一点，因为你就不用在页面级别决定需要哪些数据了。

And that's a bit nicer because, like, then you don't have to decide at a page level what data you want.

你可以直接把查询放在组件本身里，然后页面会自动判断：哦，我没有渲染这个组件，所以暂时不获取这个数据。

You could just put the query in the in the component itself, and then the page should figure out, oh, well, I'm I'm not rendering this component, so I'm not gonna fetch that just yet.

所以我认为，许多这些框架在这方面都有可能得到改进。

So I think that's something that could possibly be improved with a lot of these frameworks.

是的。

Yeah.

你觉得 React 服务器组件是否直接解决了这个问题？

And do you think React server components does like solve that directly?

因为对我来说，它确实解决了。

Because to me it does.

我想知道其他人会不会也开始这么做，或者是否存在其他解决方案。

I wonder if everybody else is going to start to do that or if there's a different solution there.

是的。

Yeah.

我认为，直接在服务器上渲染并把 HTML 发送到客户端，能解决很多问题，也让组件更具可移植性。

I think the the idea of, yeah, just render it on the server and send the HTML to the client fixes a lot of that and it makes your components a lot more portable.

是的，完全没错。

Yeah, totally.

不错。

Cool.

接下来我们做的另一件事是，说实话，如果你遇到性能问题，而且不是明显由客户端循环之类的因素导致的卡顿，我认为你的系统中很多性能问题都可以通过几件事来解决。

Well, next thing we did, which is, you know, honestly, I would say if you're running into perf issues, right, if it's not clearly like a a client side jank from looping or something like that, I would say so many perf issues in your stacks can be solved by a couple of things.

优化数据库调用、添加索引，诸如此类的操作，然后是缓存。

Optimize optimizing database calls, adding indexes, those types of things, and then caching.

缓存能解决很多性能问题，而且效果非常显著，因为我们的网站上一些最耗资源的列表都在频繁进行数据库调用。

Caching will solve so many perf issues and it will solve them really effectively because, you know, again, some of the heaviest lists that we had in the site were going off to do the database calls.

如果这个数据库调用需要200毫秒，那就是在整体加载时间上额外增加了200毫秒。

Whether if that database call takes two hundred milliseconds, that's two hundred additional milliseconds you're tacking on to the entire load of things.

如果耗时更长，那每次调用都会叠加这部分延迟。

If it takes longer than that, again, that's that's tacking on to every single time you do that call.

所以你应该做的是缓存这些调用，这样就不用每次都访问数据库，而是直接从缓存中获取数据。

So what you wanna be doing is caching those calls so that way you're not having to hit the database all the time and what you're hitting is a cache.

这个缓存可以是内存中的数据，也就是简单地保存为一个变量，也可以是像Redis这样的内存级存储。

And that cache can be something in memory, which is basically just saving it to a value, or it can be in a, a memory level store like a Redis store.

我们使用的是一个叫 Upstash 的服务。

What we used is we used a service called Upstash.

如果你听说 Vercel 正在推出他们自己的缓存平台，我认为它叫 KV。

Now if you've heard that Vercel is releasing their own caching platform, I believe it's called KV.

你可能听说过 KV 其实是 Upstash 的一个封装。

You might have heard that KV is just a wrapper around Upstash.

所以，虽然我们本可以使用 Vercel 的缓存平台并为此支付额外费用，但直接使用 Upstash 本身要合理得多。

So while we could have used Vercel's caching platform and paid the premium on top of it, it makes way more sense to just use Upstash itself.

我的意思是，为什么不这么做呢？

I mean, why wouldn't you do that?

对吧？

Right?

尤其是当它们本质上是一样的时候。

Especially if it's the same.

而且它基本上是使用 Redis，但通过无服务器 API 来实现。

And and basically it is using Redis, but it's using Redis with a serverless API.

所以我们使用了 Upstash 及其库来实现 Upstash 缓存，这基本上与 Redis 的 API 完全相同。

So we were able to use Upstash, with their library to do the Upstash caching, which is basically the exact same as Redis' API.

你用一个键来设置值，再用同一个键来获取它。

You set something with a a a key and you retrieve it with that key.

这就是一个键值存储。

Key value store.

其实就这么简单。

It's really just as simple as that.

我们的方式是将每个节目的数据库调用结果保存到缓存中。

And the way we're doing it is we're saving each database call for each show into the cache.

当我们查询时，首先检查缓存中是否有该节目。

And when we check, we first check the cache to see if the show's in the cache.

如果缓存中有，就返回缓存中的数据。

If it's in the cache, we return the one in the cache.

如果没有，就从数据库中获取。

If it's not, we we get the one from the database.

所以你只在需要从数据库获取信息时才进行数据库调用。

So you're only doing the database calls when you have to get, information from the database.

那么，什么时候必须从数据库获取信息呢？

Now when do have to get information from the database?

我们是按毫秒级别的时间线来设置的。

Well, we set it up on a millisecond timeline.

因此，新的节目会每六百毫秒自动从数据库获取最新数据。

So newer shows automatically will retrieve a new one from the database every six hundred milliseconds.

当它从数据库获取新数据时，会同时更新缓存。

When it retrieves a new one from the database, it then updates the cache.

对吧？

Right?

而较旧的节目则会保留在缓存中长达三千六百毫秒，因为旧节目通常更新频率较低。

And likewise, older shows will be there for three thousand six hundred milliseconds that way because the older shows, you know, they don't get updated as much.

假设我们的节目笔记中出现了错误，我们需要快速更新它。

And let's say we have an, uh-oh, in one of our show notes or something, we need to update it really quick.

我们可以进行这个更新，并确保不是每个人都会收到旧的缓存数据。

We can make that update and be assured that not everybody's going to be served the old cache.

另外，我在管理后台创建了一个清除全部缓存的按钮，Wes，我不知道你有没有看到，用于紧急情况。

Now I also created in the admin section, Wes, I don't know if you've seen this, a drop all cache button in an emergency.

我们想彻底清除整个缓存。

We wanna just completely nuke the cache.

你可以点击这个按钮。

You can click that button.

它会直接删除整个缓存。

It's just gonna delete the cache entirely.

哦，这很好。

Oh, that's good.

我本来也在考虑这个问题。

I was gonna think about that.

是的。

Yeah.

我的意思是，我来自Drupal的世界，在那里每次做任何更改，你都会点击删除全部缓存的按钮，因为所有内容都被缓存得非常彻底。

I mean, I come from the world of Drupal where anytime you make any change, you click the delete all cache button because everything is cached so hard.

是的。

Yeah.

在Drupal的世界里，人人都知道缓存几乎总是问题的根源。

Everybody knows in in Drupal world that your cache is almost always going to be the problem.

所以你知道，你也可以把构建缓存或最新的Git提交作为键的一部分。

So You You know, what you could also do is you could stick the, like, the build cache or the latest git commit as part of the key.

嗯。

Mhmm.

一旦你进行新的构建，我知道像Vercel这样的CDN服务通常都会采用类似的做法。

And then as soon as you do a new build, I know with, like, a lot of Vercel CDN CDN stuff, they do something similar to that.

一旦你有了新构建，整个缓存就会失效。

As as soon as you have a new build, your entire cache is invalidated.

通常来说，我不知道他们是不是这么做的，但你可以用某种唯一的标识符作为缓存键的一部分。

And and generally how I don't know if this is how they do it, but you can just use some sort of unique identifier key as as part of your key creation.

是的。

Yes.

这完全正确。

That's totally true.

我们可以这样做来延长缓存的生命周期。

And we could do that to extend the lifespan of the cache.

但同样，我们的数据更依赖于数据库，而不是网站的构建。

But again, our data is tied more to the database than it is the build of the site.

对吧？

Right?

没错。

Exactly.

是的。

Yeah.

你可能不希望这样。

You maybe don't want that.

对。

Right.

你可以使用文件的哈希值，也许不是哈希值，但你可以使用某种唯一标识符来表明这个节目已被更新，比如它最后更新的时间戳。

You could use the hash of the file, maybe not the hash, but you could use some sort of unique identifier to say that this show has been updated, maybe the timestamp for when it was last updated.

也许这就是一个指标，对吧？

And maybe that's indicator, right?

是的。

Yeah.

但在大多数情况下，你只需要去喝杯咖啡，等你回来时问题就已经解决了。

But in most cases, just go grab a coffee and it will be fixed by the time you're done.

对吧？

Right?

比如，六百毫秒？

Like, six six hundred milliseconds?

六百毫秒。

Six hundred millisecond.

没什么。

Nothing.

是的。

Yeah.

所以你只缓存半秒钟？

So you're only caching it for half a second?

哦，六百毫秒。

Oh, six hundred milliseconds.

你是说六百六百秒吗？大概是。

Are you six hundred six hundred seconds, probably.

是六百秒。

It's six hundred seconds.

天啊。

Oh, man.

这总是让我这样。

That always gets me.

对不起。

I'm sorry.

是六百秒。

It is six hundred seconds.

我在我们的十分钟里写的是毫秒。

I wrote milliseconds in our Ten minutes.

但其实是秒。

But it is seconds.

是的。

Yes.

十分钟。

Ten minutes.

此外，Upstash 有一个很好的登录 API，如果你想知道这个东西是否被缓存了，可以直接查看。

Plus, Upstash has a nice, like, a nice login API where like you can literally if you're wondering, is this thing cached or not?

以及这个东西的过期时间还剩多少？

And how much longer is left on the expiry of this thing?

你可以直接登录 Upstash，他们提供一个简洁的图形界面，你可以查看并直接点击删除按钮，如果你真的想删除的话。

You can just log in to Upstash and they have a nice little GUI for you can you can go look at it and you can just click the delete button if you really want to.

完全正确。

Totally.

Upstash 的定价非常合理，这一点很棒。

And what's great about Upstash is the pricing was very reasonable.

我的意思是，我们实际上没花多少钱，甚至还没达到我们所需支出的任何限额。

I mean, we're not spending really, we haven't even hit any sort of limits for what we need to be spending yet.

所以从成本角度来看，它真的很好。

So cost wise, it's really good.

我过去对为这个服务付费一直很犹豫，因为以前我习惯自己搭建一个私有的 Redis 服务器。

I was very apprehensive about paying for a service for this because in the past I'm used to spinning up a, like a private Redis server and going that way.

但说实话，相比我之前在 Render.com 上运行私有 Redis 服务器为 Level Up 教程服务的开销，现在更便宜。

But honestly, has been cheaper than running a private Redis server on render.com where I did it before for level up tutorials.

它确实比那更便宜。

It's it's been cheaper than that.

所以，你知道的，嘿。

So, you know, hey.

我再次担心这会以不健康的方式增加成本，但事实证明它非常节省成本。

I was concerned again that it would start to add to the cost in an unhealthy way, but it's been very cost effective.

是的。

Yeah.

当然，如果你在听这个播客，并且想在服务器端开发上更进一步，我建议你尝试自己实现一个 Redis 缓存。

Certainly, I would recommend if you're listening to this podcast and you're you're trying to get go a little bit further with your server side development is either a, try to implement a Redis cache yourself.

这和你过去可能做过的许多本地存储设置没什么不同，或者尝试用 JavaScript 的 Map 构建一个简单的内存缓存，因为你经常可以这么做。

It's no different than a lot of, like, local storage settings that you've you've probably done in the past, or try build a little in memory cache with a map in JavaScript because you can I've you do that a lot.

你可以在函数处理程序外部创建一个 Map，然后判断：如果这个 Map 包含某个键，就直接返回它。

You can create a map outside of your function handler and then just say, well, if if the map has this key, then return it.

你还需要为数据添加时间戳，因为你得知道什么时候过期。

You do have to add like a timestamp to your data as well, because you need to know when to expire it.

而这正是 Upstash 这个服务的便捷 API 之处。

And that's the sort of the nice API of this Upstash one.

在 Radius 中，通常可以设置以秒为单位的过期时间。

And in Radius in general, can set an expiry in seconds.

是的。

Yeah.

这确实是一个很棒的功能，能够直接在这里设置过期时间。

That's actually a really great thing about this is being able to set that expiry in there.

这样我就不用自己去计算了。

That way I don't have to do the math myself.

对。

Yeah.

我还写了一个辅助函数来处理这里的 Prisma 调用。

I also just wrote a helper function to do Prisma calls for this.

所以我写了一个小的辅助函数，可以传入查询语句。

So I wrote a little helper function that you can pass in the query.

你可以传入你想执行的函数，它会自动检查缓存，返回正确的结果，而无需你每次都手动操作。

You can pass in the the function you're trying to do, and it will automatically check the cache and return the right one or whatever without you having to do that manually each time.

这只是一个不错的小小辅助函数。

It's just a nice little helper.

添加了 if 语句。

Adding the if statements.

是的。

Yeah.

无需在代码中手动添加 if 语句来填充缓存逻辑。

Without adding the if statements populating your code.

所以现在你只需要调用缓存函数，直接获取数据即可。

So now you just do a a cache function, cache call function, and and pull in that data directly in there.

老实说，这真的非常好，查询速度立刻提升了。

And, honestly, it's been really super nice, and it it it's sped up the queries instantly.

当然。

Absolutely.

我们做的另一件事是，由于我们的网站是完全服务端渲染的，我们确保每个重型路由都设置了缓存头，并且对于新内容，我们采用了完全相同的策略：如果剧集是新的，缓存时间为六百秒。

Another thing we did is since our site is fully server side rendered, we just made sure that every single heavy route got cache headers, and we did the exact same strategy for if the episode is newer, it's going to be six hundred seconds.

如果集数较旧，缓存时间将是3600秒。

If the episode is older, it's gonna be three thousand six hundred seconds in terms of how long it's cached for.

我们还使用了stale-while-revalidate，如果你想了解更多，我们专门做了一期关于这个的节目。

And we also use stale wall revalidate as well, which if you wanna learn more about that, we did an entire episode on that.

韦斯，你记得那期的编号吗？

Wes, do you have that episode number handy?

让我看看。

Let me see.

stale-while-revalidate，新Syntax搜索。

Stale man, the new Syntax search.

让我告诉你。

Let me just tell you.

新Syntax搜索速度非常快。

The new Syntax search is so fast.

关于stale-while-revalidate，第100692期是一个非常好的课程，能帮你更深入地了解为什么你可能想使用它。

You need stale wall revalidate episode 100 692 is a really great lesson to learn a little bit more about why you might want to use that.

无论如何，这些缓存机制加快了我们的初始加载速度，但我们确保每个需要快速加载的页面都启用了数据库缓存，并设置了正确且良好的缓存头，以确保这些页面加载迅速。

Either way, those those caching sped up our initial loading, but we just made sure that every single page that we needed to make sure was fast had database caching and had the correct and good cache headers for us to make sure that those were fast.

没错。

Bingo.

太棒了。

Bango.

大量的速度优化。

Lots and lots of speed improvements.

是的。

Yeah.

在第692期节目中，当我讨论使用缓存验证时，我谈到了我们如何用它来缓存生成的OG图片。

In the episode six ninety two, stay while we're validated, I talked about how we're using it to cache our OG images that are generated.

简单来说，我们使用Puppeteer加载网站中用于生成OG图片的部分。

So real quick, we use Puppeteer to load part of the website that generates the OG images.

它会截取屏幕截图，然后将图片发送出去。

That takes a screenshot, and we'll send it out the other way.

我知道现在有很多库可用。

I know there's lots of libraries out there.

这绝对是最好的方法，我向你保证，如果你想要我们这样的控制权的话。

This is the absolute best way, I guarantee you, if you want the type of control that we want over it.

不过，我在使用过程中遇到一个问题，就是与LinkedIn有关。

Now, I had hit one issue with that, and that was with LinkedIn.

所以我注意到，每当我们把我们的节目分享到LinkedIn时，都看不到漂亮的开放图谱图片。

So I noticed that whenever we shared one of our episodes on LinkedIn, we weren't getting the really nice open graph images.

而这些开放图谱图片在其他所有平台上都表现得非常好。

And those open graph images have been doing super well for us on all of the other platforms.

我们收到了更多人点击，因为它们看起来太棒了。

We're getting a lot more traction of people clicking them because they they look awesome.

对吧？

Right?

但在LinkedIn上却无法正常显示。

And they weren't working on LinkedIn.

所以我又深入研究了一整套复杂的问题，这真是我最不喜欢做的事——改点东西，提交，等构建完成，然后去我用的那个工具里查看。

So I went down the whole rabbit hole again, which is my, like, least favorite thing to do is to try change something, commit it, wait for the thing to build, go to the whatever tool that I'm using.

这次我得用LinkedIn的调试工具，点那个按钮，让它抓取内容，然后给你显示一点关于它将如何展示的信息。

In in this case, I had to use the LinkedIn debugger tool and then press the button and it would scrape it and give you a little bit of information about what it's going to display.

但它就是识别不了Open Graph标签。

And it would not pick up the Open Graph tags.

于是我花了两个小时，尝试了各种标签、不同的Open Graph命名空间，还有name和description、meta这些参数的组合。

So I spent like like two hours trying different tags and different Open Graph namespaces and name versus description and meta.

我跟Polypain聊过，因为他说他那边没问题，但当我真在LinkedIn上发布时，就是不行。

I was talking to from Polypain because like Polypain said it was working fine, but it wasn't working fine when I actually posted it on LinkedIn.

最后我想，也许生成Open Graph图片需要八到十五秒，因为如果要启动一个新浏览器，大概要十五秒；如果不用启动浏览器，大概八秒就能完成截图。

And finally, I thought, like, wonder it it takes between eight and fifteen seconds to generate the open graph image because it has to fire up a fifteen seconds if it has to fire up a new browser, about eight seconds if it doesn't have to fire up the browser and take the thing.

但等一张图片加载这么久，时间太长了。

And that's too long to wait for an image to load.

对吧？

Right?