Google sử dụng công nghệ AI để dịch nội dung sang ngôn ngữ bạn ưu tiên. Bản dịch bằng AI có thể có lỗi.

Cải thiện hiệu suất tải trang Next.js và Gatsby với tính năng phân đoạn chi tiết

Chiến lược phân đoạn webpack mới hơn trong Next.js và Gatsby giúp giảm thiểu mã trùng lặp để cải thiện hiệu suất tải trang.

Houssein Djirdeh

Chrome đang hợp tác với các công cụ và khung trong hệ sinh thái nguồn mở JavaScript. Gần đây, một số tính năng tối ưu hoá mới hơn đã được thêm vào để cải thiện hiệu suất tải của Next.js và Gatsby. Bài viết này đề cập đến chiến lược phân đoạn chi tiết được cải tiến hiện được cung cấp theo mặc định trong cả hai khung.

Giới thiệu

Giống như nhiều khung web, Next.js và Gatsby sử dụng webpack làm trình đóng gói cốt lõi. webpack phiên bản 3 đã ra mắt CommonsChunkPlugin để có thể xuất các mô-đun được chia sẻ giữa các điểm truy cập khác nhau trong một (hoặc một vài) đoạn "commons" (hoặc các đoạn). Mã dùng chung có thể được tải xuống riêng biệt và lưu trữ trong bộ nhớ đệm của trình duyệt từ sớm, nhờ đó có thể giúp cải thiện hiệu suất tải.

Mẫu này trở nên phổ biến với nhiều khung ứng dụng trang đơn áp dụng cấu hình điểm truy cập và gói như sau:

Cấu hình gói và điểm truy cập chung

Mặc dù thực tế, khái niệm gói tất cả mã mô-đun dùng chung vào một đoạn mã duy nhất có những hạn chế. Các mô-đun không được chia sẻ trong mọi điểm truy cập có thể được tải xuống cho các tuyến không sử dụng mô-đun đó, dẫn đến việc tải xuống nhiều mã hơn mức cần thiết. Ví dụ: khi page1 tải đoạn common, đoạn này sẽ tải mã cho moduleC mặc dù page1 không sử dụng moduleC. Vì lý do này, cùng với một số lý do khác, webpack phiên bản 4 đã xoá trình bổ trợ này để thay bằng một trình bổ trợ mới: SplitChunksPlugin.

Cải thiện tính năng phân đoạn

Chế độ cài đặt mặc định cho SplitChunksPlugin phù hợp với hầu hết người dùng. Nhiều đoạn phân tách được tạo dựa trên một số điều kiện để ngăn việc tìm nạp mã trùng lặp trên nhiều tuyến.

Tuy nhiên, nhiều khung web sử dụng trình bổ trợ này vẫn tuân theo phương pháp "single-commons" (một điểm chung) để phân tách đoạn. Ví dụ: Next.js sẽ tạo một gói commons chứa mọi mô-đun được dùng trong hơn 50% số trang và tất cả các phần phụ thuộc của khung (react, react-dom, v.v.).

const splitChunksConfigs = {
  …
  prod: {
    chunks: 'all',
    cacheGroups: {
      default: false,
      vendors: false,
      commons: {
        name: 'commons',
        chunks: 'all',
        minChunks: totalPages > 2 ? totalPages * 0.5 : 2,
      },
      react: {
        name: 'commons',
        chunks: 'all',
        test: /[\\/]node_modules[\\/](react|react-dom|scheduler|use-subscription)[\\/]/,
      },
    },
  },

Mặc dù việc đưa mã phụ thuộc vào khung vào một đoạn mã dùng chung có nghĩa là mã đó có thể được tải xuống và lưu vào bộ nhớ đệm cho bất kỳ điểm truy cập nào, nhưng phương pháp phỏng đoán dựa trên mức sử dụng của việc đưa các mô-đun phổ biến được dùng trong hơn một nửa số trang vào không hiệu quả lắm. Việc sửa đổi tỷ lệ này sẽ chỉ dẫn đến một trong hai kết quả:

Nếu bạn giảm tỷ lệ này, thì nhiều mã không cần thiết sẽ được tải xuống.
Nếu bạn tăng tỷ lệ này, thì sẽ có nhiều mã hơn bị trùng lặp trên nhiều tuyến.

Để giải quyết vấn đề này, Next.js đã áp dụng một cấu hình khác cho SplitChunksPlugin để giảm mã không cần thiết cho mọi tuyến.

Mọi mô-đun bên thứ ba đủ lớn (lớn hơn 160 KB) đều được chia thành từng phần riêng biệt
Một đoạn frameworks riêng biệt được tạo cho các phần phụ thuộc của khung (react, react-dom, v.v.)
Tạo nhiều đoạn mã dùng chung nếu cần (tối đa 25)
Kích thước tối thiểu để tạo một đoạn được thay đổi thành 20 KB

Chiến lược phân đoạn chi tiết này mang lại những lợi ích sau:

Thời gian tải trang được cải thiện. Việc phát ra nhiều đoạn mã dùng chung thay vì một đoạn mã duy nhất sẽ giảm thiểu lượng mã không cần thiết (hoặc trùng lặp) cho mọi điểm truy cập.
Cải thiện việc lưu vào bộ nhớ đệm trong quá trình điều hướng. Việc chia các thư viện lớn và phần phụ thuộc khung thành các đoạn riêng biệt sẽ làm giảm khả năng mất hiệu lực của bộ nhớ đệm vì cả hai đều không có khả năng thay đổi cho đến khi quá trình nâng cấp được thực hiện.

Bạn có thể xem toàn bộ cấu hình mà Next.js đã áp dụng trong webpack-config.ts.

Yêu cầu HTTP khác

SplitChunksPlugin đã xác định cơ sở cho việc phân đoạn chi tiết và việc áp dụng phương pháp này cho một khung như Next.js không phải là một khái niệm hoàn toàn mới. Tuy nhiên, nhiều khung vẫn tiếp tục sử dụng một chiến lược gói "chung" và heuristic duy nhất vì một số lý do. Điều này bao gồm cả mối lo ngại rằng nhiều yêu cầu HTTP hơn có thể ảnh hưởng tiêu cực đến hiệu suất trang web.

Trình duyệt chỉ có thể mở một số lượng kết nối TCP giới hạn đến một nguồn gốc (6 đối với Chrome), vì vậy, việc giảm thiểu số lượng đoạn do trình đóng gói xuất ra có thể đảm bảo rằng tổng số yêu cầu luôn nằm dưới ngưỡng này. Tuy nhiên, điều này chỉ đúng với HTTP/1.1. Tính năng ghép kênh trong HTTP/2 cho phép truyền trực tuyến nhiều yêu cầu song song bằng một kết nối duy nhất qua một nguồn gốc duy nhất. Nói cách khác, chúng ta thường không cần lo lắng về việc giới hạn số lượng đoạn mã do trình đóng gói phát ra.

Tất cả các trình duyệt chính đều hỗ trợ HTTP/2. Nhóm Chrome và Next.js muốn xem liệu việc tăng số lượng yêu cầu bằng cách chia gói "commons" duy nhất của Next.js thành nhiều phần được chia sẻ có ảnh hưởng đến hiệu suất tải hay không. Họ bắt đầu bằng cách đo lường hiệu suất của một trang web trong khi sửa đổi số lượng yêu cầu song song tối đa bằng cách sử dụng thuộc tính maxInitialRequests.

Hiệu suất tải trang khi số lượng yêu cầu tăng lên

Trong trung bình 3 lần chạy của nhiều lần thử nghiệm trên một trang web, thời gian load, bắt đầu hiển thị và Nội dung đầu tiên hiển thị đều giữ nguyên khi thay đổi số lượng yêu cầu ban đầu tối đa (từ 5 đến 15). Điều thú vị là chúng tôi nhận thấy hiệu suất chỉ giảm nhẹ sau khi chia nhỏ thành hàng trăm yêu cầu.

Hiệu suất tải trang với hàng trăm yêu cầu

Điều này cho thấy rằng việc duy trì dưới ngưỡng đáng tin cậy (20 đến 25 yêu cầu) đã đạt được sự cân bằng phù hợp giữa hiệu suất tải và hiệu quả lưu vào bộ nhớ đệm. Sau một số thử nghiệm cơ bản, 25 được chọn làm số lượng maxInitialRequest.

Việc sửa đổi số lượng yêu cầu tối đa xảy ra song song dẫn đến nhiều gói dùng chung, và việc tách chúng một cách thích hợp cho mỗi điểm truy cập đã giảm đáng kể lượng mã không cần thiết cho cùng một trang.

Giảm tải trọng JavaScript bằng cách tăng cường phân đoạn

Thử nghiệm này chỉ nhằm mục đích sửa đổi số lượng yêu cầu để xem liệu có bất kỳ ảnh hưởng tiêu cực nào đến hiệu suất tải trang hay không. Kết quả cho thấy việc đặt maxInitialRequests thành 25 trên trang thử nghiệm là tối ưu vì giúp giảm kích thước tải trọng JavaScript mà không làm chậm trang. Tổng lượng JavaScript cần thiết để tải trang vẫn giữ nguyên, điều này giải thích lý do hiệu suất tải trang không nhất thiết phải cải thiện khi lượng mã giảm.

webpack sử dụng 30 KB làm kích thước tối thiểu mặc định cho một đoạn được tạo. Tuy nhiên, việc kết hợp giá trị maxInitialRequests là 25 với kích thước tối thiểu là 20 KB lại giúp lưu vào bộ nhớ đệm hiệu quả hơn.

Giảm kích thước bằng các đoạn chi tiết

Nhiều khung, bao gồm cả Next.js, dựa vào định tuyến phía máy khách (do JavaScript xử lý) để chèn các thẻ tập lệnh mới hơn cho mỗi quá trình chuyển đổi tuyến. Nhưng làm cách nào để họ xác định trước các đoạn động này tại thời điểm xây dựng?

Next.js sử dụng tệp kê khai bản dựng phía máy chủ để xác định những đoạn dữ liệu đầu ra nào được các điểm truy cập khác nhau sử dụng. Để cung cấp thông tin này cho ứng dụng, một tệp kê khai bản dựng phía máy khách rút gọn đã được tạo để liên kết tất cả các phần phụ thuộc cho mọi điểm truy cập.

// Returns a promise for the dependencies for a particular route
getDependencies (route) {
  return this.promisedBuildManifest.then(
    man => (man[route] && man[route].map(url => `/_next/${url}`)) || []
  )
}

Kết quả của nhiều đoạn mã được chia sẻ trong một ứng dụng Next.js.

Chiến lược phân đoạn chi tiết mới hơn này lần đầu tiên được triển khai trong Next.js sau một cờ, nơi chiến lược này được thử nghiệm trên một số người dùng sớm. Nhiều trang web đã giảm đáng kể tổng lượng JavaScript được sử dụng cho toàn bộ trang web:

Giảm kích thước JavaScript – trên tất cả các tuyến (đã nén)
Trang web	Tổng thay đổi về JS	Mức chênh lệch (%)
https://www.barnebys.com/	-238 KB	-23%
https://sumup.com/	-220 KB	-30%
https://www.hashicorp.com/	-11 MB	-71%

Phiên bản cuối cùng được cung cấp theo mặc định trong phiên bản 9.2.

Gatsby

Gatsby từng áp dụng phương pháp tương tự là sử dụng phương pháp phỏng đoán dựa trên mức sử dụng để xác định các mô-đun phổ biến:

config.optimization = {
  …
  splitChunks: {
    name: false,
    chunks: `all`,
    cacheGroups: {
      default: false,
      vendors: false,
      commons: {
        name: `commons`,
        chunks: `all`,
        // if a chunk is used more than half the components count,
        // we can assume it's pretty global
        minChunks: componentsCount > 2 ? componentsCount * 0.5 : 2,
      },
      react: {
        name: `commons`,
        chunks: `all`,
        test: /[\\/]node_modules[\\/](react|react-dom|scheduler)[\\/]/,
      },

Bằng cách tối ưu hoá cấu hình webpack để áp dụng chiến lược phân đoạn chi tiết tương tự, họ cũng nhận thấy mức giảm đáng kể về JavaScript trên nhiều trang web lớn:

Giảm kích thước JavaScript – trên tất cả các tuyến (đã nén)
Trang web	Tổng thay đổi về JS	Mức chênh lệch (%)
https://www.gatsbyjs.org/	-680 KB	-22%
https://www.thirdandgrove.com/	-390 KB	Dưới 25%
https://ghost.org/	-1,1 MB	-35%
https://reactjs.org/	-80 Kb	-8%

Hãy xem PR để hiểu cách họ triển khai logic này vào cấu hình webpack, được cung cấp theo mặc định trong phiên bản 2.20.7.

Kết luận

Khái niệm về việc vận chuyển các đoạn chi tiết không dành riêng cho Next.js, Gatsby hay thậm chí là webpack. Mọi người nên cân nhắc cải thiện chiến lược phân đoạn của ứng dụng nếu chiến lược đó tuân theo phương pháp gói "commons" lớn, bất kể khung hoặc trình đóng gói mô-đun được sử dụng.

Nếu bạn muốn xem các hoạt động tối ưu hoá phân đoạn tương tự được áp dụng cho một ứng dụng React thuần tuý, hãy xem ứng dụng React mẫu này. Ứng dụng này sử dụng phiên bản đơn giản hoá của chiến lược phân đoạn chi tiết và có thể giúp bạn bắt đầu áp dụng cùng một loại logic cho trang web của mình.
Đối với Rollup, các đoạn được tạo một cách chi tiết theo mặc định. Hãy xem manualChunks nếu bạn muốn định cấu hình hành vi theo cách thủ công.