句號-如何設計實用的性能模型與檢測系統(tǒng)
前端早早聊大會，前端成長的新起點，與掘金聯(lián)合舉辦。加微信 codingdreamer 進大會專屬周邊群，贏在新的起跑線。
第二十八屆|前端 WebGL專場，了解3D/可視化/渲染管線/動畫等等的可能性，6-26 全天直播，9 位講師(貝殼/阿里云/螞蟻/奇安信/小米/UC/美團等等)，點我上車?? (報名地址)：
所有往期都有全程錄播，可以購買年票一次性解鎖全部
正文如下
本文是第十八屆 - 前端早早聊性能優(yōu)化專場，也是早早聊第 124 場，來自 阿里 政采云-句號 的分享。
個人介紹
首先做一下自我介紹，我叫陶越，花名句號，19 年加入政采云，目前主要負責商品中心以及政采云性能檢測系統(tǒng)。
此次分享的宗旨
本次分享不會著重講一些非常具體化的一些性能優(yōu)化的方案，針對不同的性能優(yōu)化點，業(yè)界其實都已經(jīng)有了比較通用的一些解決方案。本次我要和大家分享的是針對不同的系統(tǒng)，如何設計一套與業(yè)務想匹配的性能檢測模型。然后希望通過這次分享之后，小伙伴們可以自己動手實現(xiàn)一個屬于自己的百策。
看一下本次分享的一個大綱
百策是什么
百策是政采云平臺的一個性能檢測系統(tǒng)，百策取名自歷史人物魏征，因敢于直諫，被稱為 “魏百策”。給性能檢測平臺取名為百策的意義就是希望此系統(tǒng)能像政采云的諍臣一樣，為政采云平臺提供性能上的指導與幫助。
然后我們來看下百策的是怎么樣的。
百策提供了一個入口，輸入 URL 后能根據(jù)頁面的整體性能情況，給出綜合的一個評分。最后的得分會根據(jù)不同的頁面類型有不同的分數(shù)計算方式，為什么不同的頁面會有不同的分數(shù)計算方式這一點我會在第二章中詳細描述。
檢測結束后，會進入得分詳情頁面，右邊是百策得分詳情的整個頁面，左邊是頁面的局部放大圖?？梢钥吹皆诳偟梅置姘宓南路接写舜卧u分詳細的扣分原因以及改進的具體方案。
然后這是檢測結果中的通過項和警告項：
除了扣分情況以外，下面還會有此頁面的性能數(shù)據(jù)看板，方便查看得分走勢等數(shù)據(jù)。
以上介紹的是百策的主要功能，除了性能評分以外，百策還提供了頁面錄入，定時檢測，性能評分榜單等功能。
百策的檢測功能實際上是根據(jù)合成監(jiān)控這種方式來實現(xiàn)的。那合成監(jiān)控是什么？接下來我會聊一下前端性能監(jiān)控的兩種方式：
第一種是合成監(jiān)控：合成監(jiān)控就是模擬真實的頁面打開場景，通過你設定的一些規(guī)格去運行頁面，最后提取出的性能數(shù)據(jù)和指標，合成監(jiān)控大家最熟悉的應該就是 Chrome 的 Lighthouse。
第二種是用戶數(shù)據(jù)監(jiān)控：用戶數(shù)據(jù)監(jiān)控是將線上的真實數(shù)據(jù)的性能情況進行監(jiān)控，對用戶真實的數(shù)據(jù)進行清洗加工后，提取出性能數(shù)據(jù)和指標，此方法需要在頁面中注入 SDK 以獲取性能數(shù)據(jù)。
可以看下不同監(jiān)控方式的具體流程圖。
合成監(jiān)控主要流程包括模擬打開頁面，獲取性能數(shù)據(jù)，性能數(shù)據(jù)審計，最后是性能數(shù)據(jù)入庫。然后用戶數(shù)據(jù)兼容主要是在用戶打開頁面后，獲取性能數(shù)據(jù)，通過事先埋入的 SDK 進行數(shù)據(jù)上傳，然后發(fā)送到后臺進行數(shù)據(jù)審計，最后性能數(shù)據(jù)入庫。
了解了兩種監(jiān)控方式的具體流程之后，我們分別聊一下合成監(jiān)控和真實用戶數(shù)據(jù)監(jiān)控的優(yōu)缺點是什么。
合成監(jiān)控首先實現(xiàn)方案比較簡單，只需要在后臺模擬打開頁面即可，不用注入 SDK 獲取頁面數(shù)據(jù)，而且合成監(jiān)控方式可以做到變量調(diào)控，可以根據(jù)不同的情況模擬不同的硬件環(huán)境，并且性能數(shù)據(jù)比較豐富。缺點也顯而易見，不能代表真實用戶的性能數(shù)據(jù)，而且對于需要登錄才能打開的頁面，會直接跳轉(zhuǎn)到登錄頁面，所以此監(jiān)控方式還需要單獨實現(xiàn)登錄邏輯。而且合成監(jiān)控的數(shù)據(jù)樣本量一定是沒有用戶數(shù)據(jù)監(jiān)控多。 然后用戶數(shù)據(jù)監(jiān)控首先肯定沒有合成監(jiān)控中需要登錄的問題，打開頁面即可進行性能數(shù)據(jù)獲取，完全真實的真線數(shù)據(jù)，能夠針對性的分析性能問題。但缺點也顯而易見，無法模擬不同的硬件環(huán)境，由于使用 SDK 方式，會有流量消耗和性能消耗，數(shù)據(jù)的收集也沒有合成監(jiān)控那么豐富。
那為什么百策采用的是合成監(jiān)控模式呢？
那要從百策存在的目的說起，百策存在的目的在于提升頁面性能，并非監(jiān)控線上性能數(shù)據(jù)，百策要針對頁面中性能欠缺的地方，提供具體的性能修改指導建議，而且百策需要保證環(huán)境和硬件條件一致的情況下對頁面做性能比對。
所以總結來說就是我們需要合成監(jiān)控的所有優(yōu)點，而且也不 care 合成監(jiān)控的缺點。
百策的由來
為什么要性能檢測呢
我們先來看一張圖，該圖來源于百度用戶體驗部的頁面留存率曲線圖，可以看到用戶普遍能接受的頁面打開時間都在3 秒以內(nèi)?？梢钥吹接脩袅舸媛屎晚撁娲蜷_時間的一個關系趨勢。
所以我們進行性能檢測的目的就是為了提升用戶體驗，增加用戶留存。如果一個頁面的渲染速度非常慢，有 3 到 4 秒的白屏時間，我想大多數(shù)人可能以為網(wǎng)站掛了或者很多人就直接就把頁面關閉，那么這個網(wǎng)站的用戶留存率會比普通網(wǎng)站低很多。下面我收集了幾個頁面性能優(yōu)化與留存率關系的案例：
Shopzilla 平均頁面加載時間從 6 秒加速到 1.2 秒，增加了收入+ 12％ 和頁面瀏覽量+ 25％； Mozilla 每年的 Firefox 下載量增加了 6,000 萬，使其頁面的速度提高了 2.2 秒； 亞馬遜和沃爾瑪每減少 100 毫秒的打開時間，收入增加 1％；
接下來的 2 章是本次分享的重點內(nèi)容。
首先我們來看下如何才能搭建百策
在講如何搭建百策之前，我們先要構造自己的業(yè)務模型，要構造自己的業(yè)務模型之前就要先分析自己的業(yè)務痛點，從業(yè)務出發(fā)，才能做好百策。那我們先來聊一聊如何分析自己的業(yè)務痛點。
分析自己的業(yè)務痛點
面向的對象的特點對應的性能指標上的區(qū)別
首先需要分析自己的業(yè)務主要面向的對象是誰？他們在系統(tǒng)中是來干什么的。舉一個例子，就拿我們系統(tǒng)和淘寶進行對比。
首先政府采購面向的對象是政府采購人員，淘寶面向的對象是廣大消費者，首先在頁面的 PV、UV 上的量級是不一樣的，所以業(yè)務指標的設定上一定是不同的兩套標準，在設計性能指標時，政采云的性能指標可能會略低于淘寶的。其次政府采購人員使用的電腦上的瀏覽器一般都是低版本 IE 瀏覽器，所以在瀏覽器兼容方面進行設計時，百策的檢測力度可能會略高于淘寶。
其次政府采購人員一般在 PC 端進行采購，而淘寶消費人群主要集中在手機端，所以在性能分析時，淘寶還需要對一些極端場景，比如弱網(wǎng)場景做一些檢測，而針對政采云的性能檢測模型，網(wǎng)絡環(huán)境上的指標就不必太過于關注。最后還可以多收集現(xiàn)有用戶的吐槽點進行優(yōu)化，比如之前就有人吐槽有部分頁面出現(xiàn)了橫向滾動條，造成頁面使用困難。所以我們在檢測模型上增加了一條橫滾檢測的指標。
總結來說，分析業(yè)務痛點的訣竅共有以下 3 點：
分析系統(tǒng)面向的人群特點； 分析系統(tǒng)面向的人員使用場景特點； 收集使用人員吐槽點；
那分析完業(yè)務痛點之后，我們再來聊一聊不同的業(yè)務是怎么檢測的？
剛才在第一章中提到了一點，就是不同的頁面有不同的分數(shù)計算方式，不同的分數(shù)計算方式我們稱為不同的性能檢測模型。那為什么有不同的檢測模型呢，我們來看下下面兩張圖。
第一張是采購人的商品搜索頁面，可以看到頁面中主要都是圖片相關的內(nèi)容，沒有非常復雜的交互，主要以瀏覽為主。
第二張是供應商發(fā)布運費模版的頁面，可以看到頁面中都是表單元素，而且里面有復雜的一些業(yè)務邏輯，隨之而來的也有一些復雜的交互邏輯。
從上面兩張圖可以看到不同頁面，檢測的重點不同，模型不同，權重不同，所以不能用一套模型搞定所有的頁面。這時候檢測模型的概念就出來了。政采云總的來說可以分為 2 種檢測模型，第一種是前臺導購模型，第二種是中臺表單模型。
具體業(yè)務具體分析，首先聊一下前臺導購頁面。
前臺導購頁面的話主要面向的是采購人，主要功能可以分為物品的采購、活動頁面的展示等。分析這一類頁面的共通點，就是展示為主，并且會伴有大量的圖片信息。根據(jù)以上業(yè)務的分析結果，我從兩方面來構建業(yè)務的檢測模型。傳統(tǒng)的頁面加載時間往往不能直接反應頁面的性能狀況，因此百策采用的是漸進式的網(wǎng)頁指標來設計的，圖中除了DNS 和 TCP 耗時以外，其余時間指標都是漸進式的網(wǎng)頁指標。然后我們來一個個分析：
首先是加載時間方面。無論什么頁面，更快的加載速度一定是沒錯的，這一點我們可以把它定為通用檢測項。我們可以定義各種時間來檢測頁面，可以看到百策在時間上的檢測項包含了：DNS 耗時、TCP 耗時、首次內(nèi)容繪制時間（簡稱 FCP，指的是第一個有意義的 DOM 渲染，比如圖片、文本、SVG 等）、最大內(nèi)容繪制時間（簡稱LCP，指的是可視區(qū)最大可見元素出現(xiàn)的時間點）、首次可交互時間（簡稱 TTI，指的是用戶可以進行交互的時間，檢測的規(guī)則是主線程任務不超過 50ms 才算可用）、阻塞總時間（TBT，指的是所有主線程任務花費時間超過 50ms 的時間總和）。
那講完通用檢測項之后，剩下的檢測項就應該圍繞著業(yè)務特性來。剛才我們分析過政采云前臺導購頁面的一些通用性之后，把目光聚焦在了圖片加載優(yōu)化上，所以我們會側(cè)重于圖片性能的一些檢測項，比如說頁面上圖片加載的體積大小，圖片是否使用了 CDN 壓縮后綴，圖片是否使用懶加載，圖片是否使用了 webp 格式，是否有加載錯誤的圖片，png 格式的圖片錯誤地使用壓縮后綴反而導致圖片變大。
剩余項的話主要是一些通用性的，并且和當前導購頁面有聯(lián)系的指標，比如說累計位移偏移量（簡稱 CLS，計算規(guī)則是 500ms 內(nèi)網(wǎng)頁元素偏移的分乘以影響分）、靜態(tài)資源緩存策略、重復請求、橫向滾動條。
所以百策的前臺導購模型，總分 100 分，時間占比 45 分，圖片占比 30 分，其余項占比 25 分。
再回到我們的中臺表單頁面，中臺表單頁面主要面向的是我們的供應商和一些采購老師等角色，功能偏向于各種表單配置項，主要是由許多典型的表單頁面構建，分析這一類頁面的共通點，就是以表單為準，它不像前臺頁面有那么多的圖片展示，但會有很多的頁面交互方面的內(nèi)容。根據(jù)以上的業(yè)務分析結果，我也從兩方面來構建業(yè)務的檢測模型：
加載時間方面和前臺導購頁面基本一致，可能有區(qū)別的就是每項的扣分情況。
那除了加載時間外，剩下的檢測項目的具體指標就是側(cè)重于表單優(yōu)化的，比如說首屏 HTTP 請求、CLS，JS/CSS 壓縮情況、重復請求、橫滾、DOM 最大深度、DOM 節(jié)點數(shù)量、頁面從開始加載到結束加載后有多少時間是丟幀的（小于60FPS）等。
所以百策的中臺表單模型總分 100 分，時間占比 60 分，頁面占比 40 分。
接下來我們就講一下百策實現(xiàn)。
百策是怎么設計的（架構）
百策的架構圖介紹
首先我先把我們百策的架構圖拿出來給大家看一下，前端只是一個純展示功能的頁面，所以不多描述了。
服務端基于 nestjs （奈斯特）開發(fā)，接入了 Sentry，helmet，主要功能是用戶系統(tǒng)的監(jiān)控和保護，node-schedule用于每周定時計算已錄入系統(tǒng)中的頁面性能，一般在周五凌晨開始跑分，然后周五下午通過 nodemailer 和 ejs 服務發(fā)送性能檢測郵件。
最主要的檢測服務基于 Puppeteer 和 Lighthouse 開發(fā)。
以上就是百策的整體的一個架構圖，接下來會說一下 Puppeteer 和 Lighthouse 的主要功能以及在百策中的使用。
Puppeteer
先來看下 Puppeteer 的官方說明：Puppeteer 是一個 Node 庫，它提供了一個高級 API 來通過 DevTools 協(xié)議控制Chrome。Puppeteer 默認以 headless 模式運行，但是可以通過修改配置文件運行“有頭”模式。
簡單來說就是在 Node 端起一個瀏覽器，通過 API 控制可以模擬在瀏覽器操作的大部分功能。Puppeteer 通過DevTools 協(xié)議生成一個 Browser 對象，Browser 可以擁有多個 BrowserContext 瀏覽會話，一個 BrowserContext 也可以擁有多個頁面。
“百策”最關鍵的邏輯就是通過 Puppeteer 在 Node 端起一個瀏覽器，首先通過 API 打開首頁，模擬用戶登錄，通過同一瀏覽器不同 Tab 頁共享同域名 Session 這一特性，新開 Tab 打開待檢測的頁面，并在頁面關閉前收集數(shù)據(jù)并入庫。
再來聊一下 Lighthouse。
Lighthouse
先看下 Lighthouse 的官方說明：Lighthouse 是一個開源的自動化工具，用于改進網(wǎng)絡應用的質(zhì)量。Lighthouse 提供了多種運行方式，包括：內(nèi)嵌于 Chrome 中、Chrome 插件，Node CLI 方式和 Node Module 方式4種。
可以先看下 Lighthouse 的架構。共分為 4 步：
第一步在頁面交互后發(fā)起請求調(diào)用； 第二步喚起自己的 Gatherers，Gatherers 的主要功能在于數(shù)據(jù)收集功能，可以將它理解為數(shù)據(jù)收集器，不同的Gatherer 有自己的數(shù)據(jù)收集功能，最后將收集到的數(shù)據(jù)統(tǒng)一提交給 Audit； 第三步喚起 Audit，Audit 的主要功能在于將第二步中收集到的數(shù)據(jù)按照檢測模型分配為通過、失敗或者得分情況； 第四步將結果返回給前端。
然后我們再來看下 Lighthouse 和 Puppeteer 結合的方式，共有 2 種。關鍵點在于保證 Lighthouse 和 Puppeteer 啟動時使用同一個端口號即可：
第一種是先啟動 Puppeteer，然后將 Puppeteer 移交給 Lighthouse，具體實現(xiàn)方案是啟動 Puppeteer，為Puppeteer 增加一個 targetchanged 的鉤子函數(shù)，用于在頁面關閉前收集數(shù)據(jù)?？梢钥吹绞紫仁鞘褂?puppeteer.launch 啟動 puppeteer，然后移交給 Lighthouse 的時候，Lighthouse 的啟用端口號從 browser 中獲取。 第二種是使用 Lighthouse/chrome-launcher 啟動 Chrome，然后移交給 Puppeteer?？梢钥吹绞紫仁鞘褂胏hromeLauncher.launch啟動 Chrome，然后通過puppeteer.connect連接到瀏覽器實例，最后啟動Lighthouse。
兩種方法只是寫法上有區(qū)別，實際使用時沒有任何區(qū)別，百策采用的是方案一。
這個是一個 Demo 代碼，這一塊主要是啟動 Lighthouse，這一塊是注冊鉤子函數(shù)，用于頁面打開后的性能數(shù)據(jù)獲取，這一塊就是通過 Lighthouse 打開頁面獲取數(shù)據(jù)。
百策的實現(xiàn)介紹
下面聊一下百策的一個具體實現(xiàn)流程圖。
首先是啟動 Puppeteer，創(chuàng)建 Browser 和空白的 Page； 其次調(diào)用 goto 方法打開政采云的首頁，填充用戶名和密碼后，后臺模擬點擊提交，此時 SESSION 已經(jīng)保存到Browser 中； 然后新建一個空白的 Page，通過 Puppeteer 注冊一個鉤子函數(shù)，鉤子函數(shù)的作用是監(jiān)聽頁面各種事件，比如頁面打開事件，請求完成事件等，在不同的階段獲取不同的性能數(shù)據(jù)。舉個簡單的例子，我要獲取 window.performance 中的各種時間指標，首先要必須等待頁面加載完成，所以我需要在頁面打開前注冊一個頁面加載完成的鉤子函數(shù)，等到頁面加載完成之后，自動觸發(fā)此函數(shù)，獲取數(shù)據(jù)； 然后將 Puppeteer 移交給 Lighthouse，打開待檢測的頁面； 頁面全部加載完成之后，觸發(fā)了 Gatherers 中的鉤子函數(shù)，將收集到的數(shù)據(jù)傳遞給 Audit； 根據(jù)頁面是前臺導購頁面還是中臺表單頁面確定模型，按照模型計算得分情況； 最后就是得分情況入庫，并返回得分情況給前端展示。
登錄是非必要操作，因為有的頁面是不需要登錄就能打開的。
中間的紅框?qū)木褪?Lighthouse 的 Gatherers，Gatherers 包含了多個 Gatherer，每個 Gatherer 有自己的收集功能，比如百策就擁有 5 個 Gatherer，這 5 個 Gatherer 的功能分別是：收集 DOM 數(shù)據(jù)，收集圖片數(shù)據(jù)，收集 Lighthouse 數(shù)據(jù)，收集網(wǎng)絡請求數(shù)據(jù)和收集 performance 數(shù)據(jù)。Gatherer 的功能只有收集數(shù)據(jù)。
最右邊的紅框?qū)木褪?Lighthouse 的 Audit，主要用于將 Gatherers 收集到的數(shù)據(jù)按照性能檢測模型定義的評分項進行扣分和梳理，最終將數(shù)據(jù)入庫。每一個檢測模型對應的檢測指標項就是一個 Audit，每個 Audit 有自己的評分和扣分標準。最終將數(shù)據(jù)返回前臺。
百策的實現(xiàn)的話細節(jié)代碼可以參考下面這篇文章，感興趣的小伙伴可以在掘金搜索政采云前端團隊公眾號。大家可以關注點贊一波。
百策的模型介紹以及百策的模型指標是如何設計的
講完百策實現(xiàn)之后，在這里給大家看一下我們百策的檢測模型的具體指標。還是看一下剛才的性能檢測模型圖片，以我們的前臺導購頁面檢測模型來說。
在時間維度上，首先是打開頁面時的一些耗時分計算，DNS 耗時和 TCP 耗時，我們系統(tǒng)以 100ms 為準，每超過 10ms 扣 1 分，直到所有總分 5 分扣完為止。
接下來是打開頁面后時間維度的計算，主要靠 Lighthouse 提供。首次內(nèi)容繪制時間 1.5 秒為準，每超過 0.5 秒扣 3分，最大內(nèi)容繪制時間 2 秒為準，其他的指標我就不多描述。
然后再頁面維度方面，圖片大于 100K 的，每個扣 2 分，未使用 CDN 壓縮后綴的，每個扣 1 分，未使用懶加載的，每個扣 1 分，其他的指標后續(xù)小伙伴可以等羽雀文字稿出來之后可以細看。
以上這些指標的扣分情況是根據(jù)我們平臺平均的一個耗時來制定的。只要高于平均耗時一小部分作為滿分即可。除了以平均值作為評分情況外，我們還會參考許多業(yè)界的一些頁面進行對比，比如淘寶首頁等，我們在制定前臺頁面指標時，也會看淘寶網(wǎng)展示的一個具體情況來完善我們的檢測模型指標。
那如何構造自己的業(yè)務模型呢
構造自己的業(yè)務模型其實很簡單，可以按照我下面給的四步法原則進行分析。
建議參考頁面平均值來，比如說現(xiàn)在系統(tǒng)頁面非?？D，系統(tǒng)中大部分頁面首屏加載時間都在 2 秒到 3 秒之間，那么建議當前測評的具體指標可以將 FCP 時間定為 1.5 秒優(yōu)秀，2 秒及格，3 秒基本不得分。根據(jù)當前指標推動現(xiàn)有頁面進行整改。待大部分頁面整改到能夠通過優(yōu)秀指標后，繼續(xù)降低 FCP 檢測的標準時間。直到你認為這已經(jīng)是最高標準為止。
以上主要是根據(jù)我們業(yè)務分析出的性能檢測模型，不同的業(yè)務之間檢測模型一定有很大的差別。所以只能具體業(yè)務具體分析，可以參考四步法：
分析業(yè)務；
提取通用型的分類；
選取性能優(yōu)化方向；
制定性能優(yōu)化指標；
建立性能看板
構造完業(yè)務模型后，百策還提供了性能看版。
數(shù)據(jù)看板主要是方便我們查看性能的走勢的最好的方法。可以從以下 5 個方面做一個性能走勢的分析，時間維度報表，數(shù)量維度報表，體積維度報表，復雜度報表以及得分走勢情況。
時間維度報表代表性比較強的有加載時間，DNS、TCP 耗時等等。 數(shù)量維度報表比如有請求數(shù)量，靜態(tài)資源數(shù)量等。 得分走勢主要好似性能評分的一個趨勢圖。
性能評分有了，性能看版也有了，接下來就是要看下性能問題要如何才能解決。
怎么根據(jù)檢測結果來改善頁面性能
性能檢測的優(yōu)化方案有許多，比如加載優(yōu)化包括按需加載、緩存策略、請求合并等。渲染優(yōu)化包括了減少 DOM 數(shù)量和層級、避免 JS 渲染動畫、高頻操作節(jié)流防抖等。JS 優(yōu)化包括了異步加載、減少回流和重繪、合并 DOM 操作等。
資源優(yōu)化包括資源合并、資源壓縮、Iconfont 等。上面說的這些只是性能優(yōu)化方案中的某幾個例子。我這邊就不擴展開講了，畢竟今天的主要目標是要向大家分享怎么設計百策這樣的性能檢測系統(tǒng)。
性能優(yōu)化方案非常多，百策做的事情就是盡量讓開發(fā)者使用百策之后能知道頁面有什么性能問題，并且知道該怎么改？所以百策文檔自然而然就出現(xiàn)了。
百策文檔主要功能是收錄業(yè)界性能優(yōu)化方案，建立站點，供開發(fā)者根據(jù)指導修改代碼優(yōu)化性能。舉個2個簡單例子。比如說圖片懶加載，百策文檔會對懶加載的概念和原理解釋一番供開發(fā)者理解，那對于如何優(yōu)化也在文檔中寫明了不同框架的不同優(yōu)化建議。
再說比如未開啟 Gzip，針對 Node 端和 Tomcat 啟用的方案也都會在文檔中寫明，保證即使是剛?cè)肼毜男』锇橐材芨鶕?jù)指導進行改進優(yōu)化。
再聊一下百策總榜。百策總榜是百策中國呢頁面收錄的所有頁面做一個頁面評分并進行排行的功能。主要通過 node-schedule 定時跑評分，一般是一周一次。
以上就是百策實現(xiàn)相關的具體內(nèi)容。最后在講一下百策在公司是如何與其他基建打通的？
百策是怎么與公司的其他基建打通
之前在早早聊的頁面搭建篇介紹過政采云的魯班系統(tǒng)，簡單來說魯班系統(tǒng)就是政采云的頁面搭建系統(tǒng)。
那百策是如何實現(xiàn)與魯班系統(tǒng)的連接的呢？主要在兩個方面：
在魯班頁面搭建完成的時候，提供一個檢測按鈕，調(diào)用百策性能評分接口，生成檢測數(shù)據(jù)；
在魯班的新頁面上線的時候，會自動調(diào)用百策錄入接口，新增的頁面會被錄入到百策系統(tǒng)中。
除了魯班系統(tǒng)之外，還與 CI/CD 進行打通，云長是我們的實現(xiàn)云端構建時調(diào)用檢測接口，對于不符合優(yōu)秀分數(shù)的頁面，在云端構建時阻止發(fā)布，以保證頁面性能。
最后講一下我們的渾儀，數(shù)據(jù)埋點系統(tǒng)。對接方式也比較簡單，在百策的定時任務檢測時，會調(diào)用渾儀的獲取 PV、UV 接口獲取本周頁面的使用情況。
推薦一本書
最后推薦一本書，《代碼整潔之道》，人民郵電出版社的。
政采云介紹、招聘
最后再打一波廣告，政采云前端大量招人。再簡單介紹下我們團隊，是一個富有激情和創(chuàng)造力的團隊，團隊氛圍良好，平時除了日常業(yè)務外，還包括物料、工程化、搭建、性能、數(shù)據(jù)分析等等方面的技術建設，總有一款適合你的興趣。明年還有大量 HC，只需要你動動手，發(fā)送簡歷到 [email protected] 郵箱即可?，F(xiàn)至少還缺2位技術專家、8位資深開發(fā)工程師、8位高級開發(fā)工程師，歡迎大家猛砸簡歷。
別忘了 6-26(本周六) 的第二十八屆|前端 WebGL專場，了解3D/可視化/渲染管線/動畫等等的可能性，6-26 全天直播，9 位講師(貝殼/阿里云/螞蟻/奇安信/小米/UC/美團等等)，點我上車?? (報名地址)：
所有往期都有全程錄播，可以購買年票一次性解鎖全部
別忘了給文章點贊