一区二区三区视频播放_三级xxxx_7777奇米成人四色影视_色综合久久久久久_欧洲黄色一级视频_成人啪啪18免费网站

京東通天塔頁面(京東通天塔使用方法及作用解析)

通天塔是京東內(nèi)部的一個(gè)快速搭建活動(dòng)頁面的平臺(tái),用戶可以通過在可視化平臺(tái)上選擇需要的模板及配置對(duì)應(yīng)數(shù)據(jù),來生成對(duì)應(yīng)的原生、H5及PC活動(dòng)頁面。模板樣式豐富,操作靈活,在京東被大量使用,用戶流量也呈現(xiàn)出了非常迅猛的增長(zhǎng)。但隨著項(xiàng)目的迭代,功能越來越復(fù)雜,模板越來越多,前端和Node中間層性能問題也逐漸暴露出來,其中,前端首屏加載時(shí)間TP75性能要大于2秒,而Node中間層單核QPS相較其他應(yīng)用也較低。為了提升用戶體驗(yàn),同時(shí)提高系統(tǒng)的吞吐率,在2019年下半年我們通過對(duì)現(xiàn)有通天塔H5項(xiàng)目進(jìn)行一次全盤分析,做了一次全方位的性能優(yōu)化。 綜合性能提升超過30% 通天塔H5是以React SSR為基礎(chǔ)進(jìn)行架構(gòu)的,首屏頁面在Node中間層進(jìn)行數(shù)據(jù)請(qǐng)求及渲染,分頁和其他異步請(qǐng)求在客戶端請(qǐng)求網(wǎng)關(guān)接口并渲染,靜態(tài)資源托管在CDN,如圖1所示。
京東通天塔頁面(京東通天塔使用方法及作用解析)

圖1:通天塔H5請(qǐng)求流程 基于以上架構(gòu),經(jīng)過2019年下半年的優(yōu)化,通天塔H5前端首屏加載性能和Node中間層渲染性能都得到了極大提升。

1

首屏加載性能 首屏加載耗時(shí),TP75從原來的2.47秒減小到了1.58秒,性能提升約36.03%。圖2所示為優(yōu)化前后以周為維度的首屏TP75加載時(shí)長(zhǎng)。
京東通天塔頁面(京東通天塔使用方法及作用解析)

圖2:首屏TP75加載時(shí)間 此處首屏加載時(shí)長(zhǎng),指用戶打開頁面到首屏第一張圖片請(qǐng)求完成所經(jīng)歷的時(shí)間。橫坐標(biāo)代表第幾周,01代表今年第一周(2020/01/06 ~ 2020/01/12),52代表去年最后一周(2019/12/23 ~ 2019/12/29)。

2

服務(wù)器性能 通過對(duì)服務(wù)器進(jìn)行壓測(cè),在相同QPS維度下,CPU從原來的29.52%降低至20.5%,CPU使用率相比之前降低了30.5%
京東通天塔頁面(京東通天塔使用方法及作用解析)

圖3:同QPS下CPU利用率 線上性能分析 在進(jìn)行優(yōu)化前,需要先采集當(dāng)前線上數(shù)據(jù),了解服務(wù)目前的性能情況,我們主要通過以下方式對(duì)項(xiàng)目的性能進(jìn)行分析及監(jiān)控。

1

Performance API

Performance API是ECMAScript5才引入的,精度可達(dá)到1毫秒的千分之一,目前主流瀏覽器基本都已經(jīng)支持performance對(duì)象。通過performance.timing對(duì)象,可以拿到瀏覽器處理網(wǎng)頁各個(gè)階段的耗時(shí)。通過performance.getEntries方法,可以獲取js, css, 圖片及ajax在內(nèi)的所有請(qǐng)求的耗時(shí)信息。 我們基于Performance API,封裝了一個(gè)前端測(cè)速模塊,該模塊在頁面加載完成后將所需性能數(shù)據(jù)上報(bào)至服務(wù)器,之后可以在可視化平臺(tái)上進(jìn)行數(shù)據(jù)的展示及分析。

2

Chrome Devtools

Chrome Devtools是前端調(diào)試及性能分析常用的工具,通過該工具,可以查看頁面資源加載情況,所加載CSS、JS及圖片的大小,還可以通過Performance面板,查看頁面渲染繪制和Script執(zhí)行情況。

3

v8-profiler

通天塔H5是基于React SSR架構(gòu)的,頁面首屏在Node中間層請(qǐng)求數(shù)據(jù)并渲染,所以除純前端的監(jiān)控及分析,還需對(duì)Node層進(jìn)行性能分析及優(yōu)化。在Node層性能分析中,我們主要通過v8-profiler模塊進(jìn)行性能分析。 在本地或測(cè)試環(huán)境下新增兩個(gè)路由:
const profiler = require('v8-profiler');


router.get('/profiler/start', (req, res) => {
   //Start Profiling
   profiler.startProfiling('CPU profile');
   res.end('profile start');
});


router.get('profiler/end', (req, res) => {
   const profile = profiler.stopProfiling()
   profile.export()
     .pipe(res)
     .on('finish', () => {
         profile.delete();
         res.end();
     });
});
通過ab壓測(cè)工具,對(duì)服務(wù)器發(fā)起請(qǐng)求

ab -c 10 -n 1000 http://localhost:7001/mall/active/xxx/index.html

在壓測(cè)過程中,可以通過 http://localhost:7001/profiler/start開始性能統(tǒng)計(jì),通過http://localhost:7001/profiler/end結(jié)束性能統(tǒng)計(jì),并將結(jié)果保存為 ***.cpuprofile文件,通過Chrome Devtools中的JavaScript Profiler工具進(jìn)行分析。
京東通天塔頁面(京東通天塔使用方法及作用解析)

圖4:Node服務(wù)端代碼執(zhí)行情況 常規(guī)優(yōu)化+業(yè)務(wù)特性優(yōu)化 我們主要從兩個(gè)方面進(jìn)行性能優(yōu)化,一方面是基于較為通用的前端常規(guī)性能優(yōu)化方案,另一方面基于通天塔業(yè)務(wù)特點(diǎn)進(jìn)行的偏業(yè)務(wù)方面的優(yōu)化。

1

前端常規(guī)優(yōu)化 在優(yōu)化之初,根據(jù)《高性能網(wǎng)站建設(shè)指南》提及的常規(guī)優(yōu)化方案,我們檢查了項(xiàng)目中需要改進(jìn)或深度優(yōu)化的地方,主要涉及以下方面:
  • 盡可能的減少HTTP的請(qǐng)求數(shù),減小HTTP請(qǐng)求大小
  • 將靜態(tài)資源放在CDN,最大化利用CDN緩存能力
  • 減少CSS和JS請(qǐng)求個(gè)數(shù),減小CSS和JS包大小
  • 啟用gzip壓縮
1)減少圖片請(qǐng)求大小 在通天塔頁面中,圖片請(qǐng)求一般占比最大,在前期開發(fā)過程中,針對(duì)圖片請(qǐng)求我們已做過懶加載優(yōu)化,圖片請(qǐng)求數(shù)很難更進(jìn)一步減少,但針對(duì)圖片大小,我們可以進(jìn)行優(yōu)化。
京東通天塔頁面(京東通天塔使用方法及作用解析)

圖5:圖片展示尺寸及實(shí)際尺寸 如圖5,在頁面中圖片實(shí)際所展示坑位大小為115×115,即使在3倍屏上,所需圖片尺寸也只是345×345,但實(shí)際請(qǐng)求中,圖片的原始尺寸卻是800×800,這對(duì)用戶流量是一種浪費(fèi),同時(shí)也增加了圖片加載耗時(shí),而通天塔活動(dòng)頁中,這種類似的圖片還有很多,而同時(shí),京東圖片服務(wù)器正好支持圖片的裁剪,原來一張800×800的圖片,可以按比例縮小到所需的高度,如一張800×800的原圖 https://m.360buyimg.com/babel/jfs/t1/85209/24/15512/218570/5e7179d8E957c16c1/5fbcc42fad37fe94.jpg!q70.dpg ,通過修改URL,可以改成下發(fā)230×230尺寸的圖?http://www.wpdyw.com/wp-content/uploads/2023/02/5fbcc42fad37fe94.jpg!q70.dpg 鑒于此,針對(duì)圖片大小,可以做按實(shí)際展示大小請(qǐng)求對(duì)應(yīng)尺寸的圖片的優(yōu)化,以減小HTTP的大小。
const isJfsRegex = /360buyimg\.com\/.*\/((s([\d^_]+)x([\d^_]+)_)?jfs)/i;
export function resizeImg(url, rect) {
    const dpr = window.devicePixelRatio;
    if (!isJpegRegExp.test(url)) {
        return url;
    }
    const result = url.match(isJfsRegex);
    if (!result) {
        return url;
    }
    if (result[3] && result[4]) {
        if (!rect || (!rect.width && !rect.height)) {
            return url;
        }
        if (rect.width && !rect.height) {
            rect.height = rect.width / result[3] * result[4];
        }
        if (rect.height && !rect.width) {
            rect.width = rect.height / result[4] * result[3];
        }
        const t = 's' + Math.ceil(rect.width* dpr)  + 'x' + Math.ceil(rect.height* dpr) + '_jfs';
        return url.replace(result[1], t);
    } else {
        if (rect && rect.width && rect.height) {
            return url.replace('/jfs/', `/s${Math.ceil(rect.width * dpr)}x${Math.ceil(rect.height * dpr)}_jfs/`);
        }
    }
    return url;
}
2)最大化利用CDN緩存 在做性能優(yōu)化前,通天塔靜態(tài)資源的打包,是開發(fā)者在上線前,在自己電腦上進(jìn)行的,且文件名會(huì)依據(jù)文件內(nèi)容重新生成,格式為[filename].[contenthash:8].js。 按這種方式在個(gè)人電腦上打包,即使有package-lock.json鎖定包版本,但由于個(gè)人電腦操作系統(tǒng)及使用的npm包管理工具的不同(有的包管理工具不讀package-lock.json),node_module下的文件可能會(huì)不一致,導(dǎo)致文件的contenthash不同。 針對(duì)這個(gè)問題,我們基于Jenkins搭建了一個(gè)前端CI打包系統(tǒng),后繼所有上線前的前端靜態(tài)資源打包,都遷移到CI上進(jìn)行,通過這種方式,確保了文件名的一致性,以最大程度的利用CDN緩存。 3)調(diào)整webpack打包策略,按需加載CSS和JS 在性能優(yōu)化前,通天塔的CSS和JS資源是按以下策略打包的:
  • vendor.[contenthash:8].js: 包含node_module下的代碼
  • common.[contenthash:8].js: 包含非node_modules下的代碼
  • [channel].[contenthash:8].js: 通天塔有很多渠道,每個(gè)渠道的專屬代碼打包到這個(gè)JS中
  • template.[contenthash:8].css: 包含所有渠道通用CSS
  • [channel].[contenthash:8].css: 包含渠道專有CSS
按這種方式來進(jìn)行打包,有以下兩個(gè)問題, 1. 每個(gè)活動(dòng)會(huì)加載所有模板對(duì)應(yīng)的CSS和JS,造成不必要的加載。 2. 所有的系統(tǒng)模板代碼都打包到common包,導(dǎo)致common包非常龐大,而其中有任何一個(gè)模板代碼有改動(dòng),都會(huì)影響到common包的文件名,從而導(dǎo)致CDN緩存失效,客戶端必須重新請(qǐng)求CDN。 針對(duì)兩個(gè)問題,我們改進(jìn)了打包策略,最終方案改為:
  • vendor.[contenthash:8].js: 包含node_module下的JS文件
  • lowUsedTemp.[contenthash:8].js: 包含使用頻率低的系統(tǒng)模板代碼,頁面會(huì)按照活動(dòng)是否使用到低頻模板按需請(qǐng)求
  • mute.[contenthash:8].js: 包含剔除低頻使用模板后,較為穩(wěn)定,很少改動(dòng)的系統(tǒng)模板
  • template.[contenthash:8].js: 包含剩余非node_modules下的代碼
  • [channel].[contenthash:8].js: 包含渠道專屬代碼
  • lowUsedTemp.[contenthash:8].css: 包含使用頻率低的系統(tǒng)模板代碼的CSS,頁面會(huì)按照活動(dòng)是否使用到低頻模板按需請(qǐng)求
  • template.[contenthash:8].css: 包含所有渠道通用CSS
  • [channel].[contenthash:8].css: 包含渠道專有CSS
按照這種方式打包,只有使用到低頻使用模板的活動(dòng),才會(huì)加載lowUsedTemp.[contenthash:8].css和lowUsedTemp.[contenthash:8].js,其中按需加載的CSS占總CSS大小的25%,按需加載的JS占總大小的17%。而單獨(dú)打包出的mute.[contenthash:8].js這個(gè)JS資源,由于里面包含的模板很少被改動(dòng),所以在打包上線時(shí),其文件名也很少會(huì)變,這就可以利用CDN緩存,不會(huì)每次上線后,用戶都重新請(qǐng)求這部分代碼。

2

業(yè)務(wù)優(yōu)化 在常規(guī)的前端性能優(yōu)化達(dá)到瓶頸后,我們開始嘗試基于業(yè)務(wù)進(jìn)行性能優(yōu)化。 1)首屏精準(zhǔn)化優(yōu)化 通天塔頁面是運(yùn)營(yíng)在可視化配置平臺(tái)中,通過選擇模板,配置數(shù)據(jù)來動(dòng)態(tài)生成的,而其中類似商品樓層這種素材樓層,配置的素材數(shù)量也由運(yùn)營(yíng)自己決定,少的可能只有幾個(gè),多的幾十上百個(gè),這便導(dǎo)致通天塔首屏頁面有以下特點(diǎn) 1. 頁面靈活多變,頁面結(jié)構(gòu)難以預(yù)測(cè)。 2. 在請(qǐng)求首屏樓層數(shù)據(jù)時(shí),服務(wù)端難以計(jì)算需要下發(fā)幾個(gè)樓層剛好滿首屏,故按照素材樓層數(shù)來進(jìn)行分頁,如果首頁素材樓層配置的素材較多,節(jié)點(diǎn)數(shù)會(huì)非常龐大。 由于以上兩個(gè)特點(diǎn),導(dǎo)致很多活動(dòng)頁首屏的內(nèi)容,遠(yuǎn)大于客戶端首屏實(shí)際所需展示的長(zhǎng)度,這既加大了首屏的渲染耗時(shí),同時(shí)也浪費(fèi)了Node服務(wù)器的CPU資源(渲染了不必要的樓層)。 另外,在通過v8-profiler測(cè)試Node服務(wù)器性能時(shí),我們發(fā)現(xiàn)Node服務(wù)器端開銷最大的地方有三處
  • 通過JSON.parse解析后端下發(fā)的活動(dòng)數(shù)據(jù)
  • React.renderToString 進(jìn)行首屏渲染
  • JSON.stringify將首屏數(shù)據(jù)序列化后跟隨HTML下發(fā)給客戶端
綜合考慮各種優(yōu)化方式,最終決定采用在Node層計(jì)算每個(gè)樓層高度,按首屏高度渲染樓層數(shù)的方案。
京東通天塔頁面(京東通天塔使用方法及作用解析)

圖6:首屏精準(zhǔn)渲染流程 1. 用戶向Node中間層發(fā)起請(qǐng)求的時(shí)候,客戶端會(huì)向cookie中埋入設(shè)備寬高信息。 2. Node中間層從cookie中獲取設(shè)備寬高信息,若獲取失敗,則使用默認(rèn)值。 3. 循環(huán)計(jì)算每個(gè)樓層的高度,如果樓層累計(jì)高度超過2倍設(shè)備高度,丟棄后面的樓層數(shù)據(jù),并重置分頁信息。 4. Node中間層根據(jù)計(jì)算過后的數(shù)據(jù),渲染首頁樓層,并將數(shù)據(jù)序列化后隨HTNL下發(fā)到客戶端。 5. 前端檢測(cè)頁面是否滿兩屏,若沒滿兩屏,立即請(qǐng)求下一頁數(shù)據(jù)。 在樓層維度的分頁優(yōu)化完畢后,還可以精益求精,針對(duì)素材樓層進(jìn)行樓層內(nèi)素材的優(yōu)化,如果首頁最后一個(gè)素材樓層中有素材超過兩屏,還可以將超過兩屏的素材降級(jí)到客戶端來渲染。 上面結(jié)論中所提到的服務(wù)端性能優(yōu)化,主要就是通過首屏精準(zhǔn)化優(yōu)化實(shí)現(xiàn)的。 2)首屏圖片預(yù)加載 由于通天塔頁面的靈活性,開發(fā)者并不知道哪些樓層元素會(huì)出現(xiàn)在首屏,所以頁面中所有的圖片資源,統(tǒng)一設(shè)置為懶加載模式。而基于通天塔H5 SSR的架構(gòu),首頁在服務(wù)端渲染完成后下發(fā)給前端,前端只有在加載完JS后判斷圖片是否在首屏,在首屏的才開始加載圖片,這就會(huì)造成圖片必須要在JS加載執(zhí)行完成后才進(jìn)行加載,圖片坑位的白屏?xí)r間較長(zhǎng)。 基于以上圖片加載滯后的問題,前期我們做了第一個(gè)優(yōu)化是,在第一屏樓層之后插入一段內(nèi)聯(lián)JS,獲取頁面已加載的圖片元素,如果在首屏則先將首屏圖片的data-src置為src進(jìn)行加載,但發(fā)現(xiàn)以下問題,下面是一個(gè)測(cè)試Demo。
<!DOCTYPE html>
<html>
<head>
  <meta charset="UTF-8">
  <title>Document</title>
</head>
<body>
  <img data-src="/img-size.png" id="test" />
  <h1>我是測(cè)試代碼</h1>
  <script>
    (function() {
        var start = Date.now();
        console.log('start', start)
        var img = document.getElementById('test');
        img.onload = function() {
console.log('end', Date.now(), Date.now() - start);     // end - start > 2000ms
        }
        img.src = img.getAttribute('data-src');
    })();
</script>
  <h1>我是測(cè)試代碼22222</h1>
  <img src="/performance-cpu.jpg" />
  <script src="/test.js"></script>
</body>
</html>
其中test.js中很簡(jiǎn)單
console.log('start');
var start = Date.now();
for(;;) {
    if (Date.now() - start > 2000) {
        break;
    }
}
console.log('end');
京東通天塔頁面(京東通天塔使用方法及作用解析)

圖7:Demo頁加載執(zhí)行 從圖中可以看出這個(gè)圖片依然在JS執(zhí)行完畢后才加載。但我們發(fā)現(xiàn)performance-cpu.jpg這張圖片,由于瀏覽器對(duì)圖片資源預(yù)加載的緣故,沒被JS阻塞,基于瀏覽器對(duì)圖片的預(yù)加載,及上面做的首屏精準(zhǔn)化渲染,我們又進(jìn)行了一個(gè)優(yōu)化:在計(jì)算首屏樓層高度時(shí),給處于首屏的部分圖片元素打標(biāo),根據(jù)這個(gè)標(biāo)識(shí)在render渲染時(shí),對(duì)打標(biāo)的圖片不進(jìn)行懶加載處理,而直接用src,通過這個(gè)優(yōu)化,圖片將不被JS阻塞,提前了首屏圖片開始加載的時(shí)機(jī),減少了圖片坑位的白屏?xí)r間。 3)交互優(yōu)化 在通天塔活動(dòng)中,有許多包含多Tab的模板,如商品類模板,在之前的開發(fā)中,每次切換Tab我們都是銷毀之前Tab下的內(nèi)容,重新渲染新Tab下的內(nèi)容,這樣在重新切換回去的時(shí)候,還是需要重新渲染,造成頁面的卡頓?;诖?,我們將Tab渲染改成了增量渲染,這樣在切回上一個(gè)Tab的時(shí)候,白屏及渲染時(shí)間會(huì)大大減少。 優(yōu)化是持續(xù)性工作 在通天塔H5前端性能優(yōu)化的過程中,很大一部分是站在巨人的肩膀上進(jìn)行的,但光這些遠(yuǎn)遠(yuǎn)不夠,當(dāng)純技術(shù)優(yōu)化到一定程度后,更需要根據(jù)自己的業(yè)務(wù)特點(diǎn),從業(yè)務(wù)層面進(jìn)行優(yōu)化,這個(gè)優(yōu)化的效果可能更好。 通天塔前端的優(yōu)化在此告一段落,但優(yōu)化之路還遠(yuǎn)未結(jié)束,后續(xù)我們還會(huì)更進(jìn)一步,基于自身的業(yè)務(wù)以及一些新技術(shù),繼續(xù)深入優(yōu)化,同時(shí)也希望本文能給前端及后臺(tái)開發(fā)人員帶來一些新的想法。

聲明:本文由網(wǎng)站用戶香香發(fā)表,超夢(mèng)電商平臺(tái)僅提供信息存儲(chǔ)服務(wù),版權(quán)歸原作者所有。若發(fā)現(xiàn)本站文章存在版權(quán)問題,如發(fā)現(xiàn)文章、圖片等侵權(quán)行為,請(qǐng)聯(lián)系我們刪除。

(0)
上一篇 2023年3月17日 12:10:56
下一篇 2023年3月17日 12:20:59

相關(guān)推薦

發(fā)表回復(fù)

您的電子郵箱地址不會(huì)被公開。 必填項(xiàng)已用*標(biāo)注

主站蜘蛛池模板: 国产4区| 天天插天天插 | 亚洲欧美综合一区二区 | 国产高清一二三区 | 玖玖在线播放 | 亚洲精品美女久久久久99 | 亚洲精品动漫久久久久 | 香蕉av777xxx色综合一区 | 久草免费在线 | 日韩中文字幕电影 | 91高清免费看 | 91短视频黄 | 91视频一区二区 | 欧美在线一区二区三区四区 | 久久久久久久久久一区二区 | 福利视频免费观看 | 国产成人在线观看免费网站 | 欧美黄色网页 | 久久人人爽人人爽 | 看免费黄色一级片 | 日本a在线播放 | 少妇精品久久久久www蜜月 | 欧美精品一区视频 | 国产一区二区三区不卡在线观看 | 成人免费黄色 | 国产精品久久久久久久久久久不卡 | 一区二区三区在线视频播放 | 黄色成人在线视频 | 欧美a√| 毛片免费网址 | 91麻豆精品国产91久久久久久 | 国产精品午夜视频 | av看片| 国产精品一区二区av日韩在线 | 免费不卡视频 | 夜夜春影院 | 俄罗斯一级黄色毛片 | 日韩精品成人免费观看视频 | 中文字幕国产亚洲 | 日韩一区二区三区精品视频 | 尤物在线观看 |