标签归档:WordPress

为 WordPress 加入 Server Timing 判断不同行为性能差异

自打上次为我的博客加入了 Redis 缓存后,博客站点访问速度明显变快,几乎可以达到秒开的效果。剩下的需要在网络层面进行进一步的优化。

不过,我还在思考如何才能更好的优化我的 WordPress 性能。很显然,我需要一个指标来帮助我做决策。这让我想到了一个东西 —— HTTP 标准中的 Server-Timing Header。

Server-Timing 标头传达在一个给定请求-响应周期中的一个或多个参数和描述。它用于在用户浏览器的开发工具或 PerformanceServerTiming (en-US) 接口中显示任何后端服务器定时参数(例如,数据库读/写、CPU 时间、文件系统访问等)。

来自 https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Headers/Server-Timing

Server Timing 可以帮助我们记录服务端到底在哪些步骤中消耗了哪些时间,可以方便我进行性能的查询。

使用 WP Server Timing 添加 Server-Timing 头

我在 WordPress 的 Plugin Directory 目录进行了搜索,并没有找到支持这个功能的插件,不过我在 Github 上找到了这个插件 —— https://github.com/ocReaper/wp-server-timing

有了这个插件,我就可以无需自己手动添加相应的能力。

使用插件也非常简单,在页面上下载压缩包,并在 WordPress 后台安装并启用这个插件。

安装后的效果

安装完成后,你接下来要做的就是重新在浏览器中打开你的网站,并按下 F12 打开开发者工具,选择文档 Tab(英文是 Document),刷新当前页面,就可以看到列表中出现了一个你博客地址对应的文档,点击文档,并在弹出的窗口中切换到「时间」Tab,就可以在下方看到服务器计时了。

示意图

按照上图的结果,可以看到,我的 WordPress 耗时最长的是 Template Processing ,我需要针对这个属性进行定向优化。

辅助理解资料

以下是 WordPress 的加载顺序图,你可以对比着参考

WordPres 的加载顺序图,来源:https://www.rarst.net/wordpress/wordpress-core-load/

black flat screen tv turned on near green plant

为什么你应该自建图床?

我最近对博客做了个整体架构优化(或者其实说是重建了一次),在重建完成后,为了确保我的重建是成功的,我安装了 Broken Link Checker 来进行网站链接检查。经过插件的检查后,发现了不少我在迁移的时候出现问题的点。不过,在这个过程中,也注意到了我过去自己的问题。

首当其冲的是我在早期大量的应用了来自微博的图床,但随着后续微博图床的失效,我无法再使用这些图片,在读者访问的时候,就会相应的出现错误。我不得不针对这些图片一个个手动处理。

好在是后来 iPic 的出现,我得以从新浪图床迁移到如今自建的又拍云图床中。

而随着 WordPress 插件生态的丰富,如今我在 WordPress 上写作插图更加的方便。

自建图床和自建博客、自建网站等等的原因几乎是一样的 —— 只有你自己维护的,才是真正属于你的,别人维护的,都有可能在某个时刻不让你使用。那个时候,你的成本会骤增。比如现在的我,就在苦逼的一个个的修改图片的地址。

WordPress 的静态化缓存和动态化缓存应该如何选择?

在我发出了 为 WordPress 加入 Redis 缓存提升访问性能 的文章后,有不少朋友给了建议,主要有以下几个:

  1. 可以在前面套一层 CDN ,使用 CDN 来完成缓存。
  2. 可以配置 Nginx 缓存。
  3. 可以给文章生成静态的。

在我看来,这些都是很好的建议,对于很多新人的博客主而言,都是不错的选择。不过就我自己的需求而言,这个并不是好的选择。

从网站性能的提升而言,他们所提供的建议确实是不错的,通过对网站进行静态化处理,从而实现访问的提速,用户直接访问静态的缓存是不错的选择。

不过,对于我来说,倒也不仅仅是给读者一个更加舒服的阅读体验,对于我自己而言,更加舒适的写作体验也是极为重要的。

引入了 Redis 作为缓存后,所有的 MySQL 查询会进行一定的缓存,从而让网站的整体使用体验变得更好,对于我来说,是一个更好的选择。

为 WordPress 加入 Redis 缓存优化访问性能

在之前的文章我是如何优化博客的本站在用的一些WordPress插件中我提到,我是使用了 WP-Optimize这个插件来进行博客优化的。

WP Optimize

WP-Optimize 为用户提供了开箱即用的缓存方式,可以将你的 WordPress 文章加入文件缓存,从而减少在 MySQL 中查询的次数。

不过,文件缓存的问题是性能受限于你所使用的磁盘,而我使用的是阿里云的标准云磁盘,性能一般,所以访问速度并不能算快。

过去在我还愿意折腾 WordPress 的时候,我是会在 WordPress 上加入一些别的缓存的,比如 Redis、Memcached。不过,随着时间的流逝,我折腾的意愿变得越来越弱,就远离了这些。

直到最近刚好有空,于是开始研究起了 Redis 缓存。

其实在古早时代(比如我刚开始折腾个人博客的时候,2012年),WordPress 的 Redis 功能并不是特别好用,需要自己手动下载 object-cache.php 放在对应目录中,然后修改配置文件手动来开启,甚至还需要替换掉 index.php 文件来让请求通过缓存进行。

这次的折腾,让我感受到,时代在进步,配置缓存也变得简单了许多。

Requirements

在这篇博客中我并不打算介绍 Redis Server 的安装和调试过程,你可以在搜索引擎中找到各种各样的教程引导你如何完成安装的过程,因此,请自行完成 Redis Server 的安装,后续的各项操作会默认你已经完成了 Redis Server 的安装调试。

需要注意的是,如果你不打算修改配置文件,则需要在安装 Redis 之后,设置为空密码。而空密码是不安全的,建议你通过 iptables、安全组策略等方式,屏蔽掉 6379 端口的外部请求,只允许本地请求。

安装 Redis 缓存

我这次安装 Redis 缓存选择了 Redis Object Cache 这个插件。

Redis Object Cache

和你在别的网站上看到的教程相比,这个插件提供了一个可视化的查看和管理的方式,对于懒得手动操作和编辑代码的人来说,更加友好。

安装插件后,启用插件,你可以在设置中的「Redis」设置页面找到如下的界面:

设置页面

点击 Enable Object Cache,就会开启 Redis 的 Object Cache 。

如果你已经在之前配置好了 Redis Server,则会直接看到如下左图的界面。但如果你的 Redis Server 还没有配置或配置了密码,就会显示如下右图的界面,就需要你检查你的 Redis Server 是否配置成功。

配置成功的情况
配置失败的情况

当你看到如上左图的界面后,就说明你已经开启了 Redis 的 Object Cache 了,后续涉及到文章内容、菜单等各项基本配置的查询时,会优先使用 Redis 的缓存,而不是查询 MySQL,从而降低了 MySQL 的查询压力,提升了查询的诉求。

至此,你的 Redis 就配置好了,可以打开你的网站首页,享受飞一样的速度。

开启前的 TTFB 为 2.29 秒
开启后的 TTFB 为 673.49 毫秒

FAQ

1. 如何使用非本地 Redis Server 或如何使用带密码鉴权的 Redis Server?

如果你需要使用非本地的 Redis Server(比如云 Redis),那么你需要在你的 wp-config.php 中加入如下代码来进行配置。

define( 'WP_REDIS_HOST', '127.0.0.1' );
define( 'WP_REDIS_PORT', 6379 );
// define( 'WP_REDIS_PASSWORD', 'secret' );
define( 'WP_REDIS_TIMEOUT', 1 );

2. 如果我一个服务器上有多个 Redis ,如何配置使数据不会混淆呢?

有两种方式,

第一种方式是可以给你的不同站点配置不同的 Redis DB,只需要在你的 wp-config.php 文件中加入如下的配置,即可实现不同的站点使用不同的 Redis 数据库,你可以从 0 开始,向上递增设定不同的 Redis 数据库。

define( 'WP_REDIS_DATABASE', 0 );

第二种方式是你无法控制 Redis,必须使用同一个数据库,那么你可以通过给其添加不同的 salt 来实现即使使用同一个数据库,数据也不会产生混淆。

define('WP_CACHE_KEY_SALT', 'www_ixiqin_com_');

3. Metrics 怎么理解?

在 Redis 设置页面,你可以看到另外有一个 Metrics Tab,这个 Tab 你可以看到你的插件的工作情况,方便你随时进行查询 & Debug。

第一个 Time 是指 Redis Object Cache 和 Redis 沟通,获取数据所需的时间,可以看到,我这里的查询时间大概是在 12ms,耗时不多。需要注意,你第一次看可能会注意到,这里有一个 Object Cache Pro ,灰色的 Object Cache Pro 其实是官方在推广其自家的付费插件,付费插件 $99/月,可以提供更好的 Redis 查询性能。

第二个 Bytes 则是 Redis Object Cache 从 Redis 获取到数据的大小,当有人访问你的文章的时候,这个数据就会出现一个增长,访问结束后就会消失。

第三个 Ratio 则是缓存的命中率,基本上保持在 99% + ,说明缓存的命中率还不错。

最后一个 Calls 则是调用次数,免费版不会批量获取数据,因此,调用次数会很高,而在付费版,会一次性拿多个数据,从而获得更少的查询次数。不过我目前对于这个速度已经很满意了,就不再购买付费的版本了。

延展阅读

WordPress 5.9 + 2022 主题,如何修改主题代码?

如果你使用了最新的 WordPress 5.9 以及其自带的 WordPress 2022 主题,你会发现有个问题:

修改主题代码去哪了?

虽然提供的编辑器可以满足绝大多数需求,但对于一些特定场景下的开发需求(比如在 functions.php 中加入特定的逻辑,依然是需要修改代码的。

在当前的 5.9 版本中,主题的代码编辑器和插件的代码编辑器入口被移动到了「工具」当中,你需要到「工具」当中寻找对应的功能。

对 WordPress 2012 主题的一些改动

在上一篇文章当中,我介绍了我为什么要迁移到 2012 这个主题,在这篇文章中,我将会向你介绍一下我对其做的一些修改。

加入广告信息

之前我接受了来自芦笋的广告赞助,作为权益,我答应为芦笋提供相应的广告展出,因此,我需要通过一些代码的修改,来实现对这部分内容的修改。

具体的修改方式是修改了 WordPress 2012 主题中的 content.php 这个文件,在合适的位置加入如下的代码

<!-- ads code start -->
<?php if(is_single()){ ?>
<a target="_blank" href="https://lusun.com/invite/20143" style="padding-bottom:10px"><img src="http://ixiqin.test/wp-content/uploads/2022/01/800498db4ecc3ecade82c7dfb0aaded5.png" class="wp-block-image" alt="白宦成邀请你注册芦笋,并赠送你 30 天高级版特权" style="max-width:100%"></img></a>
<?php }?>
<!-- ads code end -->

文章页面的广告便是如此加上去的。

而侧边栏中的广告代码,则是通过 WordPress 自带的「小工具」功能来实现的,插入图片,并加入对应的链接即可。

首页显示摘要,而非全文

从阅读体验上来讲,在列表页面能看完所有内容自然是不错的,不过因为我的文章比较喜欢插入代码和图片,如果直接在文章页面展示所有内容,会导致页面看起来非常的混乱,所以我修改了对应的代码,将其调整为在首页展示摘要,而在内容详情页展示全文。

这里 2012 主题并未加入相对应的功能的开关,因此需要自行代码实现相应的功能。

原代码如下:

<?php if ( is_search() ) : // Only display excerpts for search. ?>
<div class="entry-summary">
	<?php the_excerpt(); ?>
</div><!-- .entry-summary -->
<?php else : ?>
<div class="entry-content">
	<?php the_content( __( 'Continue reading <span class="meta-nav">&rarr;</span>', 'twentytwelve' ) ); ?>
	<?php
	wp_link_pages(
		array(
			'before' => '<div class="page-links">' . __( 'Pages:', 'twentytwelve' ),
			'after'  => '</div>',
		)
	);
	?>
</div><!-- .entry-content -->
<?php endif; ?>

新的代码如下:

<?php if (is_search()): // Only display excerpts for search.
?>
        <div class="entry-summary">
            <?php the_excerpt(); ?>
        </div><!-- .entry-summary -->
        <?php
else: ?>
        <?php if (is_single()): ?>
    <div class="entry-content">
            <?php the_content(__('Continue reading <span class="meta-nav">&rarr;</span>', 'twentytwelve')); ?>
            <?php
        wp_link_pages(array('before' => '<div class="page-links">' . __('Pages:', 'twentytwelve'), 'after' => '</div>',));
?>
        </div><!-- .entry-content -->
<?php
    else: ?>
<div class="entry-summary">
            <?php the_excerpt(); ?>
        </div><!-- .entry-summary -->
<?php
    endif; // is_single()
?>
        <?php
endif; ?>

通过上述的代码实现,来控制了在首页 & 列表页面只显示摘要,而在具体的内容页面,展示全部内容。

摘要显示超过默认长度的数量

WordPress 默认的摘要长度是 55 ,而我写的内容如果只是默认的 55 ,可能看起来会比较奇怪,所以我会通过代码,将其调整为 100

function custom_excerpt_length( $length ) {
    return 100;
}
add_filter( 'excerpt_length', 'custom_excerpt_length', 999 );

加入面包屑展示

加入面包屑展示,有助于读者更好的在站内进行不同的导航,因此,借助于 All in One SEO 插件自带的面包屑功能,加入了面包屑。

<div id="aioseo_breadcrumbs" style="padding: 10px 0px;">
<?php if( function_exists( 'aioseo_breadcrumbs' ) ) aioseo_breadcrumbs(); ?>
</div>

为什么放弃 WordPress 的 2022 主题

近几年,我基本上是保持着跟随官方的步伐,使用当年的默认主题,比如 2021 出了,我就用 2021 主题,当 2022 出了,我就用了 2022 主题。

前几天我也还在使用 WordPress 2022 主题,今天恰逢得空,我就还是把主题切换回了更加古老的 2012 主题。

聊聊为什么吧。

为什么要放弃 WordPress 2022 主题?

实际上,从 2020 开始,你就会发现,WordPress 的主题设计就会逐渐的倾向于「个人主义」的主题,增加了大量的展示自己的主题,包括我自己,也在过去的一年里,大量的使用了 2021 这个主题。

2021 年我的博客的样子

但是,当我在 Beta 版试用 WordPress 的 2022 主题时,我发现这样的情况愈发的明显,甚至对于我来说,超出了我的能力范围。

2022 主题相比于 2021 主题,提供了更多的编辑的能力,用户可以用一个可视化的编辑界面,去修改你的网站的任何一个位置。从一个普通的用户者的角度来看,它赋予了用户更多的能力,可以去实现任何一个想要的效果。但从一个专业的开发者的角度来看,他从某种程度上束缚住了我的手脚,我再也不能对 WordPress 主题做任何修改(你只会获得一个「编辑器」)。此外,对于一个「不那么有审美」的人(比如我),可拖拽意味着你会拖拽出一个完全不合理的界面。

So,我放弃了2022 主题

为什么是 2012 ?

2012 是我最近在看 HappyXiao 的博客 注意到的,我发现 2012 这个 10年前的主题在处理不同设备之间的响应式、清爽感等方面做的非常好,作为一个阅读者,我的体验极佳。

而我同样希望给我的读者提供更多更加友好的阅读体验,于是,我就选择了 2012 来作为当下我的主题。

当然,这个主题并不一定完全符合我的要求,因此,我也做了一些基本的改进,这些改进,后续我会单独写一篇文章来说明。

flat screen monitor

推荐两款 WordPress 插件

我的博客写了很久,但是一直以来,有两个问题是我没有处理太好的,也正是因为没有处理好,过去的我的博客往往比较朴素。但是最近我发现了两个插件,可以完美解决我的问题,也分享给你。

对象存储对接: USS Upyun

USS Upyun 是来自于沈唁开发的又拍云存储插件,安装使用后,你的附件会在通过 WordPress 插件中上传后,自动上传至又拍云。

由于我一直以来都是使用又拍云作为图床,并配合我电脑上的 iPic 来使用,所以,配合他的插件可以让我免于使用 iPic 来上传文件,直接通过 WordPress 上传即可,大大提升了我的写作舒适度。

此外,如果你使用的其他家的云存储,也没有问题,这个作者也开发了其他几家常见云存储的插件,你可以直接使用他开发的插件来完成功能,因为是同一个人开发的,所以功能方面不会有太大的差距。

插图获取:Instant Images

Instant Image 是用来找插图的,当你在写文章的时候需要一张插图,就可以在选择图片的时候,直接从 Pixabay 或 Unsplash 上搜索并选择合适的图片,选中后,就会自动将图片下载到你本地让你使用(配合上面的又拍云插件,可以直接将图片存在对象存储上)。

Surface laptop on a round straw foot rest in an office with Christmas decorations in the background
随手选择了一张图

插入的界面也是融合在媒体库当中的,非常符合 WordPress 的使用体验。

总结

有了这两个插件,我以后大概会在写文章的时候大量配图,因为插图不再是我的痛点,那就可以多插一些符合场景的图片,来降低读者阅读文章的压力。

如何 Debug WordPress 的 Pingback 功能

前两天,朱峰老师在写博客的时候,引用了我的文章,发现我的博客并没有开通 Pingback。提醒我开通以后,发现依然没有效果。

于是进入了 Debug 模式。

Pingback 如何 Debug

PingBack 是基于 XML 构建的协议,因此,如果你需要调试的话,需要自己发送 XML 请求,以通知 WordPress 进行 Pingback 记录。

你需要构建一个 XML 文件,其中的内容如下

<?xml version="1.0" encoding="iso-8859-1"?>
<methodCall>
<methodName>pingback.ping</methodName>
<params>
 <param>
  <value>
   <!-- source,发起请求的文章,即要引用别人文章的文章 -->
   <string>https://blog.andie.im/blog-is-back/</string>
  </value>
 </param>
 <param>
  <value>
   <!-- target,被引用的文章,即他人的文章 -->
   <string>https://www.ixiqin.com/2021/10/more-and-more-good-a-lightweight-application-server/</string>
  </value>
 </param>
</params>
</methodCall>

将上述的 URL 修改为你自己的以后,就可以在命令行中对 WordPress 发起请求,以实现 PingBack 功能。

curl -X POST -d @pingback.xml https://domain/xmlrpc.php #将 Domain 替换为你自己的博客地址

发送成功后,你会看到这样的一个提示,就说明你的 Pingback 发起成功了,接下来要做的,就是在 WordPress 的评论页面去给 Pingback 进行放行了。

朱峰老师的文章

Reference

https://wordpress.org/support/topic/inbound-pingbacks-not-working/

我是如何优化博客的

由于主域名的备案掉了,所以我不得已,将站点从国内的 VPS 上迁移到了国外的 VPS 上,但是,站点迁移,速度不能下降。

事实上,经过一段优化,目前这个站点的速度着实不错,对我自己来说,基本上是秒开,而在测试网站上,速度也是杠杠的。

除了极个别监测点的速度实在是太慢,绝大多数的监测点都在 1s 内打开。

https://www.boce.com/http/www.ixiqin.com

能达到这样的速度,背后意味着很多种优化。我们一一来看。

原理

如果要对网站速度进行优化,就需要理解,在我们从浏览器中输入一个网址,到我们最终网页加载完成,都经历了哪些流程。

  1. 域名解析:我们输入在浏览器中的域名,是无法直接抵达目标主机的。因此,我们需要访问 DNS 服务,将域名转换为 IP 地址,从而才能抵达目标主机。
  2. 内容下载:当我们的请求抵达目标主机后,浏览器会下载服务器的返回。
  3. 本地渲染:浏览器将服务器的返回下载到本地后,会在浏览器的引擎中进行渲染。

当然, 在实际执行过程中,我们需要考虑的不仅仅是这三个点,不过就这三个点而言,也足够我们进行优化了,更加细致的,可以在后续遇见新的性能瓶颈后,进行优化。

分析

在理解了原理后,我们可以一一来分析

域名解析

对细节进行分析以后,可以看到,我的站点在解析时间上的耗时是普遍比较长的,大多是在 0.3 秒,这是一个优化点。

DNS 的优化总的来说,乏善可陈。因为系统底层对于 DNS 的机制只有两处,分别是

  1. Hosts
  2. DNS 解析

如果想要优化,那你就需要降低你的 DNS 解析时间。Hosts 显然是不靠谱的,你不可能让你的用户都去修改了 Hosts 后再使用。

而 DNS 解析,目前我使用的是免费的阿里云 DNS ,这里的优化其实依赖的是阿里云的 DNS 优化(付费版可能会好一点,不过我暂时不考虑上付费 DNS)。

内容下载

内容下载可以分为两个部分

  1. 内容生成:服务器计算得出结果。
  2. 内容下载:浏览器将服务器计算的结果下载到本地。

内容生成

在内容下载整个流程中,WordPress 主要的问题往往是卡在内容生成方面。

由于 WordPress 的功能强大,且在优化方面做的一般,因此,当我们的 WordPress 的内容足够多的时候, 数据库的查询就会开始变慢。

在这个时候,我们可以选择使用一些工具来加速站点的优化。一般的来说,会考虑使用 Key Value 数据库来替代直接使用 MySQL 进行查询。

这方面可选的包括

  • Memcached
  • Redis
  • 文件缓存

我因为懒得配置 MemeCached 和 Redis ,因此使用的是文件缓存,这里我用的是 WordPress 的 WP-Optimize 插件

可以看到,我的站点的缓存数量达到了 2716,缓存的大小达到了 45.6MB。也正是这些缓存,让我的站点在内容计算方面不需要耗费太多的时间,优化站点的体验。

当然,如果你追求更好的速度,可以考虑上 Redis 或 Memcache ,这些内容互联网上有非常多的教程,我就不再一一介绍。

内容下载

说完了内容生成,来谈一谈内容下载。

在内容下载方面,其实主要受限于你所使用的虚拟主机、VPS、云服务器性能。

在我们购买虚拟主机、云服务器的时候,我们往往会要购买相应的带宽。你购买的带宽越大,你的站点在下载时能够使用的带宽就会越大,相应的,下载的速度也就会越大。

在这方面,如果你的站点有备案,可以考虑购买一些国内的 CDN 服务,使用 CDN 来完成站点的加速,让你的站点加载速度可以变得更快一些。我的域名没有备案,所以没办法使用国内的 CDN,比较遗憾。

本地渲染

内容下载到本地,就会需要进行内容的渲染,而渲染的过程则和你的站点设计、标签数量、复杂度等都有关系。

你会发现,我现在站点使用的大多数是 WordPress 官方的主题,官方的主题的好处在于其站点设计简洁大方,同时页面的标签结构会比较合理,可以确保不会卡在一些奇奇怪怪得地方。

类似的,这也是为什么我很讨厌一些站点生成器(可视化拖拽工具),他们的确可以很方便的生成,但相应的,也会带来大量的冗余标签,让我觉得十分不优雅(当然,背后的人效计算又是另外一回事了)。

总结

对于你自己的博客来说,你也可以参照我的优化方法,来找到自己的问题点,并进行相应的优化,当然,如果你有什么想要讨论的,也欢迎你在下方的留言区和我一起分享。


Append:

我将 DNS 从阿里云免费 DNS 切换到 DNSPod 的个人专业版的以后,我的 DNS 解析时间获得大幅度下降,解析速度降为 0.13s 以内。如果你的解析速度也很高,值得试试。