在線采購 js 腳本和最佳實踐有多穩健

Question

我來自R背景，我開始學習一些javascript用於數據可視化目的（想想leaflet ， d3 ， chart ，...）。

許多教程和模板都建議加載包、CSS 甚至直接來自在線資源的數據，我試圖解決這個問題。 例如https://leafletjs.com/examples/quick-start/推薦：

在為 map 編寫任何代碼之前，您需要在頁面上執行以下准備步驟：

 Include Leaflet CSS file in the head section of your document: <link rel="stylesheet" href="https://unpkg.com/leaflet@1.7.1/dist/leaflet.css" integrity="sha512-xodZBNTC5n17Xt2atTPuE1HxjVMSvLVW9ocqUKLsCC5CXdbqCmblAshOMAS6/keqq/sMZMZ19scR4PsZChSR7A==" crossorigin=""/> Include Leaflet JavaScript file after Leaflet's CSS: <:-- Make sure you put this AFTER Leaflet's CSS --> <script src="https.//unpkg.com/leaflet@1.7.1/dist/leaflet.js" integrity="sha512-XQoYMqMTK8LvdxXYG3nZ448hOEQiglfqkJs1NOQV44cWnUrBc8PkAOcXy20w0vlaXaVUearIOBhiXZ5V3ynxwA==" crossorigin=""></script>

這並不是說您也不能在R中做那樣的事情。 但是，來自“ R文化”，我已經習慣了我擁有每個 package 和我的代碼所依賴的數據的本地“硬拷貝”的感覺。 然后，當我發布我的代碼時（例如，當我發布一個Shiny應用程序時），所有必需的依賴項都會立即發布，因此它可以獨立運行。 我了解服務器存儲空間方面的缺點，但我的感覺是這可能會更快且更不可靠。

我想知道我在javascript中對在線采購及其權衡的理解是否正確，如果是這樣，解決潛在缺點的最佳做法是什么。 尤其：

• 我是否正確理解像https://unpkg.com/leaflet@1.7.1/dist/leaflet.js或https://unpkg.com/leaflet@1.7.1/dist/leaflet.css這樣的依賴項每次都會重新加載我刷新頁面？
• 因此，該頁面依賴於那些沒有中斷的鏈接，對嗎？ 或者是否有一些我不知道的內部機制可以避免這種浪費的重新加載和有風險的依賴？
• 如果沒有，人們是否只能忍受鏈接中斷的風險？ 或者最好的做法是保留腳本的本地副本，例如https://unpkg.com/leaflet@1.7.1/dist/leaflet.js而不是在本地獲取它們？ 甚至，是否還有另一種最佳實踐，例如使用“更安全的提供程序”作為依賴項的來源（我是否正確理解這是https://www.jsdelivr.com/ 等服務的作用？ ）？

Answer 1

我是否正確理解像https://unpkg.com/leaflet@1.7.1/dist/leaflet.js或https://unpkg.com/leaflet@1.7.1/dist/leaflet.css這樣的依賴項每次都會重新加載我刷新頁面？

HTTP號客戶端執行緩存。

因此，該頁面依賴於那些沒有中斷的鏈接，對嗎？

是的。 （其中“破壞”包括“被防火牆阻止”（對於中國用戶來說是一個特殊問題，他們經常發現他們可以訪問網站但 JS 不起作用，因為它托管在被防火牆阻止的地方）和“ CDN 服務器被惡意接管”）

人們只是生活在鏈接中斷的風險中嗎？

是的。 風險是相對的。 通常會選擇 CDN，因為提供商值得信賴。

---

潛在的好處包括通過使用 邊緣服務器的 CDN 更快地訪問 JS，以及（至少對於流行的庫）客戶端可能已經緩存了數據，因為另一個站點使用了相同的庫。

您還使用 CDN 主機的帶寬而不是您自己的帶寬來為 JS 提供服務，這可以節省成本。

Answer 2

我是否正確理解像https://unpkg.com/leaflet@1.7.1/dist/leaflet.js或https://unpkg.com/leaflet@1.7.1/dist/leaflet.css這樣的依賴項每次都會重新加載我刷新頁面？

是和不是。 這里重要的是緩存。 瀏覽器會緩存已經加載的資源。 因此，如果用戶進入頁面並反復點擊刷新，他們只會下載這些資源一次，並且每次重新加載都將使用緩存的版本。 因此，不，它們不會每次都重新加載。

但是，任何時候用戶清除緩存或新用戶進來時他們的緩存中沒有資源，然后文件將被下載。 瀏覽器的緩存過期不是完全可預測的，因為它在很大程度上由用戶控制。 但是，如果用戶今天訪問並在下周使用相同的瀏覽器再次訪問，他們的緩存中可能仍會保留該項目。 然而，如果他們的緩存被刷新，或者他們使用不同的瀏覽器，或者不同的機器，或者訪問的是完全不同的用戶，那么是的——他們會再次加載資源。

因此，該頁面依賴於那些沒有中斷的鏈接，對嗎？ 或者是否有一些我不知道的內部機制可以避免這種浪費的重新加載和有風險的依賴？

內部機制是從上面緩存的。 但是，如果資源鏈接因任何原因被刪除，則該頁面將無法使用它。 這可能是因為：

• 鏈接的來源不再有效。
• 源被防火牆或其他機制阻止，因此用戶無法訪問它。
• 用戶使用了一些阻止機制，如廣告攔截器或腳本攔截器擴展，這意味着他們已經選擇阻止對某些資源的請求。

在所有這些情況下，結果都是相似的：如果用戶擁有所需資源的緩存副本，則他們可能可以訪問頁面的全部功能。 否則，他們不能使用它們。 不會執行腳本文件，不會應用樣式表，不會顯示圖像等。

解決這些問題的方法各不相同：

• 對於無效鏈接，您需要找到一個新的來源，甚至可能自己托管。
• 對於被阻止的資源，您可能需要找到阻止機制可接受的托管站點。 自托管可能是一種選擇。
• 如果用戶阻止了您的腳本，他們很可能需要取消阻止它們。 盡管上述兩種方法的組合也可能有效——在不以廣告聞名的域上托管可能會避免被阻止，並且自托管也可能有效。 至少在 uMatrix 的情況下——默認情況下插件會阻止頁面外部的所有腳本（極少數例外）。 如果腳本來自同一個域，則默認情況下 uMatrix 將允許它們。

如果沒有，人們是否只能忍受鏈接中斷的風險？ 或者最好的做法是保留腳本的本地副本，例如https://unpkg.com/leaflet@1.7.1/dist/leaflet.js而不是在本地獲取它們？

這里基本上有兩種方法。 每個都有自己的優點和缺點。 快速細分是：

• 您可以接受外部托管的資源。

  • 優勢：有幾個大的content delivery.networks（CDN），比如unpkg或者jsdelivr。 它們因其可靠性而被廣泛使用。 此外，一些圖書館可能會提供他們自己的 CDN - 例如，jQuery 就是這樣做的。 從 CDN 獲取資源可以節省寬度和空間，但也可以提高加載速度。 CDN 的速度可能比您的托管服務更快。 此外，對於廣泛使用的圖書館，CDN 副本可能會緩存在訪問與您使用相同 CDN 副本的另一個站點的用戶站點上。
  • 缺點：它確實會讓您依賴您無法控制的資源。 大型 CDN 是可靠的，但如果發生任何事情，您仍然無法直接控制。 如果您使用較小的 CDN（例如，庫特定或其他），那么您沒有關於其可靠性的數據。 如果外部鏈接失效，您的網站將無法運行，直到它被修復，這可能需要幾天的時間——您必須了解它，弄清楚發生了什么變化，希望能找到一個替代鏈接，更新網站。 如果找不到直接替代品，則可能需要進行更多更改。

• 您可以自己托管資源。

  • 優勢：您可以完全控制何時以及如何存儲內容。 您甚至可以以某種方式處理資源以幫助您的應用程序。 可以縮小腳本，可以縮放圖像並將其大小調整為幾種不同的大小，以優化不同位置的顯示（例如，圖標、小圖像和全尺寸圖像）。
  • 缺點：占用更多空間，占用更多帶寬。 此外，現在您必須管理所有這些資源並確保它們存在、可用等。

您當然也可以使用混合方法。 托管一些資源，從外部使用其他資源。 取決於您希望對您的應用程序執行什么操作以及您希望保留何種級別的控制權以及您希望付出多少額外的努力和成本。

綜上所述，對於許多小項目來說，選擇哪條路徑並不重要。 如果您只使用少數幾個庫，那么無論您是從 CDN 使用它們還是自己托管它們都無關緊要。 只要選擇了可靠的 CDN 提供商，中斷的可能性就很小。 如果您托管這些資源，它們很可能會占用幾百 KB（如果是的話）。

如果您的項目增長並且您擁有的依賴項列表開始變得越來越大，那么可能是時候進行評估並決定如何托管它們以及如何使用它們了。 這個問題沒有單一的答案，它可能取決於你已經擁有的東西。 也許您的主機空間很小。 或者您按下載的兆字節付費。 在這種情況下，外部托管會更有意義。 或者，也許您自己有一個強大的存儲選項，並且您有信心可以確保應用程序的可用性，在這種情況下，自托管可能更可取