近年來，越來越多的優化前端專案的平台提供了自架或代理第三方資源的機會。 Akamai 允許您設置 用於自行產生的 URL。 Cloudflare 擁有 Edge Workers 技術。 法斯特嗪可以 頁面上的 URL，以便它們指向位於網站主網域上的第三方資源。
如果您知道專案中使用的第三方服務不會經常更改，並且將它們交付給客戶的流程可以改進，那麼您可能正在考慮代理此類服務。 透過這種方法，您可以很好地使這些資源更接近您的用戶，並在客戶端獲得對其快取的更完整的控制。 此外，這還可以保護用戶免受第三方服務「崩潰」或其效能下降造成的麻煩。
好：性能提高
自託管他人的資源可以以非常明顯的方式提高效能。 瀏覽器不需要再次存取DNS，不需要與第三方網域建立TCP連線和執行TLS握手。 透過比較以下兩個圖，您可以了解自託管其他人的資源如何影響效能。
第三方資源是從外部來源下載的（取自 )
第三方資源與網站其他資料存放在同一位置（取自 )
這種情況也得到了改善，因為瀏覽器將使用對已與主網域建立的 HTTP/2 連線的資料進行多路復用和優先排序的功能。
如果您不託管第三方資源，那麼由於它們將從與主網域不同的網域加載，因此無法對它們進行優先排序。 這將導致它們相互競爭客戶端的頻寬。 這可能會導致對於建立頁面至關重要的內容的載入時間比理想情況下可實現的時間長得多。 有關 HTTP/2 優先順序的討論很好地解釋了這一切。
可以假設在外部資源連結中使用屬性 preconnect 將有助於解決問題。 然而，如果這些通往不同網域的連結太多，實際上可能會在最關鍵的時刻使通訊線路超載。
如果您自己託管第三方資源，您可以控制如何將這些資源提供給客戶端。 也就是說，我們正在討論以下內容：
- 您可以確保使用最適合每個瀏覽器的資料壓縮演算法（Brotli/gzip）。
- 您可以增加通常不是特別長的資源的快取時間，即使是最知名的提供者也是如此（例如，GA 標記的相應值設定為 30 分鐘）。
您甚至可以將相關內容合併到快取管理策略（URL 雜湊、版本控制等）中，將資源的 TTL 延長至一年。 我們下面會談到這一點。
▍防止第三方服務運作中斷或關閉
自託管第三方資源的另一個有趣的方面是，它允許您減輕與第三方服務中斷相關的風險。 假設您正在使用的第三方 A/B 測試解決方案是作為在頁面頭部載入的阻止腳本實現的。 該腳本加載緩慢。 如果相應的腳本載入失敗，頁面將為空。 如果載入時間很長，頁面的顯示就會有很長的延遲。 或者，假設該項目使用從第三方 CDN 資源下載的程式庫。 讓我們想像一下該資源在某個國家遇到了故障或被阻止。 這樣的情況會導致違反網站邏輯。
要了解當某些外部服務不可用時您的網站如何運作，您可以使用 SPOF 部分 .
pagetest.org 上的 SPOF 部分
▍瀏覽器中快取素材的問題怎麼辦？ （提示：這是一個神話）
您可能認為使用公共 CDN 會自動帶來更好的資源效能，因為這些服務擁有相當高品質的網路並且分佈在世界各地。 但其實一切都有點複雜。
假設我們有幾個不同的網站：website1.com、website2.com、website3.com。 所有這些網站都使用 jQuery 函式庫。 我們使用 CDN 將其連接到它們，例如 - googleapis.com。 您可以期望瀏覽器下載並快取該庫一次，然後在所有三個網站上使用它。 這可以減少網路負載。 也許這可以讓您在某個地方省錢並幫助提高資源效能。 從實際角度來看，一切看起來都不一樣。 例如，Safari 有一個功能稱為 ：快取根據文件來源和第三方資源來源採用雙鍵。 關於這個主題的好文章。
舊研究 и ，以及最近的 Paul Calvano 表示，資源在瀏覽器快取中儲存的時間並不像我們預期的那麼長：「專案本身的資源和第三方資源的快取時間之間存在嚴重差距。 我們正在談論 CSS 和網頁字體。 即95%的原生字體的快取壽命超過一周，而50%的第三方字體的快取壽命不到一周！ 這為網頁開發人員提供了一個令人信服的理由來自行託管字體文件！”
因此，如果您託管其他人的內容，您將不會注意到瀏覽器快取導致的任何效能問題。
現在我們已經介紹了第三方自架的優勢，接下來我們來談談如何區分這種方法的好壞。
壞處：細節決定成敗
如果未確保正確快取此類資源，則無法自動將第三方資源移至您自己的網域。
這裡的主要問題之一是快取時間。 例如，版本資訊包含在第三方腳本名稱中，如下所示： jquery-3.4.1.js。 這樣的檔案將來不會改變，因此不會導致其快取出現任何問題。
但是，如果在處理文件時未使用某些版本控制方案，則快取的腳本（其內容變更而檔案名稱保持不變）可能會過時。 這可能是一個嚴重的問題，因為它不允許將自動安全性補丁新增至客戶端需要盡快接收的腳本。 開發人員必須努力更新快取中的此類腳本。 此外，這可能會導致應用程式失敗，因為客戶端上使用的快取程式碼與專案的伺服器部分設計的最新版本的程式碼不同。
確實，如果我們談論經常更新的材料（標籤管理器、A/B 測試解決方案），那麼使用 CDN 工具快取它們是一項可以解決的任務，但要複雜得多。 Commanders Act（一種標籤管理解決方案）等服務在發布新版本時使用 Webhooks。 這使您能夠強制刷新 CDN 上的緩存，或者更好的是，能夠強制更新哈希值或 URL。
▍向客戶自適應地交付材料
另外，當我們談論快取時，我們需要考慮到CDN上使用的快取設定可能不適合某些第三方資源。 例如，此類資源可以使用使用者代理嗅探（自適應服務）技術來為特定瀏覽器提供專門針對這些瀏覽器最佳化的內容版本。 這些技術依賴正規表示式或 HTTP 頭資訊資料庫來確定瀏覽器的功能。 User-Agent。 一旦他們知道自己正在使用哪種瀏覽器，他們就會為其提供專門設計的材料。
在這裡你可以記住兩項服務。 第一個是 googlefonts.com。 第二個是polyfill.io。 Google Fonts 服務根據瀏覽器的功能，為特定資源提供各種 CSS 程式碼（使用 woff2 資源提供連結） unicode-range).
以下是從不同瀏覽器進行的幾個 Google Fonts 查詢的結果。
Chrome 中的 Google Fonts 查詢結果
從 IE10 執行的 Google Fonts 查詢的結果
Polyfill.io 只提供瀏覽器所需的 polyfill。 這樣做是出於性能原因。
例如，讓我們來看看如果從不同的瀏覽器執行以下請求會發生什麼：
回應從 IE10 執行的此類請求，將收到 34 KB 的資料。 從 Chrome 執行的答案將為空。
憤怒：一些隱私考慮
這一點按順序排在最後，但也同樣重要。 關鍵是，在專案主網域或其子網域上自託管第三方資源可能會危害使用者的隱私並對主 Web 專案產生負面影響。
如果您的 CDN 系統配置不正確，您最終可能會將網域的 cookie 傳送到第三方服務。 如果沒有在 CDN 層級組織適當的過濾，那麼您的會話 cookie 通常無法在 JavaScript 中使用（使用 httponly），可能會發送到國外主機。
這正是 Eulerian 或 Criteo 等追蹤器可能發生的情況。 第三方追蹤器可能已在 cookie 中設定了唯一識別碼。 如果它們是網站材料的一部分，那麼當使用者使用不同的網路資源時，他們可以自行讀取識別碼。
如今，大多數瀏覽器都包含針對此類追蹤器行為的保護措施。 因此，追蹤器現在使用技術 ，偽裝成自己的腳本用於各種項目。 也就是說，追蹤器允許網站所有者將 CNAME 添加到特定網域的設定中，該網域的位址通常看起來像一組隨機字元。
儘管不建議讓網站 cookie 對所有子網域都可用（例如 - *.website.com），但許多網站都會這樣做。 在這種情況下，此類 cookie 會自動傳送到偽裝的第三方追蹤器。 結果，我們不能再談論任何隱私。
此外，HTTP 標頭也會發生同樣的情況 ，它們僅發送到主域，因為它們可用於創建 用戶。 確保您使用的 CDN 服務正確過濾這些標頭。
結果
如果您打算很快實現第三方資源的自託管，我給您一些提示：
- 託管您最重要的 JS 庫、字體和 CSS 文件。 這將降低因第三方服務故障而導致網站重要資源不可用而導致網站故障或效能下降的風險。
- 在 CDN 上快取第三方資源之前，請確保在命名其檔案時使用某種版本控制系統，或者您可以在發布新版本時透過手動或自動重置 CDN 快取來管理這些資源的生命週期。劇本。
- 請務必小心您的 CDN、代理伺服器和快取設定。 這將允許您防止向您的項目或標頭發送 cookie
Client-Hints第三方服務。
親愛的讀者！ 您是否在您的伺服器上託管對您的專案運作極為重要的其他人的資料？
來源： www.habr.com