DNS查詢瓶頸？首次白屏與預取解方
「網站第一次打開，怎麼……就是慢得讓人有點煩躁？」唉，有時候我真的懷疑是不是自己的網路爛掉了。其實，大概很多人都卡在一個叫 DNS 查詢的環節啦，欸，就是那個網域名稱系統查詢。你不覺得，每次遇到那種塞滿七八種外部服務、還有一堆第三方腳本的頁面，等待的時間就會莫名拉長？然後螢幕白著、完全沒內容跳出來——看著秒數一直過去，我偶爾也忍不住懷疑人生。
嗯，資訊圈的人觀察到，有個東西叫 DNS 預先解析（或有人講 DNS Prefetch），這玩意兒據說能提早把那些惱人的查詢搞定。啊對，好像是在 HTML 的 head 區塊裡偷偷加幾行，把門牌號碼先查好一樣。咦，我剛才差點忘記自己要講什麼……總之，新來的用戶不用再呆等伺服器反應，那段啟動時光大致上就縮短了。但老實說，也不是每次都會明顯變快啦；尤其是那種要串接很多資源、廣告追蹤碼或外部字型的情境下，這方法確實挺有效果。
我記得有開發者分享過，只要在
嗯，資訊圈的人觀察到，有個東西叫 DNS 預先解析（或有人講 DNS Prefetch），這玩意兒據說能提早把那些惱人的查詢搞定。啊對，好像是在 HTML 的 head 區塊裡偷偷加幾行，把門牌號碼先查好一樣。咦，我剛才差點忘記自己要講什麼……總之，新來的用戶不用再呆等伺服器反應，那段啟動時光大致上就縮短了。但老實說，也不是每次都會明顯變快啦；尤其是那種要串接很多資源、廣告追蹤碼或外部字型的情境下，這方法確實挺有效果。
我記得有開發者分享過，只要在
從Chrome到Edge：Resource Hints的進化路線
嗯，現在的狀況有點好笑，其實 Chrome 官方文件都直接擺例子出來，手把手教你 Resource Hints 要怎麼下才不會踩雷。前端圈內最近幾年才開始有人真的熱烈討論這些事吧？我記得以前大家還在拼命壓縮圖片、快取塞到爆炸——唉，那時候感覺世界單純多了。可是說真的，這種老派招數現在用起來就有點…呃，像是硬要用傳統信箱寄 email 吧。話說回來，我剛剛突然想到家裡那台超舊的電腦，不知道還能不能開機？啊對，主題是瀏覽器更新。
新版 Edge 跟 Firefox 其實也沒什麼張揚，就默默把 dns-prefetch、preconnect 之類新語法加進支援清單裡，導致開發者只能跟著局勢邊走邊調整策略，有一種被時代推著跑的無力感。有時候你打開一個頁面，看它資源提示混搭三四種，好像在玩拼圖遊戲一樣；然後欸，其實如果想讓跨域請求提前預設好連線，也沒什麼其他更穩的方式了。講白了那些技術名詞聽起來很兇殘，但總體就是為了多來源網頁互動做細緻設定啦——只是想事情能不要拖慢使用者體驗就好。
突然岔題一下，每次看到「單一主機撐全站」那種架構我都會忍不住懷舊，可惜這年代已經很難回去了吧？嗯，好吧，拉回正題。不管怎樣，以前那套靠單一主機硬撐到底的模式，大概只剩下記憶而已。
新版 Edge 跟 Firefox 其實也沒什麼張揚，就默默把 dns-prefetch、preconnect 之類新語法加進支援清單裡，導致開發者只能跟著局勢邊走邊調整策略，有一種被時代推著跑的無力感。有時候你打開一個頁面，看它資源提示混搭三四種，好像在玩拼圖遊戲一樣；然後欸，其實如果想讓跨域請求提前預設好連線，也沒什麼其他更穩的方式了。講白了那些技術名詞聽起來很兇殘，但總體就是為了多來源網頁互動做細緻設定啦——只是想事情能不要拖慢使用者體驗就好。
突然岔題一下，每次看到「單一主機撐全站」那種架構我都會忍不住懷舊，可惜這年代已經很難回去了吧？嗯，好吧，拉回正題。不管怎樣，以前那套靠單一主機硬撐到底的模式，大概只剩下記憶而已。
Comparison Table:
| 主題 | 結論 |
|---|---|
| DNS 預取效益 | 在理想環境下，DNS 預取可節省約 70 毫秒的解析時間，但實際效果受網路品質和快取狀況影響，可能拉長至超過 100 毫秒。 |
| 預連接與預取標籤使用 | 僅針對高頻且關鍵的外部服務（如登入驗證、CDN）考慮使用 DNS 預取或預連接，不建議隨意添加所有資源。 |
| 流量分析的重要性 | 應優先檢視流量分布圖表，以確定哪些資源最常被即時調用，從而做出合理的優化決策。 |
| 錯誤配置後果 | 不當配置 DNS 預取或預連接會導致初始渲染速度下降，甚至拖慢頁面加載，而非提升性能。 |
| 定期檢查與微調 | 建議每隔一段時間回顧並微調現有的 resource hints 配置，以保持網站性能並減少無謂的緩存壓力。 |
第三方資源怎麼選，dns-prefetch該不該加主站？
Mozilla 的開發手冊那句直接寫「千萬別對自家主域名加 dns-prefetch」，老實說有點狠，嗯，不過現場測起來的確會這樣——就，多餘。欸，有時候我還是會懷疑是不是自己眼花，可結果就是效能會被拖慢。唉，好吧。其實你去看，有些團隊到現在還是喜歡把所有第三方連結全預取一遍，好像多貼幾個 hint 標籤心裡才安心，但說真的，這種做法未必真有幫助。
話題講遠了，我拉回來……舉個例子啦，如果你把 dns-prefetch 用在本身網站的主網域上——理論上訪客每次進站早解析過 DNS，再下提示根本沒啥意義，有時甚至卡住流量分配，變成一種莫名消耗資源的行為。有點像……嗯，不知道怎麼形容，就是白忙一場那種感覺。
正確流程應該大概這樣：先盤點外部資源清單，只針對經常性請求、又離站比較遠（譬如某些廣告追蹤或分析腳本）的幾個第三方服務才去放 dns-prefetch 或 preconnect。至於那些跨國 CDN，反而更需要細緻設計，不是隨便亂加標籤就行了。我突然想到一件事——之前有人整個站都貼 hint 標籤，最後用戶端 CPU 飆高，他還以為圖片太大，其實只是提示玩太兇，就……唉，技術圈也不是每天都嚴肅嘛。
話題講遠了，我拉回來……舉個例子啦，如果你把 dns-prefetch 用在本身網站的主網域上——理論上訪客每次進站早解析過 DNS，再下提示根本沒啥意義，有時甚至卡住流量分配，變成一種莫名消耗資源的行為。有點像……嗯，不知道怎麼形容，就是白忙一場那種感覺。
正確流程應該大概這樣：先盤點外部資源清單，只針對經常性請求、又離站比較遠（譬如某些廣告追蹤或分析腳本）的幾個第三方服務才去放 dns-prefetch 或 preconnect。至於那些跨國 CDN，反而更需要細緻設計，不是隨便亂加標籤就行了。我突然想到一件事——之前有人整個站都貼 hint 標籤，最後用戶端 CPU 飆高，他還以為圖片太大，其實只是提示玩太兇，就……唉，技術圈也不是每天都嚴肅嘛。
CDN圖片、外部字體秒開的秘密武器
之前遇過一個品牌站，嗯，那個首頁首屏堆了一大堆外部字體，圖片又東一塊西一塊散在什麼 CDN 上。DNS 查詢的時候光來源就拖了七八個吧，唉，我記得那時候 latency 落差大概有七十多毫秒？這數字還挺刺眼的。然後開發者邊翻 Chrome DevTools 的 screenshot 邊碎念，我其實當下注意力飄到旁邊同事在喝什麼奇怪的飲料——咳，拉回來，他說：「我們直接把常用字體服務商和主要圖床都加上 dns-prefetch 放進 head。」結果更詭異的是改完隔天流量明明就順很多，跳出率居然掉了一截。
其實這方法也沒多新鮮啦，大概早有人試過。不過踩點真的超重要。像我自己有時候想偷懶，一股腦全丟 hint 標籤進去，其實沒必要；只有那些跨區請求很頻繁的第三方資源才值得特別預取。突然想到前幾天 DNS 又炸鍋…算了，不提。我是說，如果 CDN 圖片本來就走自家 domain，你 hint 什麼呢？反而 cloud 字體這種要跑遠路的，加 hint 差異就很明顯。
SEO 跟首屏時間如果被前段連線卡住，那些操作大致能讓三成左右用戶感受到提速吧——不過細節真的藏魔鬼。有次我貼錯位置，一堆 hint 標籤疊在一起，用戶端 CPU 反倒開始喘氣，有夠煩。怎麼選到底？老實講，只能自己拉 network log 慢慢拆解看，憑感覺寫規則最後都會踩雷。好吧，就只能這樣了。
其實這方法也沒多新鮮啦，大概早有人試過。不過踩點真的超重要。像我自己有時候想偷懶，一股腦全丟 hint 標籤進去，其實沒必要；只有那些跨區請求很頻繁的第三方資源才值得特別預取。突然想到前幾天 DNS 又炸鍋…算了，不提。我是說，如果 CDN 圖片本來就走自家 domain，你 hint 什麼呢？反而 cloud 字體這種要跑遠路的，加 hint 差異就很明顯。
SEO 跟首屏時間如果被前段連線卡住，那些操作大致能讓三成左右用戶感受到提速吧——不過細節真的藏魔鬼。有次我貼錯位置，一堆 hint 標籤疊在一起，用戶端 CPU 反倒開始喘氣，有夠煩。怎麼選到底？老實講，只能自己拉 network log 慢慢拆解看，憑感覺寫規則最後都會踩雷。好吧，就只能這樣了。
歐美媒體與亞洲網站：不同路徑追求極速
嗯，像歐洲那邊的大型新聞媒體，據說真的很愛把 resource hints 當成 SEO 加速的標配。這種事情其實我一開始也沒太在意啦，不過 2023 年底，好像有些主流網站還特地優化了 DNS 預取的位置。然後——欸，我突然想到，上次看到一個國際站的 head 標籤，內容密密麻麻的，專家隨手翻給我看時還碎念了一下，他們反而很少會在 CDN 圖片上疊加那些冗餘的預連接。原因咧？說穿了就是網路骨幹本來就夠穩固，所以根本不需要再花心思搞什麼多重備援。好吧，其實這邏輯我還是有點不太能感同身受。
亞洲市場卻又完全不同，唉，有時候真的很難講清楚差異在哪裡，也許是基礎設施落差很明顯。有些產業直接選擇偏向 CDN 冗餘備援，多弄幾條路徑以防萬一，就算會有資源重複請求，也覺得比較安心。我自己其實偶爾也會想，是不是人都喜歡留個退路？扯遠了，拉回正題。
「選擇方案其實很看場景，例如跨國內容服務，如果只靠單一 hint 標籤，大概難以解決所有痛點。」技術圈裡偶爾也有人質疑：是不是每個外部資源都值得加 hint？答案並沒有絕對，有點玄妙。有研究團隊發現過度預取可能讓效能表現反而起伏更大，那種感覺就像你努力做了很多準備，但結果卻變得不可控。
有趣的是啊，其實文化背景或團隊決策風格往往才是最後拍板的關鍵，有人堅持自動化測試數據為王，有人寧可信老派的人力拆解流程。唔，每次遇到這種分歧，我都會忍不住懷疑，到底要怎麼下判斷才好？只能說吧，目前還沒有哪一種模式永遠勝出，大概就是這樣。
亞洲市場卻又完全不同，唉，有時候真的很難講清楚差異在哪裡，也許是基礎設施落差很明顯。有些產業直接選擇偏向 CDN 冗餘備援，多弄幾條路徑以防萬一，就算會有資源重複請求，也覺得比較安心。我自己其實偶爾也會想，是不是人都喜歡留個退路？扯遠了，拉回正題。
「選擇方案其實很看場景，例如跨國內容服務，如果只靠單一 hint 標籤，大概難以解決所有痛點。」技術圈裡偶爾也有人質疑：是不是每個外部資源都值得加 hint？答案並沒有絕對，有點玄妙。有研究團隊發現過度預取可能讓效能表現反而起伏更大，那種感覺就像你努力做了很多準備，但結果卻變得不可控。
有趣的是啊，其實文化背景或團隊決策風格往往才是最後拍板的關鍵，有人堅持自動化測試數據為王，有人寧可信老派的人力拆解流程。唔，每次遇到這種分歧，我都會忍不住懷疑，到底要怎麼下判斷才好？只能說吧，目前還沒有哪一種模式永遠勝出，大概就是這樣。
實驗室數據浮動，解析時間省下多少毫秒？
根據 2023 年東亞多地的網路測試，DNS 預取這個機制啊，在第三方來源上其實能省下七十多毫秒的解析等待——嗯，不過這數字感覺有點飄忽。有人就說啦，只要終端用戶那邊網路品質一差、或者本地快取怪怪的，時差會被拉大，有時甚至超過一百毫秒。真是讓人有點無奈。
明明同樣一組設定，你在歐洲骨幹線路上跑超順，然後搬去南亞某些區域……欸？完全沒起色，到底怎麼回事？我自己都懷疑是不是哪裡漏掉什麼細節。岔個題，前陣子還看到有團隊直接把 DNS 預取搬到頁面最前頭，結果反而效能浮動更明顯——這種事誰想得到？
其實每次大家討論那些小小的數字，都很容易迷失。有時候你拿出量化成果來看，好像以為單一指標就能判斷全部，可現實就是太多環境條件糾纏著，根本難以下定論。唉，我也只是大致描述一下罷了。
明明同樣一組設定，你在歐洲骨幹線路上跑超順，然後搬去南亞某些區域……欸？完全沒起色，到底怎麼回事？我自己都懷疑是不是哪裡漏掉什麼細節。岔個題，前陣子還看到有團隊直接把 DNS 預取搬到頁面最前頭，結果反而效能浮動更明顯——這種事誰想得到？
其實每次大家討論那些小小的數字，都很容易迷失。有時候你拿出量化成果來看，好像以為單一指標就能判斷全部，可現實就是太多環境條件糾纏著，根本難以下定論。唉，我也只是大致描述一下罷了。
資料來源：
敏感來源先上標籤，非關鍵資源別急著優化
「先看看流量分布圖表，這個步驟其實蠻多人會直接跳過…唉，我自己有時候也懶得點開。」一位網站維運工程師順口提到。不是每個資源都值得你花精力去優先解析或預連接嘛，有些真的沒差。我常常搞不清楚到底該從哪裡下手，然後滑一下又分心，嗯，不過流程大致上還是會先釐清哪些外部服務最常被即時調用，比方說登入驗證啦、第三方分析、又或者圖片 CDN 這種對延遲很敏感的來源，反正那幾個端點總跑不了。
欸我突然想到，上次有人問我 preconnect 跟 dns-prefetch 到底要不要亂加一通？其實這就跟剛才講的一樣，只針對那些重點端點考慮就好。剩下那些偶爾載入的非關鍵資源，維持原生加載反而比較穩——據說啦，如果硬套預取標籤，有時候還可能拖慢初始渲染速度，聽起來真是本末倒置。有些開發者乾脆把全部第三方服務全丟進去，但現場觀察結果，其實成效差異相當明顯，好吧…有時候測到最後才發現優化幅度跟一開始想像的落差將近一半。
規則設計這種東西，好像也不用一次定死，每隔一段時間回頭檢查一下、微調排序順序，也許才能比較兼顧速度和穩定性吧。我自己常常改了又改，一下覺得快了，一下又出事，很煩，但大概就是這麼回事。
欸我突然想到，上次有人問我 preconnect 跟 dns-prefetch 到底要不要亂加一通？其實這就跟剛才講的一樣，只針對那些重點端點考慮就好。剩下那些偶爾載入的非關鍵資源，維持原生加載反而比較穩——據說啦，如果硬套預取標籤，有時候還可能拖慢初始渲染速度，聽起來真是本末倒置。有些開發者乾脆把全部第三方服務全丟進去，但現場觀察結果，其實成效差異相當明顯，好吧…有時候測到最後才發現優化幅度跟一開始想像的落差將近一半。
規則設計這種東西，好像也不用一次定死，每隔一段時間回頭檢查一下、微調排序順序，也許才能比較兼顧速度和穩定性吧。我自己常常改了又改，一下覺得快了，一下又出事，很煩，但大概就是這麼回事。
亂加預取反傷效能？小心冷門鏈結拖慢速度
「有人直接把整批冷門端點都加進 dns-prefetch，結果首屏反而更慢，」這話我到現在還記得。嗯，好像在哪個前端協作群組裡聽過，有點模糊，但印象挺深。其實很多人沒注意到，瀏覽器能同時處理的 DNS 查詢數量是有限的，你以為丟一堆內部鏈結或低頻外部資源進去就會有神奇效果嗎？唉，現實往往不是這麼簡單。反而卡住那些原本應該優先處理的請求，真的是，自找麻煩吧。
說到快取壓力，我覺得好像沒人真的在乎那個記憶體佔用變高到底有多誇張——但它就是會升溫啊。有時候想到這些冷門資源平常載入率就很低，你卻強行叫它們提前解析，我都想問一句：到底圖什麼？欸，不對，我剛剛是不是又岔題了。總之，就是只會讓事情更複雜。
有個工程師之前試過，把所有第三方服務域名全塞上去，結果怎樣？首頁渲染速度下降幅度將近一半，用戶直接抱怨畫面空白時間拉長。我突然想到自己也做過類似蠢事，大概吧。你再比對另一批專案，只針對登入驗證或圖片 CDN 這種高頻、關鍵端點設預取標籤，首屏穩定性明顯好很多啊。
檢查 Network 面板的時候，有沒有發現一些頁面的 JS 檔下載順序被打亂了？居然只是因為那些多餘的預取在搗蛋。唉，其實 dns-prefetch 並不是愈多愈好啦。錯誤配置帶來的副作用，比完全不用還尷尬——就像本末倒置一樣。不知道為什麼，每次現場討論總有人掉進過度優化陷阱，可能是太想追求完美吧，可惜最後只剩下徒勞和嘆氣。
說到快取壓力，我覺得好像沒人真的在乎那個記憶體佔用變高到底有多誇張——但它就是會升溫啊。有時候想到這些冷門資源平常載入率就很低，你卻強行叫它們提前解析，我都想問一句：到底圖什麼？欸，不對，我剛剛是不是又岔題了。總之，就是只會讓事情更複雜。
有個工程師之前試過，把所有第三方服務域名全塞上去，結果怎樣？首頁渲染速度下降幅度將近一半，用戶直接抱怨畫面空白時間拉長。我突然想到自己也做過類似蠢事，大概吧。你再比對另一批專案，只針對登入驗證或圖片 CDN 這種高頻、關鍵端點設預取標籤，首屏穩定性明顯好很多啊。
檢查 Network 面板的時候，有沒有發現一些頁面的 JS 檔下載順序被打亂了？居然只是因為那些多餘的預取在搗蛋。唉，其實 dns-prefetch 並不是愈多愈好啦。錯誤配置帶來的副作用，比完全不用還尷尬——就像本末倒置一樣。不知道為什麼，每次現場討論總有人掉進過度優化陷阱，可能是太想追求完美吧，可惜最後只剩下徒勞和嘆氣。
IE與WebView那些年沒說的兼容陷阱
欸你知道嗎？前幾天又聽到有人在碎念：「為什麼同一份 resource hints，搬去另一個平台就突然沒屁用了？」其實這種事老早就見怪不怪，特別是那種死都要用舊版 IE 的企業內網，或者一些莫名其妙還活著的定制 WebView 老殼。嗯，我有時候真的懷疑他們是不是對新東西過敏。有些標籤像 dns-prefetch、preconnect，你加上去——結果跟空氣沒兩樣，好像根本沒寫。
然後你以為瀏覽器會乖乖照標準來？想太多吧。現實就是，那兼容性清單永遠長得歪七扭八，一下支援一下裝死。唉，有點無奈。原本滿心期待用資源預取把首屏白畫面壓縮到極致，結果加了半天發現速度一點都沒變快。我朋友之前也踩過雷，他們團隊明明超嚴謹，各式各樣的 resource hints 全部配齊，到最後才意外發現：該瀏覽器根本連語法都看不懂，只能乾瞪眼嘆氣。
好啦，其實我剛剛突然想到昨天吃的拉麵真鹹…呃，回到主題。有時候光 prefetch 或 preconnect 那幾行要不要適配，就可能決定整套前端優化到底成不成立。不查相容表直接開衝？設計再華麗，也許最後只剩自己自言自語，很崩潰的。
然後你以為瀏覽器會乖乖照標準來？想太多吧。現實就是，那兼容性清單永遠長得歪七扭八，一下支援一下裝死。唉，有點無奈。原本滿心期待用資源預取把首屏白畫面壓縮到極致，結果加了半天發現速度一點都沒變快。我朋友之前也踩過雷，他們團隊明明超嚴謹，各式各樣的 resource hints 全部配齊，到最後才意外發現：該瀏覽器根本連語法都看不懂，只能乾瞪眼嘆氣。
好啦，其實我剛剛突然想到昨天吃的拉麵真鹹…呃，回到主題。有時候光 prefetch 或 preconnect 那幾行要不要適配，就可能決定整套前端優化到底成不成立。不查相容表直接開衝？設計再華麗，也許最後只剩自己自言自語，很崩潰的。
Less is more：多元整合才是穩定加速王道
資源調度這種麻煩事，Mozilla 文件裡有提過一嘴啦——預取、預連接的標籤，其實嘛，真的只推薦放給「外部而且熱用」的第三方來源。嗯，有些團隊很愛把所有外鏈一股腦丟進 dns-prefetch，好像多多益善，但老實說，大可不必。唉，我自己偶爾也會想偷懶全加，然後才發現其實沒意義。嗯，還是得回頭看流量分布統計吧，先搞清楚首屏重要內容到底仰賴哪些來源，再慢慢決定要不要加 dns-prefetch 或 preconnect。突然想到，上次開會時有人堅持自家主站也要加標籤，我當下差點翻白眼——自家主站或那些冷門 API 真不用去搶那幾條可憐的併發連線資源，不小心反而拖累首屏渲染速度。
說到工具啊，其實 Chrome DevTools 的網路面板還蠻好用的，可以直接看出各個外部服務解析花了多少時間。有時候我邊測邊喝咖啡，一不小心就盯著某個 CDN 圖片卡半天，所以哪些圖片、字體或 JS 檔案該優先處理，大致上都能靠這工具抓出來。欸對，有時又會突然想起瀏覽器相容性的鳥事，像有些舊版 WebView 或 IE，就是硬生生不支援新標籤，只能另想辦法，例如倒退回傳統 async script 或乾脆善用 CDN 路徑冗餘，雖然感覺有點土法煉鋼。
最後維護的時候，也不能鬆懈啦（雖然我常常忘記），建議還是隔段時間檢查一下現有 resource hints 配置。有什麼變動就微調，把非關鍵標籤移掉，不然緩存壓力莫名其妙就漲上來，到底為誰辛苦為誰忙？唉，有時候真的很想罵人，但現實只能默默改設定，又是一夜未眠…
說到工具啊，其實 Chrome DevTools 的網路面板還蠻好用的，可以直接看出各個外部服務解析花了多少時間。有時候我邊測邊喝咖啡，一不小心就盯著某個 CDN 圖片卡半天，所以哪些圖片、字體或 JS 檔案該優先處理，大致上都能靠這工具抓出來。欸對，有時又會突然想起瀏覽器相容性的鳥事，像有些舊版 WebView 或 IE，就是硬生生不支援新標籤，只能另想辦法，例如倒退回傳統 async script 或乾脆善用 CDN 路徑冗餘，雖然感覺有點土法煉鋼。
最後維護的時候，也不能鬆懈啦（雖然我常常忘記），建議還是隔段時間檢查一下現有 resource hints 配置。有什麼變動就微調，把非關鍵標籤移掉，不然緩存壓力莫名其妙就漲上來，到底為誰辛苦為誰忙？唉，有時候真的很想罵人，但現實只能默默改設定，又是一夜未眠…
