主機與地理位置
主機位置與 TTFB 直接影響爬取效率
主機像店面的地段——客人（與 Google 的爬蟲）每次上門都要走這段路，路太遠太塞，來的次數就變少。
03為什麼是現在學
主機決定 TTFB（伺服器首位元組回應時間），它墊在所有速度指標底下：主機慢，前端再怎麼優化都在追著補。
04白話理解（對客戶簡報可直接引用）
你的網站檔案放在某台伺服器上，訪客與 Google 每次開你的網頁都要跟那台機器來回。機器離台灣遠（或等級太低），每個頁面都多等零點幾秒——訪客感受得到，Google 的爬蟲也會因此少爬幾頁。台灣受眾就選有台灣／亞洲節點的主機或 CDN，並確認 TTFB 穩定在 0.8 秒內。
05工具箱
- ▸PageSpeed Insights — 看 TTFB 與整體速度（實地資料優先）
- ▸curl -w '%{time_starttransfer}' — 工程師 30 秒實測 TTFB
- ▸CDN（Cloudflare／Vercel Edge） — 把靜態資源放到離訪客近的節點
06怎麼做 · SOP 3 步（每步標產出物）
- 1量測首頁與三個內頁的 TTFB（不同時段各三次）→ TTFB 量測紀錄
- 2確認主機／CDN 是否有亞洲節點，受眾在哪就近部署→ 主機規格表
- 3TTFB > 0.8s：先查快取設定，再談升級方案→ 改善方案與費用比較
07場景應用（實戰經驗）
- ◆台灣中小企業常見：掛在美國廉價虛擬主機，TTFB 1.5 秒起跳——換到有台灣節點的方案通常是整個專案 CP 值最高的一步。
- ◆WordPress 站：主機層快取（page cache）沒開，等於每個訪客都要現煮一次頁面。
08⚠️ 常見誤區
- ✕只看主機「不限流量」的行銷話術，不看實測 TTFB。
- ✕把 Lighthouse 實驗室分數當實際體驗——實地資料（CrUX）才算數。
口訣
「TTFB 是所有速度的地板——地板不平，上面怎麼裝潢都是歪的。」
10里程碑 · 完成標準（可驗證）
- ☐首頁 TTFB p75 ≤ 0.8s
- ☐靜態資源走 CDN
- ☐主機方案與流量成長規劃書面化
學習者勾自己的進度；顧問勾客戶專案的交付——同一份標準，兩種用法。
12檢核方式與依據出處
程式自動判定：輸入網址，掃描引擎自己爬、自己打 API、自己判定。
依據等級決定計分權重（🟢×3／🔵×2／⚠️×1）——權重量的是「依據有多硬」， 不是「我們覺得多重要」。查無權威文件的判準，誠實標「業界慣例」。