壓縮後 TTFB 變成 1.7 毫秒，整頁卻從 43 毫秒降到 8 毫秒
作者是 John Graham-Cumming。JSON-LD 的刊登時間是 2012 年 7 月 5 日，修改時間寫 2026 年 7 月 15 日。正文沒有說實驗重做，數字仍是這一次對照。2012 年的公司拼法是 CloudFlare。頁面列了德文、西班牙文、法文和簡體中文。佇列裡的三則是其中三種譯本。
當時常見的測速服務把 TTFB 當成網站伺服器回應有多快。他說理論上越快代表伺服器越好，但這個理論不好。文中引當時的 Wikipedia：從虛擬使用者發出 HTTP 請求，到瀏覽器收到頁面第一個位元組的時間。今天的 Wikipedia 頁面已經改過，沒有那句，所以不把現在的條目當成這次測試的定義。
目錄（6）
編譯自 Cloudflare · John Graham-Cumming · 2012-07-05 原文
完整來源聲明
來源聲明：本文根據 John Graham-Cumming（Cloudflare，2012-07-05）〈Stop worrying about Time To First Byte (TTFB)〉編譯為繁體中文，不是逐句翻譯。頁面沒有寫 CC BY。法文、簡體中文和德文是同一篇的譯本，不另成篇。測試是他們自己的伺服器：先送出 HTTP 狀態列的 H，停 10 秒；nginx 壓縮對照只有一頁。原文：https://blog.cloudflare.com/ttfb-time-to-first-byte-considered-meaningles/。文中「編輯解讀」為本站觀點，不屬於原文。檢索日期：2026-10-17。
測到的是狀態列的第一個字母
瀏覽器送出請求和標頭，伺服器先回狀態列，通常是 HTTP/1.1 200 OK，接著是標頭，最後才是頁面內容。
他們的測試伺服器不一樣。收到請求後，先送出 HTTP/1.1 200 OK 的第一個字母 H，停 10 秒，再送其餘標頭和頁面。程式是 Go，作者連到自己的程式碼倉庫。1 倉庫頁面這次沒有在 HTML 裡重述這 10 秒，10 秒以文章為準。
用 WebPageTest 開這個伺服器時，它報的 TTFB 是收到 H 的時間，不是頁面送出的時間。10 秒的停頓把這件事顯出來。Gomez 報了同一個數字。Gomez 當年的測試網址現在開到別的監測產品頁，沒有放進本文連結。
所以這些工具報的 TTFB，是 HTTP 回應的第一個位元組，不是頁面資料的第一個位元組。標頭可以很快產生。使用者看不看得到頁面，取決於後面的資料。
壓縮後 TTFB 變大，整頁下載變短
他們大量用 nginx。Gzip 會讓網頁下載變小，但壓縮本身要時間，TTFB 會變大，即使整頁下載更快。
對照用的是當時最大的一篇 Wikipedia：〈List of Advanced Dungeons and Dragons 2nd Edition Monsters〉。同一頁用 nginx 送，壓縮開和關各一次。表是：
| TTFB | 頁面載入 | |
|---|---|---|
| 不壓縮 | 213 微秒 | 43 毫秒 |
| Gzip 開 | 1.7 毫秒 | 8 毫秒 |
213 微秒是 0.213 毫秒。他說整頁下載快了 5 倍，TTFB 大了 8 倍。43 除以 8 是 5.4，1.7 除以 0.213 約是 8。他用的是這兩個整數倍。原因是 nginx 會等壓縮開始才送 HTTP 標頭；關掉壓縮時，標頭立刻送出。只看 TTFB，壓縮像是壞事。看下載時間，方向相反。
他說從使用者的角度，TTFB 幾乎沒用。在這個真實例子裡，它和下載時間是負向一起走的：TTFB 越差，下載越快。這是一頁、兩種設定，不是很多網站算出來的相關係數。表上也沒有寫客戶端在哪裡量。
看 nginx 原始碼之後，他們知道可以先把標頭送出，讓壓縮開啟時 TTFB 仍然很好看。他們沒有這樣做。那會在 TCP 慢啟動時浪費一個封包，傷害使用者，只是讓 Cloudflare 在某些測試裡好看。慢啟動的說明他連到另一篇 Cloudflare 文章，那篇講連線開始時不會一次把封包送滿，不是這張壓縮表的第二次實驗。2
他留下的用途只有伺服器上的趨勢
他說 TTFB 大概只在看趨勢時有用，而且最好在伺服器上量，把網路延遲拿掉。趨勢可以看出伺服器是不是出問題，例如過載。從遠處量，量到的同時有網路延遲，會蓋住伺服器真正的回應時間。
在 Cloudflare，TTFB 不是重要指標。他們要的是使用者真正看到頁面的時間，並說會推出工具讓發布者看到訪客經驗。那是 2012 年的預告，這篇沒有工具名稱，也沒有看到頁面的秒數。
常見問題
- TTFB 量的是頁面第一個位元組嗎？這次不是。測試伺服器先送 HTTP/1.1 200 OK 的 H，停 10 秒，再送標頭和頁面。WebPageTest 和 Gomez 把 TTFB 記在收到 H 的時候。報出來的是回應的第一個位元組，不是頁面資料。
- 壓縮會不會讓網站變慢？這張表不是。同一篇 Wikipedia、nginx：不壓縮時 TTFB 213 微秒、載入 43 毫秒；Gzip 開時 TTFB 1.7 毫秒、載入 8 毫秒。他寫下載快 5 倍、TTFB 大 8 倍。只有這一頁，沒有寫量測地點。
- 先送標頭讓 TTFB 變好看，可以嗎？他們知道 nginx 做得到，但沒有做。理由是 TCP 慢啟動時會浪費一個封包，使用者更慢，只是測試數字好看。這是他們的決定，不是另一組速度數據。
- TTFB 完全不能看嗎？他留下的用途是伺服器上的趨勢，用來看出過載這類問題。從遠處量會把網路延遲算進去。這篇沒有訪客看到頁面的秒數。
- 法文、中文、德文要各寫一篇嗎？不用。頁面寫明那是同一篇的譯本，網址是同一則英文文章的語言路徑。實驗沒有因為語言而改變。
編輯解讀
一句話重點：2012 年這次，測速工具的 TTFB 停在回應標頭。壓縮讓這一頁的 TTFB 變大，整頁下載變短。
這對你的網站意味著什麼：
- 遠端 TTFB 變好，先問它是不是只收到標頭。這次 WebPageTest 和 Gomez 都把 H 算進去。
- Gzip 不要只用 TTFB 判斷。這張表是 TTFB 變差、下載變快。不要把 5 倍和 8 倍挪到別的頁面。
- 不要為了測試分數先送標頭。他們認為那會在慢啟動浪費封包。
- 若要看伺服器是不是過載，用伺服器上的趨勢，不要用混進延遲的遠端單次數字。
適用與不適用的情境：適用於讀 2012 年這一次對照。不適用於把 213 微秒或 8 毫秒當成你的網站，或當成現在瀏覽器對 TTFB 的定義。
需要注意的限制：測試伺服器和 nginx 都是 Cloudflare 自己的。壓縮只有一頁、兩種設定，沒有寫量測地點。10 秒是故意停頓。Gomez 舊網址現在不是當年的測試頁。2026 年的修改時間沒有新數字。後來 Cloudflare 還有別的測速文，本文不併。
可複用規則3 條
從本文提煉，可供人工對照或 AI 分析站點時作為依據。全部規則
Cloudflare 2012-07-05 的測試伺服器先送出 HTTP/1.1 200 OK 的第一個字母 H，停 10 秒，再送其餘標頭和頁面。WebPageTest 和 Gomez 把 TTFB 記在收到 H 的時間。報出的是回應的第一個位元組，不是頁面資料的第一個位元組。
- 寫明先送 H 再停 10 秒
- 頁面資料還沒送出
同一篇、同一頁 Wikipedia、nginx：不壓縮時 TTFB 213 微秒、載入 43 毫秒；Gzip 開時 TTFB 1.7 毫秒、載入 8 毫秒。作者寫下載快 5 倍、TTFB 大 8 倍。nginx 等壓縮開始才送標頭。只有這一頁、兩種設定，沒有寫量測地點。
- 兩個原始數字都在
- 標成單頁對照
同一篇：TTFB 若要用來發現伺服器過載，最好在伺服器上看趨勢，把網路延遲拿掉。從遠處量會把延遲算進去。他們沒有為了讓壓縮時的 TTFB 好看而先送標頭，因為那會在 TCP 慢啟動浪費封包。這篇沒有訪客看到頁面的秒數。
- 遠端和伺服器上分開
- 先送標頭是他們拒絕的做法
名詞與資料來源
- John Graham-Cumming／Cloudflare：〈Stop worrying about Time To First Byte (TTFB)〉 https://blog.cloudflare.com/ttfb-time-to-first-byte-considered-meaningles/（刊登：2012-07-05；JSON-LD 修改時間：2026-07-15；檢索：2026-10-17）。程式碼倉庫：https://github.com/jgrahamc/ttfb（檢索：2026-10-17）。倉庫標題是 CloudFlare TTFB Test Server。10 秒停頓以文章為準。
- Cloudflare：〈Why mobile performance is difficult〉 https://blog.cloudflare.com/why-mobile-performance-is-difficult（檢索：2026-10-17）。寫連線開始時 TCP 慢啟動不會一次把封包送滿。不是壓縮表的第二次實驗。