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