你觉得你的 WordPress 网站很慢吗？想要加快网站速度却不知道该怎么做？这篇文章将会用浅显易懂的方式分享我对 WordPress 网页加速的心得，还有在 GTmetrix 和 Google 网站速度测试 PageSpeed Insights 拿到满分的方法。
在正式开始之前，先提一点关于 WordPress 网站速度（Page Speed）的观念。
不同的 WordPress 网站类型
WordPress 可以用来架设各式各样的网站，依照不同的网站内容，我们可以将他们分为「静态内容」的网站或是「动态内容」的网站，这两种不同类型的网站，在整体的运作方式上有很大的不同。
主要内容为静态的网站
主要内容为静态的网站其网页文件都较为固定、不常更新，也不会随着访客的不同而有所改变，像是「部落格」或是中小企业的「形象网站」、「摄影作品网站」等。
静态的内容可以透过缓存或是 CDN 的方式有效的提升网页速度效能、减少主机负担。
主要内容为动态的网站
而主要内容为动态的网站，会基于某些特定的因素，例如：访客的地理位置、登入与否和留言互动而改变内容，像是「会员论坛」、「电子商务」、「社群网站」等。
和静态内容不同的是，动态的内容由更改页面内容的脚本生成，并非所有对服务器的请求都可以直接从缓存提供，会需要额外的主机资源和更多的数据库查询。
这解释了为什么把动态内容为主的网络架设在廉价的虚拟主机上，就算使用了缓存插件，对网站速度的提升还是很有限，所以不同类型的 WordPress 网站需要使用不同的网页加速方式。
网页效能最佳化
网页效能最佳化（Web Performance Optimization）指的是提升或是优化在使用者的网页浏览器上，下载和显示网页的速度。
影响网页速度的因素有很多，我会针对不同的因素来分享提升 WordPress 网站速度的 7 个方法：
- 挑选高性能的主机
- 选择最靠近访客的主机
- 减少 DNS Lookup Time
- 选择性能优异的主题
- 使用能够大幅提升网页速度的缓存技术
- 图像最佳化是必须的
- 使用内容传递网络 CDN
挑选高性能的主机
你可能留意到了，上面提到了主机资源，选用高性能的主机是解决网页速度问题的方法之一。
大多数第一次架站的初学者都是选用价格较低的共享虚拟主机，这并没有什么错，这种主机非常适合刚接触 WordPress 的朋友。但是随着你的熟练度增加、架站速度提升或是你的网站渐渐成长、访客流量慢慢升高，廉价的主机会开始不堪使用。
如果网页加载的时间超过 8 到 10 秒，使用者的将会感到烦躁。大约三分之一的网站访客不愿意等待网页加载超过 4 秒钟，几乎一半的访客不会等待超过 6 秒钟。
对于 Google 而言，页面加载时间从 0.4 秒增加到 0.9 秒会使流量和广告收入减少 20％。而对于 Amazon 而言，每 100 毫秒的加载时间增加，销售额就下降 1％。
最新版本的 PHP
PHP 是一种开源的程序语言，WordPress 的核心、主题以及插件都是用 PHP 语言编写而成的。
你的虚拟主机会提供不同版本的 PHP，而较新的 PHP 版本可以提供较佳的效能，所以你应该要选择有提供最新 PHP 版本的虚拟主机。
WordPress 与 PHP 7+ 相容，与 PHP 5 相比，PHP 7+ 的性能有了很好的提升，除非你有特别的需求非使用 PHP 5 不可，否则请切换至 PHP 7+。
如果你的虚拟主机后台是 cPanel，那么你可以在 cPanel 底下切换 PHP 的版本，或是如果你是 SiteGround 主机的用户，你可以使用 SG Optimizer 插件切换。
数据库
最常见的数据库是 MySQL，请确定你选择的主机商有提供最新的版本。另一个选择是 MariaDB 数据库，据说有比较好的性能表现，但是我想差异并不会太大。
更多数据库的效能比较，请参考下列文章
- Benchmarking InnoDB and MyRocks Performance using Sysbench
- MariaDB 10.1 and MySQL 5.7 performance on commodity hardware
- MySQL Performance : 8.0 and UTF8 impact
网页服务器软件
目前常见的网页服务器软件是 Apache、NGINX + Apache 和 LiteSpeed。
Apache 和 NGINX 都是免费开源的软件，所以受到广大的主机供应商所爱戴。虽然 Apache 目前还是拥有最高的市佔率，也有很好的相容性，但是在效能上和其他两者相比就稍微弱势了一点。
如果你是因为 .htaccess 的便利性而使用 Apache，那你应该选择 NGINX + Apache 或是 LiteSpeed。
受到许多人喜爱的 SiteGround 虚拟主机便是採用 NGINX + Apache 的方式。
根据大多数人的测试结果，NGINX 比 Apache 的速度还要快，尤其是在静态的网页内容上，而对动态内容而言两者的差异并不会太多。
- Nginx vs Apache: Which Serves You Best in 2019?
- NGINX vs. Apache (Pro/Con Review, Uses, & Hosting for Each)
- Apache Vs NGINX – Which Is The Best Web Server for You?
LiteSpeed 是另一个选择，它可以使用 .htaccess 并且完全兼容 Apache 成为 Apache 的替代品。它并不像 Apache 或是 NGINX 一样知名，主要的原因是它是由「LiteSpeed Technologies」所开发的付费软件，使用该软件的主机商必须支付一笔授权费用才可以销售。
它的效能媲美 NGINX，有过之而无不及，我个人觉得 LiteSpeed 的最大优点是它提供了一个免费的加速插件「LiteSpeed Cache」，该插件能够大幅的提升 WordPress 网站的效能，在我实际测试之下，其结果完全不会输给着名的 WP Rocket 加速缓存插件（付费）。
你将可以在本文章中「使用缓存」的段落看到「LiteSpeed Cache」更详细的测试。
如果你想使用 LiteSpeed 的虚拟主机，网易资讯会是不错的选择。
HTTP/2
HTTP/2 标準于 2015 年 5 月发表，相较于 HTTP/1.1，HTTP/2 藉由新的改进，可以获得速度上的提升，页面载入速度可以加快 11.81% 到 47.7%。一般常见的主机Endurance International Group (EIG)
选择最靠近访客的主机
跟挑选主机一样，主机的地理位置也是一开始架设网站就必须决定的，选择最靠近你目标受众（Target Audience）的主机位置也许比这篇文章裏头提到的任何网页加速方式都还来的重要。
因为主机位置将会决定「网络延迟」（Network Latency）的表现，减少网络延迟时间同时也代表减少网页加载时间（Page Load Time）和增加网页效能（Web Performance）。
网络延迟
是指数据封包透过网络传输，从一个点到另一个点所需要花费的时间。可以指单向或是双向的延迟，在讨论网页效能的时候通常指的是双向。值得另外一提的是，高速的网络频宽能帮助加速下载网页内容，但是并不会减少网络延迟时间。
我们可以用「Dotcom-Tools」从全球 25 个节点来测试由网易资讯借给我位于台北机房的虚拟主机。
dotcom-tools 网络延迟测试
结果很明显，由于机房在台北，所有位于亚洲的城市都有比较短的网页加载时间，其次是美国再来是欧洲。而且最快（上海 0.77 秒）和最慢（南非的约翰内斯堡 5.2 秒）的速度差异相当大。
当然这跟机房的连外网络配置有关係，不过一般来说选择最靠近目标受众的主机位置绝对是正确的，因为缩短了地理距离通常也代表减少了传输过程中的节点（路由器）数量，就好比转机一定比直飞需要花的时间还要来得多。
除了对访客的网页加载时间有影响之外，网络延迟也会对使用 WordPress 控制台的管理员造成影响，换句话说，撇开网页内容的多寡不谈，如果连 WordPress 控制台使用起来都卡卡的，那就很有可能需要对网络延迟或是 TTFB 效能做优化。TTFB（Time to First Byte）
减少 DNS Lookup Time
「DNS Lookup」时间也是我们在网页效能最佳化当中值得注意的一个环节，它代表的是当浏览器要获取某个网域的资源时向 DNS 请求该网域的 IP 位址所花费的时间。通常由 DNS 主机的性能来决定 Lookup Time 的快慢。
例如从我在浏览器上输入 https://tw.yahoo.com/ 开始，我的浏览器会用「tw.yahoo.com」这个域名透过 DNS （Domain Name System）来找查 Yahoo 台湾在网络上的位置，一直到当它收到 DNS 回传 Yahoo 台湾的 IP 位址时，这段时间就称为「DNS Lookup」。
用 Pingdom 日本服务器测试 Yahoo 台湾的 DNS Lookup Time
要怎么测试 DNS Lookup?
你可以用「SolveDNS」来测试网站的 DNS Lookup 速度，它可以从全球各地测试该网站的 DNS 服务器，这边有一些我测试的结果，给大家参考
SiteGround DNS Speed Test
这个网站所使用的 DNS 服务器是 SiteGround 位于新加坡的主机，所以亚洲城市所花费的 DNS Lookup 时间都相对较短，新加坡有极快的速度（3.66 ms）也许代表该测试主机和 SiteGround 主机是在同一个数据中心。
从这边 DNS Lookup 所发花费的时间也可以看得到地理距离所造成的网络延迟，这也是为什么你应该选择最靠近受众的虚拟主机。
Google DNS Speed Test
Google 的 DNS 主机不意外的快上许多，但是……
同样使用 SiteGround 新加坡虚拟主机架设的网站，改用 Cloudflare 的 DNS 主机后，DNS Lookup 时间大幅减少，有效的达到网页效能最佳化的目的。
我会在这篇文章的后半段分享如何使用 Cloudflare CDN 来减少 DNS Lookup 时间。
你还可以到 DNS 排名网站 DNSPerf 中查看众多 DNS 供应商的排名比较。
DNSPerf DNS 供应商排名
选择性能优异的主题
我在之前的文章中有提到过，好的 WordPress 主题应该要力求简洁并且拥有良好的加载速度，因为主题对 WordPress 网站的速度影响真的很大，原因是
- CSS 的数量和大小，文件越少、越小，读取速度就越快。
- JavaScript 的数量和大小，许多特殊的功能都要仰赖 JavaScript，像是 Slider 或是特殊选单，数量太多或是文件太大都会造成页面读取时间增加。
- 第三方 HTTP 请求的数量，每个连外资源都需要连接到其他服务器，如果有网络延迟或是对方服务器忙碌都会影响网页效能，
例如 Google 字型、Font Awesome 图标等。 - 图片的数量和是否有做最佳化，没有压缩的图片文件通常都会比压缩过后的文件大上好几倍。
- 编写程序的优劣，写得好的 PHP 小巧又快速，不好的文件大又慢，完全取决于开发商的功力。
这边我们先使用网易资讯借给我的主机安装全新的 WordPress 做为基準，并且安装标榜快速、轻量的 Astra 来测试主题对网页效能的影响。
在什么最佳化都没有使用的情况下，空白的 WordPress 在 GTmetrix 的测试中几乎拿到了满分，在没有使用缓存的情况下已经是非常好的表现了。
预设的 Twenty Nineteen 主题 GTmetrix 测试
Astra 在他们的网站上宣称这个主题拥有无与伦比的速度，让我们来测试看看。
Astra 拥有「无与伦比的速度」
刚安装完空白的 Astra 果然最佳化的很好，居然可以比 WordPress 预设的 Twenty Nineteen 主题还要来的小。
只有 9 个请求 非常的简洁
但是为了让测试更接近实际日常使用的情境，我用「Astra Starter Sites」这个插件来添加一个内容比较丰富的 demo，并且选择大家最喜欢的 Elementor 页面编辑器来做搭配。
一键载入 demo 真的很方便
安装完 demo 之后分数从 100% 下降至 93%，页面大小增加了 1 MB 多，HTTP 请求增加到 45 个，导致网页读取时间增加了 1.5 秒左右。
在 45 个 HTTP 请求中，CSS（绿色） 佔了 10 个、字型（红色）佔了 8 个、JavaScript（紫色）则佔了 16 个、其余的则是图片。虽然请求增多了但是文件都不大，显然 Astra 有特别留意网页效能的部分。
而真正比较会影响网页加载时间的第三方 HTTP 请求，也只有 Google 字型而已。
为什么减少第三方 HTTP 请求很重要?
我想在汇入 demo 之后，CSS 和 JavaScript 会大幅增加应该是和 Elementor页面编辑器有很大的关係，不过这些文件都不大，和 Elementor 带给我们的功能性和便利性来说，我觉得是相当值得的，如果你还是有效能上的疑虑，可以考虑使用 Astra 古腾堡区块增强插件的方案。
所以想要知道一个主题会怎么影响你的网页效能只需要使用一个具备瀑布图（Waterfall Chart）的测量工具，并且观察它增加文件的大小和加载时间，以及第三方 HTTP 请求的数量就可以了。如何正确的进行网页效能测试?
选择轻量化且性能优异的主题是避免网页加载速度变慢的第一道关卡，轻量型主题缺乏的功能可以之后再用插件的方式增加，请务必慎选你的主题。
如果你想要知道更多有关选择 WordPress 主题的重要性，请参考「如何选择 WordPress 最佳主题?」文章。
使用能够大幅提升网页速度的缓存技术
使用各种缓存（cache）技术可以大幅提升 WordPress 的网页效能，这是不可或缺的最佳化方式。
什么是缓存?
一般的情况下，当浏览器向网页服务器（虚拟主机）发送请求时，网页服务器将会处理这些请求，并一项一项的从储存文件的硬盘或是数据库中把这些数据回送给浏览器，最后显示到我们面前。
但是如果每一个访客的请求都是这样处理的话，会变得相当没有效率，尤其是有些文件特别庞大或是访客特别多的时候，所以我们会使用缓存来加快这个过程。
我们指示服务器主机将一些每次都会被请求的文件複制并且集中放在某个硬盘位置或是记忆体上，当下一次有相同请求的时候，就直接将已经集中好的文件立刻回传，不用再从数据库中查询。
这样不但能加快服务器的响应时间（减少 TTFB），也能减少服务器的工作量、降低服务器资源的使用。
缓存的类型
能够用来加速网页效能的缓存技术五花八门，不过在这边我把它们区分为
- 服务器端的缓存，在虚拟主机上应用的缓存技术，不同的主机可能会有不同的缓存技术，例如 SiteGround 提供了「静态缓存」、「动态缓存」和「Memcached」，而网易资讯的主机则是提供「LiteSpeed Cache」。
- WordPress 缓存插件，安装在 WordPress 上的插件，像是「WP Rocket」、「W3 Total Cache」和「WP Super Cache」等。
- CDN 缓存，使用 CDN（Content Delivery Network）内容传递网络的缓存。
静态缓存与动态缓存
服务器端的缓存
我们用「LiteSpeed Cache」来测试服务器端的缓存，根据开发商的说明「LiteSpeed Cache」插件是只限于「LiteSpeed」产品的服务器级插件，和一般的 PHP 缓存插件不同。
在同一个安装了 Astra demo 的网站做测试，在还没安装「LiteSpeed Cache」插件之前的 TTFB 是 571.62 ms，内容下载是 88.79 ms。
安装「LiteSpeed Cache」插件之后我没有做设置上的变动，完全维持预设值，结果 TTFB 下降到 156.68 ms，内容下载则缩短到 0.54 ms。
两个测试分别使用不同的 Google Chrome 无痕式视窗，并在测试前手动清除浏览器缓存。
下面是使用 GTmetrix 香港测试节点的结果
我们可以看到由于是同样的香港测试主机，不管在 DNS Lookup、Connecting 或是 SSL 上所花费的时间都是类似的。
但是，Waiting（TTFB）从 427.3 ms 缩短到 46 ms 和 Receiving（内容下载）从 124.7 ms 缩短到 2.6 ms 具有非常戏剧性的差异，这就是缓存的威力。
WordPress 缓存和最佳化插件
我目前使用的缓存插件是 SG Optimizer（SiteGround 主机限定）+ WP Rocket（付费）+ Autoptimize（免费），他们能够互相搭配并且帮我解决彼此的小问题。
利益揭露
我没有收到任何的报酬来撰写此篇文章，不过如果你决定通过点击本文中的 WP Rocket 和 SiteGround链接来购买产品，那么我可能会获得一笔小额佣金，这将不会影响你的任何权益或是购买商品的价格。
本网站没有使用烦人的广告，Affiliate 链接是目前唯一的收入来源，如果你想要支持我继续经营本网站，请使用本站链接购买你需要的产品，我会非常感谢您。
这些缓存插件通常也会包含 CSS、JavaScript、HTML 缩小（minify）或是合併（combine）等最佳化功能，这对于减少 HTTP 请求和加速网页加载速度有帮助，但是这些功能有时候会影响网站的外观（CSS）或是功能（JS），我自己的经验是行动装置的选单失效，所以在使用时请务必彻底检查。
「LiteSpeed Cache」插件当中也有这些功能，我们来试试看效果如何。
先将「进阶功能」打开
然后到「优化」页面把所有选项都打开，之后别忘了要清除所有缓存。
结果显示 HTTP 请求由于文件合併的关係从 45 个下降到了 24 个，GTmetrix 的分数也有些许提升，其余的变化都不大，没有大幅度的提升我想是因为 Astra 原本的 CSS 和 JavaScript 最佳化就做得不错了。
- 打开最佳化之前
- 打开最佳化之后
「LiteSpeed Cache」还有其他针对动态缓存最佳化的设置，但是由于我们的 demo 是属于静态网站我就不在这边做测试了。
图像最佳化是必须的
图片文件包括 png、gif、jpg、jpeg、webp、ico or svg 通常是整个网页文件当中占比最大的，它们的文件大小可以远比 CSS 和 JavaScript 巨大，就算你的服务器和 WordPress 都做好了最佳化，没有压缩的图片还是可以非常容易的增加网页加载的时间。
网页图片的最佳化一点都不困难，这边有几个建议给大家
- 使用在线图片压缩工具，在上传图片到 WordPress 媒体库之前就先压缩好图片。
- 调整图片大小，一般来说，解析度越大的图片文件就会越大，使用符合你的网页解析度的图片尺寸可以帮助你减少图片的文件大小。
- 使用
jpg或是jpeg的图片格式，有损压缩格式可以在可接受的品质範围内大幅度的减少文件大小。 - 使用 WordPress 图片最佳化插件，这些插件能够自动帮助你压缩、最佳化所有上传到 WordPress 的图片。
使用图片最佳化插件
我们继续最佳化 Astra demo 网站，从 GTmetrix 的报告当中可以看到，有部分的图片还有压缩的空间。
我使用 Imagify Image Optimizer 这款图片插件来测试
它可以帮我们一次压缩所有在 WordPress 媒体库的图片
Imagify Image Optimizer 压缩了 57% 的图片大小
压缩完，再使用 GTmetrix 测试，发现图片未最佳化的提示已经解决，分数也来到了接近满分的 98%。
更详细的图片最佳化内容请参照「4 个步骤完成 WordPress 网站图片最佳化」。
使用内容传递网络 CDN
CDN 是 Content Delivery Network 或 Content Distribution Network 的缩写。
这项技术能够将你的网站内容加载到世界各地的数据中心，利用最靠近访客数据中心的缓存来传递文件，可以有效的加快网页文件的传输、减少网络延迟带来的影响，并且透过 CDN 供应商的高速 DNS 主机可以同时减少 DNS Lookup 时间。
CDN 还有一项优点是，在我们把 DNS 指向 CDN 后，它会充当在客户端和虚拟主机之间的中间服务器，拦截所有客户端的请求，这样的好处是它可以提供强大的网页应用程序防火墙（Web application firewall），可以帮助阻止对你网站的恶意攻击。
我们使用免费的 Cloudflare 来测试 CDN 究竟能帮助我们加快多少速度。
启动 Cloudflare CDN
首先到 Cloudflare CDN 网站，注册一个帐号然后加入你的网站域名
Cloudflare 会检查你的域名是否可以使用他们的系统
选择你的方案
确认方案
确认 DNS 设置
Cloudflare 提供的 DNS 资讯
这个时候你需要将你的域名名称服务器（Name Server）更改为 Cloudflare 所提供的，如果你不知道怎么做可以参考这里。
等待使用者将 DNS 指向 Cloudflare
设置好 DNS 后，刷新页面就会看到如下图所示已完成启动的画面。
完成启动
Cloudflare 的控制面板
设置 Cloudflare CDN
启动 Cloudflare 后需要进行一些设置，你可以参考下面「网络攻略」网站的设置并依照自己的需求来做适当的调整。我只列出我有做修改的地方，没有列出来的代表我沿用预设值。
Crypto 页面
如果你有使用 SSL 的话 可以设置为「Full（strict）」
如果有收到「网页内容包含非安全连线」的警告 可以打开这个选项
Speed 页面
在 CF 端缩小 CSS、JS、HTML 文件 如果你已经有使用最佳化插件 这个选项不一定要打开
Caching 页面
使用文件的标头（header）来决定缓存文件的保留时间
Page Rules 页面
这边的设置是最重要的，因为 Cloudflare 预设只会缓存 CSS 和 JS 等文件，但是要真正发挥 Cloudflare 的能力我会将 HTML 也加入缓存。
避免缓存预览页面
避免缓存控制台页面
我设置缓存所有的网页文件并且每 2 个小时分别刷新「Browser Cache」（浏览器 < – > CDN 数据中心）和「Edge Cache」（数据中心 < – > 虚拟主机）的缓存。刷新的时间可以依照你更新网站的需求来做调整。
缓存所有的网站文件
Scrape Shield 页面
防止网站图片被盗连
由于我缓存了所有的网页文件，有时候会不小心将前端网页上方的工具列也缓存起来，导致一般的访客也会看到工具列，在不添加额外程序码的情况下，解决这个问题的方法有两个
- 只使用未登入的浏览器浏览网页前端
- 在 WordPress「使用者」的页面中关闭显示前端工具列
关于「Cache Everything」
用 Cloudflare 的「Cache Everything」来缓存静态的 HTML 是非常激进的做法，虽然可以让你的网站快上一个档次，但是对于动态内容为主的网站却会造成很大的影响和不方便。
就算是静态的网站 ，WordPress 工具列显示在未登入访客的页面和评论区显示管理员登入身分这两个问题也是在缓存了 HTML 之后暂时还没有很好的解决办法。
目前唯一的方式就是加入 Cloudflare 的「商业方案」，该方案提供了「Bypass Cache on Cookie」的 Page Rule 可以有效地用 Cookie 的方式解决上述问题，但是 $200 美金的月费恐怕不是一般玩家或是部落客愿意负担的。（谢谢网友 cras4202tw 提供资讯）
测试 Cloudflare 速度
由于 Cloudflare 不支援子域名所以这边使用「网络攻略」的网站做测试。
这是没有打开 Cloudflare CDN 的数据
这是打开 Cloudflare CDN 的数据
从上面的测试结果可以看到打开 Cloudflare 后整体的读取时间从 781 ms 下降到 235 ms，主要的原因是 DNS Lookup 和 TTFB 都有大幅度的下降。不用太在意下降的分数通常过几天之后会再上升。
你也可以用你的所在位置来测试 Cloudflare 的速度
- 打开 Cloudflare 之前
- 打开 Cloudflare 之后
根据 Cloudflare Support 的这篇文章，你可以使用「https://www.example.com/cdn-cgi/trace」（记得替换网址）搭配「国际机场代码」查看你目前的所在位置是使用哪个地区的 Cloudflare 数据中心。
Cloudflare 包括台北在内 在全球有 175 个数据中心
Cloudflare TTFB 过高?
上面提到了使用「Cache Everything」能够大幅度的加快网页加载速度，但是那必须归功于缓存 HTML 之后所减少的时间。我发现如果我使用 Cloudflare 但是不使用「Cache Everything」的 Page Rule 的话，使用 GTmetrix 香港主机测试，整体的 TTFB 反而升高了。
这边是测试结果
没有将 DNS 指向 Cloudflare（完全不使用 Cloudflare）
将 DNS 指向 Cloudflare 但是不打开连线
使用 Cloudflare 「Standard Cache」Page Rule
使用 Cloudflare 「Cache Everything」Page Rule
把测试数据做成表格后可以清楚看到
- Cloudflare 的 DNS 主机是比 SiteGround 的还要快的
- 如果只用 Cloudflare 预设的缓存方式反而有可能导致网页效能下降
- 「Cache Everything」是提升效能最多的方式
| DNS Lookup | TTFB | Fully Loaded Time | |
| No CF | 70.4 ms | 147.1 ms | 1.7 s |
| CF DNS | 28.9 ms | 145.6 ms | 1.5 s |
| CF Standard | 23.7 ms | 566.5 ms | 2.0 s |
| CF Cache Everything | 20.6 ms | 44.2 ms | 1.1 s |
Cloudflare 官方的说法很像比较偏向于，会导致 TTFB 升高的因素可能有很多，包含了网络延迟、测试地点和他们主机的文件压缩方式等等，但是他们相信整体的网页效能会是增加的。
我个人对于 Cloudflare 的结论是
- 如果 Cloudflare 没能提升网页效能，可以只使用他们的 DNS 主机
- 如果要追求最快效能就使用「Cache Everything」
延伸阅读：How to Use Cloudflare DNS Without CDN or WAF
结论
以上是我加速网站的心得，希望对大家有所帮助。网站加速的方法有很多，我在这边分享的有很多都是针对静态内容的网站，如果你的网站是以动态内容为主，也许从主机端去做加强（升级主机、动态缓存）会更合适。
