石家莊橋西區(qū)網(wǎng)站制作公司您是否正在CDN / Edge上使用服務(wù)人員，例如進(jìn)行A / B測(cè)試？
在這一點(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í)，我們可以嘗試始終領(lǐng)先于客戶(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倍。”
