怎麼讀這本手冊
你如果寫過 ASP.NET Web Forms，會覺得名詞很熟：頁面、回傳、控制項、Code-Behind。熟的是感覺，不是實作。WebForms Core 沒有 ViewState，也不把整頁重新畫出來。伺服器只回一小段文字，告訴瀏覽器「把這個標籤的字改掉、把那個按鈕關掉」。
阅读文章 →三個容易搜到的名字
搜尋「WebForm Core .NET」會同時掉進三個專案。它們都提到 Web Forms，也都跑在新的 .NET 上，解決的問題卻不一樣。先把地圖畫出來，後面才不會把 A 的安裝步驟套到 B 的頁面上。
阅读文章 →舊版 Web Forms 留下的直覺
WebForms Core 的命名是故意的。CodeBehind 的介紹寫著，結構和命名會讓人想起以前的 Microsoft Web Forms。官方教學的結論也說，功能感覺相近，實作是另一套更有彈性的做法。要學會新的那套，得先知道舊的直覺從哪裡來，又是哪裡斷掉。
阅读文章 →一條請求長什麼樣子
WebFormsJS 做三件事。第一，送出時把表單序列化：一般表單用查詢字串形式，multipart 表單用 FormData。第二，看回應正文是不是 Action Control；是就執行，不是就把正文當成 AJAX 結果放進頁面（預設可放進一個 div，見 PostBackOptions.SetResponseInsideDivTag）。第三，在第一次整頁輸出時，若伺服器把指令放在 <web-forms ac="...">，它也會執
阅读文章 →把第一個專案跑起來
這一章只建立宿主，還不寫業務。目標是：瀏覽器開得到一頁 HTML，標頭裡有 WebFormsJS，伺服器進得了 PageLoad。
阅读文章 →走完官方那個歡迎頁
第 4 章的表單已經在頁面上。這一章補上控制器，然後對著網路面板把請求與回應讀完。範例的欄位名稱與官方教學一致，方便你對回文件。
阅读文章 →指到正確的那一個節點
Action Control 沒有控制項 ID 系統。你每次都在描述「現在這份 DOM 裡的哪一個節點」。指錯了，指令仍會成功執行，只是執行在別處。這一章把六種定位，和 C# 裡的兩種寫法，放在同一棵樹上。
阅读文章 →Action Control 代碼
你平常呼叫的是 C# 方法。除錯時讀到的是這張代碼表。兩套名字要對得起來，否則網路面板裡的一行會變成無法翻譯的縮寫。代碼取自 WebFormsJS 的公開 README，這裡按學習順序重排，不是按原始檔的段落順序。
阅读文章 →C# 類別上你會呼叫的方法
WebForms 的公開方法很多。這一章只排你在前 11 章會用到、而且能在公開教學或類別清單裡對上代碼的那些。方法的第一個參數幾乎都是定位：InputPlace 或它的字串形式。
阅读文章 →表單、檔案與頁面上的訊息
歡迎頁只有三個文字欄位。真實表單還有核取、下拉、多行文字與檔案。這一章的模式都一樣：用 name 讀取，用 WebForms 寫回頁面，不要把整頁換掉。
阅读文章 →沒有 ViewState 時，狀態放哪裡
舊版 Web Forms 把控制項狀態塞進隱藏欄位，所以重新整理與回傳之後，文字框裡的字還在。WebForms Core 的官方教學把「不使用 ViewState」列成優點。優點的背面是：你要自己決定哪些狀態活在 DOM、哪些活在伺服器、哪些活在瀏覽器歷史。
阅读文章 →練習：一頁聯絡表單
Has() 是 CodeBehind 教學用來判斷表單鍵是否有值的擴充。若你的版本沒有它，改回 !string.IsNullOrEmpty(...)。失敗的那條路不要停用按鈕，也不要排刪除。成功的那條路才停用，並讓綠色標題在數秒後消失。
阅读文章 →另外兩條同名的路
協定適合「頁面結構大致固定，互動是改文字、改樣式、加幾列、停用按鈕」。下面這些情況，公開文件沒有把它說成目標，你也不該硬做：
阅读文章 →代碼速查
elanat-send Elanat, CodeBehind tutorial series, form submit and file fields. https://elanat.net/page_content/documentation/code_behind_framework_tutorial_series/send_data_by_submitting_form
阅读文章 →課程導論：為什麼要學前端效能
Core Web Vitals 的評分採用第 75 百分位數（p75）：把某個頁面在 28 天內所有真實造訪的 LCP 值排序，取第 75% 位置的值。這代表「至少 75% 的使用者體驗到的 LCP 不超過這個值」。這個設計刻意偏向「較差的那一端」：頁面在你的高階筆電加光纖上很快沒有意義，它必須在四分之三的使用者手上（包含中階手機加不穩定的行動網路）也夠快。
阅读文章 →fetch 之前：瀏覽器如何建立連線
當使用者在網址列輸入 https://shop.example.com/ 並按下 Enter，瀏覽器並不是立刻「fetch」。在真正送出 HTTP 請求之前，有一連串的準備工作；圖 把這些步驟依時間排開，並標出 Navigation Timing API 中對應的時間點屬性（ch:perfapi會完整介紹這個 API）。
阅读文章 →效能量化指標總覽：TTFB、FP、FCP、FMP、LCP、FID、INP、CLS
圖 將本章所有指標放在同一條頁面生命週期時間線上。左半部（TTFB、FP、FCP、LCP）是「載入」階段的時間點；INP 是整段互動期間所有互動延遲的彙整；CLS 則是整個生命週期中版面跳動的累計。
阅读文章 →Web Vitals 深入：LCP、INP、CLS 的診斷與優化
web.dev 建議把 LCP 時間拆成連續的四段（圖 ）。任何 LCP 優化都應該先知道「時間花在哪一段」，再對症下藥。
阅读文章 →Performance API：瀏覽器原生的量測工具箱
所有效能量測 API 都掛在全域的 performance 物件（window.performance）上，並共用一條效能時間線Performance Timeline。時間線上的每一筆資料都是一個 PerformanceEntry，有四個共同欄位：
阅读文章 →Chrome DevTools Performance 面板實戰
按 F12（macOS：Cmd+Option+I）開啟 DevTools，切到 Performance 分頁。在尚未錄製任何東西時，你會看到 Live Metrics 畫面，它就是一個即時的 Web Vitals 儀表板：
阅读文章 →快取策略：HTTP Cache、bfcache 與 Speculation Rules
ch:beforefetch提到，一次新連線要花好幾個 RTT 才能拿到第一個位元組。若資源能在本地快取命中，這些 RTT 全部歸零，而且不佔用頻寬。圖 是一個請求離開頁面後，可能被「攔下」的各個層級。
阅读文章 →Service Worker 與效能
SW 能做的事很多（推播、背景同步、離線），但本章只談效能：它讓你可以用 JavaScript 決定每個請求的快取策略，不再受限於伺服器的 HTTP 標頭，並且能在離線或網路很差時仍立即回應。
阅读文章 →CDN：把內容搬到使用者旁邊
ch:beforefetch算過：一次全新的 HTTPS 連線到拿到第一個位元組，TCP + TLS 1.3 需要約 3 個 RTT，再加上 TCP 慢啟動，前幾十 KB 還要多幾個 RTT。RTT 的下限由物理決定：光在光纖中約每秒 20 萬公里， 每 1,000 公里的往返至少 10 ms，實際路由再加上交換與排隊延遲，通常是理論值的 1.3–2 倍。
阅读文章 →伺服器端渲染（SSR）與渲染策略
傳統 SSR 是「等全部資料到齊 → 渲染整頁 → 一次送出」，最慢的那個資料源決定了 TTFB。串流 SSR 把 HTML 拆成多段：先送出外殼與已就緒的部分（TTFB 只取決於外殼），慢的區塊用 <Suspense> 包起來，先送 fallback，資料到了再把內容當成後續 chunk 送到，並用一小段內嵌 script 把它替換到正確位置。
阅读文章 →