先想像這個小場景：快到約好的集合時間，手機只剩一點空檔，某人打開平常熟得不能再熟的網站。手指正要照老路線按下按鈕，卻發現字換行了、位置偏了一點，原本一下就能完成的動作突然需要重新找。
「欸，昨天明明就在這裡啊。」
這句假想抱怨，大概比任何架構圖都更能說明使用者在意什麼。網站後面可以換很多東西，使用者眼前卻只有現在這個畫面，以及一件想趕快完成的小事。技術改版如果不小心打斷那個節奏，就算內部整理得再漂亮，感受也會先卡一下。
因此，有一種工程成果特別安靜：事情明明做了不少，打開網站的人卻一路順順用完，甚至沒發現背後正在搬家。這種「好像沒發生什麼」的日常，反而很值得拉近鏡頭看看。
你每天打開同一個網站，通常不會在意按鈕的樣式是怎麼寫的。但如果某天文字被擠出框外、選單間距忽然改變，你很快就會注意到。對維護網站的人來說，換掉底層樣式架構，卻讓大家照常使用，是一項很實際的考驗。
GitHub 的 Primer 設計系統就面對這個問題。GitHub 在 2026 年 9 月 25 日發布的文章中，說明從 CSS-in-JS 遷移到 CSS Modules 的做法：採取漸進方式，新增翻譯檔案，以功能旗幟切換樣式，並用視覺回歸測試，來維持既有使用者體驗。[S1]
想成圖書館搬書，事情就有畫面了
假設有一間照常開放的圖書館，館員想把後台的整理方式換掉。讀者還是要找書、借書、坐在熟悉的位置讀幾頁。書不能全堆到走道，再貼張紙說「最近比較忙，請自由發揮」。整理計畫得顧到正在使用空間的人。
網站的樣式架構遷移，也可以借這個畫面來理解。讀者看見的是書架與指示牌，館員還得照顧分類、標記以及每次新書進來要放哪裡。共用的規則整理得越清楚，後續的人越容易延續同一套做法。
但「搬完」只是工程端的一個節點。對讀者而言，真正有感的是熟悉的書能不能找到、指示是不是前後一致，以及借書動線有沒有忽然變得很繞。換到網站上，就是介面呈現與操作習慣能否順順接上。
這個比喻還有一個好處：它讓人自然想起過渡期。圖書館可以先整理一區，確認標記沒亂，再繼續下一區。每一步都留得出檢查空間，遇到疑問時，也比較容易知道該回頭看哪一排。
先理解改動發生在哪裡
把設計系統想成一組網站共用的介面零件，會比較好理解這次改動。讀者看得到按鈕、文字與各種區塊，工程團隊則要維護它們背後的樣式規則。當共用規則改變，需要關心的範圍也會超過單一畫面。
依官方說明，CSS Modules 讓開發者把樣式寫在與 JavaScript 原始碼並存的 CSS 檔案中，並預設將類別名稱限制在局部範圍，降低全域選擇器衝突的風險。[S1] 可以想像，不同介面都想使用同一個簡短名稱；局部化的用意，就是避免名稱相同時，樣式意外影響到別處。
對一般使用者而言，這類改動很難直接看見。也正因如此，判斷遷移是否成功，不能只停在程式碼換了什麼格式。還要追問：熟悉的介面是否維持原來的呈現？團隊有沒有辦法及早發現差異？新架構帶來的好處，是否足以支撐轉換成本？
假想小劇場：書架換好了，讀者找得到嗎
接著來一段虛構的圖書館會議，把工程問題換成日常語言。
小禾：「新分類整理好了，標籤也貼完了。」
阿沐：「那常來的讀者還找得到原本那排書嗎？」
小禾：「分類邏輯變得很整齊耶。」
阿沐：「可是入口的箭頭還指向舊位置。」
小禾：「好，先去走一次讀者路線。」
這個小劇場裡，沒有人真的反對整理。只是「內部更好維護」和「外面更好使用」需要有人幫忙接起來。網站換樣式寫法時也可以這樣問：這次改動，對正在使用的人會出現什麼差異？哪些差異是預期的，哪些需要再看一下？
問題如果夠清楚，就不必用「感覺有點怪」來回拉扯。譬如原本同一列的文字現在換行了，先確認是不是本來就要調整；若不是，再找出影響它的規則。把怪怪的感覺描述成可比對的現象，大家討論起來會省力很多。
把一次大切換拆成可檢查的步驟
官方提到的漸進策略，包含翻譯檔案、功能旗幟與視覺回歸測試三種做法。[S1] 從這組安排可以推論，團隊重視的是過渡期間如何比較與切換，而非僅僅完成檔案改寫。這個思路也讓工程決策更容易討論：每次先處理一部分，確認結果，再決定要不要往下一步走。
功能旗幟可以理解成控制某項功能或行為是否啟用的開關。在這次官方描述中，它用來切換樣式。[S1] 這讓「新的樣式已經寫好」和「開始使用新的樣式」可以分開考慮。若要借用這個思路，團隊應先想清楚切換的單位與檢查方式，才能知道每次改動究竟影響哪裡。
視覺回歸測試關心的，則是修改前後的畫面差異。假設元件的文字長度、留白或位置改變，透過前後比較，就能把需要檢查的地方指出來。GitHub 將這類測試納入遷移策略，是官方說明的一部分。[S1] 借用這種方法時，也要先列出值得比較的畫面與狀態，並決定由誰判斷差異是否符合預期。
因此，這個案例對其他團隊較有參考價值的地方，是把「能否改造」拆成「能否逐步確認改造結果」。採用類似方法時，可以先選擇範圍明確的元件，列出需要維持的呈現，再檢查切換前後的差異。這是依案例提出的實務建議。範圍越清楚，發現問題時就越容易回到對應的改動，減少在大量元件之間來回尋找的負擔。
工具冷知識：最不起眼的「名字」也會惹事
CSS Modules 有個容易被一眼滑過去的重點：類別名稱預設是局部化的。[S1] 聽起來像文件裡的小字，但想像每個閱讀區都有一張叫「注意事項」的卡片，就會懂它為什麼實用。兒童區與自修區可以用一樣的標題，不代表內容應該互相套用。
把這個比喻放回樣式，就是讓名稱有自己的適用範圍。官方說明將預防全域選擇器衝突列為這種做法的用途。[S1] 名字本身可以很普通，重要的是使用時知道它屬於哪裡。像叫一聲「組長」之前，最好先看清楚現在是哪個小組在開會。
另一個小細節，是 CSS Modules 讓 CSS 檔案與 JavaScript 原始碼並存。[S1] 所以讀到「換成 CSS Modules」，可以先把注意力放在樣式怎麼安排、名稱怎麼管理。這樣比較容易對上實際改動，不會被一堆縮寫推著走，最後只記得某個聽起來很新的名詞。
還有一個容易誤會的字是「旗幟」。功能旗幟在這次描述裡負責切換樣式。[S1] 不必真的想像畫面上插了一面旗子，把它當成決定採用哪套行為的控制開關，就好懂很多。準備完成與正式切換分成不同步驟，過渡期就多了一個可以討論與檢查的節點。
常見誤會，先把腦中的快轉鍵鬆開
第一個容易出現的誤會是：「換寫法，畫面應該也要跟著大改吧？」這個案例關心的恰好是遷移時維持既有使用者體驗。[S1] 就像圖書館更新分類作業，讀者未必需要一起學一套新找書方式。內部整理可以有自己的目標，外部的熟悉感也值得被保留下來。
第二個想法是：「兩張截圖看起來差不多，應該就沒事了。」可以再多走一步，替畫面換個情境。字變長時怎麼辦？內容很少時怎麼辦？使用者想靠鍵盤操作時，又會遇到什麼？把情境寫出來，討論就會從一張漂亮的靜態畫面，往真正的使用過程靠近。
第三個快轉結論是：「大公司採用這個，其他團隊照抄就好。」比較實用的做法，是先抄它提出問題的方式：怎麼分批、怎麼切換、怎麼比較。至於要不要搬到同一套寫法，仍然可以回到自己的產品規模、日常修改方式與維護負擔來看。
還有一個很有誘惑力的想法：「既然都要動了，順便整個重畫吧。」若把架構遷移和介面大改同時塞進一批工作，討論差異時可能更難分清原因。規劃自己的專案時，可以先把目標寫開，決定哪些變化必須發生、哪些先留到後面。把待辦分清楚，常常比把待辦堆滿更有進度感。
畫面穩定只是其中一項證據
視覺測試有明確用途，但畫面看起來相同，仍不足以回答所有使用體驗問題。例如，鍵盤操作是否順暢、不同內容長度能否正常顯示，都可以列入團隊自己的驗證清單。把檢查項目連回實際使用情境，才容易說清楚，某個差異只是外觀調整，還是已經影響使用者完成工作。
效能也是值得追蹤的問題。GitHub 的文章以提升網站效能為題。[S1] 對考慮類似遷移的團隊而言，可以先選定代表性的頁面與量測方式，再比較切換前後的結果。這樣一來，架構選擇便能連回產品真正關心的體驗，也比較容易決定後續要投入多少力氣。
若要問哪些新資料會改變對遷移的判斷，可以看三件具體的事：前後效能是否改善、介面問題是否更容易被發現，以及後續維護花多少時間。短期順利完成切換，和半年後依然容易修改，值得分別記錄。兩者一起看，才能理解轉換的代價與成果。
此外，導入新寫法之後，開發者能否看懂既有規則，也是一個實際問題。其他團隊若要跟進，可以觀察新增元件時需要查多少文件、是否反覆遇到相同疑問，並把答案補回範例。這類日常工作往往更能反映架構是否容易維護。
大型設計系統值得追問的問題，於是變得很具體：這套過渡方法能否讓問題更早被發現？往後新增元件，是否更容易維持一致？當這些答案逐漸清楚，其他團隊才有足夠依據，判斷哪些做法適合自己的產品。
週末小練習：用紙卡玩一次介面搬家
這個練習只需要紙、筆，或任何能排字的空白文件。先做一張想像中的活動卡片，上面放標題、日期與一個「查看詳情」按鈕。不用寫程式，也不用登入任何網站。這張卡片就是迷你版的共用元件。
接著複製幾張，把內容換掉。一張標題很短，一張故意很長；一張日期寫得簡單，一張加上較完整的時間資訊。先把每張卡原來的樣子留好，當成之後比對的參考。這時就會發現，同一個版型遇到不同內容，注意的地方可以完全不同。
現在挑一條規則來改，例如按鈕和文字之間的距離。每次只改一項，然後把前後版本放在一起看。哪張卡仍然順眼？哪張開始擠？「這個改動影響什麼」突然就有了具體答案，不再只是一句「版型有微調」。
再加一個小挑戰：把其中一張卡想像成手機上比較窄的區塊，試著重新排列內容。重要資訊還找得到嗎？按鈕的文字有沒有變得很難讀？這些提問的目的，是練習替使用情境留位置，並不需要做出一份漂亮到能直接交稿的設計。
最後，找另一個人只看前後兩組卡片，請對方說出哪裡不同。若對方說「感覺怪怪的」，就請他指向具體的位置。把答案記成一條能操作的描述，例如「長標題把按鈕擠到下一行」。這份清楚的描述，比十句「再修一下」更容易讓下一次修改對準問題。
練完之後，還可以替這組卡片留一張小規則卡：哪些距離固定、哪些內容可以換行、遇到長文字時先檢查哪裡。當另一個人能照著規則做出相近的結果，設計系統「讓不同人維持一致」的用途，就會變得很有感。
後記：最好用的改版，有時真的很安靜
想像那間圖書館整理完一區，讀者照樣沿著熟悉的路找到書，館員也比較容易處理新進的資料。沒有特別華麗的開幕音效，日常卻少了一點卡住的地方。網站架構的調整，也可以用這樣平實的畫面來期待。
Primer 這個案例最適合帶走的閱讀方式，是沿著切換前後去看：規則怎麼整理？差異怎麼被發現？使用中的人要不要重新適應？當這些問題有人照顧，技術名詞就能連回每天真的會發生的小動作。
下次看見一個按鈕還乖乖待在原位，可以順手想起後面的搬書工程。畫面上沒有驚喜，有時就是一次很認真的整理成果。讓人少找一下、少停一下，也是一種值得留下來的進步。
來源
- [S1] Improving site performance by shipping more CSS｜GitHub Blog｜發布：2026-09-25T15:00:00+00:00｜擷取：2026-09-26T00:02:04.055040+00:00｜https://github.blog/engineering/architecture-optimization/improving-site-performance-by-shipping-more-css
留言（0）
還沒有留言。讀完有想法，歡迎留下第一則。