百度技術沙龍第82期 百度Web前端開發實戰案例解析

本文做者:HelloDeveloperhtml

10 月 27 日,82 期百度技術沙龍,邀請了數位百度前端技術部 Web 前端資深研發工程師,從 Web 前端技術出發,經過五個主題,立足如今面向將來,由內到外地分享百度在搜索組件化的探索、搜索體驗加強、開放 Web 速度優化及開放 Web 將來發展發麪的技術沉澱和積累。前端

1ios

搜索組件化探索與實踐shell

首先進行分享的是百度前端技術部資深研發工程師陳驍帶來的《搜索組件化的探索與實踐》。json

爲何搜索要作組件化?axios

據陳驍介紹,最開始的百度搜索移動端的前端架構是從 PC 時代遷移過來,服務器端使用 Smarty 來渲染模版,實現先後端分離。前端使用 Zepto 來完成交互邏輯,可是它的擴展性比較有限,難以實現對 HTML、CSS 代碼的組件化管理,隨着移動端的交互形式愈來愈複雜,本來的方案出現了局限性。後端

因而,組件化應運而生。組件化是把一些可複用的單元提取出來,經過對幾個組件的管理,實現對整個搜索結果頁樣式的控制,提升開發的效率和橫向團隊總體升級的效率。跨域

目前百度已經有了很是多的組件化解決方案,包括 Lavas 和 Reac t。能夠具體到組件語法、基礎框架以及同構區塊。瀏覽器

以下圖所示,組件語法包括四部分:緩存

Template:組件代理結構

瀏覽器端:組件前端邏輯

Style:前端樣式

Config:同構邏輯

 

前三部分基本可以覆蓋組件的經常使用語法,而同構在服務器端和瀏覽器端都能執行,主要有 props、data、components、computed 等。

那麼這個組件代碼怎麼在線上跑起來呢?

首先會在線下經過編譯器,把它編譯成 PHP、JavaScript 兩份原碼。PHP 的編譯產物徹底使用 PHP 的語法,能夠在後端造成一個 Server Runtime,在這個過程當中,也可以把 PHP 的編譯產物渲染成字符串,經過網絡傳輸到瀏覽器端。而在瀏覽器端運行時能夠用編碼產物 Javascript 的組件,渲染成可操做的 HTML 代理結構,包括它的事件和交互。

其中的難點在於怎麼把一個組件代碼編譯成在 PHP、在 JS 都能跑的組件代碼。百度會作對於模板和一些表達設計的處理。例如,模板代碼有一個文本節點,有一個自定義組件,在編譯的過程當中,會利用編譯器把它轉化成抽象語法樹,造成樹的結構,每一個節點都有一些屬性和信息,利用語法樹的結構和屬性信息,就能夠經過代碼生成器分別生成 PHP 和 JS 的代碼。

 

這裏還有一個問題,爲何須要一個同構區塊呢?這是由於同構區塊能夠很好控制服務器端能執行的代碼,方便語法解析。另外,百度對同構代碼塊進行語法限制,以保證服務器端的穩定性,也能夠更加方便解析成想要的 PHP 代碼。

經過改造,組件化渲染框架不只可使得效率提高,保證了體驗一致性,並且進行了橫向升級下降成本。

性能優化

針對服務器端的渲染性能,百度作了很是細緻的優化:

在框架層,對渲染流程進行了簡化,添加了緩存;

在基礎組件層,對控制的簡單組件進行編譯優化;

在業務層,提供先驗工具、准入規範,線上監控和報警,並提供 a-nossr 指令。

那麼組件是如何在服務器端渲染成想要的 HTML 字符串呢?

以下圖所示,會通過如下步驟:首先,加載組件的配置,建立組件的實例。在實例的建立過程當中,對這個組件全部的數據進行初始化,包括一些特徵和計算屬性,獲得初始化狀態之後,再渲染出虛擬 DOM 樹,把整個組件節點數渲染成一個實例的形式,用虛擬 DOM 樹渲染成 HTML 字符串。

 

與此同時,百度搜索對整個渲染的過程進行了簡化。在框架層,經過建立虛擬 DOM,減小了一次遞歸,也減小了在線上運行時的邏輯。在基礎組件層,百度對橫向團隊可以徹底控制的一些簡單組件進行了優化。利用 HTML 編譯器編譯成語法樹,語法樹對它每個 AST 節點進行優化,經過將 Tag 直接定義爲普通的 DOM 節點的方法,生成最後想要的函數代碼。

 

框架層:渲染流程簡化

 

簡單組件編譯優化

目前進展

目前,百度提供搜索組件化的工具。好比搜索 Web 無障礙規劃、搜索性能准入規範、搜索設計規範;服務方面包括性能監控、先後端異常監控等;運行方面提供 VSL 語音交互框架幫助開發者開發一些語音交互邏輯;工程方面提供搜索敏捷平臺,幫助開發者直接完成聯調、提測、上線;在應用方面,有卡片、圖片搜索、諮詢搜索、移動端的首頁,還有一些獨立的站,包括百度體育和百度招聘。

 

搜索組件化技術全景圖

2

移動體驗標準化建設

第二個 Session 是由百度前端技術部資深前端工程師劉浪宇帶來的《移動體驗標準化建設》。

極致的用戶體驗是 Web 產品所追求的,那麼什麼是好的用戶體驗,如何去量化用戶體驗作到好的體驗呢?首先須要有一套清晰的體驗指導標準,而後再去落地。

移動體驗指南

移動體驗指南是基於移動 Web 生態提出一套通用的體驗指導規範,目的是更好地服務於用戶及產品的系統,爲廣大用戶提供優質的體驗。從用戶的體驗層次、交互和移動 Web 現狀,百度概括出六個緯度:

第一,快速的信息呈現。速度快慢直接影響用戶對站點的體驗評級,因此讓主體內容快速呈現給用戶纔是優質的體驗必需的。

第二,設計交互層面強調一致性。一致的設計交互能夠利用用戶的學習經驗,下降學習和使用的成本。

第三,好產品須要作到讓用戶低成本、高效地完成全部交互操做,總體操做要清晰無阻,帶給用戶最流暢的體驗。

第四,內容強調優質閱讀觀感。站點的內容可讀性、內容自己質量是否可以達到,都是優質的體驗所必需的。

第五,情感層面有兩點,首先是愉悅的情感認知,其次是讓用戶對站點信任,頁面是否安全、是否及時告知流量信息等等。

第六,關於強健的場景適配,優秀的站點應當適合於不一樣的人羣和宿主環境。

移動體驗檢測平臺

有了體驗指南,如何快速知道站點存在哪些問題?這就須要體驗檢測平臺 Radar。

Radar 的最底層是 Headless  Chrome,百度經過協議接口能夠很是快捷地操做這個瀏覽器。中間的運行是基於谷歌開源的一個網頁工具 Lighthouse 。它主要有兩個內容,第一是網頁數據收集,經過數據分析得到數據,按照規則的須要,對於這些數據進行分析後輸出想要的結果。第二,Radar 的核心是很是多的規則,主要分兩類,一類是普通的,一類是交互的。

劉浪宇以交互的規則爲例,詳細闡述了一個規則是如何實現的。以下圖,交互的規則主要分爲兩部分,第一是場景識別,第二是交互分析。舉一個比較簡單的例子,當用戶在頁面看到一個輸入框時,以爲點擊能夠直接輸入是一個良好的體驗。那麼如何量化這個規則呢?首先是場景識別,找到在這個頁面中看起來像評論輸入框的元素。而後找一些特徵,從海量數據裏面標註、提取一些通用特徵以後爲這個場景創建特徵庫。以後再基於場景所須要的特徵,進行網頁結構化數據提取。

 

Radar 規則架構(交互類規則爲例)

接下來這些場景元素就要進行交互分析,首先進行深度篩選而後進行交互操做。以模擬屏幕的點擊舉例,點擊以前用戶會看頁面的變更,好比說 DOM 的變更、跳轉的變更,而後對變更進行分析,看是否符合預期。

3

基於 Custom  Elements 標準組件化構建 Web 應用

第三個主講人是百度前端技術部資深前端工程師鄒淼江,他現場分享瞭如何高效快速的構建一個體驗良好的 Web 應用、基於 Custom Elements 標準的組件化設計、如何提高用戶端體驗和開發效率。

首先看自定義標籤,自定義標籤在功能上邏輯上與 JavaBean 相似,都封裝 Java 代碼,是可重用的組件代碼,而且容許開發人員爲複雜的操做提供邏輯名稱。另外,自定義標籤具備⽀持⽆障礙、提升開發效率、評估性能、對 SEO 良好的特色。

其中,如何使用自定義標籤進行性能評估呢?百度提供了一套搜索引擎的驗證工具。好比,符合某一種規則的 Custom  Elements,給它標高分,爲符合高性能標籤。但若是使用 DIV 的方式,搜索引擎沒辦法知道佈局是否是高性能,也沒辦法知道所對應的 JS 如何實現,若是有了 Custom  Elements 的標準,就能清晰地知道這個頁面想幹什麼。

基於此,咱們能夠設想:若是徹底使用這些 Custom  Elements 語義化標籤構建 Web 站點可行嗎?

這就須要引入組件化設計。其實目前存在的組件化設計都千篇一概,把一個頁面的功能模塊以組件樹狀的形式自由組合,堆積成一個功能的頁面或者是模塊,這就是組件的結構。具體要求:

每⼀個 Custom Element 是⼀個組件

組件內部實現相應的交互、功能和數據處理邏輯

組件之間邏輯和樣式是獨⽴隔離的

組件是能夠通訊的

組件是可復⽤的

Web Components 標準

Web Components 是指經過一種標準化的非侵入的方式封裝的一個組件。主要標準包括 Custom Elements,Shadow DOM,HTML Templates,HTML Imports 等多個維度的規範與實現。

Custom Elements 是提供一種方式讓開發者能夠自定義 HTML 元素,包括特定的組成,樣式和行爲。支持 Web Components 標準的瀏覽器會提供一系列 API 給開發者用於建立自定義的元素,或者擴展示有元素。

Shadow DOM 旨在提供一種更好地組織頁面元素的方式,來爲日趨複雜的頁面應用提供強大支持,避免代碼間的相互影響。開發者可利用 Shadow DOM 封裝本身的 HTML 標籤、CSS 樣式和 JavaScript 代碼。

HTML Imports 是一種在 HTML 中引用以及複用其餘的 HTML 文檔的方式,能夠簡單理解爲常見的模板中的 include 之類的做用。咱們能夠經過 HTML  Import 的形式,直接將作的 Custom  Elements 的標籤放進 HTML 中進行渲染渲染。

 

Web Components 兼容性

4

搜索落地頁體驗技術及應用

第四個主題由百度前端技術部前端工程師李兆明講述。如何更快、更好的將各種搜索結果頁面傳遞到用戶端一直以來是百度搜索前端的核心關注點。基於此,李兆明分別從如何讓落地頁加載更快,如何讓搜索結果頁和落地頁之間切換更加順滑以及將來的新標準,介紹百度搜索落地頁體驗技術的探索。

如何讓落地頁加載更快

思路一:提早加載。經過 Resource Hint 提示瀏覽器預解析域名、創建預鏈接,甚至進行預渲染。如果不支持的瀏覽器,則能夠經過 JavaScript 模擬一部分。

思路二:抓取數據。經過開放平臺提交數據,由百度來渲染。

思路三:MIP / AMP。MIP 提供多重措施,讓使用 MIP 技術的頁面加載速度更上一層樓。例如,CDN 加速服務;使用 MIP 設計的網站沒有任何能夠阻塞渲染的腳本,全部腳本都在頁面主體加載完成後才執行。此外,MIP 要求全部頁面都是靜態的,若是有須要實時更新的數據須要異步獲取,這樣設計節省了後端的渲染時間。

如何把兩個頁面融合在一塊兒?

其實,不管有多少優化加載速度的手段,歸根結底離不開頁面跳轉。可是,瀏覽器跳轉相對來講不夠平滑,用戶體驗不夠好,能不能把先後兩個頁面融合到一塊兒呢?

答案固然是確定的。李兆明在保證體驗、保障安全及保持開放的基礎上,講解了百度前端搜索的解決方案:

保證體驗:經過 Iframe 加載頁面;經過 PostMessage 等方法實現交互動效。

保障安全:不容許使用外部腳本,須要封裝組件審覈;經過校驗確保 HTML 符合規範。

保持開放:經過 GitHub 追蹤開發。

展望新技術

在將來,百度搜素將基於域名、Iframe 渲染問題,爲開發者帶來 Navigation Transition、Promotable Iframe、Portals 及 Web Packaging 新標準,帶來最流暢的體驗。

Navigation Transition:頁面切換的交互方式。解決了跨域問題,沒有 Iframe 渲染的歷史包袱。不過前一個頁面依然不能控制後一個頁面的加載、渲染。iframe 能夠提早加載,可是 Navigation Transitions 必定要在用戶切換的時候加載。

Promotable Iframe:與 Iframe 相關,核心代碼是 Promotable 的 API,只要調用 Promotable,就會調動頁面的一小塊,然後調動整個頁面及內容。可是這種方法涉及一些生命週期的管理和 JS 的回收問題,是不夠安全的實現,並且這樣沒有解決 CDN 的問題,依然須要改域名。

Portals:傳送門,將一個頁面傳送另外一個頁面。這個標準是 Promotable Iframe 的加強,引入了一個新的 HTML 標籤 portal,這個標籤用來替代 Iframe 顯示一塊網頁,寫法和 Iframe 相似。可是它比 Iframe 多一個功能,就是能夠經過 「active」 方法激活它。與此同時, portal 的子文檔會收到一個 portal zactive 事件,事件中能夠拿到它的上級元素,這樣又能夠把上級元素當成一個 portal 插入回本身的文檔流,使得頁面切換回去成爲可能。

Web  Packaging:解決了 CDN 跨越問題。這個標準包括三方面:簽名、打包、加載。以下圖,左邊內容提供者是站長,緩存的 CDN 類比 MIP 的 CDN ,右邊是訪問用戶,用戶瀏覽咱們百度搜索結果頁的時候,經過 MIP 的 Cache CDN 提早把數據取過來,用戶真正點擊的時候,直接從剛纔取回來的頁面去加載它。因爲內容自己是內容提供者提供的,因此他能夠對於本身 URL 進行簽名。有了這個簽名且簽名有效的時候,瀏覽器能夠本身顯示原始的網址,同時原始的網址能夠和原來的服務器進行交互,像經過原網址打開的同樣,解決了 CDN 跨域問題。

 

5

如何經過 Lavas 快速構建 PWA 站點

最後一個主題的講師是百度前端技術部資深研發工程師王軼盛爲你們介紹如何經過 Lavas 快速構建 PWA 站點。

PWA

PWA(Progress Web App)是 WEB 將來的發展方向。從體驗上來講,PWA 接近原生 APP,經過 Manifest 技術容許用戶快速打開站點並得到沉浸式的體驗,經過 Service Worker 可以作到資源預加載和離線可用等從而提高性能和可用性;同時 PWA 又擁有 Web 站點的共同優點:免安裝和自動更新。

但與 Web 站點不一樣的是,PWA 又具備可靠、快速、黏性等特色:

第一是可靠。在斷網的狀況下,PWA 可作到比較友好的離線提示,這個是 PWA 斷網的最高級,叫斷網可用。

第二是快速。53% 的用戶會放棄加載時間超過 3 秒的網站,越快的加載速度就有越少的用戶流失。PWA 提供 Service  Worker,肯定哪些訪問緩存、哪些訪問網頁,縮短加載時間。

第三是黏性。黏性是指用戶訪問過一次,下一次訪問是否麻煩。PWA 會用一個半秒的啓動動畫來保證瀏覽器首頁啓動的順滑。另外,啓動以後沒有的地址欄、菜單欄,保證用戶的沉浸式體驗。

從技術層面講,PWA 有分爲四部分:

第一是 Service  Worker 。定義預緩存、網絡攔截和緩存策略。它自己是一個 Worker,有專門的語法,須要 CACHES API,須要註冊及更新。

第二是 Manifest 。這是一個 Json 文件,定義快速入口,啓動動畫。

第三是 Web Push and Notification 。是服務器推送給客戶端的主動通知。

第四是 APP Shell 。這並非新技術,但它是經常使用的 PWA 架構。簡單來講,就是把一個 APP 分紅了外殼和內容,用 Service  Worker 把外殼緩存起來,將裏面的頁面進行跳轉。

經過 Lavas 搭建 PWA 站點

Lavas 包括工具、文檔以及對應的解決方案和建站模板,是一個開源的解決方案。Lavas 自己有兩部分,Lavas cli 和 Lavas core,內部用 Vue + Vue Router + Vuex 搭建站點,內置兩套模板 (basic & app-shell),支持傳統模式 SPA 和 SSR 快速渲染,能夠快速擁有 PWA 特性,靈活性強,配置簡單,並且文檔及時更新,內容完整。經過 Lavas 搭建 PWA 站點主要有八個步驟:

準備環境 & 初始化項目。安裝 Lavas cli,初始化項目,選擇模板,安裝依賴。

 

建立新頁面。

 

添加連接。使用 <router-link>,注意和 Vue 保持一致,to 屬性指明目標頁面,支持字符串格式的地址,支持對象。而後啓動調試服務器。

 

和服務端通信。安裝 axios,引入 axios,向後端發送請求。

 

使用 Vues 管理數據。

建立 STORE,須要定義一些內容。把請求數據移動到 action 裏面,獲取成功後調用 commit 觸發 mutation 去更改 state。

在組件中,經過 store.dispatch 觸發 action 獲取數據,而後經過 mapState 把 state 和計算屬性關聯,最後經過計算屬性在頁面上使用。

 

配置 Manifest 。Manifestt.json 定義了啓動 URL,定義各類尺寸的 icon,定義動畫配色和啓動模式。

 

配置 Service Worker。配置,指定模板位置、構建位置

 

構建和上線。執行構建命令 > lavas build;啓動生產環境 > cd dist,> lavas start。

Lavas 技術原理

Lavas 的技術原理主要有自動生成路由規則、Skeleton、App Shell。

Vue  Router 須要四個步驟作整件事情:第一步定義和引用組件,第二步把組件和路由聯繫起來,第三步是把剛剛聯繫起來的數據放到 Router 函數建立實例,第四是把 Router 放到 VUE 建立實例,結束 Vue 實例掛載就。

通過改進, Router 不用本身定義頁面級組件,能夠認定只要在 Pages 目錄中,那組件都是頁面級的,從而能夠實現自動化 Import,不須要每次寫一大堆的代碼。另外,絕大多數狀況路由規則和組件名稱是有對應關係的。自動生成路由規則映射,省去了列出映射關係的麻煩,也避免後期組件更名帶來的維護成本。

Skeleton 叫骨架屏,就是實際內容展示以前,有個大概內容給用戶看,這樣用戶提早看到一些東西。這是 Loading 升級版,由於每一個組件能夠自定義樣式、切換時機、列表等。

Lavas 的 Skeleton 均可以用,實現思路是 Vue 的掛載點通常是個空的 DIV,在構建時將 Skeleton 的內容添加到掛載點中,Vue 掛載前清空 DIV 內的佔位內容,掛載後渲染爲實際內容,使用 SW 預緩存 HTML,訪問時直接從緩存中獲取 HTML,這樣可讓用戶看到佔位的東西。

App Shell,就是把一個 APP 分兩部分,有外殼和內容,把外殼緩存起來,每打開頁面先把外殼拿出來,而後再是內容渲染。App  Shell 實現有兩個步驟,第一是劃分,告訴程序哪部分是外殼、哪部分是內容;第二是程序把外殼緩存起來。這須要實現兩方面,第一是 SPA,首次請求服務器返回 Index.HTML,全部頁面的渲染均由 JS 完成,只在掛載點內從新渲染,單頁 Index.html 就是 Shell,使用 SW 預緩存 Index.html 便可。第二是 SSR,首次請求服務器返回給所有內容,後續頁面的渲染由 JS 完成。

Web 生態的發展就是互聯網的發展,新技術的不斷涌現和新場景的不斷實現也讓這個開放的生態得以持續繁榮。王軼盛表示,百度但願國內的開發者與站長可以多多參與到 PWA 項目中,共同建設和改善國內的 Web App 生態。

原文連接地址:https://developer.baidu.com/topic/show/290231

相關文章
相關標籤/搜索