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月份拭目以待吧。沒有這個技術能力的獨立站長,也別慌,你不會的其它站長大概率也不會,保持網站內容質量不降級,你的排名大概率也不會降級,性能再重要,也不能比內容本身重要。

發現錯別字麻煩選中按Ctrl+Enter

類似帖子

1 Comment
內聯反饋
查看所有評論
2 月前

看到這篇文章,打開Google Search Console,發現有近500個網址出現LCP問題:超過4秒,非常蛋疼,可能還是由於使用的是阿里雲國內的服務器有關吧。