GitHub Copilot App 的工程團隊處理過一個真實案例：某個開源專案的提交請求包含二千二百個檔案、超過一百萬行程式碼改動，還累積了四百多則內嵌審查留言。這類大型重構或搬遷工作往往無法拆成多個提交請求，只能整包送出，導致原本的畫面渲染方式難以負荷，捲動與展開內容時會嚴重卡頓。
團隊把版面高度拆成兩套系統處理：程式碼區塊維持原本精確計算的前綴和方式，留言等高度不可預測的動態區塊則採「先估計、再量測、後修正」策略。量測工作交給一個在捲動停止時才啟動的排程器處理，優先量測畫面內已掛載的區塊，畫面外的內容最多離屏渲染一次，避免每個區塊都掛一個 ResizeObserver 拖慢捲動效能。
為了避免高度修正時畫面跳動，團隊改用「錨點」而非像素座標定位：先記住使用者正在看的行號或區塊，量到新高度後再依身分重新對齊，同時要嚴格分辨是使用者主動捲動還是程式自動捲動，否則修正機制反而會失效。他們也建立了自動化的量測、改善循環，用無頭測試與桌面端自動操作持續追蹤渲染效能與健康狀態。
這則新聞比較偏工程與產品面，不是給剛學程式的孩子的入門教材，但很適合說明一個道理：程式不是寫完能動就好，當使用者的資料量變大（例如很長的清單或很多留言），畫面要怎麼保持流暢也是重要的工程問題，這正是「效能」與「使用者體驗」在軟體開發裡的意義。
開發工具使用者體驗效能優化