今天來做一個比較簡單的分享，也是很多在做 B 端項目的同學發(fā)出過的疑問，那就是既然瀏覽器中可以使用頁面標簽，那為什么在項目中還需要使用這個組件和交互框架的形式。

更多B端干貨：

網(wǎng)頁中的頁面標簽認識

頁面標簽是用來反應(yīng)系統(tǒng)中已打開的頁面的標識，最常見于瀏覽器頂部，每當我們新建一個頁面，就會創(chuàng)建一個新的標簽。我們不僅可以通過它來判斷打開了多少頁面，也可以用通過點擊它們來切換當前聚焦的頁面或關(guān)閉頁面。

當然，除了瀏覽器外，還有很多其它的軟件也熱衷于使用頁面標簽組件，如我們常用的設(shè)計軟件、辦公軟件和通訊軟件。

以軟件層面來說，頁面標簽的使用可以說非常的普及，但是在網(wǎng)站的系統(tǒng)中，這個組件普及度并不高，第一個能想到的應(yīng)該就是郵箱系統(tǒng)了。

而日常會接觸到的 B 端 SAAS 工具里，也很少會用到這個組件。想必大家都能理解背后的原因，因為網(wǎng)站系統(tǒng)也需要瀏覽器訪問，瀏覽器自帶了頁面標簽，直接使用瀏覽器的標簽不就行了！

所以問題來了，為什么在網(wǎng)站頁面里再做一個頁面標簽組件？這就要先從頁面標簽組件出現(xiàn)的過程說起了，在上古時期……

全球使用最廣泛的瀏覽器當然是非 Windows 的 IE ( Internet Explorer) 瀏覽器莫屬。這個瀏覽器是 Windows 系統(tǒng)捆綁自帶的瀏覽器，從 1995 年上線，在短短幾年間成功成為全球開發(fā)者最痛恨的瀏覽器，阻礙整個互聯(lián)網(wǎng)發(fā)展的腳步，茍活到 2022 年 6 月 15 日 21:00 正式停止更新（普天同慶）。

IE 不僅本身的引擎內(nèi)核一般，而且和 Windows 捆綁的特性而獲取的龐大用戶體量，成為所有網(wǎng)頁新技術(shù)普及的最大阻力。因為絕大多數(shù)網(wǎng)站開發(fā)，都不可能忽視這個群體，就需要花費大量的精力去適配稀爛的老版 IE。

比如在 2010 年以前做網(wǎng)站的時候，如果想要使用已經(jīng)發(fā)布很多年的 CSS 來做樣式，你就要首先解決怎么在 Windows 2000 和 XP 默認安裝的 IE5、6 能正常顯示（對 CSS 支持極差），它們是所有網(wǎng)頁前端和設(shè)計師的噩夢。

而早期 IE 還有個很重要的缺陷，就是它們本身是沒有頁面標簽欄的，Windows 會將打開的軟件窗口顯示在底部欄中，如果打開的頁面較多，則會進行折疊，通過點擊折疊菜單后展開。

這是一個非常低效的操作方法，因為當時的顯示器普遍在 1280 或 1440 寬，一旦打開網(wǎng)頁稍多，展開的菜單就不夠放，選擇之前打開的網(wǎng)頁就很麻煩。

不是沒有人沒注意到這個問題，現(xiàn)代瀏覽器的先驅(qū) Oprea，在 1995 年發(fā)布上線后就首個支持多窗口文檔模式（頁面標簽前身，如下圖版本形式）。但這個優(yōu)秀的交互因為軟件本身的普及度不夠高，無法代表真正的用戶使用場景。

于是，逐漸興起的網(wǎng)頁管理系統(tǒng)（從本地軟件轉(zhuǎn)移到瀏覽器訪問），就開始繼承并普及這個交互框架，通過在一個類似軟件的頁面中，以標簽的形式打開站內(nèi)的新頁面，而不用讓瀏覽器窗口被折疊起來，提升交互的效率。

這有一定的主觀成分，我也不能確定是哪個歐美管理系統(tǒng)最先使用這個交互框架，但從最早期了解到和自己項目的實際情況分析，這是產(chǎn)生最關(guān)鍵影響的因素。

當然，它也不是僅僅具備這一個優(yōu)點而已，它還同時包含另一個優(yōu)點 —— 提升加載效率。

正常加載一個網(wǎng)頁，就是客戶端向服務(wù)器獲取相關(guān)文本代碼和外部資源的過程，代碼即服務(wù)器返回的 HTML、CSS、JS 等代碼，外部資源即圖片音視頻等文件。

理論上每打開一個頁面，你就需要重新和服務(wù)器獲取一遍這些內(nèi)容，雖然存在緩存的優(yōu)化機制，但不管怎么優(yōu)化，還是會產(chǎn)生很多額外的請求和資源的重復(fù)加載。而頁面標簽的這種模式，就可以避免大量的重復(fù)請求和加載，提升頁面核心內(nèi)容的打開效率。

看過 HTML 課程的話，都應(yīng)該知道一個標準的 HTML 文檔必然會包含 、 兩個標簽。其中 head 標簽的內(nèi)容是不可見的，而且包含很多需要預(yù)加載的引用文件，本身就能消耗很多帶寬資源。

而在 body 部分中，全局組件等模塊也無需重新加載，只需要將全部重心放在對應(yīng)頁面的內(nèi)容區(qū)域即可，可能加載數(shù)據(jù)量僅為原先的一半，這對撥號上網(wǎng)的年代來講是具體的減負。

除此之外，在高頻切換頁面的使用場景中，就可以減少很多白底背景和視覺界面交替出現(xiàn)的 “閃爍感”，這是一種非常折磨人的過程，只有大量使用 SAAS 服務(wù)的同學才能感同身受。

這些優(yōu)勢雖然都很明顯，但它們主要是建立在過去的技術(shù)條件和背景上的。隨著時代發(fā)展，IE 的消亡，瀏覽器普遍自帶頁面標簽，網(wǎng)速提升數(shù)十倍，這些優(yōu)勢就變得越來越小，而缺點則越來越明顯。

那就是網(wǎng)頁內(nèi)的頁面標簽會很容易和瀏覽器中標簽 “打架”，它不僅會占用本就不多的窗口高度，還在樣式和操作上都和瀏覽器標簽很像，導(dǎo)致識別內(nèi)容效率很難提升。更要命的是，網(wǎng)頁里做的頁面標簽操作體驗和瀏覽器的可沒法比……

所以今天的 B 端系統(tǒng)中，使用這個組件的項目越來越少，雖然不是消亡，但它確實已經(jīng)完成了自己的主要歷史使命。

那到底在今天它還有什么存在的場景和價值呢？

這個我很難給出統(tǒng)一的答案，可以肯定的是，其中有一部分設(shè)計被老板和甲方強制要求添加頁面標簽，是基于過去的習慣出發(fā)，僅僅是 “路徑依賴”。

而其它原因，到底是項目需要提升加載的效率，如網(wǎng)絡(luò)很差，頁面數(shù)據(jù)量太龐大，還是不新建頁面的模式能帶來更好的操作連貫性，如深色背景但新建頁面是白色，就需要自己去探尋，找到合適的理由了。

所以，針對頁面標簽組件的使用建議，就是：

如果找不到明確的理由，就不放！如果別人讓你放且說不出理由，那就是他們的偏執(zhí)，沒有爭論的必要。職位比你高就做，沒你高就拒絕。

結(jié)尾

以上就是關(guān)于頁面標簽的分享，如果有什么其它的看法，或者有應(yīng)用頁面標簽的優(yōu)秀 SAAS 案例，也可以在下方留言。

我們下篇再賤～

歡迎關(guān)注作者的微信公眾號：「超人的電話亭」