[ad_1]
我們大多數人都進行了站點速度審核，或者看到其他人進行了審核。這些對於業務確實很有幫助，但是我經常發現它們的關注範圍很狹窄。通常，我們使用眾所周知的工具來拋出一堆東西，然後從那裡深入研究。
但是，如果我們進行更深入的研究，通常還有其他想法可以提高站點速度。我經常看到很多機會，這些機會從未在站點速度審核中涵蓋。大多數網站速度的提高都是一系列微小變化的結果，因此，在本文中，我將介紹一些我在任何網站速度審核中都從未見過的想法，所有這些都會有所作為。
圖像優化的另一個角度
考慮通過PNG優化的SVG
我最近想預訂一些票去看《冰雪奇緣2》（因為，嗯，我的孩子們……），所以降落了 這一頁。它使用三個SVG圖像作為傳輸圖標：
SVG圖像是矢量圖像，因此非常適合圖標之類的東西。如果您將圖像顯示為PNG，則可能需要向設計師詢問原始SVG， 因為可以節省很多。儘管並非總是更好，但使用SVG可以節省60％的文件大小。
在這種情況下，這些圖標每個大約為1.2k，因此它們很小。他們可能會飛抵現場速度審核的範圍（而且 Page Speed見解 要麼 GTMetrix 請在此頁面完全提及這些圖片）。
因此，您可能會想：「它們的總和少於5,000，您應該尋找更大的問題！」，但讓我們來看一下。首先，我們可以通過Jake Archibald的SVG來運行它們 壓縮工具;這是一個很棒的免費工具，在較大的SVG上，它可以發揮很大的作用。
在這種情況下，文件很小，因此您可能仍在思考「為什麼要打擾？」。該工具將它們壓縮到1240位元組到630位元組之間，而沒有任何質量損失，這是一個不錯的比率，但是並沒有節省多少。
但是，……既然我們已經壓縮了它們，我們在交付它們時可以有不同的想法……
內聯圖像
GTMetrix提出了有關內聯少量CSS或JS的建議，但未提及內聯圖像。圖像也可以內聯，有時這可能是正確的方法。
如果您認為即使是很小的圖像文件也需要完整的往返行程（ 對速度的真正影響），即使是小文件也可能需要很長時間。對於上面的Cineworld傳輸圖像，我模擬了「快速3G」連接並看到：
該站點未使用HTTP2，因此等待時間很長，然後映像（1.2kb）需要差不多600ms的時間載入（沒有HTTP2也意味著這會阻止其他請求）。這些圖像共有三個，因此它們之間可能會對頁面速度產生真正的影響。
但是，我們現在將它們壓縮到每個只有幾百個位元組，並且SVG圖像實際上是由標記組成的，類似於HTML：
實際上，您可以將SVG標記直接放入HTML文檔中！
如果我們對所有三個傳輸圖像都執行此操作，則從伺服器發送到我們的瀏覽器的此頁面的壓縮HTML將從31,182位元組增加到31,532位元組-所有3個圖像僅增加了350位元組！
總結一下：
- 我們的HTML請求增加了350個位元組，幾乎沒有任何內容
- 我們可以丟棄到伺服器的三個往返行程，這可以看到我們花費了大量時間
你們中的有些人可能已經意識到，如果圖像不是內聯的，則可以單獨緩存它們，因此以後的頁面請求將不需要重新提取它們。但是，如果我們考慮：
- 最初，每張圖片在網路上的大小約為1.5kb（它們不會壓縮SVG），其頂部約有350個位元組的HTTP標頭，總共傳輸了約5.5kb。因此，總的來說，我們減少了網路上的內容量。
- 這也意味著將需要20多個綜合瀏覽量才能從中進行緩存。
要點：考慮在哪裡有機會使用SVG而不是PNG。
要點：確保優化了SVG圖像，請使用我鏈接到的免費工具。
要點：內聯小圖像很有意義，並且可以大大提高性能。
注意：您還可以內聯PNG- 見本指南。
注意：對於優化的PNG / JPG圖像，請嘗試 海妖。
退縮，JavaScript！ HTML可以處理此問題…
如今，時常如此，由於提供了一種現成解決方案的JavaScript庫的盛行，我發現JavaScript被用於沒有它就可以實現的功能。更多的JS庫意味著更多的下載空間，可能需要更多往返伺服器中其他文件的往返時間，進而增加JavaScript執行時間和成本。
我很同情你如何做到這一點。通常會給開發人員提供較差的摘要/說明，而這些摘要/說明無法指定有關性能的任何內容，而只能指定功能。他們通常時間不多，因此很容易最終就丟掉一些東西。
但是，就可以使用HTML和/或CSS實現的功能而言，已經取得了許多進步。讓我們看一些例子。
帶有搜索的組合框
如今，具有文本搜索選項的下拉框是相當普遍的界面元素。我最近遇到的一篇文章介紹了如何使用 Select2 Javascript庫 列出這樣的清單：
這是一個有用的UI元素，可以為您的用戶提供幫助。但是，Select2庫中有一個JavaScript庫，而JavaScript庫又依賴於某些CSS和JQuery庫。這意味著要進行三次往返來收集一堆大小不一的文件：
- jQuery-101kb
- Select2 JavaScript-24kb
- Select2 CSS-3kb
對於網站速度而言，這不是理想的選擇，但是我們可以肯定值得這樣做，以便為用戶提供簡化的界面。
但是，實際上可以通過HTML數據列表元素立即使用此功能：
這允許用戶搜索列表或自由鍵入他們自己的響應，從而提供相同的功能。此外，它在智能手機上具有本機界面！
您可以在中看到這一點 這個codepen。
詳細信息/摘要
LonelyPlanet有一個漂亮的網站，我當時在看 關於西班牙的頁面，其中包含一個「閱讀更多」鏈接，大多數網路用戶會熟悉以下鏈接：
就像我看到的幾乎所有此實現一樣，他們都使用JavaScript庫來實現此目的，這又帶來了很多開銷。
但是，HTML有一對稱為詳細信息和摘要的內置標記，它們專門用於實現此功能。免費且以HTML格式原生提供。無需任何開銷，需要屏幕閱讀器的用戶可以更方便地訪問，同時還可以向Google傳達語義。
可以使用CSS以各種靈活的方式對這些標籤進行樣式設置，並重新創建我在那裡看到的大多數JS版本。
在此處查看一個簡單的演示： https://codepen.io/TomAnthony/pen/GRRLrmm
…和更多
有關可以使用HTML而不是JS實現的功能的更多示例，請查看以下鏈接：
- http://youmightnotneedjs.com/
- https://dev.to/ananyaneogi/html-can-do-that-c0n
總結：檢查您網站的功能，看看有什麼機會可以減少對本地Java / HTML選項的大型Javascript庫的依賴。
要點：請記住，不僅是有問題的JS文件的大小，而且是需要往返的次數。
注意：在某些情況下，您應該使用JS解決方案，但是權衡利弊很重要。
網路調整
每次瀏覽器必須從伺服器收集資源時，它都必須通過Internet發送消息並返回。它的速度受光速的限制。這聽起來像是一件荒謬的事情，但它意味著即使很小的請求也會增加頁面載入時間。如果您沒有找到上面的鏈接，我的帖子將說明HTTP2 更詳細地討論這個問題。
我們可以採取一些措施來幫助縮短這些請求的距離或減少所需的往返次數。這些稍微有點技術性，但是可以取得一些真正的勝利。
TLS 1.3
TLS（或SSL）是用於保護HTTPS連接的加密技術。從歷史上看，在瀏覽器和伺服器之間進行了兩次往返來設置該加密-如果用戶距伺服器50毫秒，則每個連接200毫秒。請記住，Google歷史上會建議 瞄準200ms 提供HTML（在最近的更新中，這似乎有些放鬆）；您在這裡浪費了很多時間。
最近定義的TLS 1.3標準將該過程從兩次往返減少到一次，這可以節省用戶最初連接到您的網站的寶貴時間。
向您的技術團隊諮詢有關遷移到TLS 1.3的信息；不支持該功能的瀏覽器將毫無問題地回退到TLS 1.2。所有這些都在幕後，而不是任何形式的遷移。沒有理由不這樣做。
如果您使用的是CDN，那麼只需打開CDN即可簡單。
您可以使用 這個工具 檢查您已啟用的TLS版本。
QUIC / HTTP 3
在過去的2-3年中，我們已經看到許多站點從HTTP 1.1遷移到HTTP 2，這是一個幕後升級，可以真正提高速度（如果您想了解更多，請參見上面的鏈接）。 ）。
緊隨其後的是，出現了一對新興的標準，稱為QUIC + HTTP / 3，可進一步優化瀏覽器與伺服器之間的連接，從而進一步減少所需的往返行程。
對這些功能的支持才剛剛開始變得可行，但是如果您是CloudFlare的客戶，則可以在今天和未來6個月內啟用Chrome和Firefox支持，從而使您的用戶的速度得到提高。
在這裡閱讀更多： https://blog.cloudflare.com/http3-the-past-present-and-future/
超級路由
當用戶連接到您的網站時，他們必須從任何位置打開到您的伺服器（或CDN）的網路連接。如果您將互聯網想像成一系列道路，那麼您可以想像它們需要跨這些道路「開車」到您的伺服器。但是，這意味著擁塞和交通堵塞。
事實證明，一些大型雲公司擁有自己的私家路，這些私家路的坑窪更少，流量減少並且速度限制得到改善。如果只有您的網站訪問者可以訪問這些道路，他們可以更快地「開車」向您！
好吧，你猜怎麼著？他們能！
對於CloudFlare，他們通過他們的用戶提供此訪問許可權 阿哥 產品，而如果您完全使用AWS，則可以使用它們 全球加速器。這樣一來，對您網站的請求就可以利用其專用網路並提高速度。如果您已經是客戶，兩者都是非常便宜的。
要點：如果您使用CDN，則其中許多此類好處都非常容易獲得。如果尚未使用CDN，則應該使用CDN。 CloudFlare是一個不錯的選擇，如果您使用的是AWS，那麼CloudFront也是如此。如果您更像是專業人士，那麼它們是可配置性最高的。
要點：TLS 1.3現在得到了廣泛的支持，並為新連接提供了顯著的速度改進。
要點：QUIC / HTTP3才剛剛開始獲得支持，但是在接下來的幾個月中，它將廣泛推廣。 QUIC包含TLS 1.3的優點以及更多優點。如今，典型的HTTP2連接需要3次往返才能打開。 QUIC只需要一個！
要點：如果您使用的是CloudFlare或AWS，則有可能僅通過翻轉開關即可打開智能路由功能來提高速度。
讓CSS做更多
上面我談到了HTML如何具有內置功能，您可以利用這些功能來節省對「本地滾動」解決方案的依賴，從而需要更多代碼（和瀏覽器方面的處理）來實現。在這裡，我將討論一些CSS可以為您做同樣的例子。
重用圖像
通常，您會發現在整個頁面中的多個位置使用相似圖像的頁面。例如，徽標上不同顏色的變體，或指向兩個方向的箭頭。作為唯一資產（無論它們多麼相似），每個都需要單獨下載。
回到上面尋找電影票的地方 這一頁，我們可以看到帶有左右箭頭的輪播：
與上面使用的邏輯類似，儘管這些映像文件很小，但它們仍需要往返才能從伺服器獲取。
但是，箭頭是相同的-只是指向相反的方向！我們很容易使用CSS的轉換功能在兩個方向上使用一個圖像：
你可以退房 這個codepen 舉個例子
另一個例子是，同一徽標在頁面的不同部分以不同的樣式出現；通常它們會載入多個變體，這是不必要的。 CSS可以通過多種方式為徽標重新著色：
有一個 Codepen在這裡 展示這種技術的作用。如果您想計算達到任意顏色所需的CSS過濾器值，請查看此驚人的結果 顏色計算器。
互動（例如菜單和標籤）
通常，導航元素（如菜單和選項卡）是用JavaScript實現的，但是這些也可以用純CSS完成。查看 這個codepen 例如：
動畫製作
CSS3在CSS中引入了許多強大的動畫功能。通常，它們不僅比JavaScript版本快，而且還可以更加平滑，因為它們可以在操作系統的本機代碼中運行，而不必執行相對較慢的Javascript。
查看 打Bird鳥 舉一個例子：
您可以在中找到更多 本文。 CSS動畫可以以相對較低的性能成本為頁面添加很多字元。
…和更多
有關使用純CSS解決方案可以實現的功能的更多示例，請查看：
- http://youmightnotneedjs.com/
- https://dev.to/ananyaneogi/css-can-do-that-18g7m
要點：使用CSS優化必須使用旋轉或過濾器載入的文件數。
要點：CSS動畫可以在頁面上添加字元，並且所需資源通常少於JavaScript。
要點：CSS完全能夠實現許多互動式UI元素。
總結
希望您發現這些示例本身很有用，但是我想說的更廣泛的一點是，我們所有人都應該嘗試更多地考慮站點速度。特別重要的是減少伺服器所需的往返次數；即使是小型資產也需要一些時間來獲取，並且可能會對性能（尤其是移動設備）產生顯著影響。
此處提供的想法比我們討論的要多得多，因此，如果您遇到其他問題，請務必跳入評論。