Build và tối ưu bundle

Mục lụcCopy Anchor Link

• Tổng quan
  • Kết quả cần tối ưu
  • Từ mã nguồn đến tệp trình duyệt tải
• Production build và budgets
  • Budgets là cổng chất lượng
  • Cấu hình một production build
  • Chọn ngưỡng theo baseline
• Phân tích bundle trước khi sửa
  • Đọc đầu ra build
  • Tìm module thật sự gây nặng
  • So sánh cùng điều kiện
• Code splitting và lazy loading
  • Tách theo route
  • Hoãn UI trong một route
  • Lazy loading không tự chữa mọi vấn đề
• Assets, styles và dependency
  • Ảnh, font và tệp tĩnh
  • CSS toàn cục và style component
  • Import có chủ đích
• Cấu hình production và cache
  • Tối ưu, source map và tên chunk
  • Hash tệp và cấu hình runtime
• Quy trình đo lường và xử lý regression
  • Vòng lặp năm bước
  • Ví dụ xử lý một bundle vượt budget
• Lỗi thường gặp và trade-off
• Checklist và tóm tắt

Tổng quanCopy Anchor Link

Kết quả cần tối ưuCopy Anchor Link

Một ứng dụng Angular có thể có kích thước build nhỏ nhưng vẫn tải chậm, hoặc có bundle ban đầu lớn hơn một chút nhưng phản hồi tốt hơn vì cache hiệu quả. Vì vậy cần tách ba câu hỏi:

Bundle là nhóm JavaScript, CSS và tài nguyên mà trình duyệt nhận sau khi Angular đóng gói ứng dụng. Initial bundle là phần cần cho lượt tải đầu; lazy chunk là phần chỉ được tải khi mã điều hướng hoặc hiển thị nó. Nén HTTP như Brotli làm giảm bytes truyền trên mạng, nhưng không xóa chi phí phân tích và thực thi JavaScript. Vì thế giảm mã không cần thiết vẫn có giá trị.

Từ mã nguồn đến tệp trình duyệt tảiCopy Anchor Link

Khi chạy production build, Angular CLI đọc entry point, lần theo các import, biên dịch template và tối ưu đầu ra. Bundler loại phần mã không được dùng khi có thể (tree shaking), gộp hoặc tách module thành chunks, rút gọn mã và sinh tệp trong thư mục output. Cấu hình builder và phiên bản Angular quyết định chi tiết tên tệp, định dạng stats và thuật toán đóng gói; không nên giả định mọi dự án có cùng một danh sách chunks.

direction: right

source: "Code + thư viện +\nassets" {
  width: 160
  height: 58
}

cli: "Angular CLI\nProduction build" {
  width: 152
  height: 58
}

compile: "Compile" {
  width: 130
  height: 58
}

shake: "Tree shaking" {
  width: 130
  height: 58
}

minify: "Minify / CSS optimize" {
  width: 192
  height: 58
}

chunks: "Initial + lazy chunks\nAssets" {
  width: 192
  height: 58
}

source -> cli
cli -> compile
cli -> shake
cli -> minify
compile -> chunks
shake -> chunks
minify -> chunks

direction: right

n0: "Initial + lazy chunks\nAssets" {
  width: 192
  height: 58
}

n1: "CDN / browser cache" {
  width: 176
  height: 58
}

n2: "Người dùng tải\ntheo nhu cầu" {
  width: 136
  height: 58
}

n0 -> n1
n1 -> n2

Tree shaking chỉ hoạt động tốt khi dependency công bố module có thể phân tích tĩnh và ứng dụng import đúng phần cần dùng. Một package CommonJS, một import tập hợp quá lớn, hoặc side effect lúc nạp module có thể khiến bundler phải giữ lại nhiều mã hơn dự kiến. Hãy xem output thay vì tin rằng mọi import đều được loại bỏ tự động.

Production build và budgetsCopy Anchor Link

Budgets là cổng chất lượngCopy Anchor Link

Budget là giới hạn kích thước Angular CLI kiểm tra sau build. Nó không làm bundle nhỏ đi; nó biến mức kích thước đã thống nhất thành warning hoặc error. Warning yêu cầu người review chú ý. Error làm build thất bại, phù hợp với ngưỡng không được phép vượt qua trong CI.

Các loại budget thường hữu ích:

CLI còn hỗ trợ các loại khác tùy builder, chẳng hạn any. Hãy kiểm tra schema của builder đang dùng trước khi đưa một loại mới vào policy. Với bundle, giá trị name phải khớp tên bundle mà build thực sự sinh ra; nó không phải tên component tùy ý.

Cấu hình một production buildCopy Anchor Link

Trong workspace dùng application builder hiện đại, budgets thường đặt trong cấu hình production của target build trong angular.json. Tên project và các option có thể khác nhau; hãy ghép ví dụ sau vào target đang có, không thay nguyên khối cấu hình của dự án.

{
  "projects": {
    "storefront": {
      "architect": {
        "build": {
          "builder": "@angular-devkit/build-angular:application",
          "configurations": {
            "production": {
              "optimization": true,
              "sourceMap": false,
              "namedChunks": false,
              "outputHashing": "all",
              "extractLicenses": true,
              "budgets": [
                {
                  "type": "initial",
                  "maximumWarning": "500kB",
                  "maximumError": "650kB"
                },
                {
                  "type": "anyScript",
                  "maximumWarning": "250kB",
                  "maximumError": "350kB"
                },
                {
                  "type": "anyComponentStyle",
                  "maximumWarning": "6kB",
                  "maximumError": "10kB"
                }
              ]
            }
          }
        }
      }
    }
  }
}

Chạy đúng cấu hình cần kiểm tra bằng:

ng build --configuration production

Kết quả terminal thường cho biết các tệp đầu ra và kích thước của chúng. Coi đó là artefact review: lưu log CI hoặc báo cáo chênh lệch khi pull request thay đổi kích thước đáng kể. Đừng dùng ng serve làm bằng chứng thay cho production build; development server ưu tiên phản hồi khi lập trình, không đại diện cho mã được phát hành.

Chọn ngưỡng theo baselineCopy Anchor Link

Các số 500kB và 650kB ở trên chỉ là ví dụ, không phải chuẩn chung. Ngưỡng phù hợp phụ thuộc vào loại ứng dụng, người dùng, cache, mạng mục tiêu và mức hiện tại. Thiết lập budget theo trình tự sau:

1. Build production ở commit ổn định, không có thay đổi đang thử nghiệm.
2. Ghi kích thước initial, các JS chunk lớn nhất, CSS lớn nhất và các assets quan trọng. Ghi cả đơn vị mà CLI hiển thị.
3. Chọn warning đủ gần baseline để phát hiện regression sớm, chẳng hạn phần tăng hợp lý đã được cả nhóm thống nhất.
4. Chọn error là giới hạn cần hành động. Nếu vượt error, PR phải tách mã, bỏ dependency, hoặc có quyết định ngoại lệ rõ ràng.
5. Rà lại ngưỡng sau thay đổi sản phẩm có chủ đích. Budget là policy sống, không phải một con số bất biến.

Dùng baseline — số đo được chấp nhận tại một commit xác định — tránh hai cực đoan: đặt ngưỡng quá thấp khiến mọi build hỏng, hoặc quá cao đến mức không phát hiện được regression thật.

Phân tích bundle trước khi sửaCopy Anchor Link

Đọc đầu ra buildCopy Anchor Link

Bắt đầu bằng production build và trả lời ba câu hỏi đơn giản:

ng build --configuration production

1. Chunk nào thuộc initial output và chunk nào là lazy?
2. Tệp hoặc stylesheet nào lớn bất thường so với baseline?
3. Cảnh báo budget trỏ đến loại nào: initial, một script, hay style component?

Một chunk lazy lớn không mặc định là lỗi. Nó có thể là editor, bản đồ hoặc báo cáo chỉ dùng sau một thao tác rõ ràng. Vấn đề xuất hiện khi chunk đó bị tải sớm, bị tải lặp lại do cache cấu hình sai, hoặc làm thao tác mở tính năng chậm hơn mức người dùng chấp nhận.

Khi cần dữ liệu chi tiết hơn, bật thống kê nếu builder của workspace hỗ trợ option đó:

ng build --configuration production --stats-json

Tệp stats.json và công cụ đọc nó phụ thuộc vào builder Angular đang dùng. Hãy xác minh định dạng stats trong output hoặc tài liệu của đúng phiên bản CLI trước khi đưa vào webpack-bundle-analyzer, source-map-explorer hay công cụ khác. Không nên nạp một stats file của esbuild vào công cụ chỉ hiểu webpack rồi suy luận từ báo cáo lỗi.

Tìm module thật sự gây nặngCopy Anchor Link

Một treemap hoặc báo cáo module giúp trả lời “bytes đến từ package nào?”, nhưng không tự đưa ra giải pháp. Với mỗi mục lớn, lần theo chuỗi sau:

Đặc biệt kiểm tra import path, không chỉ tên package. Ví dụ sau kéo toàn bộ namespace icons dù component chỉ dùng một biểu tượng:

// Tránh khi thư viện không tree-shake được theo namespace.
import * as icons from 'large-icon-library';

export const saveIcon = icons.save;

Ưu tiên API có import theo biểu tượng hoặc module nhỏ, nếu thư viện hỗ trợ:

import { saveIcon } from 'large-icon-library/icons/save';

export { saveIcon };

Ví dụ thứ hai chỉ có ích khi package có export path tương ứng và đánh dấu side effect đúng. Đừng tự đổi import hàng loạt chỉ vì một quy tắc chung; build lại và so sánh output để chứng minh lợi ích.

So sánh cùng điều kiệnCopy Anchor Link

So sánh production với production, cùng phiên bản Node/CLI và cùng lockfile. Một chênh lệch do cập nhật dependency hoặc do cache build lạnh có thể bị nhầm với thay đổi mã. Bảng review tối thiểu nên có:

Kích thước transfer sau gzip/Brotli và kích thước parsed/executed là các số khác nhau. Nếu mục tiêu là trải nghiệm thật, hãy bổ sung phép đo Network và Performance trong trình duyệt, theo cùng thiết bị và điều kiện mạng. Xem bài Profiling hiệu năng để thiết kế baseline trải nghiệm.

Code splitting và lazy loadingCopy Anchor Link

Tách theo routeCopy Anchor Link

Route là ranh giới code splitting tự nhiên vì người dùng thường chỉ vào một phần ứng dụng trong một phiên. Với standalone component, loadComponent trì hoãn việc tải component cho đến lúc router cần route đó:

import { Routes } from '@angular/router';

export const routes: Routes = [
  {
    path: '',
    pathMatch: 'full',
    loadComponent: () =>
      import('./features/home/home-page.component').then((m) => m.HomePageComponent),
  },
  {
    path: 'reports',
    loadComponent: () =>
      import('./features/reports/reports-page.component').then(
        (m) => m.ReportsPageComponent,
      ),
  },
];

Khi người dùng đang ở trang chủ, route reports không cần nằm trong initial chunk chỉ vì nó được khai báo trong router. Tương tự, một feature có nhiều routes con có thể dùng loadChildren để lazy-load cả tập routes:

import { Routes } from '@angular/router';

export const routes: Routes = [
  {
    path: 'admin',
    loadChildren: () =>
      import('./features/admin/admin.routes').then((m) => m.ADMIN_ROUTES),
  },
];

// features/admin/admin.routes.ts
import { Routes } from '@angular/router';

export const ADMIN_ROUTES: Routes = [
  {
    path: '',
    loadComponent: () =>
      import('./admin-dashboard.component').then((m) => m.AdminDashboardComponent),
  },
];

Đặt dependency nặng gần feature lazy. Nếu app.component.ts, một service được cung cấp ở root, hoặc một shared barrel import thư viện chart, editor hay map, mã đó vẫn có thể bị kéo vào initial graph. Lazy route chỉ tách được mã không bị import eager từ nơi khác.

Hoãn UI trong một routeCopy Anchor Link

Không phải mọi phần nặng đều xứng đáng có route riêng. Với UI nằm dưới màn hình đầu hoặc chỉ mở sau tương tác, @defer tạo ranh giới hoãn tải trong template. Ví dụ trang sản phẩm hiển thị mô tả ngay nhưng chỉ tải đánh giá khi phần placeholder đi vào viewport:

import { Component } from '@angular/core';
import { ProductSummaryComponent } from './product-summary.component';
import { ProductReviewsComponent } from './product-reviews.component';

@Component({
  selector: 'app-product-page',
  imports: [ProductSummaryComponent, ProductReviewsComponent],
  template: `
    <app-product-summary />

    @defer (on viewport) {
      <app-product-reviews />
    } @placeholder {
      <p>Cuộn xuống để tải đánh giá.</p>
    } @loading (minimum 300ms) {
      <p>Đang tải đánh giá…</p>
    } @error {
      <p>Không thể tải phần đánh giá. Hãy thử lại.</p>
    }
  `,
})
export class ProductPageComponent {}

Dependency trong khối @defer chỉ có thể được lazy-load khi nó là standalone và không được tham chiếu eager ở cùng tệp hoặc ngoài khối. ProductSummaryComponent là import eager nên vẫn nằm trong tải đầu. Hãy dùng DevTools Network hoặc output build để xác nhận reviews thực sự thành chunk riêng.

Các trigger như on interaction, on viewport và when condition phục vụ hành vi khác nhau. Chọn trigger dựa vào lúc người dùng thực sự cần UI. Nếu reviews quan trọng cho quyết định mua, hoãn đến viewport có thể hợp lý; nếu thông tin là thiết yếu ở màn hình đầu, nó chỉ tạo độ trễ không cần thiết.

Lazy loading không tự chữa mọi vấn đềCopy Anchor Link

Lazy loading đổi thời điểm tải, không làm dependency tự nhỏ hơn. Nó có các trade-off rõ ràng:

• Route đầu có thể nhanh hơn, nhưng lần mở route lazy đầu tiên có thêm độ trễ mạng và parse JavaScript.
• Quá nhiều chunks nhỏ có thể tăng request, overhead điều phối và làm luồng debug phức tạp hơn.
• Preloading có thể cải thiện lần điều hướng sau, nhưng cũng cạnh tranh băng thông với nội dung hiện tại. Chỉ preload route có xác suất truy cập cao.
• Người dùng có mạng yếu có thể thấy placeholder lâu. Luôn thiết kế loading/error state, thay vì để vùng trống.
• Lazy route không phải ranh giới bảo mật. Guard và kiểm tra quyền ở server vẫn là nguồn bảo vệ; mã đã tải về trình duyệt không nên chứa bí mật.

Nói ngắn gọn: tách theo hành trình người dùng, đo thời gian mở feature lần đầu, rồi quyết định có preload hay không.

Assets, styles và dependencyCopy Anchor Link

Ảnh, font và tệp tĩnhCopy Anchor Link

Assets có thể không xuất hiện trong budget JavaScript nhưng vẫn quyết định Largest Contentful Paint (LCP), chi phí dữ liệu và tốc độ render. Xử lý chúng theo vai trò:

Với NgOptimizedImage, priority dành cho ảnh LCP thật sự; nó không phải cờ gắn cho mọi ảnh quan trọng theo cảm giác. Một trang chỉ nên có rất ít ảnh priority để chúng không tranh tải với nhau.

<!-- Ảnh hero đã biết kích thước: ưu tiên tải. -->
<img
  ngSrc="/products/hero-960.webp"
  width="960"
  height="540"
  priority
  alt="Bàn làm việc gỗ sáng"
/>

<!-- Ảnh ở phần nội dung sau: browser có thể hoãn tải. -->
<img
  ngSrc="/products/detail-640.webp"
  width="640"
  height="480"
  loading="lazy"
  alt="Góc nghiêng của sản phẩm"
/>

Ví dụ cần import directive NgOptimizedImage vào standalone component hoặc module đang khai báo template. Kiểm tra request thực tế: server/CDN phải trả đúng định dạng, kích thước và cache header thì tối ưu trong template mới tạo hiệu quả cuối cùng.

CSS toàn cục và style componentCopy Anchor Link

styles toàn cục trong angular.json thường đi vào stylesheet toàn cục. Hãy đặt reset, token thiết kế, CSS nền tảng và style dùng thật sự xuyên ứng dụng ở đó. Một framework CSS đầy đủ hoặc bộ theme lớn đưa vào global styles sẽ ảnh hưởng mọi lượt tải, kể cả khi chỉ một trang dùng vài class của nó.

Style component có lợi vì gần component và có thể bị budget anyComponentStyle bảo vệ. Tuy nhiên, sao chép cùng animation, data URI, danh sách breakpoint hoặc selector sâu vào nhiều component làm output phình lên và khó bảo trì. Giải pháp không phải luôn là dồn mọi thứ vào global CSS; hãy tách token, utility hoặc stylesheet dùng chung thật sự có phạm vi hợp lý.

Import có chủ đíchCopy Anchor Link

Dependency thường là nguồn tăng bundle lớn nhất. Trước khi cài hoặc giữ một package, trả lời:

• Chức năng có thể dùng API trình duyệt hoặc Angular sẵn có không?
• Có cần package đó ở initial path không, hay chỉ feature hiếm dùng cần nó?
• Package có ESM/export theo phần, type declaration và lịch sử bảo trì phù hợp không?
• Có hai package đang giải quyết cùng một việc, ví dụ hai thư viện ngày tháng hoặc hai icon set, không?

Barrel file nội bộ (index.ts) hữu ích cho public API nhưng có thể che import eager. Nó không luôn làm tree shaking thất bại, nhưng nó khiến người đọc khó nhận ra component nào kéo dependency nào. Với feature nặng, import trực tiếp entry chuyên biệt và xác minh output sẽ minh bạch hơn.

Cấu hình production và cacheCopy Anchor Link

Tối ưu, source map và tên chunkCopy Anchor Link

Các option production phổ biến có mục đích khác nhau:

Các option hợp lệ và default có thể thay đổi theo Angular CLI/builder. Đừng sao chép config cũ dùng webpack vào application builder mới mà không chạy build. Schema của angular.json, ng build --help và output CI là nguồn kiểm chứng cho workspace cụ thể.

Source map là trade-off giữa khả năng điều tra và nguy cơ lộ source. Nếu phát hành map công khai, người dùng có thể đọc cấu trúc source dễ hơn. Nếu tắt hoàn toàn, stack trace minified khó hành động. Một lựa chọn thường dùng là giữ map ngoài public hosting, upload vào công cụ error tracking có kiểm soát truy cập, và kiểm tra rằng deploy không vô tình public *.map.

Hash tệp và cấu hình runtimeCopy Anchor Link

Khi nội dung tệp thay đổi, outputHashing: "all" tạo tên như main.A1B2C3.js. CDN có thể cache tệp hash lâu vì URL mới được sinh khi nội dung mới xuất hiện. HTML entry point phải được cập nhật nhanh hơn để trỏ đến hash mới.

direction: right

n0: "HTML entry\nCache ngắn /\nrevalidate" {
  width: 130
  height: 79
}

n1: "main.A1B2C3.js\nstyles.D4E5F6.css\nCache dài, immutable" {
  width: 184
  height: 79
}

n2: "Release sau\nNội dung mới → URL\nhash mới" {
  width: 168
  height: 79
}

n0 -> n1: "Tham chiếu"
n1 -> n2

Không đặt bí mật vào environment.ts, JSON cấu hình public hay bất kỳ bundle nào. Mọi giá trị client nhận được đều có thể bị xem. Với URL API hoặc feature flag không bí mật cần đổi sau build, cân nhắc file cấu hình runtime được deploy cùng ứng dụng, được tải trước bootstrap và có cache policy rõ ràng. Trade-off là thêm request và cần xử lý lỗi/timing bootstrap; đổi lại không cần build lại chỉ để đổi endpoint công khai.

Quy trình đo lường và xử lý regressionCopy Anchor Link

Vòng lặp năm bướcCopy Anchor Link

Tối ưu an toàn là một vòng lặp ngắn, không phải danh sách mẹo. Mỗi lần chỉ thay đổi một giả thuyết.

1. Tạo baseline. Chạy ng build --configuration production, lưu output, budget warnings và phép đo Network/Performance cho route mục tiêu.
2. Khoanh vùng. Chọn một chunk, asset hoặc thao tác chậm. Dùng báo cáo bundle để biết dependency nào đóng góp bytes.
3. Nêu giả thuyết. Ví dụ: “Chart chỉ dùng ở /reports, nên đưa import vào route lazy sẽ giảm initial.”
4. Thay đổi nhỏ và kiểm tra đúng. Sửa ranh giới import/route, chạy lại test liên quan và production build. Mở route lazy lần đầu để đảm bảo UI, loading và error state vẫn đúng.
5. So sánh và quyết định. Ghi chênh lệch, tác động UX và trade-off. Giữ thay đổi nếu nó giải quyết mục tiêu; nếu không, hoàn tác và thử giả thuyết khác.

Ví dụ xử lý một bundle vượt budgetCopy Anchor Link

Giả sử CI báo initial là 690 kB, vượt maximumError 650 kB. Cách xử lý có bằng chứng:

1. Xác nhận CI chạy --configuration production, lockfile không đổi ngoài ý muốn và so sánh với artefact commit trước.
2. Đọc output để biết phần tăng nằm ở initial hay chỉ là lazy chunk. Nếu only lazy tăng, kiểm tra budget đang áp dụng đúng loại hay không.
3. Mở báo cáo module. Phát hiện thư viện biểu đồ 180 kB được import từ app.component.ts, trong khi chỉ route /reports sử dụng nó.
4. Chuyển component biểu đồ và import thư viện vào route/component lazy. Kiểm tra không còn import chart thông qua service root hoặc shared barrel eager.
5. Chạy lại build, test route reports và mở reports với cache lạnh. Ghi initial mới, thời gian mở reports lần đầu, và trạng thái loading.

Nếu reports là phần chính mà hầu hết người dùng mở ngay sau đăng nhập, có thể preload route sau khi màn hình đầu ổn định. Quyết định này hợp lệ nếu số đo cho thấy nó cải thiện trải nghiệm tổng thể. Nó không hợp lệ nếu chỉ nhằm làm build không báo lỗi mà không đánh giá chi phí request mới.

Lỗi thường gặp và trade-offCopy Anchor Link

Một tối ưu có thể làm bundle nhỏ hơn nhưng code khó hiểu hoặc trải nghiệm xấu hơn. Ví dụ, dynamic import cho một utility 2 kB có thể tốn nhiều hơn lợi ích vì thêm asynchronous boundary. Chỉ tạo ranh giới lazy khi dữ liệu hành vi và kích thước đủ lớn để bù cho độ phức tạp.

Checklist và tóm tắtCopy Anchor Link

Trước khi chấp nhận thay đổi ảnh hưởng build, hãy xác minh:

• Đã chạy ng build --configuration production, không thay ng serve bằng production build.
• Budget initial, script và component style có ngưỡng dựa trên baseline, warning/error có ý nghĩa.
• Mọi thay đổi kích thước đáng kể có output hoặc báo cáo module giải thích nguyên nhân.
• Route hoặc block @defer lazy đã được mở với cache lạnh; có loading/error state phù hợp.
• Dependency lớn không còn bị import eager từ shell, root service hoặc shared barrel khi feature của nó là lazy.
• Ảnh LCP, ảnh dưới viewport, font và CSS đã được xem riêng, không chỉ đo JavaScript.
• Cache hash, HTML entry và source map có policy phù hợp môi trường deploy.
• Không có secret trong environment, assets public hay bundle; test và phép đo liên quan vẫn đạt.

Tóm lại, production build tạo ra artefact để kiểm chứng, budgets giữ regression không đi qua im lặng, và bundle analysis chỉ đường đến nguyên nhân. Code splitting, lazy loading, tối ưu asset/CSS và cache là các công cụ có trade-off. Hãy bắt đầu từ số đo của hành trình người dùng, thay đổi một nguyên nhân tại một thời điểm, rồi lưu bằng chứng trước/sau.