Web前端技術有哪些

本篇內容介紹了“Web前端技術有哪些”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

Web前端技術的范圍

1. 編程語言/技術（HTML，JavaScript，CSS等）

2. 跨瀏覽器兼容性/支持（JS Framework，CSS Library）

3. 網絡傳輸性能（并行下載，帶寬利用率）

4. 瀏覽器渲染時間/性能（TTI即用戶可交互前等待時間，JS執行性能）

個人感覺，Facebook無疑又成為了技術上的明星，在大家還在感慨其對于PHP的重大改進HipHop(Blocked inside China mainland)的時候，今年Facebook又在前端技術方面給大家帶來了驚喜。

Facebook面臨的問題

500M（Million）注冊用戶，50%每天至少訪問一次，用戶平均每日在線時間為5小時25分鐘。帶寬及服務器壓力均很大。

Facebook的解決方案

Quickling

Facebook提出了一個新名詞Ajaxify，顧名思義，就是將傳統的POST/GET轉換為Ajax請求。優點顯而易見，首先減少了不必要的HTML傳輸，只請求和渲染頁面需要更新的部分，這就相應減少了所需傳輸的內容加快了內容送達至用戶的時間。并且也減少了服務端對HTML的不必要的渲染。Facebook也提到了可以減少session的重復load/unload。

使用Ajax也許不是什么新鮮的新聞，大家拒絕這項技術的原因可能很大程度基于SEO的需求。解決方案也很簡單，將Ajax只是作為提高用戶體驗的手段，而不是瀏覽網站必須的方法，即可解決SEO的問題（P.S. Facebook不需要SEO）。

整套方案包括：Link Controller, HistoryManager, BootLoader, Busy Indicator, CSS Unloading, Permanent link support, Resetting timer functions。這些方案本身沒有什么特殊的，大部分都可以顧名思義，需要解釋一下的可能是link controller，其含義是將標準的HTML LINK請求轉換為Ajax請求（通過綁定click事件）。Facebook的可貴之處是提供了這一整套完整的解決方案，***程度上保證了網站的可用性。

效果：

提高了10%-30%的網站傳輸時間，并提高了20%-30%的服務端頁面渲染速度。

使用范圍：

45%的Facebook頁面使用了此項技術。

PageCache

簡單的說，就是將訪問過的頁面緩存在客戶端。但我們知道，作為Facebook這樣交互性很強的網站，需要保障用戶能盡早的獲得更新后的信息，而不是給用戶展示一個毫無意義的過期頁面。

Facebook設計了一個框架來識別一個頁面是否來自于緩存（猜測：頁面***加載完畢后將所有Ajax的Callback和Result緩存在本地。Facebook頁面是基于Ajax獲取頁面內容），若來自于緩存，通過Ajax來更新所需更新的模塊（猜測：通過JavaScript預先定義本頁面所需更新的div Id及對應的callback handler，并在頁面下載時同時下載下來）。

其提到了三種更新類型：增量更新，用戶復寫（例如用戶在頁面上回復了一則評論）及跨頁更新（例如在消息詳細頁面將一則消息標識為已讀，需將首頁的未讀消息數進行更新）。核心思路還是依據Ajax進行更新。具體思路為：

增量更新：只要頁面來自于緩存，即更新所有預定義的需增量更新的模塊。

用戶復寫：通過HistoryManager記錄用戶操作并在cache頁面讀取后重放所有被標記為“replayable”的操作。

跨頁更新：通過服務端Database API發送信號至客戶端將過期緩存標識為invalid（不清楚如何實現。也許是DB端提供一個開放的webservice，客戶端通過Ajax持續訪問此API來獲得此信息）。獲得了緩存過期信號后，通過Ajax更新需要更新的信息。

Facebook順帶提到了一個更新Ajax內容避免頁面變化/閃爍的小技巧，就是先將需更新的地方設置為blank，而非直接更新其內容。

效果：

加速了10倍的網站響應時間并節約了20%的服務端頁面渲染成本。

BigPipe

此項技術通過將頁面分割為各個Pagelets的方式，將整張頁面的獲取/渲染變成了并行的方式（感覺非常像iframe sets，但Facebook使用Ajax實現。）。此項技術是Quickling和PageCache的基石。此技術包含了服務端/客戶端兩方面，在前后端均打破了以往頁面的渲染形式。

實現細節：

Pagelet的Response為JSON格式，包括id,css,js,content,onload等屬性及相應內容，收到后會通過預定義好的JS function來進行渲染。

Pagelet提供的高級功能：Pagelet的繼承，Phased Rendering（猜測：依據規則渲染，也就是依據Pagelet的Response進行渲染），跨Pagelet依賴（數據依賴，顯示依賴，JS依賴）。

BigPipe的三種模式：

◆一次渲染模式：即普通模式，支持搜索引擎，用來支持那些不支持JS的客戶端。

◆管線模式：即并行模式，并行請求，并即時渲染。

◆并行模式：并行請求，但在獲得所有請求的結果后再渲染。

效果：

提高了2倍的頁面響應時間。

擴展閱讀：世界***的PHP站點 Facebook后臺技術探秘

YouTube面臨的問題

每天2Billion的訪問。每分鐘上傳35小時的內容。可YouTube需要即時播放視頻！越快越好。

YouTube解決方案

1. 將JavaScript引用位置從頁首移至頁尾。

2. 直接嵌入Flash Player（YouTube之前使用JS來加載Flash Player）。通過頁尾的JS來判斷客戶端的Flash版本（或不支持Flash），來替換預先嵌入的Flash Player或內容（如果需要的話），用來支持特定的客戶群。

效果：頁面渲染時間從～400ms降低為～200ms。Flash播放時間從～1200ms降低為～1100ms。

3. 預加載視頻連接： 通過使用JavaScript創建Image引用視頻內容來與解析DNS并預開啟一個connection供之后使用。

效果：建立視頻連接的總時間從～260ms降低為～180ms。

4. 提供簡化版：這個很無聊，就是提供一個簡版。

效果：頁面加載時間從～1750ms降低為～1100ms。

5. UIX Widget系統：延遲加載非關鍵內容。其實整段沒什么新意，大部分省略，無非是通過Ajax在頁面渲染完后再來動態加載非關鍵內容。比較特別的是利用JS的事件冒泡，在最上層用一個handler來處理各種事件（優點不詳。。也許只是代碼比較簡潔集中吧），通過CSS來標識和識別對應的handler。

Yahoo Mail

Yahoo如何構建下一代的Mail系統？答案就是通過YUI3。Yahoo的技術絕對是***的，其已經將Web前端技術發展到一個非常成熟的地步，照顧到Web的方方面面（數據壓縮，模塊化，高效CSS，非阻礙式JavaScript加載，靜態內容提供，利用瀏覽器Cache等等），所以也鮮有創新了。某種程度上來說，Facebook的一些所謂創新也不過是后知后覺，Yahoo早已考慮并實現了這些方案，只是也許不是那么有針對性而已。

Baidu

感覺整體傾向于組織結構介紹及一些比較過時的內容。

Taobao

還在討論一些何時使用Ajax，何時不使用的問題。

相反的，淘寶的精益測試倒是引起了我的興趣，出自微軟的淘寶員工鶴云講述了淘寶是如何進行CI（持續集成）的。有一些經驗例如代碼覆蓋率測試也給人一些啟發。

“Web前端技術有哪些”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！