一段优化网站Core Vital性能的历程

Google排名算法5月就要纳入排名计算：参考阅读一，参考阅读二。

有几个长期依赖Google自然排名获取流量的网站客户都很紧张，这阵子特别忙活。其中一个客户的海外小网店手持设备9屏首页PageSpeed分数一直稳定在85分以上，其实蛮好了，还是一连几天在GMail上催着想办法，跑了几次测试，LCP基本在2.8上下，把客户劝回去了，事实是真没有太多太急的优化需要做的。

也有两个网站的自然流量一直不错，尽管从来没有管过Google的性能评分分数的，其中一个mobile端50分都没跑到过，但头部一组关键词一直都在前三，客户也从来没抱怨过。

但这次Core Vital的消息一出来，这个客户和我都不太淡定，这段时间零零碎碎地做了很多很多旧站细部优化的工作，还没有最终完工，但大概可以分享一下。

懒人包：WP-Rocket / NitroPack/ Perfmatters

网站缓存及杂七杂八的性能优化一直靠WP-Rocket，这个东西不是没有缺点（在JS Minification的配置上吃过一次大亏，cache/min/占满硬盘直接导致MySQL宕机），但兼容性很强，用着很省心，项目已经续费了几年。

社区里有不少人力推NitroPack，买下来试用了，半个月没发现比WP-Rocket快在哪儿，退款。

渐渐意识到网站的根本问题还是在HTML/CSS/JS的绝对尺寸太大，有点病急乱投医似的买了一直有所耳闻的Asset CleanUp Pro操作了一通，停了几个CSS/JS文件，很开心，但PageSpeed Insight的分数没有本质变化，而且越看越觉得强行卸载wp-content甚至wp-includes里的前端文件似乎不是长期稳妥之计，一不小心会把自己害惨。

饶了着实好大一圈，发现一站式的懒人包优化法似乎帮助有限，不如先改进服务器提升基础性能（当前用的美国名声还不错的某虚拟主机，硬件参数不透明，但某些时候动态请求过超1.5s甚至过2s，其实一直都想升，只是一直都不是那么重要）。

说服客户上Kinsta（基于GCP），未接Cloudflare，关了WP-Rocket，开了Perfmatters（自带CSS/JS屏蔽功能，遂关了Asset CleanUp Pro）测下来竟然发现动态请求部分基本不上1s了，很开心（虽然接入CF后可能会是另外一个故事），也为下面的手动调优做好了准备。

关/删插件，手动代码优化

一个插件可以让前台慢，可以让后台慢，也可以让前后台都慢下来。主题本身和小功能插件还好，但Gutenberg、Elementor等主流工具链产生的前端负担可以是很吓人的。

后台的瓶颈调试用的APM开路，配合Query Monitor，揪出来主要影响后淘汰的HTTP CALL，一个插件的某Logging配置忘关，还有自己写的PHP Snippet影响到前台Post长列表页的响应速度，优化以后省下大概200ms。

前台的HTML节点接近5000，每次跑PageSpeed Insight都是红的，分享、个性化评论、embeds、非必要的widget能关的都关了，涉及到七八个插件，涉及到Gutenberg低效组件的文章内容块，客户花了时间用类似但更简洁的组件代替，其它关不了插件的做了几个filter hook把能精简的HTML代码都精简了，HTML节点数下到2000以下，看到这项不红了，决定不再继续钻牛角尖。

到这里网站FID2.7（测试还很有限），FID 120ms，CLS 0.7s，目前判断是拜客户往页面堆的动效所赐，这个层次的问题，大概率还得让Elementor的技术来解决，周期难以评估。这是一个登录页相对比较重的电商站，Elementor对于远期运营的价值仍然大大超越它产生的性能损耗。同样的问题正活跃的Gutenberg生态同等严重的存在，我对开源社区来解决性能问题的速度持悲观态度，大概率iElementor解决得慢。

在Chrome DevTool Coverage仍有明显的98%+的unused code，在WordPress的场景下，我个人认为采取任何“聪明”的手段都是不太明智的，客户也不打算再支付几十个小时的成本来怼代码，于是把注意力放到了优化外部条件上，CDN很显然是绕不过去的。

CloudFlare Argo + Page Rules

网上有资料说Argo能提供20-30%的提升，我们目前还没有足够测试数据来支撑，在GCP性能的基础上，开CF网站动态请求没变慢，我已经很满足了。

笨拙的Page Rules其实比想象的有用，只要理清楚页面的“实际”更新需求，以此设置edge cache和browser cache，能消化掉几乎所有产品目录相关页面，我们的网站兼有多货币与多语言，设置复杂一些，但越是复杂的缓存场景设置好了收益越大。

开Rocket Loader的次数与关掉它的次数基本是相等的，这个bug一样的存在，对于网页里可能有50处以上script引用的电商页似乎还只是个bug，开了就出bug。

优化内容与页面设计

如果一个网页的内容与设计坐下来用了1MB+HTML、3000+node，任何不动内容与设计本身的外部的优化手段可能都是不够的，要获得满意的结果，得重新审视网页内容编排和设计。

这是一个没有标准答案的问题，最终的决定权往往在客户那边的一整个部门的认知，要拿“我们必须把FID从黄绿变绿”为理由说服以“更长时间停留、滚动、加购、下单”以及“本周上Promotion活动数量以及广告ROI”为目标的运营删掉或简化几个内容板块，将是一个艰难的任务。

作为技术也可以建议甲方开出80小时的预算来做全站AJAX化，但即使排除钱的因素，单纯从完整的技术场景考虑这也未必是个好主意。

但要为复杂一点的WP/WC网站做Core Vital这样钻牛角尖的优化，从网站内容与设计精简的角度出发，是不应该忽略的。

我衷心希望这次“明确涉及”Core Vital的排名算法更新，不是一次乌龙，5月份拭目以待吧。没有这个技术能力的独立站长，也别慌，你不会的其它站长大概率也不会，保持网站内容质量不降级，你的排名大概率也不会降级，性能再重要，也不能比内容本身重要。