跳到主要內容

最佳實務

效能

在 GitHub 上編輯此頁面

SvelteKit 預設會執行許多工作，以讓您的應用程式效能最佳化

  • 程式碼拆分，因此只會載入您當前頁面所需的程式碼
  • 資源預載入，因此可以防止「瀑布式」（檔案要求其他檔案）
  • 檔案雜湊，因此您的資源可以永久快取
  • 要求合併，因此從不同伺服器 load 函式擷取的資料會分組成單一 HTTP 要求
  • 平行載入，因此不同的通用 load 函式會同時擷取資料
  • 資料內嵌，因此伺服器渲染期間使用 fetch 進行的請求可以在瀏覽器中重播，而不會發出新的請求
  • 保守無效化，因此只有在必要時才會重新執行 load 函式
  • 預先渲染（如有必要，可以針對每個路由進行設定），因此可以立即提供不含動態資料的頁面
  • 連結預載入，因此可以熱切預期客戶端導覽的資料和程式碼需求

儘管如此，我們（目前）無法消除所有導致速度變慢的來源。若要發揮最大的效能，您應注意下列提示。

診斷問題

Google 的 PageSpeed Insights 和（針對更進階分析）WebPageTest 是了解已部署到網際網路的網站效能特性的絕佳方式。

您的瀏覽器也包含有用的開發人員工具，用於分析您的網站，無論是已部署或是在本機執行

請注意，在 dev 模式下於本機執行您的網站會表現出與您的正式應用程式不同的行為，因此您應在建置後於 預覽 模式中進行效能測試。

工具化

如果您在瀏覽器的網路標籤中看到 API 呼叫花費很長的時間，而且您想要了解原因，您可以考慮使用 OpenTelemetry 或 Server-Timing 標頭 等工具來為您的後端進行工具化。

最佳化資產

影像

縮小影像檔案大小通常是您能對網站效能進行的最有影響力的變更之一。Svelte 提供了 影像 頁面中詳細說明的 @sveltejs/enhanced-image 套件，讓這項工作變得更輕鬆。此外，Lighthouse 可用於找出最嚴重的問題。

影片

影片檔案可能非常大，因此應特別注意確保它們已最佳化

  • 使用 Handbrake 等工具壓縮影片。考慮將影片轉換為網頁友善的格式，例如 .webm 或 .mp4。
  • 您可以 延遲載入 位於折頁以下的影片，方法是使用 preload="none"（但請注意，這會在使用者確實啟動影片時降低播放速度）。
  • 使用 FFmpeg 等工具從靜音影片中移除音軌。

字型

當使用者造訪網頁時，SvelteKit 會自動預載關鍵的 .js 和 .css 檔案，但它不會預設預載字型，因為這可能會導致下載不必要的檔案（例如 CSS 參照但實際上未在目前網頁中使用的字重）。話雖如此，正確預載字型會對您的網站感覺有多快產生很大的影響。在您的 handle 鉤子中，您可以呼叫 resolve，並使用包含您的字型的 preload 篩選器。

您可以透過子集化字體來縮小字體檔案的大小。

縮小程式碼大小

Svelte 版本

我們建議執行 Svelte 的最新版本。Svelte 4 比 Svelte 3 更小且更快。（Svelte 5 預覽版 更小且更快，但我們不建議您升級到此版本，直到它準備好投入生產。）

套件

rollup-plugin-visualizer 有助於找出哪些套件對您網站的大小貢獻最多。您也可以透過手動檢查建置輸出（在您的Vite 設定檔中使用 build: { minify: false } 來讓輸出可讀，但記得在部署您的應用程式之前取消此設定），或透過瀏覽器開發人員工具的網路標籤來尋找移除程式碼的機會。

外部指令碼

請盡量減少在瀏覽器中執行的第三方指令碼數量。例如，請考慮使用伺服器端實作，而不是使用基於 JavaScript 的分析，例如許多平台提供的平台，包括 Cloudflare、Netlify 和 Vercel。

若要在網頁工作執行序中執行第三方指令碼（避免封鎖主執行緒），請使用 Partytown 的 SvelteKit 整合。

選擇性載入

使用靜態 import 宣告匯入的程式碼會自動與您頁面的其他部分一起打包。如果您只在符合某些條件時需要某段程式碼，請改用動態 import(...) 形式。

您可以使用連結選項熱切預載入必要的程式碼和資料，以加快用戶端導覽。當您建立新的 SvelteKit 應用程式時，此功能會在 <body> 元素上預設設定。

對於不需要立即載入的慢速載入資料，從 load 函式傳回的物件可以包含承諾，而不是資料本身。對於伺服器 load 函式，這將導致資料在導覽（或初始頁面載入）後 串流 進來。

最大的效能殺手之一就是所謂的瀑布流，這是一系列依序發出的請求。這可能發生在伺服器或瀏覽器中。

  • 當 HTML 請求 JS，而 JS 請求 CSS，而 CSS 請求背景圖片和網路字型時，就會在瀏覽器中發生資源瀑布流。SvelteKit 會透過新增 modulepreload 標籤或標頭，在很大程度上為你解決這類問題，但你應該查看 開發人員工具中的網路標籤，以檢查是否需要預先載入其他資源。如果你使用網路 字型，請特別注意這一點，因為它們需要手動處理。
  • 如果通用 load 函式呼叫 API 以擷取目前使用者，然後使用該回應中的詳細資料來擷取已儲存項目清單，然後使用該回應來擷取每個項目的詳細資料，瀏覽器最終將會發出多個依序請求。這對效能來說是致命的，特別是對於實際上距離你的後端很遠的使用者。透過在可能的情況下使用 伺服器 load 函式 來避免這個問題。
  • 伺服器 load 函式也不免疫於瀑布流（儘管它們的成本低得多，因為它們很少涉及高延遲的往返行程）。例如，如果你查詢資料庫以取得目前使用者，然後使用該資料進行第二次查詢以取得已儲存項目清單，通常發出具有資料庫聯結的單一查詢會更有效能。

主機

你的前端應該位於與後端相同的資料中心，以將延遲降至最低。對於沒有中央後端的網站，許多 SvelteKit 介面卡支援部署到邊緣，這表示從附近的伺服器處理每個使用者的請求。這可以大幅減少載入時間。有些介面卡甚至支援 根據路由設定部署。你也應該考慮從 CDN（通常是邊緣網路）提供圖片 — 許多 SvelteKit 介面卡的主機將自動執行此操作。

確保你的主機使用 HTTP/2 或更新版本。Vite 的程式碼分割會建立許多小型檔案以提高快取性，這會帶來絕佳的效能，但這假設你的檔案可以使用 HTTP/2 並行載入。

進一步閱讀

在大部分情況下，建立效能良好的 SvelteKit 應用程式與建立任何效能良好的網路應用程式相同。您應該可以將一般效能資源中的資訊套用至您建立的任何網路體驗，例如 核心網路指標。

上一個 封裝
下一個 圖片