当你用 Eleventy（11ty）搭建一个内容站点，可能会有几十、几百、几千篇文章／页面。你就会想：“如果内容 /页面数量很多，是不是构建生成会变得很慢？ Eleventy 在这方面表现如何？”下面我们来深入分析。
Eleventy 的性能基线
Eleventy 是一个静态网站生成器（Static Site Generator，SSG）。它在“构建阶段”把 Markdown /模板 /数据等内容生成最终的静态 HTML 文件，然后部署或使用静态托管。访问阶段不需要运行数据库或服务器端模板渲染，所以访问性能本身几乎不受页面数影响。关键瓶颈通常在构建／生成阶段，而不是访问。
Eleventy 官方文档中有性能比对：在处理约 4000 个 Markdown 文件时，Eleventy 的构建时间非常短（大约 1.93 秒） — 这说明即使页面数量不少，其性能依然非常优秀。相比某些需要大量运行时的静态生成器／框架，Eleventy 在构建速度上处于领先地位。
当页面／文章数量很多时可能遇到的性能影响点
尽管 Eleventy 的基线性能不错，但当页面数很多或内容／模板结构复杂，会有一些需要注意的性能瓶颈：
文件 I/O 开销
Eleventy 在构建时要读很多 Markdown／模板文件，写出同等数量的 HTML 文件。如果页面数量非常大，文件读写（disk I/O）和文件系统遍历会成为耗时部分。
模板渲染与过滤器／短代码／数据处理
如果每篇文章中使用很多过滤器 (filters)、短代码 (shortcodes)、复杂模板、包含 (includes)、布局 (layouts)、分页 (pagination) 或者动态数据，那么这些处理都会累积额外耗时。每个页面可能执行一大堆的模板逻辑。
资源复制与静态文件处理
除了 HTML 输出，还可能有静态资源 (images, CSS,脚本等) 的复制／压缩／优化任务。如果站点中图片很多、压缩／响应式图像处理 (responsive images) 启用，或者某些资源转换插件／变换器 (transforms) 被启用，那么构建时间会显著增长。
内存与硬件条件限制
当页面非常多、每篇文章内容也不少时，构建过程中会占用更多内存／CPU。开发者机器性能、硬盘速度 (SSD vs HDD)、Node.js 版本、Eleventy 配置与插件所使用的额外任务都会影响整体速度。
本地开发 vs 生产构建
在本地开发模式中，每次修改某个文件可能触发整个站点重建，这在页面很多时体验会显慢。生产环境构建可能触发全站构建；而开发环境若没有增量构建支持，就更容易感觉变慢。
Eleventy 的性能优化机制与特性
Eleventy 为了应对上述瓶颈，提供或支持多种性能优化措施：
增量构建（Incremental Builds）
Eleventy 支持使用命令行参数 --incremental 来仅重建自上次构建以来发生变动的文件。这样，当你修改一篇文章或者一个模板，不需要每次重建整个站点，从而极大减少开发模式下的重建时间。
Debug / Performance 分析工具
Eleventy 提供调试模式（debug mode / benchmark / performance measurements），能让你看到哪些模板／过滤器／数据文件／短代码／静态资源复制占用了多少时间，有助于定位瓶颈并优化。
优化静态资源处理
把资源复制（passthrough copy）等动作尽可能从构建循环中剥离出来；限制对图片或大文件的重复压缩／处理；只在必要的时候对大型资源进行处理。官方建议 “take passthrough copy out of your build-loop”。
模板与布局依赖优化
精简 includes / layouts 的层级关系；避免大量嵌套／递归 includes；使用 Eleventy 的依赖追踪功能（template dependencies）；把常用内容模块化但不要过度复杂化。
硬件／环境优化
使用 SSD 而非慢硬盘；确保 Node.js 与 Eleventy 更新到性能较好的版本；本地开发中关闭不必要的插件／监控；在 CI 或生产构建中缓存中间结果或使用云构建环境等。
实际案例与经验
在官方性能对比中，Eleventy 生成约 4000 个 Markdown 文件所需时间为约 1.93 秒，这说明就算页面数达到几千，Eleventy 在基础场景下“非常快”。
有用户报告，当页面数较多（上百或上千）且文章较多（内容复杂、很多 includes 或分页），在开发模式下重建所需时间可能从几秒到几十秒不等。关键影响因素是模板复杂度与资源处理的负载。比如如果每篇文章都加载外部数据、图片响应式处理、内容中包含很多复杂计算或短代码，那么构建就会变慢。
还有用户反馈：“当 markdown 文件约 180+ 个时，本地重建时间可能是几分钟”，但当使用增量构建，仅修改少数文章时，这种时间会大幅减少。
结论与建议
结论
- 如果只是建立一个中等规模的内容站点（几十到几百篇文章、模板结构合理、资源不至于极重、资源复制／优化任务不复杂），Eleventy 的构建速度依然非常好，生成不会“很慢”。
- 当页面／文章数量非常大（上千、几千以上），或者每篇文章都非常复杂／包含很多依赖／资源处理任务多时，构建时间确实会变长，但很多情况下可以通过优化和配置将这种变慢控制在可接受范围内。
建议
- 启用 增量构建 (--incremental)，特别在本地开发中，这样你只在必要的文件／模板被改动时才重建那些文件。
- 精简模板逻辑：少用复杂 includes、嵌套 layouts、复杂分页等；将通用部分抽出；减少每篇文章加载不必要的全局数据或计算。
- 控制资源处理任务：不要在每篇文章里都重复调用图片处理／压缩／响应式处理，或尽量缓存这些处理结果。
- 测试构建时间：用 debug 模式 / benchmark 输出看看哪些环节耗时最多，并优先优化那些环节。
- 硬件与环境优化：SSD +较新的 Node.js，在 CI／生产用更强或并行能力好的机器，利用缓存。