瀏覽器分頁：為什麼開太多會卡
換句話說，你以為自己只是「多開了幾個分頁」，但對作業系統而言，可能是多開了十幾個進程、幾十條執行緒。這就是為什麼工作管理員一點開，瀏覽器底下掛著一長串子程序，每個都吃掉幾十到幾百 MB 的記憶體。
為什麼要這樣設計？穩定性與安全性的取捨
你可能會問：既然多進程這麼吃資源，為什麼不乾脆像以前一樣，全部放在同一個進程裡跑就好？答案是穩定性與安全性。早期瀏覽器（例如 IE 時代）就是單進程架構，一個分頁當掉，整個瀏覽器一起關閉，幾十個分頁全部消失，那種痛感很多人還記憶猶新。
多進程架構讓每個分頁變成「可犧牲的單位」：某個分頁 Crash，只會出現「Aw, Snap」的悲傷頁面，其他分頁仍能正常運作。同時，渲染進程被放在沙箱（Sandbox）中執行，無法直接存取系統檔案，大幅降低了惡意網站危害電腦的風險。這是一場典型的工程取捨：用更多的記憶體與進程管理成本，換取更好的穩定性與安全性。而當你開了几十個分頁時，這筆成本就會被放大到非常有感。
二、開太多分頁會卡的第一個兇手：記憶體
如果說多進程架構是「體質」，那記憶體就是「最直接的成本」。分頁一多會卡，最常見的原因就是記憶體被吃光，導致作業系統開始使用硬碟置換空間（Swap），整個系統的反應速度就會像被拉住手煞車一樣。
每個分頁到底吃掉多少記憶體？
這個問題沒有單一答案，因為每個網站的複雜度差異極大。但我們可以給一些具體的參考範圍：
所以，如果你開了 30 個分頁，平均每個 200 MB，那就是 6 GB 的記憶體。這還沒算上 GPU 進程、網路進程、擴充功能與瀏覽器本身的開銷。對於一台只有 8 GB 記憶體的筆電來說，這幾乎就是「直接見底」。
JavaScript 堆積、DOM 樹與圖片快取：記憶體都花在哪？
一個分頁的記憶體占用，大致可以拆成幾個部分：
這也是為什麼「同樣是開分頁」，開十個純文字部落格和開十個 Figma 設計檔，感受會天差地遠。分頁數量只是表象，真正的變數是「每個分頁背後的內容重量」。
記憶體不足時會發生什麼？Swap 與 OOM 的連鎖反應
當實體記憶體（RAM）快用完時，作業系統不會立刻投降，而是會啟動「置換（Swap / Paging）」機制：把暫時用不到的記憶體內容搬到硬碟（或是 macOS 的壓縮記憶體、Windows 的分頁檔）。問題是，硬碟的速度比 RAM 慢上幾個數量級，尤其是傳統硬碟，延遲可能是幾百倍。一旦系統開始頻繁置換，你會明顯感覺到：
切換分頁時畫面先凍結一兩秒，然後才「活過來」。
滑鼠移動不順、打字有延遲、滾動卡頓。
風扇突然高速運轉（因為 CPU 忙著處理置換與壓縮）。
嚴重時，瀏覽器分頁直接顯示「記憶體不足，已重新載入」。
更糟的是，若記憶體壓力持續升高，作業系統的 OOM Killer（Out-of-Memory Killer）可能會強制終止某些進程，這時你可能會看到整個瀏覽器突然關閉，或是某個分頁無預警消失。這不是瀏覽器「壞掉」，而是系統在自救。
記憶體洩漏：那些關不掉的分頁
還有一種情況特別惱人：某些分頁明明閒置很久，記憶體卻持續成長，彷彿自己在「養蚊子」。這通常是記憶體洩漏（Memory Leak）造成的。常見原因包括：
網站註冊了事件監聽器卻沒有移除，導致物件無法被垃圾回收。
JavaScript 定時器（setInterval）持續執行並累積資料。
無限滾動的頁面把舊資料快取起來，卻從不清除。
擴充功能注入的 content script 長時間持有 DOM 參考。
這類分頁即使你沒有在操作，它仍然會慢慢侵蝕記憶體。開得越久、開得越多，整體壓力就越大。這也是為什麼「重開瀏覽器」常常能讓電腦瞬間回春——因為你把那些漏水的進程全部砍掉重練了。
三、CPU 與 GPU：分頁不只吃記憶體，還會搶運算資源
很多人以為分頁卡頓只跟記憶體有關，但其實 CPU 與 GPU 也是關鍵角色。尤其當分頁裡有動畫、影片、即時通訊、廣告輪播時，即使你沒在看那個分頁，它也可能在背景偷偷消耗運算資源。
JavaScript 主執行緒與事件迴圈
每個渲染進程都有一個「主執行緒（Main Thread）」，負責執行 JavaScript、計算樣式、排版與繪製。這個執行緒是單執行緒的，也就是說，同一時間只能做一件事。當某個網站的 JavaScript 執行太久（例如解析大量 JSON、執行複雜迴圈、處理大型影像），主執行緒就會被卡住，使用者感受到的就是「這個分頁 froze 了」。
更麻煩的是，瀏覽器通常會把「同一個網站的多個分頁」放在同一個渲染進程裡。這意味著同站的多個分頁會共用同一個主執行緒。如果你開了五個同一個論壇的分頁，其中一個正在跑重型腳本，其他四個也可能跟著頓。這也是為什麼有時候「關掉某一個分頁」就能讓其他分頁恢復順暢。
背景分頁的隱形負載：計時器、輪播、即時通知
你可能會想：「我明明沒在看那個分頁，它怎麼會吃 CPU？」答案是：很多網站並不在乎你有沒有在看。背景分頁仍然可能執行以下工作：
動畫與影片：有些頁面即使切到背景，影片仍繼續播放或預載。
廣告與追蹤腳本：持續回報使用者行為、載入新廣告素材。
為了解決這個問題，現代瀏覽器會對背景分頁進行「節流（Throttling）」：例如把背景分頁的計時器最小間隔拉長到 1 秒甚至更久、暫停 requestAnimationFrame、降低影格更新頻率。但節流只是「減緩」，不是「消除」。只要分頁還活著，它就仍然握有一定的 CPU 與記憶體資源。
GPU 合成與硬體加速的雙面刃
現代瀏覽器大量使用 GPU 來進行網頁合成（Compositing）：把頁面拆成多個圖層，交給 GPU 快速疊合、捲動、播放動畫。這讓捲動更滑順、影片更省電，但也帶來新的成本：每個分頁的圖層都會占用 GPU 記憶體（VRAM）與繪製指令佇列。
當你開了几十個分頁，等於有几十組圖層要管理。GPU 進程需要記住每個分頁的紋理、陰影、濾鏡效果，甚至連看不到的分頁也可能保留部分資源。對於內建顯示晶片（內顯）的筆電來說，VRAM 是與系統記憶體共用的，這又會回頭壓縮主記憶體。這就是為什麼有些人的電腦「記憶體明明還有剩」，但切換分頁就是有一種說不出的黏滯感——問題可能出在 GPU 資源與合成管線。
此外，硬體加速在某些驅動程式不相容的情況下，反而會造成畫面撕裂、閃爍或卡頓。這也是瀏覽器設定中永遠保留「關閉硬體加速」選項的原因。
四、分頁管理機制：瀏覽器其實一直在幫你「踩煞車」
看到這裡，你可能會覺得瀏覽器好像只會吃資源。其實不然，現代瀏覽器為了避免使用者「開到死」，內建了相當多分頁管理機制。這些機制默默在你背後運作，有時你會覺得分頁「怪怪的」，其實是它們在保護你的電腦。
分頁凍結（Tab Freezing）與丟棄（Tab Discarding）
這是兩個不同層次的機制，但經常被混為一談：
這兩種機制通常會在系統記憶體壓力升高、或分頁閒置一段時間後自動觸發。以 Chrome 為例，早期的「Tab Discarding」會在記憶體不足時自動丟棄最久未使用的分頁；後來演進為「Memory Saver」模式，讓使用者可以設定哪些網站永遠保持活躍、哪些可以自動休眠。
各家瀏覽器的實作差異
不同瀏覽器對分頁管理的策略不太一樣：
這些機制的共同目標都是：在「使用者可能隨時切回來」與「系統資源有限」之間取得平衡。但沒有一個機制是完美的，因為瀏覽器無法預測你下一秒會點哪個分頁。
為什麼有些分頁「叫不醒」？
你可能遇過這種情況：切回某個很久沒看的分頁，畫面一片空白，然後才慢慢重新載入；或是表單內容不見了、影片要重新緩衝。這就是分頁被丟棄後重新載入的結果。對使用者來說，這確實有點惱人，但從資源管理的角度來看，這是必要的取捨。
如果你希望某些分頁永遠保持活躍（例如正在聽的音樂、正在跑的監控儀表板），可以在瀏覽器設定中把該網站加入「永不休眠」的清單。但要注意，每一個被豁免的分頁，都是一份長期占用的資源。豁免太多，等於讓分頁管理機制形同虛設。
五、擴充功能與網站本身：放大分頁成本的隱形推手
除了瀏覽器核心與網頁內容，還有兩個經常被忽略的因素：擴充功能（Extensions）與網站本身的設計品質。它們就像是分頁成本的「乘數」，會讓原本還過得去的資源用量瞬間失控。
擴充功能如何放大分頁成本
每一個擴充功能，尤其是會注入 content script 的那種，都可能在每一個分頁裡執行額外的 JavaScript。想想看：如果你裝了廣告阻擋、密碼管理、翻譯、截圖、筆記、比價、VPN 等十個擴充功能，而每個擴充功能都在每個分頁注入腳本，那你開 30 個分頁，就等於執行了 300 份額外的腳本。
更別提有些擴充功能本身寫得不好，會持續監聽 DOM 變化、攔截網路請求、或保留大量資料在記憶體中。這些成本不會顯示在單一分頁的記憶體用量裡，而是分散在瀏覽器主進程與各個渲染進程中，讓你很難察覺。如果你發現瀏覽器在「無痕模式」下明顯順暢，那問題很可能就出在擴充功能。
廣告、追蹤器與重型前端框架
現代網站的「肥胖化」也是分頁卡頓的重要元凶。一個看似簡單的新聞頁面，背後可能載入：
多個廣告聯播網的腳本與素材。
Google Analytics、Meta Pixel、及各類追蹤器。
客服聊天機器人、社群分享按鈕。
字型檔、圖示庫、CSS 框架、JavaScript 框架。
自動播放的影片與高解析度圖片。
這些東西單獨看都不算多，但當你同時開十几二十個這樣的網站，它們加起來的記憶體與 CPU 消耗就非常可觀。這也是為什麼「安裝一個好的廣告阻擋器」往往能明顯改善分頁過多的卡頓——因為你直接砍掉了很大一部分的隱形負載。
單頁應用程式（SPA）的隱形成本
現代很多網站採用 SPA 架構（例如 Gmail、Notion、Twitter/X、Figma）。這類網站的好處是切換頁面不用重新載入，體驗流暢；但缺點是整個應用程式的狀態會一直留在記憶體中，而且隨著你使用時間越長，累積的資料、快取、事件監聽器也越多。
換句話說，一個開了一整天的 SPA 分頁，其記憶體用量可能是剛開啟時的好幾倍。如果你同時開了好几個這類重型 Web App，再加上几十個一般分頁，那記憶體壓力自然爆表。SPA 分頁的「年齡」往往比「數量」更關鍵。
六、不同瀏覽器的策略差異：沒有一套架構適合所有人
雖然多進程架構已成為主流，但各家瀏覽器在實作細節與資源管理策略上仍有明顯差異。了解這些差異，有助於你選擇適合自己使用習慣的瀏覽器。
Chrome / Edge：功能完整但資源大戶
Chromium 系列擁有最完整的多進程架構與站點隔離，穩定性與安全性都很高，但代價就是記憶體用量偏大。Edge 在這基礎上加入了「睡眠分頁（Sleeping Tabs）」與「效率模式」，對記憶體與 CPU 的管理比 Chrome 稍積極一些。整體來說，這兩個瀏覽器適合記憶體充足（16 GB 以上）的使用者，並且建議搭配分頁管理擴充功能或內建的記憶體節省模式。
Firefox：內容進程與 Fission 的平衡
Firefox 同樣採用多進程架構，並透過「Fission」實現站點隔離。它的記憶體管理策略通常被認為比 Chrome 溫和一些，尤其在大量分頁的情境下，Firefox 有時能展現較好的記憶體效率。不過實際表現會因版本、作業系統與使用情境而異，建議依照自己的實際體驗來選擇。
Safari：省電與記憶體效率優先
Safari 在 macOS 與 iOS 上採取非常積極的資源管理策略，背景分頁經常被凍結，記憶體也會被壓縮或釋放。這讓 Safari 在筆電上通常有更好的電池續航，但代價是分頁切換時偶爾需要重新載入。對於 Apple 生態系使用者來說，Safari 往往是「開很多分頁但不想風扇狂轉」的實用選擇。
七、實用建議：如何開很多分頁又不卡？
理解原理之後，接下來要談的是「怎麼做」。以下從設定調校、使用習慣與硬體升級三個面向，給你具體可執行的建議。
瀏覽器設定調校
分頁管理習慣與工具
硬體升級的優先順序
如果你經常需要開大量分頁，與其盲目升級，不如把錢花在刀口上：
八、結論：分頁數量不是絕對，資源管理才是關鍵
回到最初的問題：「為什麼瀏覽器開太多分頁會卡？」答案其實是多層次的：多進程架構讓每個分頁都有獨立成本，記憶體與 CPU 是主要負擔，GPU 與擴充功能是隱形推手，而瀏覽器的分頁管理機制則是在背後幫你踩煞車。
分頁數量本身不是罪惡，真正的問題是「每個分頁背後的資源重量」與「你如何使用它們」。一個開了一整天的重型 Web App，可能比二十個靜態文章分頁還要吃資源；十個會自動更新、播放影片、載入廣告的分頁，可能比三十個純文字頁面更拖垮電腦。
所以，與其死守「最多開幾個分頁」的數字，不如建立幾個好習慣：定期整理分頁、關閉不用的擴充功能、開啟記憶體節省模式、把「待會再看」的頁面交給書籤或稍後閱讀工具，並在硬體允許的範圍內使用瀏覽器。當你理解背後的原理，就能做出更聰明的選擇，讓瀏覽器成為效率工具，而不是拖慢電腦的元凶。
下次當你看到分頁列又擠成一團時，不妨想想這篇文章提到的架構與機制。你會發現，那個小小的「X」按鈕，其實是你電腦效能最直接的守門員。