js提取指定网站内容(基于PHP的CMS移植到基于JavaScript的静态网站时会)

　　js提取指定网站内容(基于PHP的CMS移植到基于JavaScript的静态网站时会)

　　今年年初，我终于决定将我的网站从基于PHP的cms迁移到基于JavaScript的静态网站*敏*感*词*（SSG）。原因如下：

　　虽然我一开始是一个“全栈”的开发者，但现在我只负责前端工作：如果我需要编写自定义函数，那么我不想编写可以使用 PHP 用 Ja​​vaScript 编写的代码。我不需要抽象层，也不需要cms的复杂性——我最喜欢在markdown文件中写内容，我希望我再也不要碰Mysql数据库或所见即所得的编辑器。我想提高 网站 的性能：静态 HTML 文件在 99% 的情况下比动态页面快。最后，还有成本优势：LAMP 堆栈服务器必须按月付费；Netlify 的免费套餐（每月构建 300 分钟）应该可以轻松满足零成本个人博客的需求。

　　当我决定使用静态站点*敏*感*词*和 JavaScript（不包括 Jekyll 和 Hugo）时，只有两种截然不同的选择。

　　“我听说盖茨比很管用”

　　根据官方 网站 的声明，“Gatsby 是一个基于 React 的免费开源框架，可以帮助开发者快速构建网站 和应用程序”。它有一个 GraphQL 支持的数据层，并将所有内容输出到静态文件，让您几乎可以在任何地方托管它。

　　当我第一次听说我可以编写 React 并使用这个很酷的新 GraphQL 小工具，同时仍然能够输出不需要 JavaScript 的静态页面时，我想尝试一下。我是这样认为的：“这听起来像是增量增强，但不需要太多投资。” 不幸的是，就像大多数听起来太美的东西一样，经过一番调查，我发现它是一个坑。当用户第一次访问 Gatsby 网站 时会发生这些事情：

　　用户请求一个页面。服务器将静态生成的 HTML 文档发送到用户的浏览器，然后浏览器开始呈现页面。HTML 文档到达后，JavaScript 包（包括 React 库和其他渲染页面所需的 JavaScript）开始在后台下载、解析和编译。JavaScript 已准备好运行——整个 DOM 通过 React 组件“水化”。

　　这里有问题——Gatsby 要求你以 React 组件的形式再次加载页面；在完成此额外步骤之前，所有需要 JavaScript 的元素（例如按钮、菜单和自定义输入）实际上都无法进行交互。

　　即使你的 网站 没有任何交互元素（除了链接，即使没有 Gatsby 也不需要 JavaScript 才能工作），你的用户也必须下载这部分 JavaScript，只是为了转移你的 网站 成为单页应用程序（SPA）；SPA 有其自身的不足，我们稍后再谈。

　　这个额外的操作似乎违背了我转向SSG（提高页面速度）的初衷。华丽的 Gatsby 网站 在 2000 美元的 MacBook 上可能很快，但对于有 3G 连接和廉价智能手机的用户来说，它表明它可以显示，但没有任何反应；用户等待加载 JavaScript 的过程持续 15 秒。电池和数据流量也必须下降。

　　如果浏览器需要解析296kb的JavaScript代码来显示博客列表文章，这不是“渐进增强”，而是错误的工具。从网站 /Web应用程序的一般区别来看，React是用来构建Web应用程序的，需要有一个交互式的UI来响应用户输入或实时获取数据；而博客只是一个 网站 就是这样。

　　单页应用程序的可访问性

　　单页应用网站摒弃了传统的Web导航方式，通过加载新的HTML文档来加载新的内容；相反，它使用 AJAX 和 History API 等 JavaScript 功能来切换到新内容。, 不触发页面加载。它的目标是提高感知性能并使 网站 看起来更像“原生”应用程序（从应用程序商店下载的那种）。不再需要重新加载整页的问题在于浏览器和辅助技术使用页面加载作为触发某些有用行为的信号，包括宣布新页面的标题或将键盘焦点重置到文档的开头。

　　如果您正在开发一个专注于可访问性的单页应用程序，那么您可能会尝试使用 JavaScript 来模拟浏览器行为。Gatsby 试图通过收录一个 RouteAnnouncer 组件来为您解决这个问题。它使用 ARIA 实时区域来宣布页面的标题或 h1，以提示屏幕阅读器软件的用户跳转到该页面。但是这种方法也存在问题：在配置和本地化方面还有很多未解决的问题。

　　我们已经看到单页应用在导航方面存在固有的可访问性问题，但需要注意的是，使用前端框架也会带来其他方面的可访问性问题。在 2020 年 2 月对 100 万个主页的调查中，WebAIM 发现使用 React 的网页的可访问性错误比平均水平高 5.7%；而使用 Vue 的网页要高出 25%。这并不一定意味着框架会导致这些错误，但更多的 JavaScript 和更差的可访问性之间存在很强的相关性。

　　博客真的需要 JavaScript 吗？

　　您构建的第一个网页的性能很可能会比之后构建的许多页面要好得多——它由一个 HTML 文件和一些 CSS 组成，可能还有一些未优化的图像，但它们不会阻止页面加载。如果您有和我一样的经验，那么从您开始添加 JavaScript 的那一刻起，您的网页性能就会开始急剧下降。并非所有字节都相同：与解析、编译和执行相同大小的 JavaScript 文件所需的时间相比，解码图像并将其渲染到屏幕所需的时间要少得多。

　　JavaScript 是一种强大的语言，可以完成一些令人难以置信的事情，但您很容易在开发过程中过早地开始使用它。其实HTML和CSS就够了。您应该查看功能最少的原则：在充分利用功能较弱的语言 (HTML) 之前，不要使用功能更强大的语言 (JavaScript)。在我看来，将博客变成 JavaScript 单页应用程序会带来不必要的复杂性。

　　这个 文章 不是为了批评盖茨比而写的。背后有一些聪明人，他们已经承认了本文提到的许多问题，并试图解决它们。静态渲染和水合页面仍然比完全客户端渲染的 React 应用程序（例如 create-react-app 生成的页面）要好得多，后者在没有 JavaScript 的情况下无法使用。我对盖茨比的宣传方式真的很不满意。他们说 Gatsby 适合任何类型的 网站。客户端 JavaScript 是有成本的，开发人员应该意识到这一点。

　　用更少的 JavaScript 构建 Gatsby 网站

　　这让我陷入了两难境地：使用 Gatsby 开发 网站 是一种美妙的体验；但开发体验 (DX) 应始终排在用户体验 (UX) 之后。那么如何避免在构建 Gatsby 网站 时大量使用 JS 带来的固有问题呢？当然，我们应该尝试删除那些 JavaScript。幸运的是，Gatsby 社区已经做了很多努力来构建一个更轻量级的 网站：

　　首先，使用 gatsby-plugin-preact 用 Preact 替换 React 可以节省几千字节。我在组件库中使用了它，并立即将 JavaScript 负载减少了大约 30kb。

　　如果您想要更激进的方法，可以使用插件从 Gatsby 网站 中删除所有 Gatsby JavaScript。

　　您可以继续编写 React 组件和 GraphQL，甚至可以使用 CSS-in-JS 库（只要它输出 CSS 或内联样式），而无需向浏览器发送任何 JavaScript。Gatsby 的大部分问题都可以通过丢弃所有客户端 JavaScript 来解决。Gatsby Starter Low Tech 博客使用无 JavaScript 插件和其他技术（包括将所有图像转换为灰度）来帮助您创建一个轻量级且节能的博客。

　　从零开始

　　这时候感觉有点不对劲——使用了一个框架，推送了大量的客户端JavaScript，却删除了所有的JavaScript代码。这似乎是一个非常复杂的网站构造方法。我想看看我是否可以在没有客户端JavaScript的情况下构建一个功能齐全的博客，所以我不需要任何插件来删除它。所以我转向了另一个选择：

　　Eleventy 鼓励您按照自己的意愿构建 网站。您可以使用您最熟悉的技术，它只负责生成页面。Eleventy 为您提供了十种模板语言选项，可以任意搭配，包括markdown、nunjucks 和liquid；这意味着我可以从 Craft 复制和粘贴旧模板，更改文件扩展名，并进行一些小的调整。运行于十一。不需要为任何新打包器调整前端构建过程，我只需要放入现有的 webpack 文件和 src 文件夹。使用并发包，我可以在 Eleventy 的服务过程中同时运行构建脚本。

　　和 Gatsby 一样，Eleventy 也有一个插件生态系统（虽然很小，但增长很快）。我选择了一些可以在不添加客户端 JavaScript 的情况下添加功能的插件：

　　当代码片段显示在帖子中时，它通常包括特定于语言的语法突出显示。有一些 JavaScript 库可以做到这一点，最流行的似乎是 Prism——你可以在客户端运行它，但由于我们使用的是 JavaScript SSG，我们可以在构建时运行它并突出显示语法 HTML 元素和 CSS显示所需的类直接烘焙到文档中——因此无需在浏览器中下载库。

　　11-plugin-embed-tweet 也可以在构建时而不是在客户端运行 JavaScript。Twitter 的默认嵌入代码强制用户下载大量 JavaScript 以显示推文。该插件可以在构建时获取和渲染推文，因此只需要少量的 HTML 和 CSS，完全不需要额外的 JavaScript。

　　与其他新技术一样，Eleventy 缺少一些更成熟的工具提供的功能。例如，在 Eleventy 中没有优雅的方式来生成响应式图像。相比之下，Gatsby 中优秀的 gatsby-image 插件可以生成延迟加载和响应式图像元素，加载全分辨率文件后可以在低分辨率或 SVG 版本的图像之间平滑切换。Eleventry还有一个让我困惑的地方：我有段时间没了解它的分页功能，以为它只是把帖子分页成指定大小的组，然后意识到它可以动态生成全新的页面；我还发现自己在同一个文件中混用了模板语言：可以随意在markdown文件中收录nunjucks标签，或者用JavaScript替换基于yaml的frontmatter，

　　综上所述

　　如果你仍然选择 Gatsby，我不会责怪你——有时使用自以为是的框架是好的，如果你想快速完成工作，这是一个可靠的解决方案。只需注意其性能成本以及与 JavaScript 相关的所有潜在可访问性问题。

　　我选择用Eleventy来搭建自己的网站，但我知道这种方法并不适合所有人——完全按照自己的意愿来搭建可能会很麻烦。但是你不需要完全向我学习——和 Gatsby 类似，Eleventy 也有很多可以作为基础的入门项目。其中一些工具，例如 Andy Bell 的 Hylia 入门套件，可以在几分钟内获得一个 网站。它甚至预配置了 Netlify cms，因此您无需编写任何代码即可编辑 网站 的内容。

　　我学到了什么？使用 Eleventy 无需 JavaScript 即可轻松构建博客，但总会有一些功能需要客户端 JavaScript：

　　我会在不久的将来将 JavaScript 添加到 网站 吗？答案可能是否定的：我上面列出的功能并不那么重要。我不建议大家删除你网站上的所有JavaScript文件，但是从现在开始，在构建网站的时候，我会尽量把JavaScript当作一个可选的额外功能，而不是基本的体验组件。我鼓励你也这样做。

　　关注我转发这篇文章文章，私信我“接收信息”，即可免费获得价值4999元的InfoQ迷你书！