從 GitHub 實戰案例看網站速度優化：為什麼改寫程式碼能讓網頁快那麼多？

為什麼網站會越做越慢？從 GitHub 的痛點說起

當您的企業官網或電商網站流量越來越大時，有沒有發現網頁打開的速度變慢了？這往往是因為底層程式碼的「技術債」累積所致。全球知名的開發者平台 GitHub 就曾面臨這個痛點。隨著網站功能與元件數量爆炸性成長，他們原本使用的 CSS-in-JS（一種把網頁外觀樣式跟邏輯程式碼混在一起寫的技術）開始嚴重拖慢網站速度，導致初次載入時間變長、伺服器運算效能下降。

對中小企業主來說，這就像是在一間原本只有兩層樓的辦公室裡，硬塞進了十層樓的家具，雖然東西都在，但動線變得非常卡。如果不從源頭解決，網站速度只會越來越慢，最終流失沒有耐心等候的顧客。

解法：把樣式獨立出來，並用「功能開關」安全升級

為了徹底解決這個問題，GitHub 的工程團隊決定放棄原本的寫法，改用 CSS Modules（一種把樣式獨立成專屬檔案，避免程式碼互相干擾的寫法）。這種做法讓網頁樣式可以直接附在 HTML 中發送，不需要再經過額外的程式運算，大幅減輕了伺服器的負擔。

但要把整個網站的底層架構換掉，風險極高。萬一改版後網站壞掉怎麼辦？GitHub 採用了漸進式遷移策略，並大量使用 Feature flags（一種可以控制新功能只對部分使用者開放的機制）。這就像是電燈的開關，新版的樣式先只對內部員工開放，確認沒有問題後，再慢慢擴大到所有使用者。這種做法確保了網站在升級期間，依然能正常運作，不會中斷現有服務。

經過這番調整，GitHub 取得了顯著的成果：伺服器端渲染頁面的時間減少了 55%，網頁元件的初始化時間也減少了 25%。這意味著顧客能更快速地看到完整的網頁內容。

AI 神隊友登場：讓原本半年的工作在三週內完成

在解決了核心元件的問題後，GitHub 還面臨另一個挑戰：網站中還有數千處使用了 sx prop（一種在程式碼中直接寫入樣式的快捷寫法）的地方需要逐一修改。這是一項極度繁瑣且耗時的工作。

這時，AI 工具成為了破局的關鍵。GitHub 引入了 Copilot（AI 寫程式助手）來協助工程師。原本需要 8 位工程師花 6 個月才能完成的數千個修改，在 AI 助手的強大程式碼轉換能力下，最後僅由 2 位工程師在 3 週內就將剩餘的修改全部清零。這不僅證明了 AI 在處理重複性高、規則明確的技術任務時具有極高效率，也為企業未來導入 AI 工具提供了極佳的範例。

崴米的建議

從 GitHub 的實戰案例中，我們可以學到網站效能優化不僅僅是壓縮圖片，底層架構的選擇與升級同樣重要。針對中小企業主與行銷人員，崴米提供以下三點建議：

• 定期檢視網站速度，不要等客人流失才發現：網站速度直接影響轉換率。在決定大動干戈進行大改版前，建議先使用免費網站健檢，了解目前網站的手機版、速度與搜尋引擎基本設定狀況，找出最迫切的痛點。
• 要求團隊做好風險控管，確保升級不中斷服務：當您的網站需要進行底層技術升級或大幅改版時，請務必確認開發團隊有完善的測試與上線機制，確保顧客在升級期間依然能順暢瀏覽與下單，避免面臨效能崩潰的風險。
• 主動優化網站速度，把體感分數拉回來：網站速度是顧客體驗的第一關。如果您發現網站打開很慢，或者在健檢後發現速度分數不及格，可以考慮透過我們的網站速度優化服務，從底層架構到前端呈現，把分數和客人的體感一起拉回來。

參考來源：Improving site performance by shipping more CSS