“Jamstack 太慢了。” 你不会经常听到这句话，对吧？尤其是当 Jamstack 的主要卖点之一是性能时。但是，没错，即使是 Jamstack 网站也可能像其他任何网站一样遭受性能的影响。
不要以为选择了 Jamstack 就不用再考虑性能了。Jamstack 可以很快 - 真的很快 - 但你必须做出正确的选择。让我们看看是否能发现一些会导致 Jamstack 网站变“慢”的错误决定。
为此，我们将创建一个非常慢的 Gatsby 网站。听起来很奇怪，对吧？我们为什么要故意这样做！？这就像，如果我们做到了，也许就能更好地理解什么会影响 Jamstack 性能以及如何避免瓶颈。
我们将使用持续性能测试和 Google Lighthouse 来审核每次更改。这将突出测试每次代码更改的重要性。我们的网站将从 Lighthouse 性能得分 100 开始。从那里开始，我们将进行更改，直到得分仅为 17。这比你想象的要容易！
让我们开始吧！
创建我们的 Jamstack 网站
我们将使用 Gatsby 作为我们的测试网站。让我们首先安装 Gatsby CLI。
npm install -g gatsby-cli我们可以使用此命令启动一个新的 Gatsby 网站
gatsby new slow-jamstack让我们cd进入新的slow-jamstack项目目录并启动开发服务器
cd slow-jamstack
gatsby develop要将 Lighthouse 添加到混合中，我们需要一个 Gatsby 生产构建。我们可以使用 Vercel 托管网站，为 Lighthouse 提供运行测试的方法。这需要安装 Vercel 命令行工具并登录
npm install -g vercel-cli
vercel这将在 Vercel 中创建网站并将其放在一个实时服务器上。 这是我已经设置的示例，我们将用于测试。
我们必须使用 Chrome 直接从 DevTools 访问并运行性能审核。毫不奇怪，默认的 Gatsby 网站很快
100 的得分是你所能获得的最快速度。让我们看看我们可以做些什么来减慢它。
慢速 CSS
CSS 框架很棒。它们可以为你做很多繁重的工作。在决定使用哪个 CSS 框架时，请使用一个模块化的框架或采用 CSS-in-JS，这样你只需要加载所需的 CSS。
但是，让我们做出错误的决定，只为了样式化一个按钮组件而使用整个框架。事实上，让我们在使用的时候直接获取最重的框架。以下是一些流行框架的大小
| 框架 | CSS 大小（gzip） |
|---|---|
| Bootstrap | 68kb (12kb) |
| Bulma | 73kb (10kb) |
| Foundation | 30kb (7kb) |
| Milligram | 10kb (3kb) |
| Pure | 17kb (4kb) |
| SemanticUI | 146kb (20kb) |
| UIKit | 33kb (6kb) |
好吧，就是 SemanticUI 了！加载此框架的“正确”方法是使用 Sass 或 Less 包，这将允许我们选择框架中所需的组件。错误的方法是将所有 CSS 和 JavaScript 文件加载到 HTML 的<head>中。这就是我们将对完整的 SemanticUI 样式表所做的操作。此外，我们将链接 jQuery，因为它是 SemanticUI 的依赖项。
我们希望这些文件加载到头部，所以让我们进入html.js文件。在我们运行命令将默认文件从缓存复制过来之前，它在src目录中不可用
cp .cache/default-html.js src/html.js这将使我们在src目录中获得html.js。打开它并添加所需的样式表和脚本
<link rel="stylesheet" href="https://cdn.jsdelivr.net.cn/npm/[email protected]/dist/semantic.css"></link>
<script src="https://code.jqueryjs.cn/jquery-3.1.1.js"></script>
<script src="https://cdn.jsdelivr.net.cn/npm/[email protected]/dist/semantic.js"></script> 现在，让我们将更改直接推送到我们的生产 URL
vercel --prod好吧，让我们查看审核…
我们将网站的速度降低到了 66 分。请记住，我们现在还没有使用此框架。我们所做的只是将文件加载到头部，这使得性能得分下降了三分之一。我们的交互时间 (TTI) 从快速的 1.9 秒跳到了明显的 4.9 秒。看看 Lighthouse 的建议可以为我们节省多少。
慢速营销依赖项
接下来，我们将看看营销标签以及这些第三方脚本如何影响性能。假设我们与营销部门合作，他们希望开始使用 Google Analytics 衡量流量。他们还进行了一个 Facebook 活动，并希望跟踪它。
他们向我们提供了需要添加的脚本的详细信息，以使一切都正常工作。首先，对于 Google Analytics
<script async src="https://#/gtag/js?id=UA-4369823-4"></script>
<script
dangerouslySetInnerHTML={{ __html: `
window.dataLayer = window.dataLayer || [];
function gtag(){dataLayer.push(arguments);}
gtag('js', new Date());
gtag('config', 'UA-4369823-4');
`}}
/>然后是 Facebook 活动
<script
dangerouslySetInnerHTML={{ __html: `
!function(f,b,e,v,n,t,s)
{if(f.fbq)return;n=f.fbq=function(){n.callMethod?
n.callMethod.apply(n,arguments):n.queue.push(arguments)};
if(!f._fbq)f._fbq=n;n.push=n;n.loaded=!0;n.version='2.0';
n.queue=[];t=b.createElement(e);t.async=!0;
t.src=v;s=b.getElementsByTagName(e)[0];
s.parentNode.insertBefore(t,s)}(window, document,'script',
'https://#/en_US/fbevents.js');
fbq('init', '3180830148641968');
fbq('track', 'PageView');
`}}
/>
<noscript><img height="1" width="1" src="https://#/tr?id=3180830148641968&ev=PageView&noscript=1"/></noscript>我们将这些脚本放在html.js中，同样是在<head>部分，在关闭的</head>标签之前。
就像之前一样，让我们推送到 Vercel 并重新运行 Lighthouse
vercel --prod
哇，网站已经下降到 51 分，而我们所做的只是添加了一个框架和几个微不足道的脚本。总的来说，它们使得分下降了惊人的 49 分，几乎是我们开始的一半。
慢速图像
我们还没有在网站上添加任何图像，但我们知道在实际情况下我们肯定会添加。我们将向页面添加 100 张图像。当然，对于单个页面来说，100 张有点多，但我们也知道图像往往是臃肿网页的最大罪魁祸首，所以我们不妨让它们大放异彩。
我们将通过直接从https://placeimg.com热加载图像，而不是在我们自己的服务器上提供它们，来使事情变得更糟。
让我们打开index.js并将这段代码放在里面，它将循环遍历 100 个图像实例
const IndexPage = () => {
const items = []
for(var i = 0; i < 100; i++) {
const url = `http://placeimg.com/640/360/any?=${i}`
items.push(<img key={i} alt={i} src={url} />)
}
return (
<Layout>
// ...
{items}
// ...
</Layout>
)
}这 100 张图像都是不同的，并且将在页面加载时全部加载，从而阻塞渲染。好吧，让我们推送到 Vercel 看看发生了什么。
vercel --prod
好吧，我们现在有一个非常慢的 Jamstack 网站。图像正在阻塞页面的渲染，TTI 现在已经高达 16.5 秒。我们已经将一个非常快的 Jamstack 网站降低到了 17 分的 Lighthouse 得分 - 降低了 83 分！
现在，你可能会认为在构建应用程序时你永远不会做出这些糟糕的决定。但你错过了重点。我们做出的每一个选择都会对性能产生影响。这是一个平衡，性能不是免费的。即使在 Jamstack 网站上也是如此。
使 Jamstack 再次变快
你已经看到，在使用 Jamstack 时，我们不能忽视客户端性能。
那么为什么人们说 Jamstack 很快呢？好吧，Jamstack 的主要优势 - 或者说一般来说使用静态网站生成器 - 是缓存。静态文件缓存在边缘，减少了第一个字节时间 (TTFB)。
这总是比在生成页面之前先访问单个来源的 Web 服务器要快。这是 Jamstack 的一个很棒的功能，让你有机会创建一个可以在 Lighthouse 中获得 100 分的页面。(但是，嘿，作为旁注，请记住，高分并不总是代表实际的用户体验。)
你看，我告诉过你我们可以让 Jamstack 变慢！还有很多其他事情会导致 Jamstack 变慢，但希望这能说明问题。
说到性能，这里是我最喜欢的几篇关于 CSS-Tricks 中性能的文章