Lynx | 小熊写字的地方

【译】无头 Chrome：服务端渲染 JS 页面的一个解决方案

2018-09-17

TL;DR

无头 Chrome 是一个将动态 JS 页面转成静态 HTML 页面的即插即用的解决方案。将其运行于 web 服务器之上，你可以预渲染任何现代 JS 特性，从而提速内容加载，并且是可被搜索引擎索引的。

本篇文章介绍的技术，旨在教大家如何使用 Puppeteer 的 API，给一个 Express 服务器添加服务端渲染（SSR）能力。最棒的地方是，应用本身几乎不需要修改任何代码。无头 Chrome 做了所有的重活。三两行代码，SSR 页面带回家。

大餐之前先来点甜点：

import puppeteer from 'puppeteer';

async function ssr(url) {
  const browser = await puppeteer.launch({headless: true});
  const page = await browser.newPage();
  await page.goto(url, {waitUntil: 'networkidle0'});
  const html = await page.content(); // serialized HTML of page DOM.
  await browser.close();
  return html;
}

注意： 我会在文章中使用 ES 模块（import），这要求 Node 8.5.0+，并在运行时加上 --experimental-modules 标志。觉得麻烦的话可以自行使用 require() 语句。关于 Node 上的 ES 模块支持可以读读这篇文章。

## 导论 ----------------------------

如果我对 SEO 理解没有偏差的话，你读到这篇文章可能因为下面两个原因之一。首先，你已经搭建了一个 web 应用，并且它没有被搜索引擎索引！你的应用可能是 SPA，PWA，使用了 vanilla JS，或者使用了其他更复杂的框架或类库。老实说，你使用何种技术并不重要。重要的是，你花费了大量时间搭建出优秀的 web 页面，然而用户却搜不到它。你读这篇文章的另一个理由可能是因为，网上一些文章说了服务端渲染可以提升性能。你希望快速减少 JavaScript 启动时间，提升首次有效绘制速度。

一些框架，比如 Preact 使用了工具来实现服务端渲染。如果你使用的框架具备预渲染的解决方案，请继续使用。没有任何理由引入另一个工具（无头 Chrome / Puppeteer）。

爬取现代网站

搜索引擎爬虫，社交平台，甚至浏览器自诞生至今就唯一依赖于静态 HTML 标记，来索引 web 页面和表层内容。现代 web 页面已经演变的大为不同。基于 JavaScript 的应用，在很多时候，需要保持网站内容是对于爬取工具是可见的。

一些爬虫，比如 Google 搜索，已经变得更智能了！Google 的爬虫使用 Chrome 41 执行 JavaScript，并渲染出最终的页面。但是这个方案才刚出来，还不完美。举个例子，使用了新特性的页面，比如 ES6 Class，模块，箭头函数等，将会在这个比较老的浏览器上报错，使得页面不能正确渲染。至于其他搜索引擎，鬼知道它们在干嘛！？¯_(ツ)_/¯

使用无头 Chrome 预渲染页面

所有的爬虫程序都能够理解 HTML。我们要“解决”索引问题的话需要一个工具，它来执行 JS 生成 HTML。我不会告诉你现在已经有这样一个工具了！

该工具可以运行所有类型的现代 JavaScript，并吐出静态 HTML。
出现新特性时，该工具可以保持更新
已有应用上只需少量代码就可以运行这个工具

听起来很不错吧？这个工具就是浏览器！

无头 Chrome 不在乎你使用什么库、框架或者工具。它将 JavaScript 作为早餐，在午饭前吐出静态 HTML。可能会更快一点 :) -Eric

如果你用的 Node，Puppeteer 容易上手。它的 API 提供了预渲染客户端应用的能力。下面用个例子演示下。

1. JS 应用示例

我们以一个 JavaScript 生成 HTML 的动态页面为例：

public/index.html

<html>
<body>
  <div id="container">
    <!-- Populated by the JS below. -->
  </div>
</body>
<script>
function renderPosts(posts, container) {
  const html = posts.reduce((html, post) => {
    return `${html}
      <li class="post">
        <h2>${post.title}</h2>
        <div class="summary">${post.summary}</div>
        <p>${post.content}</p>
      </li>`;
  }, '');

  // CAREFUL: assumes html is sanitized.
  container.innerHTML = `<ul id="posts">${html}</ul>`;
}

(async() => {
  const container = document.querySelector('#container');
  const posts = await fetch('/posts').then(resp => resp.json());
  renderPosts(posts, container);
})();
</script>
</html>

2. 服务端渲染函数

接下来，我们会使用之前提到的 ssr() 函数，并充实它的内容。

ssr.mjs

import puppeteer from 'puppeteer';

// In-memory cache of rendered pages. Note: this will be cleared whenever the
// server process stops. If you need true persistence, use something like
// Google Cloud Storage (https://firebase.google.com/docs/storage/web/start).
const RENDER_CACHE = new Map();

async function ssr(url) {
  if (RENDER_CACHE.has(url)) {
    return {html: RENDER_CACHE.get(url), ttRenderMs: 0};
  }

  const start = Date.now();

  const browser = await puppeteer.launch();
  const page = await browser.newPage();
  try {
    // networkidle0 waits for the network to be idle (no requests for 500ms).
    // The page's JS has likely produced markup by this point, but wait longer
    // if your site lazy loads, etc.
    await page.goto(url, {waitUntil: 'networkidle0'});
    await page.waitForSelector('#posts'); // ensure #posts exists in the DOM.
  } catch (err) {
    console.error(err);
    throw new Error('page.goto/waitForSelector timed out.');
  }

  const html = await page.content(); // serialized HTML of page DOM.
  await browser.close();

  const ttRenderMs = Date.now() - start;
  console.info(`Headless rendered page in: ${ttRenderMs}ms`);

  RENDER_CACHE.set(url, html); // cache rendered page.

  return {html, ttRenderMs};
}

export {ssr as default};

主要的变化：

添加了缓存。缓存已渲染的 HTML 对于加速响应时间居功至伟。当页面再次有请求过来，避免了无头 Chrome 的重复执行。我随后会讨论其他的优化。
添加加载页面超时时的基本错误处理。
添加了 page.waitForSelector('#posts') 这行代码。确保在丢弃这个序列化页面之前，posts 节点存在于 DOM 之中。
记录无头浏览器渲染页面所用时间。
代码都被封装进名为 ssr.mjs 的模块中。

3. web 服务器示例

最后，一个小的 express 服务器完成了所有的工作。它预渲染 URL http://localhost/index.html（主页），并在响应中返回渲染结果。由于响应中包含了静态 HTML，当用户访问页面，posts 节点会立刻呈现。

server.mjs

import express from 'express';
import ssr from './ssr.mjs';

const app = express();

app.get('/', async (req, res, next) => {
  const {html, ttRenderMs} = await ssr(`${req.protocol}://${req.get('host')}/index.html`);
  // Add Server-Timing! See https://w3c.github.io/server-timing/.
  res.set('Server-Timing', `Prerender;dur=${ttRenderMs};desc="Headless render time (ms)"`);
  return res.status(200).send(html); // Serve prerendered page as response.
});

app.listen(8080, () => console.log('Server started. Press Ctrl+C to quit'));

要运行这个例子，需安装依赖 (npm i --save puppeteer express)，然后使用 Node 8.5.0+ 并带有 --experimental-modules 标志来运行服务器。

这是一个该服务器返回的响应示例：

<html>
<body>
  <div id="container">
    <ul id="posts">
      <li class="post">
        <h2>Title 1</h2>
        <div class="summary">Summary 1</div>
        <p>post content 1</p>
      </li>
      <li class="post">
        <h2>Title 2</h2>
        <div class="summary">Summary 2</div>
        <p>post content 2</p>
      </li>
      ...
    </ul>
  </div>
</body>
<script>
...
</script>
</html>

Server-Timing API 的一个最佳用例

Server-Timing API 支持将服务器性能指标（比如请求/响应时间，数据库查询）返回给浏览器。客户端可以使用这些信息来追踪 web 应用的所有性能数据。

Server-Timing 的一个最佳用例是上报无头 Chrome 预渲染页面的时间！只需在响应上添加 Server-Timing 头，就可以实现这一点：

res.set('Server-Timing',  `Prerender;dur=1000;desc="Headless render time (ms)"`);

客户端上，Performance Timeline API 和 PerformanceObserver 可以获取这些指标：

  const entry = performance.getEntriesByType('navigation').find(
    e => e.name === location.href);
console.log(entry.serverTiming[0].toJSON());

{
  "name": "Prerender",
  "duration": 3808,
  "description": "Headless render time (ms)"
}

性能结果

注意： 这些数据体现了我随后讨论的大多数性能优化。

性能数据怎么样？在我的一个应用(代码)上，无头 Chrome 渲染页面大约需要 1s。页面被缓存后， 3G 低网速模拟下，FCP 要比客户端渲染版本的快 8.37s。

	首次绘制 (FP)	首次内容绘制 (FCP)
客户端渲染	4s	11s
服务端渲染	2.3s	~2.3s

这些结果很有用。因为服务端渲染页面不再依赖于 JavaScript 的加载，用户看到有意义的内容比以前快得多。

Preventing re-hydration

还记得我说“我们无需在客户端应用上改任何代码”吗？那是骗你们的。

Express 应用接收请求，使用 Puppeteer 将页面加载进无头浏览器，然后在响应中返回结果。但这里有一个问题。

浏览器加载页面时，无头 Chrome 中相同的 JS 会在服务器上再次执行。有两处都在生成 HTML。

一起来修复这个问题。我们要告知页面，它的 HTML 早就名花有主了。我找到的解决方案是，在页面加载时判断 <ul id="posts"> 是否已在 DOM 中，如果在，页面就已经在服务端渲染过了，这样就可以避免重新创建 DOM。

public/index.html

<html>
<body>
  <div id="container">
    <!-- Populated by JS (below) or by prerendering (server). Either way,
         #container gets populated with the posts markup:
      <ul id="posts">...</ul>
    -->
  </div>
</body>
<script>
...
(async() => {
  const container = document.querySelector('#container');

  // Posts markup is already in DOM if we're seeing a SSR'd.
  // Don't re-hydrate the posts here on the client.
  const PRE_RENDERED = container.querySelector('#posts');
  if (!PRE_RENDERED) {
    const posts = await fetch('/posts').then(resp => resp.json());
    renderPosts(posts, container);
  }
})();
</script>
</html>

优化

除了缓存渲染结果之外，还有一些有趣的优化技巧。有的优化可以快速见效，而有的可能带有猜测性的。

中止不必要的请求

现在，整个页面（以及它请求的所有资源）都无脑地加载进无头 Chrome。然而，我们只关注于两件事情：

渲染 HTML
生成 HTML 的 JS

不构造 DOM 的网络请求是浪费的。一些资源，比如图片、字体、样式表和媒体内容，不参与页面的 HTML 构建。它们负责添加样式，补充页面的结构，但并不显式地创建页面。我们应该告诉浏览器去忽略掉这些资源！这样可以减少无头 Chrome 的工作负担，从而节省带宽，并且潜在地加速了大型页面的预渲染时间。

Protocol 开发者工具提供了一个强大的特性，叫做网络拦截。它可以用于在浏览器发出之前修改请求。Puppeteer 也支持网络拦截，它是通过打开 page.setRequestInterception(true)，监听页面的 request 事件来实现的。这样我们可以中止某些资源请求。

ssr.mjs

async function ssr(url) {
  ...
  const page = await browser.newPage();

  // 1. Intercept network requests.
  await page.setRequestInterception(true);

  page.on('request', req => {
    // 2. Ignore requests for resources that don't produce DOM
    // (images, stylesheets, media).
    const whitelist = ['document', 'script', 'xhr', 'fetch'];
    if (!whitelist.includes(req.resourceType())) {
      return req.abort();
    }

    // 3. Pass through all other requests.
    req.continue();
  });

  await page.goto(url, {waitUntil: 'networkidle0'});
  const html = await page.content(); // serialized HTML of page DOM.
  await browser.close();

  return {html};
}

注意： 安全起见，我使用了一个白名单，允许所有其他类型的请求能够继续正常发出。预先避免中止掉其他必要的请求。

内联关键资源

使用构建工具（比如 gulp）编译应用，并在构建时将关键 CSS/JS 内联到页面内，是一种很常见的做法。由于浏览器初始化页面加载时的请求数更少了，这样也就加速了首次有效绘制时间。

别用构建工具了，浏览器就是你的构建工具！我们可以用 Puppeteer 管理页面 DOM，内联样式，JavaScript，或者其他任何你想在预渲染之前加到页面中的东西。

这个例子演示了如何拦截本地样式表的响应，并将这些资源内联进 <style> 标签中：

ssr.mjs

import urlModule from 'url';
const URL = urlModule.URL;

async function ssr(url) {
  ...
  const stylesheetContents = {};

  // 1. Stash the responses of local stylesheets.
  page.on('response', async resp => {
    const responseUrl = resp.url();
    const sameOrigin = new URL(responseUrl).origin === new URL(url).origin;
    const isStylesheet = resp.request().resourceType() === 'stylesheet';
    if (sameOrigin && isStylesheet) {
      stylesheetContents[responseUrl] = await resp.text();
    }
  });

  // 2. Load page as normal, waiting for network requests to be idle.
  await page.goto(url, {waitUntil: 'networkidle0'});

  // 3. Inline the CSS.
  // Replace stylesheets in the page with their equivalent <style>.
  await page.$$eval('link[rel="stylesheet"]', (links, content) => {
    links.forEach(link => {
      const cssText = content[link.href];
      if (cssText) {
        const style = document.createElement('style');
        style.textContent = cssText;
        link.replaceWith(style);
      }
    });
  }, stylesheetContents);

  // 4. Get updated serialized HTML of page.
  const html = await page.content();
  await browser.close();

  return {html};
}

这段代码：

使用一个 page.on('response') 处理器来监听网络响应。
储藏本地样式表的响应。
找到 DOM 中所有的 <link rel="stylesheet">，将它们替换成一个等价的 <style>。具体见 page.$$eval API 文档。style.textContent 被设为样式表的响应内容。

自动压缩资源

另一个可以借助网络拦截玩的小把戏是修改请求的响应内容。

举个例子，你想要压缩 CSS，但也希望开发阶段不要被压缩，这样开发时能方便些。假设你已经用另一个工具来预压缩 styles.css，可以用 Request.respond()，将 styles.css 的内容重写为 styles.min.css。

ssr.mjs

import fs from 'fs';

async function ssr(url) {
  ...

  // 1. Intercept network requests.
  await page.setRequestInterception(true);

  page.on('request', req => {
    // 2. If request is for styles.css, respond with the minified version.
    if (req.url().endsWith('styles.css')) {
      return req.respond({
        status: 200,
        contentType: 'text/css',
        body: fs.readFileSync('./public/styles.min.css', 'utf-8')
      });
    }
    ...

    req.continue();
  });
  ...

  const html = await page.content();
  await browser.close();

  return {html};
}

重用 Chrome 实例实现交叉渲染

每次预渲染都启动新的浏览器会很浪费。相反，你希望只启动一个实例，然后在多个页面渲染时重用它。

Puppeteer 可以通过调用 puppeteer.connect()，连接到一个已有的 Chrome 实例，它接收实例的远程调试 URL 作为参数。为保证浏览器实例的长时间运行，我们可以将 ssr() 函数启动 Chrome 这部分代码移到 Express 服务器里。

server.mjs

import express from 'express';
import puppeteer from 'puppeteer';
import ssr from './ssr.mjs';

let browserWSEndpoint = null;
const app = express();

app.get('/', async (req, res, next) => {
  if (!browserWSEndpoint) {
    const browser = await puppeteer.launch();
    browserWSEndpoint = await browser.wsEndpoint();
  }

  const url = `${req.protocol}://${req.get('host')}/index.html`;
  const {html} = await ssr(url, browserWSEndpoint);

  return res.status(200).send(html);
});

ssr.mjs

import puppeteer from 'puppeteer';

/**
 * @param {string} url URL to prerender.
 * @param {string} browserWSEndpoint Optional remote debugging URL. If
 *     provided, Puppeteer's reconnects to the browser instance. Otherwise,
 *     a new browser instance is launched.
 */
async function ssr(url, browserWSEndpoint) {
  ...
  console.info('Connecting to existing Chrome instance.');
  const browser = await puppeteer.connect({browserWSEndpoint});

  const page = await browser.newPage();
  ...
  await page.close(); // Close the page we opened here (not the browser).

  return {html};
}

例子：实现周期性预渲染的定时任务

在 App 引擎面板应用里，我创建了一个定时处理器，来周期性的重复渲染排名前几位的页面。帮助用户快速看到最新内容，他们根本感知不到一个新页面的启动性能消耗。在这个例子中，生成多个 Chrome 实例会很浪费。相反，我用了一个共享的浏览器实例来一次性渲染这些页面。

import puppeteer from 'puppeteer';
import * as prerender from './ssr.mjs';
import urlModule from 'url';
const URL = urlModule.URL;

app.get('/cron/update_cache', async (req, res) => {
  if (!req.get('X-Appengine-Cron')) {
    return res.status(403).send('Sorry, cron handler can only be run as admin.');
  }

  const browser = await puppeteer.launch();
  const homepage = new URL(`${req.protocol}://${req.get('host')}`);

  // Re-render main page and a few pages back.
  prerender.clearCache();
  await prerender.ssr(homepage.href, await browser.wsEndpoint());
  await prerender.ssr(`${homepage}?year=2018`);
  await prerender.ssr(`${homepage}?year=2017`);
  await prerender.ssr(`${homepage}?year=2016`);
  await browser.close();

  res.status(200).send('Render cache updated!');
});

我还在 ssr.js export 上加了一个 clearCache() 函数。

...
function clearCache() {
  RENDER_CACHE.clear();
}

export {ssr, clearCache};

## 其他因素 ------------------------------------

告诉页面：“你正在被无头浏览器渲染”

当页面正在服务器上的无头 Chrome 中渲染时，客户端逻辑很有必要知道这一信息。我的应用使用了钩子来“关闭”部分不参与渲染 post 节点的页面。举例来说，我禁用了懒加载 firebase-auth.js 这部分代码。根本不需要用户登录！

在 URL 上加一个 ?headless 参数，是一个给页面加钩子的简单方法：

ssr.mjs

import urlModule from 'url';
const URL = urlModule.URL;

async function ssr(url) {
  ...
  // Add ?headless to the URL so the page has a signal
  // it's being loaded by headless Chrome.
  const renderUrl = new URL(url);
  renderUrl.searchParams.set('headless', '');
  await page.goto(renderUrl, {waitUntil: 'networkidle0'});
  ...

  return {html};
}

可以在页面内查询该参数：

public/index.html

<html>
<body>
  <div id="container">
    <!-- Populated by the JS below. -->
  </div>
</body>
<script>
...

(async() => {
  const params = new URL(location.href).searchParams;

  const RENDERING_IN_HEADLESS = params.has('headless');
  if (RENDERING_IN_HEADLESS) {
    // Being rendered by headless Chrome on the server.
    // e.g. shut off features, don't lazy load non-essential resources, etc.
  }

  const container = document.querySelector('#container');
  const posts = await fetch('/posts').then(resp => resp.json());
  renderPosts(posts, container);
})();
</script>
</html>

Tip：Page.evaluateOnNewDocument() 也可以方便的查询参数。它会在页面中注入代码，让 Puppeteer 在页面中剩余待执行的 JavaScript 之前运行这些代码。

避免 PV 膨胀

你如果正在页面上使用分析工具，那么要小心了。预渲染的页面可能会造成 PV 出现膨胀。具体来说，打点数据将会提升2倍，一半是在无头 Chrome 渲染时，另一半出现在用户浏览器渲染时。

那么怎么修复这个问题呢？将所有加载分析脚本的请求拦截掉。

page.on('request', req => {
  // Don't load Google Analytics lib requests so pageviews aren't 2x.
  const blacklist = ['www.google-analytics.com', '/gtag/js', 'ga.js', 'analytics.js'];
  if (blacklist.find(regex => req.url().match(regex))) {
    return req.abort();
  }
  ...
  req.continue();
});

代码不加载，页面访问就不会被记录。真 Skr 个机灵鬼 💥。

或者，你也可以继续加载分析脚本，来获悉服务器上运行的预渲染器数。

结论

Puppeteer 通过运行无头 Chrome，不费吹灰之力就实现了服务端渲染。提升加载性能和没有改动大量代码就增强了应用的可索引性，是这个方案中我最喜欢的“特性”。

注意： 如果你对文章中描述的技术感兴趣，可以去看看这个应用，以及它的代码。

附录

现有技术的讨论

很难在服务端上渲染客户端应用。有多难？去看看大家给这个话题奉献了多少个 npm 包就知道了。有数不清的模式，工具，和服务来辅助服务端渲染的 JS 应用。

同构 JavaScript

同构 JavaScript 的概念很简单：同样的代码既能在服务端运行，也能在客户端（浏览器）运行。服务器和客户端共享代码，美滋滋！

实践中，我发现同构 JS 很难实现。这是我自己的问题…

我最近开始做一个项目，尝试下 lit-html。Lit 是一个优秀的库，它可以允许你写使用 JS 模板字符串写 HTML <template>，然后高效地将这些模板渲染为 DOM。问题是它的核心特性（使用 <template> 元素）只能在浏览器上工作。这意味着它在 Node 服务器上不能运行。我希望 Node 和前端共享的 SSR 代码能够脱离 window 对象。

最后我意识到可以使用无头 Chrome 来服务端渲染应用，Chrome 是经用户的手运行或是在服务器上自动运行并不重要，它反正是愉快地执行了所有 JS。不要多问。

无头 Chrome 在服务器和客户端上启用 “同构 JS”。它对于当前库不支持服务端（Node）给出了一个不错的解决方案。

预渲染工具

Node 社区已经诞生了好几吨解决服务端渲染 JS 应用的工具。毫无新意！个人而言，我发现各人对于这些工具的体会可能不同，所以使用这些工具前肯定要做好功课。比如说，一些服务端渲染工具比较老，并且没有使用无头 Chrome（或者任何其他无头浏览器）。相反，它们使用 PhantomJS（又名旧 Safari），这意味着使用新特性时页面不会正确渲染。

一个值得注意的例外是 Prerender。Prerender 使用了无头 Chrome 和 Express 中间件。

const prerender =  require('prerender');  
const server = prerender();  
server.use(prerender.removeScriptTags());  
server.use(prerender.blockResources());  
server.start();

Prerender 省去了跨平台下载和安装 Chrome 的所有细节。要正确完成这一过程通常是相当棘手的，这也是 Puppeteer 存在的原因之一。我也提了一些渲染我的部分应用的 issue。

浏览器中渲染的 Chrome 状态

prerender 渲染的 Chrome 状态