重點整理
- 網頁卡頓常因動態內容高度不確定，打破了系統預先計算的規則。
- 將固定內容與動態內容分開計算，可大幅降低系統重新渲染的負擔。
- 採用「結構優先」的資料傳輸，能讓使用者在等待時感覺網頁載入更快。
- 避免畫面跳動的秘密在於「滾動錨定」，鎖定使用者正在看的區塊。
當企業在開發大型電商網站、複雜後台系統，或是引入 AI 工具生成大量內容時，常遇到「資料量一大，網頁就卡頓」的痛點。這不僅影響使用者體驗，更可能導致轉換率下降。近期 GitHub 分享了他們如何讓包含上百萬行修改的超大程式碼審查頁面保持流暢，背後的技術思維，對於我們優化網站與系統效能有著極佳的啟發。
為什麼「動態內容」是網頁卡頓的元凶？
在 GitHub 中，工程師會透過 Pull Request（提交程式碼修改並請求合併的流程）來討論程式碼。當面臨大型系統重構時，往往會產生一個包含數千個檔案、上百萬行 Diff（程式碼修改前後的差異對比）的超大頁面。
要讓這種大頁面流暢滑動，工程師通常會使用 Virtualization（虛擬化渲染）。這是一種只計算並繪製螢幕上看得到的內容，隱藏看不到的部分，以減輕系統負擔的技術。如果網頁上只有純文字或程式碼，因為每行高度固定，系統可以預先算好所有位置，滑動時就會非常順暢。
但問題出在「評論」等動態內容上。一則評論的高度是不確定的，它可能包含會自動換行的文字、可展開的區塊、正在輸入的回覆框，或是還沒載入完成的圖片。因為高度無法預先確定，系統必須在畫面繪製時不斷重新計算，這會打破虛擬化渲染的規則，導致網頁在滑動時產生嚴重的卡頓與延遲。
GitHub 的解法：把「固定」與「動態」分開算
為了解決這個問題，GitHub 團隊放棄了用同一套規則計算所有內容，改採用「雙重幾何架構」，將文件高度分為兩個獨立的領域：
- 確定的程式碼高度：純文字與程式碼的高度是固定的，系統可以預先精確計算，且不會因為評論的變化而重新計算。
- 動態區塊的有效高度：針對評論、回覆框等高度不確定的內容，系統會先給一個「估計值」，等內容真正渲染出來後，再偷偷測量真實高度並更新。
此外，他們也優化了測量時機與畫面穩定度。系統不會在每次畫面滾動時都去重新計算，而是等使用者停止滑動、畫面靜止時，才批次處理視窗範圍內的測量工作。同時，引入 Scroll anchoring（滾動錨定）技術，當動態內容高度改變時，系統會透過鎖定「使用者正在看的區塊身分」來微調畫面，而不是用像素去硬算，這樣就能避免畫面突然跳動，讓閱讀體驗保持平順。
先傳結構，再傳內容的資料管道
除了前端畫面的優化，後端資料的傳輸策略也至關重要。GitHub 採用了「先串流結構，再串流內容」的做法。這就像是先快速把網頁的骨架與文字位置傳給瀏覽器，讓使用者能立刻看到版面並開始滑動，至於圖片或複雜的動態內容，則在背景慢慢載入。這種策略能大幅提升使用者對「網頁載入速度」的感知，減少等待的焦慮感。
崴米的建議
從 GitHub 的優化經驗中，我們為中小企業主與行銷人員整理了三個可以馬上應用的建議：
- 檢視網站的動態內容載入策略：若您的電商網站有大量的商品評論、圖文並茂的商品詳情，或是使用 AI 生成的大量內容，請與工程師討論如何優化這些「高度不確定」元素的渲染方式，避免拖慢整體網頁速度。
- 導入「骨架螢幕」提升感知速度：在資料還在從後端傳輸時，先顯示網頁的結構骨架，讓使用者感覺網頁已經在載入中，這能有效降低跳出率，提升使用者體驗。
- 在專案初期就定義效能指標：在規劃大型網站或 AI 應用時，不要等上線後才處理卡頓問題。提前與開發團隊討論「虛擬化渲染」的應用情境，並設定明確的頁面載入與滑動流暢度指標，從源頭把關網站品質。
