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月份拭目以待吧。没有这个技术能力的独立站长,也别慌,你不会的其它站长大概率也不会,保持网站内容质量不降级,你的排名大概率也不会降级,性能再重要,也不能比内容本身重要。

类似文章

订阅评论
提醒

1 Comment
内联反馈
查看所有评论
3 年 前

看到这篇文章,打开Google Search Console,发现有近500个网址出现LCP问题:超过4秒,非常蛋疼,可能还是由于使用的是阿里云国内的服务器有关吧。