关于Chrome Headless会话不可预测的 * CPU * 和 * 内存消耗 *，已经有很多讨论。
根据讨论构建headless以最小化cpu + mem使用率，可以通过以下方式优化CPU+内存使用率：

• 使用自定义代理或C++ ProtocolHandlers，您可以返回存根1x1像素图像，甚至完全阻止它们。
• Chromium团队正致力于在生成帧时添加一个programmatic control。目前headless chrome仍然试图以60 fps的速度渲染，这相当浪费。许多页面确实需要一些帧（可能是10 - 20 fps）才能正确渲染（由于使用了requestAnimationFrame和animation triggers），但我们预计这里会节省大量CPU。
• MemoryInfra应该可以帮助您确定在您的设置中哪个组件占用的内存最多。
• 用法可以是：

$ headless_shell --remote-debugging-port=9222 --trace-startup=*,disabled-by-default-memory-infra http://www.chromium.org

• Chromium总是尽可能多地使用可用的资源，如果您想有效地限制它的使用率，您应该考虑使用cgroups

上面已经提到了几点，下面是在生产环境中运行headless浏览器时需要采用的一些常见最佳实践：

• • 图：Headless Chrome的资源使用情况不稳定**〈/sup
• • 不要运行无头浏览器 *：

不管怎么说，如果可能的话，不要运行无头浏览器。无头浏览器是不可预测的，而且很饥渴。几乎所有你能用浏览器做的事情（除了插入和运行JavaScript）都可以用简单的Linux工具完成。有一些库提供优雅的Node API，用于通过HTTP请求和刮取获取数据，如果这是你的最终目标的话。

• • 不需要时不要运行无头浏览器 *：

有些用户试图保持浏览器打开，即使在不使用的时候，这样它总是可以用于连接。虽然这可能是一个很好的策略，以帮助加快会话启动，但它只会在几个小时后结束痛苦。这主要是因为浏览器喜欢缓存的东西，慢慢地消耗更多的内存。任何时候你不积极使用浏览器，关闭它!

• • 与浏览器并行，而不是与页面并行 *：

我们应该只在绝对必要的时候运行一个会话，下一个最佳实践是在每个浏览器上只运行一个会话。虽然通过并行处理页面可以节省一些开销，但如果一个页面崩溃，它可能会导致整个浏览器崩溃。另外，每个页面并不能保证是完全干净的（cookie和存储可能会泄漏）。

• • • page.waitForNavigation**：

最常见的问题之一是触发页面加载的操作，以及脚本执行的突然丢失。这是因为触发pageload的操作通常会导致后续工作被吞噬。为了解决这个问题，通常必须调用page-loading-action并立即等待下一个页面加载。

• • 使用Docker包含所有内容 *：

Chrome需要很多依赖项才能正常运行。即使所有这些都完成了，你还是要担心字体和幻像进程之类的问题，所以使用某种容器来包含它是理想的。Docker几乎是为这项任务定制的，因为你可以限制可用资源的数量并用沙箱保护它。自己创建自己的Docker文件。
为了避免运行僵尸进程（这在Chrome中很常见），您需要使用类似**dumb-init**的命令来正确启动。

• • 两个不同的运行时 *：

可以有两个 * JavaScript运行时 * 在运行（Node和浏览器），这对于可共享性来说是很好的，但它的代价是混乱，因为一些页面方法将要求您显式地传入引用（而不是使用闭包或提升）。
举个例子，当在协议的底层使用page.evaluate时，这实际上是stringifies函数，并将其传递到Chrome，所以闭包和提升之类的操作根本不起作用。如果你需要将一些引用或值传递到evaluate调用中，只需将它们作为参数附加，这样就可以得到正确的处理。
参考：Observations running 2 million headless sessions

考虑使用Docker。它有很好的文档功能来限制系统资源的使用，比如内存和CPU。好消息是，它很容易建立一个内部有无头Chrome（在X11之上）的Docker映像。
这方面有很多现成的解决方案，请查看：https://hub.docker.com/r/justinribeiro/chrome-headless/