在這一點(diǎn)上,我們已經(jīng)很習(xí)慣在客戶(hù)端上運(yùn)行服務(wù)工作者,但是通過(guò)CDN在服務(wù)器上實(shí)現(xiàn)它們,我們也可以使用它們來(lái)調(diào)整邊緣性能。
例如,在A / B測(cè)試中,當(dāng)HTML需要為不同的用戶(hù)改變其內(nèi)容時(shí),我們可以使用CDN服務(wù)器上的Service Workers處理邏輯。我們還可以流式傳輸HTML重寫(xiě)以加速使用Google字體的網(wǎng)站。
服務(wù)人員安裝的時(shí)間序列。據(jù)
網(wǎng)站制作 Almanac稱(chēng),所有桌面頁(yè)面中只有0.44%注冊(cè)了服務(wù)工作者。(大型預(yù)覽)
優(yōu)化渲染性能。
通過(guò)CSS隔離來(lái)隔離昂貴的組件,例如,以限制瀏覽器樣式,畫(huà)布外導(dǎo)航的布局和繪畫(huà)或第三方小部件的范圍。確保在滾動(dòng)頁(yè)面或?yàn)樵卦O(shè)置動(dòng)畫(huà)時(shí)沒(méi)有滯后,并且始終保持每秒60幀的速度。如果這不可能,那么至少使每秒幀數(shù)保持一致,更好是60到15的混合范圍。使用CSS'will-change通知瀏覽器哪些元素和屬性將發(fā)生變化。
另外,還要評(píng)估運(yùn)行時(shí)渲染性能(例如,在DevTools中)。首先,請(qǐng)查看Paul Lewis的有關(guān)瀏覽器渲染優(yōu)化的免費(fèi)Udacity課程,以及Georgy Marchuk關(guān)于瀏覽器繪畫(huà)和
網(wǎng)站制作性能注意事項(xiàng)的文章。
如果您想更深入地研究該主題,Nolan Lawson在他的文章中分享了一些技巧,可以準(zhǔn)確地測(cè)量布局性能,Jason Miller也建議了其他技巧。我們也有Sergey Chikuyonok的一篇有關(guān)如何正確獲得GPU動(dòng)畫(huà)的文章。
注意:對(duì)GPU合成層的更改更便宜,因此,如果您僅通過(guò)opacity和觸發(fā)合成就可以擺脫困境transform,那么您將走上正確的道路。Anna Migas在有關(guān)“調(diào)試UI渲染性能”的演講中也提供了許多實(shí)用建議。
您是否優(yōu)化了渲染體驗(yàn)?
盡管組件如何在頁(yè)面上出現(xiàn)的順序以及我們?nèi)绾蜗驗(yàn)g覽器提供資產(chǎn)的策略很重要,但我們也不應(yīng)低估感知性能的作用。該概念涉及等待的心理方面,基本上在其他事情發(fā)生時(shí)使客戶(hù)保持忙碌或忙碌。這就是感知管理,搶先開(kāi)始,提早完成和容忍管理的地方。
這是什么意思呢?在加載資產(chǎn)時(shí),我們可以嘗試始終于客戶(hù)一步,因此在后臺(tái)發(fā)生大量事情時(shí),體驗(yàn)會(huì)很快。為了保持客戶(hù)的參與度,我們可以測(cè)試框架屏幕(實(shí)現(xiàn)演示)而不是加載指示器,添加過(guò)渡/動(dòng)畫(huà),并在沒(méi)有其他要優(yōu)化的地方基本欺騙UX。但是要當(dāng)心:在部署之前應(yīng)先測(cè)試骨架屏幕,因?yàn)橐恍y(cè)試表明骨架屏幕在所有指標(biāo)上的表現(xiàn)都更差。
您是否防止布局偏移和重新粉刷?
在感知性能領(lǐng)域可能的更具破壞性的經(jīng)驗(yàn)之一是布局轉(zhuǎn)移,或回流,造成重新調(diào)整圖像和視頻,網(wǎng)頁(yè)字體,注入廣告或者后期發(fā)現(xiàn)的腳本與實(shí)際內(nèi)容填入組件。結(jié)果,客戶(hù)可能開(kāi)始閱讀文章,而只是被閱讀區(qū)域上方的布局跳轉(zhuǎn)打斷。經(jīng)驗(yàn)常常是突然的并且令人迷惑:這可能是加載需要重新考慮的優(yōu)先事項(xiàng)的情況。
社區(qū)已經(jīng)開(kāi)發(fā)了一些技術(shù)和解決方法來(lái)避免回流。始終設(shè)置寬度 圖像上的高度和高度屬性,因此現(xiàn)代瀏覽器默認(rèn)情況下會(huì)分配該框并保留空間(Firefox,Chrome)。
對(duì)于圖像或視頻,我們都可以使用SVG占位符來(lái)保留將在其中顯示媒體的顯示框。這意味著當(dāng)您還需要保持其縱橫比時(shí),可以正確保留該區(qū)域。
除了不使用外部腳本進(jìn)行延遲加載圖像外,僅當(dāng)不支持本機(jī)延遲加載時(shí),才在加載外部腳本時(shí)考慮使用本機(jī)延遲加載或混合延遲加載。
如上所述,始終將網(wǎng)站制作字體重新粉刷分組并立即從所有后備字體過(guò)渡到所有網(wǎng)站制作字體-只需通過(guò)使用font-style-matcher調(diào)整行高和字體之間的間距來(lái)確保切換不會(huì)太突然。(請(qǐng)注意,盡管如此,調(diào)整也會(huì)因復(fù)雜的字體堆棧而變得復(fù)雜。)
為確保包含回流的影響,請(qǐng)使用Layout Instability API來(lái)測(cè)量布局穩(wěn)定性。有了它,您就可以計(jì)算出“累積布局偏移”(CLS)分?jǐn)?shù)并將其作為測(cè)試中的一項(xiàng)要求,因此,只要出現(xiàn)回歸,就可以跟蹤并修復(fù)它。
要計(jì)算布局平移分?jǐn)?shù),瀏覽器將查看視口大小以及兩個(gè)渲染幀之間視口中不穩(wěn)定元素的移動(dòng)。理想情況下,分?jǐn)?shù)應(yīng)接近0。Milica Mihajlija和Philip Walton對(duì)于CLS是什么以及如何進(jìn)行測(cè)量有很好的指導(dǎo)。這是衡量和保持可感知的性能并避免中斷的良好起點(diǎn),尤其是對(duì)于關(guān)鍵業(yè)務(wù)任務(wù)而言。
獎(jiǎng)勵(lì):如果您想減少重排和重繪,請(qǐng)查看Charis Theodoulou的“更小化DOM重排/布局打亂”指南和Paul Irish的“什么導(dǎo)致布局/重排”列表以及CSSTriggers.com(有關(guān)觸發(fā)布局,繪制的CSS屬性的參考表)和合成。
聯(lián)網(wǎng)和HTTP / 2
是否啟用OCSP裝訂?
通過(guò)在服務(wù)器上啟用OCSP裝訂,可以加快TLS握手的速度。創(chuàng)建了聯(lián)機(jī)證書(shū)狀態(tài)協(xié)議(OCSP),以替代證書(shū)吊銷(xiāo)列表(CRL)協(xié)議。兩種協(xié)議都用于檢查
SSL證書(shū)是否已被吊銷(xiāo)。但是,OCSP協(xié)議不需要瀏覽器花時(shí)間下載,然后在列表中搜索證書(shū)信息,因此減少了握手所需的時(shí)間。
您是否已采用IPv6?
由于我們的IPv4空間不足,并且主要的移動(dòng)網(wǎng)絡(luò)都在迅速采用IPv6(美國(guó)已達(dá)到50%的IPv6采用閾值),因此更好將您的DNS更新為IPv6,以確保未來(lái)的安全。只需確保在網(wǎng)絡(luò)上提供雙棧支持即可,它使IPv6和IPv4可以同時(shí)并行運(yùn)行。畢竟,IPv6不向后兼容。此外,研究表明,由于鄰居發(fā)現(xiàn)(NDP)和路由優(yōu)化,IPv6使這些網(wǎng)站的速度提高了10%至15%。
確保所有資產(chǎn)都通過(guò)HTTP / 2運(yùn)行。
在過(guò)去的幾年中,隨著Google向著更加安全的HTTPS網(wǎng)站發(fā)展,切換到HTTP / 2環(huán)境無(wú)疑是一項(xiàng)不錯(cuò)的投資。實(shí)際上,根據(jù)
網(wǎng)站制作 Almanac,所有請(qǐng)求中的54%已經(jīng)通過(guò)HTTP / 2運(yùn)行。
重要的是要了解HTTP / 2并不好,并且存在優(yōu)先級(jí)問(wèn)題,但是它得到了很好的支持,它不會(huì)隨處可見(jiàn)。而且,在大多數(shù)情況下,您更好這么做。
如果您仍在運(yùn)行HTTP,則更耗時(shí)的任務(wù)將是首先遷移到HTTPS,然后調(diào)整構(gòu)建過(guò)程以適應(yīng)HTTP / 2復(fù)用和并行化。對(duì)于本文的其余部分,我將假定您正在切換到或已經(jīng)切換到HTTP / 2。
根據(jù)網(wǎng)站制作 Almanac的數(shù)據(jù),到2019年底,所有請(qǐng)求中有54%通過(guò)HTTP / 2進(jìn)行了服務(wù)-正式標(biāo)準(zhǔn)化僅四年后。(圖片來(lái)源:網(wǎng)站制作年鑒)(大預(yù)覽)
正確部署HTTP / 2。
同樣,通過(guò)HTTP / 2提供資產(chǎn)到目前為止,您可以對(duì)資產(chǎn)的服務(wù)方式進(jìn)行部分改革,從而從中受益。您需要在包裝模塊和并行加載許多小模塊之間找到一個(gè)很好的平衡。歸根結(jié)底,更好的請(qǐng)求還是沒(méi)有請(qǐng)求,但是,目標(biāo)是在資產(chǎn)的快速首次交付和緩存之間找到一個(gè)平衡。
一方面,您可能希望避免將資產(chǎn)完全串聯(lián)在一起,而不是將整個(gè)接口分解為許多小模塊,將其壓縮為構(gòu)建過(guò)程的一部分并并行加載。一個(gè)文件的更改不需要重新下載整個(gè)樣式表或JavaScript。它還可以更大程度地減少解析時(shí)間,并使單個(gè)頁(yè)面的有效負(fù)載保持較低。
另一方面,包裝仍然很重要。通過(guò)使用許多小的腳本,整體壓縮將受到影響。大包的壓縮將受益于字典的重用,而單獨(dú)的小包則不會(huì)。有解決此問(wèn)題的標(biāo)準(zhǔn)方法,但目前還很遙遠(yuǎn)。其次,瀏覽器尚未針對(duì)此類(lèi)工作流程進(jìn)行優(yōu)化。例如,Chrome將觸發(fā)與資源數(shù)量成線(xiàn)性關(guān)系的進(jìn)程間通信(IPC),因此包括數(shù)百個(gè)資源將導(dǎo)致瀏覽器運(yùn)行時(shí)成本增加。
漸進(jìn)式CSS加載
為了獲得HTTP / 2的更佳效果,請(qǐng)考慮逐步加載CSS,這是Chrome的Jake Archibald建議的。
不過(guò),您可以嘗試逐步加載CSS。實(shí)際上,內(nèi)置CSS不再阻止Chrome的渲染。但是存在一些優(yōu)先級(jí)問(wèn)題,因此它不是那么簡(jiǎn)單,但是值得嘗試。
您可以擺脫HTTP / 2連接合并的束縛,它使您可以在受益于HTTP / 2的同時(shí)使用域分片,但是在實(shí)踐中很難做到這一點(diǎn),通常,這不是一個(gè)好習(xí)慣。同樣,HTTP / 2和Subresource Integrity并非總是如此。
該怎么辦?好吧,如果您使用的是HTTP / 2,則發(fā)送大約6–10個(gè)軟件包似乎是一個(gè)不錯(cuò)的妥協(xié)(對(duì)于舊版瀏覽器來(lái)說(shuō)還算不錯(cuò))。進(jìn)行實(shí)驗(yàn)和衡量,以找到適合您網(wǎng)站的平衡。
您的服務(wù)器和CDN是否支持HTTP / 2?
不同的服務(wù)器和CDN對(duì)HTTP / 2的支持不同。使用TLS快速嗎?檢查您的選項(xiàng),或快速查找服務(wù)器的性能以及可以支持的功能。
咨詢(xún)Pat Meenan對(duì)HTTP / 2優(yōu)先級(jí)的驚人研究(視頻),并測(cè)試服務(wù)器對(duì)HTTP / 2優(yōu)先級(jí)的支持。根據(jù)Pat的建議,建議啟用BBR擁塞控制并將tcp_notsent_lowatHTTP / 2優(yōu)先級(jí)設(shè)置為16KB,以便在Linux 4.9內(nèi)核及更高版本的內(nèi)核上可靠地工作(感謝Yoav!)。Andy Davies對(duì)跨瀏覽器,CDN和Cloud Hosting Services的HTTP / 2優(yōu)先級(jí)進(jìn)行了類(lèi)似的研究。
在此期間,請(qǐng)仔細(xì)檢查您的內(nèi)核是否支持TCP BBR,并在可能的情況下啟用它。當(dāng)前在Google Cloud Platform,Amazon Cloudfront,Linux(例如Ubuntu)上使用。
您的服務(wù)器和CDN是否支持HTTP over QUIC(HTTP / 3)?
如果您喜歡冒險(xiǎn)或前沿,則可能要檢查服務(wù)器或CDN是否支持HTTP over QUIC(也稱(chēng)為HTTP / 3)。雖然HTTP / 2進(jìn)行了重大改進(jìn),但在網(wǎng)絡(luò)速度慢或不可靠(大量數(shù)據(jù)包丟失)的情況下,它的性能并不是特別好。
為了解決這個(gè)問(wèn)題,Google一直在研究Google QUIC,這是Chrome今天用于許多Google服務(wù)的協(xié)議。然后,Google在2015年將許多學(xué)習(xí)成果帶到了IETF,該學(xué)習(xí)現(xiàn)在正在標(biāo)準(zhǔn)化。
QUIC和HTTP / 3更好,更防彈:具有更快的握手,更好的加密,更可靠的獨(dú)立流,更多加密,并且如果客戶(hù)端以前與服務(wù)器建立連接,則使用0-RTT。但是,這是相當(dāng)占用CPU的資源(在相同帶寬下,CPU使用率是2-3倍),未優(yōu)化UDP堆棧,并且硬件和TLS層存在一些未解決的問(wèn)題。
HTTP / 3有望在2020年初作為標(biāo)準(zhǔn)發(fā)布。Chrome和Safari確認(rèn)它們已經(jīng)具有內(nèi)部實(shí)現(xiàn),并且在Chrome Canary和Firefox Nightly中可以使用HTTP / 3。一些CDN已經(jīng)支持QUIC和HTTP / 3。Apache,nginx或IIS均不支持它,但它可能會(huì)在2020年發(fā)生變化。
TLS快了嗎?
TLS快速嗎?允許您在切換到HTTP / 2時(shí)檢查服務(wù)器和CDN的選項(xiàng)。(大型預(yù)覽)
是否正在使用HPACK壓縮?
如果您使用的是HTTP / 2,請(qǐng)仔細(xì)檢查服務(wù)器是否對(duì)HTTP響應(yīng)標(biāo)頭實(shí)施了HPACK壓縮,以減少不必要的開(kāi)銷(xiāo)。由于HTTP / 2服務(wù)器相對(duì)較新,因此它們可能不完全支持該規(guī)范,以HPACK為例。H2spec是一個(gè)很棒的工具(如果技術(shù)上非常詳細(xì)),可以檢查該工具。HPACK的壓縮算法令人印象深刻,并且有效。
確保服務(wù)器上的安全性是防彈的。
HTTP / 2的所有瀏覽器實(shí)現(xiàn)都在TLS上運(yùn)行,因此您可能要避免安全警告或頁(yè)面上的某些元素不起作用。仔細(xì)檢查您的安全標(biāo)頭設(shè)置是否正確,消除已知漏洞并檢查HTTPS設(shè)置。另外,請(qǐng)確保所有外部插件和跟蹤腳本都通過(guò)HTTPS加載,無(wú)法進(jìn)行跨站點(diǎn)腳本編寫(xiě),并且正確設(shè)置了HTTP Strict Transport Security標(biāo)頭和Content Security Policy標(biāo)頭。
測(cè)試與監(jiān)控
您是否優(yōu)化了審計(jì)工作流程?
聽(tīng)起來(lái)似乎沒(méi)什么大不了的,但是唾手可得的正確設(shè)置可以為您節(jié)省大量測(cè)試時(shí)間。考慮使用Tim Kadlec的Alfred Workflow for
網(wǎng)站制作PageTest將測(cè)試提交到網(wǎng)站制作PageTest的公共實(shí)例。實(shí)際上,網(wǎng)站制作PageTest具有許多晦澀的功能,因此花時(shí)間學(xué)習(xí)如何讀取網(wǎng)站制作PageTest Waterfall View圖表以及如何讀取
網(wǎng)站制作PageTest Connection View圖表以更快地診斷和解決性能問(wèn)題。
你也可以駕車(chē)從谷歌電子表格網(wǎng)站制作PageTest和一體化交通方便,性能和SEO分?jǐn)?shù)到您的特拉維斯設(shè)置的燈塔CI或直接進(jìn)入的網(wǎng)站制作Pack。
而且,如果您需要快速調(diào)試某些東西,但是您的構(gòu)建過(guò)程似乎非常緩慢,請(qǐng)記住,對(duì)于大多數(shù)JavaScript ,“空格刪除和符號(hào)處理占縮小代碼的大小的95%,而不是精心設(shè)計(jì)的代碼轉(zhuǎn)換。您可以只需禁用壓縮即可將Uglify構(gòu)建速度提高3到4倍。”
文章題目:成都高新區(qū)網(wǎng)站制作公司
轉(zhuǎn)載來(lái)源:http://www.rwnh.cn/news16/176616.html
網(wǎng)站建設(shè)、網(wǎng)絡(luò)推廣公司-創(chuàng)新互聯(lián),是專(zhuān)注品牌與效果的網(wǎng)站制作,網(wǎng)絡(luò)營(yíng)銷(xiāo)seo公司;服務(wù)項(xiàng)目有網(wǎng)站制作等
廣告
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶(hù)投稿、用戶(hù)轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請(qǐng)盡快告知,我們將會(huì)在第一時(shí)間刪除。文章觀(guān)點(diǎn)不代表本網(wǎng)站立場(chǎng),如需處理請(qǐng)聯(lián)系客服。電話(huà):028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時(shí)需注明來(lái)源:
創(chuàng)新互聯(lián)