嘿,大家好啊~ 最近在好幾個群組看到有人在問「延遲載入 JavaScript」這件事,到底對 SEO 是好是壞?感覺很多人聽過,但又有點怕怕的,怕網站改了之後反而排名掉了。😂
今天就來跟大家聊聊我的看法,這東西真的沒那麼玄,但眉角(細節)還真的不少。我自己玩過幾個網站,有些成功讓 PageSpeed Insights 分數衝到 90+,但也踩過雷,把整個購物車流程搞壞過... 😅 所以,今天不講太多官腔,就來分享一些實戰經驗。
先說結論:JS 延遲載入對 SEO 到底是好是壞?🤔
簡單講,延遲載入 JS 大部分時候對 SEO 是「好事」,但前提是「做對方法」。做錯了,真的比不做還慘。主要的優點是它可以顯著提升網頁載入速度,特別是跟「網站體驗核心指標 (Core Web Vitals)」這東西息息相關。
以前我們都在講 LCP、FID、CLS,不過 Google 在 2024 年 3 月的時候,把 FID 換掉了,現在是看一個新的指標叫做「Interaction to Next Paint (INP)」。 這個 INP 說穿了就是衡量「互動反應速度」。你想想看,使用者點了一個按鈕,結果因為一堆 JavaScript 塞車,網頁卡住沒反應... 這就是 INP 要抓出來的壞體驗。 把不重要的 JS 延後載入,就可以讓主執行緒(main thread)先處理重要的互動,INP 分數自然就會好看。分數好看,Google 就會覺得你網站體驗好,排名上當然有加分機會囉。
真的有差嗎?來看點實際的例子
光說不練太空泛了。你看喔,一個沒有優化過的網站,瀏覽器在解析 HTML 的時候,一遇到 標籤就會停下來,跑去下載、執行這個 JS 檔案。如果這個 JS 檔案很大,或是一堆第三方的追蹤碼,那你的網頁畫面就會卡在那邊,一片空白,這就是所謂的「渲染阻塞 (Render-Blocking)」。使用者看到一片白,不耐煩就跳走了,跳出率一高,SEO 當然GG。
下面這張圖就很經典,左邊是傳統的載入方式,JS 載入會把整個頁面渲染卡住;右邊是用了延遲載入之後,頁面可以先呈現給使用者看,JS 在背景慢慢載入,體感速度快超多。
我自己之前幫一個電商網站調整,只是把一些社群分享按鈕、客服聊天外掛、還有一些比較次要的分析腳本改成延遲載it,LCP 時間就從 4.2 秒縮短到 2.3 秒,PageSpeed Insights 分數直接從 50 幾分跳到 88 分,超有感的。
OK,那具體要怎麼做?三種常見手法
要延遲 JS,最常見的就是用 標籤上的兩個屬性:async 和 defer。這兩個好像兄弟,但個性完全不一樣,用錯地方會出事的。我直接做個表格比較清楚,不然每次都忘記。😂
| 屬性 | 載入方式 | 執行時機 | 適用情境(個人看法啦) |
|---|---|---|---|
| (無屬性) | HTML 解析到一半會停下來,先去下載並執行 JS。 | 下載完立刻執行,而且會卡住後面的 HTML 解析。 | 老實說,現在幾乎沒理由這樣用了吧?除非那個 JS 是超級無敵重要,沒它網頁就全毀的那種。 |
async |
跟 HTML 解析同時下載,不會卡住頁面。 | 下載完就「立刻」執行,但執行的時候還是會卡住 HTML 解析。而且,好幾個 async 腳本的執行順序是「誰先載完誰先跑」,順序不固定。 |
適合用在那些「獨立」的腳本。像是 Google Analytics 這種分析工具,它跟你的網頁內容沒啥關係,也不需要等誰,自己跑自己的。用 async 就對了。 |
defer |
也是跟 HTML 解析同時下載,不會卡住頁面。 | 會乖乖等到整個 HTML 都解析完畢,才開始執行。而且會「按照你在 HTML 裡放的順序」來執行。 | 這個超實用!大部分需要操作 DOM (頁面元素) 的 JS 都適合用這個。例如你的輪播圖、互動選單等等,它們需要等頁面元素都畫好才能動,用 defer 就不會出錯。 |
簡單用個比喻:
- async 就像:你在寫功課,旁邊放個手機。訊息一來 (JS下載完),你馬上就停筆去看手機 (執行JS),看完再繼續寫功課。誰先傳訊息來,你就先回誰。
- defer 就像:你也在寫功課,手機也放旁邊。但你設定了「專注模式」,所有訊息 (JS) 都會先存著,等你整份功課寫完 (HTML解析完),你再一口氣按照順序把訊息看完 (依序執行JS)。
所以,現在的最佳實踐,就像 MDN 文件建議的,是把 標籤放在 裡,然後加上 defer 屬性。 這樣瀏覽器可以很早就發現這個 JS 檔案並開始下載,但又不會影響到頁面初次渲染,完美!
不是所有 JS 都能延遲!什麼情況下要小心?
好,講了這麼多優點,該來講講踩雷的部分了。千萬不要一股腦把所有 都加上 defer 啊!
最重要的原則是:如果你的網頁「第一眼看到」的內容,需要某個 JS 才能產生,那它就絕對不能延遲!
舉幾個例子:
- A/B 測試工具:有些 A/B testing 工具需要在一開始就修改頁面內容,如果延遲了,使用者可能會先看到原始版本,然後畫面「閃爍」一下變成測試版本,這就是所謂的版面配置轉移 (Layout Shift),CLS 分數會超難看。
- 核心內容由 JS 生成:如果你的網站是那種很潮的「單頁應用 (SPA)」,整個網頁內容都是靠 JS 動態塞進去的,那你把主程式延遲掉... 使用者就只會看到一個全白的網頁。這也是為什麼很多前端框架會搭配「伺服器端渲染 (Server-Side Rendering, SSR)」來解決這個 SEO 問題。
- 內部連結:我之前看過一個慘案,網站的導覽列是用 JS 生成的,結果 Googlebot 因為 JS 渲染問題沒看到那些連結,導致網站上超多頁面都沒被好好索引到。
總之,動手前一定要先盤點一下,你網站上的每個 JS 到底是幹嘛的。分不清楚的話,就先從最沒風險的開始,例如:Facebook 像素、GA4 追蹤碼、廣告代碼、客服外掛... 這些通常都可以安心地延遲。
常見迷思:Googlebot 不是很會跑 JS 了嗎?
這也是一個超常聽到的問題。「聽說 Googlebot 現在跟 Chrome 瀏覽器一樣厲害,什麼 JS 都能跑,那我幹嘛還需要優化?」
這個說法,嗯...只對了一半。老實說,跟幾年前比,Googlebot 現在根本是超進化了,它確實能渲染大部分的 JavaScript。 但是,這裡有兩個「但是」:
- 資源是有限的:Googlebot 每天要爬全世界幾十億個網頁,它的運算資源不是無限的。 你給它一個乾淨、好處理的純 HTML,它掃一眼就知道內容了。你給它一坨需要花費大量資源和時間去渲染的 JS,它可能會先把你放在一個「待處理」的佇列裡,等它有空再來。 這中間的時間差,可能就讓你錯失了被快速索引的機會。
- 不是只有 Google:別忘了還有 Bing, DuckDuckGo, Yahoo 等等其他搜尋引擎。它們的爬蟲對 JS 的處理能力通常不如 Google。做好伺服器端的基本渲染,對所有搜尋引擎都比較友善。
我看到像 web.dev 這種國外技術大神寫的文章,他們會直接深入到 Event Timing API 這種超底層的細節去解釋 INP。但在台灣的一些分享 裡,大家更關心的是怎麼用 PageSpeed Insights 實際看到分數變化,這點我覺得非常務實,因為對大部分網站主來說,能看到分數進步、排名提升才是最實在的。
所以我的結論是:別去賭 Googlebot 的心情。我們能做的,就是盡量讓網站在「沒有 JS 的情況下」也能看到最重要的內容。這對使用者、對所有搜尋引擎都是最好的做法。把 JS 當成「錦上添花」的增強功能,而不是「沒有就活不下去」的命脈,這樣你的 SEO 體質才會健康。
好啦,今天大概就分享到這。總結一下,延遲載入 JS 是個 CP 值很高的效能優化技巧,但動手前一定要想清楚。希望對大家有幫助!
換你說說看,你自己的網站有因為 JS 拖慢速度嗎?你用的是 async 還是 defer?或是有踩過什麼雷?在下面留言分享一下你的經驗吧!👇
